It has been one of the busiest weeks in cybersecurity in years. A flaw in PHP, the language behind most of the world’s websites, sent companies, governments and even banks scrambling to take sites offline. A popular AI tool was hijacked to steal passwords and keys. India’s largest bank confirmed customer data on the dark web, US banks found unvetted AI agents inside customer accounts, and a game giant, a developer platform and school districts all reported attacks.

If you run a business, you don’t need to follow every headline. You need to know which of these could touch you, and what to do about it. This article gives you both, in plain English.

The short version: if you have a website, ask whoever manages it whether PHP has been updated this week. If your team builds with AI tools, check whether anyone uses LiteLLM. If you use any service that told you to “rotate your keys”, do it today. And never give your bank login to an AI assistant.

Diagram of a typical business setup: customers, website or shop on PHP, hosting or cloud, and an AI gateway connecting to AI models. Red tags mark where this week's incidents hit: account leaks at Capcom and SBI and AI agents in bank logins, PHP2Shell on the website, the Railway breach in hosting, and the LiteLLM fake release in the AI gateway, each with one action to take.
Where this week's attacks hit a typical business, and the one thing to do for each.

This list covers attacks reported between 17 and 22 October 2026. We link to the original sources, and we say clearly where facts are still unconfirmed.

This week's cyber attacks at a glance

Not every item below is the same kind of event. Some are breaches (attackers got in and took something). Others are vulnerabilities (a weakness that attackers could use if you don’t fix it). We label each one.

# What happened Type Date Who should care
1 PHP2Shell: two critical flaws in PHP itself Vulnerability, actively targeted Fix released 21 Oct Anyone with a website on PHP (WordPress, WooCommerce, Drupal, Magento and many more)
2 LiteLLM: hijacked release of a popular AI gateway stole passwords and keys Supply-chain attack 21 Oct Teams building with AI models
3 State Bank of India (SBI): 3,897 customer records confirmed on the dark web Data leak Filed 21 Oct SBI customers in India
4 US banks: unvetted AI agents found inside customer accounts Account security risk Reported 22 Oct Bank customers using AI assistants
5 Banks take sites offline for PHP2Shell: MUFG, Nomura, Bangladesh Bank and others Precautionary shutdown 21-22 Oct Banks and financial firms everywhere
6 Railway: developer cloud platform says secrets may have been accessed Breach 21 Oct Businesses hosting apps on Railway
7 Capcom: 11.77 million CAPCOM ID records exposed Breach Announced 22 Oct Gamers with a CAPCOM ID
8 OpenCode: stolen AI API keys ran up users’ bills Breach 17 Oct Developers who stored AI keys in OpenCode Console
9 eMudhra: weak keys in eight website-security certificates Security failure Reported 17 Oct Mostly IT teams; browser users are already protected
10 Arista VeloCloud: network management zero-day exploited Vulnerability, exploited 22 Oct Companies using VeloCloud SD-WAN
11 Schools in Virginia and Idaho hit by ransomware Breach and disruption 17-21 Oct Schools and public bodies
12 Ahold Delhaize (Stop & Shop, Albert Heijn and others) restores services Recovery from earlier attack Updates 19-20 Oct Retailers and grocery customers
Timeline from 17 to 22 October 2026. 17 Oct: first PHP2Shell attempt seen by AWS, OpenCode AI keys stolen, eMudhra certificates blocked, Idaho schools hit. 18-19 Oct: Jerome schools close, Ahold Delhaize restoring sites. 20 Oct: PHP flaw details leak. 21 Oct: PHP fixes released and sites go offline, LiteLLM fake release, Railway secrets exposed, SBI confirms 3,897 records, Richmond schools ransom notes. 22 Oct: Capcom 11.77 million IDs, US banks find AI agents in accounts, MUFG, Nomura and Bangladesh Bank take services offline, Arista zero-day, eMudhra exits.
The week at a glance: 17-22 October 2026.

1. PHP2Shell: the flaw that put most websites at risk

