This is a web server tricked into reaching out over SMB and handing an attacker a reusable office badge
The Tenable finding maps to CVE-2024-40898: an SSRF issue in Apache HTTP Server on Windows when mod_rewrite is used in server or vhost context and request-controlled input is fed into rewrite logic. Apache says the vulnerable range is 2.4.0 through 2.4.61 on Windows, fixed in 2.4.62 on 2024-07-17. Successful exploitation can make the server initiate a connection to an attacker-controlled host and leak NTLM credentials/hashes.
The scanner's HIGH label is technically defensible from a pure CVSS lens, but it overshoots real enterprise urgency. This is not generic pre-auth Apache RCE: it is Windows-only, depends on specific unsafe rewrite behavior, and usually needs outbound SMB/UNC reachability plus usable NTLM/relay conditions before the hash leak becomes meaningful business impact.
4 steps from start to impact.
Find a Windows Apache host with unsafe mod_rewrite
mod_rewrite in server/vhost context in a way that passes attacker-controlled request data into a path or target the server will resolve. Version alone is not enough; the dangerous configuration has to exist.- Target is running Apache HTTP Server on Windows
- Version is 2.4.0 through 2.4.61
mod_rewriteis enabled and used in server/vhost context- Rewrite rules or expressions consume unvalidated request input
- Apache on Windows is a much smaller population than Apache on Linux
- Many Windows Apache deployments do not use risky server/vhost rewrite rules
- Version scanners cannot prove the dangerous rewrite pattern is present
Trigger outbound SSRF to attacker infrastructure
curl, Burp Repeater, or a custom Python request is enough if the rewrite rule is unsafe.- Attacker can send HTTP requests to the site
- Rewrite logic transforms request input into a network path or equivalent outbound lookup
- Host can make outbound connections to attacker-controlled infrastructure
- Outbound egress filtering often blocks TCP/445 from web servers
- Some environments restrict UNC/SMB resolution from server workloads
- WAFs may not stop server-side path resolution, but secure rewrite design does
Capture NTLM material with Responder or Inveigh
Responder or Inveigh can capture the NTLM authentication attempt. At this point the attacker has credential material, not code execution on the web server. The value depends on what account the Apache service runs under and whether NTLM is still broadly accepted in the estate.- Outbound authentication reaches attacker-controlled listener
- NTLM is enabled and usable from the web server account context
- Local service accounts often have limited blast radius
- Managed service accounts or hardened identities reduce reuse value
- Some enterprises have aggressively reduced NTLM usage
Relay or crack the credential material with ntlmrelayx
Impacket ntlmrelayx or offline cracking plus a reachable target that still accepts the presented NTLM auth. This is where many real deployments break the chain: SMB signing, LDAP signing/channel binding, blocked east-west paths, and weak service account privileges all sharply limit payoff. The highest-risk outcome is not Apache compromise itself; it is credential abuse elsewhere.- A relayable or crackable NTLM capture is obtained
- Reachable internal service accepts that credential or relay
- Target protections like SMB signing / LDAP protections are absent or incomplete
- Modern relay protections frequently kill the chain
- Captured account may not have meaningful lateral movement rights
- This step usually requires deeper network positioning than the initial web request
The supporting signals.
| In-the-wild status | No solid active exploitation evidence found. Censys said on 2024-07-23 there was *no known active exploitation* for this issue pair, and the CVE is not present in the current CISA KEV catalog page reviewed. |
|---|---|
| PoC availability | Public code exists, but quality is mixed. Tenable flags Exploit Available: true, and Censys links a public GitHub repo. That repo appears to be more of a scanner/demo than a trustworthy, production-grade exploit. |
| EPSS | Low signal. FIRST provides the authoritative EPSS API, but the exact current value should be fetched at triage time. Third-party mirrors have shown this CVE in a low EPSS band rather than a hot exploitation band. |
| KEV status | Not KEV-listed based on the CISA catalog page reviewed. No federal due date pressure. |
| CVSS vs reality | NVD: 7.5 HIGH (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). CISA-ADP: 9.1 CRITICAL adds integrity impact, likely assuming downstream credential abuse. In practice, the immediate bug is a hash leak path, not direct server takeover. |
| Affected versions | Apache HTTP Server on Windows 2.4.0 through 2.4.61 per Apache's advisory. Tenable plugin 210450 keys on prior to 2.4.62. |
| Fixed version | 2.4.62 released by Apache on 2024-07-17. The fix was committed on 2024-07-15 according to Apache's advisory timeline. |
| Exposure population | Internet-visible Apache is huge; Internet-visible Windows Apache with unsafe server/vhost rewrites is not. Censys published queries for public-facing Apache 2.4.0-2.4.61, but those queries overcount because they do not distinguish Windows or vulnerable rewrite behavior. |
| Detection coverage | Moderate asset coverage, weak exploitability coverage. Nessus finds likely candidates by version on Windows, but it does not verify mod_rewrite misuse, UNC resolution, or outbound SMB reachability. |
| Disclosure / reporters | Reported: 2024-07-12. Patch released: 2024-07-17. NVD published: 2024-07-18. Reported by: Smi1e and xiaojunjie of DBAPPSecurity Ltd. |
noisgate verdict.
The decisive factor is that this is Windows-only and configuration-dependent: the attacker needs a vulnerable Apache-on-Windows deployment with unsafe server/vhost rewrite behavior before anything interesting happens. Even then, the bug usually yields credential material leakage, and turning that into business impact depends on outbound SMB/UNC reachability and weak NTLM/relay defenses elsewhere.
Why this verdict
- Windows-only cut: start from the vendor HIGH, then push down because this is not the mainstream Apache/Linux exposure set; it only matters on Windows deployments.
- Unsafe rewrite prerequisite: the attacker needs
mod_rewritein server/vhost context to consume untrusted input in a dangerous way. That is a real configuration dependency, not a universal property of all vulnerable versions. - Hash leak, not box-owning: the immediate impact is NTLM leakage. That can become serious, but only if outbound connectivity and downstream relay/reuse conditions line up.
Why not higher?
There is no strong evidence of active exploitation, no KEV listing, and no direct pre-auth RCE on the web server itself. The chain depends on a narrower deployment subset and then depends again on egress and identity weaknesses to turn disclosure into broader compromise.
Why not lower?
This is still unauthenticated and remote against an Internet-facing service, so it is not backlog fluff. If you do run Apache on Windows with permissive rewrites and weak outbound controls, a simple request can hand an attacker credential material from the web tier.
What to do — in priority order.
- Block outbound SMB from web tiers — Deny TCP/445 and related outbound file-service paths from Apache hosts to the Internet and unneeded internal segments. This directly cuts the NTLM leak/relay chain; for a MEDIUM verdict there is no noisgate mitigation SLA, but this is the highest-value control to apply during normal change windows while you patch.
- Audit and constrain
mod_rewrite— Review server/vhost rewrite rules for any use of request-derived values that can become filesystem or network paths. Replace unsafe patterns with explicit allowlists and literal destinations; again, no mitigation SLA applies for MEDIUM, so do this as part of standard web config review. - Reduce NTLM blast radius — Where feasible, disable NTLM, prefer Kerberos, enforce SMB signing, and harden LDAP relay protections on systems reachable from web servers. This does not remove the bug, but it strips most of the downstream payoff if a hash is captured.
- Watch for outbound auth from Apache hosts — Alert on web servers initiating SMB, WebDAV, or unusual DNS/auth traffic to untrusted destinations. That gives you compensating visibility while you move the host to 2.4.62+ inside the remediation window.
WAF-only thinkingdoesn't solve the core problem; the dangerous behavior is the server's own outbound resolution after rewrite logic runs.Hiding the Apache bannerdoesn't matter; exploitation depends on configuration and behavior, not just version disclosure.MFA on user accountsis largely irrelevant to the initial leak path; the exposed material is server-originated NTLM authentication.
Crowdsourced verification payload.
Run this on the target Windows host or through your remote execution platform. Invoke with powershell -ExecutionPolicy Bypass -File .\check-apache-cve-2024-40898.ps1 as a standard user; local admin is helpful for service enumeration but not strictly required.
# check-apache-cve-2024-40898.ps1
# Detect whether a Windows host appears vulnerable to CVE-2024-40898 based on installed Apache httpd version.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0 = VULNERABLE, 1 = PATCHED, 2 = UNKNOWN
$ErrorActionPreference = 'SilentlyContinue'
function Get-ApacheCandidates {
$paths = New-Object System.Collections.Generic.List[string]
# Common install paths
@(
'C:\Apache24\bin\httpd.exe',
'C:\Program Files\Apache Group\Apache2\bin\httpd.exe',
'C:\Program Files\Apache24\bin\httpd.exe',
'C:\Program Files (x86)\Apache Group\Apache2\bin\httpd.exe',
'C:\Program Files (x86)\Apache24\bin\httpd.exe'
) | ForEach-Object {
if (Test-Path $_) { [void]$paths.Add($_) }
}
# Service image paths
try {
$services = Get-CimInstance Win32_Service | Where-Object {
$_.PathName -match 'httpd\.exe' -or $_.Name -match 'Apache' -or $_.DisplayName -match 'Apache'
}
foreach ($svc in $services) {
$raw = $svc.PathName
if (-not $raw) { continue }
# Extract the executable path, handling quoted and unquoted ImagePath values
$candidate = $null
if ($raw -match '^"([^"]*httpd\.exe)"') {
$candidate = $matches[1]
} elseif ($raw -match '^([^ ]*httpd\.exe)') {
$candidate = $matches[1]
}
if ($candidate -and (Test-Path $candidate)) {
[void]$paths.Add($candidate)
}
}
} catch {}
return $paths | Sort-Object -Unique
}
function Get-ApacheVersion([string]$exe) {
try {
$output = & $exe -v 2>$null
if ($LASTEXITCODE -ne 0 -or -not $output) { return $null }
$text = ($output | Out-String)
if ($text -match 'Apache\/([0-9]+\.[0-9]+\.[0-9]+)') {
return [version]$matches[1]
}
} catch {}
return $null
}
$candidates = Get-ApacheCandidates
if (-not $candidates -or $candidates.Count -eq 0) {
Write-Output 'UNKNOWN: Apache httpd.exe not found in common paths or service configuration.'
exit 2
}
$vulnMin = [version]'2.4.0'
$vulnFixed = [version]'2.4.62'
$found = $false
$patchedSeen = $false
foreach ($exe in $candidates) {
$ver = Get-ApacheVersion -exe $exe
if (-not $ver) { continue }
$found = $true
if ($ver -ge $vulnMin -and $ver -lt $vulnFixed) {
Write-Output ("VULNERABLE: {0} reports Apache {1}, which is below 2.4.62 on Windows." -f $exe, $ver)
exit 0
}
if ($ver -ge $vulnFixed) {
$patchedSeen = $true
}
}
if ($patchedSeen) {
Write-Output 'PATCHED: Detected Apache httpd version is 2.4.62 or later.'
exit 1
}
if ($found) {
Write-Output 'UNKNOWN: Apache was found, but the version could not be evaluated cleanly.'
exit 2
}
Write-Output 'UNKNOWN: No usable Apache version information was obtained.'
exit 2If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.