Notifications
Clear all
Topic starter
18/08/2026 2:21 pm
TL;DR: A Maven Central jar published as io.github.davidtimur:c2-lab executed a remote-access payload during compilation when placed on the annotation-processor path, while rebuilding its command channel across nine releases and even disabling TLS validation in the final version, according to Xygeni. The case shows that build-time execution boundaries in Java are broader than many supply-chain scanners assume, especially when service registration files trigger code outside source-level review.
NHIMG editorial — based on content published by Xygeni: JavacDoor, a Maven artifact that ran during compilation rather than installation
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when a Java artifact can execute during compilation?
A: The normal assumption that dependencies are inert until imported breaks immediately.
Q: Why do build systems need identity controls as well as package controls?
A: Because the real target is often the build service account, signing key, or artifact publishing credential.
Q: How do security teams detect malicious behaviour hidden inside jars?
A: They need structural parsing, not text grepping.
Practitioner guidance
- Classify annotation-processor paths as executable trust zones Inventory every dependency that can be loaded by javac, and separate those artifacts from normal compile-classpath libraries.
- Inspect jar service-registration files before promotion Build a control that parses archives for service-provider entries, then traces each named class into bytecode and constant pools.
- Monitor compiler subprocesses and outbound build traffic Alert when javac spawns shell processes or when build jobs make unexpected outbound connections during compilation.
What's in the full report
Xygeni's full article covers the operational detail this post intentionally leaves for the source:
- Release-by-release timeline showing how the payload changed from callback to reverse shell to HTTP polling
- Constant-pool indicators and build-log markers that help distinguish this artifact from ordinary annotation processors
- Observed network paths, headers, and TLS manipulation patterns for deeper incident triage
- Removal details for the artifact and group from Maven Central, useful for provenance investigations
👉 Read Xygeni's analysis of the JavacDoor Maven artifact and build-time execution →
Javac annotation processors: are your build paths executable?
Explore further
18/08/2026 3:13 pm
Compiler-triggered execution is a supply-chain risk class of its own: this case is not just malware in a jar, it is build-time code execution through a documented language feature. That makes the control problem different from simple dependency approval, because the trigger sits in compiler semantics and service discovery. Teams should therefore classify annotation processors as active execution artifacts, not passive libraries.
A question worth separating out:
Q: Who is accountable when a build dependency steals source code?
A: Accountability usually spans engineering, platform security, and supply chain governance. Engineering owns dependency selection, platform teams own build isolation and egress controls, and security owns detection and policy enforcement. For regulated environments, the question becomes whether the organisation can prove it had reasonable controls over code provenance and execution.
👉 Read our full editorial: Javac can execute compiled jars during builds, not just installs
