vLLM published three advisories last night against 0.33.0, which had reached PyPI nine hours earlier. Two are unauthenticated 7.5s that let one request take a server down: one on deployments started with --skip-tokenizer-init, the other on any multimodal model that fetches images. If you build container images with kaniko where an Azure identity is reachable, 1.25.20 matters more: before it, a build could send that identity's access token to a registry host the build names.

A package scanner raises almost none of this. vLLM, kaniko, Langroid, Bifrost, LangBot and the AWS server have no record in GitHub's database this morning, and Chainlit's CVE has no package attached. The Go vulnerability database is the exception: it has listed kaniko's upstream Azure helper as unfixed since August 18 (GO-2026-6225).

Worth your morning

vLLM: two ways to take the engine down, fixed before they were announced. 0.33.0 reached PyPI on Monday at 10:13 UTC and the advisories went up between 19:48 and 19:50. The first (GHSA-q9v9, 7.5) applies to servers started with --skip-tokenizer-init, the setup used for pre-tokenized and RL serving: one unauthenticated request can crash the EngineCore and take the shared engine down for every tenant, from 0.28.0. It's an incomplete fix of GHSA-25q3, covered on September 4, which didn't cover the tokenizer-disabled path. The fix merged on October 22, so 0.32.0 doesn't have it and 0.33.0 does. The second (GHSA-5r3c, 7.5, from 0.6.0) applies to multimodal models: vLLM checked the number of images per request and the limits on each one, but not the total bytes a request could make it download and decode, so one request could exhaust the frontend. 0.33.0 adds per-request budgets for downloaded and decoded media. The third (GHSA-qrj2, 5.4) only matters if you serve model repositories you don't control: a crafted speculators config could make vLLM load a different local checkpoint and expose its tokenizer vocabulary through /detokenize. None of the three has a CVE yet.

kaniko: the Azure helper that answered for every registry. kaniko, now maintained by Chainguard since Google archived the original in June 2025, has a 9.3 (GHSA-5q7h, CVE-2026-105769) in the Azure Container Registry credential helper it bundles. kaniko asks that helper for credentials for any registry that has none in your Docker config and isn't a Google or Amazon registry, and the helper didn't check closely enough that the host was really ACR. So a build of a Dockerfile, or build arguments, you don't fully control could send an Azure Resource Manager access token to the wrong host, wherever the build can reach an Azure identity: service-principal environment variables, AKS workload identity, or a managed identity through the instance metadata service. You don't have to use ACR to be affected. The token works against Resource Manager with that identity's roles and can be exchanged for registry credentials, so an identity with AcrPush lets someone push to your registries.

v1.25.20 (October 27) carries a patched copy of the helper that accepts only mcr.microsoft.com and ACR's own domains. The repository publishes no binaries, so rebuild the executor and warmer from 1.25.20, or update the github.com/chainguard-dev/kaniko module. If you can't yet, remove Azure credentials from build pods and block the metadata endpoint there, or set AZURE_ENVIRONMENT=none if you don't use kaniko's built-in ACR login. The advisory says that if you have built untrusted Dockerfiles with an Azure identity available, any token issued to that identity during those builds should be treated as compromised. Google's archived kaniko (last release v1.24.0, May 2025) pins the same helper version and won't be fixed, and the helper's own issue has been open since August 13.

Langroid: seven advisories this digest missed. The Langroid repository published seven advisories between July 25 and October 9, and none reached this digest: the project was last tabled on July 9 and wasn't on the watch list. None has a CVE or a record in GitHub's database. The worst is a 9.8 (GHSA-83w4): CSVGraphAgent ran LLM-generated Cypher against Neo4j without the allow_dangerous_operations check, which allows reading, changing and deleting the graph, and more where APOC procedures are granted. Two 8.1s let untrusted chat content call tools meant to be handle-only, which can read and write files or run SQL (GHSA-2j3c, GHSA-4fpx), and a third 8.1 bypassed SQLChatAgent's SELECT-only allowlist for a write-capable database role (GHSA-3gpx). An 8.8 from October (GHSA-2xfq, from 0.1.48) means a database user who can create tables could get SQL run when SQLChatAgent connects to PostgreSQL. A 6.5 on RepoLoader symlinks and a medium on DOCX decompression complete the set. Every fix shipped the same day as its advisory: 0.65.11, 0.65.14, 0.68.8 and 0.69.2. Upgrade to 0.69.18 (October 30).

Bifrost and LangBot: two more from projects that dropped off the list.

