DEV Community: HOL (Hashgraph Online)

CVE-2026-77774: Magento still needs APSB26-138 after the StyleSmuggler hotfix

Michael Kantor — Tue, 08 Sep 2026 19:43:24 +0000

Originally published at HOL

If you applied Adobe's StyleSmuggler hotfix yesterday and stopped there, Adobe Commerce and Magento Open Source still carry a separate September patch train. APSB26-138 (Priority 2, published September 8, 2026) closes eight Critical issues, including unauthenticated authorization bypasses and stored XSS that can escalate privileges. Adobe states it is not aware of exploitation for these issues. That is not the same as "the StyleSmuggler hotfix covered it."

The operator trap is explicit in Adobe's release notes: the APSB26-146 hotfix for CVE-2026-75650 is not bundled into the September Isolated patch. Apply the hotfix first, then the September Isolated files (or the matching cloud-patches update). Merchants who only rotated keys and closed GraphQL styles still need APSB26-138.

What broke

Adobe's bulletin lists eight CVEs. The ones that matter first for internet-facing stores:

CVE-2026-77774 - Incorrect Authorization, Critical (CVSS 8.6). No authentication required. Security feature bypass with unauthorized read access. Scope changed.
CVE-2026-76202 - Incorrect Authorization, Critical (CVSS 8.2). No authentication required. Privilege escalation with high confidentiality impact.
CVE-2026-76200 and CVE-2026-76201 - Stored XSS, Critical (CVSS 9.3 each). No authentication required, but user interaction is required. Privilege escalation with changed scope.
CVE-2026-77111 - Incorrect Authorization, Critical (CVSS 8.7). High privileges required. Write-side security feature bypass.
CVE-2026-77110 - Path traversal, Critical (CVSS 7.6). High privileges required. Limited security feature bypass outside intended paths.
CVE-2026-77109 and CVE-2026-77108 - Incorrect Authorization, Critical. Marked B2B in the bulletin. Privilege escalation on Adobe Commerce B2B lines.

Unlike StyleSmuggler, Adobe rates this bulletin Priority 2 and reports no known in-the-wild use. The damage modes are authz bypass and XSS-assisted privilege escalation, not unauthenticated template RCE.

Who is not in scope

Stores that already installed the September 2026 security packages (*-2026-sep) or the matching September Isolated patch files for every installed component, and still have the APSB26-146 StyleSmuggler hotfix applied.
Magento Open Source without Adobe Commerce B2B: CVE-2026-77109 and CVE-2026-77108 are B2B-scoped in APSB26-138.
Adobe Campaign Classic OS command injection is a different product and bulletin (APSB26-142 / CVE-2026-82004), not this Magento train.
High-privilege-only path traversal (CVE-2026-77110) and write bypass (CVE-2026-77111) are not unauthenticated storefront bugs; they still need the same September train.

One concrete check

From the Commerce project root, after the July 2026 Isolated patch that ships Commerce Version Tool:

php vendor/bin/patch-status

Read applied_patches, missing_patches, and per-CVE vulnerability_status. You want PROTECTED for CVE-2026-77774 (and the siblings below), not only for CVE-2026-75650. If CVT is missing, php vendor/bin/patch-status --version fails until the July Isolated file is present.

Cloud merchants who cannot run CVT can confirm a specific Isolated file with Quality Patches Tool, for example grepping the September CE file id for their line after it is applied.

How to fix

Upgrade Adobe Commerce / Magento Open Source to the September 2026 security builds, or apply the September Isolated patch files for your exact release line:

Adobe Commerce: 2.4.9-2026-sep, 2.4.8-2026-sep, 2.4.7-2026-sep, 2.4.6-2026-sep, 2.4.5-2026-sep, 2.4.4-2026-sep
Magento Open Source: 2.4.9-2026-sep, 2.4.8-2026-sep, 2.4.7-2026-sep (Open Source Isolated downloads start at 2.4.7+)
Adobe Commerce B2B: matching *-2026-sep lines in APSB26-138

Operational order from Adobe's FAQ:

Apply APSB26-146 / VULN-39341 StyleSmuggler hotfix if it is not already on the box (actively exploited; not included in the September Isolated zip).
Confirm August 2026 Isolated patches for your line are already applied. September builds on August.
Apply the September Isolated component files in CE → EE → B2B order when those components are installed, or take the cloud-patches path if Magento Cloud Patches already carries the fix.
Re-run php vendor/bin/patch-status and confirm the September CVE set shows PROTECTED.

Adobe is shipping these September fixes as Isolated patch files only (no Composer security packages for this drop). That is intentional for speed, but it means you cannot treat "composer update finished" as proof for APSB26-138.

What this is not

This is not another StyleSmuggler-class unauthenticated RCE advisory, and Adobe is not reporting active exploitation for APSB26-138. It is also not optional if you already hotfixed CVE-2026-75650: the September authz and XSS cluster is a second train.

References

Adobe Security Bulletin APSB26-138
September 2026 Isolated patch release notes (KA-44020)
Adobe Security Bulletin APSB26-146 (StyleSmuggler)
HOL Guard evidence packs: CVE-2026-77774, CVE-2026-76202, CVE-2026-76200

CVE-2026-75021: fastify-cli debug-host bind can expose Inspector RCE

Michael Kantor — Tue, 08 Sep 2026 14:39:27 +0000

Originally published at HOL

You asked the Inspector to stay on loopback. Operator precedence put it on every interface instead. fastify-cli 1.5.0 through 8.0.0 starts Node's Inspector when debug mode is on, but the host selection expression is grouped wrong. Because || binds tighter than ?:, any truthy --debug-host (including 127.0.0.1) collapses into the Docker/Kubernetes branch and binds 0.0.0.0. The Inspector is an unauthenticated code-eval interface. If that port is reachable, a remote party can attach Chrome DevTools Protocol and run OS commands as the Fastify process.

Upgrade to fastify-cli 8.0.1. Debug mode is off by default. This is not a Fastify framework core bug.

What breaks

GitHub advisory GHSA-88v4-3ph7-r88m / CVE-2026-75021 rates this High CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Complexity is high: debug mode must be on, an explicit debug host must be set, and the Inspector port (default 9320) must be reachable.

In affected start.js (shown from 8.0.0) the host argument is:

require('node:inspector').open(
  opts.debugPort,
  opts.debugHost || isDocker() || isKubernetes() ? listenAddressDocker : undefined
)

Because || binds tighter than ?:, that parses as (opts.debugHost || isDocker() || isKubernetes()) ? '0.0.0.0' : undefined (where listenAddressDocker is 0.0.0.0). Any truthy opts.debugHost therefore selects the Docker/Kubernetes branch.

The README documents that Docker/Kubernetes default the Inspector host to 0.0.0.0. Operators pass --debug-host 127.0.0.1 or FASTIFY_DEBUG_HOST=127.0.0.1 to tighten that. Broken builds ignore the intended loopback and still bind every interface.

8.0.1 fixes the grouping with nullish coalescing:

require('node:inspector').open(
  opts.debugPort,
  opts.debugHost ?? (isDocker() || isKubernetes() ? listenAddressDocker : undefined)
)

Affected: >=1.5.0 <8.0.1. Fixed: 8.0.1 (npm updated 2026-09-07). CVE published 2026-09-08. GHSA published 2026-09-07.

Who is not in scope

Processes that never enable CLI debug (-d / --debug / FASTIFY_DEBUG).
Apps that do not use fastify-cli start.
Installations already on fastify-cli 8.0.1 or newer.
The Fastify framework package itself (this is CLI host selection only).

How to check

From the project root:

npm ls fastify-cli
npx fastify version

If debug is enabled, confirm what the Inspector bound:

ss -lntp | grep 9320
# or: lsof -iTCP:9320 -sTCP:LISTEN

If you passed --debug-host 127.0.0.1 (or set FASTIFY_DEBUG_HOST=127.0.0.1) but still see 0.0.0.0:9320, the install is broken.

How to fix

Upgrade the CLI:

npm install fastify-cli@8.0.1

Until you can patch: do not enable --debug on remotely reachable hosts, and firewall the Inspector port.

What this is not

