Lead Story | High — Credible Imminent Risk | Cloud+DevOps · Dev |
|
BadHost Flaw in Starlette Lets Attackers Bypass Authentication With a Single HTTP Character — AI Agent Servers Are First in Line
A malformed HTTP Host header lets any client forge the path Starlette presents to authorisation middleware, bypassing access controls on FastAPI services, AI agent frameworks, vLLM inference servers, and LiteLLM proxies that have not yet patched to version 1.0.1.
X41 D-Sec discovered CVE-2026-48710 during an OSTIF-sponsored audit of vLLM and disclosed it through OSTIF, with a patch published May 21, 2026. From an attacker’s position the mechanics are direct: send any request with a malformed HTTP Host header — a single appended /, ?, or # is enough — and the path Starlette presents to authorisation middleware diverges from the path the ASGI server actually routed. Middleware checking whether a request may reach a protected endpoint reads a path the attacker controls; the routing layer is unaffected and sends the request through. Any access control built on request.url rather than the internal scope[“path”] variable is bypassable with one crafted HTTP header. OSTIF Disclosure → NVD →
Starlette draws over 400,000 dependent projects on GitHub alone — a figure that encompasses FastAPI, vLLM inference servers, LiteLLM proxy gateways, MCP servers, and the AI agent harnesses standing up across enterprise deployments. Secwest warned that the CVSS 6.5 score “materially understates the downstream impact,” noting the flaw reaches “most of the model-serving, gateway, proxy, eval, agent, and MCP-server infrastructure that has been stood up in the last two years.” Upgrade to Starlette 1.0.1, which validates Host headers against RFC 9112. CSO Online → BadHost.org →
→ Key Takeaway CVE-2026-48710 gives any attacker with network access to a FastAPI-based service a straightforward path to bypass path-level authorisation controls — one crafted HTTP request, no credentials required. The blast radius covers vLLM inference servers, LiteLLM proxy gateways, MCP servers, and the broader AI agent infrastructure built on Starlette over the last two years. Action: Ask your engineering and AI infrastructure teams to confirm whether any internal or externally exposed services run FastAPI, vLLM, LiteLLM, or other Starlette-based frameworks — and verify that Starlette has been updated to version 1.0.1 or later. |
Quick Hits
| 01 |
TrapDoor Supply Chain Campaign Poisons npm, PyPI, and Crates.io — and Corrupts AI Coding Assistant Config Files to Complete the Exfiltration
Socket identified 34+ malicious packages across 384+ versions published to npm, PyPI, and Crates.io starting May 22, 2026, designed to steal developer credentials, AWS and GitHub tokens, SSH keys, and crypto wallets via postinstall hooks and auto-executing imports. Where TrapDoor diverges from standard supply chain campaigns is a secondary delivery stage: the same threat actor submitted pull requests to prominent open-source AI projects including LangChain, MetaGPT, and OpenHands, inserting modified .cursorrules and CLAUDE.md project configuration files carrying instructions encoded with zero-width Unicode characters. Standard text editors render these characters as blank; AI coding assistants parse the full Unicode stream and act on the hidden directives, running what appears to the developer as a routine security scan while silently collecting and transmitting credentials. Developers in crypto, DeFi, and AI tooling should audit recently installed packages across all three ecosystems and escalate any suspicious dependencies to their security teams. The Hacker News → Socket →
| High — Active Supply Chain Campaign | Dev · Cloud+DevOps |
|
CVE Watch
|
CVE Watch
CVE-2026-27771 (Gitea): Four Years of Silent Exposure — Unauthenticated Container Image Pull Affects 30,000+ Deployments, Patch to 1.26.2
Gitea versions prior to 1.26.2 failed to enforce the private designation on container repositories, allowing any unauthenticated user to pull private container images from exposed instances without credentials. The flaw went undetected for approximately four years and affects over 30,000 deployments in healthcare, aerospace, retail infrastructure, and ISP sectors across more than 30 countries. Forgejo, a widely adopted Gitea fork sharing the same container registry implementation, confirmed in its own testing that it is also affected. Gitea 1.26.2 resolves the issue; the interim workaround is to set [service].REQUIRE_SIGNIN_VIEW=true in the Gitea configuration to enforce authentication for all content access. The Hacker News → Noscope →
| Vendor: Gitea (Forgejo also affected) · CVE: CVE-2026-27771 · CVSS: Not assigned — no score from any primary source as of May 27, 2026 · Attack Vector: Network · Affected: All Gitea prior to 1.26.2; Forgejo (confirmed) · Fix: Gitea 1.26.2 · Status: No confirmed in-wild exploitation as of May 27, 2026; credible imminent risk given public disclosure and trivial unauthenticated access mechanism |
|
Compliance Tip of the Day
|
NIST CSF 2.0 — GV.RM-05 — Govern: Risk Management Strategy
AI Dependency Chains Are Supplier Risk — Establish the GV.RM-05 Communication Lines
NIST CSF 2.0 GV.RM-05 requires that “Lines of communication across the organization are established for cybersecurity risks, including risks from suppliers and other third parties” — the BadHost disclosure shows exactly where this breaks down: a critical vulnerability in Starlette reaches every FastAPI-based AI service in the organisation without the owning team necessarily knowing Starlette is in the dependency chain. When vulnerability communication stops at the application layer, transitive upstream flaws enter the stack without a responsible team to act on the alert. Action: Ask your AI infrastructure and engineering teams whether software composition analysis tools scan transitive dependencies — not just direct imports — and confirm that vulnerability alerts from upstream packages like Starlette route to both the security function and the teams managing AI services. NIST CSF 2.0 reference: csf.tools/gv-rm-05 →
|
On Our Radar
UEFI Secure Boot KEK certificate expiry — June 24, 2026 (27 days): Microsoft’s Corporation KEK CA 2011 expires June 24; the UEFI CA 2011 follows June 27; the Windows Production PCA 2011 expires October 2026. Organisations with dual-boot Linux configurations or air-gapped systems not receiving automatic firmware updates should confirm remediation plans now. Tracking since Issue #039. Microsoft Support →
|
