← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2022-37436 · CWE-113 · Disclosed 2023-01-17

Prior to Apache HTTP Server 2

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

This is like a bad package label inside your own warehouse, not a burglar picking the front-door lock

CVE-2022-37436 lives in Apache HTTP Server mod_proxy before 2.4.55. A backend server behind Apache can send malformed response headers so Apache truncates headers early and shoves later headers into the response body instead. The practical result is that browser-enforced headers such as Set-Cookie, HSTS, X-Frame-Options, or CSP may be dropped on the floor if they appear after the bad header.

The vendor's MEDIUM is fair in lab conditions but still a little generous for enterprise prioritization. The decisive friction is attacker position: the adversary needs control of, or a malicious foothold in, the proxied backend that Apache already trusts. That makes this primarily a *post-compromise / untrusted-backend* integrity bug with narrow blast radius, not a clean unauthenticated remote path into the proxy tier.

"This is a reverse-proxy trust-boundary bug, not an internet-facing initial-access bug."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land on or control a proxied backend

The attacker first needs a backend application or service that sits behind Apache mod_proxy and can emit arbitrary HTTP response headers. In practice this means a compromised app server, a malicious tenant backend, or a deliberately crafted test service using a simple tool like socat/netcat or a custom Python HTTP responder. The Apache advisory explicitly frames the threat actor as a malicious backend.
Conditions required:
  • Apache HTTP Server before 2.4.55
  • mod_proxy in use for reverse proxying
  • Attacker can control backend response headers
Where this breaks in practice:
  • This is not reachable from the open internet unless the attacker already owns or can impersonate the origin server behind Apache
  • Most enterprise reverse proxies front first-party applications operated by the same team, not hostile multi-tenant origins
Detection/coverage: External scanners usually miss this because they cannot prove backend control. Config scanners can flag vulnerable Apache versions, but they often over-report if mod_proxy is installed but not actually brokering untrusted backends.
STEP 02

Send a malformed header through the proxy

Using a custom backend responder or raw socket tooling, the attacker returns a header sequence that causes Apache's proxy header parser to stop early. The fix commit (8b6d55f) changed this behavior so bad backend headers now fail closed instead of continuing with truncated parsing. Before the fix, the proxy could continue forwarding a damaged response structure downstream.
Conditions required:
  • Backend can emit malformed or oversized header material
  • Apache forwards that backend response via affected mod_proxy code path
Where this breaks in practice:
  • The attacker needs precise control over header ordering and malformed content
  • Impact depends on useful security headers appearing *after* the truncation point
Detection/coverage: Reverse-proxy logs may show backend header parsing warnings or upstream read errors after the fix path was introduced. Pre-fix, evidence is weaker and often buried in application/debug logs.
STEP 03

Strip security semantics from the client response

Once parsing truncates, later headers are treated as body bytes instead of headers. That can neutralize browser protections or cookie directives for that response, creating an integrity failure in the security envelope delivered to the client. The client still gets a response, just not the security-relevant headers the origin or proxy intended.
Conditions required:
  • Security-relevant headers appear after the malformed one
  • Client behavior depends on those headers being honored
Where this breaks in practice:
  • No direct server-side code execution or proxy takeover follows from this flaw alone
  • The attacker still needs a second-stage web attack or a security control bypass that benefits from missing headers
Detection/coverage: HTTP security header monitoring, synthetic browser tests, or response-diff checks can catch missing CSP/HSTS/XFO/Set-Cookie attributes. Commodity vuln scanners generally do not validate this response-manipulation outcome.
STEP 04

Exploit the downgraded browser-side posture

With headers suppressed, an attacker may make follow-on attacks easier: weaker framing protection, weaker cookie handling, or weaker content restrictions. But the bug is only an enabler; it does not itself provide auth bypass, data theft, or code execution. Real damage depends on what the application and browser would have prevented with those missing headers.
Conditions required:
  • A meaningful downstream web attack exists
  • Users hit the affected proxied path
