Last week a security researcher pointed a frontier model at the WordPress source, told it to keep reading for at least six hours, and let it run. It came back with a pre-authentication SQL injection in the batch API that chains all the way to remote code execution. The flaw has been in the code since version 5.6, shipped in 2020, and it sits under something like 500 million installations. Adam Kues at Searchlight Cyber published the writeup on July 20, and it reached the front page of Hacker News the same day.
The number everyone repeated was the cost. Roughly $25 of compute, about half a week on a $200 plan, against the half a million dollars exploit brokers reportedly pay for a WordPress RCE of this class. The gap is dramatic and it makes a good headline. But the price is not the part that has stayed with us. We read code all day for a living, and what we recognized in that report was not a bargain. It was the shape of the work.
The shape of the work
A single bug is one thing. What this model did was assemble a chain out of parts that are individually unremarkable. It found a mismatch between how the batch API validates requests and how it executes them, where the validation loop and the execution loop are batched separately and their indices drift out of alignment. That desync is the foothold. From there it poisoned the in-memory post cache with fabricated rows, used embed processing to reach changeset handling, got a changeset applied while the request was briefly running with administrator privilege, and turned that into code execution through hook manipulation.
None of those pieces lives near the others. The validation logic, the caching layer, the embed handling, the changeset application, the privilege boundary: these are different files, different subsystems, written at different times by different people for different reasons. The work was holding all of them in view at once and noticing that a value fabricated over here becomes trusted over there, and that the trust, three hops later, is enough to run arbitrary code. That is cross-file reasoning over a large, old codebase. It is precisely the thing that used to require an expert who had lived inside a system long enough to carry its seams in their head.
That is why the cost is a distraction. The scarce input in security research was never really the compute. It was the attention. A person who can hold a codebase in their mind and chase a value across five subsystems is rare and expensive and does not scale. What changed is that this kind of reading no longer needs that person to sit and do it. It needs someone to point at the codebase, describe the shape of the search, and pay for a few hours of grinding. The report describes a math-proof-style prompt repurposed for security, up to four agents running in parallel, managed like a small portfolio of leads. The expensive part moved from the reading to the direction.
The symmetry we now live inside
We use this exact capability. When we review a change, refactor a module, or try to understand why a system behaves the way it does, we are doing cross-file reading and chaining our own gadgets. We follow a value from where it enters to where it gets trusted. We look for the place where two subsystems disagree about what is valid. The report reads like a description of our own good days, turned toward a different goal.
There is no version of this where the defensive reading is cheap and easy and the offensive reading stays hard and rare. It is one capability. The same thing that lets an agent notice that our input validation and our execution path disagree is the thing that lets it notice the same disagreement in order to exploit it. We do not get to keep one and refuse the other. So the honest way to hold this is to assume that any codebase we ship, including ours, can be read adversarially for the price of a few coffees by anyone who cares to point an agent at it and wait.
That assumption is not new in kind. Serious teams have always assumed a determined attacker would eventually read their code. What changed is the “determined” and the “eventually.” The determination now costs $25 and the eventually is an afternoon. The threshold that used to filter out all but well-resourced or highly motivated attackers has mostly dissolved. What is left on the other side of it is a much larger set of people with a much smaller reason to bother.
What actually changes in practice
Not as much as the headline suggests, and more than is comfortable. A few things we have taken from it.
The first is that we now assume adversarial reading is cheap and treat it as a baseline condition, not a scenario. When we weigh whether a boundary is strong enough, the question is no longer whether someone would spend a week of expert time to find the gap. It is whether an agent grinding for an afternoon would find it, and the answer for most non-trivial gaps is yes. That pushes us toward defenses that survive being fully understood, rather than ones that merely survive not being looked at closely.
The second is that the same tooling is ours to point inward first. If a frontier model can find a validation-execution desync in our code for $25, we can spend the $25 before anyone else does. This is the cheapest that pre-emptive adversarial reading of our own systems has ever been. We have started treating it as a normal cost of shipping something that matters, the way running the test suite is a normal cost. The reading that can be turned against us is the reading we get to run first, and running it first is now affordable enough that not running it is a choice.
The third is subtler and it is about where skill now sits. The model did not decide to look at WordPress. It did not decide six hours was the right budget, or that a proof-style prompt was the right frame, or that four parallel agents managed as a portfolio was the right structure. A person made all of those calls, and the quality of those calls is most of what separated a useful result from a very expensive way to produce nothing. The grinding got cheap. The direction did not. The scarce skill is no longer the reading itself. It is knowing what to read, how long to let it run, and what a real lead looks like when it surfaces among the noise.
We keep coming back to the fact that a codebase an agent can reason about clearly is a codebase an agent can reason about clearly, and that property is neutral. It helps whoever is reading. The old comfort was that clarity mostly helped the maintainers, because they were the only ones with the time to benefit from it. That comfort is gone. What replaces it is not obscurity, which never worked and works less now, but the discipline of assuming the reading has already happened and building as though the reader was on the other side.