Severity by source
CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Local-only race condition requiring low privileges and high complexity; limited impact across all three dimensions with no scope change.
Primary rating from Vendor (VulDB).
CVSS VectorVendor: VulDB
Lifecycle Timeline
2DescriptionCVE.org
A flaw has been found in antlr ANTLR4 up to 4.13.2. This affects the function ObjectInputStream.readObject of the file antlr4-maven-plugin/src/main/java/org/antlr/mojo/antlr4/GrammarDependencies.java of the component Maven Plugin. This manipulation causes time-of-check time-of-use. The attack is restricted to local execution. A high degree of complexity is needed for the attack. It is indicated that the exploitability is difficult. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
AnalysisAI
Time-of-check time-of-use (TOCTOU) race condition in antlr4-maven-plugin up to version 4.13.2 allows a local low-privileged attacker to manipulate grammar dependency state between validation and consumption in ObjectInputStream.readObject() within GrammarDependencies.java, yielding limited confidentiality, integrity, and availability impact on build artifacts. No public exploit identified at time of analysis is incorrect here - a publicly available exploit exists via a GitHub issue, though KEV listing is absent, indicating no confirmed widespread active exploitation. The CVSS 4.0 score of 1.1 reflects genuine low real-world risk due to local-only access, high attack complexity, and constrained impact scope.
Technical ContextAI
ANTLR4 (Another Tool for Language Recognition, version 4) is a Java-based parser generator widely used in compiler and language tooling projects. The affected component is the antlr4-maven-plugin (CPE: cpe:2.3:a:antlr:antlr4:*:*:*:*:*:*:*:*), which automates grammar compilation during Maven builds. The vulnerable code path is in GrammarDependencies.java, which calls ObjectInputStream.readObject() to deserialize cached grammar dependency data from disk. CWE-367 (Time-Of-Check Time-Of-Use) describes the root cause: the plugin reads a file handle or path reference, validates or checks a property of the object (e.g., file integrity, class type), and then proceeds to use the data - but a race window between check and use allows a concurrent local process to swap or modify the underlying file. Java's ObjectInputStream.readObject() is historically sensitive to the deserialization of unexpected class graphs; in this TOCTOU context, the attacker exploits the gap rather than a pure gadget-chain deserialization flaw. The plugin runs at build time, not production runtime, which significantly constrains the attack surface.
RemediationAI
No vendor-released patch has been identified at time of analysis - the vendor did not respond to coordinated disclosure. Teams using antlr4-maven-plugin should consider pinning to the latest 4.13.2 release and monitoring the upstream ANTLR4 GitHub repository for any subsequent releases that address this issue. As a compensating control, restrict write access to the Maven local repository cache and build working directories so that only the build service account can write to these paths, reducing the feasibility of file substitution during the TOCTOU window. Running Maven builds in isolated, ephemeral containers (e.g., Docker build stages with read-only bind mounts for dependency caches) eliminates the local attacker's ability to race the file operation, though this introduces build infrastructure overhead. Disabling grammar dependency caching in the plugin, if the configuration supports it, would eliminate the ObjectInputStream.readObject() code path entirely, but this may significantly increase incremental build times. Reference the POC at https://github.com/wooyun123/wooyun/issues/7 to understand the race window and validate whether mitigations are effective in your specific build environment.
Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m
Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti
Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent
Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug
JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up
Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up
The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow
Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla
The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-40000
GHSA-h73j-vjhq-j9vg