This is not an unauthenticated RCE on a default Fastify production listen. Debug mode must be turned on, and the widened bind only shows up when an explicit debug host is supplied. It is not a vuln in fastify core request handling.

References

BREAKING: CVE-2026-75650 lets unauth callers run code on Adobe Commerce and Magento

Michael Kantor — Mon, 07 Sep 2026 21:01:28 +0000

Originally published at HOL

If you run Adobe Commerce or Magento Open Source with GraphQL reachable, an unauthenticated caller can smuggle PHP into Magento's template engine through styles properties and get that code executed when Magento renders its own "Payment Transaction Failed Reminder" email. Adobe published APSB26-146 today (Priority 1) for CVE-2026-75650, scored CVSS 10.0 (AV:N/AC:L/PR:N/UI:N/S:C), and states the bug is already exploited in the wild. The fix is the VULN-39341 composer hotfix, not a full minor release. Sansec tracked the same chain as StyleSmuggler with confirmed exploitation since September 4, three days before the Adobe bulletin.

This is the operator write-up. The HOL Guard evidence pack for CVE-2026-75650 is the source record.

What breaks

Adobe's CVE text is short: improper neutralization of special elements used in a template engine (CWE-1336) that can yield arbitrary code execution in the context of the current user, without user interaction, with changed scope. The bulletin lists Adobe Commerce 2.4.4-2026-aug through 2.4.9-2026-aug and earlier on those trains, Magento Open Source 2.4.6-2026-aug through 2.4.9-2026-aug and earlier, and Adobe Commerce B2B 1.3.3-2026-aug through 1.5.3-2026-aug and earlier. Authentication required to exploit: No.

Sansec's public StyleSmuggler write-up fills in the mechanism Adobe's advisory does not spell out. Attackers plant malicious PHP into a file Magento itself writes (for example a payment-failure report) by stuffing hostile content into GraphQL styles properties that skip existing sanitization. A second stage deliberately triggers Magento's standard Payment Transaction Failed Reminder email. The poisoned code runs while Magento renders that message server-side, so nobody has to open or receive the email. Sansec reproduced the full unauthenticated chain on clean Magento Open Source 2.4.7, 2.4.8, and 2.4.9, and reported a victim on 2.4.6-p15 with July and August 2026 security patches applied and security:patch-status clean. Patch train currency was not a defense before VULN-39341.

Post-exploitation payloads Sansec published include Rust implants that rename themselves across [kworker/...], fc-cache, and chronyd, plus PHP droppers and web shells under pub/media. A second, unrelated actor was already dropping PHP webshells on September 7. Treat any store that was internet-facing between September 4 and hotfix application as compromise-suspect until scanned.

Who is not in scope

Stores that are not Adobe Commerce / Magento Open Source (or Commerce B2B). WooCommerce, Shopify, BigCommerce, and custom storefronts are outside this CVE.
Magento 1.x / Adobe Commerce 1.x. Affected trains in APSB26-146 are the 2.4.x (and B2B 1.3–1.5) lines listed above.
Merchants who already applied Adobe's VULN-39341 hotfix and completed the encryption-key plus credential rotation checklist in the Experience League article. Hotfix alone closes the hole; rotation is required for full remediation if secrets may have been read.
Headless frontends are not a free pass. Sansec notes Redis/DB session moves and classic vs Hyvä storefront choices do not stop the GraphQL/template path. If GraphQL is reachable on an affected Magento backend, you are in scope until patched.

What this is not

This is not a browser XSS bug and it is not "only" email phishing. It is unauthenticated remote code execution on the Magento/Adobe Commerce application process via template injection, confirmed by Adobe as exploited in the wild. It is also not fixed by upgrading to 2.4.9 alone: Adobe's affected table includes 2.4.9-2026-aug and earlier until the hotfix is applied.

How to fix

Lead with Adobe's Priority 1 path:

Download VULN-39341-composer-patches.zip from repo.magento.com (Adobe Commerce credentials required).
Unzip and apply the composer patch per Adobe's "How to apply a composer patch provided by Adobe" KB. The patch file name in Adobe's example is VULN-39341_Hotfix_COMPOSER.patch.
Adobe tested the hotfix on the 2026-aug builds of Commerce 2.4.4–2.4.9, Magento Open Source 2.4.6–2.4.9, and B2B 1.3.3–1.5.3. Older builds on those branches are still listed as affected; Adobe says the patch is unverified there.
Rotate credentials after the patch. Adobe's Experience League article is explicit: rotating the encryption key alone does not invalidate anything an attacker already read. Rotate admin passwords, REST/SOAP/GraphQL integration tokens, OAuth client secrets, payment gateway API credentials at the provider, database credentials, SSH/deploy keys, and third-party extension API keys at their source.
Scan for compromise before you declare the store clean. Patching does not remove implants dropped between September 4 and hotfix day.

Operator check (Adobe Commerce on Cloud / Quality Patches Tool path Adobe documents):

# After installing the Quality Patches Tool and placing the hotfix:
vendor/bin/magento-patches -n status | grep "39341\|Status"
# Expect VULN-39341 / …/m2-hotfixes/VULN-39341_Hotfix_COMPOSER.patch → Applied

Host IOCs Sansec published for StyleSmuggler implants (run on the Magento host):

If you cannot patch immediately and you do not need GraphQL for a headless or PWA storefront, Sansec's interim guidance was to disable GraphQL until the official fix landed. Prefer the Adobe hotfix now that APSB26-146 exists; do not treat GraphQL disable as a substitute for VULN-39341 plus credential rotation and a malware scan.

CISA KEV (added 2026-09-08)

CISA added CVE-2026-75650 to the Known Exploited Vulnerabilities catalog on 2026-09-08 (catalog version 2026.09.08). Federal and BOD 26-04 covered operators have until 2026-09-11. The KEV row requires forensic triage (Yes). Ransomware use is listed as Unknown. Adobe already called this Priority 1 and exploited in the wild on 2026-09-07; the KEV listing is the federal must-patch clock, not a new technical finding.

References

BREAKING: CVE-2026-75650 is unauthenticated RCE in Adobe Commerce and Magento, already exploited

Michael Kantor — Mon, 07 Sep 2026 21:01:25 +0000

Originally published at HOL

If you run Adobe Commerce or Magento Open Source and you have not applied today's emergency hotfix, an attacker who can reach your storefront can run PHP as your web user with no login. Adobe published APSB26-146 for CVE-2026-75650 on September 7, 2026, scored it 10.0 (AV:N/AC:L/PR:N/UI:N/S:C), Priority 1, and says it is already being exploited in the wild. The fix is a hotfix named VULN-39341, not a full minor release. Stores on the latest 2026-aug builds are still vulnerable until that patch is applied and credentials are rotated.

This is the operator write-up. The HOL Guard evidence pack for CVE-2026-75650 is the source record.

What breaks

Adobe's CNA description is short: improper neutralization of special elements in a template engine (CWE-1336) that yields arbitrary code execution in the current user context, no user interaction required, scope changed. Sansec publicly tracked the in-the-wild chain as StyleSmuggler before the CVE landed. Their write-up matches Adobe's urgency: attackers poison Magento's template path through styles properties that slip past existing safeguards, then get Magento itself to execute the payload while rendering the standard "Payment Transaction Failed Reminder" email. Nobody has to open the mail. The render path is enough, and the chain still works when delivery fails.

Sansec reproduced the unauthenticated chain on clean Magento Open Source 2.4.7, 2.4.8, and 2.4.9. Their first confirmed victim was on 2.4.6-p15 with the July and August 2026 Commerce security updates already applied and security:patch-status clean. Being current on APSB26-92 / APSB26-73 is not a substitute for VULN-39341. Adobe's bulletin lists Adobe Commerce through 2.4.9-2026-aug, Magento Open Source through the same train, and Adobe Commerce B2B through 1.5.3-2026-aug as affected.

After code execution, Sansec has been documenting implant turnover in the same campaign window: background processes disguised as [kworker/u:8:0], then fc-cache, then chronyd, plus a second actor dropping a PHP web shell under pub/media. Treat "we patched" as incomplete until you have also hunted those hosts.

Who is not in scope

