← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:193420 · CWE-125 · Disclosed 2022-06-08

Apache 2

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a pinhole leak in a side-door most shops never installed

CVE-2022-28330 is an out-of-bounds read in Apache HTTP Server mod_isapi. The vulnerable set is Apache HTTP Server 2.4.53 and earlier on Windows, and only when the server is configured to process requests with mod_isapi. Apache fixed it in 2.4.54, and the upstream fix touches modules/arch/win32/mod_isapi.c, which matches the very narrow platform/module scope.

The vendor/NVD MEDIUM 5.3 score is technically fair in a vacuum because the bug is remote and unauthenticated, but it overstates operational urgency for most enterprises. This is Windows-only, requires mod_isapi to be enabled and actually used, and the published impact is low confidentiality only—no integrity, no availability, no demonstrated RCE. For a 10,000-host estate, that combination is strong downward pressure.

"Real bug, tiny target set: Windows Apache plus mod_isapi plus exposed ISAPI paths, for a low-impact read-only leak."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find the rare exposed target

The attacker first needs an Apache httpd instance on Windows, not Linux, and it must be old enough to be < 2.4.54. In practice the initial tool is commodity discovery such as nmap, passive banner collection, or internet search engines, but version alone is not enough because the vulnerable code lives in mod_isapi, not generic core httpd.
Conditions required:
  • Apache HTTP Server is deployed on Windows
  • Version is 2.4.53 or earlier
  • The service is reachable over the network
Where this breaks in practice:
  • Most enterprise Apache deployments are Linux, not Windows
  • Banner/version data does not prove mod_isapi is present or reachable
  • Tenable plugin 193420 is version-based and does not prove exploitability
Detection/coverage: Network scanners will find old Windows Apache, but coverage is noisy because they usually do not verify whether mod_isapi is enabled.
STEP 02

Reach an ISAPI-mapped path

Next the attacker must hit a request path that is actually handled by mod_isapi, typically through an AddHandler isapi-handler .dll mapping or related ISAPI configuration. A basic tool like curl is enough for probing, but the request has to traverse application-specific routing into the module.
Conditions required:
  • mod_isapi is loaded
  • An ISAPI handler mapping exists
  • The mapped path is exposed to the attacker
Where this breaks in practice:
  • mod_isapi is Win32-only and uncommon in modern Apache estates
  • Many Windows Apache installs do not expose ISAPI extensions externally
  • WAFs, reverse proxies, or app rewrites may prevent direct handler access
Detection/coverage: Config review is better than remote scanning here. Look for LoadModule isapi_module and AddHandler isapi-handler in httpd.conf and included configs.
STEP 03

Trigger the out-of-bounds read

With a reachable ISAPI path, the attacker sends crafted HTTP requests to exercise the flawed mod_isapi code path. The published impact is a read beyond bounds, which means unintended process memory disclosure is the realistic outcome, not code execution from the advisory alone.
Conditions required:
  • The request reaches the vulnerable mod_isapi code path
  • Crafted input reliably triggers the read condition
Where this breaks in practice:
  • No authoritative public write-up demonstrates reliable high-value exfiltration
  • Read-only memory disclosure often yields limited, inconsistent data
  • Process isolation and short-lived workers reduce the payoff
Detection/coverage: Expect normal web logs to be weak. Look for repeated malformed requests to ISAPI endpoints and memory access faults in Apache/Windows Event logs if exploitation is unstable.
STEP 04

Extract useful data from process memory

The final stage is turning any leaked bytes into something actionable such as credentials, tokens, paths, or application data. This is where many theoretical memory-read bugs die in real environments: the attacker may get fragments, not secrets, and must repeat requests without crashing the app or tripping defenders.
Conditions required:
  • Leaked memory contains useful secrets
  • The attacker can repeat requests and correlate results
Where this breaks in practice:
  • Confidentiality impact is rated low by NVD
  • No integrity or availability impact is described
  • Blast radius is typically limited to the specific Apache worker/process context
Detection/coverage: EDR on the Windows host and crash telemetry are more useful than perimeter IDS. Most vulnerability scanners cannot validate this impact path end-to-end.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found in the sources reviewed. CISA references this CVE in its June 13, 2022 vulnerability bulletin and later as bundled third-party component exposure in a 2025 ICS advisory, but not as a standalone actively exploited issue.
KEV statusNot found in current CISA KEV catalog search; treat as not KEV-listed based on reviewed sources, with medium confidence because CISA search/discovery can lag interface changes.
PoC / exploit codeI found no authoritative public PoC from Apache, NVD, CISA, or Openwall. Tenable marks plugin exploit ease as 'Exploits are available', but I could not validate a trustworthy weaponized repo from primary sources.
EPSSCIRCL/Vulnerability-Lookup shows EPSS 0.00488 with 65.742 percentile on 2026-05-31. That is low absolute exploitation probability and supports de-prioritization absent local exposure.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N = remote and unauthenticated, but confidentiality low only. The vector does not capture the real-world narrowing of Windows + mod_isapi + exposed handler path.
Affected versionsApache HTTP Server 2.4.53 and earlier on Windows, only when configured to process requests with mod_isapi.
Fixed versions / backportsUpstream fix is 2.4.54. Linux distro trackers reviewed are effectively not affected because this is Windows-specific: Ubuntu marks releases Not affected and notes 'This is a windows-specific issue'; Debian notes apache2 <not-affected> (Windows specific).
Exposure realityThis is not 'all Apache'. Apache documentation says mod_isapi is Win32 only, and admins must map ISAPI handlers explicitly. I did not find reliable public Shodan/Censys counts tied specifically to exposed mod_isapi paths, which itself is a signal that the exposed population is niche.
Disclosure / patch dateApache released the fix in 2.4.54 on 2022-06-08. NVD lists 2022-06-09 as the NVD published date.
Researcher / reporterReported by Ronald Crane (Zippenhop LLC), per Apache and Openwall.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.8/10)

