Skip to content
Vulnerabilities

Apache Tomcat APR connector remains vulnerable to local socket access

A low-severity race condition in Apache Tomcat 9.0.47 to 9.0.122 allows unauthorised local access to Unix domain sockets via the APR connector.

Illustration: A tangled knot of grey Ethernet cables spills from a small, open server chassis.
AI-generated illustration: AppSec Scoop

Key points

  • CVE-2026-80353 affects Apache Tomcat versions 9.0.47 through 9.0.122.
  • The flaw is a time-of-check time-of-use race condition in the APR/Native connector.
  • The previous fix for CVE-2026-65183 did not address this specific component.

Apache Tomcat users relying on the APR/Native connector face a persistent security gap. An unauthorised local user can exploit a race condition to access Unix domain sockets in affected versions.

What happened

Mark Thomas posted an advisory to the oss-security mailing list on 20 October regarding CVE-2026-80353. The report identifies a time-of-check time-of-use vulnerability within Apache Tomcat. This flaw exists specifically when the application creates Unix domain sockets for the APR/Native connector. The issue allows an unauthorised local user to gain access to these sockets. The vulnerability affects Apache Tomcat versions 9.0.47 through 9.0.122.

The advisory notes that a previous remediation effort missed this specific attack vector. The fix released for CVE-2026-65183 addressed the same race condition in the NIO connector only. It did not resolve the identical issue present in the APR/Native connector code. Consequently, systems updated for the earlier CVE remain exposed to this new variant.

Why it matters

Organisations using the APR/Native connector for high-performance Unix socket communication are at risk. The vulnerability is rated as low severity by the reporter. The oversight in the previous patch cycle indicates that partial fixes may leave residual exposure. Teams must verify whether their deployment uses the APR connector rather than the NIO connector.

What happens next

  • Identify all servers running Apache Tomcat 9.0.47 through 9.0.122.
  • Check configuration files to determine if the APR/Native connector is enabled.
  • Monitor vendor channels for a specific patch addressing CVE-2026-80353.
  • Apply strict file permissions to socket directories as an immediate mitigation.

Patch priority

Security teams should prioritise systems where the APR/Native connector is actively handling production traffic. Isolate these instances from untrusted local users immediately. Validate that any previous updates applied for CVE-2026-65183 did not inadvertently switch the connector type. Test configuration changes in a non-production environment before rolling them out. Ensure backup procedures are current before making any system modifications. Reduce the attack surface by restricting local user access to the directories containing the Unix domain sockets.

What to do and how to stay safe: Apache Tomcat

  • Audit server configurations to confirm whether the APR/Native connector is in use.
  • Restrict local user permissions on directories hosting Unix domain sockets.
  • Monitor official Apache Tomcat channels for a dedicated patch release.
  • Review logs for unauthorised access attempts to socket files.

Step-by-step guide: Patch Management: Definition, Purpose and Operational Reality

General security guidance from the AppSec Scoop newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which Apache Tomcat versions are affected by CVE-2026-80353?

Versions 9.0.47 through 9.0.122 are affected by this vulnerability.

Is this a new issue or an oversight from a previous fix?

It is an oversight; the fix for CVE-2026-65183 addressed the NIO connector but not the APR/Native connector.

What is the severity of CVE-2026-80353?

The advisory rates the severity as low.

Sources

  1. oss-security mailing list
Apache TomcatCVE-2026-80353APR connectorUnix domain socketsrace condition

Related stories

Organisations face rapid SYSTEM compromise via AI agents and known Windows flaws

Attackers used AI-driven automation and public exploits to seize full server control in under 24 hours, bypassing traditional malware signatures and standard detection methods.