Apache HTTP Server has a Windows-only Server-Side Request Forgery (SSRF) flaw that can be forced to make the server connect to attacker-controlled UNC (SMB) targets and thereby
leak NTLM authentication material — a vulnerability tracked as CVE-2025-59775 and fixed in Apache httpd 2.4.66.
Background
Apache’s security team published a patch release (2.4.66) that includes a number of fixes; among them is a
moderate-rated SSRF that can lead to
NTLM leakage when a Windows-hosted Apache instance is configured with specific settings. The bug is triggered when
AllowEncodedSlashes is set to
On and
MergeSlashes is set to
Off, allowing crafted requests or content to be interpreted by the server as UNC paths and causing the underlying Windows OS to attempt an SMB connection and NTLM authentication to a remote target. The Apache advisory explicitly recommends upgrading to 2.4.66 to remediate the issue. This report was credited to security researcher Orange Tsai (DEVCORE) and was reported to the project in September 2025; Apache applied a fix in the 2.4.x tree and shipped it with the 2.4.66 release.
Overview: What the vulnerability actually does
The precise trigger conditions
- The server must be running Apache HTTP Server on Windows. The issue is specifically a Windows-side behavior because the attack relies on UNC/SMB handling by the operating system.
- AllowEncodedSlashes On — this option allows encoded path separators (for example, %5C for backslash or %2F for forward slash) to be accepted and decoded in the server’s path handling. When enabled, encoded separators are decoded and can change the ultimate path the server acts on.
- MergeSlashes Off — when disabled, Apache does not collapse multiple consecutive slashes in the URL path. With merging disabled, crafted sequences can preserve multiple separators that are meaningful to downstream processing or to string-based rewrite/expressions.
When these two settings are present together and unvalidated input is passed into a feature that causes the server to resolve or fetch a path (for example, through rewrite rules, proxied requests, or expressions), an attacker can cause the server process to resolve a path that decodes into a Windows UNC path such as \attacker.example\share. The operating system (or an associated component) will then attempt to open that network resource, which triggers an SMB session and NTLM authentication handshake — and that handshake exposes an NTLM challenge/response that a hostile SMB endpoint can collect.
Why UNC leads to credential leakage
Accessing a UNC path instructs Windows to initiate an SMB session to the remote host. SMB commonly negotiates NTLM authentication as part of session setup if Kerberos is not available or negotiation falls back to NTLM. During that handshake the client will send NTLM challenge/response tokens (NTLMv2 responses) which, while not plaintext passwords, are sufficient for offline cracking, relay using other tools, or pass-the-hash/relay-style attacks depending on the environment and protections in place. Microsoft’s SMB/NTLM protocol documentation explains how NTLM messages are embedded in SMB exchanges and how a client can fall back to NTLM negotiation; modern Windows features (SMB signing, NTLM blocking) are designed to mitigate these risks but are not universally configured by default across all environments.
How serious is this? Impact and attack scenarios
Practical impact
- Credential exposure: The immediate effect is that NTLM authentication material — the NTLMv2 challenge/response — may be transmitted to an attacker-controlled SMB server. That material can be harvested and used for offline brute-force, or for relay/pass-the-hash style attacks if other environmental conditions allow.
- Lateral movement: Harvested NTLM responses may permit attackers to impersonate the user or escalate further inside a Windows domain if complementary weaknesses exist. This is a common step in multi-stage intrusions that target Windows environments.
- Remote, unauthenticated initiation: The vulnerability does not require the attacker to have local access; the attacker needs to deliver a specially crafted HTTP request or content that the vulnerable Apache server interprets in the affected path-processing components. Depending on site configuration, these requests can be sent over the Internet.
Conditions that limit exploitation
- Requires a specific configuration: Both AllowEncodedSlashes = On and MergeSlashes = Off must be in effect. These are not default settings: AllowEncodedSlashes is Off by default and MergeSlashes defaults to On, so only servers where an administrator intentionally enabled the former (or disabled the latter) are at risk. This raises the attack complexity relative to a fully default deployment.
- Windows-only: Non-Windows Apache deployments are unaffected because the attack relies on Windows UNC/SMB semantics. That reduces the global blast radius but raises concern for internet-facing Windows hosts or internal servers that proxy requests and run on Windows.
- Network controls and endpoint hardening may block exploitation: If outbound SMB (TCP port 445/139) is blocked by firewall rules, or if NTLM blocking or SMB signing is enforced on the host, the attacker’s ability to harvest useful material is reduced or prevented. Microsoft has added features to block NTLM over SMB and to require SMB signing in modern Windows versions; administrators can use these features to mitigate the impact.
Exploitability and real-world evidence
At time of disclosure there are
no public reports of widespread active exploitation of CVE-2025-59775. Vendor advisories and public trackers recommend patching but do not report in-the-wild exploitation data for this specific CVE. That said, the general technique — coaxing Windows to authenticate to attacker-controlled SMB endpoints via UNC paths — is well-known and has been abused in multiple prior campaigns and CVEs; therefore the lack of immediate public exploitation does not mean the risk is theoretical.
Technical analysis: why these Apache settings matter
AllowEncodedSlashes
- When AllowEncodedSlashes On is set, Apache accepts URL-encoded path separators (including encoded backslashes on systems that recognize them) and decodes them. That gives an attacker the ability to encode “\” characters inside a request path using %5C or similar encodings and have Apache turn them into literal backslashes during path resolution — which is precisely what is needed to craft a UNC path from a URL. The directive exists primarily to support apps that legitimately need encoded slashes in path-info, but decoding slashes has known security implications and is therefore disabled by default.
MergeSlashes
- MergeSlashes Off prevents Apache from collapsing multiple consecutive slashes. That behavior can be relied on by configuration patterns or legacy applications; however, leaving MergeSlashes disabled allows crafted sequences like “/%5C%5Cattacker%5Cshare” to persist through path normalization and to be interpreted downstream as a UNC path. Apache’s MergeSlashes default is On precisely to avoid ambiguous path semantics and to reduce these sorts of attack surface permutations.
Combining the two: how SSRF becomes UNC SSRF
Many Apache modules and expressions accept server-side variables and may, in some configurations, assemble or pass user-supplied path segments into local file access or URL fetch operations. If a downstream action uses the decoded path as a target and that target is a UNC path, the Windows OS will attempt SMB. In other words, server-side request forgery occurs because the server is induced to make an outbound network request (or file access) to an attacker-controlled host; on Windows the outbound network protocol used for UNC is SMB, which carries NTLM authentication. The chaining of decoded slashes plus preserved multiple separators makes such UNC targets possible from within a URL context.
Recommendations: patching, configuration, hardening and detection
The single most important immediate action for affected operators is straightforward:
- Upgrade Apache httpd to 2.4.66 (or later) — the vendor fix for this issue is included in that release.
Beyond the patch, apply layered mitigations and detection controls:
- Configuration lockdown
- If your application does not require it, set AllowEncodedSlashes Off (the default) and set MergeSlashes On (the default). If either is intentionally changed for application compatibility, treat the configuration as high-risk and isolate the service.
- Review any use of mod_rewrite, proxying, or Apache expressions that accept user data into file or URL targets. Sanitize inputs and avoid passing user-supplied path fragments into functions that perform outbound network calls.
- Network controls
- Block outbound SMB (TCP 445 and 139) from web servers to untrusted networks. A properly configured egress firewall that prevents servers from initiating SMB sessions to the Internet or to untrusted subnets will blunt this class of attack.
- Where possible, maintain allowlists for SMB destinations; web servers rarely need to connect to arbitrary SMB endpoints.
- Windows-specific hardening
- Use SMB NTLM blocking features or group policy controls to prevent clients from offering NTLM to arbitrary SMB servers. Newer Windows versions include explicit controls to block NTLM over SMB for outbound connections — administrators should evaluate these settings and apply exceptions only where needed.
- Enforce SMB signing and SMB encryption where possible so that even if a connection is established, attacks like relays or tampering are more difficult.
- Evaluate disabling NTLM entirely in environments that can migrate to Kerberos-only authentication; where NTLM is required, implement monitoring and strict allowlists.
- Application-layer mitigations
- Consider adding mod_security rules or a web application firewall (WAF) that detects and blocks requests containing encoded backslashes (%5C) or suspicious sequences when passed into sensitive flows.
- Audit and restrict the use of Apache features that pass request-derived values into filesystem access or proxy backends.
- Detection and response
- Monitor web server logs for requests with %5C,
%2F sequences, unusual repeated slashes, or patterns that previously triggered path normalization. Correlate those with any unexpected outbound SMB connections from the host.
- Monitor network telemetry for outbound SMB session attempts from web servers to unusual destinations; investigate any SMB session initiation that terminates on non-approved external IPs. Look especially for session setup/NTLM challenge/response patterns and repeated failed authentication attempts.
- If suspicious activity is detected, capture PCAPs and relevant logs to determine whether NTLM tokens were emitted and to which host; treat exposed NTLM responses as high-priority credential compromise indicators.
Detection playbook (quick steps for incident teams)
- Search web server logs for requests containing encoded backslashes (%5C) or long sequences that decode into UNC-like patterns.
- Search network logs / firewall logs for outbound TCP 445/139 flows originating from the web server. Note destination IPs and timestamps.
- If SMB outbound sessions are found, pull flow data and, if available, packet captures to verify whether an NTLM challenge/response occurred.
- Rotate affected passwords/keys and treat recovered NTLM tokens as potentially compromised — assume the attacker may be able to perform offline cracking or relay under some conditions.
- Patch Apache to 2.4.66 and harden the Windows host (NTLM blocking, SMB signing, egress blocking) before reinstating services.
Why this class of vulnerability keeps recurring
SSRF is a long-standing web-server problem: many applications inadvertently accept or reflect attacker-controlled URLs or path fragments into server-side fetch logic. What makes the
UNC SSRF subclass particularly dangerous in Windows environments is that the attacker need not directly capture credentials from a web form — simply provoking the OS to attempt an SMB connection can cause the client to present NTLM artifacts to a hostile SMB listener. Prior incidents and campaigns have abused this behavior by distributing content that triggers Windows to connect to attacker-controlled SMB endpoints, harvesting NTLMv2 tokens for later abuse. Microsoft and platform maintainers have continued to add mitigations (SMB signing, NTLM blocking), but the legacy compatibility of Windows and the flexibility of server configurations keep the attack surface present. Apache’s project has previously flagged SSRF via UNC paths as a nuanced category and has signalled that it will treat such reports with care; this vulnerability sits in that historical context. The Apache advisory notes that the server “offers limited protection against administrators directing the server to open UNC paths” — in other words, some of the risk stems from configuration choices made by site operators.
Critical analysis: strengths and residual risks
Strengths of the response
- Prompt vendor fix: Apache incorporated the fix into the 2.4.66 release and published the advisory with actionable configuration context. Operators can remediate by upgrading to a specific version.
- Clear configuration guidance: The advisory specifies the configuration elements involved (AllowEncodedSlashes, MergeSlashes), which allows administrators to quickly audit and, where feasible, revert risky configuration choices.
- Ecosystem awareness: Distribution maintainers (Debian, SUSE, Amazon trackers) and security lists have picked up the advisory and are coordinating backports and packages; this helps reduce friction for administrators in applying updates.
Residual and systemic risks
- Configuration-driven exposure: Because the vulnerability depends on non-default settings, it will affect organizations who changed settings for legitimate reasons; these shops may be slow to patch because the setting is needed for application compatibility. That creates a durable, non-trivial risk for some deployments.
- Windows-specific chainability: Even after patching Apache, environments with other vector paths (e.g., application code that constructs UNC targets, or proxy stacks) may remain vulnerable if similar path-decoding problems exist elsewhere. Comprehensive mitigation requires both application and platform hardening.
- Credential reuse & relay threats: Harvested NTLM tokens are a long-lived risk in many estates because NTLM-style authentication continues to be used for legacy services. Organizations with partial migration to Kerberos may still have endpoints that accept NTLM, enabling further misuse of harvested tokens.
- Detection limitations: Without egress monitoring, outbound SMB flows may go unnoticed, and incident detection relies on good logging and a security-aware operations team. Web hosts often have minimal egress filtering by default in cloud environments, increasing exposure.
Conclusion
CVE-2025-59775 is a practical reminder that feature flags and historical compatibility options in web servers can create surprising cross-layer risks when combined with platform-specific behaviors. The bug’s core is not a cryptographic failure but a
path normalization and SSRF chaining that leverages Windows UNC semantics to extract NTLM artifacts. Administrators of Windows-hosted Apache instances should treat the advisory as high priority for affected systems: upgrade to
httpd 2.4.66, audit
AllowEncodedSlashes and
MergeSlashes, block unnecessary outbound SMB, and harden Windows SMB/NTLM behavior using NTLM blocking and SMB signing — a layered approach that significantly reduces the real-world risk this vulnerability represents.
Source: MSRC
Security Update Guide - Microsoft Security Response Center