Where this breaks in practice:
  • Requires chaining with a separate browser- or app-layer weakness
  • Blast radius is limited to responses served by the specific affected backend path
Detection/coverage: Look for sudden absence of expected security headers on proxied routes and correlate with anomalous backend changes or compromise indicators.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence of active exploitation found in the source set, and not present in CISA KEV.
KEV statusNot listed in the CISA Known Exploited Vulnerabilities Catalog as of the current catalog page.
EPSS0.00539 from the user-supplied intel block; that is a low-likelihood signal and consistent with the lack of public exploitation evidence reviewed here.
PoC availabilityNo canonical vendor PoC. A working proof is trivial with a custom backend that emits malformed headers; secondary tracking at cvefeed.io reports public GitHub PoCs, but nothing in the reviewed primary sources suggests mature offensive tooling or campaign use.
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N assumes network reachability with no privileges, but the missing real-world qualifier is attacker control of the backend. That prerequisite is substantial downward pressure on operational severity.
Affected versionsApache HTTP Server before 2.4.55 according to Apache and CVE.org. The vulnerable component is mod_proxy, so hosts not using proxy functionality are much less relevant operationally.
Fixed versionsUpstream fix landed in 2.4.55 on 2023-01-17. Distro backports matter: Ubuntu fixed Jammy in 2.4.52-1ubuntu4.3 and Focal in 2.4.41-4ubuntu3.13; Debian fixed Buster in 2.4.38-3+deb10u9 and Bullseye in 2.4.56-1~deb11u1.
Researcher / disclosureDisclosed 2023-01-17; credited finder is Dimas Fariski Setyawan Putra (@nyxsorcerer).
Patch behaviorThe Apache fix commit 8b6d55f changes proxy header handling to fail on bad header instead of continuing with truncated parsing. That confirms the exploit primitive is malformed backend response handling, not memory corruption.
Exposure realityApache exposure on the internet is enormous in general, but this CVE does not scale with exposure counts. The vulnerable population is the subset running affected mod_proxy paths *and* trusting a compromised or hostile backend.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.6/10)

The single biggest severity reducer is that exploitation requires a malicious or compromised backend already behind your reverse proxy. That turns this from an internet initial-access issue into a narrow trust-boundary failure whose impact is usually limited to degraded client-side security headers on specific proxied routes.

HIGH Affected-version and fix metadata
HIGH No KEV / no public active exploitation evidence in reviewed sources
MEDIUM Operational severity downgrade based on enterprise deployment friction

Why this verdict

  • Requires attacker control of the backend: the adversary must already own, impersonate, or operate the origin behind Apache mod_proxy, which strongly implies prior compromise or a rare untrusted-backend architecture.
  • Reachable population is much smaller than generic Apache counts: only hosts using affected mod_proxy paths are relevant, and many enterprises proxy only first-party apps they already control.
  • Impact is integrity-only and usually chained: the flaw suppresses or garbles later response headers, but it does not directly yield code execution, credential theft, or proxy compromise without another web-layer weakness.

Why not higher?

If this were unauthenticated remote header injection from the client side, or if it yielded proxy takeover, this would climb fast. But needing a malicious backend is a huge real-world gate, and the direct outcome is mostly loss of response-header semantics rather than system compromise.

Why not lower?

This is still a real trust-boundary flaw in a very common edge component. In environments with shared reverse-proxy infrastructure, third-party backends, service-mesh experiments, or already-suspect app servers, it can quietly remove security headers and make follow-on web attacks easier.

05 · Compensating Control

