The official MCP Python SDK published two client-side advisories yesterday, both fixed in 1.30.0 and 2.2.0 on September 7, and the 7.5 stays open after the upgrade for anyone using the unattended OAuth providers unless they also pass issuer=. Vercel's AI SDK Harness names fixed versions that don't contain the fix, LiteLLM has an 8.1 JWT account takeover with no fix, and Langflow disclosed two 9.9s it closed in June and July. On the Angular side, two SSR advisories reach dependency scanners today, and the fast-uri floor this digest has carried since September 4 was too low.

Worth your morning

MCP Python SDK: the upgrade alone doesn't fix the 7.5 for unattended clients. GHSA-qx49-fqc8-xw99 (7.5) covers MCP clients that connect over HTTP with the SDK's OAuth providers. An MCP server you don't fully trust could point the client at an authorization server of its choosing, and the client would send it credentials meant for a legitimate one. You're affected if your code uses OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider or the deprecated 1.x RFC7523OAuthClientProvider, and it may connect to servers you don't control while holding a pre-provisioned secret, a signing key or a stored client registration. Servers built with the SDK, stdio clients and clients that attach their own tokens are not affected. The advisory scores the unattended providers; for the interactive one, where a person has to start the sign-in, it gives 6.5.

The fix shipped in 1.30.0 and 2.2.0 on September 7, three weeks before the advisory. Two steps come after the upgrade. ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider keep following whatever authorization server the MCP server advertises until you pass issuer=. On 1.30.0, leaving it out raises only a DeprecationWarning, which Python hides by default. RFC7523OAuthClientProvider has no issuer option at all, so move off it. A registration stored without an issuer, which includes everything 1.x stored before 1.30.0, stays unbound, so clear stored OAuth client information once and let the client register again. The second advisory, GHSA-rwrf-2pqf-9j8j (6.5, or 7.5 for unattended agents), is fixed by the same releases with no further step: while validating tool results, the client fetched $ref URLs chosen by the server. It affects every client that calls tools on servers you don't control. Neither advisory has a CVE, and both return 404 in GitHub's database, so pip-audit won't raise them.

AI SDK Harness: the fixed versions exist, the fix doesn't. Vercel published GHSA-4mqq-99j3-3hmv at 17:44 UTC yesterday. When a Harness session resumes from saved state and the resumed session brings in a credential variable that wasn't in the saved placeholder map, code or agent activity inside the sandbox can read that credential in the clear. Changing provider or authentication mode between creating and resuming a session is enough to trigger it. Depending on the adapter, that credential could be a model-provider API key, a source-control token or an OAuth token. The advisory's package list names fixed versions for six packages, from @ai-sdk/harness 1.0.130 to @ai-sdk/harness-claude-code 1.0.134, and all six were published about an hour later. Their changelogs list only dependency bumps, the helper the fix adds to @ai-sdk/harness is in neither 1.0.130 nor 1.0.132, the newest, and the advisory's own text says the fix is proposed in PR 21599, which is still open. A scanner comparing installed versions against that list will report @ai-sdk/harness clean. It has 424,000 downloads a week. Until a release carries the PR, follow the advisory's workaround: create a fresh session and sandbox whenever credential variable names change, and don't reuse saved lifecycle state across that change. If a resumed session may have exposed credentials to untrusted sandbox activity, rotate them and review their use.

LiteLLM: an 8.1 in JWT sign-in, and no fix yet. VulnCheck filed CVE-2026-93355 (8.1, 7.6 on v4) last night, following an OX Security disclosure. With JWT authentication on, a token LiteLLM doesn't recognise is matched to an existing user by its email claim, without checking email_verified. Anyone holding a valid token from the configured identity provider whose email address matches an administrator's inherits that account's role, proxy_admin included. The record says the stored identity binding is also overwritten, so the access survives. VulnCheck lists 1.102.1 and a September 27 commit as affected, and no release names a fix. 1.103.0 shipped the same day, and nothing in its proxy authentication code checks email_verified. Deployments that don't use JWT authentication are outside the flaw. If yours does, make sure the identity provider it trusts can't issue tokens carrying email addresses that nobody verified, for example a single-tenant directory you administer, and check which identities are bound to proxy_admin accounts. The record is unreviewed and has no package mapping, so scanners won't raise it.

