I am not a full-time security researcher. I run a WordPress hosting company. During my day I patch websites, clean up malware, and spend a lot of my time pointing AI agents at things I want to automate. So I am both overjoyed and a bit at a loss for words that this is my story.
This month Wordfence paid me $15,600 for an unauthenticated remote code execution bug in Elementor Pro. As far as I can tell, that is the largest publicly disclosed single-finding payout from their bug bounty program.
I was not trying to break a bounty record. I was attempting to see whether I could direct AI agents to turn real security research into real findings. Spoiler: it did.
This story starts with a WordPress core RCE, not Elementor.
Searchlight Cyber published wp2shell: pre-authentication remote code execution in WordPress core. No plugins required. Stock install. This is the holy grail of WordPress security findings.
I knew right away this was not a lucky find. It was some combination of amazing cybersecurity research and AI. I knew that because I personally wasn’t able to recreate the proof of concept, even with a super powerful AI.
I fed the public CVE material into my AI agents and asked them to build a working exploit. They struggled. The chain was so deep and so well hidden that nothing useful came out of the honest path. I only was able to verify the exploit by letting Claude Code “cheat” and read someone else’s exploit.
That is how well hidden the core finding was. I do not believe a human would have found that bug without AI assistance. Not in any reasonable amount of time. The code path was not sitting in an obvious place. It was a chain.
A few days later Searchlight published the full story of how they found it with GPT-5.6 Sol Ultra. That post rewired my brain. They had not just used AI. They had directed it like a research team: multi-agent search, approach families, hours of pressure, no changelog cheating. I wanted to try something in that spirit on WordPress plugins.
I tried to copy their methods. I burned a lot of GPT-5.6 Sol doing it.
I immediately wanted to recreate how they hunted. Not the WordPress core exploit itself. The method. Long AI agent runs. Parallel approaches. First-principles reading. Not a simple “find vulns in this plugin” prompt.
I burned through the equivalent of a few weeks of ChatGPT Sol Ultra usage in a few days, helped by some timely usage resets. The models found things. Some of them were even real reports. Nothing that big. Plenty of mediums. Almost nothing that survived a clean proof-of-concept which felt worth a bounty.
I nearly gave up but then decided to doubled down. Go big or go home, right?
Instead of hunting forever in the open ocean of every random plugin on WordPress.org, I decided to raise the stakes. Take the chain-hunting idea from the core discovery, turn it into a real audit skill, and aim it at the biggest WordPress plugins. High install counts. Heavy prior attention. Commercial products people assume are already picked clean.
That skill became /wp-registry-scan-chain. It mines findings I already have in WP Registry, pairs delivery primitives with sinks, and fans out subagents to prove or kill the chain. Most chains die. A rigorous “no chain” is a win. The occasional real chain is why the skill exists.
Elementor Pro is about as high-value as WordPress plugins get. Commercial. Everywhere. Heavily scanned. The kind of codebase where people assume the critical bugs are gone.
Ironically, I was not even on the latest Opus. My Sol usage was spent. So I ran the long audit on Claude Opus 4.8 against a local zip of Elementor Pro 4.2.0.
A few hours later… it found something huge.
One Claude Code session. The day before Opus 5 shipped.
The whole finding lives in a single Claude Code session on July 24, 2026. Model: claude-opus-4-8. Ironically, that was the day before Anthropic released Opus 5.0. My Command Center still has the full transcript.
Session id e7f63854-b5b9-4cf5-86d3-768c6ff40e25. Started as a slash command. Ended with a Wordfence submission receipt. I was not pair-programming line by line for two hours. I was directing.
The session was short because the loop was already built.
Two hours sounds fast until you notice what was already standing behind that slash command. The chain skill. The proof-of-concept scaffolder. SandyWP for a public disposable verify. Fleet management for real-world prevalence. WP Registry for tracking. Wordfence disclosure worksheets. I was not inventing process in the moment. I was steering a machine I had already built.
/wp-registry-scan-chain against Elementor Pro 4.2.0. Five parallel chain hypotheses. One critical emerges: unauthenticated RCE.Claude filled the Wordfence form. I reviewed and sent it.
The filing was not a separate session or a hand-typed research report. It was the same Opus 4.8 Claude Code session that found the bug.
Once the finding was proven on a clean site, Claude scaffolded the Wordfence package:
- A disclosure worksheet with the fields Wordfence expects
- A DevTools console script that auto-fills their Vue submit form
- The required demo video
- The supporting evidence Wordfence asks researchers to include
Wordfence asks whether you used AI. The filler answered Yes and named the tools: Claude Code (Claude Opus 4.8). The model did the heavy lifting. I directed it.
What stayed manual on purpose:
- Signing into wordfence.com as a registered researcher
- Pasting the filler into the browser console and reviewing every field
- Attaching the video (the script never attaches files)
- Ticking the exclusivity agreement and clicking Submit
Upon submission I pasted the Wordfence receipt back into the session so the registry could record the report and stop resurfacing the same bug.
I will leave the technicals to the experts.
This post is not a PoC or a walkthrough on how the exploit works. Again, I am host WordPress sites full-time and am just the guy who directed AI at just the right time and got paid for a real finding. The people who should document the bug class, the patch, and the defensive guidance are the ones coordinating disclosure.
If Wordfence publishes an official post on this Elementor Pro issue, that is the place for the technical detail. I will link it here:
What I will say, it was an unauthenticated remote code execution finding in Elementor Pro, found by hunting a chain rather than a single loud sink. Delivery plus sink. That is the wp2shell lesson applied to a high-value plugin. Unlike the WordPress core chain, this was not a labyrinth of gadgets. It was a small validation bug on a public form path that turned into unauthenticated RCE once you asked the chain question.
Same lesson. Very different levels of complexity.
| Dimension | WordPress core (wp2shell) | Elementor Pro (this bounty) |
|---|---|---|
| What made it critical | A long multi-stage chain across core subsystems | A short delivery-plus-sink chain in one plugin surface |
| How hard to invent | Extremely. Many independent pieces had to fit | Moderate. The root cause is small once you look in the right place |
| How hard to prove | Hard. I could not rebuild it without reading the published solution | Straightforward once found. Clean site, control run, exploit run, done |
| Default install? | Yes. Stock WordPress | No. Needs a published form with a file upload field |
| What AI was good for | Discovering and chaining obscure core gadgets | Hunting high-value targets with a chain mindset at code scale |
| Why it still matters | Proved AI-directed research can crack the hardest target in the ecosystem | Proved the same method pays on commercial plugins people assume are already clean |
These AI models are crazy smart. We just have to aim them.
Here is the breakdown of what I actually did in that Claude Code session.
I read real research and turned it into a skill. I chose high-value targets instead of endless long-tail grinding. I forced empirical proof on a clean site. I asked for fleet prevalence. I decided Wordfence exclusivity. I pasted Claude’s console filler into Wordfence myself and hit submit.
Opus 4.8 read a commercial plugin, ran five parallel chain theories, discarded four, kept one, verified the chain on a clean site, wrote the Wordfence worksheet and console filler, disclosed AI usage on the form, and survived my “prove it on SandyWP” demand. That is expert-grade security work at machine speed.
Same general goal. Worse results. Trying to recreate Searchlight’s method without enough aim. No “go big” filter. No forced runtime proof discipline early enough. The model family was not the only variable. The operating system around the model was.
Previously scanned codebases are not finished. They are waiting for better questions.
Elementor Pro has been through years of human audits, automated scanners, and bug bounty attention. Wordfence alone has published a long history of Elementor and Elementor Pro CVEs. The interesting part is not that another bug existed. The interesting part is that the winning chain sat under findings that looked low until someone asked the chain question.
I think that is the new default. Frontier models are now good enough to do work that used to require a specialized security researcher, as long as a human feeds them the right research ideas, forces proof, and aims them at targets worth the tokens. AI paired with smart humans will keep finding new discoveries in codebases everybody already scanned.
If you want the research that unlocked this specific find, read wp2shell and the Sol Ultra writeup. We are entering the age of AI where all of the biggest security findings are going to be found by AI.