The Biggest Cybersecurity Issues This Week (October 2026): What Developers Need to Patch

The third week of October 2026 was rough for anyone running software on the internet. In five days we got two critical PHP flaws now under active attack, a CVSS 10 GitLab bug that goes back to 2014, a hacked release of one of the most popular AI libraries, and an Indian certificate authority whose private keys were so weak that one of them was the number 4.

If you're a developer or run your own servers, at least one of these probably affects you.

The 2-minute checklist

Start here, then read the details for anything that applies to you:

• Run PHP anywhere? Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart PHP
• Use LiteLLM? Check whether version 1.107.0 was ever installed or pulled on October 21. If yes, treat that machine as compromised
• Host your own GitLab? Upgrade to 19.5.1, 19.4.3, 19.3.6, or the backport for your line (19.2.9, 19.1.9, 19.0.10, 18.11.13)
• Ship Go binaries or run non-browser software that checks TLS? Update Go to 1.27.3 or 1.26.10 and rebuild, and update your OS trust store, so the bad eMudhra certificates are rejected

1. PHP2Shell is now being exploited

What happened: On October 21, PHP shipped emergency fixes for two critical flaws in the PHP engine itself, CVE-2026–109618 and CVE-2026–109619. Both are rated 9.2 and let an attacker run code on a web server without logging in.

The disclosure was messy. Details leaked a day early, a research firm accidentally posted a video of its working exploit the night before, and a vendor published patched builds hours before the official release, which let anyone study the fix early.

Why it's urgent now: within hours of the patch, watchTowr reported active exploitation attempts against both flaws. Amazon's threat intelligence team said its honeypots saw exploit attempts going back to October 17, days before the patch existed.

What to do: update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, restart PHP-FPM, and confirm the new version is live. PHP 8.1 and older get no fix from PHP. If you can't update today, set session.upload_progress.enabled = 0 in php.ini as a stopgap.

I wrote a full step-by-step guide for this one: PHP2Shell: How to Check and Patch the Critical PHP Vulnerabilities.

2. LiteLLM's release pipeline was hacked

What happened: LiteLLM is a popular Python library that gives you one interface to many AI model providers. It gets about 23 million downloads a week. On October 21, attackers published version 1.107.0 to PyPI and to LiteLLM's official Docker images, with a credential stealer inside. It was live for about two hours before being removed.

LiteLLM says the attackers apparently used stolen GitHub CLI tokens from three engineers to point its trusted release pipeline at a lookalike repository. This is the second time this year a malicious LiteLLM release reached PyPI.

Why it's nasty: the malware hid in a .pth file, which Python runs automatically on every start. You didn't even need to import litellm. Any Python process on an infected machine ran the stealer. It grabbed cloud credentials, SSH keys, API keys and more, and on Linux and macOS it also installed a loader that pulled new code every hour.

Affected: litellm==1.107.0 on PyPI, plus the Docker tags v1.107.0, latest, main-latest and main-stable pulled during the window.

What to do:

• Search your lockfiles, CI logs, caches and running containers for 1.107.0
• Look in site-packages for litellm-1.107.0.dist-info, cook.pth, cook.py and sitecustomize.py
• If you find it, isolate the machine. Don't just run pip uninstall, since running that environment's Python can trigger the malware again
• Rebuild from a clean environment pinned to litellm==1.106.2, and pin Docker images by digest, not by latest
• Rotate everything that machine could reach: cloud keys, AI provider keys, LiteLLM master and virtual keys, SSH keys, database passwords, and publish tokens

The bigger lesson: if your Dockerfile says latest or your requirements say litellm>=1.x, you automatically pulled whatever the attacker published. Pin exact versions.

3. GitLab's CVSS 10 bug goes back to 2014

What happened: On October 21, GitLab fixed CVE-2026–110264, rated the maximum 10.0. It's an integer overflow in the regular expression engine bundled with GitLab. Under certain conditions, an attacker without an account can run code on the server just by getting it to compile a crafted regex.

The scary part: it affects every self-managed GitLab version since 7.0, released in 2014.

The trap: GitLab shipped a different CVSS 10 regex fix on October 12. If you patched then, you are not covered. Versions 19.4.2, 19.3.5 and 19.2.8 are still vulnerable to this new one. It's the fourth code-execution bug in GitLab's regex engine found by the same researcher in about a month.

