This episode of the Jukebox podcast features Austin Ginder, a long-time WordPress developer and founder of Anchor Hosting, who explains how AI is helping to uncover a worrying new class of WordPress attacks: supply-chain compromises of plugins.
Background
Austin has worked with WordPress since 2010 and has run Anchor Hosting since 2014, managing thousands of sites. While he doesn’t consider himself a traditional security expert, his experience cleaning infected sites and a recent availability of AI-assisted forensics put him in a position to detect and document several supply-chain incidents affecting WordPress plugins.
What is a supply-chain attack in WordPress plugins?
Unlike straightforward site hacks, supply-chain attacks target the distribution path of software. Two typical patterns Austin describes are:
– Unauthorized updates pushed via compromised credentials to a plugin’s official repository, so users receive malicious updates while believing they’re legitimate.
– Purchase or takeover of a plugin or plugin company by bad actors, who then subtly change the plugin to offload updates to a third-party server. From that point the plugin can receive arbitrary payloads out of view of wordpress.org.
Both approaches let attackers hide malicious code behind otherwise normal-looking plugins. The plugin may continue to function as expected while a backdoor waits dormant until the attacker decides to “pull the trigger.” That means many sites could be infected but appear fine until malicious activity is deployed.
How AI changed the game
Historically, auditing tens of thousands of open-source plugins and tracking every change was prohibitively labor intensive. Austin used modern AI tools (Claude Code and similar) to automate large-scale forensic analysis: scanning plugin repo activity, comparing file hashes and versions across sites, and highlighting unusual offloads to external update channels.
AI doesn’t magically fix everything, but it makes it feasible for an individual researcher to parse massive SVN histories and correlate indicators that would otherwise be buried. Austin describes it as a superpower for after-the-fact investigations — tracing where a malicious update began and which sites were affected.
Real findings
Austin’s work uncovered multiple distinct incidents. Examples include:
– A coordinated problem involving an “Essential Plugins” bundle, where plugins were taken offline by the WordPress Plugin Team after suspicious updates were identified.
– A widget/plugin that began embedding unusual third-party JavaScript on client sites; tracing revealed the plugin had been hijacked and redirected to an external update channel.
– Variant installations of plugins on managed sites that didn’t match the official wordpress.org versions — indicating sites were running hijacked builds.
– A high‑reach plugin wired into thousands of sites that appeared compromised but hadn’t been activated by the attacker yet, showing the danger of dormant backdoors waiting for the right moment.
These are different stories with a common theme: attackers prefer stealth. They usually avoid obvious malware and instead add sneaky updaters or backdoors that let them monetize later via SEO spam, ad injection, or other payloads.
WP Beacon: documenting supply-chain incidents
To make findings accessible and actionable, Austin launched WP Beacon (wpbeacon.io). Rather than a general vulnerability database, WP Beacon focuses on supply-chain attacks specifically: documenting how the compromise happened, indicators of compromise, and data that security teams and hosts can use to take down attacker infrastructure.
Austin sees WP Beacon as complementary to the work of the WordPress Plugin Team and hosting providers. A timely, well-documented report can empower security teams at hosts to suspend offending domains and remove malicious infrastructure — actions that protect end users.
The role of hosts and scale
Hosts have a crucial advantage because they see large volumes of sites and malware incidents. Austin argues that a hosting provider with broad visibility could feed incidents into AI tools to identify patterns and much more quickly find the upstream cause of infections. The combination of hosting telemetry and AI-powered analysis would be one of the most effective defenses.
Practical suggestions and limitations
– Code auditing at scale: Austin argues for systematic auditing of PHP and JavaScript lines where harmful behavior is most likely, rather than trying to vet every trivial asset change. He’s found it practical to hash and audit individual plugin versions and reuse those results across sites running identical builds.
– Individual site owners can use modern AI tools to run an audit of their own backups and files to identify suspicious code, though the process may require careful prompts and iteration.
– Openness vs. friction: The open nature of WordPress is a strength and complicates adding heavy onboarding or permissions systems like app stores. Austin wants to keep WordPress flexible, but recognizes architectural approaches (or a new ecosystem) might be needed for stricter sandboxing or permission models.
Outlook
Austin hopes this becomes a solvable, collaborative problem: better visibility, more automated auditing, and hosts taking action to disrupt attacker infrastructure. He acknowledges the work isn’t finished — some bad actors have persisted for over a decade, reappearing after takedowns — but believes making exploitation harder and faster to detect will reduce the problem.
Get involved
If you manage multiple sites, work for a hosting provider, or research WordPress security, Austin recommends: increase automated auditing of plugin code, collaborate with security teams, and share findings that pinpoint attacker infrastructure so it can be removed. His project WP Beacon aims to be a central source for supply‑chain incident reports, and he’s open to contact via his blog (anchor.host) or social channels.
Conclusion
The episode is a wake-up call: the ecosystem’s openness enables powerful innovation but also allows stealthy supply-chain attacks. AI has changed what’s possible for detection and forensics, enabling individuals and teams to find patterns across repositories and sites. The practical path forward is cooperative — hosts, security researchers, the plugin review team, and maintainers sharing data and using automated tools to audit and respond more quickly. Until then, plugin updates remain a potential vector for hidden compromises, and site owners should stay vigilant.
