October is Cybersecurity Awareness Month, meant to be the month businesses talk about cyber awareness. This year, threat actors did the teaching. Some parts of the infosec community have dubbed it "Black October", and whatever you make of the name, it is worth pausing on what has happened.

Businesses are more connected than they have ever been: to software, suppliers, cloud platforms, open-source tools and, increasingly, physical equipment. Most of the time, those connections are precisely what make modern organisations work. This month has given us a glimpse of what can happen when one of them breaks.

 

Cybersecurity Awareness Month

October at a glance

1 OCT ··························· 31 OCT

11–12 OctFrench supermarket refrigeration attack14–15 OctZeabur credentials and secrets read17 OcteMudhra certificate keys problem reported21 OctRailway credential exposure (disclosed 21 Oct)21 OctLiteLLM malicious release21 OctPHP2Shell and Node.js fixes released

One month. One common thread: dependency.

Need some support?

If your team is still working through any of these issues, or you'd simply like a second opinion on where your business stands, you don't have to figure it out alone.

Our experts are here to offer guidance or a steer whenever you need it.

Call 0808 500 1436

1. Security flaws found in PHP, the software behind millions of websites

This will no doubt be the most prominent event for most reading this. If you had never heard of PHP before this month, you weren't alone. PHP is a programming language that helps websites and online services work. It runs behind the scenes, processing information and building the pages you see. When you fill in an online form or log in to an account, PHP may well be doing some of the work. It has been around since 1994 and sits underneath countless ecommerce sites, customer portals, intranets and content management systems, quietly doing its job while the business gets on with its own.

In October, two security flaws in PHP became public. Known together as PHP2Shell, they could, under certain conditions, let an attacker make a vulnerable server run their own instructions without needing to log in. Security updates were released on 21 October, but an attempt to exploit the flaws had already been recorded before the fixes were public. Some government websites were taken offline as a precaution, and suddenly a piece of software most people had never heard of was in the headlines.

It's worth keeping that in proportion. Taking a system offline to protect it is not proof that it was attacked, and using PHP doesn't automatically mean a business has been compromised. It means the business needs to check whether it's affected and act. The amount of news coverage is not a measure of your own risk.

At Intercity, we've carried out our own checks across the services, websites and applications we manage, and sought assurance from the technology vendors behind them. If your business is still checking, here are a few practical pointers:

  • Start with internet-facing systems. The National Cyber Security Centre advises prioritising these and applying security updates. If an affected system can't be updated or protected promptly, taking it offline may be necessary.
  • Ask each supplier what their answer covers. One supplier saying "you're fine" may not cover everything, because PHP can be built into other products you use. Check with whoever looks after your websites and web hosting, business applications, internet-facing systems, third-party software and services, and any applications installed outside your standard device build.
  • Be wary of quick fixes. Don't assume a tool has been properly checked just because it promises an answer to PHP. Researchers have found tools labelled "PHP2Shell" that didn't actually test for these flaws, and unverified code can contain malware. Ask your IT specialist to verify where anything came from and what it does before you use it.

If you're still checking

Ask these questions

Start with your IT team, website agency, hosting company and relevant software suppliers.

1Do we use PHP, including inside third-party products or software installed later?
2Are any affected versions present, and are those systems accessible from the internet?
3What have you checked, and what falls outside your checks?
4Have updates or temporary protections been applied, and how have you confirmed they work?
5If protection is temporary, when will the permanent fix follow?
6What still needs doing, who is responsible and when will it be completed?
7Which other suppliers do we need answers from to complete the picture?
Keep the answers in one shared listNote each system, who manages it, what has been checked and what still needs doing, with an owner and a due date. A simple spreadsheet will do. Keep "not yet checked" separate from "not affected", and update the list as answers come in.

 

2. A tampered update to a popular AI tool was designed to steal access details

 LiteLLM is a free, open-source tool that helps business software connect to AI models from providers such as OpenAI and Anthropic. On 21 October, a tampered version was published through the everyday channels developers use to download software. It was online for around three hours and is estimated to have been downloaded more than 49,000 times. It contained code designed to steal the passwords and keys that give access to cloud services and other business systems, and to give attackers a way back in. 

