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.
This week on Wordfence Security News. A password reset flaw in Kirki lets unauthenticated attackers
take over administrator accounts. An UpdraftPlus bug turns remote management into remote
code execution. A Check Point VPN zero-day is tied to Qilin ransomware. A Cisco SD-WAN flaw is used
to push rogue configurations to edge devices. And a supply chain worm turns trusted AI coding tools
into credential stealers. This is Wordfence Security News, I'm Alex Thomas.
Our first story this week is a critical flaw in Kirki, a page builder plugin for WordPress that
lets unauthenticated attackers take over the administrator account on a site. The vulnerability
was discovered by researcher CHOIGYEONGMIN through the Wordfence bug bounty program.
The bug is in Kirki's forgot password endpoint.
A normal password reset flow only needs a username.
The site looks up the user and emails the reset link to whatever address that user has on file.
Kirki's endpoint accepts a username and an email in the same request,
and then sends a request link to whichever email the request supplies.
So an attacker who has never logged in can ask the site to send the admin's reset link
to an inbox the attacker controls.
Click the link and set a new admin password.
Kirki patched this into version 6.0.7 on May 18th.
Public disclosure was on June 1st.
Now, our telemetry on this one tells us a story about how fast attackers move once a vulnerability is public.
The first real exploit request we saw came in at 4.22pm UTC on June 1st, 16 hours after the disclosure went live.
The next day, June 2nd, we logged 1143 attacks.
Most of them were aimed at the obvious usernames: admin, administrator, wpadmin, and root.
More than 500 of those exploit requests, roughly one in four, carried what looks like a placeholder email from a public proof of concept, attacker@example.com.
Those particular attempts wouldn't actually take over an account.
Example.com is a reserved documentation domain and not an email domain or tied to any inbox an attacker can read, so the reset link goes nowhere.
But it tells us something about how the attacks ran.
Within hours of public disclosure, it seems like attackers were copying the proof of concept straight out of a public write-up and firing it at sites in bulk, without bothering to swap in their own email address.
If you run Kirki, update to 6.0.7 or later.
Wordfence Premium, Care, and Response customers have had a firewall rule blocking this since May 9th,
more than a week before the patch shipped.
Free users got the same rule on June 8th.
Our second story is a vulnerability in UpdraftPlus,
one of the most widely installed backup plugins for WordPress,
and it's an authentication bypass to remote code execution flaw.
It was reported to the plugin team by the researcher Vtim through the Wordfence Bug Bounty program.
The flaw is in UpdraftPlus' remote management feature, UpdraftCentral.
If a site has ever been connected to UpdraftCentral, either the hosted service at teamupdraft.com or a self-hosted dashboard,
the plugin runs a listener on every page load that's supposed to only accept commands that come signed and encrypted from the dashboard.
The bug is in how it handles the encryption side.
When a message comes in, the listener tries to unlock it with the site's private key.
The attacker can send garbage instead of a real key, and the unlock will fail.
But the code doesn't bother to check the result.
It just hands the broken value into the encryption library.
And that library quietly falls back to a fixed, predictable key that anyone can guess.
All zeros.
The attacker knows that, so the attacker encrypts the command they want to run with that same all zeros key, sends it, and the site decrypts it as if it had come from the real dashboard.
There's a separate signature check too, but it can also be skipped by flipping one field in the request.
From there, the listener runs the command as the administrator who originally connected the site, which means the attacker can install and activate any plugin they want, leading to arbitrary code execution.
UpdraftPlus shipped the patch in version 1.26.5 on June 5th and listed it in the changelog as a
security fix for unauthorized operations on sites with an active UpdraftCentral key. At that point,
there was no public technical write-up, but the patch and security notice were likely enough
of a signal for attackers to start reverse engineering. Wordfence had a firewall rule
in place starting June 3rd, and the first attempts in the wild came five days later on June 8th.
In the first day of attacks, we blocked more than 2,300 requests against 1,768 distinct sites. Almost
all of them came from one IP address. Every single request fit the exploit request shape,
but had the RPC command set to ping. So this appears to be what we'd call a no-op request
that returns success if the site is vulnerable and an error if it's not. In other words, it appears
to be a reconnaissance sweep. It's possible that an attacker is using this technique to map out
which UpdraftPlus installations still have the bug, presumably before coming back with the actual
plug-and-upload payload that drops a shell. If you're on UpdraftPlus and you've ever connected
it to UpdraftCentral, update to 1.26.5 immediately. Wordfence Premium, Care, and
Response customers were protected starting June 3rd. Free users get the rule on July 3rd.
Since we recorded this segment on June 10th, Wordfence Telemetry has confirmed active exploitation
of this UpdraftPlus vulnerability with real malicious payloads. The earliest malicious
requests we observed came roughly six hours after public disclosure, and we're seeing forged
requests that are attempting to upload plugins, deactivate plugins, and create users. On June 12th,
Wordfence updated the firewall rule to ensure adequate coverage for the premium version of
UpdraftPlus, which shares the same plugin slug as the free version, but has a different affected
version range. If you use UpdraftPlus, we urge you to update to version 1.26.5 or later for the
free plugin and 2.26.5 or later for the premium version. Our top enterprise story this week is a
critical authentication bypass in Check Point Remote Access VPN that's being exploited as a
zero-day for a month and at least one of those intrusions has been traced to an affiliate of the
Qilin ransomware gang. Check Point disclosed the vulnerability on June 9th and published hot fixes
the same day. The bug is in how Check Point's VPN handles certificate validation inside the older
IKEv1 Key Exchange, the protocol that negotiates the encrypted tunnel before a user
logs in. On a vulnerable gateway, a remote attacker can establish a working VPN session
without ever presenting valid credentials. Once they're connected, they're inside the corporate
network. The vulnerable configurations are deployments still using IKEv1 without
without machine certificates required on Check Point Remote Access VPN, Mobile Access, and Spark
firewalls.
Check Point's guidance is to apply the hotfix, or if you can't patch immediately, to disable
IKEv1 or enforce machine certificate authentication on the gateway.
According to Check Point, exploitation started on May 7th.
That's more than a month of zero-day activity in the wild before Check Point's public advisory.
Check Point describes the in-the-wild activity as limited.
So far, a few dozen organizations targeted globally with a noticeable uptick in early June.
In one of those intrusions, Check Point confirmed post-compromise activity tied to a Qilin ransomware affiliate.
The other intrusions haven't been publicly attributed.
Qilin is a ransomware-as-a-service operation that first appeared in August 2022 under the name Agenda.
Its affiliates have claimed roughly 400 victims over the past few years across industries from automotive to publishing to pathology labs.
CISA added this CVE to the known Exploited Vulnerabilities catalog on June 8th, a day before Check Point's public advisory went out.
The federal patch deadline is June 11th.
If you run any of the affected Check Point products with internet-facing VPN access and the affected configuration, we urge you to apply the hotfix now.
Our second enterprise story is a zero-day in Cisco Catalyst SD-WAN Manager that's being actively exploited.
Cisco disclosed it on June 5th.
Cisco's own advisory confirms it's been used in the wild to push configuration changes out to edge devices.
Catalyst SD-WAN Manager is the control plane for Cisco SD-WAN fabric.
It's the single dashboard an enterprise uses to push policy, routing, and configuration to every branch router in its wide area network.
If you compromise the SD-WAN manager, you aren't just in control of one appliance.
You're at the control point for every site connected to the fabric.
The bug itself is a command injection in the file upload feature.
An attacker with the right credentials can upload a crafted file that runs commands on the underlying operating system as root.
Every deployment is affected. On-prem, Cisco Managed Cloud, Cloud Pro, and the FedRAMP
authorized government version. Exploitation requires authentication, which sounds like a
high bar, but Cisco's own advisory walks through a realistic attack path, which is chaining this
bug with an earlier authentication bypass in the same product. Cisco has two of them. CVE-2026-20182
is a recent critical authentication bypass that Cisco patched on May 14th.
CVE-2026-20127 is an older bypass that has been exploited as a zero-day since 2023.
Either one gets the attacker in without credentials.
Then, this new bug gets them root, and from root, the rest of the WAN.
The exploitation was reported to Cisco by three Google Mandiant researchers.
Cisco hasn't named the actor and hasn't released a victim count.
But Cisco's wording is specific.
In the cases they've seen, attackers use the bug to push configuration onto edge devices
in the field.
Cisco says there are no workarounds for this vulnerability and customers should upgrade
to the fixed software listed in its advisory.
Cisco also recommends collecting an admin tech bundle before upgrading to preserve possible
indicators of compromise.
then checking the script upload log at var/log/scripts.log for suspicious uploads and verifying edge device configuration.
Google shipped Chrome 149 to the stable channel on June 2nd,
and the security release notes for this version are the longest we've ever seen on a Chrome update.
The new version patches 429 vulnerabilities.
The previous record holder was Chrome 148 at 151, so 149 nearly triples it in a single release.
22 of those are rated critical, roughly 90 are high, and the rest, more than 300, are medium or low.
Google paid out about $208,000 in bounty rewards for the externally reported bugs.
The single biggest check went to one researcher, $97,000 for an out-of-bounds read-write in ANGLE.
Chrome's graphics engine that Google described as carrying a sandbox escape potential.
A second ANGLE bug and a use-after-free in Chrome's network stack rounded out the top three by payout.
Most of the work came from Google itself.
Of the 22 critical CVEs, 19 were found by Google's internal security team.
Three came from external researchers.
Among the roughly 90 high-severity bugs, only about 10 came from the outside.
That ratio is interesting when contrasted against the fact that, in April, Google lowered Chrome's bug bounty payouts.
Security Week raised a question about the size of this release.
How much of the surge is the result of AI-assisted vulnerability discovery?
Google has been publicly investing in AI-driven bug hunting through tools like BigSleep and AI-augmented fuzzing for the past year.
We don't have any official count of how many of the 429 vulnerabilities came from automated or AI-assisted pipelines,
but the timing is notable given Google's public investment in AI-driven bug hunting.
Google didn't flag any of the 429 as exploited in the wild at the time of release.
Chrome will auto-update on Windows, Mac, and Linux.
If you manage Chrome at scale through enterprise policy, we suggest rolling out version 149 this week.
On June 5th, GitHub disabled 73 repositories belonging to Microsoft, including some of Microsoft's most used official tooling.
One of them was Azure functions-action, the GitHub Action that thousands of customers reference in their pipelines to deploy Azure Functions.
The takedowns happened in two waves, completed inside 105 seconds.
seconds. The compromise was the miasma worm, a supply chain campaign that's now reached more
than 113 GitHub repositories across dozens of organizations. What sets this compromise apart
from typical NPM or PyPI supply chain attacks is that the attackers didn't try to sneak malicious
code into a published package. They committed configuration files directly into the repository,
files that get read and executed by the AI coding tools that developers now run in their editors.
In the compromised commit, four files were planted.
A Cloud Code session start hook, an identical hook for Gemini CLI,
a .cursorrules file flagged with always apply,
and a Visual Studio Code tasks file set to auto-run on folder open.
This means the dangerous moment wasn't cloning the repository by itself.
it was opening it in a trusted editor or AI coding tool that honored the committed configuration files.
Once opened, one of those AI tool configurations would trigger the same thing,
a 4.6 megabyte obfuscated JavaScript payload, also committed into the repo,
that scraped credentials for AWS, Azure, Google Cloud, Kubernetes,
and another 90 plus developer tools out of the environment and exfiltrated them.
This particular technique bypasses everything most teams use to defend against supply chain attacks.
There's no malicious dependency to flag or post-install hook on an NPM package,
just a file the developer's AI tool is configured to trust the moment they open the project.
The worm overlaps with code from a threat group called TeamPCP,
which built the original Mini Shai Halud supply chain worm and then open-sourced it.
So Miasma could be TeamPCP, or it could be a separate operator running a forked version.
Either way, this is the second supply chain hit on the same Microsoft team, the Durable
Task Project, in 17 days. StepSecurity tracked the earlier one, a PyPI attack on Durable Task
packages on May 19th. Microsoft's public statement to Bleeping Computer described the
disabled repositories as an internal management issue, and said the company had notified a small
number of customers who may have pulled down content from the affected repositories. The
Register also asked for comment, but didn't get one. If you have CI/CD or development environments
that consume code from Microsoft Azure, Microsoft, or Azure Samples GitHub organizations, you should
check what you pulled in over the last few days and rotate any developer cloud credentials that
touched a Microsoft repo since the start of June.
So what defends against this new vector?
StepSecurity's recommendation is straightforward.
You should treat AI coding tool configuration files the same way you treat any other executable
code committed to a repo.
Don't implicitly trust them and review them for malicious instructions.
Links to all the stories we covered today are in the description.
Thanks for watching or listening, and we'll see you next week on Wordfence Security News.