Stores that have already applied Adobe's VULN-39341 hotfix and completed the credential rotation Adobe documents. Confirm with the Quality Patches Tool status below rather than assuming a deploy succeeded.
Adobe Experience Manager, ColdFusion, and other Adobe products outside Commerce / Magento Open Source / Commerce B2B. APSB26-146 is a Commerce bulletin.
Frontends that only talk to Magento over a tightly locked integration and never expose a Magento/Adobe Commerce storefront, GraphQL, or payment callback surface to untrusted networks. You still want the hotfix on the Commerce host; you are not in the internet-exposed emergency class Sansec describes.
Non-Magento carts (Shopify, WooCommerce, custom storefronts with no Magento PHP runtime). The CWE-1336 sink is in Adobe Commerce / Magento's template engine.

What this is not

This is not an admin-only bug, not a "click a crafted link" XSS story, and not fixed by upgrading to the newest 2.4.9-2026-aug tag alone. Adobe's own table says authentication required to exploit is No, and the CVSS vector is PR:N. It is unauthenticated remote code execution via the template engine, with confirmed in-the-wild use before the hotfix existed.

How to fix

Apply Adobe's hotfix, then rotate secrets. Do not stop at the composer patch.

Download VULN-39341-composer-patches.zip from Adobe (linked from the APSB26-146 Experience League article) and apply it with Adobe's composer-patch workflow for your version line.
Adobe tested the hotfix on the 2026-aug builds of Commerce 2.4.4–2.4.9, Magento Open Source 2.4.6–2.4.9, and Commerce B2B 1.3.3–1.5.3. Older builds in those branches are still listed as affected; the patch may work there but Adobe has not officially verified it.
Put the store in maintenance mode, disable cron, rotate the Magento encryption key, then rotate every credential that key protected at the source: Admin passwords, REST/SOAP/GraphQL integration tokens, OAuth client secrets, payment-gateway API keys, database credentials, SSH/deploy keys, and third-party extension API keys. Adobe is explicit that rotating the encryption key alone does not invalidate anything an attacker already read.
Flush cache, re-enable cron, leave maintenance mode. Then scan for compromise before you declare victory.

Operator check that the hotfix is actually live (Cloud example from Adobe; on-prem use the same Quality Patches Tool against your local hotfix file):

# After installing Quality Patches Tool and applying VULN-39341:
vendor/bin/magento-patches -n status | grep "39341\|Status"
# Expect an Applied row for .../m2-hotfixes/VULN-39341_Hotfix_COMPOSER.patch

Sanity on the running tree:

Compromise hunt Sansec recommends after the three-day pre-patch window (treat hits as incident response, not as "noise"):

ps -eo pid,comm,args | grep -iE 'kworker/u:8:0|fc-cache|chronyd'
ls -la ~/.cache/fontconfig/fc-cache /tmp/.fc-* /tmp/.chrony-* /tmp/.kw_* 2>/dev/null
crontab -l; grep -R "fc-cache\|chronyd\|gvfsd" /var/spool/cron 2>/dev/null
find pub/media -name '*.php' 2>/dev/null
grep -ril 'x_trace_' var/report/ 2>/dev/null

Sansec Shield customers still need the Adobe hotfix. WAF rules reduce exposure; they do not replace VULN-39341 or credential rotation on a store that may already have been hit between September 4 and the September 7 bulletin.

CISA KEV (added 2026-09-08)

References

HOL Guard 3.0: Rust authority, extension-first controls, honest harness contracts

Michael Kantor — Mon, 07 Sep 2026 13:24:37 +0000

Originally published at HOL

Your agent proposes aws s3 rb s3://prod-artifacts --force in the same session where it was helpful five minutes ago. You are mid-review. YOLO is on somewhere. The bucket name looks right enough that a tired operator might hit allow. That is the failure mode Guard 3.0 is built around: not abstract model risk, but a concrete shell string that empties production before anyone finishes reading the diff.

Stable v3.0.0 cut on August 27, 2026. Current tip to pin is 3.0.113 (Production/Stable). PyPI yanked 3.0.0, so do not put that cut tag in a lockfile, Dockerfile, or CI pin. Use a living 3.0.x tip.

What broke in the 2.x mental model

Pre-3.0 Guard already intercepted harnesses, paused on new artifacts, routed approvals, and wrote receipts. Cloud stayed optional. Teams still bounced between three half-answers when something destructive showed up: which editor owned the detector, which surface owned the allow memory, and which harness hook folklore was currently true.

We kept Local Extensions and Cloud policy language looking like parallel systems. Capability identity drifted from governance objects. Operators could not tell whether a deny came from a floor, a remembered approval, or a workspace rule. That ambiguity is what we killed.

Extensions define what HOL Guard can protect. Guard Cloud Control Sets define how that protection is governed across people, devices, agents, environments, and time.

That is the ADR 0011 product sentence, quoted once. Local owns capability identity and detector facts. Cloud owns Control Sets, Deployments, acknowledgement, drift, pause, rollback, and audit. ADR also rejected paywalling Local Extensions and rejected giving every Cloud rule absolute precedence in the 3.0 release. Contextual policy precedence stays unless a separately negotiated contract says otherwise.

Rust owns the authority path

Every supported harness routes PreToolUse security semantics through a bundled, version-matched Rust runtime. Supported PostToolUse output review does too. There is no Python semantic fallback on that path in 3.x. That is the hard boundary, not a performance footnote.

The flow is boring on purpose:

harness tool call
  -> Guard hook (PreToolUse)
  -> version-matched Rust runtime
  -> CanonicalCommand parse-once
  -> Extension permission detectors (evidence only)
  -> local floors + device settings + remembered rules
  -> optional Cloud Control Set (managed-restrictive)
  -> allow | ask | deny (fail closed on authority faults)

Shell text becomes a CanonicalCommand once: segments, wrappers, pipelines, redirects, security identity. Detectors emit evidence. They do not grant authority. A safe preview segment such as git clean -ndx does not wash away a later destructive segment on the same line. Help and describe forms suppress only their owning rule and segment. Cloud matrices match executable and subcommand structure rather than English words like delete. Reordered global flags do not change recognition, which matters when an agent rewrites aws s3 rb --force s3://... into a flag order you have not memorized.

Identity, protocol, rule-digest, policy-snapshot, overload, timeout, transport, and response failures fail closed on the authority path. Soft-allow on those faults is not a degraded mode we keep. The v3.0.0 notes put the resident Rust runtime at roughly 29,000 lines shipped in-wheel. Version-matched wheels live inside the Guard package so the native binary and the Python package cannot silently drift.

Python still handles authenticated transport, harness-specific rendering, approval coordination, the dashboard control plane, and bounded non-authoritative evidence. The ownership gate exists specifically to stop someone from reintroducing Python command evaluation as PreToolUse authority when Rust is inconvenient.

Extension-first controls and the cloud matrices

An Extension is a stable Local capability boundary for a tool or domain. A Permission is an independently configurable capability inside that Extension. Detector rules recognize evidence for a Permission. Local settings and remembered rules may tighten protection. They cannot lower required floors or weaken managed restrictions.

Authority modes are personal-shared, workspace-shared, and managed-restrictive. The product-decision contract sets local_registry_authoritative and cloud_must_not_redefine_detector_matchers. Cloud targets Extension and permission identities published by the local registry. It does not become a second matcher editor.

In release 3.0, managed-restrictive actions are only disable-extension, disable-permission, and global-lockdown. Exceptions are time-bounded and cannot weaken those blocks. Composition is monotonic for non-weakenable authority. That is narrower than a full Cloud policy language, and that narrowness is intentional.

Built-in cloud destructive-operation matrices at the v3.0.0 cut: 200 AWS, 100 gcloud, and 100 Azure matrix-reviewed operations. The AWS matrix ships as two non-overlapping 100-operation batches. Directory UIs may show 1 rule on a command.cloud.* Extension. That column is not the operation count. The Extension wraps a matrix. Confirm on your tip with hol-guard command extensions.

Required core Extensions cover filesystem, git, system, windows, and guard-self-protection. They are built-in capability boundaries over the same parser used by harness hooks, not downloadable regex bundles.

