Welcome back to our Open Source Monthly Updates!
October 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.
Fortunately, 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.
Let's start with the things you probably want to patch first.
PHP2Shell: Two critical vulnerabilities in the PHP runtime
On October 21, PHP released emergency security updates addressing two critical vulnerabilities, collectively called PHP2Shell.
Both can lead to unauthenticated remote code execution under certain conditions, and both affect the PHP runtime itself rather than a specific application or framework.
The first vulnerability, CVE-2026-109618, involves memory corruption during out-of-memory handling. The second, CVE-2026-109619, involves stale global state referencing memory from previous requests.
Successful exploitation has been demonstrated against Apache mod_php, while PHP-FPM is also affected.
This 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.
And this is not just theoretical. Both vulnerabilities were added to CISA's Known Exploited Vulnerabilities catalog on October 26.
Fixed versions are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12.
To make matters slightly more interesting, PHP also disclosed CVE-2026-115560 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.
The PHP Foundation's announcement is worth reading. Beyond the technical details, it also discusses how limited resources and difficult security decisions delayed resolution of these issues.
A reminder that even the most widely used open-source projects can struggle to maintain their security infrastructure.
GitLab: Another month, another critical security update
Last month, we covered a critical GitLab vulnerability allowing arbitrary file reads.
Unfortunately, October was not particularly kind to GitLab administrators either.
On October 12, GitLab released patches for 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.
Only nine days later, GitLab disclosed 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.
Both received a maximum CVSS score of 10.0.
There 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.
Exploitation of the first vulnerability has already been observed, and CISA added it to its Known Exploited Vulnerabilities catalog on October 29.
GitLab published security updates on October 12 and October 21. The latter includes fixes in versions 19.5.1, 19.4.3, 19.3.6, and several older supported branches.
If you operate self-managed GitLab infrastructure, upgrade immediately and review the detection rules GitLab published.
A compromised GitLab instance is particularly problematic because it often has access to source code, CI/CD secrets, deployment credentials, and container registries.
In other words, compromising GitLab can be a rather effective way to compromise everything built and deployed through it.
eMudhra: When you can no longer trust your certificates
We rely on certificate authorities to establish trust in TLS connections.
That works reasonably well, assuming their private keys actually remain private.
In 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.
This means attackers could potentially issue fraudulent certificates that appeared to originate from a trusted CA.
eMudhra revoked the affected certificates, and browser vendors quickly implemented protections. According to eMudhra, the affected intermediates had not issued end-entity certificates.
The more interesting problem concerns applications that do not behave like browsers.
Many TLS clients, including those in containers, proxies, and application runtimes, rely on CA bundles without necessarily checking certificate revocation or enforcing Certificate Transparency.
For example, Istio published a security advisory 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.
This is relevant well beyond Istio.
Simply 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.
The practical takeaway: review your trust stores and update affected runtimes and images. For more details, see eMudhra's incident report.
NVIDIA Run:ai: GPU orchestration becomes open source
Now for some more positive news.
On October 13, NVIDIA announced that it was open-sourcing the complete Run:ai platform under Apache 2.0.
Run:ai provides GPU orchestration for Kubernetes. Its goal is to make expensive GPU infrastructure easier to share across teams and workloads.
The platform includes several components:
- KAI Scheduler: GPU-aware scheduling with gang scheduling, quotas, fair sharing, and topology-aware placement.
- GPU Fractioning Operator: Allows workloads to share GPU resources using CUDA-based mechanisms.
- KAI Resource Management: Handles organizational resource allocation and quotas.
- Workload Map: Provides a common representation for different AI workloads.
The important part is that these components can also be used independently.
For 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.
Having an open-source alternative for this infrastructure is particularly interesting for sovereign AI environments.
However, 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.
Nevertheless, the Run:ai repository is now available for anyone interested in exploring GPU scheduling and resource management.
Open Policy Agent: When signed policies aren't necessarily signed
OPA is widely used to make authorization decisions in cloud-native applications and infrastructure.
One particularly useful capability is distributing signed policy bundles. Applications can verify that their authorization policies originate from a trusted source before using them.
Unfortunately, an October 19 security advisory revealed that signature verification could be bypassed under certain conditions.
There were two separate problems.
First, configurations enabling bundle signing without explicitly specifying signing.keyid could silently accept unsigned bundles.
Second, 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.
The attacker still needs to control or modify the delivered bundle. This is not a vulnerability allowing arbitrary users to bypass any OPA authorization policy.
Nevertheless, it undermines the trust boundary that signed bundles are designed to establish.
Imagine 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.
That assumption did not always hold.
The issue affects OPA versions 0.22.0 through 1.21.2 and is fixed in 1.21.3.
If you distribute signed OPA bundles, this is worth checking carefully, including how your infrastructure handles delta bundles.
llm-d 1.0: Self-hosted AI inference gets serious about operations
We regularly discuss which models to host ourselves.
But once you have selected a model, how do you operate it efficiently for hundreds of users?
This is where llm-d comes in.
The open-source project reached version 1.0 on October 20, bringing a stable configuration API and several capabilities aimed at production operations.
llm-d combines inference engines such as vLLM and SGLang with intelligent routing and distributed inference capabilities.
For 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.
Version 1.0 introduces improved multitenancy, request prioritization, coordinated upgrades, and session-aware routing for agentic workloads.
These 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.
llm-d also supports different accelerator vendors, including NVIDIA, AMD, and Intel GPUs, as well as Google TPUs.
For organizations investigating sovereign AI platforms, this is an interesting development.
In 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.
The operational maturity looks promising, although performance improvements should still be validated against real workloads and hardware.
Pi 1.0: A different approach to AI agents
AI coding agents are becoming increasingly sophisticated. They are also becoming increasingly complex.
Pi takes a rather different approach.
On October 1, Earendil released Pi 1.0, a stable version of its MIT-licensed, extensible AI coding agent and agent harness.
Rather than building every possible feature into the core, Pi aims to remain minimal and lets developers extend it for their own use cases.
Some interesting capabilities in version 1.0 include:
- Codemode: Allows the agent to interact with external tools and MCP servers through generated code.
- Virtual models: Extensions can implement custom model-selection and routing strategies.
- Deferred tool loading: Tools can be made available when needed instead of filling the model's context upfront.
- Transcript-aware configuration: System instructions and tools can change during a conversation.
The project also released Pi Durable, an experimental framework for building longer-running agentic applications with persistent state.
For application engineers, the interesting part is not necessarily replacing an existing coding agent.
It is the possibility of using a relatively small, open-source agent harness as the foundation for customized AI applications.
You maintain control over the agent's tools, models, and integrations without adopting an extensive orchestration framework.
Of 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.
Still, Pi is worth a look for anyone building agentic applications rather than merely consuming them.
You can find the Pi source code and releases on GitHub.
Open Source Summit Europe: Sovereignty and Security
October also brought the Open Source Summit Europe to Prague, with several interesting announcements around security and digital sovereignty.
The Open Source Enterprise Resiliency Alliance (OSERA), 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.
Meanwhile, the Linux Foundation published its 2026 State of Open Source in Europe 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.
Other 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.
Projects we're watching
Alongside the main updates, two projects caught our attention this month.
Volcano 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.
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.
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.
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.
October'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.
Open 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.
Top comments (0)