A technical deep dive into wp2shell

Hackers are exploiting critical vulnerabilities in WordPress, ServiceNow and SonicWall turning trusted websites, cloud platforms and VPN appliances into pathways for administrator access, remote code execution and malware deployment.

In this cybersecurity news episode, we break down a WordPress exploit chain involving route confusion and SQL injection, a ServiceNow pre-authentication sandbox escape, and SonicWall SMA1000 zero-days used to gain root access and install custom Java malware.

Learn how attackers abuse server-side request forgery, command injection, sandbox escapes, WebSocket tunnelling, Java instrumentation agents, webshells and memory-resident malware. We also explain why broken trust boundaries, exposed internal services and weak validation between system components create such dangerous attack paths.

This technical cyber threat analysis is designed for cybersecurity professionals, students, ethical hackers and anyone studying penetration testing, vulnerability research, incident response, malware analysis, network security or cloud security.

Thanks for listening.

Follow the podcast for more cyber security news, malware analysis, threat intelligence, AI security, and real-world attacker tradecraft.

For contact or story tips, email: cyberinvestigationsau@gmail.com

Disclaimer: This podcast is for education and awareness only. Technical details are shared to help defenders improve detection, response, and security controls.

Transcript

SPEAKER_00 0:05

Welcome back to the podcast. This week, three major security stories have been demonstrating the same dangerous principles. And those are systems are often compromised not because every security control fails, but because two components disagree about where trust begins. Let's quickly jump into story one this week. And this has been all over InfoSec News. And that is WordPress to shell. Whenever you hear the phrase two shell, you know that something is bad. I'm thinking about last year's React2 Shell. The year before there was something similarly worded, I'm forgetting what exactly what it was. This week we got WordPress 2 shell or WP2 shell. So what's happened here? WordPress has released an emergency security update for two vulnerabilities tracked as CV2026 60137 and CVE 2026 63030. The first is a SQL injection vulnerability. Yes, a SQL injection vulnerability can still dish out serious damage. The second is a route confusion vulnerability in the WordPress REST API batch endpoint. So let's dive into the technical concepts of what's actually happening here and why these two vulnerabilities are so severe. Individually, each bug has limitations. Chained together, however, they allow an unauthenticated attacker to progress from a normal internet request to administrator level control and remote code execution on a default WordPress installation. This is basically as bad as it gets. No vulnerable plugin is even required. No malicious theme is required. The attacker does not even need an existing account. This is why it's called preauth RCE. To understand the chain, we first need to understand the WordPress batch API. The endpoint at I will say it, but it's better you type it out. Allows a client to bundle several REST requests inside one HTTP post. WordPress processes each subrequest through several stages. It then passes the request. It identifies the matching route handler, it validates the parameters against the route's schema, it runs the route's permission callback, and finally it dispatches the request to the hand the handler. You don't really need to worry about those technical details too much, but what's important is that internally WordPress maintained separate arrays containing the requests, their validation results, and their matched route handlers. So those arrays were supposed to remain aligned by index. Request zero should correspond to validation results zero and handler zero. Request one should correspond to validation results one and handler one. Right. But when WordPress encountered a malformed subrequest, it added an error to one array and then continued processing without adding a corresponding entry to the matched handler array. That created a off by one state management problem. I know we're getting a bit technical here, but just bear with me. You'll quickly see the magic of what's going hap happening here and and why this is such a serious vulnerability. So after that off-by-one state management problem has arisen, the problem here is that the code could validate one request against a relatively harmless route, but later dispatch it through a different, more privileged handler, right? So in other words, the security decision and the eventual operation were no longer referring to the same object. So this is not really a traditional authentication bypass where the application simply forgets to check whether the user is logged in. It is closer to a confused deputy problem. The batch processor performs validation, but applies that validation result in the wrong subrequest. That confusion exposes the second vulnerability inside WordPress underscore query. And this is where things start to get interesting. So WordPress underscore query, or you would type it wp underscore query, is one of the core WordPress classes in the code used to retrieve posts from the database. One of its parameters, you would type it out as author underscore not underscore in, is supposed to contain a list of numeric authors, uh sorry, author identifiers to exclude. That normally means converting the supplied values through a strict integer passing function before inserting them into a database query. So for the developers out there, input sanitation. This is good security practices when programming 101. Whatever a user puts inside a text box, that needs to be checked. So what happened in the case of WordPress, the affected code sanitized into a separate class, which was called, as mentioned, author underscore not underscore in, when it arrived as an array, but not correctly when it arrived as a string. I know I'm getting quite technical here, but I think this is very important to understand what actually happened. So just bear with me, we're almost finished with the technical components. So that distinction matters between the distinction between it arriving in array but not in a string, matters because PHP is dynamically typed. WordPress, of course, being written in PHP. A parameter that developers conceptually treat as a quote unquote a list of integers can still arrive as a string unless the application enforces the type at the trust boundary. The string could consequentially reach SQL query construction without the expected integer conversion, creating a SQL injection primitive. On its own, the vulnerability query was not necessarily reachable by completely anonymous users or attackers, but the batch root confusion allowed a potential attacker to smuggle an unvalidated string into the vulnerable query path. One bug provided reachability, the other provided database query manipulation. Early exploit variants extracted password hashes from the WordPress database. Attackers could then attempt to crack a weak administrator password offline before logging in normally. More advanced variants did not need to crack a password. Researchers have found paths that used the application's own database behavior to create a new malicious administrator account. And once an attacker becomes a WordPress administrator, remote code execution is almost a built-in capability. Administrators can install plugins, and a WordPress plugin is executable PHP code. So what this means, an attacker can therefore upload a fake plugin containing a PHP web shell. Every request to that web shell can pass an OS command to PHP functions, such as shell underscore exec, giving the attacker command execution under the web service account. The scary part is attackers observed in the wild also created backdoor administrator accounts, exfiltrated credentials and secrets, installed malicious plugins, and attempted to deploy additional remote access tooling. Researchers reported tens of thousands of exploit attempts and more than two dozen public proof of concept implementations appearing within days of disclosure. Okay. Let's take a step back, folks. I know we've gotten quite in depth. You are a true engineer if you've stuck through all of that. I think of course the defensive lesson here is that patching closes the vulnerability, but does not remove an existing compromise, right? WordPress 6.8 users should be on 6.86, WordPress 69 users should be on 6.95. Administrators must also inspect recently created users, installed plugins, modified PHP files, passwords, and API secrets should be rotated if SQL injection or database access is suspected. If you're a WordPress site admin, and I know many people probably are, you've got some patching to get to. Let's quickly move on to story two. That WordPress story, I read the Searchlight Cyber write-up of that. And it seems that Searchlight Cyber has come in clutch again with a ServiceNow vulnerability. This story involves CVE tracking as 2026 6875, a pre-authentication, remote code execution vulnerability affecting ServiceNow. ServiceNow is all over. All over large corporations, which is what could make this one fairly disastrous. So let's get into the technical details of it. The vulnerability began with GlideRecord. This is ServiceNow's programmatic interface for querying platform tables. So how it works is that instead of developers constructing raw SQL, scripts create a quote unquote glide record, add conditions to our service now to execute the query. MariaDB may sit underneath the platform, but the scripts interact with ServiceNow's query-based query abstraction. The problem was that certain glide records, query values, could begin with the prefix JavaScript colon. So what this meant was that ServiceNow would evaluate the JavaScript expression and use its result as the value for the database condition. Researchers identified unauthenticated pages where an attacker controlled HTTP parameter flowed into a glide record.addQuery. That gave the attacker server-side JavaScript execution before authentication. ServiceNow had anticipated that filters might contain JavaScript, so it executed this code inside a restricted environment called GlideSystem Sandbox. Inside that sandbox, dangerous functionality was blocked. This is good code practice, sanitizing user input. Table access was restricted. Again, good. Powerful Java classes were unavailable. Function declarations were rejected, and direct use of eval or the JavaScript function constructor was prohibited. That should have limited the attacker to relatively harmless expressions. But what is interesting, one permitted capability was made it through the cracks. And that is JS include cut. Script includes are reusable ServiceNow libraries. Right? So when a script calls js.include, ServiceNow loads and evaluates a trusted library in a different execution context. Here is the hierarchical problem. Attacker controlled code was sandboxed, but the included library needed broader privileges to work properly. Therefore, the security boundary depended on sandbox code being unable to influence how the trusted include executed. So it looks like researchers discovered that JavaScript objects and functions in the shared global environment could be manipulated before loading the trusted quote unquote include. This is sometimes called prototype clobbering or global namespace poisoning. The attacker did not directly call the prohibited function constructor. Instead, they changed references used by a trusted script include so that during the quote unquote include process, a normal helper operation resolves to the function constructor. Again, I know we're getting quite technical here, but it's quite important to understand these technical details so we can really make good risk-based assessments of what's actually going on in the crazy world of cyber. So just to finalize these technical details, I think there's one more important component to add. When ServiceNow loaded the trusted library, the unsandboxed quote unquote include effectively assembled a new JavaScript function from the attacker string. The trusted code became a gadget that performed a forbidden operation on the attacker's behalf. This resembles return oriented programming.

