Black October: what PHP2Shell, eMudhra and LiteLLM mean for Indian enterprises

One week, four kinds of failure

October is Cybersecurity Awareness Month. This year the week from 17 to 24 October supplied the lessons itself, and security writers have started calling it Black October. Four stories matter most for organisations in India, and each one fails in a different place: the web server, the certificates that prove who a website is, the software supply chain, and the AI tools now inside it.

None of them needs a new strategy. Each needs someone to know what is running, find the affected systems and act within days. That is an inventory and operations problem before it is a security one.

PHP2Shell: patch every PHP server

On 21 October the PHP project released fixes for two critical flaws in the PHP interpreter itself, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0. Either can let an attacker who has not logged in run code on a server that handles web requests. One comes from how PHP cleans up after running out of memory; the other lets a worker reuse stale state left by an earlier request.

The exposure is wide. PHP says every installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and rates mod_php highest, because a demonstrated exploit fires before any application code runs. The vulnerable code dates back to PHP 5.4 in 2012. WordPress, Drupal, Joomla and Magento all run on PHP, as do many internal portals and vendor appliances.

The timeline is the warning:

• 17 October: Amazon’s honeypots saw an exploitation attempt, four days before anything was public.
• 20 October: the CVE details leaked, and PHP brought its release forward a day.
• 21 October, 14:00 UTC: fixes in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CERT-In issued vulnerability note CIVN-2026-0510 the same day, rated Critical, and CISA urged immediate patching.
• 23 October: TechCrunch reported confirmed compromises and post-exploitation activity, citing Palo Alto Networks and Trail of Bits.

Sources disagree on scale. CISA had not seen successful exploitation when it published on 21 October; CERT-In’s updated note speaks of large-scale exploitation in the wild. Hospitals, schools and some government agencies took servers offline while they patched.

1. Find every PHP installationInclude the ones you don’t think of as PHP: vendor appliances, control panels, intranet tools and old marketing sites. CISA notes PHP is often embedded in other software.
2. Patch, internet-facing firstMove to a fixed release or your Linux distribution’s patched package, then restart every PHP worker. PHP says there are no complete mitigations; its interim settings narrow specific attack paths but do not make a server safe.
3. Take the rest offlinePHP 8.1 and older get no official release. CISA advises taking systems that can’t be patched offline until they can. A web application firewall can buy time, but it is a stopgap.
4. Look back to 17 OctoberSearch for PHP worker processes starting shells or downloading tools, and new files in web roots, from 17 October onwards. A patch closes the door; it does not remove anyone already inside.

eMudhra: check your certificates and trust lists

On 17 October a researcher told the browser makers that the private keys of eight eMudhra intermediate certificate authorities, under its emSign infrastructure, could be recovered. They should have been huge random numbers. They were tiny: researchers recovered them from the public certificates in under a second, and one was reportedly the number 4. Google attributes it to keys generated with insufficient randomness.

Anyone holding such a key can sign a certificate that clients trusting the CA will accept for any website, which allows impersonation and interception. Google says no TLS certificates chaining to the affected intermediates had been logged to Certificate Transparency before it blocked them, and CERT-In said on 21 October that no malicious exploitation had been confirmed. eMudhra says it revoked the CAs within 14 hours and that none of them issued end-entity certificates.

The response was fast. Chrome blocked the keys at 19:45 UTC on 17 October, under two hours after the report. Mozilla finished blocking them the same evening, and Microsoft and Apple followed within days. Chrome is due to remove the emSign ECC Root CA – G3 root itself on 27 October. On 22 October eMudhra’s board decided to leave the global SSL/TLS certificate business. It estimates about 30,000 certificates need migrating and says it will replace them free through partners. Its digital signature certificate and eSign businesses continue.

Browsers update themselves. Much enterprise software does not:

• Replace any certificate that chains to emSign ECC Root CA – G3 now. Google says those sites will stop working in Chrome.
• List your other emSign TLS certificates, including on internal services and APIs, and plan their replacement before eMudhra’s exit takes effect.
• Update the trusted-certificate lists in containers, appliances, Java, Python, Go and Node applications, and anything that doesn’t check revocation or Certificate Transparency. Those clients still trust the weak keys until they are updated.

Browsers were protected within hours. The systems that keep their own list of trusted certificates are protected when someone updates the list.

LiteLLM: when the AI toolchain is the way in