On 21 October, the PHP project released urgent fixes for two critical flaws in PHP itself, not in any one website or plugin (php.net). An attacker who doesn’t need a password could use them to take control of a web server. The US cyber agency CISA told organisations to patch immediately.

Amazon says it saw someone try to use the flaw on 17 October, four days before the fix was public (AWS). Some government and business websites in the Netherlands and Japan went offline as a precaution (Patchstack timeline). More below.

2. LiteLLM: an AI tool turned into a password stealer

LiteLLM is free software that lets apps talk to many AI models, such as OpenAI, Anthropic and Google, through one connection. On 21 October, attackers used stolen developer logins to publish a fake version (1.107.0) through LiteLLM’s own release system. For about two hours, anyone who downloaded it got software that quietly stole cloud passwords, AI keys and browser logins (LiteLLM). More below.

3. State Bank of India: customer data on the dark web

India’s largest bank told the stock exchanges on 21 October that it “has experienced an incident involving the loss of certain data”. In a first look at about 375,000 records offered on the dark web, SBI found 3,897 customer records with personal details such as names, mobile numbers, dates of birth, addresses and loan details (The Hacker News, The Hindu). Account numbers, passwords, OTPs, card details, PAN and Aadhaar are not among the data types SBI listed. More below.

4. US banks: AI agents inside customer accounts

Axios reported on 22 October that major US banks are finding third-party AI agents operating inside customer accounts, some trying to take actions customers didn’t ask for, such as contacting call centres. Reuters said it could not immediately verify the report (Cybersecurity News summary). This is mostly not hacking in the usual sense: it starts when customers hand their bank login to an AI assistant. More below.

5. Banks and governments take websites offline

As PHP2Shell fixes arrived, organisations around the world switched off websites until they could patch. Japan’s MUFG and Nomura suspended some online services, Bangladesh Bank took its website offline on 22 October as a precaution, and government, hospital and media sites across Europe did the same, according to The Business Standard, citing AFP. These were precautions, not confirmed break-ins.

6. Railway: customer secrets may have been accessed

Railway, a platform where developers host their apps, said on 21 October that an attacker may have accessed customers’ stored settings, including passwords and API keys, and decrypted some of them (Railway). It asked all users to change every stored key, paused deployments, and on 22 October was still restoring services for some plans (status page). Railway says it believes the attack was part of a wider campaign aimed at AI providers. It has not yet said how the attacker got in.

7. Capcom: 11.77 million account records

Capcom, the company behind Street Fighter and Monster Hunter, announced on 22 October that someone had broken into its CAPCOM ID account service. About 11.77 million email addresses and related account data were exposed, and passwords were changed on 196 accounts. Capcom says no credit card data was leaked (Automaton). If you have a CAPCOM ID, expect phishing emails and change your password.

8. OpenCode: stolen AI keys ran up bills

OpenCode, an AI coding tool, said on 17 October that attackers broke into an older system and reached the AI keys of 1.4% of users of its online console. Developers reported surprise charges on their AI accounts, some above $1,000. AI providers blocked the exposed keys and refunds are underway (TechCrunch).

9. eMudhra: website certificates with guessable keys

eMudhra, an Indian certificate authority, issued eight intermediate certificates whose secret keys could be worked out almost instantly. One key was simply the number 4. Chrome and Firefox blocked them on 17 October, and Apple and Microsoft followed (BleepingComputer). Google says it found no forged website certificates using them. Ordinary browser users don’t need to do anything. On 22 October, eMudhra said it would leave the global certificate business (Indian Express).

10. Arista VeloCloud: another exploited zero-day

Arista warned on 22 October that attackers are exploiting a new flaw (CVE-2026-114625) in VeloCloud Orchestrator, which companies use to manage their wide-area networks. Fixes are available for on-premises systems (BleepingComputer). It is the third exploited flaw in this product since July.

11. Schools: ransom notes and locked doors

Richmond Public Schools in Virginia took its network offline on 21 October after ransom notes appeared on teachers’ laptops (Cybernews). Over the weekend of 17-18 October, attackers took control of cameras, door locks and heating at Idaho’s Jerome School District, closing schools (KMVT). Neither district has confirmed what data, if any, was taken.

