This Week in Cybersecurity: PHP2Shell, a Poisoned LiteLLM Release, and a China-Linked BeyondTrust Zero-Day

Explore this content with AI:

ChatGPT | Perplexity | Claude | Google AI Mode

PHP2Shell: two critical PHP flaws leaked early, and exploitation attempts began before patches shipped

PHP released emergency fixes on October 21 for two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2 by PHP, after technical details leaked a day ahead of a planned October 22 disclosure. The Hacker News reports that Wiz Research, Calif, and OpenAI's Codex Security team reported the bugs, and that the fixes landed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, with source backports for 7.4, 8.0, and 8.1, which no longer receive project updates. Sansec describes both as use-after-free bugs in the PHP engine that need no login, affect default configurations, and trace back to PHP 5.4. The bugs were found with AI help: CyberScoop reports that Calif discovered the flaw using an OpenAI model, while Wiz found and reported it independently.

Attackers didn't wait for the patch, or even for the disclosure. The Hacker News reports that Amazon Threat Intelligence's MadPot honeypot logged a single exploit attempt on October 17, four days earlier and while the flaws were still under embargo, and it's unclear how the actor learned of them. Sansec says Cloudflare saw early attack traffic at 07:43 UTC on October 21, hours before the 14:00 UTC release, and The Hacker News reports that watchTowr saw active exploitation attempts against both flaws at 14:19 UTC, and watchTowr now says exploitation has been observed in the wild as of October 21. CyberScoop says researchers saw mostly reconnaissance and that CISA had not observed exploitation as of publication; the flaws aren't in CISA's KEV catalog, and no source has confirmed that a specific server was compromised; researchers estimate more than 1.3 million internet-exposed hosts could be vulnerable. Australian government websites, including cyber.gov.au, were taken offline as a precaution, and officials haven't claimed any breach or data access.

Why it matters: PHP sits underneath WordPress, Magento, Drupal, and countless custom applications, and the flaw triggers before application code runs, so web application defenses can't be your only plan. Upgrade to a fixed release now, and check hosting providers and container images, because PHP 8.1 and older need the source backport. Stopgaps such as blocking multipart/form-data requests reduce exposure but break file uploads and aren't a full fix, and unverified exploit code circulating online may carry malware, so don't test it on a machine you care about.

Read more at ABC News

A poisoned LiteLLM release on PyPI and Docker Hub tried to steal cloud and AI credentials

On October 21, LiteLLM 1.107.0, a widely used library for routing requests across AI model providers, was published to PyPI at about 11:39 UTC with credential-stealing code in all seven of its platform wheels. According to StepSecurity's timeline, an infected Docker image followed at 11:48, the compromise was reported on GitHub at 12:06, and PyPI removed the release by 13:23 UTC; the Docker images were gone by 14:32 UTC. Chainguard says its scanner flagged the release 16 minutes after the first wheel appeared.

The git tag was clean; the malicious code existed only in the built packages. StepSecurity found the release workflow ran from a lookalike repository named Berri-AI/litellm, with a hyphen, and one of the added files, cook.pth, runs every time Python starts, so the stealer executed without anyone importing LiteLLM. It collected browser passwords, SSH and cloud keys, CI credentials, AI coding tool configurations, and the provider keys stored by a LiteLLM proxy, and it installed a loader that checked a GitHub dead drop every hour for code to run (the dead drop was empty at release). The Hacker News reports that LiteLLM now suspects the attacker took developers' GitHub CLI tokens from its own AI gateway logs, where a coding tool can embed a user's token in a logged response, and that it's still unclear how the attacker reached the exposed deployment. No threat actor has been named; Chainguard and Socket say there's no evidence linking the attack to TeamPCP, the group behind LiteLLM's March compromise, even though the technique is similar.

Why it matters: if anyone on your team installed 1.107.0, or pulled the latest Docker tag on October 21, treat that host as fully compromised; pin version 1.106.2 (or the image by digest) and rotate every credential it could reach, including the provider keys in a LiteLLM proxy database. Search network logs for requests to litellm.dev, and note that a request to a /codepy path means attacker code ran. More broadly, a clean git tag proves nothing about what reached a registry; pin by digest, hold brand-new versions briefly before they reach developer laptops and build systems, and check that provenance names the repository you expect.

Read more at StepSecurity

China-linked Armory Castle exploited a BeyondTrust Remote Support zero-day for seven weeks before disclosure

BeyondTrust disclosed CVE-2026-102764 (CVSS 9.3) on October 15, an authentication bypass in Remote Support that lets an unauthenticated attacker perform file operations on an appliance. SecurityWeek reports that the flaw affects all versions through 26.2.3, that exploitation began August 29 against two appliances (one BeyondTrust-hosted and one self-hosted), and that BeyondTrust shipped a patch on October 8, with SaaS customers updated by October 9. Rapid7 says CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog on October 16, with a federal deadline of October 19.

