ANTLR Maven plugin deserialization flaw turns build caches into risk

At a glance

What this is: CVE-2026-13502 affects the ANTLR Maven plugin and turns writable build-state into a potential Java deserialization path inside Maven builds.

Why it matters: It matters because CI runners and developer workstations often hold publishing credentials, tokens, and signing material, so build-directory trust becomes an access-control issue as well as a coding flaw.

Context

CVE-2026-13502 is a build-time trust boundary problem, not just a parser-plugin bug. The issue arises when Maven build state stored under target/maven-status/antlr4/dependencies.ser is treated as trusted input even though shared workspaces, caches, and pre-build steps can make that file attacker writable.

For IAM, PAM, and NHI teams, the important point is that build jobs often run with secrets and publishing rights that exceed what the code under build should ever inherit. Once a build plugin deserializes workspace state, the build cache becomes part of the security boundary that governs credentials, tokens, and release access.

Key questions

Q: What breaks when a Maven build deserializes attacker-writable cache state?

A: The build boundary breaks because the process starts trusting bytes that can be changed by another job, repository, or cache consumer. In practice, that can turn generated build metadata into code execution inside the Maven process. Once the runner has publishing rights or secrets, the compromise moves from a local build flaw to a supply-chain event.

Q: Why does cache reuse increase the impact of build-tool deserialization bugs?

A: Cache reuse lets one trust domain write state that a later, more privileged job reads as if it were self-generated. That creates a hidden privilege transfer across jobs and branches. The risk rises when runners hold registry credentials, signing material, or cloud tokens, because the poisoned cache can reach a high-value execution context.

Q: What are the signs that build-state trust is failing in CI pipelines?

A: Look for writable target trees, shared runner workspaces, unexpected build artefacts surviving between jobs, and plugins that read serialized files from the build directory. Repeated warnings around status files, unexplained build failures, or cache pollution across repositories are strong indicators that build-state trust is being stretched beyond its safe boundary.

Q: Should teams treat build-cache poisoning as an incident response issue?

A: Yes. If a build consumed attacker-controlled state, the response should include token rotation, artifact review, and preservation of the workspace for forensics before cleanup. The important decision is not only how to patch the plugin, but how to decide whether the build environment itself must be treated as compromised.

Technical breakdown

Why build-state deserialization is dangerous in Maven plugins

Java deserialization is not a simple file read. When a plugin calls ObjectInputStream.readObject(), it asks the JVM to rehydrate an object graph from bytes on disk, which can instantiate attacker-chosen classes unless the caller constrains the stream. In build systems, that means a seemingly inert cache file can become an execution trigger if the plugin trusts attacker-writable workspace state. The risk is amplified when the build process already has access to source-control tokens, package registries, or signing material. In this case, the problem is not the grammar parser itself but the decision to treat build metadata as trusted Java objects.

Practical implication: Treat serialized build-state files as untrusted input and remove Java serialization from build caches wherever possible.

How shared workspaces turn cache poisoning into code execution

The vulnerable file lives under target/maven-status/antlr4/dependencies.ser, which is inside the same build tree many teams reuse across jobs, branches, or repositories. If an attacker can write that path before the ANTLR goal runs, the next Maven invocation loads the poisoned state during antlr4:antlr4 execution. That creates a practical supply-chain path even when the attacker never reaches production directly, because the build runner itself becomes the execution environment. The key governance issue is workspace reuse across trust boundaries, which collapses the assumption that build outputs are always self-generated.

Practical implication: Separate writable build directories by trust level and stop reusing cached target state across untrusted jobs.

Why the TOCTOU label understates the real exposure

The public description mentions a time-of-check/time-of-use flaw because the code checks statusFile.exists() before opening it, which creates a replaceable race window. That is relevant, but the higher-impact issue is the deserialization sink after the file is opened. A race alone might swap metadata; a deserialization sink can turn that swap into arbitrary object loading inside the Maven process. For defenders, the meaningful question is not whether the file existed a millisecond earlier. It is whether attacker-controlled bytes are ever allowed to become live objects in a privileged build context.

Practical implication: Prioritise controls that block unsafe deserialization, not just controls that narrow file replacement windows.

Threat narrative

Attacker objective: The attacker aims to execute code inside a trusted build process and use that foothold to steal credentials or tamper with released artifacts.

