Hack The Planet

Well, someone hacked the planet. Or, more precisely, someone hacked Hack the Planet. Luckily it was a friend who had read about the vulnerability while I was engaged in some family time. He hacked it, and then he patched it, and then, because I have good friends, he wrote up exactly how he did it so the rest of us could learn from my mistake. His guest post is up here, and you should read it before or after this one. It is a better technical writeup than I would have given you, mostly because I was the target and not the operator this time.

Let me sit in that for a second, because it is uncomfortable and it should be.

I have spent twenty-nine years in this industry. I have delivered more executive briefings than I can count on exactly this kind of thing. I have walked into SOCs and watched alerts pile up unread, and I have written on this very blog about how best practices are rarely practiced and how the fundamentals are the fundamentals for a reason. Patch your systems. Know your assets. Reduce your attack surface. I know the sermon. I wrote the sermon. I can be preachy… 

And my site sat unpatched for two days on a critical with a working exploit in the wild, because I was unaware and living my life.

That last part is the part I actually want to talk about, because “just patch faster” is true and useless in equal measure.

Here is what happened, and my friend lays out the timeline better than I will. WordPress shipped the fix on 17 July. A public proof-of-concept existed about a day later. He was in on day two. At no point in that timeline was I outsmarted. I was out of position. There is a difference, and the difference is the whole point. The vulnerability did not require a genius to exploit (my friend is brilliant though). It required a calendar. The patch dropped, the clock started for everyone at the same instant, and I lost the race because I was at a dinner table instead of a dashboard.

This is the trend that has been eating our field alive for years, and it is getting worse. The window between “patch is public” and “exploit is public” used to be measured in weeks. Then days. Now, increasingly, hours. When a fix ships, it ships to the defenders and the attackers at the same moment, and the attackers have a structural advantage. They only have to win faster than a defender can discover and get approval to patch the vulnerability. 

Now add AI to that timeline. I want to be careful here, because the exploit that got me was not some novel machine-generated superweapon. It was a garden-variety patch-to-PoC sprint that we have seen a hundred times. But the step in that sprint that used to require real skill and real hours, diffing the patch and building a working exploit from it, is exactly the kind of task that AI is getting frighteningly good at compressing. Things that used to take a skilled researcher an afternoon are starting to take a moderately clever person with the right tooling a coffee break. AI did not invent the patch race. It is pouring gasoline on it. The trend was already bad. The accelerant is new.

So the defensive requirement is speed. Hear about the fix fast, act on it fast, beat the scanners to your box. My friend lays out the playbook in his post and it is correct. Subscribe to the right feeds, turn on automatic updates, keep good backups, know your manual override, know your stopgap. None of it is complicated. I could have written it in my sleep. I have written it, in various forms, for years.

Here is the part the sermon always leaves out.

The speed the threat demands and the speed a human life allows are not the same speed. I was not ignoring my responsibilities. I was fulfilling different ones. I was present with my family, which is the thing this entire career is supposed to be in service of, and while I was present, a patch dropped and a two-day clock started and I never heard it tick. That is not a discipline failure. It is a physics problem. There are more critical patches, dropping faster, with shorter fuses, than any individual human can personally track while also being a person.

We do not talk about this honestly enough, and it burns people out. We tell practitioners to stay current as if staying current were a matter of willpower, and then we act surprised when they are exhausted, when the home lab goes dark, when the side project blog sits two days behind on a patch because its owner was being a father instead of an administrator. The always-on expectation is not sustainable, and pretending it is does not make it so. I say this as someone who preaches the fundamentals and just got caught by them.

So what is the actual answer? It is not “try harder.” It is “need less.”

The most resilient thing I took away from getting popped is the least glamorous. Reduce what has to be defended in the first place. My friend makes this point sharper than I will in his post, and he is right. This blog is, at the end of the day, some pages of text I wrote for people to read. It does not need a database, a REST API, and a PHP runtime standing guard over a pile of essays. The machinery I was running had an attack surface that my actual content did not require. The bug that got me had somewhere to live because I gave it a home.

