Security-focused comparison of LiteLLM alternatives after the 2026 supply chain attack. Portkey, Kong, Cloudflare, Helicone evaluated for governance.
On March 24, 2026, malicious versions 1.82.7 and 1.82.8 of LiteLLM were published to PyPI by a threat actor called TeamPCP. The backdoored packages targeted SSH keys, cloud credentials, Kubernetes secrets, cryptocurrency wallets, and .env files, exfiltrating harvested data to a lookalike domain. Days later, reporting revealed that LiteLLM's SOC 2 Type 2 and ISO 27001 certifications had been obtained via Delve, a compliance startup accused of fabricating over 500 structurally identical audit reports across hundreds of clients. The two incidents left organizations without a reliable software supply chain and without a trustworthy audit trail.
This article compares the main LiteLLM alternatives for secure AI gateways across three criteria the incidents exposed: supply chain integrity, verifiable compliance, and deployment model control. For background on AI gateways in general, start there.
The attack started with Trivy, an open-source security scanner used in LiteLLM's CI/CD pipeline. Compromising Trivy gave the attackers LiteLLM's PyPI publishing credentials. Security scanners require broad read access to the environments they scan, including environment variables, configuration files, and runner memory. When a scanner is compromised, the attacker inherits its read access without triggering permission alerts.
With valid credentials in hand, TeamPCP published two backdoored LiteLLM releases. Version 1.82.8 included a file called litellm_init.pth, which executes automatically at every Python interpreter startup with no import required. This includes when pip runs, when a developer opens a Python REPL, or when an IDE's language server starts. Because the package was published using legitimate credentials, it passed all standard pip hash verification checks.
The malicious versions were live for approximately three hours against a package downloaded roughly 3.4 million times per day. The scope extended beyond Python: TeamPCP's campaign spanned PyPI, npm, Docker Hub, GitHub Actions, and OpenVSX in a single coordinated operation. AI proxy services that concentrate API keys and cloud credentials are high-value supply chain targets because a single compromised dependency yields access to every provider key the proxy manages.
For a deeper breakdown, see our full analysis of the LiteLLM supply chain attack.
The supply chain compromise prompted closer scrutiny of LiteLLM's own code. Three vulnerabilities emerged in the post-incident audit.
CVE-2026-35030 (Critical): Authentication bypass via OIDC cache collision
When enable_jwt_auth was enabled, LiteLLM cached OIDC userinfo using token[:20] as the cache key. JWTs from the same signing algorithm share the same header prefix, so an attacker could forge a token that hit another user's cache entry and inherit their session.
CVE-2026-35029 (High): Privilege escalation via /config/update
The endpoint didn't check the caller's role. Any authenticated user could modify the proxy's runtime configuration, potentially enabling arbitrary file read, admin account takeover, or remote code execution.
Pass-the-hash password storage
Passwords were stored as unsalted SHA-256 hashes, and in some cases plaintext. Several API endpoints returned the hash to any authenticated user, and /v2/login accepted the raw hash as a credential without re-hashing it. A stolen hash was as good as the password itself.
LiteLLM fixed these in v1.83.0 and launched a bug bounty program. The company's CTO also announced a switch to Vanta for compliance re-certification with an independent auditor. For the full CVE details, see our LiteLLM security vulnerabilities breakdown.
Go modules are pinned in go.sum with verifiable checksums against a public checksum database. Pip's dependency resolver can pull transitive dependencies without hash verification unless the project explicitly maintains a locked requirements file with --require-hashes. That gap is what made the .pthauto-execution attack possible: version 1.82.8 was a valid package from PyPI's perspective, signed with legitimate credentials, and pip had no mechanism to flag it.
The evaluation question for any gateway is whether your deployment pipeline would have caught version 1.82.8 before execution.
Delve issued structurally identical SOC 2 reports across hundreds of clients, with only names and logos changed. When evaluating any AI gateway's compliance claims, verify which specific products are covered and which auditor performed the review. Look up the auditor in the AICPA peer review database. Confirm the compliance scope covers the product you are using, not a parent company's generic cloud infrastructure.
The malicious LiteLLM packages were live on PyPI for three hours before quarantine. Teams running automated pip install --upgradein CI had no buffer; teams on a pinned dependency manifest with manual review would have caught the advisory before any deployment. Gateways offering self-managed deployment give teams the option to control their own infrastructure, audit dependencies before deployment, and decouple their upgrade cycle from the vendor's release cadence. Managed-only SaaS gateways remove that buffer entirely.
Separately, LiteLLM's open-source version lacks built-in authentication, audit logging, and policy controls. SSO, admin UIs, and detailed access logs are available only to enterprise (paid) customers.
| Gateway | Architecture | Deployment | License | Supply chain risk profile |
|---|---|---|---|---|
| WSO2 AI Gateway | Go/Envoy | Self-hosted, managed | Apache 2.0 | No PyPI dependency, auditable Go codebase |
| Portkey | Python | Self-hosted, SaaS | Open-source available | PyPI-distributed, self-host mitigates SaaS risk |
| OpenRouter | Managed SaaS | SaaS only | Proprietary | Zero infra, full vendor trust required |
| Kong AI Gateway | Envoy-based | Self-hosted, managed | Enterprise | Established API platform, enterprise governance |
| Cloudflare AI Gateway | Managed SaaS | SaaS only | Proprietary | Cloudflare infrastructure, no self-host option |
| Custom proxy (FastAPI/Envoy) | Varies | Self-hosted | N/A | You own every dependency and every CVE response |
WSO2's gateway is built on Envoy Proxy, written primarily in Go (88.9% of the codebase), and released under the Apache 2.0 license. It is not a Python package. The Go module graph is pinned with verifiable checksums in go.sum, and Envoy-based gateways follow Kubernetes-native deployment patterns with no .pth auto-execution surface.
For teams in regulated industries that need auditable builds and self-hosted deployment, WSO2 addresses the supply chain and deployment model criteria directly. The Apache 2.0 license means you can inspect and build from source.
Portkey bundles gateway routing, observability, guardrails, and cost tracking into a unified platform supporting 200+ AI models through an OpenAI-compatible single API. It offers both a managed SaaS option and an open-source self-hosted deployment.
Self-hosting Portkey lets teams pin a specific release and review the dependency manifest before deploying. Portkey is a Python-based system, though, so it carries the same PyPI distribution surface as LiteLLM: transitive dependencies, pip's resolver behavior, and the .pth execution vector all apply to any Python package pulled from PyPI.
Portkey's guardrails run inline with the gateway request path, covering input/output filtering and content policy enforcement alongside its routing and observability features. For more on gateway-level guardrails, see our AI guardrails guide. See also our Helicone alternatives comparison for how Portkey stacks up on observability. For a direct comparison, see SHIM vs Portkey.
OpenRouter is a managed, pay-per-token routing layer. It routes requests across multiple model providers through a single API endpoint, with no infrastructure for the calling team to deploy or maintain.
OpenRouter publishes no self-hosted option, no dependency manifest for review, no audit artifacts, and no SLA for security incident notification. These gaps disqualify it from most SOC 2-scoped or FedRAMP-adjacent deployments.
Kong extends its existing API gateway platform with AI-specific capabilities built on Envoy. Kong's AI plugins add model routing and token-level governance. Teams already running Kong have existing audit artifacts for their gateway deployment, including penetration test results, compliance documentation, and operational runbooks. The AI plugins extend that audited infrastructure.
The enterprise licensing model means this is not a lightweight evaluation. But for organizations already running Kong in production, the AI capabilities layer onto an existing, documented deployment.
Both are managed SaaS offerings tied to their respective platforms. They provide CDN-level performance and zero infrastructure management. Neither offers self-hosted deployment. Like OpenRouter, they require full trust in the vendor's pipeline. They suit teams already invested in those ecosystems who accept managed-only deployment. See the detailed breakdown at SHIM vs Cloudflare AI Gateway.
A FastAPI or raw Envoy proxy gives you control over every dependency and every deployment decision. You also own every security patch and every model compatibility update. Model providers regularly change API interfaces, authentication flows, and endpoint schemas, each requiring downstream proxy updates. Maintaining parity with even two or three providers is a sustained engineering load.
Air-gapped environments or deployments where vendor SaaS is prohibited by policy (common in defense and intelligence) may require this approach.
Regulated industries (finance, healthcare, government). WSO2's Go/Envoy architecture and Apache 2.0 license let you build from source, audit the dependency tree with go.sum checksums, and demonstrate chain of custody. The non-PyPI architecture eliminates the .pth auto-execution vector.
Startups and prototyping teams.OpenRouter or Portkey's managed tier. Portkey's 200+ model support through an OpenAI-compatible API covers major providers through one integration point, and its open-source self-hosted option provides a migration path when security requirements tighten.
Teams with existing API infrastructure.Kong's AI plugins extend an already-audited gateway deployment. The existing compliance documentation, penetration test results, and operational runbooks carry over.
Compliance verification for any vendor. Request the audit letter directly. Look up the auditor in the AICPA peer review database. Confirm the scope covers the specific product version you would deploy.
Governance, PII redaction, and security as the primary feature. That is what SHIM was built for. The comparison articles linked throughout this piece cover the specifics against each alternative.
LiteLLM shipped a rebuilt CI/CD pipeline and patched releases after the March 2026 compromise. The poisoned packages (1.82.7 and 1.82.8) were live on PyPI for approximately three hours. Whether the current release meets your security requirements depends on your risk tolerance and whether you need the enterprise-tier features (SSO, audit logs, advanced budgets) that are not available in the open-source version.
Cloudflare AI Gateway offers 100,000 requests per day at no cost, making it functionally free for moderate-volume workloads. Among paid options, Portkey's 200+ model support through an OpenAI-compatible API covers major providers through one integration point. LiteLLM itself is free under MIT license but enterprise security features require a paid tier.
For supply chain integrity and auditable builds, WSO2's Go/Envoy architecture with Apache 2.0 licensing eliminates the PyPI distribution surface entirely. For compliance certifications with verifiable auditors, check the AICPA peer review database for any vendor you evaluate. For AI governance with built-in PII redaction, SHIM focuses specifically on the security and governance layer.
Three vulnerabilities emerged: CVE-2026-35030 (Critical) — authentication bypass via OIDC cache collision using truncated token prefixes as cache keys; CVE-2026-35029 (High) — privilege escalation via the /config/update endpoint that lacked role checks; and a pass-the-hash password storage flaw where unsalted SHA-256 hashes could be used directly as credentials. All were patched in v1.83.0.