Today’s Topics:
- PHP2Shell Was Under Attack Before the Patches Were Public
- A Forgotten Credential Turned LiteLLM’s Release Pipeline Into an Attack Path
- How can Netizen help?
PHP2Shell Was Under Attack Before the Patches Were Public
Two critical vulnerabilities in the PHP runtime have raised concerns about how quickly attackers can begin targeting widely deployed software before organizations have an opportunity to apply security updates. On October 21, 2026, the PHP development team released emergency patches addressing CVE-2026-109618 and CVE-2026-109619, two memory safety vulnerabilities collectively known as PHP2Shell. Both received CVSS 4.0 scores of 9.2 and can permit unauthenticated remote code execution under vulnerable conditions. The vulnerabilities affect PHP itself rather than a particular application framework, potentially exposing web services built on WordPress, Drupal, Magento, Laravel, and other PHP-based technologies.
The disclosure became more concerning after Amazon Threat Intelligence reported evidence of attempted exploitation predating the public announcement. Analysis of telemetry collected through Amazon’s MadPot honeypot infrastructure identified an exploitation attempt on October 17, four days before the coordinated disclosure. The activity originated from an IP address associated with a commercial anonymization network. Additional attempts were observed during the early hours of October 21, before the scheduled release of the patches. Amazon reported that these attempts used different payloads and anonymization infrastructure, suggesting activity from multiple actors, although the researchers could not establish how the attackers obtained information about the vulnerabilities.
The technical issues involve how PHP manages memory during request processing and cleanup. CVE-2026-109618 originates from the runtime’s handling of out-of-memory conditions. PHP has historically used the longjmp() function to interrupt execution when memory allocation fails, allowing the interpreter to exit the current context without following the normal sequence of function returns. Under certain conditions, this behavior can interrupt request processing before internal data structures are fully initialized. The request shutdown process may subsequently treat those structures as valid, creating opportunities for memory corruption and exploitation.
Attackers can trigger the vulnerable condition through specially constructed HTTP requests that manipulate memory consumption during request parsing. PHP’s handling of multipart form data is particularly relevant, as nested input fields, file metadata structures, and request headers can require considerably more memory than their original network representation. Some request structures can cause memory exhaustion without exceeding the limits that administrators might expect to prevent oversized uploads.
CVE-2026-109619 involves a related but distinct problem with persistent request state. Certain internal references can survive after the memory backing them has been released. When a subsequent request is processed by the same worker, the runtime may access stale pointers before the affected state is properly reset. This creates a use-after-free condition that can expose memory contents or potentially support code execution under appropriate circumstances.
The distinction between the two vulnerabilities matters for exploit development and defensive monitoring. One involves abnormal interruption during memory allocation, and the other involves references that persist beyond their intended lifetime. Both expose weaknesses in assumptions about how PHP initializes, releases, and reuses internal state during request handling.
The impact also varies across PHP deployment models. Apache configurations using mod_php are particularly exposed to CVE-2026-109618, since the module can invoke request shutdown procedures after an error during initialization. Researchers demonstrated that exploitation can occur before the application begins executing its own PHP code, potentially bypassing authentication checks implemented within the application itself. PHP-FPM behaves differently during certain initialization failures, terminating affected worker processes rather than continuing through the same cleanup path. That behavior reduces exposure to the demonstrated attack path but does not eliminate the broader vulnerability, particularly in application-specific execution scenarios.
This distinction creates challenges for vulnerability assessment. Two organizations running the same PHP version may face different exploitation conditions depending on their server interface, memory configuration, installed extensions, and request handling behavior. An administrator relying exclusively on application-level vulnerability scanning may also miss the problem entirely, since the underlying weakness exists below the application framework.
The exploitation timeline further complicates incident response. Amazon identified proof-of-concept material circulating during the hours preceding public disclosure, followed by additional attempts against its sensors after the patches became available. The October 17 activity demonstrates that exploitation attempts can precede public advisories, making the disclosure date an unreliable starting point for retrospective threat hunting. Observed attempts do not establish that every targeted system was compromised, but they provide sufficient reason to examine relevant activity before the patch announcement.
Security teams investigating possible exploitation should review web server access logs, PHP error records, WAF telemetry, and available endpoint activity beginning at least October 17. Suspicious multipart requests, repeated memory exhaustion events, abnormal worker termination, and unusual application errors may provide useful investigative leads. Those indicators require correlation with surrounding activity, since memory allocation failures and malformed requests can also occur during legitimate operations.
Successful remote code execution would ordinarily occur within the security context of the affected PHP worker. Depending on the application’s configuration, that account may have access to database credentials, environment variables, local application files, session information, and internal network resources. Investigators should examine unexpected child processes launched by web-serving services, newly created executable files, suspicious outbound connections, and unusual access to credentials or configuration files. Evidence of code execution should trigger a broader investigation into potential persistence, credential theft, and lateral movement.
The PHP project released fixes in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Administrators using supported branches should install the appropriate updates and verify that running services have loaded the patched binaries. Updating packages on disk does not automatically replace code already loaded into long-running Apache or PHP-FPM workers, making service restarts an important part of remediation.
Older PHP releases introduce additional difficulties. PHP 8.1 and earlier no longer receive regular upstream security updates, although certain Linux distributions and long-term support vendors provide backported fixes. Organizations operating legacy applications must determine whether their vendor has incorporated the necessary corrections rather than relying solely on the version number reported by the runtime. Containerized workloads also require attention, since rebuilding or redeploying applications without updating their base images can leave vulnerable PHP binaries in production.
Temporary mitigations can reduce exposure when immediate patching is impossible. Restricting internet access to vulnerable applications, applying validated WAF protections, and limiting request sizes or multipart processing can interfere with known exploitation methods. Disabling session upload progress can also reduce exposure to confirmed attack paths associated with stale request state. These measures are not equivalent to installing corrected runtime code and should be treated as interim controls.
The PHP2Shell incident also raises questions about vulnerability discovery and coordinated disclosure. The PHP Foundation acknowledged that early indications of one of the underlying problems had been identified in 2024, but the issue remained unresolved amid technical difficulties and competing maintenance priorities. The complexity of changing memory handling behavior across a mature runtime contributed to the extended remediation process. Once exploitation research progressed and technical details began circulating, defenders faced a substantially shorter period in which to prepare.
For organizations that depend on PHP, the primary lesson extends beyond applying the latest emergency updates. Internet-facing software requires accurate asset inventories, reliable deployment procedures, and incident response processes that account for exploitation before public disclosure. Security teams also need visibility into runtime behavior, since vulnerabilities in an interpreter or application server may circumvent protections implemented at the application layer.
PHP2Shell demonstrates how a vulnerability within a widely deployed runtime can create risk across otherwise unrelated applications. Its most significant implication is the narrowing gap between private vulnerability knowledge and public exploitation attempts. Organizations can no longer assume that the release of a security advisory marks the beginning of attacker activity, and remediation processes built around that assumption may leave a significant period of exposure unexamined.
A Forgotten Credential Turned LiteLLM’s Release Pipeline Into an Attack Path
A supply chain compromise involving the open-source AI gateway LiteLLM has demonstrated how stolen credentials and compromised release infrastructure can transform legitimate software distributions into malware delivery mechanisms. On October 21, 2026, attackers published a malicious version of LiteLLM, identified as version 1.107.0, through the Python Package Index (PyPI) and the project’s official container registries. The affected release included credential-stealing malware and functionality capable of retrieving and executing additional code, creating risks for organizations that installed the package or deployed its associated container images.
LiteLLM is widely used to integrate applications with multiple large language model providers through a common interface. Organizations deploy it to manage API requests, route traffic between models, enforce usage limits, and centralize access to inference services. These functions frequently require access to cloud infrastructure, database connections, and authentication credentials for external AI providers. A compromised LiteLLM installation can therefore expose information extending beyond the application itself.
The malicious release remained available through PyPI for approximately two hours before being removed. Affected container images were distributed through Docker Hub and GitHub Container Registry, including releases associated with the v1.107.0, latest, main-latest, and main-stable tags. The compromise was particularly concerning since the attacker distributed malware through infrastructure that users already trusted, rather than publishing an unrelated package under a misleading name.
LiteLLM’s subsequent investigation traced the intrusion to a credential exposure that occurred months earlier. On May 27, a configuration file containing the master key for an internal LiteLLM Agent Platform deployment was committed to a public GitHub repository. The exposed information was quickly identified and removed from the visible repository history, and the associated credentials were recognized as requiring revocation. The master key, though, remained active.
On October 10, the attacker used that credential to access the Agent Platform’s API. The compromised service exposed a GitHub CLI OAuth token associated with an owner of LiteLLM’s GitHub organization. That token was not restricted to a narrowly scoped service account and provided the attacker with extensive privileges across the organization’s repositories. The attack illustrates how an exposed application credential can become an entry point into a much more sensitive identity and access management system.
The attacker subsequently used the compromised GitHub identity to execute unauthorized CI workflows that transmitted repository secrets to an external endpoint. Those workflows exposed additional GitHub CLI tokens associated with two maintainers. With access to multiple identities, the attacker could perform actions that appeared to originate from different authorized users, including triggering workflows, approving releases, and manipulating repository settings.
The compromise reached LiteLLM’s software release infrastructure on October 21. The attacker modified the release workflow so that builds retrieved their source from an attacker-controlled repository rather than the legitimate LiteLLM project. An initial attempt to modify the protected release repository using a maintainer token was rejected by branch protection. The attacker then used the organization owner’s credentials to bypass the restrictions and push the malicious change.
The release process normally required restricted approval before publishing new artifacts. Temporary modifications to support more frequent releases had permitted separate engineers to initiate and approve the process. The attacker used the stolen credentials to satisfy those approval requirements and authorize a release built from the malicious repository. The resulting packages were distributed through LiteLLM’s established publishing infrastructure.
This distinction is central to the security implications of the incident. The malicious release was not the result of an ordinary dependency substitution or a developer accidentally installing the wrong package. An attacker with privileged access manipulated the process responsible for producing trusted software artifacts. Existing build and publication mechanisms then distributed the compromised code to downstream users.
The official GitHub source tag for version 1.107.0 did not contain the malicious files found in the distributed binaries. The affected Python wheels had been built from the attacker-controlled repository, creating a discrepancy between the source code users could inspect and the packages they actually installed. This demonstrates why reviewing a public source repository is insufficient when the build and publication process cannot reliably establish which source revision produced an artifact.
The malware itself used Python interpreter initialization mechanisms to execute without requiring an application to import LiteLLM. Researchers identified three malicious files, cook.pth, cook.py, and sitecustomize.py, included in the affected Python wheels. During installation, these files were placed in the interpreter’s site-packages environment, outside the ordinary LiteLLM package directory.
Python processes certain .pth files during interpreter initialization, including executable import statements. The malicious cook.pth contained an instruction to import the cook module, which triggered execution of the associated payload. The module used Base64 encoding and zlib compression to conceal additional Python code, which was decoded and executed at runtime.
A separate execution path used sitecustomize.py, a Python module that can be imported automatically during normal interpreter initialization. This component provided additional functionality for retrieving and executing remote Python code on Unix-based systems. Microsoft’s analysis identified the capability but did not confirm that the remote execution stage had been activated during observed activity.
The use of startup hooks significantly increased the potential impact. A compromised environment did not need to execute a LiteLLM-specific command or start the proxy application to activate the credential collector. Simply launching a Python interpreter with the affected package installed could trigger malicious behavior. This potentially exposed developer workstations, CI/CD agents, automated testing environments, and containerized applications that shared the contaminated Python environment.
The credential collection functionality targeted several categories of sensitive information. Researchers identified routines designed to retrieve AWS, Azure, and Google Cloud authentication material, Kubernetes service account tokens, SSH private keys, Docker configuration files, environment variables, package manager credentials, and authentication information associated with developer tools. Additional functionality attempted to collect browser credential data, shell history, and selected records from LiteLLM’s proxy database.
The malware’s access remained subject to the privileges and files available to the compromised process. Its ability to search for a credential did not establish that the credential was present or successfully retrieved. Even with that limitation, the range of targeted information illustrates the risks of executing untrusted code in development and infrastructure environments where multiple authentication mechanisms are often available to the same user or workload.
Collected information was prepared for exfiltration using a combination of symmetric and asymmetric encryption. Microsoft’s analysis found that the collector generated an AES-256 key to encrypt the gathered data, then protected that key using an embedded RSA public key. The resulting encrypted data and associated metadata were packaged for transmission to an attacker-controlled endpoint.
The incident presents a difficult detection problem. Connections originating from a Python process may appear consistent with ordinary package management or application behavior, particularly in systems that routinely retrieve dependencies and communicate with external services. The collector’s use of encoded payloads, background execution, and encrypted outbound communication also complicated straightforward inspection.
Security monitoring can help identify suspicious activity through unexpected Python startup modules, unusual outbound connections, credential file access, and modifications to interpreter library directories. Endpoint telemetry is particularly useful for detecting Python processes interacting with authentication stores or initiating connections unrelated to the application’s expected behavior. Organizations should also monitor new or modified .pth files and sitecustomize.py modules in environments where those additions are not part of an approved configuration.
The compromise created another challenge for incident response: removing the affected Python package did not necessarily eliminate the malicious startup files. The installed artifacts placed executable content outside the application’s normal package directory. An administrator deleting the LiteLLM package without inspecting the interpreter environment could leave components capable of executing during subsequent Python launches.
LiteLLM instructed affected users to avoid immediately running pip install within contaminated environments, since launching pip itself starts Python and could reactivate the malware. Rebuilding affected virtual environments and containers from verified clean artifacts provides a more reliable remediation path than attempting to remove only the primary application directory.
Organizations that installed version 1.107.0 or executed affected container images during the compromise window should identify every potentially exposed environment, investigate available endpoint and network telemetry, and assess whether credentials accessible to those systems require revocation. This includes cloud workload identities, AI provider API keys, database credentials, CI/CD secrets, and other authentication material that may have been available to the compromised processes.
Dependency inventories, package caches, container image digests, and build records can help identify affected systems. Teams should be careful when reviewing mutable container tags, since a tag currently pointing to a clean image does not establish which image was previously deployed. Historical image digests and deployment records provide a more reliable basis for determining whether a compromised artifact was executed.
The incident also demonstrates the limitations of traditional supply chain verification mechanisms. An official package name, recognized publishing account, and successful release workflow do not independently establish that an artifact was built from approved source code. In this case, attackers used compromised identities to manipulate the source repository selected by the legitimate release process.
Organizations can reduce this risk by restricting release workflow permissions, protecting privileged identities, and separating the authority to modify build configurations from the authority to approve production releases. Build provenance controls should connect distributed artifacts to authorized source revisions and verified workflow identities. Software signing remains useful for establishing artifact integrity, but signatures must be considered alongside the trustworthiness of the process that produced the signed artifact.
The initial credential exposure is equally significant. The compromise began with an authentication key that remained valid after its publication in a public repository. That key exposed a privileged GitHub token through an internal service, which provided access to additional credentials and eventually to the software release infrastructure. Each stage depended on access inherited from the previous one.
LiteLLM had experienced a separate supply chain compromise in March 2026, when malicious versions 1.82.7 and 1.82.8 were published through PyPI. Researchers have not established a connection between that earlier incident and the October compromise. The repeated targeting nonetheless demonstrates the security significance of software used to connect AI applications with cloud services and external model providers.
The October incident illustrates how supply chain attacks can originate far outside the final application repository. A leaked credential in an experimental service became the starting point for compromised organizational identities, unauthorized CI execution, altered release configurations, and malicious packages distributed through official channels.
For organizations consuming open-source software, the lesson extends beyond avoiding a particular compromised version. Dependency management needs to account for artifact provenance, build system integrity, credential exposure, and the privileges available to installed packages. For maintainers, the incident demonstrates the importance of revoking exposed credentials, limiting automation permissions, and protecting release processes against compromised developer identities.
The LiteLLM compromise shows how an attacker can turn a trusted distribution process into the delivery mechanism for malicious code. Preventing similar incidents requires controlling the credentials and workflows that determine what gets built, who can approve it, and which artifacts ultimately reach production systems.
How Can Netizen Help?
Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally.
Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.
Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.
Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.
Leave a Reply