Editor’s note (April 2026): This article is part of the Blog Herald’s editorial archives. Originally published in 2009, it has been revised and updated to ensure accuracy and relevance for today’s readers.
When a story breaks about a WordPress hack, it spreads fast. A vulnerability report can spread through the blogosphere in a matter of hours—reshared, amplified, and stripped of the context that would make it meaningful.
It’s not the particular weaknesses of that era that are worth revisiting – many have long since been fixed. Here’s an example worth revisiting: how WordPress security stories are being misrepresented, how responsibility is being misplaced, and what bloggers and publishers can actually do to protect themselves. The fundamentals have changed less than you might expect.
Back in 2009 Matt Mullenweg compared the spread of false vulnerability reports to someone running into a crowded theater and yelling “fire.” His frustration is understandable. The WordPress security team has spent a lot of time sifting through the noise—separating valid disclosures from opportunistic rumors that have no basis in the code. The real threats got lost in the noise.
The irony is that WordPress’s transparency—openly disclosing vulnerabilities and encouraging updates—has often been weaponized against it. Platforms that quietly solved problems in-house seemed safer in comparison because they said less. Movable Type had many documented security incidents during the same period, to take that original piece as an example, but faced less public scrutiny because it was less publicized.
Where the real risk lives
The core WordPress software—what the development team ships with—has gotten significantly more rigid over the past decade and a half. The WordPress Security Team now includes dozens of contributors, runs a dedicated bug bounty program, and coordinates disclosures through a formal process. Automatic updates for minor releases introduced in WordPress 3.7 mean that most sites receive security patches without site owner intervention.
But the original article pointed to something that has become more relevant over time: the real attack surface is not the core. It is the surrounding ecosystem.
Plugins and themes remain the dominant vector for WordPress compromises. according to Sucuri’s 2023 Hacked Website Reportoutdated or vulnerable plugins account for the vast majority of successful attacks on WordPress installations. WordPress-focused security firm Patchstack tracked more than 5,000 new vulnerabilities in WordPress plugins and themes in 2023 alone — compared to a handful in core WordPress itself.
This is not a new problem. The variable is scale. The WordPress plugin directory now hosts over 59,000 plugins. Many are maintained by a single developer working in his spare time. Some are completely abandoned, even when vulnerabilities are discovered, updates are no longer accepted. A blogger who installs a popular contact form plugin in 2019 and doesn’t think twice about it could be dealing with software that has since accumulated many known exploits.
The economics of this are troubling. Plugin developers often have no financial incentive to keep their work going indefinitely. Free plugins are acts of generosity, not service contracts. As a reader who relies on them, it’s worth understanding this clearly.
The upgrade problem has not gone away
One of the most striking details of the original piece from 2009 was this: After a major vulnerability in WordPress was announced and patched, a hacker published a list of blogs still running the vulnerable version and began working on it. The lesson was open. Delayed upgrades don’t just leave you open; they advertise your exposure.
This dynamic is manifested on a larger scale today. When a vulnerability is discovered 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 narrowed dramatically.
For WordPress bloggers, this is a practical argument for automatic updates – not just for core, but also for plugins and themes where the option is available. The objection that automatic updates might break something is legitimate, but it must be weighed against what it actually costs the compromised site: lost traffic, blacklisting by Google’s Safe View, data exposure, and hours required to clean up the infection.
An article from 2009 stated that Google will take down a site if it detects spam links sent by attackers. This remains true. A successful compromise can undo months of SEO work overnight.
The transparency gap is still important
One thing from this original piece deserves to be made clear in 2026: the platform that talks the most about security issues isn’t necessarily the least secure. It just might be the most honest.
WordPress’ public vulnerability disclosure process, its relationship with security researchers, and the visibility of patch notes are features, not obligations. When the vulnerability is detected and fixed within a day, the system works. Alternatively, platforms that silently patch and leave users unaware provide a false sense of security.
This extends to the larger conversation around alternative platforms. Ghost, Substack, and other hosting solutions delegate security responsibility to the platform provider, which eliminates certain risks. But it also removes control. A blogger on a hosted platform doesn’t need to worry about plugin vulnerabilities, but he can’t verify that they’re working or respond to emerging threats independently.
No model is simply better. The key is to understand what risks you are taking and make informed decisions about them.
Actually what to do
The practical guidance here hasn’t changed much in fifteen years, which says something about how solid it is. Update WordPress core, plugins and themes. Remove plugins you don’t use. Source themes and plugins from reputable developers, not from third-party sites that offer 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. Keep regular, off-site backups, not just the ones your host provides.
None of this is complicated. Most are free. What’s required is focus—treating your blog as an infrastructure worth maintaining, not just content worth creating.
The 2009 piece ended with a word on how to protect yourself in the next section. The advice is the same now as it was then. The tools are better, the threats are more complex, and the stakes are much higher for creators building an audience and revenue stream on their site. That’s the argument for taking it seriously.
Security is not a problem you solve once. This is a condition you keep.
