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, another trusted WordPress update channel
[0:04] delivers a backdoored plugin, this time affecting Uncanny Automator Pro.
[0:09] Splunk Enterprise is exploited in the wild.
[0:12] Fortinet customers face active sandbox attacks and a large credential exposure
[0:17] campaign. An AI gateway flaw puts provider keys at risk.
[0:22] And malicious JetBrains plugins steal the API keys powering developers' AI tools.
[0:30] This is Wordfence Security News. I'm Alex Thomas.
[0:36] A trusted WordPress vendor update channel was compromised,
[0:40] delivering a backdoor version of Uncanny Automator Pro to licensed customer sites.
[0:44] Last week, we reported on two WordPress supply chain compromises,
[0:49] one where attackers pushed backdoored code through ShapedPlugin's commercial update channel,
[0:54] and another where AwesomeMotive brands serve tampered JavaScript from a vendor-controlled CDN.
[1:00] This week, the same theme continues with Uncanny Automator Pro.
[1:04] Uncanny Automator is a workflow automation plugin for WordPress.
[1:08] Site owners use it to connect different plugins, apps, memberships, forms, courses, stores, webhooks, and other actions together.
[1:17] So one event on the site can trigger another.
[1:21] The free version is on WordPress.org, and the paid pro version gets updates through Uncanny's own license update infrastructure.
[1:29] On June 15th, Uncanny Automator disclosed that an attacker had compromised part of its infrastructure on June 12th.
[1:36] According to the company, the attacker exploited a vulnerability in third-party software running on AutomatorPlugin.com.
[1:42] From there, the attacker reached two sensitive parts of the business, the store and licensing system, and the server that distributes Uncanny Automator Pro updates.
[1:52] The customer data side of the incident exposed names, email addresses,
[1:57] Uncanny Automator license keys, and the website URLs associated with those licenses.
[2:02] Uncanny says no credit card data was involved because payments are handled by Stripe and PayPal,
[2:07] and account passwords were not exposed in usable form because they were stored as cryptographic hashes.
[2:14] As a precaution, the company reset all account passwords.
[2:24] For a limited window, Uncanny's update server distributed a backdoor build of Uncanny Automator
[2:30] Pro version 7.3.0.5. Licensed sites that checked for an update during that window could download
[2:39] the tampered package directly from the vendor's own update infrastructure. Uncanny says the
[2:44] tampered build was available from about 6.30 p.m. Eastern on June 12th until 4 p.m. on June 13th.
[2:51] The company says fewer than 6% of sites received the compromised version, and Uncanny Automator
[2:58] Lite, the free version on WordPress.org, was not affected.
[3:01] If a site did install the compromised 7.3.0.5 build, Uncanny is very direct about the impact.
[3:09] That site contains malware and a backdoor and should be treated as compromised.
[3:13] Updating over the top is not enough.
[3:16] Removing and reinstalling the plugin may not be enough either, because the attacker's
[3:20] code may have already created persistence elsewhere on the site. Uncanny says it removed
[3:26] the attacker's access on June 13th, removed the tampered build, published a verified clean 7.3.0.6
[3:34] release, rotated credentials and keys the attacker could have reached, and contacted affected
[3:39] customers directly using its download logs. Now, there's also an obvious and unanswered question
[3:45] about the root cause because of what we covered last week.
[3:49] In the AwesomeMotive incident, the company said the attacker used the critical UpdraftPlus
[3:54] vulnerability to compromise a separate marketing website server, found a CDN API
[3:59] key, and used that key to tamper with JavaScript, serve to OptinMonster, TrustPulse, and Push
[4:06] Engage sites.
[4:07] That UpdraftPlus flaw was submitted through the WordPress Bug Bounty program, patched
[4:12] quickly by the UpdraftPlus team and allows unauthenticated attackers to run remote procedure
[4:18] calls as the connected administrator on sites that have been connected to UpdraftCentral.
[4:23] For Uncanny Automator, the company has not publicly named the third-party software that
[4:27] was exploited, so we don't want to state that this was also UpdraftPlus unless that is confirmed.
[4:34] But given the timing and given the AwesomeMotive incident, it is one of the key questions
[4:39] defenders and incident responders in the WordPress ecosystem will be asking.
[4:44] If you're on Uncanny Automator Pro, check your installed version.
[4:47] If you're on 7.3.0.5 or if your site updated during the June 12th to June 13th exposure window,
[4:56] follow Uncanny's remediation guidance and treat the site as compromised.
[5:00] Update to the clean 7.3.0.6 release or later, scan the files on disk,
[5:06] check for unexpected administrator accounts, review scheduled tasks and database changes,
[5:12] and rotate credentials that may have been exposed. The Repository, an independent news outlet
[5:17] reporting on WordPress, also reports that Monster Insights customers were targeted with phishing
[5:23] emails during the same broader incident window. Those emails pushed a fake Monster Insights 10.3.0
[5:30] security update, cited a fake CVE, and sent users to a typo squatted domain. Monster Insights has
[5:37] about 2 million active installations, so even if the phishing messages were caught by spam filters
[5:42] in some cases, the attempt shows how quickly attackers can pivot from a successful compromise
[5:48] into campaigns that leverage the stolen data from that compromise. So for Uncanny Automator customers,
[5:54] be especially cautious with email right now.
[5:57] Because names, email addresses, license keys, and website URLs were accessed,
[6:02] phishing messages could look very convincing.
[6:08] A critical Splunk Enterprise vulnerability has moved from advisory to active exploitation,
[6:13] raising the stakes for organizations running affected versions.
[6:16] Our top enterprise story this week is a critical flaw in Splunk Enterprise
[6:20] that is now being exploited in the wild.
[6:22] Splunk is the logging and security analytics platform a lot of companies use to collect what's happening across their network in real time.
[6:30] For example, firewall events, server logs, authentication records, endpoint alerts, and cloud activity.
[6:37] In a lot of environments, Splunk is where blue teams and IT build dashboards, alerts, and investigate operational or security issues all from a single location.
[6:47] So a critical vulnerability in Splunk is especially problematic because it's in a tool that defenders depend on to know what happened in their environment.
[6:55] The vulnerability affects Splunk Enterprise 10.0 and 10.2 releases before the fixed versions.
[7:02] Splunk Enterprise 9.4 and earlier are not affected.
[7:05] And Splunk Cloud is not affected because Splunk says Cloud does not use the vulnerable PostgreSQL sidecar.
[7:12] The flaw is in that PostgreSQL sidecar service.
[7:14] A sidecar is basically a companion service that runs alongside the main application.
[7:20] In this case, the problem is that the sidecar endpoint was missing authentication controls.
[7:25] That means an attacker who can reach the vulnerable service over the network can invoke file operations without logging in.
[7:32] Splunk's advisory describes the direct impact as arbitrary file creation and file truncation.
[7:37] In other words, an unauthenticated attacker can create files on the Splunk server or wipe existing files down to zero bytes.
[7:46] Now, that's pretty serious by itself, but on a system like Splunk, file access can become much more than just file access.
[7:54] If an attacker can write to the right location, they may be able to plant code, tamper with configurations, or interfere with the data that defending teams rely on.
[8:03] Splunk published the advisory on June 10th. On June 18th, the company updated it to say its
[8:09] product security team had become aware of limited exploitation of the vulnerability.
[8:14] CISA also added the flaw to its Known Exploited Vulnerabilities catalog the same day.
[8:18] The main condition for exploitability here is reachability. The attacker does need network
[8:24] access to the vulnerable Splunk service, so if that service is exposed to an untrusted network,
[8:29] the risk goes up exponentially. Splunk's guidance is straightforward. Upgrade Splunk
[8:35] Enterprise to version 10.4.0, 10.2.4, or 10.0.7 or later. If you can't upgrade immediately,
[8:44] Splunk says you can disable the PostgreSQL sidecar service as a mitigation by setting
[8:50] PostgreSQL to disabled in the local server configuration and restarting Splunk.
[8:55] Fortinet customers are facing two separate risks at once.
[8:59] Exploitation attempts against recently patched FortiSandbox flaws
[9:02] and a large credential exposure campaign affecting Fortinet devices.
[9:07] FortiSandbox, Fortinet's malware analysis platform,
[9:10] is built to detonate suspicious files and URLs in an isolated environment
[9:14] before they reach the rest of the network.
[9:17] And now, attackers appear to be going after FortiSandbox itself.
[9:20] Researchers at Defused Cyber say their honeypots observed exploitation attempts against three recently patched FortiSandbox vulnerabilities, a path traversal in the jRPC API, and two OS command injection flaws.
[9:34] The first two were patched by Fortinet in April. The third was patched in Fortinet's June updates.
[9:40] The most recent one, an OS command injection dubbed CVE-2026-25089, lets remote attackers send crafted HTTP requests to the FortiSandbox web interface and execute commands on the system.
[9:55] The other two bugs expand the attack path around FortiSandbox web interface and privilege boundaries.
[10:00] When combined, if an attacker can reach the vulnerable appliance, they may be able to move from the outside web interface towards code execution or deeper control over a security system sitting inside the environment.
[10:14] Now, a sandbox appliance should be isolated.
[10:17] That's the whole point.
[10:18] It handles suspicious files and URLs that may be malicious.
[10:21] But that doesn't necessarily make it low risk.
[10:24] It's still a trusted security appliance, and it's built specifically to process hostile content.
[10:30] If attackers can compromise the appliance itself, they may not be gaining access to just one server, but rather a server defenders use to safely analyze malware.
[10:39] Fortinet has patches available for all three vulnerabilities.
[10:43] If you run FortiSandbox and haven't updated yet, treat this as urgent scheduled maintenance, especially if the web interface is reachable from an untrusted network.
[10:53] And this week, Fortinet customers got a second warning from a different direction.
[10:56] CISA issued an alert about a credential exposure campaign being called FortiBleed.
[11:02] This isn't a new Fortinet vulnerability, but rather a credential problem at a very large scale.
[11:07] CISA says malicious actors have targeted internet-accessible Fortinet devices using compromised credentials.
[11:13] RecordedFuture says the dataset reportedly includes administrative and SSL VPN credentials
[11:19] for 73,932 FortiGate firewall URLs across 194 countries and more than 21,600 domains.
[11:29] CISA's advice for FortiBleed is straightforward.
[11:32] Terminate active SSL VPN and administrative sessions.
[11:35] Reset credentials.
[11:37] Enforce phishing-resistant multi-factor authentication where possible.
[11:41] Review account activity.
[11:43] And make sure management interfaces are not exposed to the public internet.
[11:50] An actively exploited LiteLLM command injection vulnerability could expose the systems and
[11:55] keys behind enterprise AI gateway deployments.
[11:59] A lot of companies are starting to put an AI gateway between their applications and
[12:03] the model providers they use.
[12:05] That gateway might hold the OpenAI key, the Anthropic key, the Azure OpenAI key, routing
[12:11] rules, usage controls, and whatever policy decides which app is allowed to call which
[12:17] model.
[12:17] That makes it convenient. It also means that if the gateway gets compromised, the attacker may not need to break every AI application one by one.
[12:26] They may already be standing in the place where all of those applications meet.
[12:30] That's a concern behind an actively exploited vulnerability in LiteLLM, an open source AI gateway used to route requests across different large language model providers.
[12:40] CISA added it to the Known Exploited Vulnerabilities catalog on June 8th,
[12:45] which means exploitation has been observed in the wild.
[12:48] CISA describes it as an authenticated command injection vulnerability.
[12:52] The bug is tied to LiteLLM's Model Context Protocol test endpoints.
[12:56] MCP is the mechanism that lets AI systems connect out to tools and external services.
[13:02] LiteLLM included test endpoints that let a user check whether an MCP server connection worked.
[13:08] A user could provide a configuration object that included the command used to launch an MCP server.
[13:14] If an attacker had access to a LiteLLM proxy key, even a low-privilege one,
[13:21] they could supply their own command and have LiteLLM run it on the underlying operating system of the target server.
[13:28] These target servers may have access to provider API keys, service tokens, routing rules, internal configuration,
[13:35] information, usage logs, and whatever credentials the organization uses to connect its applications
[13:41] to model providers. In a vulnerable deployment, compromising the gateway could mean gaining
[13:46] access to the keys behind the AI stack. There's also a more severe attack chain. Researchers have
[13:54] shown that this vulnerability can be combined with a separate vulnerability, a Starlette host
[13:59] header issue to reach unauthenticated remote code execution in some affected deployments. In other
[14:05] words, depending on how the system is exposed and configured, the attack can move from authenticated
[14:11] to unauthenticated. LiteLLM fixed this vulnerability in version 1.83.7. Organizations
[14:18] running LiteLLM should upgrade to that version or later, and they should also make sure the
[14:23] Starlette dependency is updated if they may be exposed to the chained issue. If there's any
[14:29] chance your server was exposed, we suggest rotating provider keys and reviewing logs for suspicious
[14:34] MCP test activity or unexpected command execution. JetBrains has removed malicious AI-themed plugins
[14:42] from its marketplace after reports that they were stealing developer API keys. A few weeks ago,
[14:47] we talked about Trapdoor, a supply chain campaign that used malicious packages disguised as useful
[14:54] developer and AI tools to steal credentials from developer machines. Then more recently,
[14:59] we covered the miasma worm, a supply chain attack that planted malicious configuration
[15:04] files inside GitHub repositories intended to leverage trusted developer tools that
[15:10] automatically honored those files. This next story sits in the same realm. JetBrains says
[15:15] it removed 15 malicious third-party plugins from the JetBrains marketplace after reports
[15:20] that they were stealing AI provider API keys from developers. This was a different delivery
[15:26] path than Trapdoor or Miasma the same basic target: the trusted space where developers write code, run
[15:34] tools and store credentials Trapdoor came through package ecosystems. Miasma came through repository
[15:40] configuration files. In this case, the attacker abused plugins inside the IDE. The plugins were
[15:46] published under seven separate publisher accounts and disguised as useful AI coding tools.
[15:52] They offered features developers actually want in the editor.
[15:56] Chat, code review, bug finding, unit tests, commit message help, and other coding assistant
[16:02] workflows.
[16:03] And according to Aikido Security, the plugins worked.
[16:06] A developer could install one, paste in an API key, and get the AI feature they expected.
[16:12] But when that key was saved, the plugin quietly sent it to a server controlled by the attacker.
[16:17] And that made this compromise hard to notice.
[16:20] The tool behaved like a normal AI assistant while stealing the credentials that power it.
[16:25] The stolen keys reportedly included AI provider keys for services like OpenAI, DeepSeek, and SiliconFlow.
[16:32] In some cases, that may mean unexpected usage charges.
[16:35] In others, it may expose internal prompts, generated code, model traffic, or private AI infrastructure.
[16:42] And if the same key is shared across a team, used in automation, or connected to a high-limit account, the blast radius grows quickly.
[16:51] JetBrains says it received the reports on June 16th and removed the flagged plugins from the marketplace.
[16:57] The company also blocked them from future downloads, terminated the publisher accounts tied to the campaign,
[17:03] and said it is adding stronger checks around plugins that request or handle AI provider keys.
[17:09] The exact scale is still unknown because reports count installs and exposure in different ways,
[17:15] but from what we could gather, the data shows at least 15 plugins, 7 publisher accounts,
[17:21] and malicious activity that appears to have run for months, with some plugins published as far
[17:27] back as late 2025 and others appearing as recently as June. If you installed one of the affected JetBrains
[17:34] marketplace plugins, uninstall it, rotate any AI provider keys that were configured in the plugin,
[17:40] and review provider usage logs for unusual activity. If those keys were shared across
[17:45] other tools, CI jobs, or team workflows, rotate them there too. Links to all the stories we covered
[17:51] today are in the description. Thanks for watching or listening, and we'll see you next week on Wordfence
[17:57] Security News.