CVE-2026-13502: ANTLR4 Race Condition Vulnerability

CVE-2026-13502 Overview

CVE-2026-13502 is a time-of-check time-of-use (TOCTOU) race condition in the ANTLR4 Maven Plugin. The flaw resides in the ObjectInputStream.readObject call within antlr4-maven-plugin/src/main/java/org/antlr/mojo/antlr4/GrammarDependencies.java in versions up to 4.13.2. Exploitation requires local access, low privileges, and high attack complexity. The exploit has been published, but the vendor did not respond to the disclosure. The weakness maps to [CWE-362] (concurrent execution using shared resource with improper synchronization).

Critical Impact
A local attacker can exploit the race window between file check and deserialization in the ANTLR4 Maven Plugin, though the attack complexity is high and impact is limited to low confidentiality, integrity, and availability effects.

Affected Products

ANTLR ANTLR4 versions up to and including 4.13.2
antlr4-maven-plugin component
GrammarDependencies.java file within the Maven Plugin module

Discovery Timeline

2026-06-28 - CVE-2026-13502 published to NVD
2026-06-29 - Last updated in NVD database

Technical Details for CVE-2026-13502

Vulnerability Analysis

The ANTLR4 Maven Plugin uses Java object deserialization to read cached grammar dependency metadata during build execution. The GrammarDependencies class invokes ObjectInputStream.readObject on a file after performing a prior existence or state check. Between the check and the read operation, a local attacker with filesystem access can substitute the target file. This creates a classic TOCTOU race condition where the trusted state observed at check time no longer holds at use time. The window allows an attacker to influence which serialized object gets loaded into the JVM during a Maven build.

Root Cause

The root cause is non-atomic file handling in GrammarDependencies.java. The plugin validates or stats a dependency cache file, then reopens it later for deserialization instead of holding a single file handle across both operations. Java's ObjectInputStream.readObject does not enforce identity between the checked file and the file ultimately read. This gap enables filesystem-level substitution attacks against the Maven build process.

Attack Vector

Exploitation requires local execution on the build host with permission to write to the plugin's working directory or dependency cache location. The attacker must win a narrow timing window between the plugin's file check and the deserialization call. Because the required conditions include local access, low privileges, and precise timing, exploitability is rated as difficult. Successful exploitation could allow controlled deserialization input, which may lead to limited confidentiality, integrity, or availability impact within the build environment. Refer to the VulDB Vulnerability Details for exploit publication details.

Detection Methods for CVE-2026-13502

Indicators of Compromise

Unexpected file replacements or symlink swaps within the antlr4-maven-plugin working directory during Maven builds.
Anomalous ObjectInputStream deserialization events originating from Maven build processes on shared build hosts.
Unfamiliar processes writing to grammar dependency cache files immediately before or during ANTLR4 plugin execution.

Detection Strategies

Monitor filesystem activity on Maven build agents for concurrent writes to files accessed by GrammarDependencies.java.
Audit ANTLR4 versions across build infrastructure to identify installations at or below 4.13.2.
Enable Java deserialization logging or filtering with jdk.serialFilter to record unexpected class loads during builds.

Monitoring Recommendations

Track process lineage on CI/CD runners to identify local users interacting with Maven working directories.
Alert on modifications to files under the plugin's output and cache paths that occur between successive plugin invocations.
Review build logs for deserialization errors or unexpected class instantiation originating from the ANTLR4 Maven Plugin.

How to Mitigate CVE-2026-13502

Immediate Actions Required

Restrict local access to Maven build hosts and CI/CD runners to trusted users only.
Ensure the ANTLR4 Maven Plugin working directory resides on a filesystem where only the build user has write permissions.
Configure a strict Java deserialization filter using jdk.serialFilter to reject unexpected classes during Maven builds.

Patch Information

As of the disclosure, the vendor did not respond to the reporter and no official patch has been published. Consult the VulDB CVE Database Entry and the GitHub Issue Discussion for the latest remediation status. Downstream users should track the ANTLR project for a release beyond 4.13.2 that removes or hardens the ObjectInputStream.readObject call in GrammarDependencies.java.

Workarounds

Run Maven builds in isolated, ephemeral containers so no untrusted local user shares the filesystem with the build process.
Pin the ANTLR4 Maven Plugin to a version only after verifying an upstream fix is available, and rebuild in clean environments.
Set restrictive permissions (for example, 0700) on the plugin's target and cache directories to prevent concurrent tampering.

bash

# Configuration example: harden Maven build environment against TOCTOU on shared hosts
# 1. Restrict permissions on the Maven working directory
chmod -R 700 ~/.m2
chown -R builduser:builduser ~/.m2

# 2. Enforce a Java deserialization allow-list for Maven
export MAVEN_OPTS="-Djdk.serialFilter='org.antlr.**;java.base/*;!*'"

# 3. Run builds in an ephemeral container to eliminate local co-tenants
docker run --rm -u builduser -v "$PWD":/src -w /src maven:3.9 \
  mvn -Dmaven.repo.local=/src/.m2 clean package