All Articles

TL;DR for CISOs: Two critical PHP flaws, tracked as PHP2Shell, allow unauthenticated code execution on web servers, and attack attempts appeared before and around the October 21 patch release. Patch to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or apply your vendor's backport, because the interim settings reduce exposure but do not make a server safe.

Today's slate at a glance

Lead story: PHP2Shell, two critical PHP flaws allow unauthenticated code execution

Key facts

What happened

Wiz, OpenAI and Calif found the flaws in August 2026 and worked with the PHP security team on fixes. According to SecurityWeek, details leaked on October 20, ahead of a coordinated disclosure planned for October 22, so PHP released patches a day early.

Both flaws come from PHP leaving memory in a corrupted state when a request ends abnormally. BleepingComputer reports a demonstrated exploit in which an unauthenticated request triggers the attack before application code runs. The UK National Cyber Security Centre told organizations to update immediately or take affected systems offline.

PHP core developer Gina Peter Banyard said no mitigation fully blocks attacks and that official patches are the only permanent defense. Wiz says the two CVEs group four memory-safety issues and that other variants may exist.

Evidence

• BleepingComputer, PHP ships emergency patches for critical PHP2Shell flaws
• SecurityWeek, PHP2Shell patches land as first exploitation attempts hit sensors

What this means for your team

The hard part of this incident is finding PHP, not patching it. PHP runs inside CMS platforms, vendor-managed portals, admin tools and container images that rarely appear in a software inventory under that name. Start from internet-facing hosts and work inward.

Cloudflare described its web application firewall rules as temporary, and the vendor guidance says interim settings reduce exposure without making a host safe. A WAF in front of a vulnerable runtime buys hours, not a fix. Your decision for any system that cannot be patched today is whether to take it offline.

The patch window is also a forensics window. Attempts began before the fixes were public, so servers that were reachable on October 20 and 21 deserve a look at web logs and for unexpected processes spawned by the web worker account.

Action checklist

1. Build a list of every internet-facing host and container image running PHP, record the version and SAPI (mod_php carries the highest risk per the PHP security team), and rank by exposure.
2. Apply 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the vendor or distribution backport. For PHP 7 and older, plan migration and confirm in writing what your hosting vendor has backported.
3. Where patching cannot happen today, apply the published interim settings, keep WAF rules on, restrict the host to required traffic, and set a dated plan to take it offline if it stays unpatched.
4. Review web server and PHP error logs from October 20 onward for crashes, out-of-memory events, session upload-progress requests and new child processes, and rotate secrets that were readable by the PHP worker if you find signs of access.

Supporting story: CISA and partners say SafePay ransomware has hit more than 600 organizations

Key facts

What happened

According to BleepingComputer, SafePay appeared in August 2024 as a private group that does not use affiliates, and since early 2025 it has filled the space left by BlackCat and LockBit. It steals data before encryption and threatens to publish it.

Infosecurity Magazine reports that after gaining access the operators take over or create accounts, move with built-in administration tools and remote access software, disable security software and use tools such as RClone and FileZilla to move data out. Encryption combines ChaCha20 with RSA.

The advisory recommends prioritizing known exploited vulnerabilities, enforcing multifactor authentication on all accounts, limiting administrative tools and privileges, keeping offline, immutable backups that are tested, and segmenting networks.

Evidence

• BleepingComputer, SafePay ransomware hit over 600 critical infrastructure organizations
• Infosecurity Magazine, SafePay has compromised 600 critical infrastructure victims
• HIPAA Journal, Feds issue advisory about SafePay ransomware group

What this means for your team

This advisory is a checklist you can score yourself against today. Every named entry point is a control most security teams already own: patching edge devices, MFA on VPN, credential hygiene and backup isolation. Where one of them is weak, the advisory gives you outside evidence for the funding conversation.

Backup targeting changes the recovery question. If a NAS that holds backups can be reset by an account that also administers production, the backup exists on paper only. Ask your infrastructure owner who holds credentials to the backup platform and whether those credentials are separate.

