n8n is the morning, and a scanner won't find it. Seventeen advisories went up on the project's own repository on Wednesday — ten of them high, two at 8.7 — and three days later none has reached the global npm advisory database or been assigned a CVE. Behind it, GitPython takes its third batch in eight days and needs 3.1.58, and crypto-js picks up a 9.0 critical whose fix has been on npm since February 2020.

Worth your morning

n8n — seventeen advisories your tooling can't see. The batch published on August 5 against three supported lines, with fixes in 1.123.69, 2.33.4 and 2.34.1, all three released the same morning. Ten are high, six moderate, one low, scored on CVSS 4.0 rather than 3.1 — so the numbers aren't directly comparable with the other rows above.

Two share the 8.7 ceiling. GHSA-6h4x-896x-fw5m is code execution in the n8n main process, reached through the node-schema loader in @n8n/workflow-sdk deriving a module path from the caller's node type without validating it; a global:member account is enough. GHSA-r4j2-j3wm-q689 is the Snowflake node passing free-form query input to the SDK without n8n's file-access restrictions, giving a user with working Snowflake credentials read and write access to files on the n8n host.

The rest of the highs group into three shapes. Sandbox escapes that end in code execution — the JavaScript task runner (GHSA-m3hg-p5r9-fg9h, 7.2) and the Git node reading repository-local configuration it shouldn't trust (GHSA-m87g-qr43-ccvc, 7.7). Injection through node parameters that were interpolated rather than parameterised — MongoDB (GHSA-953p-jm2c-8h5j, 7.1) and Supabase (GHSA-f4f3-2g67-4vhm, 7.1). And script execution reaching other users, through the form node's completion page (GHSA-rmr5-775f-jvm2, 8.4) and resource-locator link previews (GHSA-fh4c-9rr2-p7qc, 8.4). One more deserves naming because of where it puts the data: GHSA-9fqj-7wc5-cwhx (7.1) re-threw raw GraphQL node errors, writing decrypted credential headers into persisted execution data — so the leak survives in your database rather than in a log line.

Thirteen of the seventeen reach the 1.x line. Four are 2.x only, including the 8.7 schema-loader item, because they're in the MCP and workflow-SDK code that 1.x doesn't have.

The part worth acting on beyond the upgrade is the visibility gap. These are repo-level advisories with no CVE identifiers, and the global npm advisory database currently holds ten n8n entries, all of them from July 22. The August batch isn't there. npm audit, Dependabot and anything else reading the global feed will tell you your n8n install is clean this morning, and it is not. The July batch was mirrored eventually, so this is lag rather than permanent absence, but the lag is where you are today. Check the version you're running against the three fix lines by hand. If you pull the Docker image, note that the npm latest tag currently points at 2.33.7, which is past the 2.33.4 fix.

The audience overlap is the reason this leads. Self-hosted n8n with MCP nodes and LLM nodes wired into it is the same box, and often the same team, as everything else in this digest's primary scope — and the bar for nearly all seventeen is an authenticated member account, not an admin one.

GitPython — the third batch in eight days. Six more advisories published Thursday, five high and one moderate, all against ≤ 3.1.57 and all fixed in 3.1.58. The 8.8 pair is the priority: GHSA-jm78-9fvv-mhgr, where the git-config option-name validator applied its state machine only to section names and let =, # and whitespace through, allowing forged core.sshCommand and core.hooksPath entries and so code execution; and GHSA-wvpp-8hx9-p66j, where the option guard could be walked past when short options are passed as joined tokens. Behind them, arbitrary file overwrite through unguarded read-tree option forwarding (GHSA-4gmw-gg2m-w46p, 8.1), repository creation outside the working tree via an unvalidated .gitmodules submodule name (GHSA-hmq2-w58f-27jc, 8.2), unguarded forwarding in Repo.init (GHSA-9rj7-rf2p-w77r, 7.5), and arbitrary file read via --pathspec-from-file (GHSA-hh9p-6wh2-4mfc, 6.5).

