A link-following vulnerability is a weakness that lets an attacker make a system follow a link or redirect to an unintended location. It commonly appears in web applications, email clients, crawlers, and integrations that process URLs without strict allowlisting or destination validation, which can expose users or services to phishing, server-side request forgery, or data leakage.
How link-following vulnerabilities work
Link-following vulnerabilities emerge when a product accepts a URL, redirect target, or similar destination reference and then follows it without sufficiently checking where that link actually resolves. The defect is less about the link itself and more about trusting attacker-influenced navigation.
That trust can be explicit, as in a user-supplied redirect parameter, or indirect, as in an email client, crawler, preview service, integration, or bot that automatically dereferences a URL. The same weakness can appear in a web app, a desktop client, a backend fetcher, or a workflow that only means to inspect a link but ends up visiting it instead.
Why it is dangerous
Once a system follows an unintended destination, the attacker can steer traffic, data, or trust decisions away from the expected boundary. That can support phishing, server-side request forgery, credential theft, internal network probing, or leakage of tokens and other sensitive data when the destination is attacker-controlled.
The danger is amplified when the affected component has privileged network reach, broad file or metadata access, or trusted relationships with other services. A link-following bug can turn a simple navigation feature into a pivot point that exposes internal resources or makes the application act on behalf of a trusted user or service.
In practice, this weakness often overlaps with server-side request forgery and open redirect patterns. The key difference is the behaviour: the application is being induced to follow a destination that should never have been trusted in the first place. When the surrounding product also processes fetched content, the blast radius can extend beyond redirection into content retrieval, callback abuse, or workflow manipulation.
Where exposure usually comes from
Exposure is easiest to miss when the code path looks harmless, such as link previewing, URL expansion, content moderation, crawler logic, or third-party integration handling. A system may validate the syntax of a URL and still fail to validate its destination, scheme, host, redirect chain, or eventual resolution.
Organisations should trace every place that accepts externally influenced URLs, especially where the component runs with service credentials, internal network access, or elevated trust. For a weakness of this kind, inventory and destination handling matter more than the name of the feature, because the same flaw can hide in many different products and workflows. The Zero-Day and Exploited Vulnerabilities Guide is a useful companion when the issue has already been weaponised and the response needs fast triage.
There is also a governance angle when users or services can be routed to external domains without obvious review. Controls should make it clear which destinations are expected, which are prohibited, and which must be resolved through a safe intermediary rather than fetched directly. That is especially important in products that parse embedded links, fetch remote media, or expand shortened URLs.
Mitigation and verification
Defence starts with strict allowlisting, destination validation, and scheme restrictions, but those controls need to be applied at the point of resolution, not only at input time. Redirect targets, DNS resolution, canonicalisation, and intermediate hops all need to be treated as part of the check.
Where patching or code changes are not immediately possible, reduce the blast radius by blocking outbound access to untrusted destinations, isolating fetchers from sensitive networks, stripping credentials from outbound requests, and disabling unnecessary automatic link following. For applications and services that repeatedly handle URLs, reviewing the destination policy is more useful than relying on manual inspection of a single payload.
The practical test is whether the component can be made to visit a location the designer did not intend. If that answer is yes, the control failure is not only in URL parsing, but in the absence of reliable destination authority.
Detection and post-exploitation review
Detection usually focuses on unusual outbound requests, unexpected redirects, crawler activity to odd domains, or metadata access attempts that follow a URL fetch. If exploitation succeeded, review whether any secrets, session material, API keys, or internal responses were exposed through the unintended request path.
Post-patch review should confirm not just that the vulnerable code was fixed, but that no sensitive data was already retrieved or leaked through the weak path. If the affected service could attach credentials or use authenticated sessions while following links, those materials may need rotation or invalidation after compromise.
For teams that need broader vulnerability context while validating exposure, the CVE Program and the NIST National Vulnerability Database provide the canonical record trail for tracking affected components and linked advisories.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Link-following abuse is often detected through unusual outbound request and redirect logs. |
| Recommendation — Log and review outbound requests and redirect events to spot unexpected destination following. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | This weakness stems from insufficient validation of externally influenced URL destinations. |
| SC-7 — Boundary Protection | Destination control and egress restriction limit abuse of systems that follow attacker-chosen links. | |
| Recommendation — Validate URL destinations and redirect targets before any fetch or follow action occurs. Restrict outbound paths so untrusted destinations cannot be reached from sensitive systems. | ||
| OWASP API Security Top 10 | API7 — Server Side Request Forgery | Link-following flaws can enable SSRF when a service is induced to fetch attacker-chosen URLs. |
| Recommendation — Treat externally supplied URLs as untrusted and block internal or metadata targets. | ||
| OWASP ASVS | V4 — API and Web Service Security | URL handling in services and integrations needs verification against unsafe remote request behaviour. |
| Recommendation — Verify that services only resolve and follow destinations that pass explicit trust checks. | ||
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2026-54420 (LiteSpeed cPanel Plugin UNIX Symbolic Link (Symlink) Following)?
- Is CVE-2025-60710 (Microsoft Windows Link Following) being exploited in the wild?
- How do you patch or mitigate CVE-2025-48384 (Git Link Following)?
- How do you patch or mitigate CVE-2025-21391 (Microsoft Windows Storage Link Following)?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org