The Veeam, Cisco and SonicWall entries are older flaws. Attackers keep using them because some devices were never patched, which makes asset inventory a ransomware control.

Action checklist

1. Compare your edge device and backup software versions against the CVEs named in the advisory and the CISA Known Exploited Vulnerabilities catalog, and patch or retire anything still exposed.
2. Confirm MFA on VPN, remote access, email and administrator accounts, and review VPN logs for sign-ins from unusual hosting or commercial VPN address ranges.
3. Test a restore from an offline or immutable copy this quarter, and verify that production administrator accounts cannot change or delete backup jobs, snapshots or NAS settings.
4. Alert on mass shadow copy deletion, new remote access tools on servers and large outbound transfers to cloud storage from systems that do not normally send data.

Supporting story: LiteLLM 1.107.0 was poisoned on PyPI and Docker with a credential stealer

Key facts

What happened

The Hacker News reports that attackers used three engineers' GitHub accounts, one to trigger the release workflow and a second to approve it. StepSecurity says the release was built from a lookalike repository rather than the official BerriAI repository, and that BerriAI is still investigating how it was published.

The package was quarantined on PyPI and the malicious images were removed. LiteLLM also removed trusted publisher links to its GitHub organization on public registries and cut access to its GitHub organization to one unaffected user while the investigation continues.

The Hacker News notes the same startup-execution behavior appeared in a March 2026 LiteLLM compromise linked to the TeamPCP campaign. It describes this as a similarity and not an attribution for this incident.

Evidence

• The Hacker News, LiteLLM compromised in supply chain attack delivering credential stealer and backdoor
• StepSecurity, litellm 1.107.0 compromised on PyPI

What this means for your team

A model gateway sits next to your most valuable keys. It holds provider API keys, cloud roles and the master key that issues access to every internal AI application, so one poisoned release can turn into a spend, data and access problem at once.

The two safeguards that failed were not exotic: a release approved through accounts whose tokens were stolen, and consumers who pull the newest version automatically. Pinning by digest and delaying new releases by a day or two would have kept most teams out of this window.

Because the stealer ran at interpreter startup, removing the package is not enough. Hosts that ran Python after install need review for the leftover files and background process.

Action checklist

1. Search build logs, lockfiles, notebooks and container registries for litellm 1.107.0 and for image pulls on October 21 between roughly 11:48 and 14:32 UTC, and purge cached copies from internal mirrors.
2. On any host that ran it, check site-packages for cook.pth, cook.py and an unexpected sitecustomize.py, stop the background process, and replace the machine or container instead of cleaning it in place.
3. Rotate every credential reachable from those hosts, including cloud keys, SSH and GPG keys, registry and CI tokens, and on proxy hosts the provider API keys, master key and salt key stored in the database.
4. Pin LiteLLM to 1.106.2 by digest, block litellm.dev at DNS or egress, and search network logs for requests to it. Add a cooling-off period for new package versions in your build system.

Supporting story: GitLab patches a CVSS 10.0 regex flaw affecting self-managed releases back to 7.0

Key facts

What happened

GitLab published the release on October 21, backporting the fix to four branches outside its normal release cycle, which it does for severe issues. According to The Hacker News, a researcher using the handle joaxcar reported it, and it is the fourth code-execution flaw in GitLab's regex handling that the researcher has reported within a month.

The Hacker News also reports that an October 12 fix for CVE-2026-97229, an earlier unauthenticated regex overflow rated 10.0, means instances patched then fall back into the affected range under this release. Check your version against the October 21 list, not the earlier one.

Upgrades to 19.4.3 and 19.3.6 include database migrations, so single-node installations should plan for downtime. GitLab published two detection rules for application logs in Sigma format.

Evidence

• GitLab, Critical Patch Release 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13
• The Hacker News, critical GitLab flaw (CVSS 10.0) could allow unauthenticated RCE across 12 years of releases

