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.
Editorial analysis by NHI Mgmt Group, based on content published by Corgea: “CVE-2026-13502: antlr4-maven-plugin build-state deserialization”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:13 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: ANTLR Maven plugin deserialization flaw turns build caches into risk