DEV Community: Michael Kantor

BREAKING: OpenShift console Devfile API lets anyone SSRF your cluster

Michael Kantor — Fri, 18 Sep 2026 22:51:38 +0000

Originally published at HOL

Anyone who can reach your OpenShift console Route can POST to the Devfile parser with no login, and the console pod will fetch internal URLs and chew memory until it falls over. Red Hat published CVE-2026-75885 today as Important (preliminary CVSS 9.3, CWE-918). The hole is unauthenticated access to /api/devfile/ and /api/devfile/samples/ in the OpenShift console (bridge). There is no RHSA and no Fixed In Version yet. Restrict who can reach the console Route now, and watch access.redhat.com for the errata.

This is the operator write-up. The HOL Guard evidence pack for CVE-2026-75885 is the source record. Do not open a second article for the authenticated Dev Console webhook SSRF sibling CVE-2026-50236; that one needs a login. This one does not.

What breaks

Red Hat’s advisory: unauthenticated access to the Devfile endpoints lets a remote attacker send crafted Devfile payloads. The console pod then makes requests to internal services (SSRF) and can reflect partial responses. Repeated large requests without a content length can drive unbounded memory growth and DoS.

Bugzilla 2517885 (status NEW, Fixed In Version empty) is more specific. In pkg/server/server.go, /api/devfile/ and /api/devfile/samples/ are registered with handleFunc() and are not wrapped in authHandler / authHandlerWithUser the way other /api/* routes are. DevfileHandler decodes an arbitrary JSON body and calls ParseDevfileAndValidate. The Devfile library resolves parent.uri, Dockerfile.uri, and remote plugin references over HTTP from the console pod. There is no MaxBytesReader / body size limit. Partial response bytes show up in the parser error string (partial-read SSRF). The reporter reproduced this on an OCP 5.0 nightly. Upstream tree: openshift/console.

Red Hat scores it CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L (9.3 Important), marks mitigation as not available under their Product Security criteria, and notes scores are preliminary. Impact in plain terms: an unauthenticated caller who can hit the console Route can use the console pod as a proxy into the cluster network and can DoS the console process with large bodies.

Who is not in scope

Clusters where the OpenShift console Route is not reachable from the attacker (strict network policy, private console only, no public Route) remove the unauthenticated blast radius for this CVE, but that is exposure control, not a patch. Installs that do not run the OpenShift console / bridge are out of scope. Authenticated-only Dev Console webhook SSRF tracked as CVE-2026-50236 is a different bug with a login requirement; do not treat a fix for one as coverage for the other. Non-OpenShift Kubernetes dashboards (vanilla kube-dashboard, Rancher UI, etc.) are not this CVE.

How to check

From a host that can reach the console Route, without a session cookie or OAuth token, probe whether the Devfile endpoint accepts an unauthenticated POST (expect a parser error JSON, not a 401/403 redirect to login):

# Replace CONSOLE with your console Route base URL (no trailing slash)
# A 401/403/login redirect is healthy. A 200/4xx parser body without auth is the bad path.
curl -sk -o /tmp/devfile-probe.body -w "HTTP %{http_code}\n" \
  -X POST "$CONSOLE/api/devfile/" \
  -H "Content-Type: application/json" \
  -d '{"content":"schemaVersion: 2.2.0\nmetadata:\n  name: probe\n"}'

Also confirm which console image your cluster runs

If the POST returns application JSON from the Devfile parser with no auth challenge, treat the Route as exposed to CVE-2026-75885 until Red Hat ships a console build that wraps those routes in auth and caps body size. Keep the probe payload tiny and stop after one request; do not load-test production.

How to fix

There is no public RHSA / Fixed In Version yet (Bugzilla 2517885 still NEW with an empty Fixed In Version field as of this writing). Red Hat lists mitigation as not available under their criteria. Until errata lands:

# 1) Restrict who can reach the console Route (NetworkPolicy / ingress / private API only)
# 2) Watch for the RHSA on the CVE page, then upgrade the console operator / console image
#    https://access.redhat.com/security/cve/CVE-2026-75885
#
# After an RHSA ships, apply the errata the usual way for your OCP train, for example:
#   oc adm upgrade --to=<errata-recommended-version>
# or follow the RHSA package list for the console image digest.
#
# Re-run the unauthenticated POST probe above and confirm you get auth failure, not parser output.

Do not invent a version number. When Red Hat publishes Fixed In Version / RHSA, upgrade that build and re-check the probe. Interim control is network exposure of the console Route, not a config flag named in the advisory.

What this is not

This is not remote code execution on the cluster and not a claim that every OpenShift install on the public internet is already owned. It is unauthenticated SSRF plus resource-exhaustion DoS through two Devfile API routes on the console, with Scope Changed and Confidentiality High on Red Hat’s preliminary 9.3. It is not the authenticated Dev Console webhook SSRF (CVE-2026-50236). It is not “wait for NVD analysis before acting”: if your console Route is reachable, shrink exposure today and watch for the RHSA.

References

BREAKING: WordPress comment XSS lets strangers plant script (7.1.1)

Michael Kantor — Fri, 18 Sep 2026 06:21:30 +0000

Originally published at HOL

An unauthenticated visitor can leave stored script in WordPress through comment formatting, and WordPress just shipped 7.1.1 to stop that path. The CVE List entry is CVE-2026-93485 (Patchstack): DOM-based / stored XSS in core paragraph formatting. WordPress.org’s own security notes say the issue is unauthenticated stored XSS via paragraph formatting, subject to comment approval. The same short-cycle release also closes ten other security bugs. Treat 7.1.1 as an emergency upgrade for any site still on 7.1 or older supported branches.

This is the operator write-up for the WordPress 7.1.1 security train. The HOL Guard evidence pack for CVE-2026-93485 is the source record. Do not open a second blog post for the other fixes in this same upgrade.

What breaks

WordPress published WordPress 7.1.1 Maintenance and Security Release (dated 2026-09-17 on the news post; CVE-2026-93485 published 2026-09-18). Official wording credits Rafie Muhammad (Awesome Motive) for stored XSS in wpautop() that lets an unauthenticated visitor inject script, subject to comment approval. Patchstack’s CVE text adds that a default install can reproduce the unauthenticated stored XSS path: comment moderation is off by default, and the “must have a previously approved comment” gate can be bypassed.

Affected trains named in the CVE: WordPress 7.1 before 7.1.1, plus older lines through the usual security-backport range (7.0.x through 4.7.x as listed in the CVE). Fixed for the current line: 7.1.1. Patchstack marks the issue CVSS 7.1 (High) with unauthenticated required privilege and user interaction required for full impact.

CVE-2026-93485 is not the only reason to move. The same 7.1.1 release lists 11 security fixes, including (paraphrased from WordPress.org, not separate CVE IDs unless you have them):

Crafted URL that can install and preview an inactive theme from WordPress.org
Stored XSS in some themes that support custom headers
HTML API set_modifiable_text() comment break-out
Contributor+ arbitrary post overwrite
Authenticated path traversal in the REST templates controller
XML-RPC path that can publish customize_changeset posts bypassing edit_css
Site Administrator network-activating a network-only plugin (multisite)
Missing read_post check leaking a private parent-post title
Contributor+ draft/pending post slug disclosure
Any authenticated user reparenting comments (including notes)

WordPress.org recommends updating immediately because this is a security release. Automatic background updates will pick it up where enabled.

Who is not in scope

Sites already running WordPress 7.1.1 (or the matching security backport for your branch once it lands) are outside CVE-2026-93485. Static HTML, headless frontends that never render WordPress comments, and installs with comments fully closed remove the comment-injection path for this CVE, but they are not a substitute for the 7.1.1 binary if you still run core PHP for admin, REST, XML-RPC, or themes. Multisite-only items in the 11-fix list do not apply to single-site installs. Non-WordPress CMSes are out of scope.

How to check

On every WordPress host (and every container image that embeds core):

# WP-CLI
wp core version
wp core check-update

or from PHP in the site root

Confirm the printed version is 7.1.1 or newer on the 7.1 line (or the patched build for your older branch after backports ship). In wp-admin: Dashboard → Updates should show 7.1.1 available or already installed. Also note whether comments are open on public posts (wp option get default_comment_status) and whether moderation is required. Those settings change how easy the CVE-2026-93485 path is to hit; they do not replace the core upgrade.

How to fix

Upgrade WordPress to 7.1.1 (or the security build for your supported branch) and verify the version string afterward:

# WP-CLI (preferred)
wp core update --version=7.1.1
wp core update-db
wp core version

or Dashboard → Updates → Update Now

If you run multiple sites from one image, rebuild and redeploy the image rather than patching only one container. After upgrade, spot-check a public post with comments: submit a benign test comment and confirm it still behaves under your moderation policy. Review recent pending/approved comments for unexpected markup while you are there. WordPress notes security backports for older branches (through 4.7) are in progress; do not wait on a backport if you can move the current line to 7.1.1 now.

What this is not

This is not remote code execution and not an unauthenticated admin takeover. CVE-2026-93485 is stored / DOM XSS: an attacker plants script that runs in a visitor’s or moderator’s browser when the poisoned content is viewed. WordPress.org’s advisory ties the unauthenticated path to comment approval. It is not “every WordPress site is already owned,” and it is not limited to one obscure plugin. It is core, same-week, with an official “update immediately” security release that also closes ten other issues. Upgrade first; argue severity later.

References

Aborted multer uploads still fill the disk after the 5038 fix

Michael Kantor — Wed, 16 Sep 2026 13:35:27 +0000

Originally published at HOL

Abort a multer disk upload before the storage engine names the file, and the complete write can still land as an orphan. The June 2026 fix for CVE-2026-5038 cleaned uploads that already had a destination path. It did not catch the brief window where the request dies before diskStorage assigns that path. Late-completing writes leave finished files behind. An unauthenticated client that can open multipart uploads can accumulate those orphans until the upload directory or system temp fills. If you upgraded to 2.2.0 or 2.3.0 for 5038, you are still exposed.

Upgrade to multer@2.4.0. That release is the incomplete-fix follow-through for the same orphaned-disk class.

What breaks

GitHub advisory GHSA-3pph-fpjx-jg34 / CVE-2026-88932 rates this Moderate (CVSS 5.3, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L; CWE-400, CWE-459). Impact is availability only, and only for diskStorage. npm published 2.4.0 the same day as the advisory (2026-09-14); the GitHub release tag landed minutes earlier. Weekly downloads for multer sit around 15.6 million. About 52% of that traffic (~8.0M) was still on 2.2.x/2.3.x last week (2.2.0 ~4.77M, 2.3.0 ~3.31M), which is exactly the train people moved onto after 5038.

The 2.4.0 patch does what the GHSA one-liner does not spell out. Commit 53337f97 ("fix: remove late-completing uploads aborted before the engine names them") tracks abortCleanupDone and abortRemovedFiles in lib/make-middleware.js. If the storage engine finishes after abort cleanup already ran, middleware calls storage._removeFile directly instead of leaving the orphan. The regression test is test/orphan-before-path-assignment.js. Async destination / filename callbacks widen the race: more time between abort and path assignment means more room for a late complete write.

Affected: npm multer >=2.2.0 <2.4.0. Fixed: 2.4.0. The earlier advisory is GHSA-3p4h-7m6x-2hcm / CVE-2026-5038.

Who is not in scope

Apps that never use multer.diskStorage (for example memoryStorage only).
Already-patched installs on 2.4.0 or later.
multer v1.x (~19% of weekly downloads last week). That line is outside the affected range for this CVE; do not treat 88932 as a v1 upgrade mandate.
Uploads that never abort before the engine assigns a path (the 5038 cleanup path already covered those).

How to check

From the app root:

npm ls multer

Any resolved version in 2.2.0 through 2.3.x is vulnerable to this follow-on. In lockfiles, confirm the resolved version string, including transitive copies from Express scaffolds and upload helpers. If you pin an override for 5038 at 2.2.0 or 2.3.0, bump that pin.

How to fix

Upgrade multer to the patched release.

npm install multer@2.4.0

Pin or override transitive copies so every resolved path is 2.4.0 or newer, then restart the process. After deploy, check the configured upload directory and os.tmpdir() for leftover orphaned files from abort traffic; the patch stops new orphans, it does not vacuum old ones.

What this is not

This is not remote code execution, not path traversal outside the configured destination, and not a memoryStorage bug. A remote client that can start multipart uploads and abort early can drive disk exhaustion on the upload path. Damage stops at availability.

References

BREAKING: Unbound DNSKEY digest overflow can RCE your resolver (1.26.1)

Michael Kantor — Wed, 16 Sep 2026 09:14:41 +0000

Originally published at HOL

Your recursive DNS resolver can take attacker-controlled data from a malicious zone and overflow a digest buffer while validating DNSKEY records. NLnet Labs shipped Unbound 1.26.1 today (2026-09-16) with a same-day CVE batch. The lead issue is CVE-2026-81642: a heap overflow in the DNSSEC validator when digesting DNSKEYs, with possible remote code execution through attacker-controlled data. An adversary who controls a malicious zone only needs a vulnerable Unbound to query it.

This is the operator write-up for the 1.26.1 upgrade train. The HOL Guard evidence pack for CVE-2026-81642 is the source record. Sibling packs for the same release sit under Guard as well; do not open a second blog post for this train.

What breaks

Vendor advisory for CVE-2026-81642: a DNSKEY whose owner name uses a compression pointer into its own RDATA can overflow the digest buffer. Remote code execution is possible through attacker-controlled data. Unbound 1.26.1 checks buffer capacity after decompression and before writing.

That bug is not alone. The same 1.26.1 tarball also closes other same-day Unbound CVEs that share the upgrade:

CVE-2026-82717: CNAME synthesis that rewrites a max TTL in the packet buffer, plus a bad compression pointer, can progressively corrupt heap memory. Under some systems and compilation options that can become RCE. Disclosed by Ben Morris (Anthropic).
CVE-2026-81634: a 255-length query name with a large TCP response can heap-overflow during RRSet canonicalisation before DNSSEC validation. Triggerable from a malicious name server or a tampered response.
CVE-2026-82720: use-after-free on DoH stream cleanup when Unbound is built --with-libnghttp2. Failure paths (RPZ drop, jostle under load) can free a session while other streams remain. Reads are not attacker-controlled; a hardened allocator can turn this into DoS. Affects 1.12.0 through 1.26.0 with DoH.
CVE-2026-85501: ReTrap algorithmic DNSSEC complexity attacks (TagTrap, DelegationTrap, NsecTrap, AdditionalTrap). 1.26.1 adds match/operation/NSEC caps and defaults val-clean-additional to off.
CVE-2026-80225: unbounded consecutive TCP/DoT reads let a client monopolize one worker's event loop with distinct uncached names.
CVE-2026-78227: DoQ use-after-free when built --with-libngtcp2 (1.22.0-1.26.0): RESET_STREAM frees the stream output buffer while ngtcp2 still holds retransmission pointers.
CVE-2026-77955: ZONEMD zones below a trust anchor (zonemd-check: yes) can briefly serve or write tampered contents before verification finishes (1.13.2-1.26.0).
CVE-2026-77860: serve-expired double-decrements the per-client wait-limit, weakening the DNSBomb countermeasure from CVE-2024-33655 (1.20.0-1.26.0).

Affected line for the RCE-class DNSKEY and CNAME bugs: Unbound up to and including 1.26.0. Fixed line: Unbound 1.26.1 (unbound-1.26.1.tar.gz). Distro packages will lag; treat anything still reporting 1.26.0 or older as in the blast radius until you confirm the patch.

Who is not in scope

Resolvers that are not Unbound (BIND, Knot Resolver, PowerDNS Recursor, systemd-resolved, cloud recursive anycast) are outside this advisory set. Unbound already on 1.26.1 is outside. CVE-2026-82720 does not apply if you never built with --with-libnghttp2 / DoH. CVE-2026-78227 does not apply without --with-libngtcp2 / DoQ. CVE-2026-77955 only hits operators who enable zonemd-check: yes on zones below a trust anchor. CVE-2026-77860 only bites when serve-expired is on. Stub resolvers and authoritative-only Unbound deployments that never recurse into attacker zones still need the binary upgrade for the shared code paths, but the practical DNSKEY/CNAME RCE story is recursive validation against a hostile zone.

How to check

On every Unbound host (and every container image that embeds it):

unbound -V | head -n 5
# or
unbound -V 2>&1 | grep -E 'Version|linked libs|libnghttp2|ngtcp2'

Confirm the printed Version is 1.26.1 or newer. Also note whether the build line mentions libnghttp2 or ngtcp2; those flags decide whether 82720 / 78227 were reachable on that binary. Package managers:

dpkg -l unbound 2>/dev/null | awk '/^ii/ {print $2,$3}'
rpm -q unbound 2>/dev/null
# FreeBSD / ports style
pkg info unbound 2>/dev/null | head

If your fleet runs Unbound behind Ansible, Puppet, or a distro mirror, inventory the running binary version, not just the package name on the mirror metadata. A host still answering on 1.26.0 after the mirror shows 1.26.1 is still vulnerable.

How to fix

Upgrade Unbound to 1.26.1 and restart the service. Prefer the vendor tarball or your distro's patched package once it lands:

# source build (vendor)
curl -fsSL -O https://nlnetlabs.nl/downloads/unbound/unbound-1.26.1.tar.gz
tar xf unbound-1.26.1.tar.gz && cd unbound-1.26.1
./configure && make && sudo make install
sudo systemctl restart unbound
unbound -V | head -n 1

For Unbound 1.26.0 source trees that cannot jump packages yet, NLnet Labs published per-CVE patches (full and minimal) next to each advisory on nlnetlabs.nl/downloads/unbound/. Apply with patch -p1 then make install. Operators should still prefer the full 1.26.1 release so every sibling in this batch lands together.

After upgrade, re-check unbound -V, confirm workers are on the new binary (systemctl status unbound / process start time), and watch recursion logs for unusual DNSSEC failures from zones you do not own. If you expose DoH or DoQ, treat those listeners as in-scope until the build flags and version both clear.

What this is not

This is not a confirmed in-the-wild worm as of the vendor notes we used (the advisories do not claim active exploitation). It is not "any DNS software." It is not automatic RCE on every Unbound install: CVE-2026-81642 and CVE-2026-82717 need a path where Unbound digests or synthesizes against attacker-influenced zone data, and 82717's RCE path is layout- and build-dependent. DoH/DoQ UAFs need those features compiled in. ReTrap and the TCP/DoT read starvation bugs are availability and resource-abuse stories, not the same as the DNSKEY digest RCE. Still: Unbound is widely deployed recursive DNS. Same-day vendor RCE language on the resolver that answers for your network is enough to treat 1.26.1 as an emergency upgrade.

References

Hidden command in Claude Code: base64 piped to sh

Michael Kantor — Tue, 15 Sep 2026 13:21:55 +0000

Originally published at HOL

You were in Claude Code. The chat line looked short. Under it the agent packed a hidden command in base64 and tried to pipe the decode straight into sh. If that finishes, whatever was inside is already running on your laptop. You never saw the real program as a normal argv list.

HOL Guard froze that line before the decode hit a shell. Two buttons on screen: Allow just this once, or Keep blocked. Until you tap Allow, the packed command has not started.

Local Inbox review for a paused Claude Code command. Queue shows the short decode line; the card is PAUSED ACTION / Needs review with Allow just this once and Keep blocked.

Button labels on the live review card: Allow just this once, Keep blocked. Scope defaults to a one-time allow for this exact action.

Keep blocked leaves the action stopped. The receipt stays on your machine.

Why a short chat line still hurts

Most shell policy starts with command words you can read. A decode-then-run chain breaks that habit. Outer tokens look like a decoder. The program that matters appears only after decode. Review exists so a human sees the shape before a shell gets that output.

Sibling Extensions still matter. If the decoded content would curl credentials, that is command.data-protection. If the agent tries to clear the pause itself, that is command.guard-self-protection. This Extension only claims decode or decrypt, then immediate execute.

What Guard maps

Built-in Encoded execution protection (command.encoded-execution, v1.0.0, high). Catalog default: review. One operation: Encoded execution (command.encoded-execution.decode-and-execute). Identifies decode or decrypt chains that immediately execute their output.

Catalog shape (reviewed by default): echo <base64> | base64 --decode | sh. Copy the live example from the directory page. Do not invent a payload for this blog paste path.

A workspace can tighten to block or loosen the floor unless a managed-restrictive Control Set pins the Extension. Catalog default is not your fleet policy.

On Protect / Extensions, leave posture at Protected unless you have a deliberate reason to Watch. Watch will not stop the chain. Extra careful raises friction when your team wants more pauses around nearby shapes.

Out of scope

command.encoded-execution does not cover:

Decoding content to a file and stopping there, with no execute step in the same reviewed chain.
Credential-file send or local upload via curl: command.data-protection.
An agent calling hol-guard approvals approve on itself: command.guard-self-protection.
Package installs and one-shot runners (npx, npm): Package Firewall Extensions.
Obfuscation that never hits a reviewed decode-and-execute op.

One check that does not run the pipe

command test and command explain do not execute the command, create an approval, or write a receipt.

hol-guard command test '<paste catalog decode-and-execute example>'
hol-guard command explain '<paste catalog decode-and-execute example>'
hol-guard command controls show command.encoded-execution
hol-guard command extensions

Copy the catalog example from the directory page. Do not paste a live decode-pipe as a copy-paste exploit on this page. After an upgrade, run the test before you trust muscle memory. If test says unrecognized, confirm the Extension is current and posture is not Watch.

After Inbox lights up

This pause is for decode-or-decrypt then immediate execute. Ordinary base64 that never runs a shell is not in scope.

Change the permission in Protect / Extensions or via CLI. For a team floor that local auto-approve cannot weaken, pin a managed-restrictive Control Set on this Extension's permission ID.

If you meant the decode-and-execute, choose Allow just this once after you know what the decoded stream becomes. If you did not, Keep blocked and find which prompt or tool suggested the chain. Receipt stays local. Cloud sync is optional and does not carry the raw command.

Background: HOL Guard 3.0.

Keep a Codex Task on Track Through Compaction with Context Guard

Michael Kantor — Sat, 12 Sep 2026 18:41:27 +0000

Originally published at HOL

A long Codex task can involve research, edits, tests, and several changes of direction. When the conversation is compacted, you still need the original constraints to apply to the result. You also need to know which requirements have actually been checked.

Context Guard keeps a private checklist of requirements and verification evidence alongside the task. This walkthrough shows how to define a concrete task, pause for compaction, recover the open requirements, and check the finished artifact against them.

The example is a practice exercise, not a transcript of a measured experiment.

1. Install and activate

Use a Codex surface that supports plugins and lifecycle Hooks. Follow the current installation guide for the supported Python and Codex versions and the commands for your platform.

Installation and Hook trust are separate steps. Start a fresh Codex task, open /hooks, review and trust the plugin's Hook definitions, then start another fresh task in a disposable practice workspace. Existing tasks may retain the version they started with.

In the Codex conversation, enter:

$context-guard

Use context-guard status to inspect the protected state. Enter these controls in the Codex conversation.

2. Give the task a concrete finish line

Ask Codex to prepare a small design document using this synthetic brief:

Create docs/design/checkout-v2.md for a practice checkout service.

Keep these decisions unchanged:

The API is POST /checkout.
The service validates the request before recording the order.
The rollout date is 2026-10-01.

Use these sections: Context, Decisions, Validation, Open Questions.
Do not add infrastructure commitments.
Give each recommendation a source link or a "to verify" label.

The file path makes the expected result concrete. The fixed decisions and section names give you things to compare with the final document. The source-link rule makes unsupported recommendations visible.

Review the outline before proceeding. This pause is intentional: it leaves unfinished work available for the recovery exercise.

3. Compact, then inspect what survived

At the pause, run /compact in Codex. Once compaction finishes, enter:

context-guard status

Then ask:

Before continuing, restate the open requirements for
docs/design/checkout-v2.md, including the fixed decisions,
required sections, and evidence checks. Then write the file
and verify it against those requirements.

Compare the recovered requirements with the original brief. Check the API, operation order, date, four sections, infrastructure restriction, and recommendation rule. A status count alone cannot establish that the right details survived.

Context Guard's documented recovery behavior restores the open checklist after compaction or resume. Completed and historical work is tracked separately from the current work so earlier tasks do not automatically become new unfinished work.

4. Check the artifact and the evidence

Have Codex read the finished file and report what it verified. For this example, the readback should establish that the named file exists, contains the four required sections, and preserves the API, operation order, and date. Review recommendations for a source link or the explicit uncertainty label, and inspect whether the draft introduces an infrastructure commitment.

A successful formatting check only establishes formatting. It does not establish that the rollout date is correct or that a recommendation has support. Match each result to the requirement it actually checks, and review the cited sources yourself when their meaning matters.

Context Guard uses successful tool evidence associated with the requested result when checking completion. Its deterministic checks have limits: it cannot establish that an arbitrary design is sound or that every source supports an interpretation. Unclear evidence should remain unresolved rather than become a claim of success.

5. Recognize the ending

Normal successful paths are quiet. You do not need a special success receipt or private checkpoint command to finish an ordinary task.

If Context Guard reports that the task is not yet safely complete, ask which requirement still lacks evidence. Use context-guard diagnose for bounded diagnostic information, then address the missing check. A genuine pause for your input can end the turn while leaving the task unfinished.

For your next task, choose one concrete artifact and write down its acceptance checks before work starts. After compaction, inspect the recovered requirements; before accepting completion, inspect the artifact and the evidence. Context Guard helps carry that workflow across a long conversation, while tests and human review remain essential.

ScreenConnect client file runs hit CISA KEV

Michael Kantor — Fri, 11 Sep 2026 20:41:48 +0000

Originally published at HOL

CISA added CVE-2026-84869 to the Known Exploited Vulnerabilities catalog today (2026-09-11). ConnectWise disclosed the bug on September 8 and shipped ScreenConnect 26.6.5 the same day. The failure is in the client: during an active Support or Access session, file-transfer actions can land on the Host and run without the Host confirmation operators expect. That includes elevated execution paths. ScreenConnect servers are not in the blast radius.

Cloud instances already run 26.6.5 on the server side. You still need to reinstall host clients and update access agents so the endpoints pick up the client fix. On-prem partners upgrade the server to 26.6.5 or later, then do the same client refresh. Federal KEV due date is 2026-09-14. Forensic triage is marked Yes.

What breaks

ConnectWise rates CVE-2026-84869 Critical, CVSS 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). Weaknesses: missing authorization (CWE-862) and improper privilege management (CWE-269). Earlier ScreenConnect Client builds for Support and Access sessions processed file-transfer actions through an active remote session without proper authorization or Host confirmation. Under those conditions a Guest-side actor in the session can transfer a file to the Host and execute it, including elevated execution actions.

Impacted product line: ScreenConnect versions prior to 26.6.5. Fixed line: ScreenConnect 26.6.5 and later. NVD published the record 2026-09-08.

Priority on the ConnectWise bulletin is Priority 1 High: either being targeted or at higher risk of being targeted in the wild. Treat the client refresh as an emergency change, not a quiet backlog ticket.

Who is not in scope

ScreenConnect servers themselves. The advisory is explicit: servers are not impacted. This is a client/session handling bug, not a server RCE.
Idle boxes with no active remote session. The condition rides an active Support or Access session. It is not "anyone on the internet can drop a binary with zero session."
Cloud partners who already reinstalled host clients and access agents after the 26.6.5 cloud push. The server is already remediated in cloud; remaining risk is stale clients.
On-prem installs that cannot reach 26.6.5 yet because they are below 25.4. ConnectWise requires 25.4 or later before the 26.6.5 upgrade path. Those partners still need a plan (upgrade train, license eligibility, or TransferFiles mitigation below), but the 26.6.5 installer is not the first click.

One operator check

On the ScreenConnect instance, open Administration → Overview and read the current version. Anything prior to 26.6.5 is still on the vulnerable train for on-prem. Cloud partners should see 26.6.5 on Overview already; then verify host clients and access agents were actually reinstalled or updated after that push, not just that the server badge moved.

While you wait for a maintenance window, cut the immediate path: Administration → Security → Roles, edit each role, and deselect TransferFiles on every session group that has it. Save. Repeat for each role. ConnectWise calls this temporary mitigation, not a substitute for 26.6.5.

How to fix

Upgrade ScreenConnect to 26.6.5 or later, then refresh every host client and access agent.

Cloud: server side is already updated. Reinstall host clients and update access agents per ConnectWise docs so endpoints leave the vulnerable client build.
On-prem: download 26.6.5 from the ScreenConnect download page (valid on-prem license required). Confirm Latest Eligible Version on Administration → Overview before you install. If the license is out of maintenance, renew or upgrade the license first. Automate-integrated on-prem installs pull 26.6.5 through Automate Product Updates when Automate Assurance is active.
After the server bump: reinstall host clients and update access agents the same way cloud partners must. Patching the server alone does not retire every stale client.
Interim: strip TransferFiles from roles as above until 26.6.5 is live everywhere that matters.

ConnectWise also tells partners to review users with ScreenConnect access after the patch: remove unused accounts, re-check role grants, and treat unexpected session or transfer history as investigation material. That matches CISA's forensic-triage flag on this KEV entry.

What this is not

This is not an unauthenticated internet worm that pops ScreenConnect servers with no session. It is a client-side authorization failure during an already-active remote session: file transfer and execution without the Host confirmation operators rely on. Do not skip the client refresh because "cloud already says 26.6.5."

References

Self-managed GitLab: unauth commits API file read hits CISA KEV

Michael Kantor — Fri, 11 Sep 2026 20:17:34 +0000

Originally published at HOL

CISA added CVE-2026-85706 to the Known Exploited Vulnerabilities catalog today (2026-09-11). GitLab shipped the Critical Patch Release that closes it on September 10: 19.1.8 / 19.2.6 / 19.3.2. The bug is an unauthenticated path traversal in the repository commits API. Anyone who can reach a vulnerable self-managed instance can read arbitrary files off the GitLab server. That means repo secrets, SSH keys, .env files, and whatever else sits on disk under the GitLab service account.

GitLab.com is already patched. Dedicated customers have nothing to do. Self-managed operators on 18.7 through unpatched 19.3.x need to upgrade now. Federal agencies on KEV have a due date of 2026-09-14 and forensic triage is marked Yes.

What breaks

GitLab rates CVE-2026-85706 Critical, CVSS 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N). Improper path confinement plus missing auth enforcement on the repository commits API let an unauthenticated caller pull files from the server. Impacted: GitLab CE/EE all versions from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. Reporter: s3ntago via HackerOne. CWE-35.

The same Critical Patch Release also closes two EE-only siblings you should treat as part of the same upgrade, not separate tickets:

CVE-2026-87719 Critical CVSS 9.9. Insecure deserialization in the GraphQL subscription serializer. An authenticated user with Duo Chat access can obtain Advanced Search instance configs and credentials via a crafted subscription argument. EE only, from 18.3 before the same fixed trains.
CVE-2026-88765 High CVSS 8.5. Buffer overflow in a Unicode conversion wrapper used by Advanced Search indexing. An authenticated user can reach RCE by importing a crafted project export. EE only, from 12.3 before the same fixed trains. Attack complexity is High.

Lead with 85706. It needs no login, hits CE and EE, and is on KEV. The other two ride along when you upgrade.

Who is not in scope

GitLab.com already runs the patched build. No action.
GitLab Dedicated customers: vendor says no action required.
Versions before 18.7 for CVE-2026-85706. The commits-API path traversal range starts at 18.7.
CVE-2026-87719 and CVE-2026-88765 are Enterprise Edition only. CE instances are out of scope for those two. Both also need authentication (Duo Chat for 87719; project-import / Advanced Search path for 88765).

Operator check

Confirm your version before you declare yourself clear:

# Omnibus / package
dpkg -l gitlab-ce gitlab-ee 2>/dev/null | grep -E 'gitlab-(ce|ee)'
# or
rpm -q gitlab-ce gitlab-ee 2>/dev/null

From the Rails console / rake helper

In the Admin UI: Admin Area → Overview → Dashboard shows the running version. You need ≥ 19.1.8 on the 19.1 train, ≥ 19.2.6 on 19.2, or ≥ 19.3.2 on 19.3. Anything 18.7.x through unpatched 19.3.1 is still in the 85706 window.

If the instance is internet-facing and unpatched, treat file-read of secrets on the GitLab host as a realistic outcome and rotate credentials that lived under that service account after you upgrade.

How to fix

# Debian/Ubuntu Omnibus CE example (match your edition + train)
sudo apt-get update
sudo apt-get install gitlab-ce=19.3.2-*
# or 19.2.6-* / 19.1.8-* on older supported trains

RHEL/CentOS Omnibus

Follow GitLab's Update docs for your install type (Omnibus, Helm, source). This patch includes database migrations. Single-node installs will take downtime while migrations finish. Multi-node can use zero-downtime procedures. 19.3.2 also ships post-deploy migrations you can run after the upgrade.

GitLab Runner updates are separate; bump the application first for these CVEs.

What this is not

CVE-2026-85706 is arbitrary file read, not remote code execution by itself. It is not a worm. SaaS / GitLab.com is already fixed. The blast radius that matters is self-managed, internet-facing instances on 18.7 through unpatched 19.3.x. The EE siblings (87719 / 88765) need auth and product features (Duo Chat / Advanced Search import) that not every install enables.

References

GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8 (2026-09-10)
CISA KEV: CVE-2026-85706, dateAdded 2026-09-11, dueDate 2026-09-14, forensicTriage Yes

Your agent tried to ship your AWS keys

Michael Kantor — Fri, 11 Sep 2026 19:38:41 +0000

Originally published at HOL

You left Claude Code running. Mid-session it tried to send your AWS keys to a website you never opened. Whoever gets those keys can spin up servers on your bill. That is the laptop you code on.

HOL Guard caught the send and froze it before it left the machine. Two buttons on screen: Allow just this once, or Keep blocked. Do not tap Allow and the keys stay on the laptop. The assistant does not click for you.

Local Inbox review for a paused Claude Code command. Queue shows the curl; the card is PAUSED ACTION / Needs review with Allow just this once and Keep blocked.

Button labels on the live review card: Allow just this once, Keep blocked. Scope defaults to a one-time allow for this exact action.

Keep blocked leaves the action stopped. The receipt stays on your machine.

What Guard is watching for

This shape maps to the built-in Command data protection Extension (command.data-protection, v1.0.0). Catalog default for both operations is review:

Credential data transfer (command.data-protection.permission.credential-exfiltration). Curl that posts a cloud credentials file off the machine.
Local file upload (command.data-protection.permission.file-upload). Curl that uploads a local report PDF.

Exact credential-file curl strings live on that directory page. This post uses a /tmp dummy for the live demo so the write path stays clear of filters that trip on home credential paths.

A workspace can tighten to block or loosen the floor unless a managed-restrictive Control Set pins the Extension. Catalog default is not your fleet policy.

Live proof used a dummy under /tmp. hol-guard command test on that line returned REVIEW under command.data-protection.file-upload, with risks credential_exfiltration and network_egress. The same shape under a PreToolUse hook landed in Inbox as Needs review.

Settings → Protection: Protected (default), Extra careful, Watch.

Extensions / Modules in the local dashboard. command.data-protection ships built-in.

How the pause shows up

Guard Core owns policy, approvals, receipts, the daemon, and the local dashboard. Guard Desktop is the optional tray UI. Closing the tray does not turn enforcement off. Install from hol.org/guard/install if you want the tray; local by default, Cloud sync optional.

Install Guard Desktop from hol.org/guard/install when you want the tray UI.

Agent tool use hits a PreToolUse hook; Guard parses the line once; Inbox offers Allow just this once or Keep blocked. Protect / Extensions sets posture: Protected (default), Extra careful, or Watch. Watch records without stopping. Approvals also work from hol-guard approvals in a terminal you control.

Out of scope

command.data-protection does not cover:

Reading a secret file locally with cat or an editor. Mapped ops are send and upload.
Browser MCP tools posting a form.
Package installs (npx, pip): Package Firewall Extensions.
Decode-and-execute shell chains: command.encoded-execution.
An agent calling hol-guard approvals approve on itself: command.guard-self-protection.

One check that does not run curl

command test and command explain do not execute the command, create an approval, or write a receipt.

hol-guard command test '<WAF-safe dummy: curl posts /tmp/demo-cloud-keys to example.com>'
hol-guard command explain '<catalog file-upload example from directory page>'
hol-guard command controls show command.data-protection
hol-guard command extensions

Rehearse with a /tmp dummy path (not a home credentials path). The live proof shape returned REVIEW under command.data-protection.file-upload. Copy catalog examples from the directory page for the literal credential-file strings. After an upgrade, run the test before you trust muscle memory. If test says unrecognized, confirm the Extension is current and posture is not Watch.

What this does not claim

This is a pause on two send and upload shapes Guard already intercepts. It will not stop every outbound curl. Reading a secret file in an editor is not this Extension.

Change the permission in Protect / Extensions or via CLI. For a team floor local auto-approve settings cannot weaken, use a managed-restrictive Control Set on this Extension's permission IDs.

If you meant the upload, choose Allow just this once with your eyes on the URL. If you did not, Keep blocked and find which prompt or MCP tool suggested the curl. Receipt stays local. Cloud sync is optional and does not carry the raw command.

Background: HOL Guard 3.0.

Artifactory anonymous token chain hits CISA KEV

Michael Kantor — Fri, 11 Sep 2026 19:26:25 +0000

Originally published at HOL

CISA put CVE-2026-42018 and CVE-2026-42016 on the Known Exploited Vulnerabilities catalog today (2026-09-11). Wiz Research already documented in-the-wild chaining of those two bugs on self-hosted JFrog Artifactory: an unauthenticated call mints an internal anonymous JWT, then that low-privilege token is exchanged for admin scope. Operators who only chased CVE-2026-82329 (the join-key path we covered on 28 Aug) can still be open on this older pair.

Upgrade self-hosted Artifactory to a build that clears both CVEs on your train. Prefer the later trains JFrog listed for the Critical sibling as well: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20. Then hunt logs for the chain below.

What breaks

JFrog rates CVE-2026-42018 High (CWE-287). Published 12 Aug 2026. Artifactory can return an internal anonymous-user token to an unauthenticated caller even when anonymous access is disabled. Fixed builds on the advisory: 7.111.20, 7.117.27, 7.125.19, 7.133.28, 7.146.8.

JFrog rates CVE-2026-42016 High (CWE-863). Published 27 Jul 2026. Token validation checks signature and issuer but not intended scope, so a low-privilege token can be escalated. The advisory lists a single fixed floor: 7.133.11.

Neither bug alone is full admin. Together they are. Wiz's observed sequence (Aug 15 through Sep 8, 2026):

POST /access/api/v1/aws/token/ with a trailing slash returns HTTP 200 and a JWT for the internal anonymous user (CVE-2026-42018).
POST /access/api/v1/tokens exchanges that JWT for an admin-scoped token while the username stays anonymous (CVE-2026-42016).
Actors then create persistent admins via PUT /api/security/users/... or /access/api/ui/users/..., install malicious Groovy plugins, run /api/plugins/execute/..., and in several cases drop a Rust C2 binary under /dev/shm, /tmp, or /var/tmp.

Wiz notes a useful probe signature for 42018: the same client gets 401 on the bare path, then 200 on a trailing-slash or path variant, inside a short window. Later requests often show actor token:anonymous doing admin work. That is not normal operator traffic.

Exposure when those CVEs first published was not a niche corner case. Wiz measured about two-thirds of organizations with Artifactory still holding at least one vulnerable instance at disclosure, with slow patch velocity on the High pair versus the Critical 82329.

Who is not in scope

JFrog Cloud. Both advisories say affected Cloud environments were already fortified.
Self-hosted nodes already on fixed builds for both CVEs on your train. Clearing only 42016 or only 42018 breaks the published chain; clearing neither leaves it open.
The CVE-2026-82329 join-key path (POST /access/api/v1/registry/join). That is a different unauth-admin bug with its own ranges and KEV add on 2026-09-02. Patching 82329 does not automatically mean you cleared 42018/42016.
Branches where JFrog's 42016 advisory does not claim impact. JFrog only listed "< 7.133.11" for 42016. Do not invent that 7.146/7.161 are vulnerable to 42016, and do not invent that they are immune to 42018 without checking the 42018 table.

How to check

Confirm product version (not a single microservice build):

jf rt curl /api/system/version

Compare version to the fixed floors above. If you are still below 7.146.8 on the 7.146 train, or below 7.133.28 / 7.133.11 on 7.133, treat the chain as open until proven otherwise.

Then search Access / reverse-proxy logs for the Wiz sequence: unauthenticated POST /access/api/v1/aws/token/ (trailing slash) returning 200, followed quickly by POST /access/api/v1/tokens, then admin user creates. Flag accounts matching patterns Wiz reported (Nxploited_*, labadmin_*, svc_*, jfrog-distribution, repo-service, 0xTerror, and similar). Pull join keys and token inventories if those endpoints were hit.

How to fix

Upgrade self-hosted Artifactory on your current train to builds that include the 42018 and 42016 fixes. Practical target set that also clears the Critical sibling many fleets still chase:

7.161.x → 7.161.20
7.146.x → 7.146.38 (42018 floor on this train was 7.146.8; take the later Critical build)
7.133.x → 7.133.29 (must be at least 7.133.28 for 42018 and 7.133.11 for 42016)
7.125.x → 7.125.20
7.117.x → 7.117.28
7.111.x → 7.111.21

CISA KEV dateAdded for both CVEs is 2026-09-11 (catalogVersion 2026.09.11). dueDate is 2026-09-25. Follow BOD 26-04 and the forensic triage requirements linked from the KEV notes. After upgrade, re-run the version API and require an exact match on a patched string. Restrict the Access API from the public internet while you patch.

What this is not

This is not a JFrog Cloud emergency. It is not remote code execution by itself. Admin on Artifactory is the vendor impact; shells and Rust backdoors showed up after actors abused plugins and write paths. It is not CVE-2026-82329 (different endpoint, Critical, KEV 2026-09-02). It is not "anonymous access was left on." Wiz and JFrog both describe token minting while anonymous access is disabled.

This article is the operator write-up for the KEV / in-the-wild chain. The HOL Guard evidence pages remain the source records for CVE-2026-42018 and CVE-2026-42016. Our earlier operator post on the Critical sibling is CVE-2026-82329.

References

CVE-2026-71416: Headroom WebSocket proxy spends your OpenAI key for any reachable browser

Michael Kantor — Fri, 11 Sep 2026 14:26:23 +0000

Originally published at HOL

If a browser on your network can open ws://your-host:8787/v1/responses, it can ride Headroom's stored OpenAI key. Before headroom-ai 0.35.0, the Responses WebSocket handler accepted the upgrade without checking Origin, then injected Authorization: Bearer $OPENAI_API_KEY when the client sent none. A malicious page (or headless browser) that can reach that listener spends your quota, drives arbitrary prompts and tools, and can reach RCE if the upstream session exposes a shell tool. CVE-2026-71416 is the Sept 11 ID for a fix that already shipped in 0.35.0 on Aug 13.

Upgrade to headroom-ai>=0.35.0 (current line is 0.37.0). If you must stay on an older build, do not bind the proxy where browsers can reach it, and do not keep OPENAI_API_KEY in the proxy process environment.

What breaks

GitHub advisory GHSA-h46j-26q3-rggf / CVE-2026-71416 rates this High (CVSS 8.8, AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). User interaction is required in the CVSS sense (a browser must run the malicious WebSocket client), but no Headroom login is required once the page can reach the proxy. The GHSA PoC targets ws://<host>:8787/v1/responses with a response.create payload, including a local shell tool.

The advisory explains the missing check and the env-var auth fallback. The Aug 13 0.35.0 patch does three things the GHSA does not spell out. It rejects disallowed origins with WebSocket close code 1008 and reason origin not allowed, logging event=websocket_origin_not_allowed. Native clients that omit Origin still pass. When Origin is present and you have not configured an allowlist, only loopback origins are accepted. Operators set the allowlist with HEADROOM_WS_ORIGINS (comma-separated); if that is empty, Headroom also reads HEADROOM_CORS_ORIGINS. A literal * in the list re-opens every origin.

PyPI package name is headroom-ai (not the unrelated headroom package). GitHub shows about 71k stars; PyPI recent downloads for headroom-ai are on the order of hundreds of thousands per month. Affected: headroom-ai < 0.35.0 (GHSA marks the vulnerable train from 0.23.0). Fixed: 0.35.0 and later.

Who is not in scope

Installs already on headroom-ai>=0.35.0 (0.35.0 hit PyPI 2026-08-13; 0.37.0 is current).
Library-only or MCP-only usage that never runs the local OpenAI Responses WebSocket proxy on /v1/responses.
Proxies that never store OPENAI_API_KEY in the process environment and require the client to send its own Authorization header (the GHSA exploit path relies on the env-var injection).
Listeners that browsers cannot reach (true localhost-only bind with no malicious local content, or network policy that blocks the WS port).

How to check

From the environment that runs the proxy:

pip show headroom-ai

Any printed version below 0.35.0 is vulnerable. Also confirm whether the proxy process exports OPENAI_API_KEY and whether anything listens on port 8787 (or your configured proxy port) beyond loopback. After upgrade, if browsers on other origins must use the WS endpoint, set an explicit allowlist rather than relying on the loopback default:

export HEADROOM_WS_ORIGINS=https://app.example.com,http://127.0.0.1:3000

How to fix

Upgrade headroom-ai to the patched release or newer.

pip install 'headroom-ai>=0.35.0'

Restart the proxy. Prefer not to put long-lived provider keys in the proxy environment if clients can supply their own auth. Do not set HEADROOM_WS_ORIGINS=* unless you fully trust every browser that can reach the listener.

What this is not

This is not a bug in OpenAI, and it is not unauthenticated RCE inside the Headroom process itself. Damage is CSWSH against the proxy: a reachable WebSocket plus a stored provider key. RCE appears only when the proxied session can invoke dangerous tools (for example a local shell tool). CVE assignment landed about a month after 0.35.0 shipped; the upgrade urgency is for fleets still below that floor.

References

CVE-2026-87776: Express compression leaks native memory until the process dies

Michael Kantor — Fri, 11 Sep 2026 13:23:06 +0000

Originally published at HOL

Hang up while gzip is still streaming and the Node process keeps the zlib memory forever. The Express compression middleware (< 1.8.2) only tears down its compression stream from inside its own res.end() wrapper. When a client aborts mid-response, that wrapper never runs, so each aborted compressed reply leaves a live native zlib handle pinned. Repeat it and RSS climbs until the process is OOM-killed. The bug is unauthenticated and needs no app bug beyond shipping compression.

Upgrade to compression@1.8.2. There is no application-level workaround in the advisory.

What breaks

GitHub advisory GHSA-vc2v-76pw-4v95 / CVE-2026-87776 rates this High (CVSS 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Impact is availability only. npm published 1.8.2 the same day as the advisory (2026-09-11). Weekly downloads for compression sit around 30 million, so most Express and Connect stacks that enable response compression are on the blast radius.

The 1.8.2 patch does three things the GHSA blurb does not spell out. It adds a close listener on the response before onHeaders runs, so a disconnect that lands before the zlib stream exists is still recorded. It releases that stream through the destroy package rather than calling stream.destroy() alone, because the patch comment states that destroy() by itself still leaks the zlib handle on some Node.js versions. And if the response already closed before the stream was created, it destroys the late stream immediately, nulls the reference, and falls back to the raw response so later writes do not keep a doomed compressor alive. HISTORY.md also notes a case-insensitive match for the Cache-Control: no-transform skip, which is unrelated to the leak but ships in the same release.

Affected: compression npm < 1.8.2. Fixed: 1.8.2.

Who is not in scope

Apps that never mount compression (or an Express/Connect stack that vendors it) and let a reverse proxy or CDN handle gzip/br instead.
Already-patched installs on 1.8.2 or later.
Non-HTTP uses of zlib that do not go through this middleware.
Browsers and clients; this is a server-side leak on the response path.

How to check

From the app root:

npm ls compression

Any resolved version below 1.8.2 is vulnerable. In lockfiles, search for the package entry and confirm the resolved version string. If you vendor a copy (Next.js and similar have historically vendored this middleware), check that tree the same way; a framework-level workaround does not replace upgrading the package you actually require.

How to fix

Upgrade compression to the patched release.

npm install compression@1.8.2

Pin or override transitive copies so every resolved path is 1.8.2 or newer, then restart the process. The advisory lists no workaround other than the upgrade.

What this is not

This is not remote code execution, not credential theft, and not an auth bypass. A remote client that can open requests and disconnect early can drive memory exhaustion and crash the server. Damage stops at availability.

DEV Community: Michael Kantor

BREAKING: OpenShift console Devfile API lets anyone SSRF your cluster

What breaks

Who is not in scope

How to check

How to fix

What this is not

References

BREAKING: WordPress comment XSS lets strangers plant script (7.1.1)

What breaks

Who is not in scope

How to check

How to fix

What this is not

References

Aborted multer uploads still fill the disk after the 5038 fix

What breaks

Who is not in scope

How to check

How to fix

What this is not

References

BREAKING: Unbound DNSKEY digest overflow can RCE your resolver (1.26.1)

What breaks

Who is not in scope

How to check

How to fix

What this is not

References

Hidden command in Claude Code: base64 piped to sh

Why a short chat line still hurts

What Guard maps

Out of scope

One check that does not run the pipe

After Inbox lights up

Keep a Codex Task on Track Through Compaction with Context Guard

1. Install and activate

2. Give the task a concrete finish line

3. Compact, then inspect what survived

4. Check the artifact and the evidence

5. Recognize the ending

Links

ScreenConnect client file runs hit CISA KEV

What breaks

Who is not in scope

One operator check

How to fix

What this is not

References

Self-managed GitLab: unauth commits API file read hits CISA KEV

What breaks

Who is not in scope

Operator check

How to fix

What this is not

References

Your agent tried to ship your AWS keys

What Guard is watching for

How the pause shows up

Out of scope

One check that does not run curl

What this does not claim

Artifactory anonymous token chain hits CISA KEV

What breaks

Who is not in scope

How to check

How to fix

What this is not

References

CVE-2026-71416: Headroom WebSocket proxy spends your OpenAI key for any reachable browser

What breaks

Who is not in scope

How to check

How to fix

What this is not

References

CVE-2026-87776: Express compression leaks native memory until the process dies

What breaks

Who is not in scope

How to check