The decisive factor is reachability friction: the bug only matters on Windows Apache instances that actively use mod_isapi, which is a small slice of real estates. Even when reachable, the documented impact is low-confidence memory disclosure, not a clean RCE or auth bypass.

HIGH Affected scope is narrow: Windows + `mod_isapi` only
MEDIUM Exploitability remains low in practice due to lack of validated public weaponization
HIGH Business impact is limited to low confidentiality disclosure

Why this verdict

  • Downward adjustment: Windows-only target set — Apache and distro trackers make clear this is not a broad Apache estate problem; Linux fleets are effectively out.
  • Downward adjustment: explicit module dependency — exploitation requires mod_isapi to be enabled and mapped, which implies a legacy/specialized configuration, not default modern Apache usage.
  • Downward adjustment: low blast radius and impact — NVD rates only C:L; there is no published integrity, availability, or code-execution impact to justify medium operational urgency.
  • Downward adjustment: weak exploitation evidence — no KEV listing and no authoritative public PoC located in primary sources.
  • Minor upward floor: remote unauthenticated bug — if you do run internet-facing Windows Apache with exposed ISAPI handlers, the attack does not require credentials or user interaction.

Why not higher?

A higher severity would require either broader exposure or stronger impact. We have neither: the vulnerable population is sharply narrowed by OS and module choice, and the published outcome is low-grade memory disclosure rather than takeover. This is the definition of a CVSS-medium issue that gets smaller when you do the friction audit.

Why not lower?

It is still a real remotely reachable bug on a real, supported release line, and some enterprises do keep legacy Windows/ISAPI stacks around for line-of-business apps. If that niche exists in your environment and is internet-facing, there is non-zero confidentiality risk, so IGNORE is too dismissive as a generic enterprise-wide verdict.

05 · Compensating Control

What to do — in priority order.

  1. Inventory mod_isapi now — Confirm whether the vulnerable code is even in the execution path by checking Windows Apache configs for LoadModule isapi_module and AddHandler isapi-handler. For a LOW verdict there is no SLA; treat this as backlog hygiene and complete it in the next normal config review cycle.
  2. Restrict external access to ISAPI endpoints — If you find live ISAPI handlers, put them behind VPN, IP allowlists, or reverse-proxy access controls where practical. There is no mitigation SLA for LOW, so fold this into the next routine hardening change rather than emergency work.
  3. Disable unused mod_isapi mappings — If the app no longer needs ISAPI, remove the handler mapping and unload the module to eliminate the vulnerable path entirely. Do this during the next planned maintenance event as backlog hygiene.
  4. Watch for scanner false urgency — Because some tooling keys off version strings, annotate findings that are Windows-Apache-only and require mod_isapi. This keeps patch boards from treating all Apache 2.4.53 findings as equally urgent.
What doesn't work
  • A generic Apache version exception without checking mod_isapi — this can hide genuinely exposed Windows legacy apps that do use ISAPI.
  • Linux package backport debates — irrelevant here because the flaw is Windows-specific and Linux distro builds are generally not in scope.
  • Assuming a WAF alone solves it — a WAF may reduce malformed request reachability, but it does not prove the vulnerable code path is unreachable or the module is disabled.
06 · Verification

Crowdsourced verification payload.

Run this on the target Windows host that has Apache installed. Invoke from an elevated or standard PowerShell session with local read access, for example: powershell -ExecutionPolicy Bypass -File .\check-cve-2022-28330.ps1 -ApacheRoot 'C:\Apache24'. It checks the installed httpd version and whether mod_isapi appears enabled in config or loaded modules, then prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# check-cve-2022-28330.ps1

# CVE-2022-28330 verifier for Windows Apache httpd

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN


param(
    [string]$ApacheRoot = "C:\Apache24"
)

function Write-Result {
    param(
        [string]$Status,
        [string]$Message,
        [int]$Code
    )
    Write-Output "$Status - $Message"
    exit $Code
}