12. Ahold Delhaize: grocery sites come back

The owner of Stop & Shop, Food Lion, Albert Heijn and other brands disclosed an attack on 12 October and took websites and apps offline. In updates on 19 and 20 October it said European services were mostly restored, US online shopping was returning, and it had found no evidence that sensitive customer data was taken (The Register, Grocery Dive). Stores stayed open throughout.

PHP2Shell explained: is your website at risk?

What PHP is, and why this one is different

PHP is the programming language that runs behind a large share of websites, including most sites built on WordPress, WooCommerce, Drupal, Joomla and Magento. Usually a website security problem sits in one plugin or one app. PHP2Shell is different: the weakness is in PHP itself, so a website can be vulnerable even if its own code is perfectly written (Wiz).

In simple terms, PHP could get confused when a web request used up its memory at exactly the wrong moment, or when one request left behind data that the next request trusted. A carefully crafted request could turn that confusion into control of the server. The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and both are rated critical (PHP Foundation).

Researchers at Wiz also showed the flaws could leak pieces of server memory, which may include passwords and session tokens, even without taking over the server.

Has anyone actually been hacked?

This is where the reports differ, so it is worth being precise:

  • Attempts: yes. Amazon saw an attempt on 17 October and more on 21 October, and says the flaw is “now being broadly exploited”. Cloudflare and Patchstack also reported attack traffic (AWS, Patchstack).
  • Confirmed break-ins: not publicly documented yet. Amazon says it is unclear whether the early attempts would have worked. CISA said it had not seen exploitation when it published its alert on 21 October. As of 22 October, CISA had not added the flaws to its list of known exploited vulnerabilities.

Given how quickly exploit code spread, treat any unpatched, internet-facing PHP site as at real risk.

Which versions are fixed?

If you run Update to
PHP 8.5 8.5.12
PHP 8.4 8.4.27
PHP 8.3 8.3.36
PHP 8.2 8.2.35
PHP 8.1 or older Ask your hosting company or software vendor for a patched build, or upgrade. These versions no longer get official updates

Source: php.net security advisory. Linux distributions and hosting providers may ship the fix under their own version numbers, so check your provider’s notice rather than the number alone.

What to ask your developer or hosting company

You don’t need to be technical to handle this. Send these questions:

  1. “Which PHP version are our websites, shops and internal tools running, including staging sites?”
  2. “Have they been updated to a fixed version since 21 October, and have the web servers been restarted?”
  3. “Do any of our other products or appliances include PHP inside them?”
  4. “If anything can’t be updated today, can we take it offline or put it behind a firewall until it can?”
  5. “Have we checked our logs for signs of attack since 17 October?”

If you use managed hosting for WordPress or a shop platform, your provider may already have patched. Ask them to confirm in writing.

PHP’s official advice is clear that the temporary configuration workarounds circulating online reduce the risk but don’t remove it. Updating is the only complete fix. Avoid “fix” plugins or code snippets from unknown sources.

The LiteLLM hack explained: why AI tools are now a target

What LiteLLM does

Many businesses using AI don’t connect to one model. They use several, from OpenAI, Anthropic, Google and others. LiteLLM is a widely used free tool that sits in the middle as a gateway: one place to route requests, track spending and store the keys for every AI provider. That makes it very convenient. It also means one copy of LiteLLM can hold the keys to everything.

What happened on 21 October

According to LiteLLM’s own report:

  • Attackers got hold of login tokens belonging to three LiteLLM developers.
  • They used them to switch off safety checks and run LiteLLM’s real release process, but pointed it at a lookalike copy of the code (Berri-AI instead of BerriAI).
  • The poisoned version, 1.107.0, went out through the official download channels. It was live on PyPI (the main Python download site) from 11:39 to 13:23 UTC, and in the official Docker images until 14:20 UTC.
  • Anything that installed or started it ran hidden code that collected cloud passwords, AI keys, SSH keys, browser logins and the keys stored inside LiteLLM, and sent them to the attackers. It also set up a back door that checked for new commands every hour.