SPEAKER_01 15:32

At a conceptual level. This resembles return oriented programming at a conceptual level.

SPEAKER_00 15:50

Or ROP, if you're a developer and familiar with that terminology. In ROP, an attacker chains pieces of existing code because injecting new executable code is difficult. Here the researchers chained legitimate JavaScript framework behaviors to produce an operation the sandbox explicitly prohibited. The sandbox checked what the attacker called directly. It did not fully account for the trusted code, might be called indirectly after the attacker altered its dependencies. Escaping into the main quote unquote Rhino JavaScript environment had serious consequences. And this is where the destruction really happened. The attacker could access ServiceNow tables, create administrative accounts, and interact with powerful glide classes. Researchers also found that compromised ServiceNow instances could execute commands through configured mid-servers. So for users that aren't familiar, a mid-server is a ServiceNow component commonly deployed inside corporate networks so that the cloud platform can communicate with internal systems or connectivity to on-prem infrastructure. That makes this more than a SaaS account compromise problem. A vulnerable internet-facing ServiceNow instance could potentially become a bridge into a private network infrastructure. The searchlight cyber reported the vulnerability on the 1st of April 2026, which is a while ago. ServiceNow deployed initial mitigations to hosted cloud instances with 24 hours and subsequently patched the underlying issue, which is good to hear. ServiceNow seems to have also introduced tighter, quote unquote, guarded script restrictions that limit sandbox expressions by blocking assignments, control flow, so on and so forth. I think the larger lesson is that sandboxes must constrain both direct capabilities and indirect influences. I think that's a quick a clear takeaway. You know, if you ask me, designers m must also examine shared mutable objects, callbacks, reflections, script loading mechanisms. Developers will understand what I'm talking about there in order to implement a more privileged interpreter context. I think that those are all the main stories in cyber kicking off the first half of this week. We've definitely got technical today. I think hopefully people find that useful. I know a lot of people know the headlines, but may not necessarily know the technical details involved in a lot of these malicious attacks. So I hope that you enjoyed the podcast. Leave a like and a comment. It all does really help. See you next time.