I Was Flying Blind

By Thursday afternoon, my corner of X was convinced the internet was about to die.

A pair of flaws in PHP, the software a huge part of the web runs on, had just gone public, and a pile of other breaches landed in the same couple of days. The feed said everything was going to break. The economy was going to crash. Everybody's life was about to be disrupted. Somebody called it Black October, and the name stuck.

It got my attention, and I'm glad it did, because when I asked my own AI to look, it turned out I had serious problems of my own.

My AI assistant scanned my complete business ecosystem and came back with a ranked list of things to fix - from critical to not-urgent. It surfaced two items I needed to fix urgently - both on apps I'd built (one for me and one for a client).

In plain speak there was a flaw that would allow a bot or bad actor to create logins in the apps and do who knows what.

This is probably a good time to tell you… I'm not a developer or a cyber-security expert.

Yet, for the last six months I've been building things I'd never built before like full web apps.

These are more involved than just a regular website. These apps come with databases, logic, paywalls, logins, etc. and I build them all with AI doing the building.

So I admit this humbly… beyond what I wanted them to do and how I wanted them to look, I didn't know how any of them were built, and I didn't know what they needed from a security standpoint.

I have been flying blind.

When my AI came back with the list of security risks, I asked it to implement the fixes the apps needed.

• It upgraded and redeployed both apps.
• It checked every property of mine (and my clients) to ensure nothing was running with PHP (none were).
• It found old copies of two of my apps and deleted them.
• It wrote down every key and password my business runs on, and found one secret that was readable on a live page.

And here's the impressive part. It addressed everything while I was getting my daughter ready for school.

That's when it hit me that this week was the clearest case for going AI-Native I'd seen.

Then I thought about how that would sound to somebody who knows security.

Because the honest version of my story is that the holes were there in the first place because I built apps with AI without knowing how they worked.

If you work in security, I'm exactly who you were worried about this week: a business owner shipping apps with passwords and payments in them, with no idea what's going on under the hood.

And a second objection was waiting behind that one, which I'd been half making myself. Isn't AI the reason all of this is happening? It's hard to watch a week like this one and not assume AI had a hand in it.

So before I could say any of this out loud, I had three things to settle:

• What Black October was, and what it wasn't.
• Whether AI is the villain here.
• Whether someone like me has any business building apps at all, which is the question the critics would ask first, and the one I owe the straightest answer.