That is the reframe. The way you win a race you cannot personally run fast enough is to stop entering it. Automate the patching you can. Cut the attack surface you do not need so there are fewer clocks ticking in the first place. Build backups so a bad day is an inconvenience and not a catastrophe. The goal is a setup where being a human being for two days is survivable, because the machine held the line while you were gone.

I got lucky. My attacker was a friend who patched the hole and sent me notes. The next one will not be, for me or for you. Take the free lesson I paid for. Subscribe to the feeds, turn on the auto-updates, cut the surface you are not using, and then go be present with your people, knowing you built a thing that does not need you standing over it every hour of every day.

Reduce your attack surface. Patch what you can. And do not forget to spend time with the people who make all of this worthwhile, and worth fighting for.

Hack the Planet!

*Authorized guest post by aaronott*

If you’re reading this, you read this site, so this is aimed at you, not my friend who runs it, though I did get authorization to post this. I got into their blog on 19 July. Here’s why that’s a story about your blog too.

I didn’t do anything clever. I got in through wp2shell, the WordPress pre-auth bug that had a patch sitting there for two days before I used it. The site wasn’t some abandoned install on a five-year-old version. It was reasonably current. The fix was just two days old and hadn’t been applied yet.

That’s the whole lesson, and it’s the most common one in this business.

On 17 July, WordPress shipped 7.0.2 and 6.9.5 to close wp2shell: a REST API batch-endpoint route confusion (CVE-2026-63030) chained to a `WP_Query` SQL injection (CVE-2026-60137). Together they hand an unauthenticated attacker a blind SQL injection through a single public endpoint, and on a lot of ordinary hosts, a path to running code.

When a fix ships, the clock starts for everyone at the same moment. Attackers diff the patch, build a working exploit, and start scanning within hours. wp2shell went from patch to public proof-of-concept in about a day. I was in on day two. Nobody caught by this gets outsmarted, they just find out too late.

The one thing you actually control is how fast you hear about the fix. Two things cover that:

