On this page
- What happened in October 2026
- Lesson 1: AI has changed the volume and speed of risk
- Lesson 2: Patch speed is now a business capability
- Lesson 3: You can't protect what you can't see
- Lesson 4: Your suppliers and developer tools are part of your attack surface
- Lesson 5: The basics still decide most outcomes
- Eight questions to ask your security team before the end of the year
- Looking ahead: awareness is a year-round job
Cybersecurity Awareness Month 2026 is over, and it taught a lesson no poster could: the time between a flaw being found and attackers using it is now measured in days. Researchers nicknamed last month "Black October". It brought a critical flaw in a language that runs much of the web, mass attacks on corporate firewalls, and breaches of the tools developers rely on.
The National Cybersecurity Alliance's theme for 2026 (opens in a new tab) was "Don't Make It Easy for Them." October showed business leaders what that means in practice. Most of the month's damage fell on organisations that patched slowly, didn't know what software they ran, or trusted suppliers too readily.
This article sets out five lessons from October 2026 and eight questions every executive should ask their security team before the end of the year.
What happened in October 2026
Three events defined the month for business leaders.
PHP2Shell. Researchers using AI found two critical flaws in PHP, the language behind a large share of websites. Both let attackers take over a web server without logging in. On 21 October, governments and companies took websites offline to patch (opens in a new tab). Within five days, CISA had added both flaws to its Known Exploited Vulnerabilities (KEV) catalogue (opens in a new tab) and given US federal agencies three days to fix them. By 27 October, researchers at Delft University had logged more than 60,000 exploit attempts (opens in a new tab) from over 600 IP addresses in more than 70 countries.
Edge devices under siege. A group called k0t broke into organisations around the world through exposed firewalls and VPNs, exposing more than 70,000 credentials, according to Group-IB and NyxLab (opens in a new tab).
Supply chain breaches. Attackers published a malicious version of LiteLLM (opens in a new tab), a popular tool for connecting applications to AI models, built to steal credentials. A separate campaign, GhostAction (opens in a new tab), hijacked about 1,900 GitHub accounts to steal secrets.
For the full picture, see our Black October roundup of the month's research findings (opens in a new tab).
Lesson 1: AI has changed the volume and speed of risk
AI is finding software flaws faster than ever, so more urgent fixes are landing on your teams. Google's Threat Intelligence Group counted (opens in a new tab) about 5,000 vulnerability disclosures in January 2026. By August, the monthly figure had reached a record of more than 10,700. VulnCheck estimates that AI helped roughly double (opens in a new tab) the number of flaws found compared with a year earlier.
That isn't a reason to panic. VulnCheck also found that only about 1.3% of AI-discovered flaws were exploited (opens in a new tab) in the first half of 2026, roughly the same rate as for all other flaws. What has changed is the speed. The median time from a flaw's public disclosure to confirmed exploitation fell from about 120 days in 2025 to 80 days.
What this means for you: fixing everything is impossible, so the job is now to fix the few flaws that matter, fast. That takes good prioritisation, not just more staff.
Lesson 2: Patch speed is now a business capability
PHP2Shell showed how little time organisations have:
- According to Amazon (opens in a new tab), attackers were probing for the flaw four days before the fix was released.
- On 24 October, three days after the patch, attackers were recorded taking control of servers (opens in a new tab).
- CISA then gave US federal agencies just three days to fix it.
Many organisations still treat patching as routine IT maintenance on a monthly cycle, and that no longer matches the threat. When a critical flaw lands, taking a service offline briefly to patch it is a business decision, and it has to be made within hours.
What this means for you: agree three things in advance:
- who can authorise emergency downtime;
- your target time to patch a critical flaw;
- how you'll tell customers about a short outage.
The organisations that took their websites offline on 21 October weren't failing. They were acting fast.
Lesson 3: You can't protect what you can't see
During PHP2Shell, every security team faced the same first question: where do we run PHP? Many couldn't answer it quickly.
- Where PHP hides: inside websites, hosting panels, container images, cloud workloads and vendor products.
- Vendor products: they may need their own update (opens in a new tab), even after the server itself is patched.
- After the KEV listing: the hard part became finding which systems still ran a vulnerable version, and who owned each one (opens in a new tab).
Outdated technology makes this worse. Modat found (opens in a new tab) that about 79% of 4.38 million internet-facing PHP services ran versions that PHP no longer supports. Those systems got no new official release, so their owners had to rely on backports or paid extended support.
What this means for you:
- Fund a live inventory of the software you run, including what's inside vendor products.
- Treat end-of-life software as a business risk, with an owner and a retirement date.
Without that, every emergency starts with days of searching.
Lesson 4: Your suppliers and developer tools are part of your attack surface
Several of October's biggest incidents didn't start inside the victim's network. They started in the tools and packages organisations trust.
- LiteLLM: the project shipped a malicious release (opens in a new tab) that stole cloud keys, AI provider keys and passwords. The attacker got in through hijacked engineer accounts. It was the project's second compromise of the year, after an attack in March (opens in a new tab) that came through a poisoned security scanner.
- GhostAction (opens in a new tab): this campaign planted malicious automation files in tens of thousands of code repositories to steal secrets.
AI tools add a new layer of risk. As teams experiment with AI agents and plug-ins, those tools often hold powerful keys to company systems, and AI products are increasingly targeted themselves (opens in a new tab). Of 28 known exploited flaws in AI systems, 10 have been exploited.
What this means for you: ask which AI tools and open-source components your teams use, who approved them, and what access they hold. Short-lived credentials and fast secret rotation turn a supplier breach from a disaster into an inconvenience.
Lesson 5: The basics still decide most outcomes
For all the talk of AI, many of October's attacks relied on familiar weaknesses.
Exposed edge devices. The k0t group didn't research its victims. It scanned the internet for exposed firewalls and VPNs and broke into whatever it found. What mattered was the product and whether it was exposed, not the victim's industry, as Group-IB and NyxLab found (opens in a new tab). Being a smaller or less well-known company is no protection.
People. The ROMULUS campaign (opens in a new tab) used ClickFix, a trick that persuades people to paste and run a malicious command themselves, slipping past email and endpoint defences. Other attackers delivered iPhone spyware through ads and hijacked website scripts (opens in a new tab), which put executives' phones at risk during ordinary browsing.
What this means for you:
- keep management interfaces off the internet;
- require multi-factor authentication everywhere;
- update phones promptly;
- train staff on today's tricks, not last decade's.
These are exactly the habits this year's awareness month promoted, and they still stop most attacks.
Eight questions to ask your security team before the end of the year
Use these to turn October's lessons into action. Clear, specific answers are a good sign. Vague ones show you where to invest.
- 1Are we fully patched for PHP2Shell, and did we check for signs of compromise from before the patch? It's now confirmed as actively exploited.
- 2How long does it take us to patch a critical, internet-facing flaw? Do we measure it, and what's our target?
- 3Who can approve emergency downtime, and how fast? Is that written down?
- 4Do we have a current inventory of the software we run, including inside vendor products and containers?
- 5What end-of-life software are we still running, and when will each piece be retired?
- 6Which AI tools, agents and open-source components are in use, and what access do they have?
- 7Which firewalls, VPNs and admin portals are exposed to the internet, and are they all patched and protected by multi-factor authentication?
- 8How quickly could we rotate every key and password if a supplier were breached?
Looking ahead: awareness is a year-round job
Experts expect October's pace to continue. Cloudflare's chief executive has said (opens in a new tab) he expects a couple of years in which every week feels like a crisis, as AI keeps surfacing old bugs. Exploitation is also spreading: botnet operators have joined the PHP2Shell attacks (opens in a new tab), a sign that a flaw's reach widens quickly once working attack tools circulate.
There's good news too. With PHP2Shell, AI helped defenders find the flaws before attackers did, and the same tools are increasingly available to security teams. CISA's 2026 theme, "Securing the Next 250" (opens in a new tab), frames security as long-term work, not a once-a-year campaign.
Awareness month may be over, but its lesson for leaders is simple: speed, visibility and trust in suppliers are now board-level issues. The organisations best placed for the next Black October will be the ones that know what they run and can act on it within hours.



