CVE-2025-59775: Apache HTTP Server SSRF Vulnerability

CVE-2025-59775 Overview

A Server-Side Request Forgery (SSRF) vulnerability has been identified in Apache HTTP Server on Windows systems. When configured with AllowEncodedSlashes On and MergeSlashes Off, the vulnerability allows attackers to potentially leak NTLM hashes to a malicious server via crafted SSRF requests or malicious content. This vulnerability affects Apache HTTP Server installations on Windows platforms and can be exploited remotely without authentication.

Critical Impact

This SSRF vulnerability enables attackers to exfiltrate NTLM authentication hashes from Windows systems running vulnerable Apache HTTP Server configurations, potentially leading to credential theft and lateral movement within enterprise networks.

Affected Products

• Apache HTTP Server on Windows (versions prior to 2.4.66)
• Systems configured with AllowEncodedSlashes On
• Systems configured with MergeSlashes Off

Discovery Timeline

• 2025-12-05 - CVE-2025-59775 published to NVD
• 2025-12-10 - Last updated in NVD database

Technical Details for CVE-2025-59775

Vulnerability Analysis

This SSRF vulnerability in Apache HTTP Server arises from improper handling of encoded slashes when specific configuration directives are enabled. When AllowEncodedSlashes On permits URL-encoded slashes in request URIs and MergeSlashes Off prevents the normalization of consecutive slashes, attackers can craft malicious requests that bypass normal URL validation and trigger server-side requests to attacker-controlled endpoints.

The vulnerability is particularly dangerous on Windows systems because it can be leveraged to force the Apache server to initiate outbound connections using Windows authentication mechanisms. When the server connects to a malicious SMB or HTTP server, it may automatically send NTLM authentication credentials as part of the Windows Integrated Authentication process.

Root Cause

The root cause of this vulnerability is classified under CWE-918 (Server-Side Request Forgery). The issue stems from insufficient validation of user-controlled input when the server processes URLs with encoded slashes in specific configurations. The combination of AllowEncodedSlashes On and MergeSlashes Off creates a condition where URL path normalization is bypassed, allowing attackers to construct request paths that redirect server-side operations to arbitrary destinations.

Attack Vector

The attack vector for this vulnerability is network-based, requiring no authentication or user interaction. An attacker can exploit this vulnerability by sending specially crafted HTTP requests to the vulnerable Apache HTTP Server. The malicious request contains encoded slashes that, when processed by the server with the vulnerable configuration, cause the server to make outbound requests to attacker-controlled infrastructure.

On Windows systems, when the server initiates a connection to a malicious endpoint (such as a rogue SMB server or WebDAV server), the Windows authentication subsystem may automatically attempt NTLM authentication, transmitting the server's NTLM hash to the attacker. These captured hashes can then be used in relay attacks or cracked offline to reveal plaintext credentials.

Technical details regarding specific exploitation techniques can be found in the Openwall OSS Security List Post and the Apache HTTP Server Vulnerabilities advisory.

Detection Methods for CVE-2025-59775

Indicators of Compromise

• Unusual outbound SMB (port 445) or WebDAV connections originating from the Apache HTTP Server process
• HTTP requests containing encoded slashes (%2F) in URI paths targeting internal or external resources
• Unexpected NTLM authentication attempts from the web server to external IP addresses
• Log entries showing requests with abnormally structured paths containing consecutive encoded characters

Detection Strategies

• Monitor Apache access logs for requests containing %2F or %5C encoded characters in suspicious patterns
• Implement network monitoring to detect outbound SMB/CIFS traffic from web server systems
• Deploy intrusion detection signatures that flag SSRF patterns in HTTP request URIs
• Audit Apache configuration files for instances of AllowEncodedSlashes On combined with MergeSlashes Off

Monitoring Recommendations

• Configure SIEM alerts for outbound connections from web servers to non-whitelisted destinations on ports 445, 139, or 80/443 to unknown hosts
• Enable detailed Apache access logging with URI decoding to capture potentially malicious request patterns
• Implement egress filtering and monitor for NTLM authentication traffic leaving the DMZ
• Regularly review Apache configuration changes through file integrity monitoring

How to Mitigate CVE-2025-59775

Immediate Actions Required

• Upgrade Apache HTTP Server to version 2.4.66 or later immediately
• Review Apache configurations for instances of AllowEncodedSlashes On and MergeSlashes Off and evaluate necessity
• Implement network egress filtering to block outbound SMB traffic from web servers
• Consider disabling NTLM authentication on Windows systems running Apache HTTP Server where not required

Patch Information

Apache has addressed this vulnerability in version 2.4.66. Users are strongly recommended to upgrade to this version or later to remediate the SSRF vulnerability. The official security advisory and patch details are available at the Apache HTTP Server Vulnerabilities page.

Workarounds

• Set AllowEncodedSlashes Off in Apache configuration if encoded slashes in URLs are not required for your application
• Set MergeSlashes On to enable slash normalization and prevent URL manipulation
• Implement a Web Application Firewall (WAF) rule to block requests containing suspicious encoded slash patterns
• Configure Windows Firewall to block outbound SMB connections (port 445) from the Apache server process

# Configuration example - Apache httpd.conf mitigation
# Add or modify these directives to reduce SSRF attack surface

# Disable encoded slashes if not required
AllowEncodedSlashes Off

# Enable slash merging to normalize paths
MergeSlashes On

# Alternatively, if you must allow encoded slashes, ensure strict request filtering
# is implemented at the WAF/proxy layer