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.
[0:02] An AI vulnerability researcher catches a critical authentication bypass
[0:06] in a popular WordPress plugin.
[0:08] A new Microsoft Exchange zero-day is under active exploitation
[0:12] with no patch in sight.
[0:15] A critical authentication bypass hits Cisco's SD-WAN controllers
[0:18] with CISA giving federal agencies just three days to patch.
[0:22] And the Shai-Halud worm we covered last week has been open-sourced on GitHub.
[0:30] This is Wordfence Security News for the week of May 18th, 2026. I'm Alex Thomas.
[0:37] The top WordPress story this week is a critical authentication bypass vulnerability in Burst
[0:43] Statistics, a privacy-focused WordPress analytics plugin with over 200,000 active installations.
[0:50] The vulnerability lets an unauthenticated attacker impersonate an administrator on any
[0:55] REST API request. In a worst-case scenario, an attacker can create a new administrator account
[1:01] on a vulnerable site with no real credentials. The vulnerability was discovered by Wordfence's
[1:06] Chloe Chamberland and PRISM, Wordfence's AI-enabled vulnerability research platform.
[1:12] PRISM identified the bug 15 days after the vulnerable code was first shipped. The vendor
[1:17] shipped a patched version 3.4.2 four days later. The technical flaw is in the plugin's main WP
[1:24] integration. The plugin authentication check accepts a null response from WordPress core as if
[1:30] it were a successful login, which lets an attacker pass the check without ever supplying a valid
[1:36] password. In telemetry from May 13th through the morning of May 21st, Wordfence blocked over 88,000
[1:43] requests targeting this vulnerability across 376 distinct site hosts and 1,637 unique source IP
[1:51] addresses. Peak day was Sunday, May 17th, with over 24,000 block requests. About 61% of those
[1:59] blocks were sites running on a version of Burst Statistics in the advisory's affected range. The
[2:05] rest were older, unaffected versions caught by the Wordfence firewall's extended scope. The mix
[2:11] of rest routes captured in the Wordfence WAF telemetry lines up with how this vulnerability
[2:16] would be abused. Most requests, around 55,000, hit the WordPress core users/me endpoint,
[2:22] which can test whether the bypass worked. We also saw requests to Burst's main wp-auth endpoint
[2:29] and WordPress core's user creation endpoint. This doesn't mean every request was a successful
[2:35] takeover attempt, but the block traffic is clearly focused on the routes that matter for this
[2:40] vulnerability. If you run Burst Statistics Update to version 3.4.2 immediately. Wordfence Premium
[2:47] Care and Response customers have been protected since May 8th. Wordfence free users will receive
[2:52] the same protection on June 7th. The biggest enterprise story this week is a zero-day
[3:00] under active exploitation in Microsoft Exchange, disclosed by the company on May 14th. The
[3:06] The vulnerability is a cross-site scripting flaw in Outlook web access affecting Exchange Server 2016, 2019, and Subscription Edition.
[3:15] Exchange Online is not affected.
[3:17] Almost on cue, two days after a patch Tuesday with no zero days, Microsoft confirmed a new Exchange zero-day was already being used in the wild.
[3:27] The attack starts with an email inbox.
[3:29] An attacker sends a specially crafted email to a target when the recipient opens that message in OWA and performs certain interaction conditions that Microsoft have not publicly described.
[3:42] Attacker-controlled JavaScript executes inside the victim's authenticated OWA session.
[3:47] That can let the attacker access mailbox data or take actions available to that user inside OWA.
[3:54] The attacker does not need a prior foothold in the organization or stolen credentials.
[4:00] As of this recording, there is no permanent patch yet.
[4:03] Microsoft's current guidance is to rely on the Exchange Emergency Mitigation Service,
[4:08] which deploys an automatic URL rewrite mitigation tagged M2.1.x.
[4:14] For environments where the Emergency Mitigation Service cannot reach Microsoft's Update Service,
[4:19] Microsoft is directing admins to the Exchange On-Premises Mitigation Tool.
[4:24] CISA added the vulnerability to its known Exploited Vulnerabilities catalog on May 15th
[4:29] and set a federal remediation deadline of May 29th.
[4:33] If you operate on-premise Exchange Server with OWA exposed to the internet,
[4:38] verify the Emergency Mitigation Service is running and that M2.1.x is applied.
[4:45] The fastest way to check is the Exchange Health Checker script at aka.ms forward slash Exchange Health Checker.
[4:53] Now, Microsoft's Exchange team had an even worse week than the zero-day alone.
[4:58] Over at Pwn2Own Berlin, researcher Orange Tsai of Devcore chained three different Exchange vulnerabilities to achieve remote code execution as system, earning $200,000.
[5:11] That work goes through the zero-day initiative's coordinated disclosure process and is not the same flaw under exploitation.
[5:18] but it reinforces that Exchange is under heavy researcher and attacker scrutiny right now.
[5:24] Continuing with active exploitation this week,
[5:26] Cisco disclosed a maximum severity vulnerability in Catalyst's SD-WAN controller and manager on May 14th.
[5:34] The flaw lives in the peering authentication that Cisco's controllers use to talk to each other.
[5:39] A remote, unauthenticated attacker who can reach the affected surface
[5:43] can abuse the control connection handshake,
[5:46] so the controller treats the session as authenticated, giving the attacker access as an internal high-privileged account.
[5:54] There is no workaround. The only fix is patching to the versions listed in Cisco's advisory.
[6:00] Cisco's SD-WAN controller manages the whole SD-WAN overlay network.
[6:04] With this kind of access, an attacker can modify SD-WAN configurations, push routing changes,
[6:09] and use the controller as a foothold deeper into the SD-WAN environment.
[6:14] Cisco Talos has attributed the active exploitation to a sophisticated attacker they track as UAT-8616,
[6:22] the same cluster behind exploitation of a similar Cisco SD-WAN authentication bypass back in 2023.
[6:30] The group has been observed adding SSH keys, modifying configurations, and escalating to root after gaining access.
[6:37] CISA added the vulnerability to its known exploited vulnerabilities catalog on May 14th under Emergency Directive 2603, giving federal agencies until May 17th to patch.
[6:48] That is a three-day window, which is unusually tight.
[6:51] For private sector teams running Catalyst SD-WAN controller or manager, the guidance is to patch immediately, review control connection output for unfamiliar peers, and check authentication logs for unexpected SSH key additions to the VM manage admin account.
[7:07] This is the sixth Cisco SD-WAN zero-day exploited in 2026 alone.
[7:11] alone. Moving to the broader cybersecurity landscape, researchers at Hidden Layer disclosed
[7:19] a critical pre-authentication remote code execution vulnerability in ChromaDB on May 18th.
[7:26] ChromaDB is an open source vector database, and it is one of the most widely deployed building
[7:32] blocks in modern AI applications, with 13 million downloads per month, and customers including
[7:39] Capital One and United Healthcare featured on its homepage.
[7:43] The bug is in ChromaDB's Python server.
[7:46] When a client creates a collection in ChromaDB, the request can specify which AI model the
[7:51] server should use.
[7:53] The server fetches that model from the public Hugging Face model repository and loads it.
[7:58] The problem is that AI models are not passive data files.
[8:02] Loading one can execute code that ships inside the model package.
[8:06] So if an attacker points the server at a malicious model and passes the right loading options,
[8:11] the server can run attacker-controlled code.
[8:14] That part on its own would already be bad, but ChromaDB is supposed to require a valid
[8:19] login before any of that happens.
[8:22] The vulnerable endpoint does contain an authentication check.
[8:26] However, Hidden Layer found that the check runs in the wrong place.
[8:29] The server loads and runs the model first, and then checks whether the request was authenticated.
[8:35] By the time it rejects an unauthenticated request, the attacker's code has already executed.
[8:41] Hidden Layer first reported this to ChromaDB on February 17th and says it made four contact
[8:46] attempts through different channels with no response.
[8:50] As of Hidden Layer's disclosure, the vulnerability was unpatched in version 1.5.8, and Bleeping
[8:56] Computer reported that it was still unclear whether the latter 1.5.9 release fixed it.
[9:01] HiddenLayer found that 73% of the internet-exposed ChromaDB instances it found through Shodan
[9:07] were running version 1.0.0 or later, the range where the vulnerable feature exists.
[9:13] The interim fix is to switch to ChromaDB's Rust-based deployment, which is not affected,
[9:19] or to restrict network access to the ChromaDB port to trusted clients only.
[9:24] Following up on last week's mini Shai Halud segment, we covered the worm that hijacked
[9:29] TanStack's GitHub Actions pipeline and published 84 malicious package versions. The day after our
[9:35] recording, OpenAI disclosed that two employee devices in its corporate environment had been
[9:41] impacted by that attack. OpenAI said it found no evidence that user data, production systems,
[9:47] or core intellectual property were compromised, but this incident shows the kind of downstream
[9:52] reach the worm was designed for. Then it got worse. TeamPCP published the full source code
[9:59] of the Shai Halud worm on GitHub, with the message Shai Halud open-sourcing the carnage.
[10:06] Is it Vibe-coded? Yes. Does it work? Let the results speak. Change keys and C2 as needed.
[10:13] The repositories included deployment instructions and were quickly removed by GitHub,
[10:18] but multiple forks had already spread. TeamPCP also posted a supply chain challenge on breach
[10:24] forums offering rewards to anyone who used the code to compromise packages. Other actors took
[10:29] TeamPCP up on the offer almost immediately. OX Security reported on May 18th that the first
[10:36] Shai-Halud copycat appeared on NPM in a package called chalk-templet, a typo squat of the popular
[10:43] Chalk Template package. The clone uses the same code without obfuscation, but points to a different
[10:50] command and control server. By May 19th, researchers were warning that copycat activity
[10:56] was accelerating, with new malicious NPM packages already appearing that reused the leaked code.
[11:02] This was not the only NPM trust failed this week. The Node IPC package, a Node.js library with
[11:08] roughly 800,000 weekly downloads, was also compromised after an attacker apparently
[11:14] re-registered a maintainer's expired email domain. Researchers say that likely gave the attacker
[11:20] a path to reset the NPM account and publish malicious versions.
[11:24] Links to all the stories we covered today are in the description.
[11:28] Thanks for watching or listening, and we'll see you next week on Wordfence Security News.