It was 2 AM and I was staring at my WordPress dashboard, watching the numbers climb. Not visitor numbers. Not sales numbers. Attack numbers. My site had gone from a sleepy affiliate blog getting thirty visitors a day to receiving over four thousand requests in a single hour, and every single one of them was trying to exploit something called XML-RPC.

I didn't even know what XML-RPC was until that night. I learned fast.

What Hit Me

Here's what I understood after spending three hours reading WordPress security forums at 3 AM: XML-RPC is a protocol that lets external services communicate with WordPress. It's used for things like the mobile app, trackbacks, and pingbacks. It's also the single biggest security headache for any WordPress site owner who doesn't know to disable it.

Someone, somewhere, had decided to use my site as a pawn in a brute-force attack. They were sending hundreds of requests per minute through the XML-RPC endpoint, trying username and password combinations. My site was essentially being used as a weapon, and I was the one paying for the bandwidth.

The terrifying part? My hosting panel showed CPU usage at 97%. The site was barely loading. If this kept up, Hostinger would probably suspend my account for exceeding resources. Months of work, 150+ blog posts, dozens of WooCommerce products — all of it could disappear because of someone's automated script.

The Fix (And What I Learned About WordPress Security)

I disabled XML-RPC first. Then pingbacks. Then I found out about something called the Broken Link Checker plugin, which was also hammering my database with constant requests. I disabled that too. Then I went into my .htaccess file and started blocking bot traffic aggressively.

Here's what I learned: WordPress, out of the box, is not secure. It's built for convenience, not for someone running an affiliate store on a shared hosting plan. Every plugin you install is a potential vulnerability. Every default feature you don't use is a potential attack vector. The pingback system, which was designed to let blogs notify each other when they link to each other, had become a tool for distributed denial of service attacks.

I spent the next three days hardening everything. I added firewall rules. I blocked suspicious IP ranges. I disabled user enumeration. I restricted access to the login page. I felt like I was fortifying a castle that was constantly under siege, except the castle was a WordPress site about affiliate marketing and the siege engines were bots running from server farms I couldn't even locate.

The Emotional Toll Nobody Talks About

Here's what the security guides don't tell you: being attacked feels personal, even when it isn't. I knew, logically, that some random attacker wasn't targeting Justice Manyika specifically. They were scanning the internet for vulnerable WordPress sites and mine happened to be one. But at 2 AM, watching your CPU meter turn red, it feels like someone is trying to destroy what you built.

And there's the helplessness. You can't call the police. You can't report it to anyone who will actually do something about it. The attack is coming from IP addresses in twelve different countries. The hosting provider's support chat gives you a link to a generic article about "improving site security." You're on your own, with a .htaccess file and whatever you can learn from forums in the next hour.

I remember sitting there after I'd finally gotten the attack under control, the CPU meter back to normal, the site loading again. I didn't feel relieved. I felt exhausted and, honestly, a little scared. This was supposed to be the passive income dream. Build a website, write content, collect affiliate commissions. Nobody mentioned that you'd also need to become a part-time security engineer.

What I'd Tell Someone Starting Out

If you're about to launch a WordPress site, do these things before you publish a single post. Disable XML-RPC if you're not using the mobile app. Disable pingbacks and trackbacks. Remove the Broken Link Checker plugin if you have it. Add basic firewall rules to your .htaccess. Block bot user agents. Limit login attempts. And for the love of everything, do not install every plugin that looks helpful. Each one is a door into your site.

I also learned that shared hosting has limits they don't advertise. My Hostinger plan said "unlimited bandwidth" but didn't mention that CPU usage has a hard cap. An attack that a dedicated server would shrug off can take down an entire shared hosting account. When you're choosing hosting, think about the worst-case scenario, not the average day.

The Bigger Lesson

The pingback attack taught me something that would prove true over and over again in this journey: building something online means maintaining it. The "set it and forget it" dream of passive income doesn't exist. Every system you build requires attention. Every platform has vulnerabilities. Every automated process can break.

And when it breaks at 2 AM, there's no IT department to call. There's just you, a .htaccess file, and whatever you can learn from a forum post written by someone in a different timezone who had the same problem three years ago.

That night, after I'd secured everything, I set up monitoring so I'd get an email if CPU spiked again. Then I went to bed at 4 AM, set my alarm for 7, and got three hours of sleep before my day job. The passive income dream was starting to feel like a second full-time job. But I wasn't ready to quit. Not yet.

Comments

Popular posts from this blog