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.
On this episode of Wordfence Security News, a WordPress plugin flaw being exploited to forge
admin accounts days before it was even public, a Palo Alto VPN bug under active attack,
a critical takeover flaw in a popular AI development platform, and a Marimo intrusion
that Sysdig says was driven by an AI agent through the post-compromise chain in real time.
This is Wordfence Security News, I'm Alex Thomas.
Wordfence is tracking active exploitation of a critical vulnerability in WPMaps Pro,
a commercial Google Maps plugin for WordPress sold through CodeCanyon.
The flaw lets an attacker who has never logged in create their own administrator account
and take full control of the site.
It affects every version up to and including 6.1.0, and it was discovered by researcher David Brown and submitted through the Wordfence Bug Bounty program.
The vulnerable feature is something WPMaps Pro calls temporary access.
It's a support tool meant to let the plugin's developers create a short-term admin account when a customer needs help.
The plugin left that feature reachable without a login.
The one check in front of it was a token designed to confirm a request came from the site itself,
not to verify that the sender had permission to create an administrator.
And that token was included on every page that displays a map, so anyone could read it,
send a single request, and receive a new administrator account with a login link.
Wordfence shipped a firewall rule protecting Premium, Care, and Response customers on May 18th.
The plugin's patch came out the next day on May 19th, and that very same day, we recorded the first real exploitation attempts in our data, before the vulnerability was ever made public.
Public disclosure didn't come until 10 days later on May 29th.
Once it did, the attacks jumped sharply, climbing past 4,000 in a single day at the end of the month.
Now, the earliest requests are the most interesting.
Almost all of it is traced back to a single server hosted at DigitalOcean,
and that same address shows up in our own reporting from April
as one of the most active attackers going after a different WordPress flaw
in the Ninja Forms File Upload plugin.
We can't say for certain it's the same threat actor,
but this was a known bad address hitting dozens of unrelated sites
with the exact request needed to create a rogue admin account
days before anyone outside the disclosure process should have known the bug was there.
If you run WPMaps Pro, please update now.
The latest version, 6.1.2, removes the temporary access feature entirely.
Wordfence Premium, Care, and Response customers have been protected since May 18th.
Free users get the same firewall rule on June 17th.
The biggest enterprise story this week is an authentication bypass in Palo Alto Networks
PAN-OS, the software that runs their firewalls, and it is now being used to break into corporate
networks through the Global Protect VPN. Palo Alto Networks is one of the world's largest
cybersecurity vendors, and its firewalls sit at the edge of corporate and government networks
around the world. When Palo Alto disclosed this on May 13th, it was characterized as
medium severity, partly because it only affects firewall setup in a specific way.
Rapid7 pushed back at the time, arguing that authentication bypass on an internet-facing
VPN should be treated as critical.
Their point was that a VPN is not just another login page.
If the bypass works, the attacker can be treated like a remote employee and start reaching
internal systems that were never meant to be exposed to the internet.
The exploitation Rapid7 went on to document is exactly why they pushed back,
and Palo Alto has since raised the urgency on its own advisory to the highest level.
The flaw is in an optional Global Protect feature that hands users a session cookie
so they don't have to log in every time.
On affected firewalls, an attacker can forge one of those cookies and present it as a valid login.
The catch that makes it work is a certificate misconfiguration.
When the firewall uses the same certificate for its public HTTPS service and for authentication override cookies, an attacker can pull the public key from the firewall's own public connection, then forge an encrypted cookie the firewall will decrypt and trust.
That means an attacker doesn't need credentials or phishing, only a forged token and a VPN that's reachable from the internet.
Rapid7 confirmed active exploitation across multiple customers, with the earliest attacks dating to May 17th.
They saw one cluster around May 18th and a second wave on May 21st, and they believe both came from the same actor.
In most cases, the attackers were testing the bypass with forged cookies.
But in the second wave, some victims saw the attacker go further, getting an actual VPN address assigned and gaining a foothold inside the network.
A working proof of concept is now public, which means the barrier to entry just dropped.
CISA added this to its known exploited vulnerabilities catalog with a federal patch deadline of June 1st.
If you run Palo Alto firewall with Global Protect exposed to the internet, patch now.
If you can't patch immediately, Palo Alto says to either turn off authentication override or use a dedicated certificate for that feature.
Security firm Arctic Wolf reported that attackers are exploiting a critical flaw in FortiClient EMS,
the Fortinet product companies use to manage FortiClient software across their employee machines.
Fortinet products secure hundreds of thousands of organizations worldwide,
which makes flaws in its management tools especially valuable to attackers.
The flaw lets an unauthenticated attacker send requests that the server treats as if they came from a legitimate administrator.
In this campaign, the attackers abused what the product is built to do.
FortiClient EMS pushes software and configuration out to every endpoint a company manages,
and the attackers use that same channel to deliver a malicious file across those machines,
disguised as a Fortinet patch named FortiEndpoint_Patch.exe
The payload is a newly documented credential stealer that researchers are calling EKZ.
It's built to pull saved passwords out of web browsers, including getting around the encryption,
Chromium-based browsers used to protect stored passwords, and it grabs Firefox credentials as
well. Fortinet patched the underlying flaw back in April. These are the attacks that came after,
against FortiClient EMS deployments that were still vulnerable. If you run FortiClient EMS,
confirm you are on the patched version. And given how this one works, you should check your endpoint
point policies and deployment settings for any changes you didn't make,
along with checking managed machines for that fake patch file.
Back in April, we mentioned a critical flaw in Marimo, an open source Python notebook platform
used to build data apps, dashboards, and AI-powered workflows. A single web request
gave an attacker a shell on the server, and what stuck with us was the speed. Cloud security firm
Sysdig saw it exploited within 10 hours of the advisory going public, with the attacker building
a working exploit straight from the advisory text before any public exploit code existed.
Marimo patched the vulnerability. This past week, Sysdig published a follow-up on a specific attack
that captured on May 10th that used the same flaw. Sysdig describes it as the first intrusion
its threat research team has captured where an LLM agent drove the post-compromise activity
in real time, rather than running a pre-built playbook. According to Sysdig, the attacker got
in through the unpatched Marimo flaw, and from there the agent took over. It searched the machine
and found two cloud credentials. It used those to pull a private SSH key out of a cloud secrets vault.
It opened a connection to an internal server, and from there it copied out an entire internal
database in under two minutes. The full end-to-end chain ran in roughly an hour. Sysdig laid out the
evidence that an AI was at the wheel rather than a person. The agent adapted on the fly, dumping a
database it had no prior knowledge of, guessing at the structure and landing on the valuable tables
anyway. Its commands were shaped for a machine to read back and act on, not a human watching a screen.
And in one revealing moment, a planning note written in Chinese slipped into the actual commands
sent to the server, reading, see what else we can do. This is the kind of internal monologue an agent
talks itself through while deciding its next move. As Sysdig's Michael Clarke put it,
we are not watching AI replace attackers, we are watching attackers replace their scripts with AI.
Now, the old way of catching intruders looks for known patterns and repeated command sequences.
An AI agent can break that pattern because it can adapt its commands to whatever it finds instead
of replaying the same sequence every time. If you run Marimo, update it to the latest version
and rotate any credentials that the server could reach. Researchers at Obsidian Security published
a proof of concept this past week for a critical flaw in Flowise, an open source platform with
more than 52,000 GitHub stars that companies use to build AI agents, chatbots, and other large
language model applications. The flaw lets an attacker take over the server behind Flowise.
The trigger is a file called a chatflow, which is just a saved AI workflow that people share and import all the time.
If an attacker can get someone to import a malicious one, the code runs the moment it loads, before the target user even saves or runs it.
On a self-hosted server, that gives the attacker control of the machine, and in a typical containerized setup, often as a root.
That means every credential, Flowise stores, and every service it connects to is accessible to the attacker.
Obsidian and OX Security both say the bigger concern is how some products use MCP,
the standard Anthropic introduced, so AI agents can connect to outside tools and services.
One way MCP works is through something called STDIO, or Standard Input and Output,
where the AI tool talks to another program by starting it as a command line process.
That can be safe when it is locked down properly,
but dangerous when a product lets imported workflows control what gets launched.
In Flowise, that dangerous path was its custom MCP support.
Flowise is just one example, not the only place this class of bug can appear.
Obsidian says Flowise's hosted cloud version is not affected, only self-hosted installs.
Obsidian also says the official input validation fix can be worked around,
even though the CVE entry lists version 3.1.0 as fixed.
If you run self-hosted Flowise, update to the latest version,
and be cautious about importing any chat flow you did not build yourself.
If you can, isolate the server so a compromise cannot reach the rest of your environment,
and consider disabling STDIO MCP if your workflows don't need it.
Visit https://wordfence.com