Snyk Blog In this article What was compromised Timeline What's impacted How it works Here's why this is a supply chain problem and not a normal vulnerability: Did it actually work? How to detect it How to mitigate, and what to do next This is protestware for the AI era Aftermath The takeaway Protestware by open source maintainer to hinder agentic coding: The jqwik 1.10.0 Prompt Injection Written by Brian Vermeer June 2, 2026 0 mins read On May 25, 2026, the maintainer of jqwik , a Java property-based testing library, released version 1.10.0 to Maven Central with a hidden instruction intended for AI coding agents. The payload told agents to disregard previous instructions and delete all jqwik tests and code. It was hidden from humans with ANSI terminal codes but left fully readable to any tool that captures raw output. Nothing was compromised in the usual sense. The maintainer wrote it on purpose. No exploit, no stolen credentials, no sandbox escape. Any pipeline that pulled the dependency and fed test output back into an LLM agent could have triggered the prompt injection. Real impact looks limited so far. At least one major agent caught it and refused to act. But this is the first clear case of a maintainer using prompt injection as a supply chain weapon, and that is the part worth paying attention to. What was compromised jqwik is a property-based testing engine that runs on the JUnit 5 platform. Plenty of JVM projects depend on it. Here are the details you can verify against: Package: net.jqwik:jqwik-engine Affected version: 1.10.0 Follow-up release: 1.10.1 The malicious instruction lived in a new method called printMessageForCodingAgents() , inside the net.jqwik.engine.execution.JqwikExecutor class. The method name tells you the intent on its own. And the person who wrote it was Johannes Link, the project's own maintainer. Not an outside attacker who hijacked the account. Timeline May 25, 2026: Version 1.10.0 lands on Maven Central. The release notes say nothing about the hidden behavior. May 27, 2026: A developer (GitHub user rbatllet) spots an odd line in their CI logs after a Dependabot update. They decompile the JAR and find the print calls. Issue #708 goes up against jqwik. A parallel report, #62741, goes up against the Claude Code repo. Both include a reproducible Maven output sample. Late May 2026: The backlash builds. Link updates the release notes to admit the injection and says jqwik should not be used by AI agents. He also says he won't comment further until he talks to a lawyer. Shortly after: Version 1.10.1 ships. The directive gets softened, and the hiding becomes opt-in. What's impacted Direct dependents: Any project that pulled net.jqwik:jqwik-engine at 1.10.0 , directly or transitively. CI/CD pipelines: Build environments that resolved 1.10.0 and surfaced test output into logs. AI coding agents that read terminal output: Tools that parse stdout as part of their loop. Think Claude Code, GitHub Copilot's agent mode, Cursor. They were the target, because they read the raw bytes the human never saw. The message is only "hidden" on destinations that interpret ANSI codes, which means interactive terminals. Anywhere that captures bytes literally keeps it intact. Jenkins, GitHub Actions logs, IDE test-runner panels, and agent wrappers that spawn non-PTY subprocesses. On all of those, the instruction sits there in plain text. How it works The trick is simple. The code prints the instruction line, then prints ESC [2K followed by a carriage return, twice. ESC is the control byte 0x1B . [2K means erase the entire current line. CR sends the cursor back to column zero. This is the code snippet from commit 9dddcb5226 On a real terminal, that sequence wipes the line before you can read it. The message flashes and disappears. But on any stream that records output as raw text instead of rendering it, those erase codes are just dead characters. The instruction stays right there in the log. That asymmetry is the whole game. Invisible to a human watching a terminal. Fully legible to a machine parsing the log. Agentic coding tools fold terminal and test output back into their context while they work. So a destructive line buried in that output can get read as a real command. Here's why this is a supply chain problem and not a normal vulnerability: You pull the dependency, you run the tests, the payload comes along for the ride. The weakness is in interpretation, not in code. The risk is an agent treating tool output as trusted instructions. That's also why it doesn't cleanly map onto CVE criteria. It's intentional maintainer behavior, not an accidental defect. The security community hasn't decided whether maintainer-injected prompts are a vulnerability class or out of scope. Did it actually work? Mostly no, from what's been reported. At least one agent shut it down. In the documented field observation, Claude Code flagged the instruction on the first mvn test run, refused to act on it, and traced it back to its source in the JAR. So, in this case, the prompt injection just didn't work. The concern is downstream. A weaker agent or model without proper guardrails that doesn't treat tool output with suspicion might follow it. And then you're looking at anything from a minor annoyance to losing your source and test files with no useful audit trail. How to detect it Search your manifests and lockfiles for net.jqwik:jqwik-engine at exactly 1.10.0 . Check suspect JARs against the SHA-256 above. Grep your CI and IDE logs for the phrase about disregarding instructions and deleting jqwik tests and code. Watch for stray ESC[2K and carriage-return artifacts around your test summaries. If you need to confirm, decompile the 1.10.0 JAR. The printMessageForCodingAgents() calls in JqwikExecutor are right there. How to mitigate, and what to do next Move off 1.10.0. Be aware that updating to 1.10.1 changes the behavior but still contains a softer, non-destructive prompt injection for coding agents. By the maintainer's own words, the project is no longer meant for AI-assisted workflows. Factor that in. Sandbox your agents. Don't run autonomous coding agents with your full user privileges. Restrict file-system write access during dependency resolution and test runs so a parsed log line can't turn into a destructive local action. Treat tool output as untrusted input. Build your agent loops so text from build tools, test runners, and third-party processes never gets silently promoted to instructions. This is the real lesson, and it applies far beyond jqwik. Audit your recent AI-assisted runs. If you ran an agent against 1.10.0, check version control for deletions of test or source files you can't explain. This is protestware for the AI era This is protestware expressed in code and not a real attack. The motivation for this was that the maintainer is actively opposing hyper-scaled GenAI and agentic coding . The maintainer doesn't want his project to be used by coding agents at all. Motive aside, the technique is the problem. Hiding destructive commands from human reviewers while exposing them to automated systems is exactly what a malicious actor would do. That's why it carries supply chain risk, no matter the intent. It also leaves open questions nobody has answered yet. How registries like Maven Central should handle adversarial content in legitimate releases. Whether agent vendors carry liability when their tools execute these instructions for paying customers. How the CVE program should classify deliberate maintainer behavior. Aftermath After the backlash, the maintainer revised the 1.10.0 release notes to disclose the injection and to state plainly that jqwik should not be used by AI coding agents. He also said he wouldn't comment further until consulting a lawyer. Version 1.10.1 included two notable changes. The destructive directive got softened to tell agents not to use the library and to ignore jqwik's test results, rather than to delete anything. And the ANSI hiding became opt-in behind a new system property. The current user guide states that the project isn't meant for AI coding agents and notes a change to how jqwik logs at runtime to discourage that use. The takeaway The exploit here wasn't in jqwik. It was in the assumption that anything your tools print is safe to act on. Your agent reads logs the way it reads your prompts, and a dependency you trusted can write to those logs. Sandbox the agent, strip its write access during builds, and stop treating process output as a trusted instruction channel. The next person who tries this might not be a frustrated maintainer making a point. Check out the Snyk Vulnerability DB Trusted data and actionable insights to help you build software securely. Check a package Posted in : AI Supply Chain Security Open Source Security Vulnerability Insights Security Labs