Langflow: two 9.9s, both closed in the summer. Langflow published five repository advisories between 16:33 and 17:26 UTC yesterday, and all five are fixed at or below 1.12.0; 1.12.3 is current. In GHSA-w794-rj3p-xv45 (9.9), an MCP stdio server configuration could run an arbitrary command on the host. Per the advisory, that covers any exposed instance on an affected version, whether the attacker has an account or uses the default AUTO_LOGIN, and the reporter found several internet-facing servers still vulnerable. It was fixed in 1.10.3 (July 23), and the 1.11 line carries the same fix, forward-ported before 1.11.0 shipped. In GHSA-8qpj-27x8-pwpq (9.9), the Python REPL component ran unsandboxed code for any authenticated user, fixed in 1.10.1 (June 23). The other three are an SSRF in URL-taking components (6.3 on v4, 1.10.3), cross-user flow access through deprecated build routes (5.4, 1.10.1) and an eval() in tool-mode schema building (2.1 on v4, 1.12.0). Upgrade to 1.12.3, which the project recommends for the full hardening series. Set LANGFLOW_AUTO_LOGIN=false, and leave LANGFLOW_SSRF_PROTECTION_ENABLED at its default. None of the five has a CVE, and all return 404 in GitHub's database. The Langflow floor this digest carries moves from 1.10.1 to 1.12.0.

fast-uri: a correction to the floor. From September 4 to 11, this digest told readers that fast-uri wanted 2.4.5, 3.1.6 or 4.1.3. The project published two more highs on September 2, and one of them, GHSA-58mr-gqgx-xq4g (7.5, host confusion), affects exactly those three versions. The other, GHSA-qw65-cvwx-89v3 (7.5), affects everything below 2.4.6, 3.1.7 and 4.1.4. Both reached GitHub's reviewed feed last night, so npm audit starts raising them today. Two mediums (4.8) from September 15 push the floor to 2.4.7 / 3.1.8 / 4.1.5 and haven't reached the database yet. fast-uri has 156 million downloads a week and few people install it on purpose: ajv 8 depends on ^3.0.1, so a lockfile refresh lands on 3.1.8. Treat it as a lockfile chore for Angular CLI projects, Fastify services and the TypeScript MCP SDK alike.

Angular: two SSR records scanners will raise today, and a correction. GitHub's reviewed feed added two @angular/platform-server advisories last night. GHSA-j3r3-mxqp-r2p4 (8.6 on v4, XSS) was published on the repository on August 27 alongside the four that ran here on September 11, and it has the same fixed versions (22.1.4 / 21.2.22 / 20.3.30). GHSA-f67j-2jqw-jpq7 (8.7 on v4) is a denial of service on malformed input during server rendering, fixed in the September 9 releases. The September 10 digest said those releases shipped no security fix, which was wrong. Both need SSR, and neither is fixed on v19 or earlier. Anyone at the floor from the router advisory, 22.1.8 / 21.2.24 / 20.3.32, already has both fixes. That router advisory, GHSA-ff3f-86qr-9cv3, still returns 404 in GitHub's database.

Two narrower ones. LangGraph GHSA-4hm6-w6qq-w73v (8.6 on v4) lets an authenticated user read, overwrite or delete another user's Store data on langgraph-api servers that use a JavaScript or TypeScript authorization handler. It's fixed in langgraph-api 0.15.0 (September 25). If you can't upgrade, make those handlers reject unauthorized namespaces instead of rewriting them, for every Store action. NLTK GHSA-j456-xh4h-cpf2 (8.6) lets a caller who chooses the Weka classifier's model path read or write outside NLTK's data roots. The fix was merged on the development branch on September 6, but no release has it, and 3.10.3 from August 12 is still the newest. Don't let untrusted input choose that path.

