Heap-based Buffer Overflow vulnerability in mod_proxy_ajp of Apache HTTP Server

CVE-2026-28780 is a heap overflow in mod_proxy_ajp that is triggered when Apache HTTP Server parses a malicious reply from an AJP backend. The key qualifier is the one the scary 9.8 summary hides: the attacker does not hit the public web listener directly and win; Apache must already be configured to use mod_proxy_ajp, and it must connect to a malicious or compromised AJP server that sends a crafted response. Apache says affected versions are through 2.4.66, fixed in 2.4.67 released on 2026-05-04.

The severity inflation comes from scoring this like a generic unauthenticated network RCE. Reality is narrower. Apache itself labeled it low on 2026-05-04/05, because the exploit path requires a trusted backend relationship, which usually means internal network reachability, a compromised app server, a rogue service registration, or a misrouted proxy target. That is still worth fixing because frontends often sit in higher-trust zones, but it is a post-initial-access or trust-boundary-pivot flaw, not an internet spray-and-pray emergency.

Why this verdict

• Requires backend control: the exploit path starts only if Apache connects to a malicious AJP server, which implies internal position, prior compromise, or trust abuse.
• Reachable population is small: only hosts using mod_proxy_ajp with ajp:// backends are really in scope; plenty of Apache fleets never enable AJP at all.
• Small overwrite, uncertain weaponization: the issue is a 4-byte attacker-controlled heap overwrite, which is serious but materially harder to convert into dependable RCE than the raw CVSS suggests.

Why not higher?

It is not higher because the public HTTP surface is not the real attack surface. The attacker must already be in a position to impersonate or compromise an AJP backend, which is compounding friction and a major reduction in exposed population. No KEV listing, no reviewed in-the-wild reports, and no authoritative public exploit chain push it further down.

Why not lower?

It is not lower because memory corruption inside a reverse proxy is never free. If you do run AJP, a compromised backend can attack the frontend process and potentially cross a trust boundary toward keys, routing logic, or adjacent applications. That keeps it out of pure backlog-hygiene territory.

1. Disable mod_proxy_ajp where unused — If the business does not require AJP, remove the module and eliminate the vulnerable code path entirely. For a MEDIUM verdict there is noisgate mitigation SLA: no mitigation SLA — go straight to the 365-day remediation window, but unused AJP should still be removed during normal config hygiene.
2. Pin backend targets tightly — Restrict Apache to known AJP backend IPs/hostnames and prevent dynamic or user-influenced backend selection. This reduces the chance that service-discovery poisoning, DNS drift, or a rogue internal host can become the malicious AJP peer before patching; deploy as part of normal hardening while you work the remediation window.
3. Block rogue AJP traffic — Use host firewall rules, security groups, or ACLs so Apache can reach only sanctioned AJP backends on 8009 or your chosen port. This is the most practical containment if you must keep AJP and cannot remediate immediately.
4. Prefer HTTP/HTTPS proxying for new deployments — Where architecture allows, move new reverse-proxy integrations off AJP and onto mod_proxy_http/HTTPS. That removes this parser family from future exposure and simplifies inspection and policy enforcement.
5. Monitor Apache child crashes — Alert on repeated httpd/apache2 worker exits, core dumps, and backend-specific request failures on AJP-connected frontends. It will not stop exploitation, but it gives you the best chance to catch unsuccessful or DoS-style attempts while patches are pending.

Run this on the target Apache host with local shell access. Invoke it as bash check_cve_2026_28780.sh or bash check_cve_2026_28780.sh /etc/apache2 if configs live in a nonstandard path; no root is required for version/module checks, but reading all config files may need elevated privileges.

#!/usr/bin/env bash
# check_cve_2026_28780.sh
# Conservative detector for CVE-2026-28780 on Apache HTTP Server.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

CFG_ROOT="${1:-}"
STATUS="UNKNOWN"
REASON=""

find_httpd_bin() {
  local c
  for c in apache2ctl apachectl httpd; do
    if command -v "$c" >/dev/null 2>&1; then
      command -v "$c"
      return 0
    fi
  done
  return 1
}

extract_version() {
  local bin="$1"
  local out ver
  out="$($bin -v 2>/dev/null || true)"
  ver="$(printf '%s\n' "$out" | sed -n 's/^Server version: Apache\/\([0-9][0-9.]*\).*$/\1/p' | head -n1)"
  if [ -z "$ver" ]; then
    ver="$(printf '%s\n' "$out" | sed -n 's/^Server version:[[:space:]]*Apache\/\([0-9][0-9.]*\).*$/\1/p' | head -n1)"
  fi
  printf '%s' "$ver"
}

ver_ge() {
  # returns 0 if $1 >= $2
  [ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -n1)" = "$2" ]
}

ver_lt() {
  # returns 0 if $1 < $2
  ! ver_ge "$1" "$2"
}

guess_cfg_roots() {
  if [ -n "$CFG_ROOT" ] && [ -d "$CFG_ROOT" ]; then
    printf '%s\n' "$CFG_ROOT"
  fi
  for d in /etc/apache2 /etc/httpd /usr/local/apache2/conf; do
    [ -d "$d" ] && printf '%s\n' "$d"
  done
}

module_loaded=0
ajp_configured=0
httpd_bin="$(find_httpd_bin || true)"
version=""

if [ -n "$httpd_bin" ]; then
  version="$(extract_version "$httpd_bin")"
fi

# Check loaded modules if possible
if [ -n "$httpd_bin" ]; then
  if "$httpd_bin" -M 2>/dev/null | grep -Eq 'proxy_ajp_module|mod_proxy_ajp'; then
    module_loaded=1
  fi
fi

# Fall back to config grep for module/config presence
while IFS= read -r root; do
  if grep -R -Eqs 'LoadModule[[:space:]]+proxy_ajp_module|proxy_ajp_module' "$root" 2>/dev/null; then
    module_loaded=1
  fi
  if grep -R -Eqs 'ajp://|ProxyPass[[:space:]].*ajp:|BalancerMember[[:space:]].*ajp:' "$root" 2>/dev/null; then
    ajp_configured=1
  fi
done < <(guess_cfg_roots)

if [ -z "$version" ]; then
  echo "UNKNOWN - Could not determine Apache httpd version"
  exit 2
fi

# Upstream fixed version
if ver_ge "$version" "2.4.67"; then
  echo "PATCHED - Apache version $version is >= 2.4.67"
  exit 0
fi

# Vulnerable code present in old version, but practical exposure depends on AJP use
if ver_lt "$version" "2.4.67"; then
  if [ "$module_loaded" -eq 1 ] && [ "$ajp_configured" -eq 1 ]; then
    echo "VULNERABLE - Apache version $version is < 2.4.67 and mod_proxy_ajp with ajp:// backend config was found"
    exit 1
  fi
  if [ "$module_loaded" -eq 1 ] || [ "$ajp_configured" -eq 1 ]; then
    echo "UNKNOWN - Apache version $version is < 2.4.67 and partial AJP indicators were found; verify distro backports and active config"
    exit 2
  fi
  echo "UNKNOWN - Apache version $version is < 2.4.67 but no active AJP module/config was detected; package may still contain vulnerable code"
  exit 2
fi

echo "UNKNOWN - Unable to classify"
exit 2

Sources

1. Apache HTTP Server 2.4 vulnerabilities
2. Apache mod_proxy_ajp documentation
3. NVD CVE-2026-28780
4. OpenCVE record for CVE-2026-28780
5. CISA Known Exploited Vulnerabilities Catalog
6. Debian security tracker
7. Ubuntu CVE tracker for apache2
8. SUSE CVE page