On April 3rd, 2026, Ali Abdaal's email subscribers received messages promoting a cryptocurrency airdrop. The emails came from his actual domain. They were real emails from his account, but they weren't from Ali or his team.

Attackers had exploited a vulnerability in a WordPress plugin on his site. Through that plugin, they gained access to the connection between his website and his email platform. Within minutes, scam emails went out to his entire list.

Ali's team caught it fast. They took the site offline, revoked API keys, reset all credentials, and disconnected their email integration. His response was about as good as you could ask for.

But here's the part that matters for every creator running a WordPress site: Ali didn't do anything wrong. He used a legitimate, official plugin from a reputable company. The vulnerability came from trusted software doing exactly what it was designed to do.

The plugin was an official WordPress plugin

That's what makes this worth paying attention to. This isn't a story about a creator being careless. It's a story about a plugin that most creators would consider safe, from a company they already trust, creating an attack path straight to their most valuable business asset: their email list.

How a "safe" plugin becomes a risk

If an attacker gains access to your WordPress server (through any vulnerability, in any plugin), they can potentially use that bridge to reach your email platform. They don't need to hack your email service provider. They just need to get onto your server and use the connection that's already there.

Your WordPress site might have 20 or 30 plugins installed. Each one is code running on your server, written by someone else, with access to your data and integrations. Any one of them can be the entry point. But the plugins that connect to your email list, your payment processor, or your course platform are the ones that turn a website hack into a business problem.

Plugins vs. standalone tools

Most creators use a mix of tools. Kit for email. Stripe for payments. Circle or Teachable for community and courses. When you use these as standalone platforms (logging into kit.app directly, using Stripe's dashboard, accessing Circle through its own site), your data lives on their servers. Their security teams manage the risk.

A WordPress plugin changes that equation. It puts a piece of that platform's functionality on your server. You're now responsible for the security of that connection. If your WordPress site gets compromised, every integration connected through a plugin is potentially exposed.

Ali actually had this right in other parts of his setup. He runs his paid community on Circle, a standalone platform that doesn't live on his WordPress server. Circle wasn't affected. The vulnerability came through the plugin that bridged his WordPress site to his email platform.

What you can do about it

You don't need to become a security expert. But you do need to treat your WordPress plugins like what they are: third-party software with access to your business.

Here's what that looks like in practice.

Move functionality off WordPress when you can. If a standalone tool can do the job, use it instead of a plugin. This is especially true for high-value connections like email and payments. You can embed a Kit signup form on your WordPress site using a simple HTML snippet instead of a plugin. That embed doesn't create a server-side connection to your email account. It's just a form. A plugin, on the other hand, lives on your server and maintains an active link to your Kit account. Ask yourself: does this need to be a plugin, or can an embed or direct link do the same job?

Audit your plugin list. Go through every plugin on your site. If you don't know what it does, find out. If you're not using it, delete it. Every plugin you remove is one less thing that can be compromised. Deactivating isn't enough. Delete it.

Know which plugins connect to other platforms. Not all plugins carry the same risk. A plugin that formats your blog layout is different from a plugin that holds API keys to your email platform or payment processor. Make a list of every plugin that connects to an external service. Those are your highest-priority items to review.

Turn off automatic updates for plugins. This sounds counterintuitive. Updates usually fix security issues. But supply chain attacks (like the recent but unrelated BuddyBoss incident that affected hundreds of other WordPress sites in March 2026) can use the update system itself to deliver malicious code. A better approach: wait a few days after a plugin update drops before applying it. Check that the new version hasn't been flagged before you install it. Security updates should be installed promptly, feature updates can be delayed a little longer.

Separate your email platform from your website server. This is the big one. If your email platform connects to your WordPress site through a plugin, that plugin is a bridge an attacker can cross. Consider whether you actually need that server-side integration, or whether a simpler embed code would work. For most creators, an embedded signup form does everything they need without creating a backend connection to their entire email account.

Back up everything. Often. If your site gets compromised, you need to be able to roll back to a clean version. Daily backups, stored somewhere separate from your hosting account. Test your restore process at least quarterly so you know it works.

Know your response plan. Ali's team responded in minutes. They knew what to disconnect and in what order. Most creators wouldn't. Think through what you'd do if your site got hacked tomorrow. Which accounts would you lock first? Who would you contact? Where are your backup credentials stored? Having answers before you need them makes the difference between a bad day and a business-ending event.

The bigger picture

WordPress powers a huge percentage of creator websites. It's flexible, it's powerful, and its plugin ecosystem is one of its greatest strengths. But that ecosystem is also a massive attack surface.

Every plugin is a relationship with a third-party developer. Most of those developers are doing good work. But you can't control what happens on their end. And when the plugin in question connects to your email list, or your Stripe account, or your course platform, the stakes go up fast.

Ali Abdaal had the team and the knowledge to respond quickly. Most creators don't. That gap between "it could happen" and "I'm ready if it does" is where the real risk lives.

If you're not sure where you stand, start with two questions. First: what plugins am I running, and which ones connect to my email, payments, or course platform? Second: could any of those connections be replaced by something that doesn't live on my server?

​
Reply if you have any questions, or just want to say hi. I love hearing from you all.

Stay safe out there,
Tom
​tomprotects.com​

​
​