Groundzero Now Generates and Tests AI Security Patches
Project Groundzero now generates and rigorously validates security patches with AI, testing each repair against working exploits before it earns trust.
Groundzero now moves from finding to fixing
We built Project Groundzero to test security claims against running software. It gave us a place to run real vulnerabilities, contain the blast radius, and keep the evidence.
We have expanded Groundzero to generate security patches with AI and test those patches before we trust them. It now provides a repeatable path from a confirmed vulnerability to a tested repair.
An AI agent reads the advisory and vulnerable source, finds the affected code, and writes a repair. Groundzero then builds the package, runs a working exploit, checks the repaired version, runs the project's normal tests, and preserves the full result.
The patch is only the beginning. Confidence comes from watching what happens after it is applied. The first CVE below is our first published proof point for this new Groundzero capability.
The first published result found a patch survivor
The first complete run used CVE-2023-42282 in the npm ip package. The vulnerable function was commonly used to decide whether an address was public or private before allowing a network request.
Groundzero gave the advisory and vulnerable source to the AI agent. The agent produced a patch without seeing the upstream fix, and Groundzero locked that patch before continuing.
The upstream fix then grounded the rest of the run. It showed which code the maintainer changed and gave Groundzero a known source transition to test and reverse. From there, the system searched for different ways to express the same private address and found three working attack forms.
The published fix blocked two. The third wrote the private address 172.20.0.2 as the decimal number 2886991874. That form still passed the public-address check and reached the private service. The patch generated by our AI agent blocked all three forms and passed the package's existing tests. The relevant part of the upstream change was small:
The decimal form slipped past the condition around normalization. Groundzero found it by running the code, rather than trying to decide from the diff alone.
Evidence status
This is a measured result across three attack forms and the tests available in the project. It gives the patch specific evidence without turning a limited test set into a universal claim.
The Groundzero remediation loop
Groundzero turns patching into a repeatable loop around evidence. Each pass uses a working attack to put more pressure on the repair.
- Start from a confirmed case. Groundzero rebuilds the affected software from the advisory and source repository.
- Generate our patch. The AI agent reads the advisory and vulnerable source, writes a repair, and Groundzero locks it.
- Prove the attack. Groundzero searches for working exploits and accepts only inputs that produce the real security effect.
- Attack the repair. The verified exploits and nearby variations run against our generated patch.
- Check the application. The project's normal tests make sure the repair has not broken expected behavior.
- Preserve the result. The source, patch, attacks, observations, test results, and model transcript leave together in a replayable bundle.
- Run the loop again. A surviving attack or failed application test becomes evidence for the next repair.
When an upstream fix exists, Groundzero uses it to confirm the affected code and establish the vulnerable, fixed, and reversed behavior. Our patch is generated and locked before that upstream change enters the run.
This makes the maintainer's work a grounding point inside the loop. The purpose of the loop is to produce and pressure-test our own repair.
What rigorous testing means here
A working exploit has to do more than make the target print a success message. Groundzero watches the security effect from outside the software under test.
For a private-network bypass, a separate service records whether the target reached it. For command execution, a separate beacon records whether the command ran. The target cannot award itself a passing result.
The same attack then moves through four versions of the source. Together, they separate a real repair from a build that simply stopped working:
Evidence status
Reversing the upstream fix gives the run an important check. If the effect returns, Groundzero can connect the behavior to the exact source change. If a package fails to build, a module stops loading, or the observer becomes unreliable, the run ends as inconclusive. Those failures never count as a successful patch.
Finally, the evidence can be run again without another model call. Groundzero verifies the saved files and can rebuild the source states in Docker to repeat the measurements.
AI gives us speed; the lab gives us discipline
AI is valuable here because vulnerability work rarely arrives in a neat format. The agent can move through an unfamiliar repository, connect an advisory to the relevant code, draft a repair, and search for attack variations quickly.
Our early work also showed how easy it is to overestimate that ability. When an advisory named the vulnerable function and mechanism, the agent often found familiar bugs on its first attempt. Removing those clues caused success to fall sharply on a harder case.
That experience shaped the division of responsibility. AI explores and proposes. Groundzero controls the execution and records what happened. The rule from the original lab still applies:
Agents can propose. Evidence decides.
The runs that stop are part of the evidence
Some runs have ended without a verified exploit. One package exposed an API shape Groundzero could not yet call faithfully. Another passed a supplied hostname through DNS before reaching the vulnerable command, and the injection attempt was rejected before execution. A third case started from a version where the effect we were measuring was already blocked.
Groundzero preserved each outcome and stopped. These results show where the current system needs a broader way to call software, a controlled prerequisite such as local DNS, or a better vulnerability coordinate.
That restraint is part of how the system earns credibility. A run can succeed, fail, or remain inconclusive. Every result keeps the reason attached.
A working pipeline for everyday remediation
The core loop works. AI can generate an independent patch, Groundzero can find and verify working attacks, every repair can face the same evidence, and the completed run can be replayed without calling the model again.
The node-ip case is the first published CVE result from that complete path. Command-execution measurement is also proven in controlled cases and is being added to the same end-to-end patch flow.
The Groundzero expansion is in place. Our work now is scaling its coverage: more package ecosystems, more ways to exercise public APIs, controlled supporting services, better discovery of project tests, and intake that can begin directly from a newly disclosed advisory.
We have committed Groundzero to this direction. Each new class earns its place through a real positive case, a clean stop when evidence is unavailable, tests against the measurement itself, and a run that can be replayed from beginning to end. That rigor is how we scale the working pipeline into daily operation.
The common footing
Groundzero began as the place where Emphere tested whether its security product could see what it claimed to see. It now gives us a repeatable path from a confirmed vulnerability to a tested repair.
We can now use AI to generate our own exploits and patches. Groundzero gives that work a controlled source, a working attack, normal application tests, and evidence that survives the session. This is Groundzero's new role: use AI for speed and give every generated patch a clear record of why it deserves confidence.