Editor’s note (April 2026): This article is part of Blog Herald’s editorial archive. Originally published in 2009, it has been reviewed and updated to ensure accuracy and relevance for today’s readers.
When a story breaks about WordPress being hacked, it travels fast. A single vulnerability report can spiral through the blogging world within hours — reshared, amplified, and stripped of the context that would make it meaningful.
What’s worth revisiting isn’t the specific vulnerabilities of that era — many have long since been patched. What’s worth revisiting is the pattern: how WordPress security stories get distorted, how responsibility gets misassigned, and what bloggers and publishers can actually do to protect themselves. The fundamentals have shifted less than you might expect.
Back in 2009, Matt Mullenweg compared the spread of false vulnerability reports to someone running into a crowded theatre and shouting “fire.” His frustration was understandable. The WordPress security team spent considerable time filtering noise — separating credible disclosures from opportunistic rumours that had no grounding in the code. Real threats were getting lost in the din.
The irony is that WordPress’s transparency — openly disclosing vulnerabilities and pushing updates — was often weaponised against it. Platforms that quietly patched issues in-house appeared safer by comparison, simply because they said less. Movable Type, to use the example from that original piece, had multiple documented security incidents in the same period but faced far less public scrutiny because it disclosed less publicly.
Where the real risk lives
The core WordPress software — what the development team ships — has become significantly more hardened over the past decade and a half. The WordPress Security Team now includes dozens of contributors, runs a dedicated bug bounty programme, and coordinates disclosures through a formal process. Automatic updates for minor releases, introduced in WordPress 3.7, mean most sites receive security patches without the site owner ever intervening.
But the original article put its finger on something that has only become more relevant with time: the real attack surface isn’t the core. It’s the surrounding ecosystem.
Plugins and themes remain the dominant vector for WordPress compromises. According to Sucuri’s 2023 Hacked Website Report, outdated or vulnerable plugins account for the overwhelming majority of successful attacks on WordPress installations. Patchstack, a WordPress-focused security firm, tracked over 5,000 new vulnerabilities in WordPress plugins and themes in 2023 alone — compared to a handful in core WordPress itself.
This isn’t a new problem. What’s changed is the scale. The WordPress plugin directory now hosts over 59,000 plugins. Many are maintained by a single developer working in their spare time. Some are abandoned entirely, no longer receiving updates even when vulnerabilities are disclosed. A blogger who installed a popular contact form plugin in 2019 and never thought about it again may be running software that has accumulated multiple known exploits since then.
The economics of this are uncomfortable. Plugin developers often have no financial incentive to maintain their work indefinitely. Free plugins are acts of generosity, not service contracts. As a reader relying on them, that’s worth understanding clearly.
The upgrade problem hasn’t gone away
One of the most striking details from the original 2009 piece was this: after a major WordPress vulnerability was announced and a patch released, a hacker published a list of blogs still running the vulnerable version — and began working through it. The lesson was blunt. Delayed upgrades don’t just leave you exposed; they advertise your exposure.
That dynamic plays out at a larger scale today. When a high-severity vulnerability is disclosed in a popular plugin, exploit code can appear within hours. Automated scanners run continuously, identifying unpatched installations. The window between public disclosure and active exploitation has compressed dramatically.
For bloggers running WordPress, this is a practical argument for automatic updates — not just for core, but for plugins and themes where the option exists. The objection that automatic updates might break something is legitimate, but it needs to be weighed against what a compromised site actually costs: lost traffic, blacklisting by Google’s Safe Browsing, data exposure, and the hours required to clean up an infection.
The 2009 article noted that Google would drop a site if it detected spammy links injected by attackers. That remains true. A successful compromise can undo months of SEO work overnight.
The transparency gap still matters
Something from that original piece deserves to be said plainly in 2026: the platform that talks most about its security problems is not necessarily the least secure. It may simply be the most honest.
WordPress’s public vulnerability disclosure process, its relationship with security researchers, and the visibility of its patch notes are features, not liabilities. When a vulnerability is disclosed and fixed within days, that’s the system working. The alternative — platforms that patch quietly and leave users unaware — offers a false sense of security.
This extends to the broader conversation around alternative platforms. Ghost, Substack, and other hosted solutions shift security responsibility to the platform provider, which removes certain risks. But it also removes control. A blogger on a hosted platform doesn’t need to worry about plugin vulnerabilities, but they also can’t audit what they’re running or respond independently to emerging threats.
Neither model is simply better. What matters is understanding which risks you’re taking and making informed decisions about them.
What to actually do
The practical guidance here hasn’t changed much in fifteen years, which says something about how foundational it is. Keep WordPress core, plugins, and themes updated. Remove plugins you aren’t using. Source themes and plugins from reputable developers, not from third-party sites offering free premium downloads. Use a security plugin that actively monitors file integrity and blocks known attack patterns. Enable two-factor authentication on your admin account. Maintain regular, off-site backups — not just the copies your host provides.
None of this is complicated. Most of it is free. What it requires is attention — treating your blog as infrastructure worth protecting, not just content worth creating.
The 2009 piece ended with a promise to cover how to protect thyself in the next instalment. The advice is the same now as it would have been then. The tools are better, the threats are more sophisticated, and the stakes — for creators who’ve built audiences and income streams on their sites — are considerably higher. That’s the argument for taking it seriously.
Security isn’t a problem you solve once. It’s a condition you maintain.
