A single specially crafted HTTP request is enough to take complete control of a vulnerable WordPress website. Researchers have already observed real-world exploitation attempts using the new wp2shell exploit, while its entire attack chain was developed by OpenAI’s GPT-5.6 Sol in less than 10 hours.
Johannes B. Ullrich of the SANS Technology Institute has published an analysis of the malicious payload that attackers are already using in the wild. According to him, the exploit has been repeatedly detected against honeypot systems, while the complete payload sample was submitted by a reader of the SANS Internet Storm Center.
The attack relies on a chain of two HTTP POST requests to compromise a website. The first request checks whether the target is vulnerable, while the second delivers the actual exploit. Both requests are sent to the publicly accessible WordPress REST API endpoint /?rest_route=/batch/v1, which can be reached without authentication.
The attackers also make little effort to hide which exploit they are using. Their requests identify themselves with the User-Agent string cve-2026-63030/1.0, directly referencing one of the CVE identifiers that forms part of the wp2shell exploit chain.
To bypass security mechanisms, the exploit uses multiple layers of encoding. Parts of the payload are encoded in hexadecimal, while individual characters are concealed using \x escape sequences. In addition, the nested HTTP requests exploit a WordPress routing confusion flaw, causing the system to process them with incorrect permissions.
The malicious SQL injection is hidden inside the author_exclude parameter. Although WordPress expects this field to contain only numeric author IDs, insufficient input validation allows attackers to inject their own SQL statements.
“The exploit uses standard SQL injection techniques. It leverages a UNION query to execute a second SELECT statement,” Johannes B. Ullrich explained.
During the first request, the SQL injection simply checks whether the target website is vulnerable. If the attack succeeds, the server responds with the marker ||OK||. The attacker then sends a second POST request that writes PHP code directly to the server.
This creates a web shell that provides remote access and allows arbitrary commands to be executed on the compromised system. The attackers save the file as 94uh9ubh6e1x.php inside the /wp-content/cache/ directory.
Interestingly, the web shell is hidden from casual visitors. Accessing the file without the correct secret parameter results in a standard 404 error page.
“I call these ‘Jedi errors’… this is not the page you are looking for,” Ullrich said.
After compromising the site, the attackers also create a new WordPress administrator account to maintain access even if the web shell is removed.
Ullrich advises administrators to inspect the /wp-content/cache/ directory for suspicious PHP files and carefully review any recently created administrator accounts. Applying the latest WordPress security updates remains the primary mitigation. Website owners can also check whether their sites have been affected and assess their current security status.
The origin of the exploit itself has drawn just as much attention. According to Searchlight Cyber security researcher Adam Kues, the complete wp2shell exploit chain was discovered with the help of GPT-5.6 Sol Ultra, the same model family available through ChatGPT.
Kues said he used a $200 subscription and consumed roughly half of his weekly token allowance. Based on that usage, he estimated the total cost of discovering the exploit at around $25, despite the fact that a similar exploit chain could be worth hundreds of thousands of dollars on the exploit broker market.
According to Kues, he did not jailbreak or bypass any of the model’s safeguards. Instead, he simply instructed GPT-5.6 to find a pre-authentication WordPress vulnerability capable of leading to remote code execution (RCE).
“WordPress has been one of the hardest targets for years, and there haven’t been any major pre-authentication RCE vulnerabilities in the past decade,” the researcher said.
He added that the complete exploit chain was developed in just over 10 hours.
“I don’t make sweeping claims, but I can confidently say that no security researcher could have found and completed this exploit chain in 10 hours without artificial intelligence,” Kues concluded.