Cloudanix VulnDB

CVE-2023-5379

High · 7.5

CVSS

7.5

EPSS

1.0%

Published

Dec 12, 2023

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A specially crafted oversized request can make a web server stop accepting traffic from certain backend systems, causing websites or applications to become unavailable until fixed.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
Network Service
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Oversized AJP requests exceeding the configured max-header-size trigger connection closure without an AJP response, causing mod_proxy_cluster to mark the backend as an error worker and halt request forwarding, resulting in denial of service.

Why it matters to the business

Service availability for affected web applications is disrupted until the backend recovers, with potential for repeated outages from low-volume malicious traffic; the single known dependent package and low EPSS indicate limited ecosystem exposure despite the three-year age of the issue.

How an attack unfolds

An unauthenticated attacker repeatedly transmits AJP requests crafted to exceed the listener's max-header-size limit; each request causes the backend to drop the connection, which mod_cluster interprets as an error state and stops routing traffic to that instance until manual intervention or timeout.

How to fix it

Upgrade php-censor/php-censor to version 2.1.5 or later; ensure Undertow AJP listeners have appropriately sized max-header-size settings aligned with expected traffic and monitor mod_cluster worker health.

How to confirm the fix worked

Confirm the php-censor package version is at least 2.1.5, test AJP request handling with headers at and above the configured limit to verify graceful error responses instead of connection drops, and validate mod_cluster continues forwarding after such requests.

Typical attack path

  1. Identify an AJP listener endpoint exposed via mod_cluster
  2. Craft and send AJP requests larger than the max-header-size value
  3. Observe the backend marked as error worker and traffic failover or outage
  4. Repeat the oversized requests to sustain the denial of service condition

How to detect it

Review mod_cluster logs and httpd error logs for repeated worker error-state transitions immediately following AJP requests; correlate with Undertow access logs showing connections closed without responses on AJP endpoints.

What your security team should do

  • Apply the 2.1.5 package update in the next maintenance window given the low EPSS and non-KEV status
  • Review and tune max-header-size on all AJP listeners to match legitimate request profiles
  • Add mod_cluster worker status monitoring to detect error-state transitions quickly

The record

A flaw was found in Undertow. When an AJP request is sent that exceeds the max-header-size attribute in ajp-listener, JBoss EAP is marked in an error state by mod_cluster in httpd, causing JBoss EAP to close the TCP connection without returning an AJP response. This happens because mod_proxy_cluster marks the JBoss EAP instance as an error worker when the TCP connection is closed from the backend after sending the AJP request without receiving an AJP response, and stops forwarding. This issue could allow a malicious user could to repeatedly send requests that exceed the max-header-size, causing a Denial of Service (DoS).

Affected packages

Ecosystem Package Introduced Fixed
Debian:13 undertow 0 No fix
Ubuntu:16.04:LTS undertow 0 No fix
Ubuntu:18.04:LTS undertow 0 No fix
Ubuntu:20.04:LTS undertow 0 No fix
Ubuntu:22.04:LTS undertow 0 No fix
Ubuntu:24.04:LTS undertow 0 No fix
Ubuntu:24.10 undertow 0 No fix
Ubuntu:25.04 undertow 0 No fix
Ubuntu:25.10 undertow 0 No fix
Ubuntu:Pro:16.04:LTS undertow 0 No fix
Ubuntu:Pro:18.04:LTS undertow 0 No fix
Ubuntu:Pro:20.04:LTS undertow 0 No fix

Related vulnerabilities