This is the same defect family the August 4 digest covered — caller-supplied arguments reaching git, and a denylist that keeps missing entries — now at seventeen advisories across four batches. The release history is the useful summary: 3.1.54 on July 22, 3.1.55 on the 23rd, 3.1.56 on the 25th, 3.1.57 on the 26th, 3.1.58 on August 4. Five security releases in two weeks, each one closing the previous one's misses. Pin to a range rather than a version if you can, because there's no reason to think 3.1.58 is the last of these. The exposure is unchanged: GitPython is rarely a direct dependency, and arrives under MLflow, DVC, and the coding agents and evaluation harnesses that clone a repository someone else named.

crypto-js — critical, and the fix is six years old. CVE-2026-71851 (9.0) is that CryptoJS.lib.WordArray.random() in versions before 4.0.0 is not a cryptographically secure generator. A nominal request for 128 or 256 bits produces an effective search space around 2^39 and 2^47, which is enumerable on ordinary hardware. The implementation dates to 3.1.2-4 in June 2014; 4.0.0 replaced it and shipped on February 12, 2020.

Read the scope condition before you escalate. The advisory is explicit that depending on crypto-js < 4.0.0 is not sufficient — an application is affected only if it uses that function to generate security-sensitive values. Keys, tokens, session identifiers, salts, recovery phrases. If your dependency on crypto-js is transitive and something else does your randomness, this is a version bump on a package that shouldn't be six years stale, not an incident. If you did call WordArray.random() for anything that needed to be unguessable, values generated with it need rotating, and upgrading alone doesn't do that.

The rest. pymdown-extensions CVE-2026-67422 (7.5) is exponential backtracking in the caret, tilde, betterem and magiclink inline processors — a stall on crafted input. It's here because Python markdown rendering is how a lot of LLM applications turn model output into HTML, and model output is untrusted input by construction. The fix, 11.0.1, has been on PyPI since July 2; the advisory arrived five weeks later. dompurify GHSA-55q2-fjhq-7xh7 (5.1) sits on the same path from the other end: with IN_PLACE sanitization, hook-based element removal left a detached subtree whose event handlers still executed, so the sanitizer returned while part of what it removed remained live. Only the in-place hook configuration is affected. Fixed in 3.4.13.

hono takes three, fixed together in 4.12.34. The one to check is CVE-2026-71850 (4.8): memo() retained SSR output across requests, so one user's rendered response could be served to another. Low score, wrong failure mode — cross-user disclosure doesn't degrade gracefully. The other two are a language-middleware complexity stall (CVE-2026-71848, 5.3) and the proxy helper not stripping headers named in Connection (CVE-2026-71849, 3.7). Hono is worth tracking here because it's the runtime under a growing number of MCP servers and edge-deployed model APIs; if you're already on 4.13.x you're outside the range.

pypdf closes two resource-exhaustion items in 6.15.0 — large /ToUnicode streams (CVE-2026-71870) and large CID font width ranges (CVE-2026-71852), both 4.8, both memory and runtime rather than execution. Modest on their own, and the second pdf-parser row in two days after Thursday's pdf.js 8.6. Same lesson from the other side: if your ingestion pipeline reads documents you didn't author, the parser is a trust boundary, and the cheapest failure to buy is the one where a single file exhausts the worker.

Standing items. The llama.cpp JSON-schema-to-grammar denial-of-service pair (CVE-2026-17500, CVE-2026-17501) is unpatched for a twelfth day; PR #25308 is still open and hasn't moved since August 3. Keep schema input inside your trust boundary. Open WebUI still wants 0.11.0 with no 0.10.x backport, and Flowise still wants 3.1.4. Quiet on the Venicecom side: no NuGet advisory has published since July 31, nothing new for Angular, .NET or Azure landed in the window, and the next Microsoft servicing release is Tuesday the 11th. primeng remains archived with no repository that can issue a security fix.