What it is: Windows Shortcut Following (.LNK) (CWE-64) is a type of link-following vulnerability where an application opens a Windows shortcut file without checking whether its target lies outside the intended control sphere.
Why it matters: An attacker-controlled .LNK file can silently redirect a file operation to an unauthorized file, letting them read or write data the application never intended to touch.
How to fix it: Detect shortcut files before opening them and validate their resolved target against an allowed base directory, or reject shortcuts in untrusted directories entirely.
TL;DR: CWE-64 lets an attacker plant a malicious .LNK shortcut that redirects a file operation to an unauthorized target; the fix is detecting and validating shortcut targets before following them.
| Field | Value |
|---|---|
| CWE ID | CWE-64 |
| OWASP Category | Not directly mapped |
| CAPEC | None known |
| Typical Severity | Medium |
| Affected Technologies | Windows applications, Windows file systems |
| Detection Difficulty | Hard |
| Last Updated | 2026-07-27 |
What is Windows Shortcut Following?
Windows Shortcut Following (.LNK) (CWE-64) is a type of link-following vulnerability that occurs when a product, upon opening a file or directory, does not sufficiently handle the case where the file is a Windows shortcut (.LNK) whose target lies outside the intended control sphere. As defined by the MITRE Corporation under CWE-64, this weakness has no official OWASP Top 10:2025 category mapping and is a direct child of Improper Link Resolution Before File Access (‘Link Following’) (CWE-59).
Quick Summary
A .LNK file isn’t the file it appears to be — it’s a pointer to somewhere else entirely, and Windows will happily follow that pointer when an application opens it unless the application specifically checks first. MITRE rates the likelihood of exploit as Low, since it typically requires the attacker to get a crafted shortcut into a location the target application will process, but the underlying mechanism is the same link-following risk that affects symlinks on other platforms.
Jump to: Quick Summary · Windows Shortcut Following Overview · How Windows Shortcut Following Works · Business Impact of Windows Shortcut Following · Windows Shortcut Following Attack Scenario · How to Detect Windows Shortcut Following · How to Fix Windows Shortcut Following · Framework-Specific Fixes for Windows Shortcut Following · How to Ask AI to Check Your Code for Windows Shortcut Following · Windows Shortcut Following Best Practices Checklist · Windows Shortcut Following FAQ · Vulnerabilities Related to Windows Shortcut Following · References · Scan Your Own Site
Windows Shortcut Following Overview
What: An application opens a file without checking whether it is a Windows shortcut (.LNK), silently following the shortcut to its actual target.
Why it matters: If the target lies outside the application’s intended control sphere, the attacker who planted the shortcut controls what file the operation actually touches.
Where it occurs: File-processing applications that iterate over and open files in a directory an attacker can write to, without distinguishing shortcuts from regular files.
Who is affected: Windows applications that open files in shared, writable, or otherwise attacker-influenceable directories without shortcut-aware validation.
Who is NOT affected: Applications that explicitly detect and reject (or validate the target of) shortcut files before opening them, or that only process files in directories the attacker cannot write to.
How Windows Shortcut Following Works
Root Cause
The application opens a file without first checking whether it is a Windows shortcut, and if it is, without validating that the shortcut’s target lies within the intended control sphere.
Attack Flow
- The attacker gains write access to a directory the target application will process (e.g. a shared upload or watch folder).
- The attacker places a crafted .LNK shortcut pointing at a sensitive file outside the intended directory.
- The application opens the shortcut without checking its type, following it to the attacker-chosen target.
- The application’s file operation (read, write, or execute) is redirected to the unauthorized target.
Prerequisites to Exploit
- The attacker can write a file into a directory the target application processes.
- The application opens files without detecting whether they are shortcuts.
- The shortcut’s target lies outside the application’s intended control sphere and is accessible to the process.
Vulnerable Code
foreach (var filePath in Directory.GetFiles(watchDir))
{
string content = File.ReadAllText(filePath);
Process(content);
}
File.ReadAllText() transparently follows a .lnk shortcut to its target with no check at all, so a crafted shortcut in watchDir silently redirects the read to whatever file the attacker chose.
Secure Code
foreach (var filePath in Directory.GetFiles(watchDir))
{
if (Path.GetExtension(filePath).Equals(".lnk", StringComparison.OrdinalIgnoreCase))
{
continue; // reject shortcuts in untrusted directories outright
}
string content = File.ReadAllText(filePath);
Process(content);
}
Shortcut files are detected by extension and skipped entirely before any file operation runs, closing off the redirection path.
Business Impact of Windows Shortcut Following
Confidentiality: Attackers may read the contents of a file outside the application’s intended scope by redirecting a read operation through a shortcut.
Integrity: Attackers may cause the application to write to or modify a file they choose, if the operation involves writing through the shortcut.
- Unauthorized access to files the application was never meant to touch
- Potential for the attacker to gain read/write access to files they don’t normally have permission to reach directly
Windows Shortcut Following Attack Scenario
- An attacker uploads a file to a shared folder that a backend service periodically scans and processes.
- Instead of a normal file, they place a
.lnkshortcut pointing at a sensitive configuration file elsewhere on the system. - The backend service opens the shortcut without checking its type, and Windows follows it to the configuration file.
- The service processes the configuration file’s contents as if it were the expected upload, potentially exposing or corrupting it.
How to Detect Windows Shortcut Following
Manual Testing
- Identify file-processing features that operate on files in shared or attacker-writable directories.
- Place a
.lnkshortcut pointing at a sensitive file into that directory. - Confirm whether the application follows the shortcut to its target instead of rejecting it.
Automated Scanners (SAST / DAST)
Static analysis can flag file-opening code that doesn’t check for shortcut file types, while dynamic testing with a crafted .lnk file confirms whether the live application actually follows it at runtime.
PenScan Detection
PenScan’s scanner engines test file-processing features with crafted .lnk shortcuts to confirm whether targets outside the intended directory are followed.
False Positive Guidance
If the application only processes files in a directory the attacker has no write access to, this weakness is not practically exploitable even if the code doesn’t explicitly check for shortcuts — confirm actual directory permissions before treating it as a real finding.
How to Fix Windows Shortcut Following
- Detect shortcut files (by extension or file attributes) before opening them.
- Reject shortcuts outright in any directory an untrusted party can write to.
- If shortcuts must be supported, resolve and validate the target path against an allowed base directory before use.
- Apply least-privilege access so a followed shortcut’s target has limited blast radius even if this check is missed.
Framework-Specific Fixes for Windows Shortcut Following
This weakness is specific to the Windows Shell Link (.LNK) file format; it has no equivalent on Linux/macOS, where the analogous risk is symbolic-link following (a related but distinct weakness), so no forced-fit examples are given for those platforms.
- ASP.NET/.NET: check
Path.GetExtension()for.lnkand skip or specially validate such files before any file operation, as shown above. - Java on Windows: use
Files.isSymbolicLink()-equivalent shortcut detection (via a.lnk-aware library, since Java’s own API doesn’t natively resolve Windows shortcuts) before processing a file from an untrusted directory.
How to Ask AI to Check Your Code for Windows Shortcut Following
Review the following [language] code block for potential CWE-64 Windows Shortcut Following (.LNK) vulnerabilities and rewrite it to detect and reject or validate shortcut files before opening them: [paste code here]
Windows Shortcut Following Best Practices Checklist
✅ Detect shortcut files by extension or attribute before opening them ✅ Reject shortcuts in any directory an untrusted party can write to ✅ Validate a shortcut’s resolved target against an allowed base directory if shortcuts must be supported ✅ Apply least-privilege access to limit the impact of any followed shortcut
Windows Shortcut Following FAQ
How does a malicious .LNK file redirect file access?
A Windows shortcut (.LNK) file stores a target path; if an application opens a file without checking whether it is actually a shortcut, following that shortcut can silently redirect the operation to a completely different file the attacker chose.
How is this similar to a symlink attack on Linux?
Both are link-following weaknesses (CWE-59) — Windows shortcut files play the same role as symbolic links on Unix, redirecting a file operation to an unintended target outside the expected control sphere.
How likely is this to be exploited according to MITRE?
MITRE rates the likelihood of exploit for this specific weakness as Low, reflecting that it typically requires the attacker to first get a malicious .LNK file into a location the target application will process.
How do I detect this in my own application?
Place a .LNK file pointing at a sensitive file (e.g. a system file) into a directory the application processes, and observe whether the application follows the shortcut and operates on the target instead of the shortcut file itself.
How do I fix this correctly?
Check whether a file is a shortcut before opening it, and either reject shortcuts entirely in untrusted directories or resolve and validate the target path against an allowed base directory before use.
How does least-privilege access limit the impact even if this isn’t fully fixed?
Running the file-processing application with only the minimum permissions it needs limits what a malicious shortcut’s target can actually expose or modify, even if link-following itself isn’t explicitly checked.
How can PenScan help find this weakness?
PenScan tests file-processing features with crafted .LNK shortcuts pointing outside the intended directory to confirm whether the target is followed unsafely.
Vulnerabilities Related to Windows Shortcut Following
| CWE | Name | Relationship |
|---|---|---|
| CWE-59 | Improper Link Resolution Before File Access (‘Link Following’) | ChildOf |
References
Scan Your Own Site
Manual code review catches what you know to look for. An automated scan catches what you didn’t. Scan your own website using PenScan to find Windows Shortcut Following and other risks before an attacker does.