Topic starter
20/08/2026 5:23 pm
TL;DR: CVE-2026-13502 lets attacker-writable build-state in antlr4-maven-plugin reach Java deserialization during Maven builds, according to Corgea. Maven runners need strict cache isolation because reused workspace state can cross a trust boundary into publishing or secret-bearing jobs.
Editorial analysis by NHI Mgmt Group, based on content published by Corgea: “CVE-2026-13502: antlr4-maven-plugin build-state deserialization”.
Key questions
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.
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.
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.
Glossary terms: Build-state deserialization, Workflow trust boundary, Queue Poisoning, Unsafe Serialization
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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