CVE-2026-41293

What it actually does

This is a remotely reachable improper input validation flaw in Apache Tomcat. Based on the CVSS vector, an unauthenticated network attacker can trigger the vulnerable code path without user interaction and potentially compromise confidentiality, integrity, and availability of the Tomcat process and the applications it hosts. The exact exploit primitive is not provided in the advisory data, but the severity indicates that malformed or unexpected input may be handled unsafely enough to allow complete application/server impact rather than a limited error condition.

Why it matters to the business

Internet-facing Tomcat services may be at risk of full compromise, service disruption, or unauthorized access to hosted application data if they run an affected version. Because Tomcat is commonly embedded in Java application stacks, exposure may exist both in standalone servers and bundled vendor products. The issue is not currently listed in CISA KEV, is not reported as ransomware-used, and has low EPSS activity at this time, but the CVSS severity is critical and the vulnerability has been public for 92 days, so unpatched systems should be treated as high-priority remediation items.

How an attack unfolds

An attacker first identifies a service running Apache Tomcat by probing HTTP/S responses, headers, error pages, default paths, or application behavior. They then determine whether the exposed instance falls within an affected version range: 11.0.0-M1 through 11.0.21, 10.1.0-M1 through 10.1.54, 9.0.0.M1 through 9.0.117, or the unsupported 10.0.0-M1 through 10.0.27 line. The attacker sends specially crafted network input to a vulnerable Tomcat endpoint or parser path that fails to validate the input correctly. If successful, the flaw may allow the attacker to alter application behavior, access protected data, disrupt the service, or gain a stronger foothold in the hosted Java application environment. Post-exploitation activity would likely focus on credential discovery, web shell or malicious WAR deployment where permissions allow it, persistence in application directories, and lateral movement using secrets available to the Tomcat process.

How to fix it

Upgrade Apache Tomcat to a vendor-fixed release outside the affected ranges as soon as Apache publishes or confirms the corrected version for the deployed branch. Do not remain on Apache Tomcat 10.0.x, which is end of support; migrate to a supported Tomcat line. If immediate upgrade is not possible, reduce exposure by removing direct internet access to Tomcat, placing it behind a reverse proxy or WAF with strict request validation, disabling unused connectors and default applications, restricting access to manager/host-manager interfaces, enforcing least privilege for the Tomcat service account, and monitoring for exploitation attempts. Also update bundled Tomcat copies shipped inside commercial products, containers, appliances, CI/CD images, and Java application distributions, not only standalone installations.

How to confirm the fix worked

Confirm the running Tomcat version from startup logs, package managers, container image manifests, application server metadata, and the Tomcat ServerInfo output where available. Validate that no deployed instance reports an affected version in the 11.0.0-M1 through 11.0.21, 10.1.0-M1 through 10.1.54, 9.0.0.M1 through 9.0.117, or 10.0.0-M1 through 10.0.27 ranges. Restart Tomcat after upgrade and verify that the startup banner and runtime package metadata reflect the fixed build. Re-run external and internal vulnerability scans, software composition analysis, and container image scans to confirm the vulnerable Tomcat artifact is no longer present. For mitigations, test that management endpoints are not publicly reachable, unexpected HTTP methods and malformed requests are rejected, and Tomcat runs under a constrained service account with limited filesystem and network permissions.

Typical attack path

1. Scan the internet or target network for HTTP/S services that appear to be Apache Tomcat or Tomcat-backed applications.
2. Fingerprint the Tomcat major/minor version using headers, error pages, default endpoints, management interfaces, package metadata leaks, or indirect application behavior.
3. Confirm the instance is within an affected range: 11.0.0-M1 through 11.0.21, 10.1.0-M1 through 10.1.54, 9.0.0.M1 through 9.0.117, or 10.0.0-M1 through 10.0.27.
4. Send crafted input to the vulnerable Tomcat processing path to trigger improper validation.
5. Use the resulting impact to read or manipulate application data, interrupt service, or gain control over the hosted application context.
6. Attempt persistence or follow-on actions such as deploying malicious application artifacts, modifying configuration, collecting credentials, or pivoting to adjacent systems.

How to detect it

Investigate whether affected Tomcat instances received suspicious traffic before remediation. Review Tomcat access logs, localhost logs, catalina logs, application logs, reverse proxy logs, load balancer logs, WAF events, EDR telemetry, and file integrity monitoring data. Look for spikes in malformed HTTP requests, unusual encodings, unexpected request methods, abnormal 400/500 responses followed by successful requests, requests to rarely used Tomcat endpoints, access to manager or host-manager paths, and traffic from scanning infrastructure. On hosts, inspect webapps, work, temp, conf, and logs directories for unexpected WAR, JSP, class, JAR, or configuration changes; compare timestamps against suspicious requests. Review process telemetry for Tomcat spawning shells, script interpreters, network utilities, or other child processes not normally launched by the Java service. Check for newly created users, modified Tomcat credentials, changed deployment descriptors, altered context XML files, unusual outbound connections from the Tomcat process, and credential access involving environment variables, configuration files, keystores, or application secrets. No specific public exploit strings, payload markers, or threat actor indicators are provided in the input, so detection should focus on behavioral evidence and environment-specific baselining.

What your security team should do

• Inventory all standalone, embedded, containerized, and vendor-bundled Apache Tomcat deployments, including non-production environments exposed to untrusted networks.
• Prioritize remediation for internet-facing Tomcat instances and systems that process sensitive data or have access to internal credentials, databases, or management networks.
• Upgrade affected Tomcat branches to vendor-fixed supported releases; migrate any 10.0.x deployments to a supported branch.
• Ask application and platform owners to verify whether commercial products, appliances, and Java applications bundle affected Tomcat versions and obtain vendor patches where needed.
• Temporarily restrict external access, enforce reverse-proxy/WAF controls, and limit management interface access until patching is complete.
• Enable heightened monitoring of Tomcat access logs, catalina logs, application logs, reverse proxy logs, WAF alerts, endpoint telemetry, and deployment directories for signs of abnormal requests or unauthorized application changes.
• Review Tomcat service account privileges, remove write access where not required, rotate credentials accessible to the Tomcat process if compromise is suspected, and validate no unexpected WAR/JSP/class files were deployed.
• Track Apache advisories for exact fixed versions because the supplied advisory data does not include a concrete fixed version.