Notifications
Clear all
Topic starter
20/08/2026 5:23 pm
TL;DR: CVE-2026-13502 affects org.antlr:antlr4-maven-plugin 4.13.0 through 4.13.2, where attacker-writable build-state in target/maven-status/antlr4/dependencies.ser can be deserialized inside Maven builds, creating a code-execution path in CI runners and developer workstations, according to Corgea. Build metadata is now part of the application security boundary, so cache trust, workspace reuse, and serialization handling need immediate review.
NHIMG editorial — based on content published by Corgea: CVE-2026-13502 analysis for the ANTLR4 Maven plugin
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Corgea's analysis of CVE-2026-13502 in the ANTLR4 Maven plugin →
ANTLR Maven plugin CVE-2026-13502: what build teams should check?
Explore further
20/08/2026 6:13 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: ANTLR Maven plugin deserialization flaw turns build caches into risk