What to do — in priority order.

  1. Restrict proxy trust boundaries — Limit Apache reverse proxying to known first-party backends and block ad hoc upstreams via config review and network policy. For a LOW verdict there is no SLA-driven emergency mitigation, but fold this into normal hygiene and complete the control review during the backlog cycle before the patch window closes.
  2. Monitor response security headers — Add synthetic checks for expected headers like Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, and hardened Set-Cookie attributes on proxied routes. This catches the *actual failure mode* of the CVE and should be implemented as standard observability rather than an emergency action.
  3. Segment backend-to-proxy paths — Use internal allowlists, mTLS where possible, and tight service ACLs so only intended upstreams can talk to the proxy tier. That reduces the chance a rogue or pivoted backend can sit behind Apache and weaponize malformed responses.
  4. Prefer distro-fixed packages over raw version matching — Because major Linux vendors backported the fix into older package versions, validate patched package releases instead of chasing only upstream 2.4.55+. For LOW, do this as part of routine patch hygiene before the remediation deadline.
What doesn't work
  • A WAF in front of Apache does not solve this, because the malformed content comes from the trusted backend response path, not the inbound client request.
  • MFA is irrelevant here; there is no user-authentication control in the exploit chain.
  • Perimeter scanning alone misses the key prerequisite, because external scanners usually cannot prove backend control or whether the vulnerable proxy path is actually in use.
06 · Verification

Crowdsourced verification payload.

Run this on the target Linux host that serves Apache traffic, not from an auditor workstation. Invoke it as sudo bash ./check-cve-2022-37436.sh; root is recommended so apachectl/httpd -M and package metadata are readable. The script outputs VULNERABLE, PATCHED, or UNKNOWN and exits 0, 1, or 2 respectively.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check-cve-2022-37436.sh
# Detect likely exposure to CVE-2022-37436 on Linux Apache HTTP Server hosts.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

status="UNKNOWN"
reason="could not determine"
server_bin=""
server_ver=""
mods=""

have_cmd() { command -v "$1" >/dev/null 2>&1; }
ver_lt() { [ "$(printf '%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]; }
ver_ge() { [ "$(printf '%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ]; }

find_apache() {
  for c in apache2 httpd apachectl apache2ctl; do
    if have_cmd "$c"; then
      echo "$c"
      return 0
    fi
  done
  return 1
}

extract_ver() {
  "$1" -v 2>/dev/null | sed -n 's/.*Apache\/[[:space:]]*\([0-9.][0-9.]*\).*/\1/p' | head -n1
}

list_mods() {
  local c="$1"
  if "$c" -M >/dev/null 2>&1; then
    "$c" -M 2>/dev/null
    return 0
  fi
  if have_cmd apachectl && apachectl -M >/dev/null 2>&1; then
    apachectl -M 2>/dev/null
    return 0
  fi
  if have_cmd apache2ctl && apache2ctl -M >/dev/null 2>&1; then
    apache2ctl -M 2>/dev/null
    return 0
  fi
  return 1
}

pkg_ver_deb() {
  dpkg-query -W -f='${Version}\n' apache2 2>/dev/null | head -n1
}

pkg_ver_rpm() {
  rpm -q --qf '%{VERSION}-%{RELEASE}\n' httpd 2>/dev/null | head -n1
}

is_proxy_loaded() {
  echo "$mods" | grep -Eiq 'proxy(_http|_ajp|_fcgi|_uwsgi|_http2)?_module|proxy_module'
}

server_bin="$(find_apache || true)"
if [ -z "$server_bin" ]; then
  echo "UNKNOWN - Apache binaries not found"
  exit 2
fi

server_ver="$(extract_ver "$server_bin")"
if [ -z "$server_ver" ]; then
  echo "UNKNOWN - could not parse Apache version from $server_bin -v"
  exit 2
fi

mods="$(list_mods "$server_bin" || true)"
if [ -n "$mods" ] && ! is_proxy_loaded; then
  echo "PATCHED - Apache $server_ver found, but no proxy module appears loaded; CVE-2022-37436 targets mod_proxy response handling"
  exit 0
fi

# Debian / Ubuntu package-aware checks for known backports
if have_cmd dpkg-query; then
  pkg="$(pkg_ver_deb)"
  if [ -n "$pkg" ]; then
    . /etc/os-release 2>/dev/null || true
    case "${VERSION_CODENAME:-}" in
      jammy)
        if ver_ge "$pkg" "2.4.52-1ubuntu4.3"; then
          echo "PATCHED - Ubuntu jammy apache2 package $pkg includes the fix"
          exit 0
        fi
        ;;
      focal)
        if ver_ge "$pkg" "2.4.41-4ubuntu3.13"; then
          echo "PATCHED - Ubuntu focal apache2 package $pkg includes the fix"
          exit 0
        fi
        ;;
      bionic)
        if ver_ge "$pkg" "2.4.29-1ubuntu4.26"; then
          echo "PATCHED - Ubuntu bionic apache2 package $pkg includes the fix"
          exit 0
        fi
        ;;
      xenial)
        if ver_ge "$pkg" "2.4.18-2ubuntu3.17+esm9"; then
          echo "PATCHED - Ubuntu xenial apache2 package $pkg includes the fix"
          exit 0
        fi
        ;;
      kinetic)
        if ver_ge "$pkg" "2.4.54-2ubuntu1.1"; then
          echo "PATCHED - Ubuntu kinetic apache2 package $pkg includes the fix"
          exit 0
        fi
        ;;
    esac

    # Debian backports noted in tracker
    case "${VERSION_CODENAME:-}" in
      buster)
        if ver_ge "$pkg" "2.4.38-3+deb10u9"; then
          echo "PATCHED - Debian buster apache2 package $pkg includes the fix"
          exit 0
        fi
        ;;
      bullseye)
        if ver_ge "$pkg" "2.4.56-1~deb11u1" || ver_ge "$pkg" "2.4.62-1~deb11u1" || ver_ge "$pkg" "2.4.66-1~deb11u1"; then
          echo "PATCHED - Debian bullseye apache2 package $pkg includes the fix"
          exit 0
        fi
        ;;
      bookworm)
        if ver_ge "$pkg" "2.4.62-1~deb12u2" || ver_ge "$pkg" "2.4.66-1~deb12u1"; then
          echo "PATCHED - Debian bookworm apache2 package $pkg includes the fix"
          exit 0
        fi
        ;;
    esac
  fi