Security firm Wiz says it then saw the attackers testing stolen Amazon Web Services credentials and checking which AI models they could use, about four and a half hours after theft (The Hacker News, citing Wiz). Stolen cloud keys are often used to run up AI bills on someone else’s account, a practice known as “LLMjacking”.

LiteLLM’s paid enterprise customers, who use a separate private download source, were not affected.

How the attackers got the developer logins

This part is still being investigated, and it is the most important lesson. LiteLLM believes the attackers got into an internal copy of LiteLLM that was reachable from the internet, possibly through a recently patched flaw. Inside its logs, they found the developers’ GitHub login tokens. LiteLLM says it found cases where an AI coding assistant (Claude Code) placed a GitHub token in a response, which then ended up in LiteLLM’s request logs.

In other words: a tool that logs AI conversations can end up storing passwords, and if that tool is exposed to the internet, those logs become a target. LiteLLM has not confirmed the full chain yet.

This was also LiteLLM’s second hijacking in 2026, after a separate attack in March (BleepingComputer). Researchers have not linked the two. CISA’s catalogue also lists three LiteLLM flaws exploited in attacks earlier this year, so internet-facing LiteLLM servers need regular patching anyway.

Am I affected?

You are likely affected only if all of these are true:

  • Someone in your company, or a supplier building for you, uses LiteLLM.
  • They installed it without fixing the version, or used the latest-style Docker images.
  • They did so during the hours above on 21 October.

If so, LiteLLM’s advice is to assume every secret on that machine or server was stolen. In practice that means:

  1. Don’t just run the normal update command. The hidden code runs again every time Python starts, including during an update. Follow LiteLLM’s clean-up steps, or better, rebuild the server or container from scratch.
  2. Install version 1.106.2 or another release from before 21 October, and fix that version in your settings.
  3. From a clean computer, change every password and key that machine could reach: cloud accounts, AI provider keys, database passwords, code hosting tokens.
  4. Check your cloud and AI bills and logs for activity you don’t recognise.

If you don’t use LiteLLM directly, ask your developers and any agency building AI features for you.

Banks this week: SBI, US banks and what customers should do

SBI: what was exposed, and what wasn’t

SBI says it was alerted on 16 October by its threat intelligence provider, CERT-In and the Defence Cyber Agency, and has brought in an independent security firm. It says the incident has no material impact on its operations (The Hacker News). Some important points are still open:

  • Where the data came from is not yet known. SBI’s filing doesn’t say whether its own systems, a subsidiary or a supplier was breached.
  • The 3,897 figure is preliminary. It comes from SBI’s first review of a larger set of about 375,000 records.
  • The main risk is convincing scam calls and messages. With a name, mobile number, date of birth, branch and loan details, a fraudster can sound very much like the bank.

If you bank with SBI: don’t share an OTP, PIN or password with anyone who calls, even if they know your details. Call back on the number on the SBI website or your card. Report suspected fraud to report.phishing@sbi.co.in or India’s cybercrime helpline, 1930.

US banks and AI agents: a new kind of account risk

The Axios report describes something different from a classic breach. Customers are giving AI assistants their banking username and password so the assistant can check balances or pay bills. The bank never approved that access, and some agents reportedly went further than asked. Morgan Stanley, JPMorgan, Bank of America and Citi are restricting or blocking such agents, and many banks are moving towards read-only access for approved tools. Morgan Stanley told Axios it had not seen “rogue AI agents accessing our platforms”, so this should not be read as confirmed theft. No losses have been disclosed (Cybersecurity News).

The US Comptroller of the Currency, Jonathan Gould, said on 22 October that banks had been preparing for this “for months” and are using their own AI to block bad actors from moving money (American Banker).

If you use an AI assistant: don’t give it your banking password. Use the bank’s own app, or an approved read-only connection if your bank offers one. Remove any AI tool that already has your login, and change the password.

What PwC’s survey says about how ready companies are

