CVE-2026-43514

What it actually does

CVE-2026-43514 is an observable timing discrepancy in Apache Tomcat's comparison of the AJP connector secret. When the AJP connector is enabled and protected with a shared secret, an unauthenticated network attacker who can reach the AJP port may be able to infer information about the configured secret by measuring response timing differences across many guesses. The impact is limited to confidentiality of the AJP secret and requires high-precision measurement, repeated attempts, and network access to the AJP service; it does not directly provide code execution, privilege escalation, or service disruption.

Why it matters to the business

Organizations exposing Tomcat AJP services to untrusted networks could face increased risk that an attacker gradually discovers the AJP shared secret and then uses the AJP connector as a trusted backend channel. While the CVSS score is low and exploitation is high-complexity with low EPSS and no known KEV listing, Tomcat is widely deployed and AJP misconfiguration has historically led to serious exposure, so internet-facing or partner-facing AJP ports should be treated as higher priority than the base score alone suggests.

How an attack unfolds

An attacker first identifies an Apache Tomcat instance with the AJP connector reachable over the network, typically on TCP port 8009. If the connector requires a secret, the attacker repeatedly sends AJP requests with candidate secret values and measures subtle timing differences in how Tomcat compares the supplied value against the configured secret. By statistically analyzing many requests under stable network conditions, the attacker may infer correct portions of the secret or narrow the search space. If the secret is recovered, the attacker may attempt to authenticate to the AJP connector and interact with backend application paths as a trusted front-end component, depending on connector configuration and application deployment. The timing nature of the flaw makes exploitation noisy in request volume but not necessarily obvious in application logs unless AJP access and failures are logged.

How to fix it

Upgrade Apache Tomcat to a fixed version: 11.0.22 or later for the 11.x line, 10.1.55 or later for the 10.1.x line, or 9.0.118 or later for the 9.x line. Apache Tomcat 8.5.x and 7.x are affected but are end-of-life or unsupported in many contexts; migrate to a supported fixed branch rather than relying on long-term compensating controls. If immediate upgrade is not possible, restrict AJP to trusted local or private network interfaces only, block external access to TCP port 8009, disable the AJP connector if not required, use a high-entropy secret, rotate the AJP secret after patching, and ensure reverse proxies or load balancers do not expose AJP to untrusted clients.

How to confirm the fix worked

Confirm the installed Tomcat version is 11.0.22 or later, 10.1.55 or later, or 9.0.118 or later. Review Tomcat configuration files such as server.xml to verify whether the AJP connector is enabled, whether it binds only to trusted interfaces, and whether the secretRequired and secret attributes are configured appropriately. Validate network exposure by scanning from untrusted network segments for open AJP services, especially TCP port 8009. After remediation, verify that unauthenticated hosts cannot connect to AJP and that the connector either is disabled, bound to localhost/private trusted addresses, or running a fixed Tomcat version. If the secret may have been exposed, rotate it and confirm dependent proxy or web server configurations have been updated accordingly.

Typical attack path

1. Scan for reachable Apache Tomcat AJP connectors, commonly TCP port 8009.
2. Confirm the AJP connector is enabled and requires a shared secret.
3. Send repeated AJP requests with crafted or guessed secret values.
4. Measure response timing differences across large numbers of attempts.
5. Use statistical analysis to infer information about the configured AJP secret.
6. If the secret is recovered, authenticate to the AJP connector and attempt backend access through trusted AJP routing.
7. Leverage any resulting access to enumerate deployed applications or reach protected application functionality.

How to detect it

Review network telemetry, firewall logs, load balancer logs, and host-based connection logs for unusual or repeated connections to Tomcat AJP services, commonly TCP port 8009. Look for high-volume short-lived AJP sessions, repeated failed AJP secret validation events, sequential or patterned attempts from the same source, and connections to AJP from hosts that are not approved reverse proxies or application front ends. Inspect Tomcat catalina logs, localhost logs, application logs, and any enhanced connector/access logging for AJP request failures or rejected messages. Because timing attacks may not leave a distinctive application-layer signature, prioritize correlation: sustained request bursts to AJP, many rejected AJP requests, low-and-slow probing over long periods, and any subsequent successful AJP access from previously failing or unauthorized sources. If packet capture or network detection is available, review traffic to TCP/8009 for AJP protocol messages from unauthorized IPs and abnormal volumes of requests with varying secret values. No public exploitation or named threat actor activity is indicated in the provided data, but absence from KEV does not rule out targeted probing against exposed AJP services.

• tcp/8009
• AJP/1.3
• org.apache.coyote.ajp.AjpNioProtocol
• org.apache.coyote.ajp.AjpAprProtocol
• org.apache.coyote.ajp.AjpNio2Protocol
• Connector protocol="AJP/1.3"
• secretRequired="true"
• secretRequired="false"
• server.xml
• catalina.out
• catalina.log
• localhost.log
• FailedRequestFilter
• Invalid message received with signature
• Rejected request because no secret was provided
• AJP request rejected
• Apache JServ Protocol

What your security team should do

• Prioritize patching any Tomcat instance with AJP reachable from the internet, partner networks, user subnets, or other untrusted segments.
• Upgrade to Tomcat 11.0.22+, 10.1.55+, or 9.0.118+; migrate unsupported 8.5.x and 7.x deployments to a supported branch.
• Block inbound access to TCP port 8009 except from explicitly authorized reverse proxies or application tiers.
• Disable the AJP connector wherever it is not required.
• Rotate AJP shared secrets after upgrading or after any suspected probing activity.
• Search logs and network telemetry for high-volume AJP connection attempts or repeated failed secret/authentication attempts.
• Add AJP exposure checks to external attack surface management and internal vulnerability scanning.
• Treat legacy Tomcat deployments as a modernization priority because unsupported branches may remain vulnerable without fixed releases.