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 WordPress font optimization plugin exploited before the
[0:05] developer even had a patch out, Oracle's business software back under attack, this time eBusiness
[0:11] Suite's payment system, attackers planning backdoors inside engineering software used by
[0:16] manufacturers and defense contractors, ransomware crews pick up Microsoft's leaked BlueHammer
[0:22] Defender flaw, a remote support tools login flaw giving attackers a path to steal cloud,
[0:28] source code and AI credentials, and a clean GitHub repo with no malware at all,
[0:34] showing how an AI coding agent can still be tricked into opening a backdoor.
[0:42] This is Wordfence Security News. I'm Alex Thomas.
[0:48] Our top story starts with a plugin most site owners never think twice about.
[0:53] OMGF, short for Optimize My Google Fonts, lets WordPress sites host Google Fonts locally instead
[0:59] of pulling them from Google servers for speed and privacy. The Pro version adds extra optimization
[1:05] features, including a way to cache stylesheets from other websites. That caching feature is
[1:10] where the problem lies. OMGF Pro scans a page for references to outside stylesheets and
[1:17] automatically fetches and saves a copy.
[1:20] And that scan isn't picky about where on the page the reference comes from, or what kind
[1:26] of file comes back.
[1:27] An attacker can plant that reference somewhere the site reflects user input back onto the
[1:33] page, a search box for example, then point it at a file they control, and OMGF Pro will
[1:40] fetch that file and save it straight into the site's upload folder.
[1:43] Exploitation doesn't require a login and no check is done on what type of file it actually is.
[1:49] If that file is a PHP script, all it takes to run is a second equally unauthenticated request.
[1:57] Visiting the file's new web address directly executes it as code.
[2:01] This one came through our own bug bounty program.
[2:04] We began responsible disclosure with OMGF's developer on June 23rd and had a firewall rule
[2:10] protecting Wordfence Premium, Care, and Response customers the very next day. Attackers had a
[2:15] working exploit within about a day of that rule going out while disclosure was still underway
[2:22] and before the developer's own public alert. It started small. Then, once the issue became
[2:28] more widely known, it scaled up fast. As of this recording, our firewall has logged more than
[2:34] 60,000 blocked attack attempts across nearly 8,000 sites. That early wave had a pattern to it too.
[2:41] Nearly half of the sites hit in those first hours were on German domains, and more than half were
[2:48] German, Austrian, or Swiss. That tracks with OMGF Pro's user base, which skews European,
[2:54] and points to attackers going after known users of the plugin rather than scanning the internet
[2:59] at random. We also found that the same domain hosting this attack, elemetate.com, also turned
[3:06] up in a completely different WordPress plugin attack back in the spring, a similar file upload
[3:11] bug in the caching plugin called Breeze Cache. This was a different plugin and a different
[3:17] vulnerability, but the same attacker infrastructure months apart. The developer has since confirmed
[3:23] active exploitation, published indicators of compromise, and shipped a fix in version 5.2.7.
[3:29] If you or a client runs OMGF Pro, update to 5.2.7 now. Wordfence Premium, Care,
[3:36] and Response customers have been covered since June 24th. Free users get this rule
[3:42] on our standard 30-day schedule. Oracle patched this back in May. Attackers are exploiting it
[3:50] anyway and more than 900 systems may still be wide open. Oracle's enterprise software has had a rough
[3:56] few weeks. We told you about attackers going after PeopleSoft not long ago. Now it's a different part
[4:02] of Oracle's business software, eBusiness Suite, and specifically the part that handles payments.
[4:08] The issue is almost absurdly simple to abuse. There's no real check on who's allowed to talk
[4:14] to Oracle Payments file transfer system so anyone who knows the right request to send can take over
[4:20] Oracle payments without any required account or password. Oracle actually patched this back in May,
[4:25] but over the weekend on June 27th, a security firm called Defused caught someone actually using it
[4:31] against systems they monitor, and this wasn't random bot traffic. It looked deliberate and
[4:37] targeted, and there wasn't a public write-up of the bug floating around yet, which tells you
[4:42] whoever's behind it did their own homework. Shadow Server was tracking around 950 exposed
[4:48] Oracle EBS instances, though that does not mean all were vulnerable or compromised.
[4:54] And the PeopleSoft story from a few weeks back, that fallout is still happening. Nissan says
[4:59] this week that employee information, including social security numbers and bank details,
[5:05] may have been swept up in that earlier breach. If your business runs eBusiness Suite,
[5:09] go make sure that May patch actually got applied, and if the payments piece is reachable from the
[5:15] the open internet, you should fix that ASAP. Put it behind a VPN or at least restrict who's allowed
[5:21] to reach it. This is the first time a PTC product has ever landed on CISA's list of actively exploited
[5:28] vulnerabilities. PTC makes Windchill and FlexPLM, software that manufacturers, automakers, and
[5:35] aerospace and defense contractors use to manage all their engineering data, product designs, specs,
[5:41] and so on. There's a critical flaw in how these systems handle incoming data. If sent the right
[5:47] kind of malformed request, the software can execute attacker-supplied code without any
[5:53] login needed. PTC released patches in June. About a week later, they had to admit something worse.
[5:59] Attackers were already exploiting the flaw anyway, deploying JSP web shells on vulnerable systems,
[6:05] potentially giving attackers access to sensitive engineering and product lifecycle data.
[6:11] CISA added it to their exploited list on June 25th.
[6:15] If you're running Windchill or FlexPLM, patch it now and check whether you were already compromised.
[6:21] A researcher leaked this Microsoft vulnerability on purpose as a protest.
[6:26] Now ransomware gangs are using it.
[6:28] A few episodes back, we reported on BlueHammer, the name for a vulnerability affecting Microsoft's Defender software,
[6:34] that was deliberately leaked by a researcher back in April
[6:38] as a protest against how Microsoft handles vulnerability reports.
[6:42] Microsoft patched it, but this week,
[6:44] CISA has flagged it as used in ransomware attacks.
[6:47] Nobody's named which group yet,
[6:49] but if your systems haven't been patched since April,
[6:52] we urge you to update now.
[6:57] The software IT teams use to remotely control computers
[7:00] has a login flaw,
[7:01] and attackers are using it to steal AI and cloud credentials.
[7:05] SimpleHelp is a remote monitoring and management software,
[7:09] the kind of tool IT teams and managed service providers use to reach
[7:13] into and control other people's computers from a distance.
[7:17] Which is exactly why a critical flaw in it is such a big deal.
[7:21] On servers set up to let people log in through an outside identity provider,
[7:26] SimpleHelp failed to properly verify the cryptographic signature
[7:29] of identity tokens in affected OIDC configurations.
[7:33] So an attacker can just fake one and walk in with a fully trusted technician account,
[7:38] the kind of account built to remote into other people's machines without needing a password at all.
[7:44] It even sidesteps multi-factor authentication,
[7:46] since a new technician account gets to set up its own second factor the first time it signs in.
[7:52] Horizon3.ai found and disclosed the bug back on June 12th,
[7:57] though Simple Help had actually already fixed it quietly in late May.
[8:02] That didn't stop attackers.
[8:04] Blackpoint Cyber caught them going after servers that hadn't updated yet,
[8:09] using that fake technician access to push out a loader called Taskweaver,
[8:14] which in turn drops a new info stealer called Djinn onto the machine.
[8:19] Djinn goes after just about everything.
[8:21] Cloud logins, SSH keys, source code credentials,
[8:24] saved browser data, and the tokens and configuration data tied to AI development tools and MCP-connected workflows.
[8:32] So if your organization runs SimpleHelp, get it updated right away,
[8:36] and take a look through your technician accounts for anyone who shouldn't be there.
[8:40] If you spot one, assume that account touched everything it could reach,
[8:43] and start rotating credentials and cloud keys.
[8:46] Researchers just showed how an AI coding assistant can be tricked into opening a back door
[8:51] without a single line of malicious code.
[8:54] Our final story continues a theme we've hit a few times this year.
[8:58] Attackers going after the tools developers use to write code.
[9:01] This one isn't a real-world campaign.
[9:03] It's a research demo from Mozilla's Odin team showing how a clean-looking GitHub repository
[9:10] could trick an AI coding agent into running attacker-controlled code.
[9:15] The chain works like this.
[9:16] A developer asks an agent, like Claude Code, to set up a cloned project.
[9:21] A package in the repo is built to fail on its first run, producing an error message that tells you to run a follow-up setup command.
[9:31] The agent, trying to help, runs it automatically.
[9:35] That command calls a script that pulls the real payload from a DNS TXT record the attacker controls.
[9:42] It decodes it, runs it, and then the attacker has a shell running with the developer's own privileges, providing access to their API keys, their code, and their sessions.
[9:54] The point of the demo is that the agent was not trying to open a shell.
[9:58] It was trying to fix what looked like an ordinary setup error.
[10:01] Now, this is a research demo, not an attack seen in the wild yet, and it's not unique to one tool.
[10:07] Researchers say the same pattern can apply to other AI coding agents, not just cloud code.
[10:14] But it's a good reminder, don't let an agent run setup commands from a repo you haven't
[10:20] read yourself.
[10:21] Links to all the stories we covered today are in the description.
[10:24] Thanks for watching or listening.
[10:26] We're taking next week off, so we'll see you in two weeks on Wordfence Security News.