Missed, and fixed since August: Mesop. Google's Python UI framework published GHSA-683v-j9wx-qrw3 (10.0) on August 25, and this digest never mentioned it. Crafted state sent by a client could change class-level values shared by every session, enough to break the server or impersonate the assistant or system role in a chat app. 1.3.5 (August 17) restricts state restore to declared fields. Yesterday's GHSA-3gph-hhjm-6m5c (5.3, control characters in CSP-report terminal output) names no fixed version, but 1.3.7 (September 26) strips them. Run 1.3.7.

Paperwork your scanner may raise. vLLM published three advisories of its own yesterday (6.5, 6.5, 3.1), fixed in 0.28.0, 0.29.0 and 0.30.0, so current releases have all three. Open WebUI added a 19th advisory to Sunday's batch, GHSA-q46m-r89w-j74p (7.6, terminal users managing other users' terminals), which is also fixed in 0.11.4. VulnCheck filed CVE-2026-93348 (8.1, 8.6 on v4) for an August Unsloth fix: loading a model whose config.json carries a crafted value ran code. It's fixed in unsloth-zoo 2026.8.14 and unsloth 2026.8.20 (August 25), and current releases are 2026.9.8 and 2026.9.12. Zscaler's MCP server got CVE-2026-59563 (4.6) for confirmation tokens that could be replayed across resources in 0.7.0 and 0.7.1, fixed in 0.7.2 in March. undici's GHSA-3wwx-pv8p-q78v (5.9, a WebSocket compression denial of service) reached the reviewed feed after a September 4 fix in 6.28.1, 7.29.1 and 8.10.2.

Standing items. vLLM 0.30.0 is still the newest release, and all of its open fix PRs are still unmerged, including the six for the September 22 KV-transfer CVEs. SGLang is still v0.5.20, FalkorDB is still v4.20.7 on the C engine, and Tencent BrowserSkill's issue 273 is still open with no commits to the daemon's WebSocket handler. mcp-remote is still 0.14.3, with no commit since September 21. OpenClaw moved its extended-stable tag overnight from 2026.7.35 to 2026.8.33, whose notes say it covers every repository advisory that affects 2026.8.2, including the Prometheus-metrics and Discord fixes that the main line got in 2026.9.3. If you run extended-stable, that's the upgrade, even though those two records' ranges still read as covering it. LiteLLM has shipped no maintenance release since Friday's three, which lack the semantic-cache fix. Milvus 2.6.25 and 3.0.3, the versions yesterday's import fix names, still don't exist. Obot has released nothing on the 0.24 line since 0.24.2, and MONAI's three older repository records still name no fixed version. ToolHive 0.51.4, Open WebUI 0.11.4, mcp-atlassian 0.23.1, knowns 0.34.1, Chroma 1.5.9, gray-matter 4.0.3, Kotaemon v0.12.0 and mcp-fetch 1.6.3 are unchanged, and Flowise is still archived. ToolHive's GHSA-2gjv-f568-6cxp, mcp-atlassian's GHSA-5j8j-256g-vvp5, Payload's GHSA-v49j-62m6-pgrr, Obot's GHSA-6fwv-3h4c-37j9 and Milvus's GHSA-jh4h-22hq-x74p all still return 404 in GitHub's database.

On the Microsoft side there is nothing to apply. Monday's revision of the September document touched no .NET, ASP.NET Core, Visual Studio or Azure service entry, only Azure Linux package mirrors. .NET 10.0.12, 9.0.20 and 8.0.31 are still the current security releases, and PrimeNG is still 22.1.1. GitHub's reviewed advisory feed came back on Monday afternoon with 17 records, its first since Friday at 21:48 UTC.