• Bifrost published a 9.8 on September 23 (GHSA-86gf): with management authentication off, anyone who can reach the management API can run commands in the gateway container as the Bifrost user, through its stdio MCP client settings. The record's range stops at 1.5.27 while it names 2.1.0 as the fix, so take transports/v2.1.0 (September 8) or later; v2.4.0 is current. Turn on governance.auth_config.is_enabled either way. It was off by default when this digest covered Bifrost's plugin-URL flaw on September 7.
• LangBot's plugin runtime ran a debug WebSocket on 0.0.0.0:5401 whose key defaulted to empty and wasn't set by the official Docker setup, so anyone who could reach the port could register a plugin that reads every message, private chats included, and sends as any bot (GHSA-m7qm, 8.6, July 31). The advisory names no fixed version. The SDK changed the check on August 4, and at 0.7.20 (this morning) an empty key is refused and the runtime generates a random one when none is configured. Upgrade, and keep 5401 off the network.

Chainlit: the fix release is now the affected one, and there won't be another. VulnCheck's CVE-2026-120492 (5.4 on v3.1, 6.3 on v4) says 2.12.0, the release that fixed September's MCP 9.8 (September 1), still lets requests get past path-scoped entries in features.mcp.user_servers.allowed_urls and reach other paths on an allowed host. 2.12.0 is the newest release, GitHub lists the repository as archived, and its last commit is from August 26. MCP has been off by default since 2.7.0. If you turned it on, treat every allowed_urls entry as allowing its whole host, or turn MCP off, and plan for a framework that still ships fixes.

Also on the AI stack.

• AWS Serverless MCP Server 0.2.1 (October 30) fixes a path traversal in its deployment-status component that let anyone who can influence the agent's input read JSON files outside that directory (GHSA-r6mm, AWS bulletin 2026-164). AWS lists no workaround.
• MCPVault (@bitbonsai/mcpvault, about 32,000 downloads a week) fixed a vault-boundary bypass through unresolved symlinks in 0.17.1 on October 23, the same day as its advisory (GHSA-97wj, medium). Only 0.17.0 was affected; 0.18.3 is current. Another one this digest missed.
• network-ai 5.17.2 (Monday) fixes a low: on a 0.0.0.0 bind, the Streamable HTTP MCP transport reflected a localhost Origin, so a local web page could read its tool list (GHSA-jw52). A September advisory covered the same flaw in the SSE transport.
• Next.js has a security release scheduled for today, November 3, covering seven medium vulnerabilities. Yesterday's 16.4.4 is a backport release and doesn't include them.

Also on the Venicecom stack. The Azure Functions SignalR Service extension (Microsoft.Azure.WebJobs.Extensions.SignalRService 2.3.0, this morning) moves to MessagePack 2.5.307 and Microsoft.Azure.SignalR.Serverless.Protocols 1.11.1 for GHSA-qhrr, covered on October 14, including the MessagePack reader the protocol assembly embeds. A Functions app that only raised its own MessagePack reference still had that embedded copy until this release.

Paperwork your scanner may raise. GitHub's reviewed database took DBHub's GHSA-j656 (CVE-2026-61789) last night, a read-only SQL check bypass fixed in 0.22.6 in June alongside the two covered on September 25; 1.5.1 is current. Bifrost's second September 23 record, GHSA-2qp8 (8.1), is the plugin-URL flaw from September 7 filed again; it now names 2.1.0 instead of 2.0.0.

Quiet elsewhere. GitHub's reviewed feed published two records on Monday, DBHub's and one for an SD-JWT library outside both lists; the same query for October 28–29 returns 117, so the feed is working. MSRC's November document doesn't exist yet (Patch Tuesday is November 10), and the only October revision since yesterday is to an open-source msgpack entry, not .NET or Azure. Angular 21.2.26 and 20.3.35 carry a non-security fix for downgraded components. .NET and PrimeNG released nothing.

Standing items. LMDeploy's PR 4964 is still open and 0.18.0 is still the newest release. fickling has no release after v0.1.12, and DeepInfer's PR 242 is still open. AG-UI's three client fixes (PRs 2575, 2698 and 3241) are still open, so @ag-ui/client 1.0.3 has all three. Prefab UI's own advisory still isn't public, and FastMCP 4.1.6 (this morning) still declares prefab-ui>=0.18.0 in its apps extra. Gradio 6.31.0 still requires pillow<13.0. GitHub's record for oauthlib's GHSA-3jp2 still names 4.0.0, network-ai's still stops at 5.12.2, and node-forge's signature-forgery records still aren't there. mcp-remote 0.16.0 still declares open ^10.1.0. Open WebUI still hasn't published the advisories promised for 0.12.5, and nginx-ui's GHSA-8mrc still isn't public.