The good news is that security researchers spotted the malicious version within minutes, and it was removed the same day. The risk is limited to systems that installed or pulled the affected version on 21 October. If you use AI tools and aren’t sure whether LiteLLM sits behind any of them, it’s worth asking your IT team or suppliers.

 

3. Flaw discovered in Node.js, affecting web applications.

Node.js helps run a huge variety of web applications, from internal portals to customer-facing services. In October, a high-severity flaw was fixed in Brotli, a small part of Node.js that shrinks data so it can travel quickly between systems. Organisations then had to find where the affected software was running and make sure the fix was in place.

Modern applications are assembled from many components maintained by different people, so something very small can have a very large blast radius. Leaders don't need to understand Brotli. They need to know that if something buried in a critical service goes wrong, the business can find where it's exposed and respond quickly.

Small component, large blast radius

Customers and staff who use them

Applications built on it

Node.js

Brotli

If something buried inside a critical service fails, do you know where you're exposed?

 

4. Website security certificates linked to eMudhra had to be distrusted or replaced

When you visit a secure website, the padlock in your browser relies on a digital certificate. It's how your browser checks that the site you're connecting to is genuine. Those certificates are issued by trusted organisations known as certificate authorities.

Problems were identified with security keys linked to the infrastructure of eMudhra, one such certificate authority, and the affected certificates had to be distrusted or replaced. Suddenly the dependency wasn't simply a piece of software. It was trust itself.

Think about how much digital business rests on that concept. A customer trusts their browser. The browser trusts the certificate. The organisation relies on the authority behind that certificate. Each party depends on somebody else having done their job properly. That's the modern digital economy in miniature.

Cybersecurity therefore isn't simply about building higher walls around your organisation. Increasingly, it means understanding the chains of trust running through it. And that includes suppliers.

 

5. Passwords and access keys exposed at cloud platforms Railway and Zeabur

Railway and Zeabur help developers build and run applications in the cloud, which means holding passwords, access keys and other sensitive settings on their customers' behalf. October reports linked both platforms to incidents in which that information was exposed. For affected customers, the sensible response was to assume any exposed password or key was compromised and change it.

The lesson for leadership teams is that "our supplier handles that" is not the same as "we've handled the risk". You can contract out running a service, but not the business impact when it fails. If a critical supplier was attacked tonight, could you answer these questions tomorrow morning?

  • Would you know which services were affected?
  • Who would make the decisions?
  • How would you operate?
  • Who would speak to customers?
  • How long could you manage without that supplier?

 

6. Hackers altered the fridge settings in hundreds of supermarkets across France

On the night of 11 to 12 October, attackers compromised remotely controlled refrigeration systems used by hundreds of French supermarkets. Temperature and defrost settings were altered and some units reportedly reached up to 50°C for several hours. Fresh and frozen food had to be removed from sale, and small fires were reported at some sites.

This was a digital intrusion with physical consequences that staff and customers could see. For another business it could be manufacturing equipment, building access, payments, logistics or Microsoft 365. Knowing which systems your business can't operate without isn't an IT exercise. It's a business continuity exercise.

 

WHAT OCTOBER'S INCIDENTS TELL US ABOUT RESILIENCE

Look at these incidents individually and they seem very different. Zoom out and the same word keeps appearing: dependency.

The connections that make modern businesses fast and capable also mean a problem at a supplier, in a piece of software or in connected equipment can reach you without you ever being targeted directly. And with AI making weaknesses quicker to find, security through obscurity no longer holds. Understanding your gaps and dependencies has never mattered more.

None of this is a criticism of the teams who have spent this month patching, checking and reassuring. They are the ones absorbing the pressure of machine-speed threats, and leaders have a part to play in making sure that pressure is shared and sustainable. Resilience is about people as much as systems.

So when things settle, it may be worth asking a different question from "Are we secure?": "What do we depend on, and what happens if one of those things stops working?" A few practical starting points:

  • Who can take a critical service offline if it's compromised?
  • Who makes the business decision if a supplier calls at 2am?
  • Who speaks to customers if they're affected?
  • Is there another way of working if a key system is unavailable?

These aren't questions for IT alone, and they're far easier to answer together, calmly, than in the middle of an incident.