We mostly write here about how autonomous testing works, and where it stops. This one is a field note: the same agent harness we run against customers' own apps, pointed for the first time at a live program on Intigriti, a public bug bounty platform. On its first day it found and proved a remote code execution bug. The program rated it exceptional and paid a €3,000 bounty. The payout is public on our researcher profile.
We are writing it down because it is the honest test of the whole idea. Inside a customer's workspace the agent is told what to look at. A public program is a cold target with real researchers already on it, a scope document, and no hints. If the approach only works when we choose the target, it does not really work.
What it found
The target, an analytics instance, exposed a developer tool that should never have faced the internet: a component playground, left reachable without authentication. That playground took input from the browser and compiled it into server-side templates. Our harness noticed that a value it controlled was being turned into code the server would run, built a request that closed the template and added its own expression, and got the server to execute it. No login, no credentials.
The underlying weakness is now public as CVE-2026-8467, a code-injection flaw in the Phoenix Storybook playground (it is fixed in version 1.1.0). The chain, end to end, is short and unglamorous, which is exactly why it is dangerous:
- A debug surface was deployed to production and left unauthenticated.
- That surface compiled attacker-controlled input into templates.
- The templates ran with no sandbox, so the input became code.
There is no SQL step, no privilege dance, no second bug to reach the first. It is one exposed surface that trusts the wrong input, and that is the most common shape of a serious finding: not an exotic technique, but a forgotten door.
Why this is the part that matters
A scanner can flag "an admin or debug panel is reachable." That is a lead. What it cannot do is cross the gap between reachable and exploitable — build the one request that proves the panel will run attacker code, and nothing more. That gap is where most "potential criticals" quietly die as false positives, and it is the gap the agent has to cross on its own to earn a rating like this one.
It crossed it the same way it does in a normal run: it read how the surface behaved, formed a hypothesis about where the trust was misplaced, and only kept the result once it had a working request and the server's response to show for it. The bounty is a proof that held up to someone else's review, on a target we did not pick.
What we are taking from it
One finding is one finding. It does not tell us the agent is better than the researchers who work these programs every day, and we are not going to pretend it does. What it tells us is narrower and more useful: the loop that finds proven bugs in a customer's app finds them in the wild too, against a scope it has never seen, with the proof standing up to an external reviewer.
We will keep running it on public programs, and we will keep writing the results down here, the quiet days as well as this one. If you want the same loop pointed at your own app instead of a cold target, that is what Vulnix is: a pentest that ends with a working exploit, not a list of maybes.