Subscribe. For WordPress, watch the [WordPress.org news feed](https://wordpress.org/news/), where every core security release gets announced (it has an RSS feed you can drop into a reader), plus a CVE alert scoped to the plugins and themes you actually run. You should find the security feed for your stack, if there isn’t one, choose another stack. That’s enough for most single-site setups.

Have a fast way to act. You don’t need an incident-response binder if it’s just you and one blog. You need four things: have a good set of backups that run daily, turn on automatic security updates so criticals often land before you’re even awake, know how to update by hand for when they don’t, and know one stopgap you can throw up if you can’t patch right away (for wp2shell, blocking the batch endpoint at your host or WAF bought time). That’s it. The point isn’t process, it’s beating the scanners to your box.

Now here is my jab:

Look at what got compromised here: a whole content-management system, a REST API, a database, and a PHP runtime, all standing in front of what is basically some pages of text someone wrote for people to read.

If that describes your blog too, it’s worth asking whether you need the machinery. A static site is Markdown in, HTML out, served as flat files. No database to inject into, no endpoint to confuse, no login to brute-force. Hugo, Eleventy, Zola, Astro: pick one, `git push`, go to bed. The bug I used has nowhere to live in that world, because there’s no SQL for the injection to reach.

You don’t need a content management system. You need content, and a way to manage it. Those turn out to be very different amounts of attack surface.

So: subscribe, turn on auto-updates, and if you’re running a whole CMS to serve flat HTML, give static a look. It only took two days.

Hack the planet. Just patch yours first.

*aaronott*

Over the holiday weekend I had some time to think (which can be a dangerous thing), and one of the things that has been on my mind is the need for real-time information to make quick, accurate, confident decisions. I put a short version of this up on LinkedIn, and the conversation it started was good enough that I wanted to expand it into a full post. When minutes matter, information wins. That lesson has been learned in every conflict this country has fought. It was true when riders carried word that the regulars were out. It was true when the Union cracked Confederate signals, when codebreakers shortened a world war, and when a forward air controller in Vietnam had seconds to sort friend from foe. The technology changes every generation. The requirement never has.

Col John Boyd distilled this into the OODA Loop (Observe, Orient, Decide, Act), and it is no accident that Observe comes first. Every decision inherits the quality of the observation that feeds it. If your observations are late, incomplete, or wrong, the loop doesn’t just slow down. It compounds the error. You orient on a false picture, decide with false confidence, and act on the wrong problem. Garbage in doesn’t just produce garbage out. It produces confident garbage, at speed, which is worse.

Most people who reference Boyd fixate on speed, on “getting inside the adversary’s loop.” But speed is a product, not an input. The input is observation. The fighter pilot who sees first, wins. The watch floor that spots the first sign of an intrusion has options that the one who finds it three weeks later does not. Decision dominance starts with observation dominance. There is no shortcut.

One of the replies to my LinkedIn post pushed on an important nuance, and it deserves space here. Observation is not a clean camera feed. Boyd himself put Orientation at the center of the loop, shaped by our genetics, our culture, and our previous experiences. Our default orientation, built from everything we have seen and done, affects how we observe the world and each engagement with an adversary. Our decisions and actions also impact our future observations, keeping the loop alive for the entire engagement.

This is where the idea of the Bayesian brain aligns nicely with Boyd. Each turn of the loop updates our orientation, and the more reps we have, the better our predictions and the faster our loops. This is why experienced analysts seem to “just know” where to look. They aren’t psychic. They have turned the loop thousands of times, and their orientation has been refined by every one of them. It is also why we need to be honest about the flip side. An orientation built on bad assumptions will filter out the very observations that would correct it. If you have ever watched an organization miss an intrusion because “that system isn’t internet facing” or “we don’t have anything anyone would want,” you have watched orientation defeat observation.

Here is the uncomfortable truth. Most organizations don’t deliberately consider how they observe. They don’t know what data and information is important to what they are trying to achieve. They don’t think about how they collect that information, or what it costs to collect it. And they don’t think about how to sort through the noise to get to the signal.

I have walked into plenty of environments that were collecting everything and observing nothing. Log sources feeding a SIEM that nobody tuned. Alerts covering every screen in the SOC while the analysts sat with their heads down, trained by years of false positives to ignore them all. Plenty of organizations pay to collect and store data they never actually use, which is noise with a bill attached. That is not observation. That is hoarding.

Fixing this doesn’t start with a tool. It starts with three questions, asked in order:

Why?

What is the mission of your organization? What are you actually here to do? This sounds basic, but I have sat in rooms where the security team could not articulate what the business does to make money or accomplish its mission. If you can’t state your why, everything downstream is guesswork.

What?

What do you need to protect to fulfill that why? These are your crown jewels, your critical systems, your data that actually matters. Not everything is critical, and pretending everything is critical is the same as protecting nothing.

How?

How are you going to protect your what? Now, and only now, do tools, telemetry, and collection strategy enter the conversation. Your how should be a direct answer to your what, which is a direct answer to your why.

When you work the ladder in this order, your observation strategy builds itself. You know what data matters, because it maps to what you protect. You know what to collect, because it gives you visibility into those things. You know what is noise, because it doesn’t. And you can finally have an honest conversation about the cost of collection, because every log source either serves the mission or it is a bill you are paying out of habit.

When you skip the ladder, you get what most organizations have. Shelfware, alert fatigue, and a very expensive pile of data that answers no questions.

As folks who have been through this process, it is our responsibility to help those who haven’t. Too many people in our industry try to sell the newest widget instead of working with clients to understand their pains and giving them guidance on how to solve them. Even if it isn’t buying your widget. The organizations that achieve decision dominance are not the ones with the most dashboards. They are the ones where accurate, contextualized information gets in front of the right people in time to matter. Whether it is a watch floor spotting the first sign of an intrusion, an analyst trying to remember where they saw that IP before, or a leader deciding whether to wake people up at 0200 for a perceived incident, the loop turns on observation.

Observe deliberately. Orient honestly. Decide with confidence. Act.

That is the work. Everything else is downstream.