Three new CVEs landed against Flowise overnight, and for once the archived project's last release is the answer: all three fix at 3.1.4, the version it stopped at. Langflow is the loud one — a 9.9 published Monday with no patched version named — but the version it names shipped in March. And three vLLM CVEs appeared yesterday afternoon for defects this digest covered on September 1.

Worth your morning

Flowise — the archived release is the fix, which is not how this usually goes. Three CVEs were assigned yesterday: CVE-2026-90533 (6.0, an organisation member can read the owner's full user record, password hash included), CVE-2026-90534 (6.1, a node-load endpoint mounted with no route-level permission check that decrypts a credential chosen by raw id), and CVE-2026-90535 (6.3, unauthenticated abort of anyone's in-flight prediction). All three name 3.1.4 as the fix, and 3.1.4 — July 29 — is the last release the project ever made. This digest has carried "Flowise is archived at 3.1.4 with four permanent criticals" since September 6; that line now needs a second half. If you are on 3.1.3 or below, the upgrade is real and available. If you are already on 3.1.4, today changes nothing for you, and the four criticals above it are still never getting a release. Reach is modest either way — about 1,750 npm installs a week.

Langflow — a 9.9 that resolves to a version you almost certainly do not run. GHSA-7w94-79vh-5mr2 is command execution on the host by any authenticated user, non-admin accounts included, through the MCP server configuration surface. It went up Monday afternoon and this digest missed it for three mornings — it is repository-only, no CVE, and nothing in the pip feed carries it. Two things make it hard to act on. The affected range is not < x; it is exactly 1.8.3, a release from March 26 superseded six days later, with 1.12.1 current since September 8. And no patched version is declared — which is not an oversight, because not one of Langflow's eight published advisories declares a fixed version, going back to March. That makes the whole set unresolvable by any scanner that works on version ranges, and it means "is this fixed in 1.12.1" is a question the vendor's own feed cannot answer. The defensible read: run current, and treat the authenticated-user boundary as the thing that matters here, because that is what the finding turns on. Worth re-checking who holds an account on your instance today.

vLLM — three CVEs, zero work. CVE-2026-90553 (7.8), CVE-2026-90555 (6.5) and CVE-2026-90554 (6.2) were published yesterday at 15:31 and all fix at 0.28.0. The first is the LlavaOnevision2 processor loader that ignored trust_remote_code; the second is the sample-rate header that slipped the decode duration limit. This digest tabled both on September 1, when they had no CVE attached. These are identifiers, not defects — the same records, now numbered. Your scanner will surface three new criticals-and-highs against vLLM this morning and every one of them sits below the floor. Separately, a third repository advisory from yesterday's batch (GHSA-j682-9xp5-rrf3, 3.7) published three minutes after the two we tabled and was missed: same fix, same range. The floor stays 0.29.0.

Socket Firewall. CVE-2026-90651 (8.1) affects registry mode below 2.0.0: leave api_ssl_verify and upstream_ssl_verify out of socket.yml and the generated config sets both to false, so outbound requests to the Socket API and to upstream package registries accept any certificate without validating the chain. Anyone able to sit between the firewall and the registry can alter what comes back. It is a supply-chain control that declines to check certificates unless you remember to ask it to. Fixed in 2.0.0; if you cannot take the major today, name both keys explicitly.

Nothing new from Ollama, llama.cpp, LangChain, LlamaIndex, Haystack or the vector databases at repository level. Open WebUI and n8n are unchanged. Microsoft revised the September release on the 12th but shipped no new .NET or Azure advisory — the 8th's Patch Tuesday line stands.