PHP2Shell vs LiteLLM: when to update dependencies

On October 21, PHP released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS v4.0 9.2 and can allow unauthenticated remote code execution.

CVE-2026-109618 involves out-of-memory handling interrupting PHP while internal request data is only partially initialized. CVE-2026-109619 can leave request-owned state accessible after its backing memory has been freed, allowing a later request handled by the same worker to use stale state.

PHP's advice was unusually direct: there are no complete mitigations. Update.

The fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP also published minimal source backports for 7.4, 8.0 and 8.1 for users building from source or without an LTS vendor.

Debian accepted php8.2 8.2.35-1~deb12u1 into bookworm-security at 14:00:20 UTC the same day. Its changelog lists fixes for both CVEs.
‍

Updating a pinned build

StableBuild keeps daily snapshots of Debian, Ubuntu and Alpine package repositories.

A snapshot from before the fixed Debian package became available contains the older repository state.

Once a snapshot containing 8.2.35-1~deb12u1 is available, you can move the pin forward, rebuild and test. That snapshot can then become the new reproducible baseline.

For PHP2Shell, you want the dependency set to move.

‍

LiteLLM 1.107.0 lasted 103 minutes

Earlier on October 21, LiteLLM published version 1.107.0 to PyPI.

According to LiteLLM's incident report, all seven wheels for the release were compromised. They were uploaded between 11:39:51 and 11:40:13 UTC and removed by 13:23 UTC.

The wheels contained credential-stealing malware and infrastructure for remote code execution. LiteLLM says the attackers used compromised developer GitHub credentials to modify its release pipeline and approve the malicious release.

The official v1.107.0 GitHub source tag was clean. The PyPI artifacts were built from an attacker-controlled repository.

A build using a StableBuild PyPI snapshot from October 20 would not see 1.107.0 at all. Dependency resolution happens against the registry state from the pinned date.

This is the kind of case dependency cooldown is meant for. A newly published package can be held back for a defined period before it becomes available to builds. Under a two-hour cooldown, 1.107.0 would still have been cooling down when PyPI removed it 103 minutes later.

‍

Knowing what can enter a build

StableBuild Enterprise offers SBOM export, security scanning and dependency cooldown.

SBOM export provides an inventory of the dependencies in a build. Security scanning adds vulnerability information to that inventory. Dependency cooldown controls how quickly newly published versions become available.

PHP2Shell required moving an existing dependency forward to a fixed version. LiteLLM 1.107.0 was a new version you would have been better off not resolving during its short time on PyPI.

A reproducible build gives both changes a known starting point. You can see what produced the existing build, change the dependency set deliberately and keep the resulting state reproducible.

If you need more control over the dependencies entering your builds, get in touch about StableBuild Enterprise.