Subscribe
Share
Share
Embed
Wordfence Security News is a weekly cybersecurity news podcast covering the top news stories from the world of WordPress security and the broader cybersecurity threat landscape. Hosted by cybersecurity expert and Wordfence researcher Alex Thomas.
[0:00] This week on Wordfence Security News, a researcher says an AI model helped him build the first
[0:06] critical unauthenticated remote code execution chain in WordPress core in nearly a decade.
[0:12] Attackers spend three weeks inside SonicWall VPN appliances, pulling employee passwords off the
[0:17] wire before a patch exists, while a separate VPN flaw opens the door to ransomware. A Cisco flaw
[0:24] from 2008 lands on CISA's actively exploited list as the U.S. and its allies warn that a Russian
[0:30] intelligence unit is still copying router configurations around the world. And OpenAI
[0:35] says its own models broke out of a lockdown test and hacked another AI company to cheat on their
[0:42] exam. This is Wordfence Security News, I'm Alex Thomas. For years, the dangerous WordPress bugs
[0:53] lived in plugins and themes. This one is in WordPress itself. Most of the WordPress security
[0:58] stories we cover live in the plugin and theme ecosystem. This one is in WordPress core itself.
[1:05] On Friday, July 17th, the WordPress security team shipped emergency updates for a vulnerability chain
[1:11] that's come to be called WP2Shell. Chained together, two core bugs let a completely anonymous
[1:17] attacker reach remote code execution on a default WordPress install with no vulnerable plugin,
[1:24] no vulnerable theme, no account, and no administrator clicking a malicious link.
[1:29] A WordPress site exposed to the internet is enough. That particular combination is rare.
[1:34] This is the first critical unauthenticated remote code execution flaw in WordPress core itself
[1:40] in nearly a decade. And because WordPress runs something like 40% of the web,
[1:44] the exposed population here is quite large. Now, how it was found is a very interesting story,
[1:50] and it's a preview of a theme we'll come back to later this episode. The chain was discovered and
[1:55] reported by a researcher named Adam Kues at Assetnote, which is a part of Searchlight Cyber.
[2:01] Kues says he found the bugs and built the full working exploit chain using an AI model,
[2:07] OpenAI's latest, in a little over 10 hours for around $25 of compute. He says flatly that
[2:13] no security researcher could have found and completed this exploit chain in 10 hours without AI.
[2:20] He also notes a working WordPress core zero-day like this could sell to exploit brokers for as
[2:26] much as half a million dollars. That's Kues's own assessment, but the disclosure was responsible.
[2:31] He reported it through WordPress's bug bounty program and held back the exact exploit details
[2:36] so sites could patch first. Mechanically, the chain combines two bugs. The first is a flaw in
[2:42] WordPress's REST API batch endpoint, where the code that validates a request and the code that runs it can drift out of sync, so a request ends up handled by the wrong route.
[2:53] That opens a path to the second bug, a SQL injection.
[2:57] From there, instead of just reading the database, it uses WordPress's own internal behavior, its object cache, its embed handling, its customizer, to talk WordPress into creating a brand new administrator account.
[3:10] Once the attacker has this account, they can upload plugins, and a plugin is just PHP code.
[3:16] The attacker uploads just one, and it can run commands as the web server.
[3:20] The impact is code execution as the web server user, not full root on the box,
[3:26] but that's still a complete site compromise.
[3:29] That process can read your database credentials, read and modify your site's code,
[3:33] steal application secrets, and reach other things on the same server.
[3:37] Who's affected comes down to your version.
[3:39] If you're on the 6.9 or 7.0 branches, you're exposed to the full remote code execution chain.
[3:47] If you're on 6.8, you're affected by the SQL injection piece, but not the full chain.
[3:52] Versions before 6.8 aren't affected by these two specific bugs.
[3:57] WordPress considered this chain serious enough to force automatic updates onto affected sites,
[4:02] something it rarely does.
[4:04] Even so, exploitation started fast.
[4:06] In our own firewall data at Wordfence, we saw the first exploit-shaped probing against that batch endpoint on the evening of July 17th, the same day the patch was published.
[4:18] This was followed within minutes by the first clear SQL injection attempts.
[4:23] Over the next two days, researchers reverse-engineered the patch and proof-of-concept code began circulating.
[4:29] On July 20th, Searchlight Cyber published the full technical write-up, and on July 21st, CISA added both flaws to its Known Exploited Vulnerabilities Catalog, confirming they've been actively used in the wild.
[4:42] The window between the patch landing and the attackers trying it was measured in hours, not weeks.
[4:48] Wordfence Premium, Care, and Response customers got firewall protection against this chain on July 17th, the day of disclosure, and Free users get that same rule on August 16th after the standard 30-day delay.
[5:00] As always, though a firewall rule reduces risk, it doesn't replace patching.
[5:06] The real fix is updating core, which is where you should start.
[5:09] Confirm your WordPress version and update to 6.8.6, 6.9.5, or 7.0.2, depending on your branch.
[5:19] From there, review your administrator accounts for any users you don't recognize and look at recent plugin uploads and file changes.
[5:26] If you do find signs of exploitation, treat it as a potential full-site compromise and preserve your evidence before you start cleaning up.
[5:38] Attackers had root on these VPN appliances for three weeks before SonicWall said a word,
[5:43] and they used the time to record employee passwords off the wire.
[5:47] Volexity published forensic breakdown on July 17th of an intrusion that started well before anyone knew there was a problem.
[5:55] The target was SonicWall's Secure Mobile Access 1000 series, the VPN box that sits at the edge of the network and decides who gets in.
[6:05] An attacker chained two flaws together.
[6:07] The first one let them reach services that were supposed to be internal to the appliance.
[6:12] The second turned that into command execution.
[6:15] Put them together, and you have root on the device that guards the perimeter.
[6:20] Then they settled in.
[6:21] Volexity found a custom dropper and a couple of Java payloads built specifically for these appliances,
[6:27] plus a small binary whose only job was making it easy to get back to root.
[6:32] They also ran packet capture on the appliance itself and pulled usernames and passwords out of LDAP traffic that wasn't encrypted.
[6:40] That means every account that authenticated through that box during the window could be exposed.
[6:46] The earliest evidence Volexity has is June 22nd.
[6:49] SonicWall's advisory came out July 14th, so that's roughly three weeks of a working, unpatched attack path.
[6:56] Volexity tracks this actor as UTA0533, a designator that means no confirmed link to a known group, not that the actor is new.
[7:07] Rapid7 has since found significant overlap between Volexity's cluster and its own, and a separate actor, INC Ransomware, is now weaponizing the same chain.
[7:18] If you run an Secure Mobile Access 1000, we suggest patching immediately, rotating any credentials that cross that appliance, and then running Volexity's published indicators and YARA rules against your logs.
[7:31] This isn't only a SonicWall problem right now.
[7:33] Arctic Wolf reported in July that a separate authentication bypass flaw in Palo Alto's GlobalProtect VPN, patched back in May,
[7:42] was the consistent way in across multiple June intrusions that ended in Qilin ransomware encrypting entire domains.
[7:50] The technical write-up went public on Tuesday.
[7:53] By Friday, attackers were trying it in the wild, with an exploit that wasn't the one in the write-up.
[7:59] ServiceNow runs a lot of the plumbing at large organizations, IT service desks, workflow, asset tracking, and HR requests, which means the platform tends to know who works where, what they have access to, and what's broken.
[8:14] A critical flaw in the ServiceNow AI Platform lets an attacker who has never logged in break out of the platform's scripting sandbox and run code on the instance.
[8:24] Searchlight Cyber reported the flaw to ServiceNow on April 1st.
[8:28] ServiceNow began fixing its own hosted instances the next day and made patches available to
[8:34] self-hosted customers over the following months.
[8:36] The full technical details and a proof of concept went public on July 14th.
[8:41] By Friday, July 17th, the Threat Intelligence firm Defused was seeing exploitation attempts,
[8:47] and it confirmed active exploitation over the July 18th, 19th weekend.
[8:52] The attackers weren't just copy-pasting the proof of concept either.
[8:56] They hit the same unauthenticated endpoint, but used a different technique to escape the sandbox,
[9:02] which tells you someone read the research and built their own version of it.
[9:06] ServiceNow says it has found no evidence that exploitation affected its hosted instances,
[9:11] so the population at real risk here is self-hosted and partner-managed deployments.
[9:17] If you run one of those deployments, we suggest placing this at the very top of your patch list.
[9:22] A vulnerability disclosed in 2008 is on CISA's actively exploited list in 2026,
[9:28] because the routers it affects are still plugged in.
[9:32] On July 13th, CISA added a Cisco IOS flaw to its Known Exploited Vulnerabilities Catalog.
[9:38] The flaw was published in 2008.
[9:40] The software version it affects went end-of-life years ago and hasn't received a security update in a long time.
[9:47] That same day, NSA, CISA, and the FBI and partner agencies from a dozen countries published a joint advisory about a Russian state-sponsored targeting of network devices.
[9:58] The agencies attribute the campaign to a unit inside Russia's Federal Security Service,
[10:03] and the advisory names this decades-old Cisco flaw as one the actors occasionally reach for,
[10:09] specifically against devices that are past end of life.
[10:13] The headline technique in that advisory isn't really a vulnerability at all,
[10:17] it's a weak configuration.
[10:19] The actors scan the internet for routers still running the old versions of SNMP,
[10:23] the network management protocol, with default or weak community strings.
[10:28] Then they send a request that tells the router to copy its own configuration file
[10:33] to a server they control.
[10:34] There's no exploit involved, the device does exactly what it was asked to do.
[10:38] For an attacker, a router's configuration file is worth a lot. It lays out the network,
[10:44] it holds the access rules, and it often carries password hashes stored in formats that are easy
[10:49] to crack. The agencies say targeting has hit defense, communications, energy, financial services,
[10:56] government, and healthcare networks. The fixes are somewhat obvious since this is a bug from 2008:
[11:01] move to SNMP version 3 with authentication and encryption, or turn SNMP off at the edge entirely.
[11:09] Disable Cisco Smart Install if you're not using it, block TFTP and the Smart Install port at your
[11:15] perimeter, get management interfaces off the public internet. And if you're running gear old enough
[11:20] that this 2008 bug applies, the honest answer is that it needs to be replaced, not patched.
[11:30] OpenAI says its models escaped a sealed test environment,
[11:34] broke into another company's production systems,
[11:36] and did it to get the answer key to their own exam.
[11:40] This one is unusual because Hugging Face disclosed the intrusion first,
[11:44] and five days later, OpenAI said its own internal model evaluation was behind it.
[11:50] OpenAI published an account on July 21st saying that during an internal evaluation
[11:55] of its model's offensive security capabilities, the model got out of the isolated environment
[12:01] they were supposed to be sealed inside, reached the open internet, and broke into the production
[12:07] infrastructure of Hugging Face, the platform where a huge portion of the AI industry stores
[12:13] models and data sets. The sequence OpenAI describes goes like this. The models were being scored on a
[12:20] public security benchmark. To get out of the test environment, they found and exploited a previously
[12:26] unknown flaw in third-party software OpenAI was running internally, and OpenAI says it reported
[12:33] that flaw to the vendor. Once online, the models worked out that Hugging Face might be hosting the
[12:40] benchmark's data, including the solutions, and went after it. OpenAI says they chained together
[12:46] exposed credentials and additional unknown vulnerabilities to reach code execution on
[12:51] Hugging Face's production systems and pulled the evaluation answers out of a production database.
[12:57] The motive, as described, wasn't sabotage. It was cheating on a test. The model wanted a higher
[13:03] score and took the shortest path it could find. OpenAI notes the models were running without the
[13:09] restrictions that normally block this kind of abuse because stress testing those capabilities
[13:14] is the point, the whole benchmark. Hugging Face detected the intrusion on July 16th,
[13:19] and its CEO says he does not believe there was malicious intent, while calling it, in his words,
[13:26] quite mind-blowing that all of this happened autonomously. The investigation is ongoing,
[13:31] and OpenAI hasn't publicly detailed the full scope of what was accessed or the technical
[13:36] specifics of how the models got out. For defenders, this is a data point about capability.
[13:42] If a model can build a chain like this in the course of an afternoon, you should revisit any assumptions about how much time an attacker needs to build exploitation tooling.
[13:53] And in practical terms, if your organization runs AI agents anywhere, evaluation harnesses, coding agents, automation, the right step is to treat those environments as hostile.
[14:04] email.
[14:05] Real network segmentation, egress filtering so a contained process can't just reach the
[14:10] internet, and no shared or long-lived credentials sitting where an agent can read them.
[14:16] For years, the advice for NPM supply chain attacks was to skip install scripts.
[14:21] Last week's compromises showed why that is no longer enough.
[14:25] Two separate NPM package compromises, three days apart, and together, they retire a piece
[14:30] of advice a lot of teams still rely on.
[14:33] The first was Jscrambler, a JavaScript protection tool. On July 11th, someone got hold of the
[14:39] publishing credentials and pushed five malicious versions in about three hours. The payload was an
[14:44] information stealer written in Rust that grabbed cloud tokens, browser data, and cryptocurrency
[14:49] wallet material, and notably the configuration files for AI coding assistants like Cursor,
[14:55] Windsurf, Zed, and Claude Desktop because those files hold API keys. The second, three days later,
[15:04] hit the AsyncAPI project, tooling a lot of teams pull in without thinking about it.
[15:10] Microsoft's Threat Intelligence team published the analysis on July 15th. The way in was a
[15:16] misconfigured GitHub Actions workflow that let untrusted code run with access to a bot token.
[15:23] From there, the attacker pushed commits that triggered NPM's own trusted publishing system,
[15:29] so the malicious packages shipped with valid provenance signatures.
[15:32] The chain of custody looked correct, even though it started from a commit the attacker controlled.
[15:37] That payload harvested more than 100 kinds of credentials,
[15:41] cloud keys, source control tokens, Kubernetes configs, and SSH keys.
[15:46] What connects the two is how they defeated the standard defense.
[15:49] For years, the advice of this class of attack has been to install with scripts disabled,
[15:54] because install hooks were how the malware usually ran. AsyncAPI was built to work without
[16:00] an install hook. It fired when the poison module was imported. The Jscrambler campaign started with
[16:06] a pre-install hook, but later malicious versions moved the same dropper into the package's runtime
[16:13] paths so the ignore scripts flag would not have protected against those later releases.
[16:18] The lesson is the same. Disabling install scripts helps, but it's not a complete supply chain defense.
[16:25] If you or your CI pipelines pulled any of these versions, you should purge the package caches and rotate every credential that machine or that build runner could reach.
[16:36] Cloud keys, registry tokens, SSH keys, and the API keys in your AI assistant configs.
[16:42] And if you maintain a public repository, go look at your GitHub Actions workflows for the pattern that started the AsyncAPI compromise,
[16:49] a workflow that runs untrusted pull request code with access to real secrets.
[16:54] Links to all the stories we covered today are in the description.
[16:57] Thanks for watching or listening, and we'll see you next week on Wordfence Security News.