1. Entry occurs when an attacker gains write access to a Maven workspace, shared cache, or pre-build step that can modify target/maven-status/antlr4/dependencies.ser.
2. Credentialed build execution then loads the poisoned file during antlr4:antlr4, and ObjectInputStream.readObject() attempts to materialise attacker-controlled object data inside the Maven process.
3. Impact follows when code execution in CI or on a developer workstation can expose source-control tokens, package-publishing rights, signing material, or downstream artifact integrity.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Build metadata has become an access boundary, not just an implementation detail. The important lesson in CVE-2026-13502 is that CI caches and generated state can no longer be assumed safe simply because they live under target/. Once a build plugin deserializes attacker-writable state, the build system itself inherits trust obligations normally reserved for application inputs. Practitioners should treat build directories as governed assets, not disposable scratch space.

Unsafe deserialization in build tooling creates a governance gap that many teams still miss. Security reviews often focus on application runtime, while build-time code paths are left to engineering convenience. This flaw shows that a privileged Maven job can be compromised before the application is even assembled, which means release pipelines need the same control discipline as production services. Teams should extend their identity and privilege model into CI runner design.

CI cache reuse is a form of privilege reuse. When one job can write state that another job later trusts, the pipeline has effectively delegated authority across trust boundaries without explicit approval. That is especially risky where runners hold registry credentials, cloud keys, or signing rights, because a poisoned cache can turn an ordinary build into a high-value compromise. Practitioners should map cache ownership and trust scope as carefully as they map human access.

ANTLR build-state poisoning is a concrete example of the secret-sprawl problem moving into the software supply chain. Secrets are not only leaking from vaults and repositories; they are also being exposed by build systems that reuse mutable state across environments. The governance response is to treat build caches, workspace artifacts, and generated metadata as part of the credential attack surface. Security teams should align build hygiene with NHI and secrets governance.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Cache poisoning is now a governance problem, not just a pipeline hygiene problem. Build teams need to assume that any writable workspace reused across trust boundaries can become an execution path, especially when a plugin deserializes state from disk. That changes the control objective from clean builds to controlled trust inheritance.

Build-state poisoning belongs in the same conversation as NHI and secrets sprawl. CI systems frequently concentrate the exact credentials attackers want, and mutable caches make those credentials reachable from places engineers often do not monitor closely. The practical implication is that pipeline design, secret placement, and cache scope have to be reviewed together rather than as separate programmes.

Build metadata is becoming part of the application security boundary. When a Maven plugin reads cached state with the same trust it gives source code, the pipeline is effectively certifying its own inputs. Teams should map that boundary explicitly and remove any persistent build state that can be influenced by untrusted code.

For practitioners

• Inventory affected Maven builds Search repositories and CI definitions for org.antlr:antlr4-maven-plugin versions 4.13.0 through 4.13.2, then identify every runner that can execute antlr4:antlr4 with writable workspace state.
• Remove trust from shared build state Delete target/maven-status/antlr4/dependencies.ser before ANTLR runs and stop reusing untrusted target/ trees across jobs, branches, or repositories.
• Constrain build-process privileges Ensure runners that can publish artifacts, access registries, or use signing material cannot also inherit writable caches from lower-trust jobs or repositories.
• Replace Java serialization in build metadata Move build-state persistence to a schema-constrained format and avoid ObjectInputStream.readObject() for any file that a workspace or cache can influence.
• Review builds as potential compromise events If a poisoned dependencies.ser may have been consumed, rotate publishing tokens, inspect generated parsers and artifacts, and preserve the build state for forensics.

Key takeaways

• CVE-2026-13502 shows that a build plugin can turn cached workspace state into a trusted execution path, which makes the CI runner part of the attack surface.
• The risk is not limited to parser generation. Any runner that holds publishing rights, source-control tokens, or signing material can turn a poisoned cache into a supply-chain compromise.
• The limiting control is to remove trust from mutable build state, separate caches by trust domain, and eliminate unsafe deserialization from the build process.

Key terms

• Build-state deserialization: The process of loading previously saved build metadata back into an object form during a build. It becomes risky when the saved state can be modified by an attacker, because the build tool may reconstruct attacker-influenced objects instead of reading inert data.
• Workflow trust boundary: A workflow trust boundary is the point where one step in a business or technical process stops being fully trusted and must be checked before the next step continues. It defines where identity, data, or action permissions change, and where controls such as approval, validation, logging, or isolation should be applied.
• Queue Poisoning: Queue poisoning is the abuse of a shared request pipeline so that attacker-controlled bytes are processed as part of another user’s or another request’s traffic. It is dangerous because the attacker does not need direct code execution to influence what the back-end sees next.
• Unsafe Serialization: Unsafe serialization is the use of file formats or deserialization methods that can execute embedded code when a model or object is loaded. In AI environments, formats such as pickle or joblib can become attack paths if untrusted artifacts are accepted. The risk is code execution disguised as data handling.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps security and IAM practitioners connect identity controls to the broader systems that build, sign, and release software.