Who's affected: only self-managed GitLab (Community and Enterprise editions). GitLab.com is already patched.

What to do: there's no workaround. Upgrade to the fixed version for your release line:

• 19.5: 19.5.1
• 19.4: 19.4.3
• 19.3: 19.3.6
• 19.2: 19.2.9
• 19.1: 19.1.9
• 19.0: 19.0.10
• 18.11: 18.11.13

If you're on an older line than 18.11, there's no fixed release. You need to move to a supported version. Start with any instance that's reachable from the internet.

4. eMudhra's private keys were guessable. One was the number 4

What happened: eMudhra is an Indian certificate authority, one of the companies whose certificates tell your browser a website is genuine. On October 17, a researcher reported that the private keys for eight of its intermediate certificates were so weak they could be recovered from the public certificates in under a second.

A private key like this should be a huge random number. These were tiny numbers like 4, 56 and 66. Reports say eMudhra blamed a bug in its key-setup script.

Why it matters: with those keys, anyone could have created fake HTTPS certificates for any website, like your bank, and browsers would have trusted them. No attacks using them have been reported, and Chrome found no rogue certificates in public logs.

How fast the fix came: Chrome and Firefox blocked the certificates on October 17, within hours of the report. Apple followed on October 19 and Microsoft on October 20. eMudhra revoked them on October 18. Mozilla also removed the root they chain to, and Chrome is dropping it on October 27.

What to do:

• Regular users: nothing, as long as your browser and OS are up to date
• Developers: this is where it gets tricky. Many non-browser apps never check whether a certificate was revoked. If you ship Go binaries, update to Go 1.27.3 or 1.26.10 and rebuild, since those versions reject the bad chains. Update OS trust stores on your servers and containers, and check any SDKs or devices that do their own TLS
• eMudhra customers: eMudhra estimates around 30,000 customer certificates need replacing. If your site uses an eMudhra or emSign certificate, contact them and plan the switch

Also on the radar this week

• SafePay ransomware: CISA published a #StopRansomware advisory (AA26–293A) on October 20 about the SafePay group
• PwnEscape: a critical Linux virtual machine escape, CVE-2026–99999, rated 9.3. No exploitation in the wild was confirmed as of October 21, but if you run virtualization hosts, watch for your vendor's patch
• INTERPOL crackdown: on October 22, INTERPOL announced a global operation that arrested 1,462 suspects, disrupted 10,909 malicious networks and recovered more than $105 million

The pattern this week

Look at these four together and the same lessons keep showing up.

The window between disclosure and attack is gone. PHP2Shell exploit attempts started before the patch even shipped. You can't wait for a quiet weekend to update anymore. Turn on automatic security updates where you can.

Your supply chain is your attack surface. LiteLLM's own code was fine. The attackers went after the release pipeline. Anyone who pulled latest got the malware automatically. Pin exact versions and image digests, and treat developer tokens like passwords.

"Patched" isn't a one-time state. GitLab users who updated on October 12 were exposed again nine days later. Subscribe to security notices for every piece of infrastructure you run yourself.

Basic mistakes still break big systems. A certificate authority trusted by every major browser used private keys a child could guess. The fix came fast because browsers can push blocks within hours. Most of your other software can't.

FAQ

What are the biggest cybersecurity issues right now? This week: PHP2Shell (two critical PHP flaws now under attack), the LiteLLM 1.107.0 supply chain compromise, GitLab's CVSS 10 flaw CVE-2026–110264, and the eMudhra certificate key compromise.

Is PHP2Shell being exploited? Yes. Researchers reported active exploitation attempts against both CVEs within hours of the October 21 patch, and Amazon saw attempts going back to October 17.

Which LiteLLM version is safe? LiteLLM recommends pinning to 1.106.2 or another explicit earlier version. Only 1.107.0 and the Docker tags pulled during the October 21 window were malicious.

Is GitLab.com affected by CVE-2026–110264? No. GitLab.com is already patched. Only self-managed GitLab installations need to upgrade.

Do I need to do anything about eMudhra? If your browser and OS are updated, no. Developers should update Go, OS trust stores and any software that does its own TLS checks. Sites using eMudhra certificates should plan to replace them.

Patch PHP, check for LiteLLM 1.107.0, upgrade self-hosted GitLab, and update your trust stores. That's this week's whole to-do list.

I build products in public and write about the tools developers actually use. Follow me here, or on X at @soham_nayak04.