Apache Software Foundation Apache Tomcat buffer under-read can mix responses and expose prior data

Buffer under-read vulnerability in Apache Tomcat meant that a large non-blocking write could result in the response body being split between the current request and the next request received on that connection leading most likely to failure of the second request and possibly leakage of data from the first response to the second. This issue affects Apache Tomcat: from 11.0.0-M25 through 11.0.26. Users are recommended to upgrade to version 11.0.27, which fixes the issue.

• Apache Tomcat from 11.0.0-M25 through 11.0.26 is identified as affected.
• Apache Tomcat 11.0.27 is identified as the version that fixes the issue.
• The supplied record establishes only this Apache Tomcat 11 release branch. The status of parallel branches, other packaged distributions, or versions outside the stated range is not established by the available evidence.

The weakness is classified as CWE-127 Buffer under-read in Apache Tomcat. During a large non-blocking write, Tomcat may read less data than intended from a buffer, causing the response body to be split between the current request and the next request received on the same connection. The attacker-controlled condition is a remotely supplied request sequence on a reusable connection; the normalized record states that authentication and user interaction are not required. Red Hat describes narrower practical runtime conditions involving asynchronous non-blocking writes, data large enough to trigger buffer fragmentation, connection reuse, and suitable timing. The available evidence does not identify the internal buffer structure, size threshold, function, or exact configuration that triggers the flaw.

The flaw is remotely reachable, and the normalized record states that the follow-up request requires neither authentication nor user interaction. Practical exploitation depends on whether the application performs asynchronous non-blocking response writes, produces a sufficiently large response, and permits connection reuse. Red Hat notes that reliable exploitation also depends on precise timing and specialized application logic, so practical exploitability may vary substantially across deployments. The record marks a public exploit as false, but it does not provide a known-exploited status; this does not prove that exploitation is impossible or has never occurred. No evidence returned here identifies a campaign, victim, or specific abuse activity.

The flaw can split a response body between the current request and the subsequent request on the same connection. The technical outcome can include disclosure of data from the earlier response and failure of the later request, creating confidentiality and availability consequences. The described exposure is limited to response mixing between requests or sessions sharing a connection; no evidence establishes data modification, privilege escalation, or code execution. Actual exposure depends on the contents of the earlier response, connection reuse, and whether the application uses non-blocking writes.

Response mixing can disclose data intended for an earlier request to a later requester sharing the same connection. Depending on the response contents, application data or other sensitive information could be exposed, but the available evidence does not identify a specific data type or victim. The subsequent request will most likely fail, causing user-visible errors, retries, and service disruption. The record does not describe data modification, privilege escalation, or account takeover.

1. Upgrade Apache Tomcat from the affected range to 11.0.27, which the Apache source identifies as fixing the issue.
2. For vendor packages, container images, or other redistributed builds, apply the provider's corresponding update and verify the Apache Tomcat version actually deployed.
3. Prioritize review of applications that use asynchronous or non-blocking response writes and connection reuse while planning the upgrade.
4. The available evidence does not identify a reliable compensating configuration. If an upgrade cannot be completed immediately, treat deployments meeting the stated runtime conditions as exposed and increase review of cross-request response failures.

• Inventory running Apache Tomcat processes, packages, container images, and embedded installations, then compare the observed version with the affected range.
• Identify applications that use asynchronous or non-blocking response writes, especially where HTTP connections can be reused.
• Review telemetry and error reports for repeated failures of subsequent requests or response content being associated with the wrong request on the same connection. Treat these as investigation leads, not confirmed indicators of compromise.
• Check client reports and integration-test results for content from an earlier response appearing in a later response. The absence of such evidence in logs does not prove that the system is safe.
• Confirm remediation through version and package inventory after the upgrade rather than relying only on normal service behavior.