These incidents fit a pattern that PwC measured just before this week. Its 2027 Global Digital Trust Insights survey, published on 1 October 2026 with responses from 3,934 business and technology leaders in 71 countries, found:

  • About half of security leaders said attacks on AI systems are the threat they are least prepared for, ahead of cloud threats, third-party breaches and ransomware. (Reported as 50% by CDO Magazine and 52% by Infosecurity Magazine.)
  • 84% of security and finance leaders expect cyber budgets to rise, and 58% put AI among their top cyber spending priorities.
  • Only about half have fully put in place basic data controls such as data classification (49%) and data loss prevention (48%).
  • Only 22% would let AI agents take defensive actions fully on their own.

In plain terms: companies know AI is the weak spot, and most are spending more, but the basics of knowing where data sits and who controls AI tools are still unfinished. This week’s LiteLLM, Railway, OpenCode and bank-agent stories are all versions of that gap. Source: PwC 2027 Global Digital Trust Insights.

What every business should do now

Here is a priority list, roughly in the order we would do it.

Today

  • Patch PHP everywhere. Websites, online shops, booking systems, staging sites and internal tools. Confirm with your developer or host.
  • Check for LiteLLM 1.107.0. If it ran anywhere, rebuild and change all secrets as described above.
  • Change keys you were told to change. If Railway, OpenCode or any supplier asked you to rotate keys, do it now, not at the next maintenance window.
  • Set spending alerts on your cloud and AI provider accounts, so stolen keys show up as an alert rather than a surprise bill.
  • Warn customers and staff about scam calls. After the SBI and Capcom leaks, expect callers who know personal details. Remind people that real banks never ask for OTPs or passwords.

This week

  • Make a simple list of what runs your business online: websites, hosting, AI tools, payment and email providers, and who manages each one. You can’t patch what you don’t know you have.
  • Turn on two-factor login for code hosting, cloud and admin accounts, and remove access for people who no longer need it.
  • Don’t keep AI gateways and admin panels open to the whole internet. Put them behind a login, VPN or allow list.
  • Check what your AI tools log. If prompts and responses are stored, assume secrets can end up there. Limit who can read the logs and how long they are kept.
  • Lock software versions. Ask developers to install exact, known-good versions rather than “latest”, and to wait a short time before adopting brand-new releases.

If you think you were hit

  • Preserve evidence before you wipe anything. Take copies of logs and, where possible, a snapshot of the affected server. You may need them for insurers, customers or regulators.
  • Change secrets from a clean device, not from the machine you suspect.
  • Check whether personal data was involved. If it was, you may have legal duties to report the incident. For example, the EU and UK GDPR generally require notifying the regulator within 72 hours of becoming aware of a reportable personal data breach, and India’s CERT-In directions require certain incidents to be reported within six hours. Rules depend on your country and sector, so get legal advice early.
  • Tell your insurer if you have cyber cover. Many policies have notice requirements.

What it means for your business

Small businesses and online shops

PHP2Shell is the one to act on. If your shop runs on WooCommerce, Magento or another PHP platform, your exposure depends entirely on whether your host has updated PHP. Managed hosts usually patch quickly. Self-managed servers and forgotten old sites are where the risk sits. Retail and ecommerce sites also handle customer logins and payment flows, so a compromised server can lead to stolen customer data or tampered checkout pages.

Teams building with AI

The LiteLLM, Railway and OpenCode incidents share a theme: attackers are going after the keys that unlock AI services, because those keys can be resold or used to run expensive workloads. Treat AI provider keys like bank cards. Give each project its own key with a spending limit, keep them out of code and chat logs, and know how to cancel them quickly.

Banks, fintechs and finance teams

This week showed banks being hit from three directions at once: a web platform flaw (PHP2Shell) that forced some to switch off services, leaked customer data (SBI) that fuels targeted fraud, and AI agents logging in with customers’ own passwords. Finance teams should confirm PHP patching across every customer-facing portal, prepare scripts for call-centre staff about impersonation scams, and decide a clear policy on AI agents: block screen-scraping logins and offer a safe, read-only route instead.

Larger companies and regulated industries

The hard part is not the patch but the inventory. PHP is often hidden inside other products, and AI gateways are often installed by individual teams without central oversight. Ask your suppliers directly whether their products contain PHP or LiteLLM, and when they patched. For regulated sectors such as finance, healthcare and public services, keep a record of these decisions; it will matter if a regulator or auditor asks later.

