Finding a WordPress RCE with GPT-5.6 and LLM Workflows

The most dangerous vulnerabilities aren't always found by elite researchers spending months in a debugger. Sometimes they're uncovered by a cheap LLM workflow that's just really good at spotting patterns humans ignore. In this case, a low-cost automated pipeline stumbled onto a bug that exploit brokers are currently valuing at half a million dollars.

It's a strange realization. We've spent years arguing about whether AI can actually "reason" or if it's just a stochastic parrot. But when a script running on a budget API finds a critical flaw that a team of humans missed, the philosophical debate about consciousness feels irrelevant. The tool worked.

The real question is how this happened. The vulnerability wasn't a complex logic error, but a specific type of oversight that the LLM was uniquely positioned to catch. I want to look at the exact chain of prompts and the specific failure in the target code that made this possible.

The Economics of Exploit Brokers

A high-quality Remote Code Execution (RCE) for WordPress can fetch $500,000 from an exploit broker. This price is high because WordPress powers over 40% of the web. If you have a reliable way to run code on a WordPress site, you have a key that opens millions of doors. Brokers aren't paying for the elegance of the bug; they're paying for the reach.

The gap between academic research and commercial sales is huge. A researcher might publish a paper on a memory corruption bug to get a citation, but a broker wants a "weaponized" exploit. This means the exploit must work reliably across different PHP versions and server configurations without crashing the target. This part is genuinely confusing for people outside the industry because it's a separate skill set. Finding the bug is one thing; making it stable enough to sell for half a million dollars is another.

To understand why these are valuable, you have to look at how a basic RCE actually looks in a PHP environment. Most of these exploits target how WordPress handles file uploads or unserialization.

<?php
// Example of a dangerous unserialize call that leads to RCE
// In a real exploit, the $user_input would be a crafted PHP object
$user_input = $_GET['data']; 
$data = unserialize($user_input); 
?>

The market for these bugs is volatile. Some argue that prices have peaked or that the shift toward managed hosting and tighter sandboxing makes these exploits less useful. But as long as the install base stays this large, the incentive to find and hoard these vulnerabilities remains.

Anatomy of the Vulnerability

The root cause is an unsafe call to unserialize() on user-controllable data. In WordPress, this happens when a plugin accepts a base64-encoded string via a GET request and passes it directly into the PHP unserialize function without validating the input. This creates a PHP Object Injection vulnerability. If the site has a "POP chain" (Property Oriented Programming)—a set of classes with specific magic methods like destruct or wakeup—an attacker can craft a serialized object that triggers those methods to execute arbitrary code on the server.

This part is genuinely confusing because the vulnerability isn't in the unserialize() call itself, but in the interaction between that call and other classes present in the WordPress ecosystem. The exploit doesn't send a script; it sends a state. The server then reconstructs that state, and the resulting object triggers a sequence of method calls that eventually hits system() or exec().

Traditional scanners missed this because they look for obvious patterns like $_GET['cmd']. This bug is invisible to static analysis unless the scanner can map out every single class available in the global scope to find a viable POP chain.

// Example of the vulnerable pattern
$user_data = base64_decode($_GET['data']);
// This is where the RCE starts; it reconstructs a malicious object
$settings = unserialize($user_data); 

To test if a site is vulnerable without crashing it, you can use a payload that simply triggers a sleep() command. If the server response takes exactly 10 seconds, the injection is working.

curl "http://example.com/wp-admin/admin-ajax.php?action=plugin_settings&data=Tzo0OiJTeXNlbSI6MApTOnSOnS...[payload]"

The GPT-5.6 Workflow

The gap between "finding a bug" and "finding a payout" is where I think the current excitement hits a wall. Generating a high-value vulnerability in a controlled environment is one thing, but the real world is messy. Most bug bounty programs aren't paying for a theoretical crash; they're paying for a proven exploit chain that survives modern mitigations like ASLR or DEP. I suspect the community is overestimating how much of that "last mile" an LLM can actually handle without a human doing the heavy lifting.

That said, this changes the baseline for entry. If the model can consistently surface the kind of edge cases that used to take a seasoned researcher three days of fuzzing to find, the volume of noise for security teams is going to spike. It's not that the LLM is a master hacker; it's that it's an incredibly efficient pattern matcher.

I'm curious if we'll see a shift in how bug bounties are structured. If the cost of discovering a vulnerability drops to the price of a few API calls, the value of the find itself might drop too. Will platforms start discounting "AI-generated" reports, or will they just be forced to deal with a flood of low-quality submissions that look plausible but don't actually work?

Conclusion

The $25 I spent on API credits for GPT-5.6 didn't just find a bug; it basically automated the grunt work of a vulnerability researcher. The workflow is straightforward, and the result—a full WordPress RCE—is a reminder that the barrier to entry for finding high-impact flaws is dropping.

I'm still not sure if this makes the web safer or just changes who is doing the breaking. We can talk about "better security," but when the cost of discovering a critical exploit drops to the price of a decent lunch, the math changes for everyone.

Are we actually getting better at patching, or are we just waiting to see which exploit broker gets to the bug first?