External community contribs (blitcp, Noodle, Probe, repo2nb, Skill Sunset) stay off until a local-admin enable. Cloud cannot flip External on by itself.

Delegated package-manager protection points at the package-firewall contract rather than duplicated command-policy rules.

Install intent, package metadata, and the final pre-execution Guard result ride the shared runtime envelope before an approval is queued. Saved artifact-level package blocks stay sticky until a new allow rule or exception exists.

hol-guard command test 'aws s3 rb s3://prod-bucket --force'
hol-guard command explain 'gcloud sql instances delete my-db --quiet'
hol-guard command extensions

command test and command explain are side-effect-free. They do not execute the command, create an approval, or write a receipt. Use them after every upgrade before you trust muscle memory on az group delete or php artisan migrate:fresh.

Protection Center, Test Lab, Core vs Desktop

Protection Center is the operator control plane for command protection modules. Open it from Modules in the local dashboard. Compatibility routes for /extensions remain. Posture choices are Protected, Extra careful, or Watch. Default is Protected.

Protected stops theft, wipes, and Guard bypass, then remembers ordinary first-seen decisions. Extra careful also asks on first new site or tool install. Watch records without stopping. Use Watch only while debugging false positives. If Watch becomes your standing posture, you are collecting receipts while the blast radius stays live.

hol-guard settings set protection protected
hol-guard command controls status
hol-guard command controls list
hol-guard command controls show command.git
hol-guard command controls patterns --tool command.git
hol-guard command controls preview command.git --target-kind extension --state disabled

Those inspect or preview local state. They do not contact Cloud. Writes still go through preview, proof, approval, and apply. A device setting can preserve or tighten protection. It cannot lower an immutable floor, override Emergency Lockdown, or weaken a workspace managed restriction.

Test Lab rehearses a bounded command against current local protection without executing it. No subprocess. No activity row. No approval. No Cloud upload. No raw command in the response payload. Same contract as command explain: explanatory, not a sandbox.

We moved the menu-bar tray to hashgraph-online/hol-guard-desktop. Guard Core stays headless and owns enforcement: policy, approvals, receipts, daemon, browser dashboard, updates, repair, diagnostics. Desktop is optional. If the tray vanished after upgrade, you lost a UI process, not the authority path. Desktop is not required for blocking.

Protection Center is presentation over the same extension-control catalog, effective state, preview, proof, apply, and runtime evaluation contracts used by the CLI. It must not invent separate enforcement semantics. Simple mode is the default; Advanced and Developer modes reveal implementation detail. Organization-managed settings stay read-only on the device. Settings history comes from the authenticated local authority transition chain: picking an earlier version prepares only the historical device layer as a draft against the current revision, with the organization layer still in force, and still requires the normal proof-bound approval flow.

Local decision integrity and evidence privacy

Saved local decisions are verified against Guard-maintained integrity key material before they become authoritative again. Coming from older local memory, migrate deliberately:

hol-guard policies integrity-status
hol-guard policies migrate-local-integrity --preserve-all-local
hol-guard policies verify

Tampered or recovery-required authority state goes through the approval-bound Settings integrity repair flow in Protection Center. Do not hand-edit the authority database. Unsigned, unknown-key, or tampered local decision rows should fail closed until an operator repairs them.

Command activity is a local security-evidence domain. It records bounded facts about Guard decisions and proof metadata, not command content. Opaque activity references, harness, phase, status, proof level, bounded reason classes, extension and rule identities: yes. Raw commands, arguments, paths, workspace names, package names, environment values, credentials, matcher free-text with user input: no. Positive field allowlists enforce that. Redaction alone is not the contract.

Correlation handles use a local HMAC-SHA-256 over length-framed harness identifiers with an installation-local random key. Session-only correlation never proves execution. Default egress is local-only. Optional Cloud egress, when opted in, accepts only rare-cell-suppressed daily aggregate counts, not activity rows or receipt payloads. Catalog and control status stay bounded security metadata for the same reason: support evidence must not become a side channel for shell text.

Harness contracts, stated honestly

Support is not identical across harnesses. Treat the matrix as contracts, not slogans. Guard's own authority path fails closed on the faults listed above. Harness adapters still differ when Guard itself is unreachable or a hook crashes.

Codex: Guard-owned PreToolUse and PermissionRequest hooks are authoritative, including deny in YOLO mode. Wrapper launch refuses when native hooks are missing or disabled. Thread resume works when a live binding exists.
Grok: waits on the original PreToolUse after queuing approval, then returns allow so Grok resumes the same tool call. Fails open if a hook crashes or times out.
Kimi: fails open on crash or timeout so Kimi Code keeps working when Guard is unreachable.
ZCode: fails open on crash or timeout.
Cline: evaluates PreToolUse synchronously and fails closed when Guard is unavailable or payloads are contradictory.

Harness     | Guard crash / unavail          | Resume note
Codex       | refuses missing native hooks   | thread resume when bound
Grok        | fail-open on crash/timeout     | same-call resume
Kimi        | fail-open on crash/timeout     | keeps working
ZCode       | fail-open on crash/timeout     | keeps working
Cline       | fail-closed on unavail/bad payload | sync PreToolUse

Codex refusing a launch without native hooks is a feature. Grok, Kimi, and ZCode failing open means Guard unreachable is not the same as Guard deny. Cline failing closed means an unavailable Guard stops action-bearing tools. Read harness-support.md for the harness you actually run, then prove it with status and command explain on that machine.

No VS Code Copilot extension-host claim. A VS Code inline permission sheet alone is not Guard proof. No Goose adapter in this repository. No Cisco AIBOM runtime policy in this pass.

Local floor stays up when Cloud pauses

Local Guard without sign-in still intercepts, blocks on supported actions, writes receipts, and resolves approvals. Cloud outage, trial end, past due, or never connected must not be translated into protection expired. That mistranslation is a product bug.

Sync paused is not unprotected. Codes like feature_not_in_plan, device_limit_reached, and cloud_sync_paused_plan_limit describe Cloud state only. Solo's two-device limit is a Cloud-sync limit. A third machine still installs and protects locally.

Team Cloud is where managed-restrictive Control Sets become interesting: shared workspaces, simulation, staged rollout, acknowledgement, drift, rollback, RBAC, and evidence exports. Deployment is a signed Control Set version delivered to an eligible runtime cohort. Stages fail closed independently. Compatibility evaluation and atomic application have to land before managed restrictions are enabled on a cohort; unsupported clients must not receive a fallback that silently drops Extension enforcement semantics.

Cloud adds sync, history, Control Sets, simulation, staged rollout, acknowledgement, drift, rollback, and shared review. A paused sync stage does not mean Local Guard stopped protecting the shell. A catalog mismatch excludes a device from that Cloud rollout; local enforcement continues. Invalid signed bundles follow the incident runbook; do not describe local protection as disabled merely because Cloud sync failed.

Day one on a laptop still looks familiar: install Guard Core, run init or install for the harness you use, confirm status, then rehearse a destructive class with command explain before you trust muscle memory. Decision-integrity tooling and receipts continue offline.

Upgrade once, prove four green bars

Prefer the current tip. Do not pin yanked 3.0.0. Repair the harnesses you use. Prove recognition with command explain. Migrate local decision integrity if you are coming from older local memory.

uv tool install --force "hol-guard[cisco]==3.0.113"
hol-guard --version
hol-guard init
hol-guard install codex
hol-guard apps repair grok
hol-guard status
hol-guard command explain 'aws s3 rb s3://prod-bucket --force'
hol-guard command test 'az vm delete -g rg -n vm1 --yes'
hol-guard command controls status
hol-guard policies integrity-status
hol-guard policies migrate-local-integrity --preserve-all-local

Package reports a 3.0.x version at or above 3.0.113.
status shows the harness protected with hooks present.
command explain names a built-in Extension and permission evidence for a destructive class you care about.
policies integrity-status is clean or successfully migrated.

Then open Protection Center once and set posture deliberately. Do not inherit 2.x muscle memory for Watch. After that, the product model is simple enough to hold in one head: Extensions name what can be protected, Rust decides before the shell starts, Control Sets govern those identities across people and devices, and Cloud sync state never gets to redefine whether the local floor is still standing.