The bigger picture: AI is speeding up both sides

Two trends stand out this week.

The gap between a fix and an attack is shrinking. PHP’s flaws had existed for more than a decade. AI-assisted research by Wiz, OpenAI and Calif turned them into working attacks, and once details leaked, exploit code spread within hours. Amazon’s security team says AI makes it cheaper to turn a patch into an attack, so more attackers can act within hours of a disclosure (AWS). “We’ll patch next month” is no longer a safe plan for internet-facing systems.

The software supply chain now includes AI. LiteLLM did everything many experts recommend after its March incident, including a private release repository, signed images and approval steps. Attackers still got through by stealing the logins of people allowed to approve releases. The lesson for businesses: a trusted name on a download is not a guarantee. Fix versions, watch for unusual behaviour, and make sure one stolen login can’t unlock everything.

Frequently asked questions

What is PHP2Shell in simple terms?

It is the nickname for two critical flaws in PHP, the language that powers many websites. They could let an attacker take over a web server without a password. PHP released fixes on 21 October 2026.

Is my WordPress site affected by PHP2Shell?

WordPress itself is not the problem; the PHP version underneath it is. If your host runs a PHP version older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or an unpatched vendor build), your site is exposed. Ask your host to confirm they have updated.

Does updating my WordPress plugins fix it?

No. Plugins and themes run on top of PHP. Only updating PHP itself fixes PHP2Shell. Keep your plugins updated anyway, for other reasons.

Was my website hacked if it ran an old PHP version this week?

Not necessarily. Being on a vulnerable version means you were exposed, not that you were breached. Ask your developer or host to check server logs and look for unexpected activity since 17 October.

What is LiteLLM, and should I be worried?

LiteLLM is a tool developers use to connect apps to many AI models. You should only be concerned if your team or a supplier installed version 1.107.0 or used its “latest” Docker images on 21 October. If so, treat that system’s passwords and keys as stolen.

Was my SBI account hacked?

SBI has not said any accounts were taken over. It confirmed that personal details for 3,897 customers appeared in data on the dark web. Account numbers, passwords, OTPs and card details are not among the data types it listed. The real risk is scam calls that use your details to sound genuine, so never share an OTP or PIN.

Is it safe to let an AI assistant use my bank account?

Not by giving it your password. US banks are blocking AI agents that log in with customers’ credentials, and most bank terms forbid sharing your login. Use your bank’s own app or an approved read-only connection.

I have a CAPCOM ID. What should I do?

Change your CAPCOM ID password, and change it anywhere else you used the same one. Watch for emails pretending to be Capcom, since email addresses were exposed. Capcom says card details were not leaked.

Do I need to do anything about the eMudhra certificates?

If you only use a web browser, no. Chrome, Firefox, Safari and Edge already block them. IT teams running older devices, custom software or Linux systems should make sure their certificate lists are up to date.

Who should I contact if I think my business was affected?

Start with your IT provider or developer and, if you have one, your cyber insurer. For personal data, check your legal reporting duties. In India, incidents can be reported to CERT-In; in the US, to CISA.

Key takeaways

  • Patch PHP now on every website and system you run. It is the most widespread risk this week.
  • Check for LiteLLM 1.107.0. If it ran, rebuild and change every reachable secret.
  • Rotate keys whenever a supplier tells you to, and set spending alerts on cloud and AI accounts.
  • Don’t share bank logins with AI tools, and warn customers about scam calls after the SBI and Capcom leaks.
  • Know what you run. A simple list of websites, tools and suppliers is the best defence against the next surprise.

Attacks are moving faster, but the basics still work: know what you run, keep it updated, protect the keys, and have a plan before you need one.

If you’d like a second pair of eyes on your website, cloud setup or AI tools, you can see what we do or get in touch.

This article reflects information published up to 22 October 2026. Several investigations, including LiteLLM’s and Railway’s, are ongoing, and details may change. It is general information, not legal advice.