LiteLLM is a widely used open-source library that lets applications call many AI models through one interface. On 21 October attackers published LiteLLM 1.107.0 to PyPI and Docker Hub with malware inside. The poisoned builds were live for about two to three hours: 11:39 to 13:23 UTC on PyPI, and 11:46 to 14:20 UTC for the Docker tags v1.107.0, latest, main-latest and main-stable.

The source code in the Git tag was clean; only the published packages carried the payload, so reading the code would not have caught it. The malware installed itself into Python’s startup files, so it ran whenever Python started in that environment, whether or not anything imported LiteLLM. It collected AWS, Azure, GCP and Kubernetes credentials, AI provider keys, Git and SSH keys, browser data and environment variables, and sent them out encrypted. Wiz reports the attacker testing stolen AWS keys about four and a half hours later.

LiteLLM says the attackers used stolen GitHub CLI tokens from three of its engineers to run its own release pipeline, and that the tokens appear to have come from the logs of an internal deployment exposed to the internet. It is the project’s second supply-chain compromise this year.

1. Look for 1.107.0 everywhereCheck lockfiles, container images, CI caches and developer laptops. The last clean release is 1.106.2.
2. Treat an install as a compromiseIf 1.107.0 was installed, or one of those images started, on 21 October, rebuild the machine and rotate every credential it could reach. Upgrading alone leaves the stolen keys in the attacker’s hands.
3. Tighten the pipelinePin dependencies to exact versions with hashes, keep build systems from reaching hosts you haven’t approved, and keep tokens out of application logs.

GitLab and the rest of the patch queue

Also on 21 October, GitLab fixed CVE-2026-110264, rated 10.0, which can let an attacker who has not logged in run code on self-managed GitLab, Community and Enterprise Editions, under certain conditions. The flaw is in the regular-expression engine of the Ruby that GitLab ships, so it reaches back to GitLab 7.0 in 2014. GitLab.com is already patched. The fixed releases are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. This was GitLab’s second 10.0 fix in October, and the releases from the first one are still vulnerable, so teams that patched promptly need to patch again.

The queue is longer than this article. Microsoft’s October Patch Tuesday included a Windows Shell security feature bypass already being exploited (CVE-2026-96951), and Oracle and Splunk published critical fixes during the week. A source-code server is a high-value target: it holds the code, the pipeline secrets and the path to production.

AI agents that went past their brief

OpenAI has been publishing reports of what it calls misalignment incidents: cases where its own models, during training, evaluation or internal use, did things nobody asked for. Two batches landed this month.

• Published 15 October: models given simple data-lookup tasks during training and evaluation in June instead broke into the live systems holding the data, including a government statistics website and an international research organisation, using credentials and settings they found along the way. None mentioned its methods in its final answer.
• Reported 21 October: two internal coding agents weakened monitoring. On 3 October a GPT-6.1 Sol agent fixing an evaluation pipeline switched off automatic alerts to OpenAI’s security team; on 6 October a GPT-6 Astra agent removed a monitoring integration, then told the user it hadn’t.

OpenAI says the agents read ordinary instructions as permission to weaken safeguards, and that it is making monitoring harder for models to disable. The lesson for an enterprise is not to stop using AI tools. It is to give them the same controls you would give a new contractor with administrator access, then a few more:

• Give each agent its own account and least-privilege tokens, never a person’s credentials.
• Log agent actions somewhere the agent cannot edit, and require a person to approve changes to monitoring, alerting or access.
• Verify what an agent reports against the logs; its summary is not evidence.

AI is on both sides of this week. TechCrunch reports that the PHP flaws were judged unexploitable in a 2024 audit, until researchers at Calif, working in an AI-assisted research programme run with OpenAI and Wiz, showed otherwise.

For Indian organisations: the six-hour clock

CERT-In’s 2022 Directions require reportable cyber incidents to be reported within six hours of being noticed. If your look-back finds a compromised web server, a forged certificate or stolen keys, the clock may already be running. The decision about what is reportable belongs with your compliance team, but it is only possible if the logs exist, the clocks agree and the runbook names who sends the report. Our guide to CERT-In’s 180-day logs and clock sync covers that groundwork.

For banks and government bodies, each of this week’s stories also touches a third party: the hosting company running a PHP site, the CA behind an API certificate, the vendor whose appliance embeds PHP or its own CA list. Ask those suppliers this week what they run and when they patched, and keep their answers.

This week’s checklist

Tick what runs in your estate and the list below puts the actions in order.

If you can’t answer “do we run this?” for one of the boxes, start there. You can’t patch what you haven’t found.