fi

# Generic upstream version fallback
if ver_ge "$server_ver" "2.4.55"; then
  echo "PATCHED - Apache upstream version $server_ver is >= 2.4.55"
  exit 0
fi

if [ -n "$mods" ] && is_proxy_loaded && ver_lt "$server_ver" "2.4.55"; then
  echo "VULNERABLE - Apache $server_ver is < 2.4.55 and proxy modules appear loaded"
  exit 1
fi

# RPM-based systems often backport; avoid false positives if package provenance is unclear
if have_cmd rpm; then
  pkg="$(pkg_ver_rpm)"
  if [ -n "$pkg" ] && ver_lt "$server_ver" "2.4.55"; then
    echo "UNKNOWN - Apache $server_ver is < 2.4.55, but RPM distros may backport fixes; inspect vendor advisory for package $pkg and confirm whether mod_proxy is in use"
    exit 2
  fi
fi

echo "UNKNOWN - Apache $server_ver detected, but exposure could not be determined confidently"
exit 2
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not treat this like an internet-edge fire drill unless you run shared or semi-trusted backends behind Apache. First, inventory where mod_proxy is actually in use and identify any third-party, tenant, or recently compromised upstreams; for a LOW verdict there is no noisgate mitigation SLA and no emergency block is required. Then push the normal package update through backlog hygiene and complete patching within the noisgate remediation SLA for LOW items; if you discover untrusted backends or active app-tier compromise, escalate that environment separately because the *backend compromise* is the real incident, not this CVE in isolation.

Sources

  1. Apache HTTP Server 2.4 vulnerabilities advisory
  2. CVE.org record
  3. NVD entry
  4. Apache fix commit 8b6d55f
  5. Ubuntu CVE tracker
  6. Debian security tracker
  7. CISA Known Exploited Vulnerabilities Catalog
  8. Secondary PoC tracking
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.