function Get-HttpdPath {
    param([string]$Root)

    $candidates = @(
        (Join-Path $Root 'bin\httpd.exe'),
        'C:\Apache24\bin\httpd.exe',
        'C:\Program Files\Apache Group\Apache2\bin\httpd.exe',
        'C:\Program Files\Apache24\bin\httpd.exe'
    )

    foreach ($p in $candidates) {
        if (Test-Path $p) { return $p }
    }

    $cmd = Get-Command httpd.exe -ErrorAction SilentlyContinue
    if ($cmd) { return $cmd.Source }

    return $null
}

function Get-ApacheVersion {
    param([string]$HttpdExe)

    try {
        $out = & $HttpdExe -v 2>$null
        $text = ($out | Out-String)
        if ($text -match 'Apache\/([0-9]+)\.([0-9]+)\.([0-9]+)') {
            return [PSCustomObject]@{
                Raw = $Matches[0]
                Version = [version]("{0}.{1}.{2}" -f $Matches[1], $Matches[2], $Matches[3])
            }
        }
    } catch {}

    return $null
}

function Test-ModIsapiLoaded {
    param([string]$HttpdExe)

    try {
        $mods = & $HttpdExe -M 2>$null
        $modText = ($mods | Out-String)
        if ($modText -match 'isapi_module') { return $true }
    } catch {}

    return $false
}

function Get-ConfigFiles {
    param([string]$Root)

    $files = @()
    $confRoot = Join-Path $Root 'conf'
    if (Test-Path $confRoot) {
        $files += Get-ChildItem -Path $confRoot -Recurse -File -Include *.conf -ErrorAction SilentlyContinue
    }
    return $files | Select-Object -ExpandProperty FullName -Unique
}

function Test-ModIsapiConfigured {
    param([string[]]$ConfigFiles)

    $loadFound = $false
    $handlerFound = $false

    foreach ($file in $ConfigFiles) {
        try {
            $content = Get-Content -Path $file -Raw -ErrorAction Stop
            if ($content -match '(?im)^\s*LoadModule\s+isapi_module\b') { $loadFound = $true }
            if ($content -match '(?im)^\s*AddHandler\s+isapi-handler\b') { $handlerFound = $true }
        } catch {
            continue
        }
    }

    return [PSCustomObject]@{
        LoadModule = $loadFound
        AddHandler = $handlerFound
        Effective = ($loadFound -or $handlerFound)
    }
}

$httpd = Get-HttpdPath -Root $ApacheRoot
if (-not $httpd) {
    Write-Result -Status 'UNKNOWN' -Message 'httpd.exe not found; supply -ApacheRoot' -Code 2
}

$versionInfo = Get-ApacheVersion -HttpdExe $httpd
if (-not $versionInfo) {
    Write-Result -Status 'UNKNOWN' -Message "Could not determine Apache version from $httpd" -Code 2
}

$fixedVersion = [version]'2.4.54'
$configFiles = Get-ConfigFiles -Root (Split-Path (Split-Path $httpd -Parent) -Parent)
$configCheck = Test-ModIsapiConfigured -ConfigFiles $configFiles
$moduleLoaded = Test-ModIsapiLoaded -HttpdExe $httpd
$modIsapiEffective = ($moduleLoaded -or $configCheck.Effective)

if ($versionInfo.Version -ge $fixedVersion) {
    Write-Result -Status 'PATCHED' -Message ("Apache version {0} is >= 2.4.54" -f $versionInfo.Version) -Code 0
}

if ($versionInfo.Version -lt $fixedVersion -and $modIsapiEffective) {
    $details = @()
    if ($moduleLoaded) { $details += 'module loaded' }
    if ($configCheck.LoadModule) { $details += 'LoadModule present' }
    if ($configCheck.AddHandler) { $details += 'ISAPI handler mapping present' }
    Write-Result -Status 'VULNERABLE' -Message ("Apache version {0} with mod_isapi indicators: {1}" -f $versionInfo.Version, ($details -join ', ')) -Code 1
}

Write-Result -Status 'PATCHED' -Message ("Apache version {0} is old, but no mod_isapi evidence found; vulnerable code likely not in execution path" -f $versionInfo.Version) -Code 0
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not burn an emergency window on every Apache finding tied to this CVE. First, identify the small set of Windows Apache systems that actually load or map mod_isapi; if none do, close or exception the finding with evidence. For the hosts that do, there is noisgate mitigation SLA: no SLA (treat as backlog hygiene) and noisgate remediation SLA: treat as backlog hygiene for this LOW verdict—fold verification and cleanup into the next planned maintenance cycle, and upgrade those systems to 2.4.54+ or retire the ISAPI path in normal change control.

Sources

  1. Apache HTTP Server 2.4 vulnerabilities
  2. NVD CVE-2022-28330
  3. MITRE CVE record
  4. Openwall oss-security post
  5. Apache mod_isapi documentation
  6. Ubuntu CVE tracker
  7. Debian security tracker
  8. Apache fix commit 801e414
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.