If marketing surfaces or an old README still talk early 3.x language, ignore them for pins. Treat the installed package version, the v3.0.0 release notes, ADR 0011, and product-decision.json as the operator sources of truth. After the four green bars, skip changelog side quests until you have actually watched one destructive class land as Extension permission evidence on your harness.

References

BREAKING: CVE-2026-76578 lets an unauthenticated LDAP client become a FreeIPA admin

Michael Kantor — Mon, 07 Sep 2026 12:58:23 +0000

Originally published at HOL

If your FreeIPA or Red Hat IdM LDAP ports are reachable without a login, an unauthenticated client can forge a Kerberos principal into the administrators group and run the directory as an admin. Red Hat scored CVE-2026-76578 at 9.8 (AV:N/AC:L/PR:N/UI:N) and says it reproduced the chain on a default, unmodified FreeIPA install. No fixed RPM is listed yet. Upstream FreeIPA master landed the ACI hardening today with Fixes: CVE-2026-76578 in the commit messages. Until your vendor package ships, treat open 389/636 from untrusted networks as an emergency.

This is the operator write-up. The HOL Guard evidence pack for CVE-2026-76578 is the source record.

What breaks

FreeIPA ships a self-service ACI named Users can create self-managed tokens under cn=otp. It allowed add when ipatokenOwner and managedBy matched SELFDN, but it did not constrain which object classes or attributes the new entry could carry. Combined with how 389 Directory Server evaluates anonymous binds against self-referential allow rules, a credential-less LDAP client could create a token-shaped entry that also smuggled a Kerberos principal, key material, password, and SID, then land that principal in the administrators group.

Red Hat's public statement is blunt: a prior uniqueness fix (CVE-2026-13097) blocked the literal admin name-collision trick, but it did not close the unauthenticated write path. The attacker no longer needs to impersonate the literal admin account. They pick their own name, join administrators, and get genuine admin LDAP rights (user add/delete demonstrated in Red Hat's own tests). On SID-enabled deployments that access also reaches other IdM services.

Upstream commit 316a3e45d2 (Alexander Bokovoy) is the surgical OTP fix: the ADD ACI now carries a targattrfilters clause that only permits OTP object classes (top, ipaToken, ipatokenTOTP, ipatokenHOTP) and forbids an injected aci. Attributes that need Kerberos or password object classes fail that filter. The commit notes that 389-ds does not consult targetattr on ADD, so targattrfilters is the lever that actually works. Legitimate ipa otptoken-add is unaffected.

That OTP constraint alone is not the whole story. Companion upgrades add an absolute deny for anonymous modifications on the IPA suffix and on o=ipaca when a CA exists (21-deny-anonymous-modify.update), harden self-service bind rules, and deny anonymous SID reads. The absolute deny uses userdn != "ldap:///all" because there is no ACI keyword that means "no credentials were sent"; empty-DN anonymous binds are the ones that fail ldap:///all. The patch text also warns that authmethod="none" means "do not check auth method" and would deny everyone if used as a deny clause, and that nsslapd-allow-unauthenticated-binds should stay off.

Who is not in scope

