{"slug": "ipt-s-oss-october-2026-updates-php2shell-gitlab-emudhra-run-ai-opa-llm-d-and-pi", "title": "ipt's OSS October 2026 Updates: PHP2Shell, GitLab, eMudhra, Run:ai, OPA, llm-d, and Pi", "summary": "In October, PHP released emergency updates for two critical runtime vulnerabilities, collectively called PHP2Shell (CVE-2026-109618 and CVE-2026-109619), that allow unauthenticated remote code execution and were added to CISA's Known Exploited Vulnerabilities catalog on October 26. GitLab separately patched two maximum-severity integer-overflow flaws in its CI/CD regular-expression compiler (CVE-2026-97229 and CVE-2026-110264), the first of which has already been exploited. The roundup also notes NVIDIA open-sourcing Run:ai, llm-d reaching version 1.0, and the lightweight Pi agent framework.", "body_md": "Welcome back to our Open Source Monthly Updates!\n\nOctober was a particularly busy month for security. PHP and GitLab suffered critical vulnerabilities that allow remote code execution, while a certificate authority incident raised uncomfortable questions about how much we can trust TLS connections.\n\nFortunately, there is also good news. NVIDIA open-sourced its Run:ai platform, llm-d reached version 1.0, and Pi is showing how lightweight, extensible AI agents could become an interesting alternative to more opinionated frameworks.\n\nLet's start with the things you probably want to patch first.\n\nOn October 21, PHP released emergency security updates addressing two critical vulnerabilities, collectively called **PHP2Shell**.\n\nBoth can lead to unauthenticated remote code execution under certain conditions, and both affect the PHP runtime itself rather than a specific application or framework.\n\nThe first vulnerability, [CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w), involves memory corruption during out-of-memory handling. The second, [CVE-2026-109619](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp), involves stale global state referencing memory from previous requests.\n\nSuccessful exploitation has been demonstrated against Apache `mod_php`, while PHP-FPM is also affected.\n\nThis is particularly concerning because fixing your application's dependencies will not help if the underlying interpreter remains vulnerable. Whether you use Symfony, Laravel, WordPress, or something else entirely, the PHP runtime needs to be updated.\n\nAnd this is not just theoretical. Both vulnerabilities were added to CISA's Known Exploited Vulnerabilities catalog on October 26.\n\nFixed versions are **PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12**.\n\nTo make matters slightly more interesting, PHP also disclosed [CVE-2026-115560](https://www.php.net/archive/2026.php#2026-10-23-1) on October 23. This separate, much narrower vulnerability requires an unusual combination of session configuration and application behavior. It was not fixed by the emergency releases. PHP recommends disabling `session.upload_progress.enabled` in affected configurations until a fix is available.\n\nThe [PHP Foundation's announcement](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) is worth reading. Beyond the technical details, it also discusses how limited resources and difficult security decisions delayed resolution of these issues.\n\nA reminder that even the most widely used open-source projects can struggle to maintain their security infrastructure.\n\nLast month, we covered a critical GitLab vulnerability allowing arbitrary file reads.\n\nUnfortunately, October was not particularly kind to GitLab administrators either.\n\nOn October 12, GitLab released patches for [CVE-2026-97229](https://www.cve.org/CVERecord?id=CVE-2026-97229), a critical vulnerability involving integer overflow in the CI/CD regular-expression compiler. Specially crafted regular expressions in CI/CD configuration files could lead to remote code execution on the GitLab server.\n\nOnly nine days later, GitLab disclosed [CVE-2026-110264](https://www.cve.org/CVERecord?id=CVE-2026-110264), another integer overflow in regular-expression compilation. This second vulnerability affects an even broader range of GitLab versions, potentially dating back to version 7.0.\n\nBoth received a maximum CVSS score of 10.0.\n\nThere are exploitation prerequisites, particularly for the first vulnerability, where an attacker needs a way to introduce malicious CI/CD configuration. However, GitLab confirmed that the vulnerabilities could potentially be exploited without authentication under certain conditions.\n\nExploitation of the first vulnerability has already been observed, and CISA added it to its Known Exploited Vulnerabilities catalog on October 29.\n\nGitLab published [security updates on October 12](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/) and [October 21](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/). The latter includes fixes in versions 19.5.1, 19.4.3, 19.3.6, and several older supported branches.\n\nIf you operate self-managed GitLab infrastructure, upgrade immediately and review the detection rules GitLab published.\n\nA compromised GitLab instance is particularly problematic because it often has access to source code, CI/CD secrets, deployment credentials, and container registries.\n\nIn other words, compromising GitLab can be a rather effective way to compromise everything built and deployed through it.\n\nWe rely on certificate authorities to establish trust in TLS connections.\n\nThat works reasonably well, assuming their private keys actually remain private.\n\nIn October, researchers discovered that eight intermediate certificate authorities operated by eMudhra had been created with cryptographically weak keys. Their private keys could effectively be reconstructed from information available in the public certificates.\n\nThis means attackers could potentially issue fraudulent certificates that appeared to originate from a trusted CA.\n\neMudhra revoked the affected certificates, and browser vendors quickly implemented protections. According to eMudhra, the affected intermediates had not issued end-entity certificates.\n\nThe more interesting problem concerns applications that do not behave like browsers.\n\nMany TLS clients, including those in containers, proxies, and application runtimes, rely on CA bundles without necessarily checking certificate revocation or enforcing Certificate Transparency.\n\nFor example, [Istio published a security advisory](https://istio.io/latest/news/security/istio-security-2026-008/) and updated its dependencies and CA bundles to address the incident. Internal Istio mesh mTLS is not affected, but outbound TLS connections using publicly trusted CAs can be.\n\nThis is relevant well beyond Istio.\n\nSimply updating the trust store on a Kubernetes node might not help if an application container ships its own outdated certificates or uses a runtime with different trust behavior.\n\nThe practical takeaway: review your trust stores and update affected runtimes and images. For more details, see [eMudhra's incident report](https://emudhra.com/en/post/certificate-security-incident).\n\nNow for some more positive news.\n\nOn October 13, NVIDIA announced that it was [open-sourcing the complete Run:ai platform](https://developer.nvidia.com/blog/nvidia-runai-is-now-open-source-as-part-of-nvidia-dsx-ai-factory-platform) under Apache 2.0.\n\nRun:ai provides GPU orchestration for Kubernetes. Its goal is to make expensive GPU infrastructure easier to share across teams and workloads.\n\nThe platform includes several components:\n\nThe important part is that these components can also be used independently.\n\nFor enterprises building shared AI platforms, efficient GPU allocation is becoming increasingly important. Running one model on one GPU is relatively straightforward. Running dozens of models and training jobs for different teams, while ensuring fair resource allocation, is a different challenge entirely.\n\nHaving an open-source alternative for this infrastructure is particularly interesting for sovereign AI environments.\n\nHowever, some vendor dependencies remain. GPU sharing still relies on NVIDIA technologies, and downloading NVIDIA's packaged Community Product involves additional license terms. Open source does not automatically mean hardware independence.\n\nNevertheless, the [Run:ai repository](https://github.com/dsx-ai-factory/run-ai) is now available for anyone interested in exploring GPU scheduling and resource management.\n\nOPA is widely used to make authorization decisions in cloud-native applications and infrastructure.\n\nOne particularly useful capability is distributing signed policy bundles. Applications can verify that their authorization policies originate from a trusted source before using them.\n\nUnfortunately, an [October 19 security advisory](https://github.com/open-policy-agent/opa/security/advisories/GHSA-g2pf-6v5v-qcc8) revealed that signature verification could be bypassed under certain conditions.\n\nThere were two separate problems.\n\nFirst, configurations enabling bundle signing without explicitly specifying `signing.keyid` could silently accept unsigned bundles.\n\nSecond, an attacker could replace a signed snapshot bundle with an unsigned delta bundle. OPA would accept the delta without verifying its signature, potentially allowing an attacker to modify policy data.\n\nThe attacker still needs to control or modify the delivered bundle. This is not a vulnerability allowing arbitrary users to bypass any OPA authorization policy.\n\nNevertheless, it undermines the trust boundary that signed bundles are designed to establish.\n\nImagine distributing centrally managed authorization policies to hundreds of applications. If an attacker compromises the bundle distribution infrastructure, signatures should prevent unauthorized modifications from being accepted.\n\nThat assumption did not always hold.\n\nThe issue affects OPA versions 0.22.0 through 1.21.2 and is fixed in **1.21.3**.\n\nIf you distribute signed OPA bundles, this is worth checking carefully, including how your infrastructure handles delta bundles.\n\nWe regularly discuss which models to host ourselves.\n\nBut once you have selected a model, how do you operate it efficiently for hundreds of users?\n\nThis is where [llm-d](https://llm-d.ai/blog/llm-d-v1.0-state-of-the-art-inference-ready-for-day-2) comes in.\n\nThe open-source project reached version **1.0 on October 20**, bringing a stable configuration API and several capabilities aimed at production operations.\n\nllm-d combines inference engines such as vLLM and SGLang with intelligent routing and distributed inference capabilities.\n\nFor example, it can split the prefill and decode phases of inference across different GPU pools. It also supports KV-cache-aware routing, attempting to send requests to workers that already hold reusable context.\n\nVersion 1.0 introduces improved multitenancy, request prioritization, coordinated upgrades, and session-aware routing for agentic workloads.\n\nThese features matter because a shared inference platform needs more than raw token throughput. It must handle competing workloads, avoid one tenant monopolizing resources, and remain available during upgrades.\n\nllm-d also supports different accelerator vendors, including NVIDIA, AMD, and Intel GPUs, as well as Google TPUs.\n\nFor organizations investigating sovereign AI platforms, this is an interesting development.\n\nIn combination with Run:ai, it also demonstrates how the open-source ecosystem is starting to address different layers of enterprise AI infrastructure: GPU allocation on one side and efficient model serving on the other.\n\nThe operational maturity looks promising, although performance improvements should still be validated against real workloads and hardware.\n\nAI coding agents are becoming increasingly sophisticated. They are also becoming increasingly complex.\n\nPi takes a rather different approach.\n\nOn October 1, Earendil released [Pi 1.0](https://earendil.com/posts/pi-1-0/), a stable version of its MIT-licensed, extensible AI coding agent and agent harness.\n\nRather than building every possible feature into the core, Pi aims to remain minimal and lets developers extend it for their own use cases.\n\nSome interesting capabilities in version 1.0 include:\n\nThe project also released **Pi Durable**, an experimental framework for building longer-running agentic applications with persistent state.\n\nFor application engineers, the interesting part is not necessarily replacing an existing coding agent.\n\nIt is the possibility of using a relatively small, open-source agent harness as the foundation for customized AI applications.\n\nYou maintain control over the agent's tools, models, and integrations without adopting an extensive orchestration framework.\n\nOf course, a stable agent harness does not automatically solve enterprise requirements such as sandboxing, auditing, or reliable long-running execution. Pi Durable is also explicitly experimental.\n\nStill, Pi is worth a look for anyone building agentic applications rather than merely consuming them.\n\nYou can find the [Pi source code and releases on GitHub](https://github.com/earendil-works/pi).\n\nOctober also brought the **Open Source Summit Europe** to Prague, with several interesting announcements around security and digital sovereignty.\n\nThe [Open Source Enterprise Resiliency Alliance (OSERA)](https://osera.finos.org/), backed by major banks including Deutsche Bank and Goldman Sachs, announced that it was operational. Rather than having every organization independently patch the same vulnerable dependencies, OSERA aims to coordinate remediation efforts. The initiative has already delivered fixes for more than 50 projects in the Java ecosystem, although access to the initial patch service is restricted to members. An interesting approach to making open-source maintenance more sustainable.\n\nMeanwhile, the Linux Foundation published its [2026 State of Open Source in Europe](https://www.linuxfoundation.org/research/world-of-open-source-eu-2026) report. **94% of surveyed organizations consider digital sovereignty important**, yet 31% still lack formal open-source governance. The report highlights an important distinction: using open source is not the same as being technologically independent. The ability to maintain and contribute to the software matters just as much.\n\nOther conference topics included practical preparations for the EU Cyber Resilience Act, verifiable identities for open-source contributors and AI agents, and improved SBOM standards for software supply chains.\n\nAlongside the main updates, two projects caught our attention this month.\n\n[Volcano](https://www.cncf.io/blog/2026/10/28/volcano-v1-16-released-namespacequeue-fairshare-and-a-broader-hypernode-ecosystem/) released version 1.16, introducing namespace-local queue hierarchies and historical resource-aware fair-share scheduling. As GPU infrastructure becomes increasingly shared between teams, features like these are particularly interesting. Volcano is also worth comparing with NVIDIA's KAI Scheduler if you're evaluating scheduling solutions for AI workloads.\n\n[agentgateway](https://github.com/agentgateway/agentgateway) is an open-source gateway for AI agents, LLMs, and MCP servers. It provides centralized authentication, authorization, routing, and observability. Version 1.7, released in October, introduced improvements to model routing, analytics, and policy enforcement for MCP traffic. As enterprises increasingly integrate AI agents with internal systems, having a central place to control and observe their communication could become important.\n\n[ToolHive](https://github.com/stacklok/toolhive) tackles a related problem from a different angle: securely running and managing MCP servers. It supports container isolation, Kubernetes deployments, authentication, and access policies. October brought further improvements to authorization and even added support for the Pi coding agent mentioned above. As MCP servers increasingly provide access to sensitive internal systems, managing their lifecycle and security becomes essential. ToolHive is still pre-1.0, but it is an interesting candidate for building enterprise MCP platforms.\n\n[Capsule](https://github.com/projectcapsule/capsule) takes an interesting approach to Kubernetes multitenancy. Rather than creating separate virtual clusters, it groups namespaces into tenants with shared policies, quotas, and RBAC. With Capsule Proxy, tenants also get a filtered view of the Kubernetes API, allowing them to list their own namespaces without accessing those of other tenants. October's 0.15 release expanded tenant policy capabilities and addressed several security issues. For internal developer platforms, Capsule could offer an attractive alternative to vCluster, avoiding the overhead of separate control planes. The trade-off is that tenants still share the underlying Kubernetes control plane.\n\nOctober's developments highlight two directions in open source. Critical vulnerabilities in PHP, GitLab, and OPA remind us that maintaining open-source infrastructure requires constant attention. Meanwhile, projects such as Run:ai, llm-d, and Pi show how quickly the ecosystem around AI infrastructure and agentic applications is maturing.\n\nOpen source increasingly provides the building blocks for independent, enterprise-grade platforms. Operating them might not be getting easier, but the architectural choices are certainly becoming more interesting.", "url": "https://wpnews.pro/news/ipt-s-oss-october-2026-updates-php2shell-gitlab-emudhra-run-ai-opa-llm-d-and-pi", "canonical_source": "https://dev.to/ipt/ipts-oss-october-2026-updates-php2shell-gitlab-emudhra-runai-opa-llm-d-and-pi-1gb0", "published_at": "2026-11-02 05:47:14+00:00", "updated_at": "2026-11-02 05:52:07.173860+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "developer-tools"], "entities": ["PHP", "GitLab", "CISA", "NVIDIA", "Run:ai", "llm-d", "Pi", "PHP Foundation"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/ipt-s-oss-october-2026-updates-php2shell-gitlab-emudhra-run-ai-opa-llm-d-and-pi", "markdown": "https://wpnews.pro/news/ipt-s-oss-october-2026-updates-php2shell-gitlab-emudhra-run-ai-opa-llm-d-and-pi.md", "text": "https://wpnews.pro/news/ipt-s-oss-october-2026-updates-php2shell-gitlab-emudhra-run-ai-opa-llm-d-and-pi.txt", "jsonld": "https://wpnews.pro/news/ipt-s-oss-october-2026-updates-php2shell-gitlab-emudhra-run-ai-opa-llm-d-and-pi.jsonld"}}