ANTLR Maven plugin deserialization flaw turns build caches into risk

At a glance

What this is: This is a CVE in the ANTLR4 Maven plugin where attacker-controlled build-state can be deserialized during parser generation, turning a build cache into an execution risk.

Why it matters: It matters because CI runners and developer builds often hold tokens, signing material, and publishing rights, so a build-time flaw can become an identity and secret exposure problem as well as an AppSec issue.

👉 Read Corgea's analysis of CVE-2026-13502 in the ANTLR4 Maven plugin

Context

CVE-2026-13502 shows how a build plugin can become a security boundary when it reads state from attacker-writable directories during Maven execution. The issue is not just a time-of-check/time-of-use race. The more material problem is that the plugin deserializes persisted build metadata, which means poisoned cache contents can influence the build process itself.

For identity and access teams, the important point is that build systems are not isolated from identity risk. CI runners and developer workstations often carry package-registry credentials, source-control tokens, cloud keys, and artifact-publishing rights, so a build-time compromise can quickly become a secrets exposure and privilege abuse event. That makes workspace trust and credential scoping part of the same control plane.

This pattern is increasingly typical in modern supply-chain attacks, where trusted automation handles untrusted inputs. The starting position here is unfortunately common in mixed-trust development environments, especially where caches and shared workspaces are reused across jobs.

Key questions

Q: What breaks when a build plugin deserializes attacker-controlled state?

A: The build stops being a passive compiler step and becomes an execution boundary. If attacker-writable bytes are deserialized with ObjectInputStream.readObject(), the plugin may instantiate object graphs or trigger unsafe behaviour inside the Maven process. That can expose secrets, corrupt artifacts, or give the attacker code execution inside the CI runner or developer workstation.

Q: Why do shared CI workspaces make build-cache attacks more dangerous?

A: Shared workspaces let untrusted writes survive long enough to be consumed by later jobs that run with higher privilege or more secrets. That turns a local cache issue into a supply-chain problem because the attacker is not trying to break the build immediately. They are trying to influence the next trusted execution step.

Q: What do security teams get wrong about serialization warnings in build tools?

A: They often treat them as reliability defects instead of trust-boundary failures. In a build pipeline, deserialization warnings matter because the process may already hold package credentials, signing keys, or deployment access. The control question is not whether the cache usually works, but whether attacker-controlled data can ever reach it.

Q: Who should be accountable for secrets hidden inside build and release pipelines?

A: Ownership should sit with the teams that operate the workflow and the identity controls that authorize it, not with the security team alone. If a pipeline can reach production systems, package registries, or internal repositories, its credential posture belongs in governance reviews, access recertification, and incident response planning.

Technical breakdown

Why Java deserialization in a build plugin is dangerous

The vulnerable code path uses ObjectInputStream.readObject() to load dependencies.ser from the Maven build directory. In Java, deserialization is not simple parsing. It reconstructs object graphs and can instantiate attacker-influenced classes unless the caller constrains the stream. That is why ObjectInputFilter exists. When build tools accept serialized state from writable directories, they turn local file manipulation into a potential execution primitive inside the build process.

Practical implication: treat any build-state deserialization as a code-execution boundary, not a harmless cache read.

How shared workspaces turn TOCTOU into a supply-chain problem

The plugin checks whether the status file exists before opening it, which creates a replaceable race window. In a single-user context that may look like a stability defect, but in CI the window matters because another job, step, or malicious dependency can write to the same path between checks. Shared runners, reused workspaces, and mutable caches make the race exploitable in practice, especially when the same process later runs with publishing or signing privileges.

Practical implication: separate writable build state by trust boundary and stop reusing target directories across jobs.

Why build-state poisoning is an identity and secrets issue

Maven jobs often run with access to repository tokens, package registries, cloud credentials, and signing material. If attacker-controlled build-state is deserialized in that context, the issue expands beyond code integrity into NHI governance because the CI job itself behaves like a privileged workload identity. The real risk is not just broken builds. It is credential exposure, artifact tampering, and downstream trust in a pipeline that should have been least-privileged and ephemeral.

Practical implication: inventory the secrets held by build identities before you decide whether a vulnerable runner can be tolerated.

Threat narrative

Attacker objective: The attacker wants code execution inside the build pipeline so they can steal credentials, tamper with artifacts, or pivot into release systems.

1. Entry occurs when an attacker writes a poisoned dependencies.ser file into a shared workspace, cached build directory, or other attacker-controlled Maven path.
2. Escalation happens when antlr4:antlr4 runs and GrammarDependencies.loadStatus() deserializes that file with ObjectInputStream.readObject() without a class filter.
3. Impact is code execution or object-graph abuse inside the Maven process, with exposure of tokens, signing material, generated artifacts, or downstream deployment trust.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Gravity SMTP CVE-2026-4020 API Keys Exposure — CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Build-state deserialization is now a governance problem, not just a code defect. The important failure here is not simply that a file was checked too late. It is that a build plugin treated attacker-writable serialized data as trusted input inside a privileged process. That collapses the boundary between cache data and executable state, which is exactly where supply-chain attacks become operationally dangerous. Practitioners should treat serialized build metadata as part of the application security boundary.