What this means for your team

Source control holds your code, pipeline secrets and deploy credentials, so a server-side code execution flaw there is an access path into production. Absence of known exploitation is a lead time, not a clearance, given how quickly fixed flaws get reverse engineered.

The version table is the useful detail for planning. Four of the seven fixed branches fall outside GitLab's standard support window, which means a lagging instance may need a multi-step upgrade and a maintenance window, not a quick patch.

If the instance is reachable from the internet, ask whether it needs to be. Moving it behind VPN or an identity-aware proxy shrinks the unauthenticated attack surface for the next flaw too.

Action checklist

1. List every self-managed GitLab instance, including team-run and test servers, with its version and whether it is reachable from the internet.
2. Upgrade to the fixed release for your branch, scheduling downtime for single-node installs that run migrations, and verify the running version after the change.
3. Deploy GitLab's published Sigma detections to application logs, and review logs for Onigmo worker crashes and unusual rendering errors since October 12.
4. Rotate CI/CD variables, runner tokens and deploy keys on any instance you cannot show was unreachable, and restrict inbound access to the instance to the networks that need it.

Also notable

• Onamae.com Desktop Cloud (Japan): GMO Internet's VPS service confirmed on October 20 that a third party installed unauthorized programs on some customer servers, then began shutting servers down on October 21. Up to 26,739 servers are affected, the service is suspended with no restart date, and customers should rotate any secrets stored on their servers. Payment card data is reported to sit on separate infrastructure. Source: BleepingComputer (single source reviewed).
• State Bank of India: SBI told stock exchanges on October 21 that it identified 3,897 customer records in a dark web set of about 375,000 records. The figure is preliminary, the source and authenticity are unconfirmed, and the filing lists no account numbers, passwords or card details. A threat actor claim of 375,000 rows has not been verified. Source: The Hacker News (single source reviewed).
• UpdraftPlus and UpdraftCentral: TeamUpdraft says a website breach on October 17 and 18 may have exposed customer connection keys, which attackers used to plant backdoors on connected WordPress sites over an 18-hour window per Patchstack. Update UpdraftPlus to 1.26.12 or later, remove the connection key and review administrator accounts and plugins. Source: The Hacker News (single source reviewed).

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name used for two critical PHP runtime flaws, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2. They allow unauthenticated remote code execution on web servers, and PHP released fixes on October 21, 2026.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, plus source backports for PHP 7.4, 8.0 and 8.1. PHP 8.1 and older no longer receive upstream updates, so check whether your distribution or hosting vendor has backported the fix.

Do the interim PHP settings protect my server?

No. The PHP security team and a PHP core developer say the settings reduce exposure but do not fully block attacks, and that patching is the only permanent defense.

How many organizations has SafePay ransomware breached?

CISA, as reported by BleepingComputer, says at least 600 organizations since August 2024, across North America, South America, Europe and Australia. The true number is likely higher because the group's leak site lists only victims who did not pay.

What should I check if I installed LiteLLM 1.107.0?

Look for cook.pth, cook.py or an unexpected sitecustomize.py in site-packages, stop the background process, replace the host or container, and rotate every credential it could reach. Pin LiteLLM to 1.106.2 by digest.

Is the GitLab CVE-2026-110264 flaw being exploited?

GitLab reports no evidence of exploitation, and The Hacker News says it was not in the CISA Known Exploited Vulnerabilities catalog as of October 22. There is no workaround, so upgrade self-managed instances to a fixed release.

What should a CISO do first this week?

Inventory internet-facing PHP hosts and patch them, verify MFA and edge device patching against the SafePay advisory, hunt for LiteLLM 1.107.0 in build systems, and upgrade any self-managed GitLab.

Corrections and takedown requests: CISO Platform is committed to accuracy and fairness. If any detail in this briefing is inaccurate, or if you represent an affected organization and would like a correction or removal, please contact us at pritha.aash@cisoplatform.com and we will review your request promptly.