CVE-2026-33857

What it actually does

CVE-2026-33857 is an out-of-bounds read vulnerability in mod_proxy_ajp in Apache HTTP Server through 2.4.66. When Apache is configured to proxy traffic using the AJP protocol, a specially crafted network request can cause the module to read memory outside the intended buffer. The stated impact is limited to confidentiality: an unauthenticated remote attacker may be able to disclose unintended process memory or adjacent data handled by the Apache worker process. The CVSS vector indicates network exploitability, low attack complexity, no authentication required, no user interaction, unchanged scope, low confidentiality impact, and no integrity or availability impact.

Why it matters to the business

Organizations using Apache HTTP Server as an AJP reverse proxy may face limited information disclosure risk if exposed services remain on versions through 2.4.66. Potentially exposed data could include fragments of proxied request or response data, headers, cookies, backend metadata, or other memory-resident values depending on process state and configuration. There is no current CISA KEV listing, no known ransomware association, no named threat actor reporting, no public exploit maturity, and EPSS is low and flat at 0.00393, so broad active exploitation is not currently indicated. However, because Apache HTTP Server is widely deployed infrastructure and this issue is remotely reachable in affected configurations, remediation should be scheduled promptly, especially for internet-facing reverse proxies using mod_proxy_ajp.

How an attack unfolds

An attacker first identifies an Apache HTTP Server instance that is running an affected version and has mod_proxy_ajp enabled for a reachable route. The attacker then sends crafted HTTP requests that are translated by Apache into AJP proxy traffic in a way that triggers the out-of-bounds read condition in mod_proxy_ajp. If exploitation succeeds, Apache may include unintended memory contents in a response, error behavior, or protocol output observable by the attacker. The attacker may repeat requests to collect small memory fragments and analyze them for sensitive values such as session identifiers, authentication headers, backend application data, internal hostnames, or configuration-derived strings. Exploitation does not provide code execution or direct data modification by itself, but any disclosed secrets could support follow-on attacks such as session hijacking or access to backend services.

How to fix it

Upgrade Apache HTTP Server to version 2.4.67 or later. The advisory states that Apache HTTP Server through 2.4.66 is affected and 2.4.67 fixes the issue. Where vendor operating-system packages are used, apply the vendor-provided Apache/httpd security update that backports the fix and verify the package changelog references this vulnerability or the mod_proxy_ajp out-of-bounds read fix. If immediate upgrade is not possible, disable mod_proxy_ajp if it is not required, remove or restrict ProxyPass/ProxyPassMatch rules using the ajp:// scheme, and limit access to AJP-backed routes to trusted networks or upstream controls. Review reverse-proxy configurations to ensure AJP is not exposed unnecessarily and prefer supported HTTP-based proxying where feasible.

How to confirm the fix worked

Confirm Apache HTTP Server is upgraded to 2.4.67 or later, or that the operating-system vendor package includes the backported fix. Validate with commands such as `httpd -v`, `apache2 -v`, package manager queries, container image manifests, and vendor changelogs. Inspect Apache configuration for `LoadModule proxy_ajp_module`, `mod_proxy_ajp`, `ProxyPass` or `ProxyPassMatch` directives using `ajp://`, and included configuration files. Confirm that any required AJP proxying still functions after upgrade and that unneeded AJP proxy routes are removed. From an exposure perspective, test externally reachable virtual hosts and paths to verify that only intended services are reachable and that version disclosure is minimized. Vulnerability scanners should be tuned to check both Apache version and whether AJP proxying is enabled, because systems running affected versions without mod_proxy_ajp in use have materially lower practical exposure.

Typical attack path

1. Scan for Apache HTTP Server instances and identify version banners, error pages, headers, or package metadata suggesting versions through 2.4.66.
2. Determine whether mod_proxy_ajp is enabled by probing routes, reverse-proxy behavior, AJP-backed applications, and characteristic backend responses.
3. Send specially crafted requests to an AJP-proxied endpoint to exercise the vulnerable mod_proxy_ajp parsing path.
4. Observe responses, abnormal output, connection behavior, or error patterns that may contain leaked memory or confirm the vulnerable code path.
5. Repeat requests with varied lengths, headers, and payload structure to attempt disclosure of useful memory fragments.
6. Extract any sensitive values from returned data and use them for follow-on access, session abuse, credential replay, or reconnaissance.

How to detect it

To assess possible prior exploitation, review Apache access logs, error logs, reverse-proxy logs, WAF/CDN logs, and backend application logs for requests to AJP-proxied routes that show malformed syntax, unusual header or body lengths, repeated probing, abnormal response sizes, or unexplained 500/502/503 errors. Focus on systems running Apache HTTP Server through 2.4.66 with mod_proxy_ajp enabled and `ajp://` proxy rules. Look for repeated requests from the same source varying payload size, header count, encoding, transfer behavior, or path parameters, followed by unexpectedly large or binary-looking responses. Correlate suspicious requests with backend logs for protocol errors, truncated responses, or unusual AJP forwarding behavior. Because no public exploit maturity, named threat actor activity, KEV listing, or ransomware association is currently reported, there are no reliable exploit-specific payload signatures; detection should emphasize behavioral anomalies against AJP-backed paths and signs of information leakage in responses. If full packet capture or response-body logging is available, search for responses from Apache that contain memory-like fragments, unexpected headers, session tokens, backend hostnames, configuration strings, or binary data unrelated to the requested resource.

• LoadModule proxy_ajp_module
• mod_proxy_ajp
• ProxyPass ajp://
• ProxyPassMatch ajp://
• ajp://
• proxy:error
• proxy_ajp:error
• AH01030
• AH01031
• AH00898
• AH01102
• AH00992
• 500
• 502
• 503

What your security team should do

• Inventory internet-facing and internal Apache HTTP Server deployments, prioritizing reverse proxies, application gateways, and container images that may include mod_proxy_ajp.
• Upgrade affected Apache HTTP Server instances through 2.4.66 to 2.4.67 or later, or apply the equivalent vendor backported security package.
• Prioritize remediation for servers with `mod_proxy_ajp` loaded and `ajp://` ProxyPass or ProxyPassMatch routes, especially if reachable from untrusted networks.
• Disable mod_proxy_ajp and remove AJP proxy mappings where they are not operationally required.
• Add detection for unusual requests against AJP-backed proxy paths, repeated malformed requests, spikes in 4xx/5xx responses, and responses with abnormal sizes from affected Apache servers.
• Review Apache access logs, error logs, reverse-proxy logs, WAF logs, and backend application logs for suspicious probing since publication, especially on internet-facing systems.
• Reduce information leakage by disabling unnecessary version banners and standardizing error handling on externally exposed Apache servers.
• Track Apache Software Foundation and operating-system vendor advisories for any exploitability clarifications, backported fix identifiers, or subsequent hardening guidance.