Hosts that are only FreeIPA/IdM clients (SSSD against someone else's IPA). This is a server-side LDAP ACI issue on the IPA masters/replicas.
IPA servers where ports 389/636 are not reachable from any untrusted network and anonymous binds are already rejected. You still want the package when it lands, but you are not in the emergency exposure class Red Hat describes.
Deployments that only applied the earlier CVE-2026-13097 uniqueness / canonical-name collision fix. Red Hat says that patch does not remediate this CVE.
CVE-2026-79678 (same-day FreeIPA Important): authenticated idp-add reaches a constrained eval() before the authz check for environment disclosure and memory DoS. Different bug, different preconditions. Not unauthenticated admin takeover.

What this is not

This is not a remote code execution bug in the IPA host OS, and it is not a Kerberos wire-protocol flaw. It is unauthenticated directory privilege escalation to FreeIPA administrators via LDAP ACIs. Red Hat reproduced admin LDAP read and admin-only write/delete; that is full IdM admin, not a sandbox escape story.

How to fix

There is no fixed ipa-server / IdM errata in the Red Hat CVE page yet (products still show affected / under investigation). Until the vendor package arrives:

Restrict LDAP to trusted hosts only: firewall TCP 389 and 636 so the internet and untrusted VLANs cannot reach IPA masters/replicas.
Disable anonymous LDAP binds if your clients do not require them. Red Hat says that blocks this specific path; confirm NIS/compat and any legacy anonymous readers before flipping it in production.
Confirm nsslapd-allow-unauthenticated-binds is off on the 389-ds instances backing IPA.
Watch for the FreeIPA / RHEL IdM update that ships install/updates/40-otp.update with the constrained self-managed-token ACI and 21-deny-anonymous-modify.update. Upstream master already has those files; package that train when your distro publishes it, then re-run ipa-server-upgrade / the normal IdM update path so the ACI update scripts apply.

Operator check you can run today from a host that should not be able to speak LDAP anonymously to the IPA server:

ldapsearch -x -H ldap://ipa.example.com -b "" -s base namingContexts
# Expect bind failure or referral policy you already chose.
# If this returns namingContexts from an untrusted network, treat LDAP as exposed.
rpm -q ipa-server 389-ds-base || true
# After the fix package: confirm the live ACI text includes
# targattrfilters on "Users can create self-managed tokens"
# and "Deny all modifications for anonymous binds".

Same-day sibling worth patching in the same window: CVE-2026-79678 (Important, CVSS 8.1). Any authenticated IPA principal can hit ipa idp-add before authorization and read process environment variables or DoS via memory exhaustion. On container images that left Directory Manager / admin passwords in the environment after first boot, that disclosure is worse. Red Hat says the eval() path cannot call functions (parentheses forbidden). Fix is still "upgrade when the package exists"; there is no config kill-switch.

References

Red Hat CVE-2026-76578
Bugzilla 2519522
freeipa otp: constrain self-managed-token ADD
freeipa aci: deny anonymous modifications
Red Hat CVE-2026-79678 (sibling)
Red Hat CVE-2026-13097 (prior collision fix; not sufficient alone)

BREAKING: CVE-2026-86259 lets unauth OpenMAIC callers pull cloud credentials via SSRF

Michael Kantor — Sun, 06 Sep 2026 13:45:25 +0000

Originally published at HOL

OpenMAIC before 1.0.1 will fetch any URL you put in x-base-url when the SSRF guard is skipped, and the default install has no access code. On a cloud host that means an unauthenticated caller can pull Instance Metadata Service credentials through generation endpoints such as POST /api/generate/image. Same-day GHSA-9m7h-vh2h-rc3w and release v1.0.1 ship today. CVE-2026-86259 is the lead. Three sibling advisories land in the same upgrade.

This is the operator write-up. The HOL Guard evidence pack for CVE-2026-86259 is the source record.

What breaks

Two defaults stack:

Fail-open auth. middleware.ts does if (!accessCode) return NextResponse.next(). The shipped .env.example leaves ACCESS_CODE commented optional, so every API route is reachable with no cookie.
Environment-gated SSRF. In 1.0.0, routes such as app/api/generate/image/route.ts only called validateUrlForSSRF(clientBaseUrl) when NODE_ENV === 'production'. Development, staging, preview, and unset environments skipped the guard and fetched the client URL.

Chain: unset ACCESS_CODE + non-production NODE_ENV + x-base-url pointing at the cloud metadata service on an image, video, PDF, or extract route. The server returns IAM material in the response. The same pattern also reaches loopback services when those ports are open on the host.

v1.0.1 removes the NODE_ENV gate so validateUrlForSSRF runs unconditionally, and adds a repository test that fails if a gated call site comes back. CHANGELOG 1.0.1 also lists three other fixes in the same tag: classroom path write (GHSA-p2wh-m28m-c5xw), stored slide HTML (GHSA-7rhf-2798-mvcj), and redirect credential drop (GHSA-725p-44hx-v52c).

The incomplete part of 1.0.1

Read the patch, not only the advisory remediation list. GHSA-9m7h suggested fail-closed middleware when ACCESS_CODE is missing. The shipped 1.0.1 tree does not do that. middleware.ts is byte-identical between v1.0.0 and v1.0.1; the fail-open if (!accessCode) return NextResponse.next() remains. README and .env.example still document ACCESS_CODE as optional.

So: upgrading closes the SSRF gate everywhere, including non-production. It does not by itself stop unauthenticated callers from hitting your API surface. Set ACCESS_CODE in .env.local (or your deploy secrets) on every reachable instance.

Breaking change after upgrade: client-supplied loopback or private provider base URLs (local Ollama or Lemonade entered in Settings) are now rejected in every environment unless you set ALLOW_LOCAL_NETWORKS=true. Production already behaved that way; development did not.

Who is not in scope

Deployments that already run with NODE_ENV=production (SSRF validation was already on) and a non-empty ACCESS_CODE.
Managed or server-configured providers that ignore client x-base-url (OpenMAIC managed-provider path drops the client base URL).
Hosted open.maic.chat instances that enforce access codes.
Anyone not running OpenMAIC.

Operator check

grep -n '^ACCESS_CODE=' .env.local .env 2>/dev/null
node -p "require('./package.json').version"

Expect ACCESS_CODE set to a real secret and version 1.0.1 or newer. Empty grep output means the middleware still fail-opens even after you upgrade.

How to fix

git fetch --tags && git checkout v1.0.1
pnpm install && pnpm build && pnpm start

Then set a strong ACCESS_CODE=... in .env.local (or your secret store) and restart. If you point Settings at a local LLM endpoint, add ALLOW_LOCAL_NETWORKS=true. Node must be 22.19.0 or newer after this release.

Rotate any cloud credentials that lived on hosts that exposed OpenMAIC without an access code before you patched. Treat temporary IMDS tokens as compromised for the full window the instance was reachable.

What this is not

Not a Next.js framework CVE. Not remote code execution by itself. Not wormable without a reachable OpenMAIC. Not fixed by only bumping the Next.js, undici, or lodash deps that also landed in 1.0.1.

References

GHSA-9m7h-vh2h-rc3w (lead SSRF / unauth chain)
OpenMAIC v1.0.1 release
CHANGELOG 1.0.1
Patch observation: app/api/generate/image/route.ts drops the NODE_ENV === 'production' gate; middleware.ts unchanged vs 1.0.0
Siblings in the same release: GHSA-p2wh-m28m-c5xw, GHSA-7rhf-2798-mvcj, GHSA-725p-44hx-v52c

BREAKING: CVE-2026-67276 and MikroTrick can take over MikroTik RouterOS with SSH exposed

Michael Kantor — Sat, 05 Sep 2026 20:16:28 +0000

Originally published at HOL

CERT Polska confirmed active attacks against MikroTik RouterOS that chain SSH flaws into full device takeover when SSH is reachable from the internet. They call that chain MikroTrick. CVE IDs landed today (2026-09-05). MikroTik already pushed silent fixes on 2026-09-03 in 7.24.2, 7.23.4, and 6.49.21. If you run RouterOS with management services on a public address, patch and hunt for compromise markers now. This post covers the six CERT-coordinated CVEs in one upgrade.

This is the operator write-up. The HOL Guard evidence packs for each CVE ID are the source records.

What breaks

MikroTik's Sep 3 bulletin said only that a security update was important and that most configurations were not at risk. The binaries disclosed more than the prose. CERT Polska's Sep 5 write-up, plus independent binary diffs of 7.23.3 vs 7.23.4, map six issues:

CVE-2026-67276 (CVSS 9.2 per CERT) - SSH public-key auth compared RSA key type and modulus but not the exponent. An attacker who knows an authorized RSA modulus can supply a crafted key (commonly e=1 / low-exponent forgery paths) and open an SSH channel as that user without the private key.
CVE-2026-86060 (CVSS 9.2 per CERT) - usernames that begin with a prohibited character (field IoC: literal -2) reach a legacy login helper that treats -N as "read trusted name/policy fields from file descriptor N." That can replace the RouterOS policy mask and escalate to full admin. CERT pairs this with 67276 as MikroTrick.
CVE-2026-67279 - SSH rekey before authentication lets an unauthenticated client open a session and write or overwrite files in the managed file namespace (including support/config material).
CVE-2026-67281 - WebFig /jsproxy unauthenticated file read via a stale principal pointer and path escape; can disclose config stores that hold credentials.
CVE-2026-67277 (CVSS 8.8 per CERT) - bandwidth-test (btest) accepts a "related" connection before the primary session finishes auth, leaking kernel buffer data or crashing/restarting the device.
CVE-2026-67278 - malformed RSA/PKCS#1 v1.5 signatures accepted in X.509 validation; with an e=3 trust-store root this enables TLS server impersonation on outbound RouterOS TLS.

Fixed trains (vendor + CERT): 7.24.2 (stable), 7.23.4 (long-term), 6.49.21 (v6 long-term), and 7.25beta3+. Affected range per CERT: from 7.24 below 7.24.2, from 7.0.0 below 7.23.4, from 6.0.0 below 6.49.21.

CERT reports observing internet-facing SSH devices taken over with this combination in recent days, and that the released patches stop the observed attacks. MikroTik's patched builds also set a Flagged device-mode marker when known compromise fingerprints are present.

Who is not in scope

Devices already on 7.24.2, 7.23.4, 6.49.21, or any later build that contains these fixes (still run the Flagged / IoC checks below if SSH was ever public).
Boxes where SSH, WWW/WWW-SSL (WebFig), and the bandwidth-test server are not reachable from untrusted networks, and that do not initiate untrusted outbound TLS/SSH client sessions from the router. MikroTik's own bulletin still says regular home/default layouts are lower immediate risk; that is exposure scoping, not a skip.
This is not a claim that every RSA key on every RouterOS install is forgeable. The SSH auth bypass needs knowledge of an authorized RSA modulus (and the weak verifier behavior). Independent lab work reproduced public-key auth without the private key against authorized e=3 keys on 7.23.3; stock e=65537 is not a universal break.

Operator check

# version (want 7.24.2+, 7.23.4+, or 6.49.21+)
/system resource print

Flagged marker after upgrade/reboot
/system device-mode print
IoCs CERT associates with the in-the-wild chain
/log print where message~"-2"
/user print where name="ops"
management exposure (tighten if these listen on WAN)

Log lines to treat as compromise attempts (CERT):

login failure for user -2 from <ip> via ssh
user <name> added by ssh:-2@<ip>

Also hunt unexpected full-policy accounts, scheduler entries that fetch then import, SOCKS proxies, and tunnels you did not create. Absence of Flagged is not proof of cleanliness. MikroTik documents that the marker only catches selected fingerprints.

If you use RADIUS / User Manager for SSH, review whether a username like -2 could ever be accepted from an external AAA path. Independent reverse-engineering of the silent patch reproduced post-auth policy injection once SSH accepted that username, and could not reproduce a stock local-user password path that accepts literal -2 without that precondition.

How to fix

Upgrade RouterOS immediately to 7.24.2, 7.23.4, 6.49.21, or newer via System → Packages → Check for Updates (or your normal image pipeline). Prefer the channel you already run (stable vs long-term). Do not leave older "still listed as long-term" builds such as unpatched 7.20.x / 7.21.x in place: MikroTik's forum clarification is that the fix starts at the named releases, and many years of versions are affected.

Until you can patch: remove SSH, WWW/WWW-SSL, and bandwidth-test from untrusted addresses; do not use /system ssh / /system ssh-exec or outbound TLS from an unpatched box across untrusted paths. Those are temporary exposure cuts only.

If Flagged, IoCs, or unknown users/scripts appear: isolate the device, preserve logs and config for IR, factory-reset, rebuild from a known-good config, and rotate passwords, keys, and RADIUS secrets. Do not blindly restore a full backup from a possibly compromised unit. CERT also warns against clearing the Flagged marker before evidence is secured.

Extra hardening after patch (from the silent-patch analysis, not required by the CVE text alone): audit authorized SSH RSA keys for exponent 3 and prefer Ed25519/ECDSA or RSA e=65537; remove test policy from accounts that do not need diagnostic tools (built-in read includes test and can reach unsafe helpers); restrict or disable MAC-Telnet on untrusted L2.

What this is not

This is not a claim that every MikroTik on the internet is owned without SSH (or the other listed services) being reachable. It is not a silent worm against firewalled management planes. It is also not "CVE assignment of a years-old dead bug": the vendor patched on Sep 3, CERT published CVE detail and active-exploitation confirmation on Sep 5, and internet-exposed SSH is the live blast radius right now. Guard's knownExploited flag may still read false until KEV/NVD catch up; believe CERT's operational confirmation over that lag.

References

HOL Guard evidence pack (CVE-2026-67276)
CERT Polska: actively exploited MikroTrick advisory
CERT Polska: CVE table and per-ID descriptions
MikroTik September 2026 vulnerability bulletin
MikroTik forum: Important security update
Independent silent-patch reverse engineering (7.23.3 vs 7.23.4)
Sibling Guard packs: CVE-2026-86060, CVE-2026-67279, CVE-2026-67281, CVE-2026-67277, CVE-2026-67278

BREAKING: CVE-2026-0799 lets crafted BPF filters walk libpcap process memory

Michael Kantor — Sat, 05 Sep 2026 19:14:34 +0000

Originally published at HOL

The Tcpdump Group shipped libpcap 1.10.7 today with seven CVEs that hit the userspace BPF interpreter and the optional rpcap path. CVE-2026-0799 is the lead: crafted BPF scratch-memory indexes can make the interpreter read and write process memory far outside the intended M[] registers. Six siblings land in the same upgrade. If you ship packet capture, offline BPF replay, or remote capture, treat 1.10.7 as today's floor.

This is the operator write-up. The HOL Guard evidence packs for each CVE ID are the source records.

What breaks

libpcap's userspace BPF interpreter (pcapint_filter_with_aux_data() in bpf_filter.c) assumes programs look like ones libpcap itself compiled or validated. That assumption fails when an app feeds it attacker-controlled instructions through pcap_offline_filter() or a similar path:

CVE-2026-0799 - LD/ST scratch register index is not capped at 15, so the interpreter can walk a huge slice of process memory (Include Security / Mozilla SOS case from 2018, independently confirmed only recently).
CVE-2026-31912 - no program-bounds check on jumps or missing return, so the PC can leave the filter buffer.
CVE-2026-31911 - invalid opcode calls abort() and kills the process.
CVE-2026-6244 - div #k / mod #k with k=0 is not rejected.
CVE-2026-6554 - backward ja loops are unbounded (infinite loop DoS).

On the remote-capture side (only when rpcap is built and used):

CVE-2026-18238 - rpcap client mishandles RPCAP_MSG_PACKET headers; a malicious server can make the client treat up to 20 bytes past the buffer as packet data (affects 1.8.x through <1.10.7).
CVE-2026-18313 - rpcapd leaks up to 64KB per filter/start-capture message and never frees it (1.9.x through <1.10.7).

Release tag libpcap-1.10.7 is dated 2026-09-05. Tarballs are on tcpdump.org. The same release also deprecates bpf_filter() and, on Windows CMake builds, disables remote capture by default.

Who is not in scope

Apps that only compile filters with pcap_compile() / pcap_setfilter() and never hand untrusted BPF bytecode to the userspace interpreter. The Tcpdump Group's own advisories call the BPF bugs "particular uncommon use cases."
Hosts that never enable or link rpcap / rpcapd. Stock live tcpdump -i against a local interface is not the rpcap client bug.
Already on libpcap 1.10.7 (or a distro build that clearly backports these seven commits).

Operator check

# linked libpcap version string
python3 -c "import ctypes; print(ctypes.CDLL(None).pcap_lib_version().decode())" 2>/dev/null \
  || (command -v tcpdump >/dev/null && tcpdump --version 2>&1 | head -5)

Debian/Ubuntu package train
dpkg -l 'libpcap*' 2>/dev/null | awk '/^ii/ {print $2, $3}'
RHEL/Fedora

Anything reporting below 1.10.7 (or a vendor changelog that does not list these CVE IDs) is still on the vulnerable train. Confirm whether your binary was built with remote capture (--enable-remote / CMake remote option) if you care about the rpcap pair.

How to fix

Upgrade libpcap to 1.10.7 or newer. Source release: libpcap-1.10.7.tar.xz (signed). Rebuild anything that statically links libpcap (custom tcpdump builds, NIDS sensors, appliance images). Prefer distro packages once they carry 1.10.7 or explicit backports of the seven commits.

If you cannot upgrade yet and you expose rpcapd, shut remote capture off or put it behind mutual TLS and a tight allowlist. If you evaluate untrusted .bpf / raw filter programs in-process, stop doing that until the library is current.

What this is not

This is not a claim of wormable remote code execution against every host that has libpcap installed. The dangerous BPF paths need an application that runs crafted filter programs through the userspace interpreter. The rpcap issues need remote capture in the build and an attacker on that channel. No CVSS or KEV entry was published with the CVE records at assignment time.

References

HOL Guard evidence pack (CVE-2026-0799)
tcpdump.org - libpcap 1.10.7 release
CHANGES for 1.10.7 (CVE lines for 0799 / 31912 / 31911 / 6244 / 6554 / 18313 / 18238)
Commits: 0799, 31912, 31911, 6244, 6554, 18238, 18313
Sibling Guard packs: CVE-2026-31912, CVE-2026-31911, CVE-2026-6244, CVE-2026-6554, CVE-2026-18238, CVE-2026-18313

CVE-2026-85787: AWS postgres MCP read-only denylist missed set_config()

Michael Kantor — Fri, 04 Sep 2026 20:48:05 +0000

Originally published at HOL

Read-only mode on AWS Labs' Postgres MCP server was enforced by a keyword denylist that missed several Postgres primitives. Before awslabs.postgres-mcp-server 1.1.7, an incomplete blocklist in mutable_sql_detector.py could let SQL that rides an authenticated MCP session mutate data or session state even when the server was configured for read-only queries. AWS published this as CVE-2026-85787 / bulletin 2026-101-AWS on 2026-09-04.

Upgrade to awslabs.postgres-mcp-server 1.1.7 or newer (current PyPI tip is 1.2.0). Pair the bump with a least-privilege Postgres role. The application denylist is defense in depth, not the primary boundary.

What breaks

The MCP server translates natural-language tool calls into SQL against Aurora/Postgres. In the default configuration readonly_query is true unless you pass --allow_write_query. Mutating statements are supposed to die in detect_mutating_keywords / check_sql_injection_risk before they hit the wire.

The 1.1.6 → 1.1.7 patch (PyPI upload 2026-06-25) shows what the old denylist missed. Blocking the SET keyword did not catch the function form set_config(...), because set is not on a word boundary inside set_config. A read query could therefore call set_config('row_security','off',false) or set_config('session_replication_role',...) and defeat RLS-style isolation or session hardening that operators thought the MCP could not touch. The same release also closed related gaps the bulletin only summarizes as an "incomplete list":

SET_CONFIG added to mutating keywords (read-only mode) plus a dedicated SECURITY_SET_CONFIG_PATTERN that rejects those two GUCs in both read and write modes.
Unconditional blocks on the dblink* family (SSRF from the database backend, including to the instance metadata service at 169.254.169.254).
COPY ... TO|FROM PROGRAM blocked even when writes are enabled (shell execution on the DB host when privileges allow).
strip_quoted_identifiers() so double-quoted spellings like "pg_sleep" no longer slip past word-boundary regexes.
Comment-injection heuristic also evaluated on raw SQL, because normalization folded away a trailing --.

AWS rates the bulletin Important. There is no CVSS in the CVE record or NVD entry yet. The attacker model in the advisory is an unauthenticated actor placing crafted SQL into content that an authenticated user later submits through the MCP client. This is not a direct unauthenticated Postgres wire exploit.

Affected: any PyPI awslabs.postgres-mcp-server version < 1.1.7. Fixed: 1.1.7 (2026-06-25). Current tip at write-up: 1.2.0 (2026-08-26).

Who is not in scope

Postgres / Aurora itself. This is the AWS Labs MCP wrapper package, not a database engine CVE.
Installs already on 1.1.7 or 1.2.x.
Deployments that intentionally run with --allow_write_query and already grant the MCP role the DML it needs. Those operators still want the 1.1.7 denylist hardening for dblink* / COPY ... PROGRAM / security GUCs.
Other MCP servers (MySQL, DynamoDB, generic SQL bridges). Only this package's SQL validator.

How to check

From the environment that launches the MCP server, inspect the installed package version:

pip show awslabs.postgres-mcp-server

Read the Version field. Any value below 1.1.7 is in the affected range. If you launch via uvx or a Cursor/VS Code MCP config args list, check that pin the same way (or run pip show inside the same environment the MCP process uses).

How to fix

Upgrade the package, then keep the database role tight.

pip install 'awslabs.postgres-mcp-server>=1.1.7'
# or refresh the uvx pin to @latest / @1.2.0

AWS's workaround (still recommended after the bump): connect the MCP server as a dedicated role, never as superuser / rds_superuser / cluster master. For read-only use, grant only CONNECT + USAGE + SELECT on the schemas the agent needs, and prefer forcing read-only transactions at the role level. The denylist and the role privileges should both hold.

What this is not

This is not a remote unauthenticated Postgres login bug, not a claim of active exploitation, and not a same-day emergency for fleets already on 1.1.7+. The CVE assignment landed on 2026-09-04 for a fix that shipped on PyPI on 2026-06-25. Damage is "read-only" MCP sessions that could still change data or session GUCs when the denylist missed a primitive and the DB role was over-privileged.

References

BREAKING: CVE-2026-9317 lets anyone who can reach your Nango runner run code

Michael Kantor — Fri, 04 Sep 2026 18:39:27 +0000

Originally published at HOL

Anyone who can reach your Nango runner port can start caller-supplied JavaScript in that process. Before 0.71.6, the runner tRPC surface exposed start, abort, and notifyWhenIdle as public procedures with an empty context. No auth middleware sat in front. Network access to the runner was enough to call start with caller-supplied code and execute it inside the runner.

Upgrade alone is not the fix. v0.71.6 ships runner auth, but NANGO_INTERNAL_AUTH_REQUIRED defaults to false. Shipping the new image with no new vars is a no-op. Existing runners keep accepting unauthenticated dispatch until you set REQUIRED=true and restart so runners inherit it.

What breaks

CVE-2026-9317 (VulnCheck, critical, CVSS 9.2 CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, CWE-306) covers Nango >=0 <0.71.6. Fixed in 0.71.6 (GitHub release 2026-09-02). Credit: Katriel Moses, VulnCheck.

Pre-patch packages/runner/lib/server.ts registered those procedures as publicProcedure with empty createContext. RUNNER_SECRET_KEY existed in the env schema but was unenforced on this surface. PR #7288 / commit ed3030a9a0f8e4f3810fd10cb3a1905a2f5f87d2 (merged 2026-09-01) adds internalServiceAuthMiddleware plus task/node-bound procedures. Jobs mint an EdDSA JWT (aud: runner); runners verify with the public key only. /health stays open.

Docs and .env.example still default NANGO_INTERNAL_AUTH_REQUIRED to false. Fail-open is intentional until you flip the flag. Put the signing key on jobs only (NANGO_INTERNAL_AUTH_SIGNING_KEY). Set NANGO_INTERNAL_AUTH_REQUIRED=true on the orchestrator then jobs. Runners receive the public key and REQUIRED at node start. Never put the signing key on runners.

Who is not in scope

Nango Cloud customers (Nango operates the runners).
Deployments where the runner port is not reachable from untrusted hosts.
Callers that only hit GET /health.
Dashboard and public API login paths. This is runner-internal tRPC, not end-user auth.

How to check

From the deploy root, search compose/values/env for NANGO_INTERNAL_AUTH_REQUIRED and the nango image tag, then check runner /health and the installed nango package version.

Confirm image or package version is at least 0.71.6 and NANGO_INTERNAL_AUTH_REQUIRED=true on jobs, orchestrator, and runners after restart. An upgraded tag with REQUIRED still false or unset is still exposed on a reachable runner port.

How to fix

1. Upgrade self-hosted Nango to 0.71.6 or newer.

2. On jobs, set NANGO_INTERNAL_AUTH_SIGNING_KEY. Do not put that key on runners.

3. Set NANGO_INTERNAL_AUTH_REQUIRED=true on the orchestrator, then on jobs. Restart so runners inherit the public key and REQUIRED=true at node start.

4. Re-check version and REQUIRED after restart. Until REQUIRED=true is live on the runner processes, the open door remains.

What this is not

This is not a wormable internet bug without a path to the runner port. It is not fixed by an image bump alone without flipping REQUIRED. It is not the separate August 26 Nango proxy advisories.

References

CVE-2026-85024: undici WebSocket deflate bug can crash the Node process

Michael Kantor — Fri, 04 Sep 2026 17:12:25 +0000

Originally published at HOL

A hostile WebSocket peer can take down the whole Node process, not just the socket. undici's WebSocket client (including Node.js's bundled globalThis.WebSocket) crashes the entire Node.js process when a remote WebSocket peer sends a permessage-deflate compressed message that crosses the decompressed-payload size limit and then contains a malformed DEFLATE block. In lib/web/websocket/permessage-deflate.js, the size-limit cleanup calls removeAllListeners() on the internal zlib InflateRaw, removing its error listener, but leaves the stream running.