What Black October was (and what it wasn't)#

(As of October 23, 2026. The details will keep moving, and the sources are at the end.)

The core of it was real.

Two critical flaws in PHP made it possible for a stranger to run their own code on a website's server without logging in. PHP rated both 9.2 out of 10 for severity and released the fix on October 21 with a blunt note: updating is the only safe choice.

Nearly every version of PHP going back to 2012 was affected, and the researchers who found the flaws showed the attack working against WordPress, among others.

And it didn't stay a developer problem. Most of the conversation online happened in shorthand between coders and security researchers, which made it easy for everyone else to tune out.

This one reached ordinary life anyway.

Governments didn't wait to find out what would happen. On the day the fix came out, council websites in Edinburgh and Oxford and the Metropolitan Police's site were among those that went offline in Britain, where the national cyber security agency had told organizations to consider taking unpatched systems down.

Luxembourg's government took some of its own services offline as a precaution, and the head of Luxembourg's House of Cybersecurity said well over 5,000 websites there were affected.

There were shutdowns in the Netherlands, Finland, France, Germany, Belgium and Denmark too, mostly precautionary. The NSA told organizations to patch right away or take their sites offline until they could.

Once the flaws were public, attack attempts jumped from thousands to millions, according to Cloudflare's CEO. And in the same few days, more breaches were announced, one after another, from a cloud hosting company to Quest Diagnostics, which told regulators that someone had gotten into one of its systems and that it believes patient records were accessed.

So it was serious.

What it wasn't was the end of the internet. But it was a loud warning that we all need to pay attention to.

As of the latest reports, none of the agencies that went offline had confirmed a break-in. The shutdowns did their job, which is a credit to the people who scrambled to patch, and it's no reason for the rest of us to relax.

Because Black October wasn't a one-week story either.

Some of the attacks announced that week had been running for weeks or months before anyone noticed. And these flaws were found because AI can now read old code at a scale no team of people could.

One security company found the same PHP flaws simply by asking an AI model to find bad vulnerabilities in PHP. If finding them is that easy now, there are more out there to find, and the people looking aren't all on the same side.

A cryptographer at Johns Hopkins put it bluntly: the whole internet is dry tinder.

If you run your website on WordPress, Black October was your problem this week whether you knew it or not. You, or your web person, or your host had to deal with it. Some hosts patched on their own, and two of my clients' main sites were on hosts like that. One client's site wasn't, and nobody would have known until somebody checked.

Which brings me to the thing I'd assumed going in.

Whether AI is the villain here#

When I first heard about the sheer scale of the attack, I assumed AI was to blame.

AI has given us the ability to do almost everything at scale, and I couldn't imagine this would have happened without it.

Turns out, that assumption is only half correct.

The scale part is true. AI gave attackers the ability to attack millions, not just thousands of vulnerabilities.

But AI didn't put the flaws in PHP.

A human did - whether it was deliberate or not - over a decade ago.

And turning a flaw like that into a working attack still takes a skilled person, too. AI speeds that person up, and the skill is still theirs.

So I've landed on neutral ground about the AI.

It's the human we should take issue with.

The evil behind an attack comes from people. What AI did this week was accentuate bad people and their behavior.

So the responsibility falls on us. Because if AI magnifies whatever it's pointed at, it's up to us to point it at good.

Which brought me back to the question I'd been putting off, the one about me.

Whether someone like me should be building apps at all#

The objection, in its strongest form, goes like this: people who don't know how their app is built shouldn't be shipping apps with passwords and payments in them.

I agree with the critics on more of that than they might expect. Before this week I wasn't doing the safety checks, and that was wrong.

Where I part ways with them is the idea that the answer is to understand how every piece of security works.

Knowing that security is my job is one thing, and knowing how to implement every aspect of it is another.

The way I think about it now, I'm the pilot flying the plane. The pilot's job is the preflight safety checks: walk around the plane, run the list, and refuse to take off until every item passes.

Making the checks pass is the mechanic's job, and AI is my mechanic.

The pilot doesn't need to know how to rebuild the engine, as long as she never skips the preflight checks.

So why did my mechanic build apps with holes in them?

It's the obvious question if you believe, as I do, that AI is smarter than me and smarter than any IT person I could hire, and a heck of a lot faster.

The answer is that a mechanic works to the job it's given.

I was flying blind when I built those apps, so I didn't know what to ask for, and I most likely never told the AI that iron-clad security was part of what success looks like.

It built to the standard I gave it, and nobody checked until this week. (That one's on the pilot, and I'll own it.)

But then a stranger on X did me a real favor. Someone whose apps had been hacked shared a list of checks, and my AI ran it on my apps.

It found a page that would sign anyone in as an admin, an app meant to be invitation-only that would let anyone sign up, and a paid feature that members could switch on for themselves. All of it was closed the same day, and that check now runs on the first of every month.

The critics are right that you shouldn't ship without the checks, and with AI as your mechanic, running them is something any owner can do.

Now I run the checks, and every new build starts with me telling the AI what success looks like, security included.

Which leaves the owner who isn't building anything at all, and that's the person I think this week matters most for.

What it adds up to#

With all three answers on the table, the same pattern ran through every one of them.

The human is the X-factor: the attackers pointing AI at harm, the builders like me flying blind, and the owners deciding right now how their business is set up to respond when the next one lands.

That last group is most people.

Most of the business owners I work with aren't building apps. They're on WordPress, or Squarespace, or a platform like GoHighLevel, or a site somebody built for them years ago, and this week they had to lean on a person to figure out what was going on, come up with a plan and carry it out. Some of them are still waiting.

From my side, the week looked different, and it's the part I keep coming back to.

I didn't have to log into my host. I didn't have to research a fix. I didn't have to carry that low hum of worry that I was missing something or doing something wrong.

My AI researched the threat and fixed everything, for me and for my clients, because my business lives in my own files and everything is connected where my AI can reach it.

It went the same way for the smaller scares that came with it. In the middle of the week Stripe emailed to warn that my setup might be running a vulnerable version of Node.js, and that my keys might have been exposed.

As far as I knew, I'd never set up Node.js with Stripe myself, so my first question was whether the email was even real. My AI checked that it was, worked out that it was most likely about the payment forms I run through GoHighLevel rather than anything I'd built, and patched three functions on my own sites against the same flaw while it was there.

And when GoHighLevel said they'd patched everything, I asked my AI to run a real end-to-end test of my live sites anyway. A vendor saying it's patched is a good place to start, and checking the live site is how you find out where you stand.

That's the case for going AI-Native I'd make to anyone this week: when something goes wrong, your AI can see your whole business and fix it the same day.

Going AI-Native doesn't make you safe, and my own apps are the proof.

What it gives you is the ability to find out where you stand, and act, without waiting on anyone.

I don't think PHP is the villain either. It's older technology that runs a huge share of the web and needs a lot of upkeep, which is exactly why one flaw in it could reach so far. There will be risks in every technology, now and later, including whatever we're all building on next.

Some readers will reach the end of a week like this and ask whether AI should be regulated, so bad actors can't abuse it, and us along with it. It's a fair question, and it's one I think every reader has to answer for themselves.

What I'm sure of is that we have to take responsibility, individually when we build and together as a society.

The morning after#

I keep thinking about how ordinary that morning was. My daughter was getting ready for school, and my AI was finishing work some businesses were only starting.

Black October was loud, and it was a real wake-up call, for me first. I think it's just the beginning of what we're going to see, and that's the reason to get ready now, before the next one.

Button up your digital presence, keep everything squeaky clean, and keep your security tight.

So the question I'd leave you with is what kind of business you want to be the morning after the next one: the one waiting on somebody to tell it what happened, or the one whose AI already fixed it.

The preflight checklist#

If you want to start where I did, these are the ten checks my AI ran. You don't need to know how security works to run this list, as long as you run it, and then run it again next month.

If your business handles health records, card numbers or other regulated information, have a professional look as well.

1. Is everything up to date? The software your site or app is built on gets security fixes, and you have to be on the fixed version.
2. Who can see what, logged out or with a free account? Assume a stranger can reach anything your site exposes to the internet. Every person should see only their own information.
3. Can anyone change or delete what they shouldn't? A stranger shouldn't be able to wipe your data, deleting one thing shouldn't quietly delete others, and nobody should be able to give themselves a paid plan or admin powers by editing their own profile.
4. Does every door check who's knocking? Each sign-in and each behind-the-scenes action should confirm who someone really is, not take their word for it, and no test shortcuts should be left in. An email address or an account number is never a password.
5. Where are your keys, and who can see them? Keep a list of every password and access key your business runs on: where each one lives and what it opens. Nothing secret goes in the code or on a public page, and keys you no longer use get cancelled.
6. Are your automatic jobs locked when nobody's watching? Scheduled tasks, and messages coming in from other services like payment forms, should refuse to run unless they can prove who sent them.
7. What's still switched on that you stopped using? Old copies of your site or app that are still online, retired tools still running behind the scenes, accounts you've left behind. Turn them off and delete them.
8. If something goes wrong, can you recover? Backups that work, a copy of anything that gets deleted, a limit on how much can be deleted at once, and an alert if your data suddenly shrinks.
9. Is that security warning real? When a vendor emails a warning, check it's genuine before you click anything, then find out what it's about.
10. Do it again next month. One check tells you about today. Put it on a schedule.

Hand it to your AI

Copy this into the AI that can see your project, for example Claude Code opened in your project's folder. It checks first, explains what it finds in plain words, and asks before it changes anything.

I'd like you to run a security preflight check on my project. I'm the pilot and you're my mechanic: I'm not a developer, so explain everything in plain language.

Ground rules:
- Check first. Don't change, delete or deploy anything until you've shown me what you found and I've said yes.
- Never show me the full value of a password, key or token. Tell me where it lives and what it opens.
- Don't run anything that could delete data or take my site down.
- If you can't check something, say so plainly instead of guessing.

Assume a stranger can reach everything my site or app exposes to the internet, logged out or with a free account of their own. Then check these ten things:

1. Up to date: list the software my project is built on and flag anything with security fixes I haven't installed.
2. Who can see what: what can a logged-out visitor, or a brand-new account, read? Each person should see only their own information.
3. Change and delete: can a stranger delete or wipe data? Does deleting one thing quietly delete others? Can anyone give themselves a paid plan, a trial or admin powers by editing their own profile?
4. Every door: does every sign-in and behind-the-scenes action confirm who someone is from their verified login, instead of trusting what they send? Are any test shortcuts or temporary bypasses left in? Is an email address or account number ever treated as proof of identity?
5. Keys: list every password and access key the project uses, where each lives and what it opens. Flag any that sit in the code, on a public page, or belong to a service I no longer use.
6. Automatic jobs: do scheduled tasks and incoming messages from other services (payments, forms) refuse to run without their secret, and check who sent them?
7. Still switched on: old copies of my site or app still online, retired tools still running, accounts I've stopped using.
8. Recovery: do I have backups that work? Is deleted data copied somewhere? Is there a limit on how much can be deleted at once, and an alert if my data suddenly shrinks?
9. Warnings: if I paste a security email from a vendor, check whether it's genuine and what it's about before I click anything.
10. Next month: set this check up to run again on a schedule, or tell me how.

For each finding, tell me what's wrong in plain words, what someone could do with it today, how serious it is (critical, high, medium or low), and the fix you'd make. Then wait for my go-ahead before fixing anything, starting with the most serious.

No AI connected to your site yet?

If your site runs on WordPress, Squarespace or a platform someone else manages, your AI can't see inside it yet. You can still use this list. Paste the ten checks into ChatGPT or Claude and ask it to turn them into plain questions for your web person or your host, then send those questions this week.

It's also worth asking yourself how long you want every answer to depend on someone else.

Where the numbers come from#

As of October 23, 2026. Black October is still developing, so check these before relying on them.

• The PHP flaws, the 9.2 rating, the October 21 fix and "updating is the only safe choice": PHP's security advisory and release notes, 20 and 21 October 2026, php.net. The two flaws are CVE-2026-109618 and CVE-2026-109619.
• The versions affected and the WordPress demonstration: Wiz Research, "PHP2Shell," 21 October 2026, wiz.io. Affected versions go back to PHP 5.4, released 1 March 2012 (PHP changelog).
• The UK sites that went offline, the national cyber security agency's advice and no confirmed break-ins: "UK councils and Met Police among sites pulled offline after NCSC alert," Insurance Business, 21 October 2026, insurancebusinessmag.com.
• Luxembourg's precautionary shutdown, "well over 5,000 websites," and the other European shutdowns: "PHP2Shell: thousands of websites exposed in Luxembourg," Paperjam, October 2026, paperjam.lu, quoting Pascal Steichen, director of the Luxembourg House of Cybersecurity.
• Quest Diagnostics: the company's Form 8-K filed with the SEC, signed 22 October 2026, sec.gov. The filing doesn't say how the system was accessed or tie it to the PHP flaws.
• How the flaws were found, and the AI prompt: Wiz Research (above) credits AI models and its own tools, working with OpenAI and Calif. Chainguard's CEO on finding the same bugs by asking an AI model to "find bad vulnerabilities in PHP" is as reported by 404 Media.
• Thousands to millions of attempts, the NSA's guidance, "dry tinder," and the skill it still takes: Jason Koebler, 404 Media, 22 October 2026 (above), quoting Cloudflare CEO Matthew Prince, Johns Hopkins cryptographer Matthew Green and Trail of Bits CEO Dan Guido.
• The "Black October" name and the attacks that predated the headlines: Alec Chizhik, "Black October: Many attacks had been running for months," SecurityToday, 22 October 2026, securitytoday.de.