Ephemeral build identities need the same scrutiny as human administrators. CI jobs often hold the exact secrets that attackers want after initial access, including artifact publishing rights and package registries. When a build process can deserialize untrusted state, the job identity itself becomes the attack target. This is where NHI governance intersects with AppSec: privileged automation must have tighter lifecycle controls, narrower secret scope, and less mutable workspace trust.

Mutable caches create a hidden trust debt. Shared workspaces, reused target directories, and cross-job caches all assume that earlier writes remain trustworthy. That assumption fails in mixed-trust pipelines and in any environment where pre-build steps, dependencies, or adjacent jobs can write into the same path. The concept here is build cache trust collapse, and it should be treated as a repeatable supply-chain failure mode, not an edge case.

Serialization filtering should be viewed as a minimum containment control, not a complete fix. ObjectInputFilter can reduce the blast radius, but the safer pattern is to remove raw Java serialization from build-state persistence altogether. Data-only formats and schema-constrained encodings are easier to reason about and easier to audit. Teams should assume that any tool still using object deserialization in a build path will remain a recurring review item.

Release pipeline privilege and artifact integrity are the real downstream stakes. A compromised build can do more than fail a job. It can sign, publish, or seed tampered artifacts into later stages if the same identity has persistent rights. That is why this issue belongs in both software supply-chain governance and NHI controls. The practical conclusion is to reduce standing privilege wherever build automation touches release trust.

From our research:

• 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
• 15% of commit authors have leaked at least one secret in their contribution history.
• Forward view: secret exposure in developer workflows is not rare, so pipeline trust controls need to assume credential leakage can already be in play; see Guide to the Secret Sprawl Challenge.

What this signals

Build pipelines are becoming identity-rich attack surfaces. As release automation accumulates package tokens, signing keys, and cloud credentials, the practical control question shifts from build speed to trust scoping. Teams should align CI runner permissions with the minimum secret set they actually need, then pair that with workspace isolation and tighter cache hygiene.

Build cache trust collapse is the useful concept here: once writable build-state is reused across trust boundaries, the cache becomes part of the adversary model. That means security architects should review shared runners, mutable workspaces, and pre-build hooks with the same seriousness they already give to privileged service accounts and deployment identities.

The broader lesson is that supply-chain resilience depends on identity lifecycle discipline, not just dependency scanning. Where a pipeline identity can publish, sign, or deploy, the organisation needs short-lived access, clear offboarding, and auditable state handling. For related guidance, teams can cross-check their controls against the MITRE ATT&CK Enterprise Matrix and the NIST SP 800-53 Rev 5 Security and Privacy Controls.

For practitioners

• Find affected plugin usage immediately Search all Maven projects for org.antlr:antlr4-maven-plugin 4.13.0 through 4.13.2, then confirm the resolved version in CI and local effective POM output before any further build runs.
• Remove writable build-state from shared paths Delete target/maven-status/antlr4/dependencies.ser before the ANTLR goal runs and stop reusing untrusted target or workspace state across jobs, repositories, or trust levels.
• Tighten runner identity and secret scope Reduce the permissions and secret footprint of CI job identities so build runners do not hold long-lived publishing tokens, signing keys, or cloud credentials they do not strictly need.
• Treat tampered builds as incident material If a suspicious dependencies.ser file may have been consumed, preserve logs and artifacts, rotate repository and package credentials, and review downstream outputs for tampering before redeploying.

Key takeaways

• This flaw shows that build metadata can become executable trust boundary material when a plugin deserializes attacker-writable state.
• The exposure matters because CI runners often carry high-value secrets and publishing rights, so a build-time issue can become a credential and artifact integrity event.
• The most effective containment is to eliminate mutable shared build state, narrow runner privileges, and remove raw Java serialization from the path entirely.

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.
• Shared workspace trust boundary: The point at which one job, repository, or trust level should no longer be allowed to influence another through the same filesystem path or cache. In CI, a shared workspace can quietly turn from convenience into an attack path if writes are not isolated.
• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.
• Build cache trust collapse: A failure mode where cached or persisted build data is reused across untrusted contexts even though earlier writes may no longer be trustworthy. This is especially dangerous when the cache influences execution, dependency resolution, or release outputs.

What's in the full analysis

Corgea's full research covers the operational detail this post intentionally leaves for the source:

• Exact proof-of-concept flow for poisoning dependencies.ser in a Maven workspace
• Code excerpts showing the deserialization sink and the time-of-check/time-of-use window
• Environment patterns that increase exploitability in CI runners and developer workstations
• Concrete remediation commands and upstream fix expectations for maintainers

👉 Corgea's full post covers the build-state exploit path, affected versions, and remediation steps in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle controls. It helps security and IAM practitioners apply tighter governance where automation and privileged access overlap.