NLTK is the morning's item: four highs, all closed in 3.10.0, all sitting as repo advisories since June and only reaching the database your scanner reads yesterday. It's the second day running that the news is a lag rather than a break. Underneath it, the agent execution engine flyto-core picks up six advisories including two criticals, the Dynatrace MCP server gains an authentication check it was shipping without, and dssrf needs patching again — 1.0.4 was yesterday's fix and is today's affected version.

Worth your morning

NLTK — four highs, one fix version, six weeks in transit. All four close in 3.10.0 against everything up to and including 3.9.4. The pattern matters more than any single number: the repo advisories were published in June, a fifth sibling (CVE-2026-54293) reached the global advisory database on June 16, and these four took until July 31. If you scanned NLTK in July you got a clean result on bugs that were already public.

The highest is CVE-2026-12075 (8.6), where the SSRF filter in nltk.pathsec.urlopen — the guard that nltk.download and nltk.data.load sit behind — can be walked past by DNS rebinding, so the check that passed and the fetch that followed don't have to agree on where they were going. The other three are sandbox escapes of the same family: CVE-2026-12072 and CVE-2026-12074 (7.5 each) traverse out of the corpus root through NKJPCorpusReader and FramenetCorpusReader.frame(), both bypassing pathsec with ENFORCE=True set — the advisories are explicit that the sandbox is advertised and silently not applied on these paths. CVE-2026-12061 (7.5) is quadratic backtracking in the ReviewsCorpusReader regex on a corpus you didn't write.

NLTK is rarely something you installed on purpose. It arrives underneath tokenizers, evaluation harnesses and older RAG preprocessing chains, so check what resolved it rather than what you asked for. 3.10.1 shipped today.

flyto-core — two criticals in an agent runtime. The package describes itself as an execution engine for AI agents, MCP-native, and the July 30 batch reads like a tour of what that surface costs. CVE-2026-67426 (9.3) is the one to action: the flyto-verification /run endpoint carried no authentication, returned a client-supplied callback_url without validation, and attached the internal runner secret to the resulting request — so the callback both reaches wherever it was pointed and takes the shared secret with it. CVE-2026-67429 (critical) is an arbitrary file write through the download modules. The four highs alongside them cover redirects crossing into internal space without revalidation, LLM and API keys following an attacker-set base_url, and ${env.VAR} interpolation reading secrets that the module denylist was supposed to keep out of reach. Everything closes at 2.26.7; 2.26.10 is current. If you run this exposed, the runner secret should be rotated rather than assumed intact.

The Dynatrace MCP server gets authentication. Tuesday's low-severity note about a missing approval gate turns out to have been the small one. GHSA-p7w7-4929-vpj5 (7.5) is that the HTTP transport mode had no authentication at all — any caller who could reach the port could invoke tools and read the observability data behind them. Two moderates ride along: GHSA-xrmj-5g4g-8987 (4.2) evaluates Jinja2 from notification workflow templates, and GHSA-pqh8-p93p-2rx7 accepts DQL through parameters not documented as taking it. All three close in 2.0.0, a major-version bump — the fix changes how the server expects to be called, so this is a read-the-notes upgrade rather than a bump-and-forget one. The general lesson keeps recurring: MCP servers written for stdio get an HTTP mode later, and the transport arrives before the authorization does.

Also: dssrf takes CVE-2026-54729 (8.7), where is_url_safe treats localhost as safe for anyone resolving through 1.1.1.1, because one resolution path returns nothing and nothing falls back. Fixed in 1.0.5. This is the third high against the library in three months and the second in two days, which is worth weighing if it's the control between an agent's fetch tool and your metadata endpoint. And CVE-2026-54785 (6.2) in gemini-bridge, an MCP server fronting the Gemini CLI, reads local files outside its intended scope in inline mode. Fixed in 1.3.1.

Quiet on the Venicecom side — no high or critical landed for Angular, .NET, NuGet or Azure in the window, and the moderates that did (Magick.NET's XCF decoder, an nx graph dev-server CORS policy) don't clear the bar for a morning. Three standing items carry over unchanged: the llama.cpp JSON-schema-to-grammar denial-of-service pair (CVE-2026-17500, CVE-2026-17501) is unpatched for a fifth day with PR #25308 open since July 4 and last touched on the 19th; the seventeen .NET July-servicing advisories still aren't in the GitHub feed, so check your runtime version by hand; and primeng still has no repository that can issue a security fix.