Three Trust Boundaries Under Pressure: PHP, LiteLLM, and eMudhra

Three October 21 security disclosures affected runtime handling, published package artifacts, and certificate authority key generation. Here is what operators should verify at each boundary.

2 min read516 words
Contents

By Joel Hillier, founder and CEO of Certisyn.

On October 21, 2026, security disclosures from PHP, LiteLLM, and eMudhra highlighted different trust boundaries. PHP released fixes for two critical remote-code-execution flaws. LiteLLM reported that attackers had compromised its v1.107.0 release artifacts. eMudhra disclosed weak keys in several intermediate certificate authorities used by its global TLS business. The incidents had different causes, but each reached beyond the application code an operator can inspect directly.

Runtime: PHP request handling

The PHP project says CVE-2026-109618 and CVE-2026-109619 can allow unauthenticated remote code execution. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Operators using older versions should check their distribution or long-term-support vendor for backported fixes. The project advises updating immediately.

PHP security advisory and update guidance

Package: what users install may differ from source

LiteLLM reported that compromised PyPI wheels for version 1.107.0 and several Docker and GHCR tags were available on October 21. Its incident report says the official v1.107.0 GitHub source tag did not contain the malicious files; the affected artifacts were built from an attacker-controlled repository. A clean source tag therefore did not establish that every published artifact was safe. Operators should follow LiteLLM's affected-version, registry, and credential guidance for the exact package or image they used.

LiteLLM's incident report and affected-artifact guidance

Trust root: how a certificate authority creates keys

eMudhra reported that a flaw in a 2025 key-generation ceremony produced a second set of weak keys. The company says eight intermediate CAs in its global TLS business were affected and that the weak keys reached browser root stores. eMudhra also says its infrastructure and data were not compromised and its Indian digital-signature and eSign businesses are separate. Those statements come from the company while its root-cause investigation continues.

eMudhra's October 21 statement about affected TLS intermediates

What Certisyn checks

Certisyn says its Bastion service assesses internet-facing agent infrastructure, including exposed agent gateways. The company says a scan returns INDETERMINATE and stops when evidence is too thin. Its continuous-monitoring service compares enrolled-domain scans and alerts owners about drift or new dependency advisories. Certisyn also describes a separate determination service for claims such as a patch status, with a record that another party can replay.

Hillier says Certisyn reviewed its application code, container images, and production dependencies that morning and found none of the three incidents in those systems and no high or critical dependency advisories. He says its review of third-party providers is still underway. This is Certisyn's account of its own review, not an independent audit of the company.

Certisyn invites registry participants to run a scan of their own domain at app.certisyn.com/security. Hillier's submission also describes one complimentary single scan for each registry participant through October 31, 2026, using code HOLSCAN at the scan checkout. The submission lists a $500 price before the code. Check Certisyn's current checkout terms for eligibility and availability.

These incidents show why an assessment should identify its boundary: the runtime and version examined, the package artifact and registry, or the certificate chain and key-generation process. A useful record also says what it did not verify.

Continue reading

All posts