Editor’s note (March 2026): This article is part of Blog Herald’s editorial archive. Originally published in 2005, it has been reviewed and updated to ensure accuracy and relevance for today’s readers.
Back in February 2005, a small but unsettling story circulated among early bloggers. Some sites hosted on Google’s BlogSpot platform were quietly serving spyware to unsuspecting visitors. The mechanism was almost laughably simple: Blogger allowed anyone to embed JavaScript in their posts, and a handful of bad actors had done exactly that — injecting code that threw deceptive popups at readers, telling them their browser was outdated and urging them to click “Yes” to upgrade. If they did, they installed software they never wanted.
The incident barely registered as a mainstream security story. It was treated as a quirk of the early web — a minor hiccup in the optimistic, chaotic days of blogging’s first boom. Google eventually tightened some controls, the conversation moved on, and most people forgot it ever happened.
That was a mistake. What happened on BlogSpot in 2005 was not a quirk. It was a preview.
What actually happened — and why it mattered more than anyone admitted
The core issue wasn’t Google’s fault. It was structural. Blogger, like most platforms of that era, gave users significant freedom to add custom code to their pages. That openness was, and still is, one of the things that makes blogging platforms powerful. But it also meant that anyone who got a blog — no vetting, no friction — could serve whatever they wanted to the people who visited it.
The spyware-hosting blogs used manipulative popup sequences. Users who clicked “No” were shown a second popup. Then a third. The persistence was designed to wear people down. And it worked. Visitors ended up with unwanted software installed — not because they were careless, but because the environment they were browsing in had been quietly weaponized.
What made this especially troubling was the vector of discovery: the “Next Blog” button. Clicking it would take you to a random BlogSpot blog. That randomness, that sense of open exploration, was one of the delights of the early blogosphere. And it had been turned into a trap.
The lesson should have been obvious: open publishing platforms carry real security obligations — for the platforms that run them, and for every blogger who operates on them.
Twenty years later, the problem is exponentially worse
Fast-forward to today and the same fundamental dynamic is playing out at a scale that would have been incomprehensible in 2005.
WordPress now powers roughly 43% of all websites on the internet. And according to Patchstack’s 2025 WordPress Security Report, there were 11,334 new vulnerabilities identified in the WordPress ecosystem last year alone — a 42% increase over 2024. More alarming still, attackers are now weaponizing newly disclosed vulnerabilities within a median window of just five hours for the most heavily targeted flaws.
Sucuri, one of the major web security providers, observed over 500,000 websites that became infected in 2024. And researchers tracking the DollyWay campaign — a large-scale malicious redirect operation — found that as of early 2025, over 10,000 unique infected WordPress sites were generating around 10 million monthly impressions of pages with injected malicious scripts, reaching millions of visitors every month.
The mechanics are different from 2005, but the intent is identical: use someone’s blog as a vehicle to harm the people who visit it.
The spyware is smarter now — and so is the manipulation
What made the 2005 incident easy to dismiss was how crude it was. Popups telling you to click “Yes.” Browser alerts that looked fake even to an untrained eye.
Today’s equivalents are far more sophisticated. The ShadowCaptcha campaign, first detected in August 2025, exploited over 100 compromised WordPress sites to direct visitors to fake CAPTCHA verification pages — the kind that look completely routine and trustworthy. Once a visitor completed the fake verification, they were walked through steps that delivered ransomware, information stealers, and cryptocurrency miners onto their devices.
The psychological manipulation hasn’t changed. Only the costume has.
Fake security alerts have been replaced by fake CAPTCHAs. Misleading browser upgrade prompts have become convincing phishing pages. And the deception goes deeper: according to Kaspersky data cited in a 2026 malware statistics report, spyware detections rose 51% year-over-year. Credential theft is surging. The tools are AI-augmented. They blend into legitimate processes and evade detection precisely because they look so plausible.
What this means for bloggers who think they’re not a target
One of the most persistent myths in the creator space is that small blogs are safe because they’re not worth attacking.
That was never true, and the data makes it undeniable now. Hackers don’t primarily target blogs because of who you are or how influential your site is. They target blogs because of your audience — the people who trust you enough to visit your site and click your links. A compromised blog with 2,000 monthly readers is still 2,000 people who might be redirected to a scam, infected with a stealer, or manipulated into handing over credentials.
The 2025 Melapress WordPress Security Survey found that the most common threats facing WordPress professionals today are brute force attacks, plugin or theme vulnerabilities, and malicious code injection — the same basic categories that were exploited on BlogSpot two decades ago. And yet, gaps remain staggering: only 27% of respondents had a breach recovery plan in place. Over a third of those concerned about website defacement had implemented no activity logging whatsoever.
Concern without action is its own kind of vulnerability.
The platform responsibility question hasn’t been answered
The 2005 BlogSpot incident raised a question that the industry deflected rather than answered: how responsible is a publishing platform for what its users serve to visitors?
At the time, the easy answer was “not very.” The code was added by individual users. The platform was just hosting it.
That framing never fully held up, and it holds up even less today. Platforms that enable mass publishing carry real obligations — to scan for injected malicious code, to enforce content security policies, to make it easy for users to report and respond to compromises. When a blog infects a visitor, the reputational damage extends beyond that individual site. It erodes trust in the broader ecosystem.
Google has made progress on this front with Safe Browsing technology. WordPress’s security community — Patchstack, Wordfence, Sucuri — does genuinely important work. But the data shows that nearly 58% of vulnerabilities in the WordPress ecosystem can be exploited by a complete outsider without any credentials at all. The infrastructure around open publishing has grown enormously, but the core challenge from 2005 — anyone can put code on a page that harms the people who read it — has never been fully resolved.
What you should actually do about it
If you run a blog — on any platform — the 2005 BlogSpot story should not feel like ancient history. It should feel like a warning that arrived twenty years early.
Keep your plugins, themes, and WordPress core updated. This sounds obvious, yet a significant share of the most heavily exploited vulnerabilities in 2025 were issues that had been patched months earlier — meaning thousands of blogs simply hadn’t updated. Attackers know this, and they rely on it.
Audit what’s running on your site. Unfamiliar plugins, scripts you didn’t install, third-party widgets you added years ago and forgot about — these are all potential attack surfaces. Remove what you don’t need. Monitor what you keep.
Use a web application firewall, enable two-factor authentication on your admin account, and — critically — have a recovery plan. Know what you would do if your site were compromised tomorrow. Know how to take it down, how to clean it, and how to communicate with your audience.
And perhaps most importantly, understand that your blog is not just your platform. It is an environment that you are inviting people into. The people who visit you are trusting you. That trust is not just a content relationship. It is a security obligation.
That was true in 2005. It is more true now.
The story that was always bigger than it looked
Looking back at that 2005 BlogSpot story, what’s striking is not the incident itself but how clearly it traced the outlines of everything that would follow. Open platforms. Custom code. Unsuspecting visitors. Manipulative prompts. The gap between platform freedom and platform responsibility.
Every element of today’s blog security crisis was visible in miniature in that one episode. The tools are more sophisticated now, the scale is orders of magnitude larger, and the potential harm is far more serious. But the core truth has never changed: if you publish to the web, you are responsible for what your site does to the people who come to read it.
That responsibility doesn’t diminish just because the platform is open, the code was injected by someone else, or your blog is small. It goes with the territory of having an audience. And the bloggers who understand that — who treat security not as a technical chore but as an ethical commitment — are the ones who deserve the trust they’ve earned.
