Technology

How One Person Hid Malware in 44 WordPress Plugins for 13 Years

Martin HollowayPublished 2d ago5 min readBased on 6 sources
Reading level
How One Person Hid Malware in 44 WordPress Plugins for 13 Years

A security researcher has uncovered a 13-year backdoor campaign that compromised 44 WordPress plugins, all controlled by a single operator. The finding reveals how thoroughly open-source software ecosystems can be exploited through patience and low-visibility attacks.

According to the WPScan vulnerability database, multiple plugins sold under the "Essential Plugin" name contained hidden backdoors, part of a coordinated operation where one attacker maintained secret access across numerous supposedly independent packages. The sheer breadth—44 plugins spanning more than a decade—places this among the most methodical supply-chain attacks documented in the WordPress world.

The pattern matches what security researchers call a "sleeper" attack: take control of or contribute to popular software packages, hide malicious code inside, then activate it when the time is right. A concrete example emerged through Bleeping Computer's reporting in April 2026: the Quick Page/Post Redirect plugin, installed on more than 70,000 WordPress sites, contained a dormant backdoor planted five years earlier. That backdoor could inject harmful code into infected websites. For five years, nothing suspicious happened—no alerts, no red flags. This kind of patience defeats traditional security scans and makes the attack nearly invisible to routine audits.

Why WordPress Plugins Are a Target

WordPress plugins are an appealing attack target for several reasons. The official repository hosts tens of thousands of packages, many maintained by individual developers who sometimes sell or transfer ownership without public announcement. Once malicious code is planted in a trusted, widely-installed plugin, each software update spreads the compromise further. A plugin installed on 70,000 sites means 70,000 websites where an attacker could potentially access hosting systems, steal admin passwords, or monitor visitor traffic.

The 44-plugin operation could have been built one plugin at a time over years, or the attacker may have bought existing plugins that already had thousands of installations. Both approaches have happened before. WordPress.org does not always make plugin ownership transfers obvious or transparent, and the repository's automated security scanning has historically missed threats that human researchers later found. This case appears to fit that pattern: a researcher's careful investigation, not the platform's built-in tools, exposed the attack.

The real issue here extends beyond WordPress. Any large software repository—npm for JavaScript, PyPI for Python, RubyGems for Ruby—relies on similar trust systems. A package with a real publication history and genuine users carries credibility that attackers have learned to exploit. This WordPress finding fits into a broader supply-chain compromise problem that defenders have grappled with since the SolarWinds attack became public in late 2020, when hackers infiltrated software updates to gain access to government and corporate networks.

Recent Backdoor Cases in 2025–2026

The WordPress campaign is one of several unrelated backdoor discoveries announced recently. These cases show how varied the threat landscape is.

CISA and NSA jointly attributed the BRICKSTORM backdoor to Chinese-linked actors targeting VMware and Windows systems. CISA published an analysis in February 2026 detailing how it enabled long-term persistence on infected networks. Reuters reported in December 2025 that US and Canadian authorities linked BRICKSTORM to Chinese-backed operators targeting critical infrastructure—an accusation China's government dismissed. In April 2026, CISA released a separate analysis of FIRESTARTER, another distinct backdoor malware uncovered during forensic investigations.

On the political side, US House Judiciary Chair Jim Jordan and Foreign Affairs Chair Brian Mast formally requested a briefing from the British government in February 2026 about the UK reportedly ordering Apple to create a backdoor into encrypted communications—a legislative and policy question, not an attack, but one that touches the same core tension: who should have access to encrypted or protected systems, and on whose authority.

These separate incidents do not connect as part of one plot. What they illustrate is that "backdoor" now spans three distinct problems: attackers sneaking code into trusted software, governments ordering companies to build hidden access points, and state-sponsored groups targeting critical infrastructure. Each demands its own defense strategy.

What Organizations Should Do

For teams running WordPress in production—large news sites, enterprise content systems, managed hosting companies—the immediate concern is knowing where plugins actually come from. Software analysis tools that scan for suspicious code patterns are more reliable than trusting the official repository's reputation checks. Watching the network traffic leaving web servers can catch command-and-control communications once dormant backdoors activate. And examining the ownership history of plugins, when possible, deserves the same care that security teams apply to third-party code in other software environments.

The 13-year duration should reshape how organizations think about security. Most companies update passwords, patch software, and review access logs once a year or more often. A backdoor that wakes up once every few years, quietly exfiltrates data, and otherwise stays silent will slip past those checkpoints. The researcher who uncovered this almost certainly did so by manually reading the code—which is why open-source transparency matters, even when discovery takes over a decade.