Cyber Decision LedgerDecision area
Patch prioritization
146 public Decision Records in the whole ledger carry this label. Back to the full Ledger →
Decision Records
Replace Coldcard seeds generated with weak entropy
Treat potentially affected seeds as a high-severity exposure. Generate replacement seeds on corrected or otherwise trusted hardware, verify recovery offline, and migrate funds promptly rather than relying on a firmware update alone.
Use Coinkite's authoritative advisory to determine whether a seed may be affected. If it was generated under affected conditions, do not rely on a firmware update alone: create a new seed on corrected or otherwise trusted hardware, test recovery offline, and migrate funds promptly. Confirm exact model, firmware, and entropy-exception scope with the vendor advisory.
Contain reported VMware vCenter exploitation
Remove vCenter management access from the internet, isolate systems showing compromise indicators, preserve evidence, apply vendor-supported fixes, rotate administrative credentials that may have been reachable, and hunt across managed ESXi hosts and datastores.
Organizations responding to reported vCenter exploitation should remove management interfaces from internet exposure, isolate systems with compromise indicators, preserve evidence, apply authoritative vendor fixes, rotate potentially reachable administrative credentials, and hunt across managed hosts and datastores. Verify local compromise rather than assuming every system was affected.
Immediate exposure reduction for affected SAP Commerce Cloud systems
Identify potentially affected internet-facing Data Hub Adapter deployments, apply the applicable vendor-confirmed remediation or restrict the vulnerable endpoint until remediation is complete, preserve telemetry, and escalate to incident response only when exploit traffic is followed by consequential system behavior.
Organizations should promptly determine whether internet-facing SAP Commerce Cloud Data Hub Adapter deployments are affected, apply the applicable vendor-confirmed remediation or restrict the vulnerable endpoint until remediation is complete, and preserve telemetry. Escalate to incident response only when exploit traffic is accompanied by execution, file changes, outbound activity, persistence, or other consequential system behavior. Honeypot attempts alone do not establish production compromise.
Immediate hardening of identity recovery and payment-change workflows
Identity recovery, payroll, finance, manager, and privileged-user workflows should ban voice-only recovery, require verified approvals and pre-registered callbacks, move high-risk users toward phishing-resistant authentication, revoke sessions after suspected compromise, audit mailbox rules and delegates, and require out-of-band approval for payroll-bank changes.
Treat account recovery, privileged session handling, and payroll-bank changes as high-risk workflows. Require verified approvals and callbacks to registered channels, phase in phishing-resistant authentication for high-risk users, revoke active sessions and refresh tokens after suspected compromise, audit mailbox rules and delegates, and require out-of-band approval for bank-detail changes. Avoid presenting unverified incident mechanics as settled facts.
Emergency patching for exposed self-hosted Roundcube
Exposed self-hosted Roundcube installations should preserve relevant logs first, then urgently upgrade according to vendor-fixed branches, restrict risky plugins or administrative access as needed, and hunt for abnormal mailbox, IMAP, callback, PHP execution, and session activity.
For exposed self-hosted Roundcube deployments, preserve relevant logs before maintenance, verify the vendor-recommended fixed branch locally, upgrade promptly, restrict risky plugins or administrative access where needed, and hunt for abnormal mailbox, IMAP, callback, PHP execution, and session activity. Caveat exploit-mechanic wording unless primary technical evidence is added.
Containment-first patching for exposed SonicWall SMA1000 appliances
Exposed SonicWall SMA1000 appliances should be isolated or tightly access-restricted before and during emergency patching, with logs preserved, active sessions revoked, and investigation for compromise that may have occurred before patching.
For exposed SonicWall SMA1000 appliances, treat emergency patching as a containment event: restrict access, preserve logs, revoke sessions, apply the vendor-recommended fixed version, and review for signs of earlier compromise. Avoid stating exact exploitation or fixed-build details unless separately verified.
Finance-sensitive Android loader checks
Keep Anatsa-style Android loader activity below the edge and MSP emergency priority, but run same-day MDM and app inventory for finance-sensitive Android devices, require Play Protect or mobile threat scans, remove suspicious reader or utility apps, check Accessibility and SMS permissions, and increase banking, payroll, expense-card, and crypto transaction monitoring.
Organizations with Android devices used for banking, payroll, expense-card, or cryptocurrency workflows should run same-day MDM and app inventory checks, require mobile threat or Play Protect scanning, remove suspicious reader or utility apps, review Accessibility and SMS permissions, and monitor finance transactions. Keep campaign mechanics qualified unless app names or public indicators are added.
OT remote-access safety sweep for small utilities
Small water, wastewater, and energy operators should perform a controlled OT safety sweep: verify physical process state locally, remove public PLC and HMI exposure, restrict vendor VPNs, cellular routers, private APN paths, and edge management access, rotate default credentials with OT staff present, preserve logs, and test manual fallback procedures before disruptive segmentation changes.
Small water, wastewater, and energy operators should run a safety-first remote-access review with operations staff: verify local process state, remove public controller and HMI exposure, tighten vendor and cellular access paths, change default credentials carefully, preserve logs, and test manual fallback before disruptive network changes. Avoid unsupported attribution or incident-specific details.
Assume-compromise handling for exposed Metabase and Langflow
Exposed Metabase and IBM Langflow instances should still be handled as possible compromise: remove internet exposure, upgrade or patch when applicable, revoke sessions, rotate connected credentials, and review logs for admin, export, secret-access, code-execution, and lateral-movement activity.
If Metabase or Langflow is exposed, reduce internet access and treat connected secrets and sessions as potentially at risk. Use vendor guidance for exact versions and patches, and review logs for administrative changes, data export, secret access, execution, and movement activity.
Review reliance on Connective Belgian eID signatures
Do not assume blanket invalidity or continued reliance for signatures from the vulnerable window. Patch and version-verify managed endpoints, risk-tier or temporarily suspend high-value remote signing until verified, preserve signing logs and transaction metadata, and run a case-specific signature-reliance review before deciding whether affected transactions must be challenged, re-executed, caveated, or reported.
Organizations using affected Connective Belgian eID signing workflows should verify patch status against current vendor guidance, preserve signing logs and transaction metadata, consider a risk-tiered pause for high-value remote signing until verified, and conduct a case-specific reliance review with appropriate legal and operational stakeholders before deciding whether any transaction needs caveats or re-execution.
Freeze executed developer-trust paths after malicious packages or extensions
Freeze and quarantine CI jobs, build runners, publish workflows, and developer workstations where suspect npm packages, WEL1DROPPER or Sliver activity, malicious VS Code extensions, or AI-tool impersonators were installed or executed. Preserve artifacts first, rotate repository, cloud, package, and wallet credentials, and rebuild from clean images when payload execution, persistence, Sliver, or secret exposure is plausible.
When a validated malicious package, extension, or developer-tool impersonator may have executed, freeze and quarantine the affected developer-trust path, preserve artifacts, rotate exposed repository, cloud, package, and wallet credentials, and rebuild from clean images where payload execution, persistence, or secret exposure is plausible. Use trusted indicator lists for exact package and extension scoping.
Identity session and approval workflow hardening
Treat phishing-kit takedown as disruption, not remediation: revoke risky Microsoft 365 and Entra sessions and refresh tokens, inspect OAuth grants, require phishing-resistant MFA for high-risk roles, shorten session persistence, and move payment, payroll, vendor-bank, HR, and help-desk approvals to out-of-band dual control rather than relying on voice, video, email, or chat alone.
Organizations should treat phishing-kit takedowns as disruption rather than remediation and harden Microsoft 365 and Entra sessions, OAuth grants, MFA, and session persistence. High-risk finance, payroll, HR, vendor-bank, and help-desk approvals should require out-of-band dual control instead of relying on voice, video, email, or chat alone.
WordPress emergency patching without mass RCE framing
Emergency-patch externally exposed and administrator-heavy WordPress sites, restrict login and admin paths to VPN or known IPs where patching is delayed, and reserve full containment for sites with post-exploitation indicators. Do not label the issue as mass unauthenticated remote code execution based on the reviewed evidence.
Treat WordPress core CVE-2026-64638 as urgent patching for exposed or administrator-heavy sites, restrict login and admin paths if patching is delayed, and reserve containment for sites with post-exploitation indicators. The reviewed packet does not support describing it as mass unauthenticated remote code execution.
BTCPay Server LND release-status verification
Do not treat a reported release number as automatically safe. Treat BTCPay Server deployments with LND integration as exposed until the current project-fixed build is confirmed, public access is restricted, LND macaroons and related credential material are rotated or revoked, logs are reviewed, and funds are moved only after fresh credential authority is established.
Because release status in the reviewed material is unresolved, operators of BTCPay Server with LND integration should verify current project guidance before treating any release as fixed, restrict public access, rotate or revoke LND macaroons and related credentials, review logs, and resume fund movement only under fresh credential authority.
CI/CD release freeze for exposed TeamCity and risky npm changes
Pause release builds triggered by exposed or suspect TeamCity infrastructure and apply risk-based holds on high-risk npm dependency changes until the build path is investigated, dependencies are pinned, and build-job credentials are rotated.
Engineering teams with exposed or suspect TeamCity infrastructure should pause affected release builds, preserve and investigate CI evidence, pin high-risk dependencies, and rotate credentials available to build jobs. npm dependency holds should remain risk-based unless package-specific evidence is added.
N-central delegated-management containment
Treat reported N-central exploitation as a potential delegated-management trust-plane compromise. Apply the current vendor hotfix after preserving relevant evidence, reduce exposure, review remote-management activity, and revoke or rotate delegated credentials, sessions, API keys, and related trust paths.
Organizations operating N-central should treat the reported exploitation as a potential delegated-management compromise. Preserve relevant evidence, apply the current vendor hotfix, reduce exposed access, review remote-management activity, and rotate delegated credentials, sessions, API keys, and related trust paths as appropriate.
AI agent execution containment
Treat coding and browser AI agents as privileged execution infrastructure. Validate vendor advisories and update affected tools, run agents in constrained workspaces, isolate agent CI runners, remove long-lived secrets from agent-visible environments, deny tunnel or persistence creation from agent ancestry by default, and keep browser agents away from authentication, finance, and admin workflows.
Security teams should manage coding and browser AI agents like privileged execution paths: constrain workspaces, isolate CI runners, remove long-lived secrets, restrict sensitive browser workflows, and block tunnel or persistence creation from agent-launched processes unless explicitly approved. Vendor-specific patch statements should be tied to confirmed advisories.
Token and session revocation before password resets
For exposed automation tokens, credential-based tenant compromise, or MFA phishing, revoke API tokens, workflow credentials, OAuth grants, sessions, remembered devices, recovery factors, and newly enrolled authenticators before relying on password resets.
When SaaS or automation credential exposure is confirmed, a password reset alone is not sufficient. Revoke or invalidate exposed tokens, OAuth grants, sessions, remembered devices, recovery factors, and suspicious newly enrolled authenticators before treating the account or workflow as restored.
Contain risky network-accessible Paperclip instances
Treat network-accessible Paperclip instances with risky default or authenticated configuration as emergency risk: restrict access or take them offline, disable registration and import paths where possible, preserve relevant logs and snapshots, upgrade after validating the fixed stream, and rotate reachable secrets.
Administrators should contain exposed, risky Paperclip deployments quickly and validate fixed-release guidance before reopening. Preserve logs and rotate reachable secrets where integrations could have been exposed; do not cite an exact cutoff unless primary release or vulnerability database guidance is available.
Revoke reusable identity trust before rotating passwords
For credential-based intrusions, revoke active sessions, refresh tokens, OAuth grants, SAML sessions, remembered devices, API keys, and weak trust paths before or alongside scoped password rotation; move targeted privileged users toward phishing-resistant MFA.
In credential-driven incidents, prioritize revoking reusable trust artifacts, then rotate exposed credentials and strengthen MFA for targeted privileged accounts. Present this as a response pattern, not confirmation that every named scenario occurred.
Water-sector exposed control-path containment
Operators should remove public exposure from controllers, HMIs, engineering workstations, VPNs, cellular modems, and vendor remote-access paths; preserve controller state; verify physical process conditions; and restore only after safe local control and trusted access paths are validated.
Water and wastewater teams with exposed control or remote-access paths should prioritize same-day containment: remove public exposure, preserve state, check physical process conditions, and restore through trusted access. Treat attribution and reported incident scale as secondary unless primary advisories are added.
Coldcard seed-provenance fund migration
Yes. Where Coldcard seed provenance is affected or uncertain, treat the seed material as unsuitable for continued custody: generate fresh seed material on verified unaffected hardware or through an audited ceremony, migrate funds in staged transactions, and rotate multisig signers where provenance is uncertain.
Where Coldcard seed provenance is affected or uncertain, do not rely on firmware updates alone. Generate fresh seed material using verified unaffected hardware or an audited ceremony, move funds in staged transactions, and rotate multisig signers as needed. Avoid broad claims about affected scope unless a direct source defines it.
AI-agent and SaaS identity token-broker lockdown
Yes. Treat AI-agent automation and SaaS identity flows as token-broker control planes tonight: restrict device-code authentication and OAuth consent, review high-risk app scopes, rotate automation and API tokens, use task-scoped least-privilege agent roles, require human approval for privileged tool calls, patch affected agent-framework deployments as vendor updates are available, and log tool-call provenance.
Treat AI-agent automation and SaaS identity flows as token-broker control planes. Restrict device-code authentication and OAuth consent, review high-risk app scopes, rotate automation and API tokens, enforce least privilege and human approval for privileged tool calls, apply vendor updates as available, and log tool-call provenance. Do not imply confirmed tenant compromise without corroboration.
Developer-tool one-click execution patching
Engineering fleets, especially privileged developer workstations, should patch vendor-confirmed fixed releases immediately. Review telemetry for editor-launched shells or credential tooling after commit-link activity, and rotate GitHub, npm, cloud, CI, or signing credentials only where execution is suspected or privileged telemetry is missing.
Engineering teams should update Cursor, VS Code, and Google Antigravity to vendor-confirmed fixed releases and review privileged developer telemetry for signs of editor-launched execution after suspicious commit-link activity. Credential rotation should be targeted to suspected execution or missing privileged telemetry.
Shai-Hulud npm publishing and CI/CD containment
Do not reopen npm publishing and CI/CD normally after Shai-Hulud package cleanup. Freeze risky publishing and dependency updates, identify affected direct and transitive paths from local lockfiles and inventories, hunt build hosts and developer endpoints, rotate reachable developer, cloud, and CI secrets, rebuild runners, and restore release authority only from clean credentials and verified packages.
Teams recovering from the Shai-Hulud npm compromise should keep risky publishing and dependency updates frozen until package inventory, developer and build-host review, secret rotation, and runner rebuilds are complete. Precise affected-version claims should come from authoritative package evidence or local verification.
N-able N-central control-plane containment
Treat exposed N-able N-central administration as an incident-response control-plane problem: remove direct internet exposure, apply vendor-confirmed fixes or mitigations, rotate administrative and API credentials, revoke active sessions, hunt for remote-control abuse and persistence, and review managed endpoints and customer access logs.
Organizations with exposed N-able N-central administration should treat the issue as a control-plane containment event, not routine patching: remove direct exposure, apply vendor-confirmed fixes or mitigations, reset trust in administrative access, and check for downstream misuse before returning to normal operations.
Harden hotel network use for high-risk travel
Yes. For executive, diplomatic, defense, energy, media, government, and similar high-risk travel, use separate or managed devices, phishing-resistant MFA, avoid sensitive logins over unmanaged hotel networks, and revoke or refresh tokens after travel.
High-risk travelers should temporarily harden hotel network use with managed or separate devices, phishing-resistant authentication, avoidance of sensitive logins over unmanaged networks, and token refresh after travel. Keep campaign attribution cautious.
Govern privileged AI agents as untrusted automation
Yes. Treat AI agents with CI/CD, cloud, browser, or internet authority as untrusted automation by removing long-lived secrets, using least-privilege tokens, separating read-only from write-capable agents, requiring human approval for privileged actions, blocking production credentials, filtering egress, logging tool calls, and alerting on unexpected workflow or secret-handling behavior.
Treat AI agents that can touch CI/CD, cloud, browser, or internet workflows as untrusted automation: remove long-lived secrets, use least privilege, require human approval for privileged actions, block production credentials, control egress, log tool calls, and monitor unusual workflow or secret-handling behavior.
Isolate exposed water control paths
Yes. If a water or wastewater control path is reachable from the internet, isolate or firewall it now, verify the physical process locally, preserve controller and network evidence, and require engineering approval before PLC logic, restart, patching, or network changes.
Where water or wastewater control paths are reachable from the internet, operators should isolate or firewall them, verify physical process state locally, preserve controller and network evidence, and require engineering approval before changes to PLC logic, restarts, patching, or network paths.
N-able N-central containment for exposed management environments
Treat exposed N-able N-central and Take Control environments as a critical containment event, not as patch-only remediation. Restrict management access, patch to validated fixed releases, revoke active admin sessions and credentials, and hunt for unauthorized remote-control activity and tunnel persistence before closure.
For exposed N-able management environments discussed in the briefing, treat remediation as containment-first. Restrict management access, patch to validated fixed releases, revoke sessions and credentials, and look for unauthorized remote-control activity or tunnel-style persistence before declaring recovery complete.