Mandiant and Google Threat Intelligence Group attribute the activity to Armory Castle, a suspected China-nexus espionage group formerly tracked as UNC5221 (CrowdStrike calls it Warp Panda). BleepingComputer reports that the attackers gained root access, deployed the Sawfly web shell and the Bareclaw tunneler, wiped logs, and moved laterally using compromised Administrator credentials. Mandiant notes the group has previously exploited zero-days in Citrix NetScaler and Ivanti Connect Secure, and that it has widened exploitation after public disclosure, so similar attempts against this flaw are possible. The Shadowserver Foundation tracks more than 1,400 BeyondTrust remote support instances exposed to the internet.

Why it matters: remote support and privileged access appliances hold the keys to everything they connect, so a compromise here is a skeleton key. Patch self-hosted Remote Support now, along with Privileged Remote Access, which shares the affected code, and forward appliance logs to a SIEM in near real time, because this actor deletes local logs. Rotate any credentials the appliance stored, image it before rebuilding, and treat any internet-reachable vulnerable appliance from the exploitation window as potentially compromised until it's reviewed.

Read more at Rapid7

Eight eMudhra certificate authority keys were so weak that anyone could recover them, and browsers moved to block them

Chrome and Firefox blocked eight eMudhra intermediate certificate authority (CA) certificates on October 17, after a researcher reported that their private keys were generated with insufficient randomness. Mozilla's Dennis Jackson said, as SecurityWeek reports, that the keys are "effectively all-zeroes apart from the last byte" and can be recovered almost instantly, and The Hacker News reports that security researcher Scott Helme recovered all eight from the public certificates in under a second. Anyone holding one of those keys could forge a certificate that clients trusting the CA would accept for any website. eMudhra says a script error in a key ceremony created a second, weaker set of keys that was used by mistake, that only one of the eight intermediates was deployed in production, and that none issued certificates to end users.

Apple blocked the certificates on October 19, Microsoft on October 20, and Go shipped a fix the same day (CVE-2026-111943). Google says Chrome will remove the emSign ECC Root CA - G3 root, expected to reach users on October 27. Google found no fraudulent certificates in Certificate Transparency logs before the block, but not every client enforces Certificate Transparency, and software that doesn't check revocation may keep trusting these chains until it's updated. India's CERT-In said on October 21 that public disclosures don't establish confirmed malicious use, and eMudhra's root-cause investigation is still open.

Why it matters: certificate trust is a quiet dependency, and a failure here can break services as well as weaken them. Update operating systems, language runtimes, containers, and CA bundles as vendors ship fixes (several were still pending when reporting published), and look for tools with their own trust stores or no revocation checks. If any of your sites chain to emSign ECC Root CA - G3, get a certificate from a different hierarchy before October 27, or they may stop loading for Chrome users.

Read more at the Google Security Blog

A compromised login at a testing vendor exposed records on millions of California students

California officials say an unauthorized party used a compromised login credential to copy student files from Educational Testing Service (ETS), the contractor that administers the state's CAASPP and ELPAC exams, between May 22 and September 18. The Record reports that ETS discovered the breach on September 25 and that the California Department of Education began notifying families on October 16, with notices continuing through November. The stolen data includes names, dates of birth, addresses, schools, districts, student ID numbers, demographic details, and disability and testing-accommodation information. Officials say the thieves didn't take Social Security numbers, driver's license and passport numbers, or financial information.

The state hasn't published an exact count. It says the data covers children enrolled in California public schools over the last three years, plus students who left the state's schools since 2006 without a confirmed transfer, and EdSource, relaying Politico, puts the total at about 7 million. ETS disabled the compromised account, took the file transfer site offline, and says no other customers were affected. No group has claimed responsibility, officials have found no evidence the data has been published, and former students are being offered 24 months of identity protection.

Why it matters: this started with one credential at a vendor and went undetected for more than four months. Ask every vendor that holds sensitive data about your people whether its accounts require multifactor authentication, how its file-transfer systems are monitored for bulk copying, and how long it keeps old records (this breach reached back to 2006). Families and staff should expect convincing phishing that references the incident.

Read more at Education Week

Final thoughts

This week's stories share a single weakness: reliance on foundations nobody checks. A web runtime that powers much of the internet, a package registry, a remote support appliance, a certificate authority, and a state testing contractor each looked like background infrastructure until it failed, and in every case attackers or researchers found the gap before defenders had a patch or a notice in hand.

If there's one action item, it’s to map your own foundations: know which runtimes, registries, remote-access tools, certificate chains, and vendors your systems depend on; how quickly you can patch or replace each one; and where a single stolen credential could open the door. Pin and slow-roll new package versions, ship appliance logs off the device, and keep a current list of the vendors that hold your data.

Check back next Thursday for the next edition of This Week in Cybersecurity.