Upgrade to undici v6.28.1, v7.29.1 or v8.10.2. Current and LTS tip Node builds still ship older undici. App dependencies can bump now. Built-in globalThis.WebSocket waits on a Node security release or an override.

What breaks

GitHub advisory GHSA-3wwx-pv8p-q78v / CVE-2026-85024 rates this Medium CVSS 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H). Complexity is high: the client must reach a hostile or compromised WebSocket endpoint. Impact is availability only.

The inflater then emits a Z_DATA_ERROR with no listener attached, which Node.js treats as a fatal unhandled error event and terminates the process. Application error/close handlers on the public WebSocket cannot observe or prevent this, because the failing object is the internal InflateRaw. A malicious or compromised WebSocket server can crash a client with a single connection, unauthenticated and without any application mistake. The attack is asymmetric (about 130 KB on the wire expands past the limit) and can be repeated on reconnect (crash loop). Affected applications are those using the undici WebSocket client (new WebSocket(...)) or Node.js's bundled globalThis.WebSocket that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint.

>=6.25.0 <6.28.1, >=7.28.0 <7.29.1, >=8.1.0 <8.10.2. Fixed: 8.10.2, 7.29.1, 6.28.1 (latest=8.10.2).

Node tip builds checked from src/undici_version.h on GitHub still ship older undici: v26.8.1 → 8.10.0, v24.20.0 → 7.29.0, v22.23.2 → 6.28.0. Latest Node GitHub releases as of this write-up were still Aug 26. There is no Node security release with patched undici yet.

Who is not in scope

Apps that never open an undici or Node WebSocket client to untrusted or third-party peers.
Server-only WebSocket stacks that do not use undici client (ws, uWebSockets, browser-only clients).
undici versions outside the three ranges above, including already-patched 8.10.2 / 7.29.1 / 6.28.1.
HTTP fetch-only undici usage with no WebSocket client path.

How to check

For app dependencies from the project root:

npm ls undici

If the resolved version falls in an affected range, upgrade. On Node builds that expose the bundled version:

node -p "process.versions.undici"

Compare that string to the fixed trains. Tip Current/LTS builds listed above still report older numbers until Node ships a security release.

How to fix

Upgrade undici to a patched release on your train.

npm install undici@8.10.2
# or on older trains:
# npm install undici@7.29.1
# npm install undici@6.28.1

Pin or override so transitive copies resolve to the patch. That covers direct new WebSocket(...) from the undici package today.

For Node bundled globalThis.WebSocket, wait for a Node security release that bumps the embedded undici, or replace that client with a dependency you control and keep patched. The advisory lists no application-level workaround.

What this is not

This is not remote code execution, not data theft, and not an unauthenticated internet worm. The peer must already be a WebSocket the client chose to connect to. Damage is process exit and restart loops under AC:H.