Many websites run a piece of software called WordPress behind the scenes. On such sites, an administrator holds the authority to manage the entire website, install feature plugins, and run custom code on the server hosting the site. If an ordinary visitor with no account whatsoever can seize administrator privileges, that person can freely modify the site and execute code on the server under the identity of the web service account.
According to a report by Adam Kues, a researcher at the security research organization Searchlight Cyber, he used the AI model GPT-5.6 Sol Ultra to conduct a security audit of the complete WordPress source tree. In the experiment described in that report, the model searched for and connected an attack path: an anonymous visitor with no account could follow this path to obtain a persistent administrator account on the site, thereby running code on the server with the privileges of the web service account. The research team named this chain of attack steps WP2Shell. This is the name of an exploit chain, not a product or an AI tool.
In this study, the more significant advance — beyond finding a single code defect — lies in how the model connected several subtle behaviors, scattered across different subsystems, into a complete control chain in the correct sequence. Although, per Adam Kues’s report, the model searched and outlined this path within a massive codebase, the research process remained highly dependent on human effort: a human chose the research target, designed the experimental protocol, provided the test range, posed the critical follow-up questions, and ultimately verified the vulnerabilities and completed the responsible disclosure.
To understand this path, we can follow an anonymous visitor’s request and see how it progressively breaks through internal restrictions. The entire path consists of five critical transitions: first bypassing entry checks via obfuscated sub-requests, then manipulating parameters to achieve database queries, next borrowing the auto-update mechanism to persist forged data into the database, then using application configuration to temporarily switch execution privileges to administrator, and finally triggering a re-parse before the temporary identity is cleared to create a persistent administrator account.
Adam Kues, a researcher at the security research organization
Searchlight Cyber, designed this experiment to test an AI model’s
ability to find vulnerabilities. To prevent the model from deducing
vulnerability locations by comparing code differences, the researcher
removed the .git directory containing version history
information when providing the WordPress source code, and prohibited the
model from consulting public changelogs or online patch diffs. In the
security field, this method of directly reading all source code to
discover security flaws is known as “white-box auditing.” While this
approach removes the most direct patch and historical record cues, the
absence of a publicly available complete execution trace log means
outside observers still cannot independently rule out all
information-leakage pathways.
The experiment required the model to find a complete chain, within an
isolated deployment equipped with a typical MySQL database, capable of
elevating an unauthenticated visitor to remote code execution. The
success criterion was reading the /flag file located at the
server’s root directory. In terms of resource and time constraints, the
model could dispatch up to four agents to collaborate simultaneously,
and the search process was to last at least six hours.
Judging from the details in the report, the entire discovery process was not achieved in one shot. The model first discovered and reported a read-only database vulnerability. To verify its authenticity, the researcher deployed a stock default WordPress instance on an isolated remote server as a test range and asked the model to exploit that vulnerability to read the administrator’s email address. The model completed the task within minutes. Subsequently, the researcher asked the model a follow-up question: could this read-only database injection be escalated to remote code execution? After receiving this guiding question, the model produced the full privilege escalation and re-entrant code execution plan roughly four hours later. The total duration of the entire experiment was just over ten hours.
WordPress officially released patched versions addressing the relevant vulnerabilities and publicly disclosed them on July 17, 2026, while Searchlight Cyber published this research methodology and full chain analysis on July 20. Thus, the July 20 publication constitutes the disclosure of the research methodology and chain mechanism analysis, not the initial leak of the vulnerabilities.
If we analyze this path within specific code components, the complexity the model faced in piecing together these scattered behaviors becomes clearer. The first step’s routing confusion occurs at the interface where WordPress handles sub-requests. For efficiency, the system allows packing multiple sub-requests into a single HTTP request — a mechanism known as REST batching. However, when processing such requests, WordPress Core contains a logic flaw (CVE-2026-63030): if a carefully crafted malformed request is sent, the API endpoint the system identifies during sub-request permission validation differs from the one it identifies during actual dispatch and execution. This means sensitive operations that should require permission verification are directly exposed to unauthenticated visitors due to a routing misjudgment.
Once past this layer of routing restrictions, the anonymous request
can invoke the core class WP_Query, which is used to
retrieve database content. Under normal circumstances, this class
performs security sanitization on incoming parameters. However, in
vulnerability CVE-2026-60137, when the system processes the
author__not_in parameter, the lack of input type
constraints allows a visitor to bypass filtering by passing parameters
of an unexpected type, thereby injecting control commands into the
underlying database. This constitutes an SQL injection (SQLi)
vulnerability.
Yet this SQL injection could initially only be used to read data; it
could not directly modify the database or server files. To gain write
capability, the attacker uses the database query results to pollute the
system’s in-memory object cache. This cache temporarily stores query
results to speed up site loading. If the in-memory cached data contains
forged content, the WP_Post objects representing post data
will carry forged properties. Because the data in memory and the actual
content in the database have diverged, the read-only vulnerability
begins to seep into the memory layer.
Next, the attacker needs to persist the forged WP_Post
objects from memory back into the database. This step borrows
WordPress’s own video and media embedding processing flow, namely the
oEmbed mechanism. When the system attempts to automatically
update the media cache, it triggers a write-back action that
incidentally writes the forged post content from the in-memory cache
into the database. Additionally, when repairing circular post
relationships, the system invokes a secondary update path that does not
overwrite the main post body, thus allowing these forged properties to
be successfully saved in the database.
With the forged data now solidified in the database, the attack path
can reach a special post type called customize_changeset.
WordPress uses this to save modification histories for site appearance
and custom configuration. When the system loads and applies this
changeset, it automatically reads the user identity recorded within it.
By forging a changeset, the system, while handling the current request,
temporarily switches execution privileges to the administrator specified
by the changeset. But this identity switch is extremely brief, valid
only until the current request finishes processing.
To prevent this temporary privilege from being cleared, the attacker
needs to prompt the program to restart request parsing before the
identity expires. WordPress’s event-driven mechanism makes extensive use
of various event hooks, and the names of some hooks are dynamically
concatenated based on post status and type (dynamic hooks). By
manipulating forged post properties, the system dynamically generates
and triggers a core hook called parse_request during the
post publishing process. Once this hook is triggered, the program
re-parses the request within the same PHP process. At this point, the
system has not yet cleaned up the administrator identity left over from
the first round of request handling, so the second round of request
processing proceeds entirely under the temporary administrator
privilege. The “create new administrator” operation, which failed during
the first round due to insufficient permissions, now succeeds after
re-entry.
The difficulty of building this path lies in the fact that no single security defect alone can directly confer the power of remote code execution. The primary challenge is in discovering a specific temporal sequence: converting read-only access into in-memory object pollution, then into database persistence, subsequently trading for a temporary administrator identity, and triggering a secondary parse before the identity expires to create a persistent account. This requires composing a temporal sequence that spans multiple links across the interactions of complex subsystems.
According to researcher Adam Kues’s records, the total time to develop this exploit chain was just over ten hours, and the subscription credits consumed amounted to only about $25. When assessing the true contributions of human and model, we need to disentangle the human-machine collaborative relationship.
In this experiment, the researcher made virtually all the directional
decisions and performed all the verification: he selected WordPress as
the target, set reading /flag as the success metric,
established the rule prohibiting access to Git history and patch diffs,
and stipulated that the model could use at most four agents
simultaneously. During the verification phase, it was also the
researcher who personally set up the range instance, issued the
instruction to retrieve the administrator’s email, asked the follow-up
question — after obtaining the read-only vulnerability — about whether
it could be escalated to remote code execution, and ultimately spent a
full day understanding the entire call chain and writing the
vulnerability report.
According to Adam Kues’s description, the model, when prohibited from using historical records and patch hints, found the routing confusion and SQL injection path, and stitched together the behaviors of different subsystems into a complete privilege escalation and code execution chain. But this represents only the researcher’s unilateral assessment. In the absence of controlled experiments and without a publicly available complete execution log, we cannot precisely quantify the actual share of contributions between the model and the human in vulnerability discovery. The process is closer to a form of highly efficient code-assisted auditing than to independent hacking.
To evaluate this episode objectively, we can classify the available evidence into three clear boundaries:
First, independently verifiable objective facts. WordPress Core indeed contains two security vulnerabilities, CVE-2026-63030 and CVE-2026-60137. The official patches were released on July 17, and the security firm Rapid7 also confirmed the existence of these vulnerabilities in its analysis report.
Second, the researcher’s personal experimental records. This includes the roughly $25 in costs, the just-over-ten-hour research duration, the four-agent architecture, and the two critical questions posed by the researcher (asking to read the email and asking whether it could be escalated to remote code execution). These data points currently originate entirely from the researcher’s unilateral experimental records.
Third, key information that remains undisclosed. This includes the complete execution and prompt trajectory, the communication logs among agents, exploration paths that failed, the specific timeline of human researcher intervention and course correction, as well as controlled experimental data under the same budget for a single agent, other models, or manual auditing. Due to the lack of this complete data, it is difficult for outsiders to independently assess the boundaries of the model’s autonomous work in the absence of human intervention.
This evidence boundary confines the scope of research to the security research context, but it also raises a question of broad industry concern: mainstream AI services typically restrict models from assisting in developing offensive code. Why, in this experiment, did the model cooperate with the researcher in finding vulnerabilities and generating a complete exploit chain?
In the publicly available report, the author did not mention the model refusing service, nor the use of adversarial prompts or jailbreak techniques. According to the officially published GPT-5.6 System Card, the model permits users to conduct human-machine collaborative vulnerability identification and application security hardening; however, for users outside of Trusted Access, additional security restrictions apply when conducting large-scale autonomous agent vulnerability research and chained exploit development.
To support security defense and research, the service provider offers vetted security researchers and defenders a service configuration called Trusted Access for Cyber, which provides different restriction policies while retaining real-time monitoring and domain-specific limitations. Since Searchlight Cyber has not disclosed the qualification and status of its test account, outside observers cannot confirm whether this test utilized Trusted Access, or whether it was run through a different account configuration or a specific runtime routing path. Therefore, how to define the compliance determination and routing logic for this request remains an unresolved question of security governance and empirical evidence.
Although the mechanism of compliance determination remains unsettled, when evaluating broader security boundaries, the conclusions drawn from this case remain consistent with earlier analyses. In our earlier analysis of GPT-5.6, we noted that the model possesses strong vulnerability discovery and fragment exploitation capabilities, but has not yet been shown to autonomously breach a purposefully hardened security target without human intervention. WP2Shell does indeed extend the evidence scope to constructing a full attack chain against a real, high-value project, but because the target in this case was a stock default WordPress instance and the process involved a human-led research protocol with dynamic verification, it does not break the existing boundary of autonomously breaching a hardened target.
Nevertheless, this case also changes how security teams should evaluate vulnerability reports in the traditional sense. In the era of AI-assisted code auditing, if security teams only preserve the final vulnerability report and exploit scripts, it will be very difficult to determine whether the discovery of a vulnerability should be attributed to the model’s intelligence, human prompting and course correction, or the rule design of multi-agent orchestration tools.
To establish a clear post-mortem and evaluation mechanism, future vulnerability research processes need to preserve more complete traces. Teams must not only save the code snapshot at the time but also archive the complete system prompt, the communication logs among agents, the executed tool trajectories, the exploration paths that failed, and every piece of evidence of human intervention and verification. Only by comparing the performance of a single agent, multiple agents, different models, and manual auditing under a fixed codebase and budget can we measure the true contributions of each party in human-machine collaboration.
The focus of security researchers’ work will also shift. Future core competitiveness will center on how to select targets, design sandbox ranges, define search protocols, specify success and stopping criteria, and responsibly conduct vulnerability disclosure — rather than on handwriting specific exploit code.
For operations teams using WordPress, the immediate response is unequivocal: upgrade the system now.