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.
4 steps from start to impact.
Land on or control a proxied backend
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.- Apache HTTP Server before
2.4.55 mod_proxyin use for reverse proxying- Attacker can control backend response headers
- 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
mod_proxy is installed but not actually brokering untrusted backends.Send a malformed header through the proxy
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.- Backend can emit malformed or oversized header material
- Apache forwards that backend response via affected
mod_proxycode path
- The attacker needs precise control over header ordering and malformed content
- Impact depends on useful security headers appearing *after* the truncation point
Strip security semantics from the client response
- Security-relevant headers appear after the malformed one
- Client behavior depends on those headers being honored
- 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
Exploit the downgraded browser-side posture
- A meaningful downstream web attack exists
- Users hit the affected proxied path
- Requires chaining with a separate browser- or app-layer weakness
- Blast radius is limited to responses served by the specific affected backend path
The supporting signals.
| In-the-wild status | No evidence of active exploitation found in the source set, and not present in CISA KEV. |
|---|---|
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities Catalog as of the current catalog page. |
| EPSS | 0.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 availability | No 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 check | CVSS: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 versions | Apache 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 versions | Upstream 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 / disclosure | Disclosed 2023-01-17; credited finder is Dimas Fariski Setyawan Putra (@nyxsorcerer). |
| Patch behavior | The 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 reality | Apache 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. |
noisgate verdict.
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.
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_proxypaths 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.
What to do — in priority order.
- 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
LOWverdict 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. - Monitor response security headers — Add synthetic checks for expected headers like
Strict-Transport-Security,Content-Security-Policy,X-Frame-Options, and hardenedSet-Cookieattributes on proxied routes. This catches the *actual failure mode* of the CVE and should be implemented as standard observability rather than an emergency action. - 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.
- 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+. ForLOW, do this as part of routine patch hygiene before the remediation deadline.
- 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.
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.
#!/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
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.