CVE-2025-31650

What it actually does

Apache Tomcat improperly handles certain malformed HTTP priority headers. When Tomcat rejects these invalid requests, error handling may fail to fully clean up request-related objects, causing memory to be retained. Repeated malformed requests can steadily exhaust JVM heap memory and trigger an OutOfMemoryError/OutOfMemoryException, making the Tomcat process unstable or unavailable. The issue affects Apache Tomcat 9.0.76 through 9.0.102, 10.1.10 through 10.1.39, and 11.0.0-M2 through 11.0.5.

Why it matters to the business

Successful exploitation can take public-facing Java web applications offline without requiring authentication, causing service outages, failed transactions, degraded customer experience, and operational response costs. The EPSS score is high and exploit availability is reported, so internet-exposed Tomcat services should be treated as priority remediation targets even though the issue is not currently listed in CISA KEV and is not known to be used in ransomware campaigns.

How an attack unfolds

An attacker identifies an exposed Apache Tomcat service running a vulnerable version, then sends a large volume of HTTP requests containing specially malformed priority headers. Each invalid request is rejected, but due to incomplete cleanup in the vulnerable error path, memory associated with the failed request can remain allocated. By sustaining or repeating this traffic, the attacker forces JVM heap usage to grow until garbage collection cannot recover enough memory. The Tomcat process may then throw OutOfMemoryError/OutOfMemoryException, stop responding, restart if supervised, or become unstable, resulting in denial of service for hosted applications.

How to fix it

Upgrade Apache Tomcat to a fixed release: 9.0.104 or later for the 9.0.x branch, 10.1.40 or later for the 10.1.x branch, or 11.0.6 or later for the 11.0.x branch. For source-based deployments, ensure the Apache Tomcat code includes commit 872451298e20bb77ea95c499e6866b1e32b337e0 or a later fixed revision. If Tomcat is bundled by an application, container image, Linux distribution, appliance, or platform service, update the vendor package or base image that contains Tomcat. As interim mitigation, restrict access to Tomcat from untrusted networks where possible, place services behind a reverse proxy or WAF capable of rejecting malformed Priority headers, enforce rate limits, tune request limits, and ensure JVM/process supervisors restart failed services; these mitigations reduce availability impact but do not replace upgrading.

How to confirm the fix worked

Confirm the running Tomcat version is not in the affected ranges: 9.0.76-9.0.102, 10.1.10-10.1.39, or 11.0.0-M2-11.0.5. Validate through startup logs, package manager metadata, container image contents, server info tooling, or the deployed Tomcat libraries rather than relying only on application banners. After upgrading, confirm Tomcat reports 9.0.104+, 10.1.40+, or 11.0.6+. Review dependency and container scans for embedded Tomcat components. In a controlled test environment only, send malformed Priority-header requests at low volume and verify they are rejected without sustained heap growth; do not perform high-volume testing against production services.

Typical attack path

1. Scan for internet-accessible Apache Tomcat endpoints or Java web applications that expose Tomcat response characteristics.
2. Fingerprint the target to determine whether it is likely running an affected Tomcat release.
3. Send repeated HTTP requests containing invalid or malformed priority headers.
4. Cause Tomcat to enter the vulnerable request error-handling path repeatedly.
5. Accumulate unreleased request-related memory in the JVM heap.
6. Trigger excessive garbage collection, OutOfMemoryError/OutOfMemoryException, application instability, or process termination.
7. Repeat traffic to keep the service unavailable or unstable after restart.

How to detect it

Look for signs of repeated malformed HTTP requests containing Priority headers followed by JVM memory pressure or Tomcat instability. Useful sources include reverse proxy logs, WAF logs, load balancer logs, Tomcat access logs, Tomcat catalina logs, application logs, JVM garbage-collection logs, container runtime logs, systemd/service manager logs, Kubernetes pod events, and APM metrics. Hunt for spikes in HTTP 400 responses, unusual request bursts from a small set of IPs, repeated requests with a Priority header, abnormal heap growth, excessive full garbage collection, OutOfMemoryError/OutOfMemoryException messages, pod restarts, JVM exits, or service-manager restart events. Correlate timestamps of malformed Priority-header traffic with memory exhaustion, GC pauses, and Tomcat restarts. Because this is a denial-of-service vulnerability rather than a code-execution issue, durable host artifacts may be limited; network and application telemetry are the most valuable evidence.

• Priority:
• priority:
• java.lang.OutOfMemoryError
• OutOfMemoryError: Java heap space
• java.lang.OutOfMemoryError: Java heap space
• OutOfMemoryException
• GC overhead limit exceeded
• java.lang.OutOfMemoryError: GC overhead limit exceeded
• Exception in thread
• org.apache.catalina.startup.Catalina
• Server startup in
• Stopping service [Catalina]
• org.apache.catalina.core.StandardService.stopInternal
• catalina.out
• localhost_access_log
• HTTP/1.1" 400
• HTTP/2" 400
• Malformed
• Invalid
• Priority header
• CrashLoopBackOff
• OOMKilled
• Killed process
• systemd[1]: tomcat
• systemd[1]: tomcat.service: Main process exited

What your security team should do

• Prioritize patching internet-facing and business-critical Tomcat deployments because exploit availability and high EPSS indicate meaningful exploitation likelihood.
• Inventory all direct, embedded, containerized, and vendor-bundled Tomcat instances, including applications that ship their own Tomcat runtime.
• Upgrade to Tomcat 9.0.104+, 10.1.40+, or 11.0.6+ depending on the deployed branch.
• Apply temporary perimeter controls to block or normalize malformed Priority headers and rate-limit suspicious request bursts until upgrades are complete.
• Monitor JVM heap, garbage collection behavior, Tomcat restarts, HTTP 400-rate spikes, and OutOfMemoryError events for signs of exploitation attempts.
• Ensure process supervision, autoscaling, and alerting are configured so Tomcat crashes or memory exhaustion are detected quickly.
• Review historical logs around unexplained outages, high garbage collection, or repeated bad-request bursts to determine whether exploitation may already have occurred.