GPT-5.6 found a WordPress RCE for $25. The expensive part came next

On July 20, Searchlight Cyber researcher Adam Kues published a detailed account of CVE-2026-63030, a pre-authentication remote code execution chain affecting recent versions of WordPress. Searchlight also launched wp2shell.com, a tool that site owners can use to check whether an installation is vulnerable. Kues says GPT-5.6 Sol Ultra found the initial SQL injection and then worked out a path from that read-only access to code execution on a default WordPress deployment using MySQL.

The reported model cost was roughly $25. Kues says the run used half of his weekly usage allowance and calculated the figure as a pro-rata share of a $200 subscription. That number is going to carry the story, especially when it is compared with the large sums exploit brokers have historically advertised for WordPress RCEs.

There is a more useful detail in the disclosure, though. Kues says the full exploit took Sol just over 10 hours to produce. The final four hours were the RCE-escalation step, after Kues had already verified the SQL injection. It then took him much longer to understand what the model had constructed, followed by another day untangling it and preparing the report.

The model searched broadly, then a human checked the result

Kues did not simply ask a chatbot to find a WordPress vulnerability. He prepared a copy of the latest stable WordPress source without its Git history, let the model pull in dependency source itself if needed, and told it not to use the internet to look for a patched version. The prompt allowed four agents and required several different research approaches to remain active instead of having every agent follow the first promising lead.

The resulting chain began with a mismatch in the REST API batch-processing path. Under a particular malformed request, validation results and matched route handlers could move out of alignment. That allowed input validated for one route to reach another route and eventually exposed a SQL injection. Sol then found a longer post-exploitation path that used WordPress caching and customization behavior to reach administrator privileges and remote code execution.

This was not accepted on the model's word. Kues tested the SQL injection against a stock WordPress installation, studied the more complicated escalation chain, and reported it through the coordinated disclosure process. The research post also says other researchers independently reproduced the chain before public proof-of-concept code appeared.

That human verification is not a footnote. A plausible exploit description and a reliable exploit against a normal deployment are different things.

The $25 figure leaves out the hard part

The experiment still changes the economics of vulnerability research. A model can read a large codebase for hours, keep several incompatible hypotheses alive, and revisit a path without a researcher manually tracing every branch. Even when most of those paths fail, running them in parallel is now fairly cheap.

But $25 was the estimated model usage, not the total cost of finding and responsibly disclosing the vulnerability. It excludes preparation of the test environment, human review, reproduction, communication with WordPress, patch development, and the operational work required across affected sites.

The Hacker News discussion has largely focused on what this does to the price of zero-days and whether model guardrails should have allowed the request. Those are fair questions. For security teams, the immediate problem is simpler: automated discovery can increase the number of credible findings faster than organizations can validate and fix them.

WordPress sites need the patched version, not an assumption

WordPress released version 7.0.2 on July 17 and identified the remote code execution issue as CVE-2026-63030. WordPress 6.9 is also affected and received the fix in version 6.9.5. The project enabled forced automatic updates because of the severity and recommends updating immediately.

Site owners should still verify the installed version rather than assume the background update completed. Managed hosts, disabled automatic updates, filesystem permissions, or a failed deployment can leave an installation behind. After updating, it is worth checking that the application still works normally and reviewing logs for unexpected REST API or administrator activity during the exposed period.

This case does not show that a model can independently replace a security researcher. In this experiment, searching a large codebase across many possible attack paths became much cheaper. The slower work now sits after discovery, where someone still has to decide whether the finding is real and what to do about it.