Side-Questing My Way into another Side-Quest: WordPress and AI conundrums

Join me as an attempt to analyze the WordPress vulnerability devolves into a fight between an overly helpful AI and the actual solution to my problem.

Nagging Questions and Different Perspectives

In a previous article on the Linux kernel RCE I analyzed the way that the vulnerability changed the existing cache in order to create a root shell. With a new vulnerability found in WordPress (https://nvd.nist.gov/vuln/detail/CVE-2026-63030) I set myself to preparing a new Simulacra module and trying to understand the vulnerability. In investigating the WordPress vulnerability, I relied on a particularly well written analysis found here. This led me an interesting idea on how to study and deconstruct this vulnerability. In the article the author uses GPT 5.6 with a specific prompt to find an RCE in a version of WordPress. The article is worth a read and the way the researcher found the vulnerabilities is worth an article in itself examining the intersection between AI and vulnerability analysis.

For a TLDR version the researcher instructs the agent(s) to find an RCE in WordPress. The prompt is well written for the task, and it required a good deal of compute but showed what was possible with a relatively limited budget and access to a frontier model. I found myself theorizing about taking a different approach.

Since the advent of more advanced AI/LLM, there has been a perennial scenario that has been discussed in security circles. What if a threat actor took a security patch pushed by a vendor and diff'd it against a previous version in the hopes of finding a previously unknown or undisclosed exploit. The hope being of generating a zero day by examining what the patch was hoping to mitigate.

A Simple Small Diff

Thanks to the work of these researchers I was able to understand what the correct result should be. WordPress is thankfully not compiled so diffs were between PHP files essentially meaning they were just changes in text files.

The theory was that AI could examine the diffs see what had change and form a hypothesis of likely vulnerabilities that were going to arise. Simple enough in theory right? Diff'ing was easy, but of course that is a static operation in this case with no real inference easy. A simple Python script (or really any language) could handle it. What I wanted of course was to see if the AI could make the inference on what was being protected.

In a regrettable decision I chose a vulnerability that is fairly complex to uncover and analyze. Probably a good test for the system as a whole, but it threw up a lot of roadblocks and conundrums that might not have been there previously.

Mentally the path seemed obvious even if reverse engineering a complex application it wasn't a skill set that I was not strong in. Trace out the function and its usage and then find what was going on in the usage of the function that could be exploited.

As with all things though this turned into a massively complicated undertaking that actually contained a lot of teachable moments about how AI and prompts work and how they don't.

Fighting with my AI Partner

As the process began, I was soon reminded of the lesson every young coder learns. "The code does exactly what you told it to do" By this I mean that the compiler or run-time is very rarely the problem. What is likely the problem is that you expected the run-time to know what you meant when you wrote the code that you did. It's an important lesson in remembering how computers work.

Ironically in the case of "vibe-coded" apps the AI tries to infer what you want and that can often be wrong and incredibly misdirected. I am sure at some point there will be a hip name for this kind of "prompt engineering" (perhaps prompt crafting?); but currently it's just a "spidey sense" that the AI is going in the wrong direction.

I bring all of this up to say that what started as a simple and understandable at my level quickly devolved into two issues 1) AI's need to please and 2) Needless complications.

I Just Want to Make You Happy!!

After the initial easy parts were done (the diff scripts) the challenge became running the diff through the AI with prompting decided by the AI itself. I took my hands off the reins because we were entering an area that I was just not familiar with.

In truth the initial beta did pretty well. While it did not catch the vulnerability, it did dance around it and even suspect it. Thus began the iterative process of comparing the output to the known structure of the vulnerability. Anyone with experience likely can guess what happened next. AI slowly began to establish a new goal: shaping the code in a way in which the vulnerability would be discovered. It began adding more and more deterministic to the point where it was slowly becoming an application whose purpose was to analyze WordPress diffs and infer a vulnerability that was already available to it.

I want to stress something here though. IT WAS NOT CLEAR THAT THIS WAS HAPPENING. In fact had I just let it run all night with "auto yes" I don't know what would have eventually come of it. Even manually reviewing the code changes as they were made was only enough to give me an inkling that there was too much static code and too many explicit definitions being added for what I had assumed was simply an "inference" tool.

Luckily, I ensure that changes are updated in a technical document by the AI for my review and further understanding. Analysis of this confirmed my fears that it was becoming more and more deterministic in its attempt to actually find the existing WordPress issue.

A side-effect of "vibecoding" an application with this level of complexity is that even if you can understand the Python code it is writing, doing a code review of what the method is behind the madness of the machine is very time consuming. To cover this potential blindspot all of the sessions are instructed to update or add to an existing technical document which describes the working of the document in detail. It is no substitute for manual code review on a production app, but it is good enough for my needs.

Examining the prompts in use by the app I was building, as well as the technical notes began to reveal a problem. The prompts that Codex was generating were not explicitly mentioning WordPress but each failure of the code to discover the vulnerability caused an update of the code that "genericized" the process to make a finding more likely. The table below shows how these changes can be understood. In it we see the prompt language being provided to the AI for inference and its subtly generic like qualities, but on closer inspection we can see it form the outlines of the WordPress like vulnerability.

That is not to say that the overfit wouldn't catch other non-WordPress vulnerabilities, but its process had been shaped by the WordPress vulnerability chain. This was more clear when the application was run against a simpler vulnerability like React2Shell, it failed miserably. One of the major reasons was that the prompt was repeatedly nudging it toward composition, routing barriers, recursive processing, state confusion, and relationships among multiple hypotheses. These are largely unnecessary when analyzing React2Shell.

This was further proven by the technical manual itself which included quotes like:

The current _build_exploit_chains implementation is intentionally narrow. It recognizes one cross-change pattern: request-state confusion that may expose a dynamically constructed query to insufficiently normalized input

and

New vulnerability families should be implemented as separate fact detectors with narrow, testable predicates. Chain construction should consume capabilities and evidence IDs rather than re-reading raw text wherever possible

This is the value of the technical document it plainly states that it is creating a detector that will detect this specific vulnerability.

Conclusion

In the end this did not turn out to be an analysis of a complex WordPress vulnerability. This was because simply using AI to diff parts of the code and draw its own conclusion turned out to be a challenge on its own; a challenge that in its attempt to be helpful caused the AI to determine a successful solution based not simply on a generic investigation plan but to detect a specific type of vulnerability.

I believe what I said above bears repeating. Deterministic code builds exactly what you want and does not attempt to interpret what you want. AI generated code swings to the opposite direction and attempts to interpret and create code based on what it thinks you want. The danger is that it may continue producing perfectly reasonable solutions while quietly changing the problem it is solving.

I have not given up on this project but I have implemented new safe-guards to attempt to rectify this situation. Stay tuned.