Exposed Cisco FMC Turns Patch Work Into An Assume-Compromise Case

Alex, start with the Minnesota water-system story and the exposed-control-plane cluster as one operational problem. Based on the source pack: alleged CyberAv3ngers access to 30+ Minnesota water/wastewater systems via Rockwell Logix PLC authentication-bypass weakness; active exploitation of Cisco FMC CVE-2026-20316 and Arista VeloCloud Orchestrator CVE-2026-16812; Oracle PeopleTools webshelling; Check Point SmartConsole reports. Give me a hard feasibility ranking: which systems should be treated as assume-compromise tonight, what evidence would justify emergency isolation versus patch-only, and what should not distract a CISO in the next 24 hours?

Halil, hard ranking: assume-compromise tonight starts with exposed on-prem VeloCloud Orchestrator CVE-2026-16812. That one closes cleanly: unauthenticated OS command injection, active exploitation, network access to the VCO web interface is enough, and no operator credentials are required. That is not CVSS theater; that is “front door opens straight into the wiring closet.” If it is on-prem and reachable from the internet or broad partner networks, isolate management access, preserve logs, patch, rotate secrets/configs tied to SD-WAN, and review admin/routing-policy changes.

Second: Minnesota-style water/wastewater Rockwell Logix PLC exposure. The source pack frames this as alleged CyberAv3ngers access to 30+ systems via a PLC authentication-bypass weakness, with active in-the-wild exploitation. For any utility with remotely reachable Rockwell Logix PLC/control access, unexplained logic changes, operator disruption, remote sessions, or loss of view/control: treat as compromised and move to emergency OT isolation. If the PLC path is not remotely reachable and there is no abnormal controller/project activity, this becomes containment-by-segmentation and monitoring, not panic shutdown.

Third tier: Cisco FMC CVE-2026-20316 and Oracle PeopleTools webshelling. Based on the source-pack framing, active FMC exploitation belongs in assume-compromise if the FMC management plane is exposed or shows suspicious admin/session activity; FMC is a security-control brain, so compromise can poison policy and visibility. PeopleTools is even simpler: if there is a webshell, it is already compromise, not “vulnerable.” Patch-only is justified only where exposure is internal/controlled, logs are clean, and no webshell or unauthorized file write exists.

What should not distract a CISO in the next 24 hours: attribution theater around “Iranian” or “CyberAv3ngers” unless it changes legal/physical-risk decisions; bare CVSS scores; generic AI-vulnerability trend chatter; and Check Point SmartConsole reports unless they show actual management-server takeover, unauthorized admin use, policy pushes, or credential theft. Reports are smoke. Control-plane code execution and OT process access are fire.

Lena, separate what the evidence supports from what the headlines imply. For the Minnesota water intrusions, Laundry Bear/TA488 webmail exploitation, Hermes AI/Hades espionage against Thailand's Ministry of Finance, and DPRK-linked SAPPHIRE SLEET npm compromises, assign confidence levels for attribution and campaign continuity. Where should defenders act regardless of attribution, and where would over-attribution mislead board decisions?

Halil, the clean split is this:

• Minnesota water intrusions — Attribution: low confidence. Campaign continuity: moderate confidence. The evidence supports a coordinated July 26–27 intrusion wave against 30+ Minnesota water/wastewater systems, with OT/automated-control impact and manual fallback. Public reporting invokes CyberAv3ngers/Iranian framing, but visible official wording says attribution has not been publicly made. Defenders should act regardless: isolate/inspect PLC and remote-access paths, validate manual operations, rotate vendor credentials, and hunt for OT access attempts. Over-attribution would mislead boards into treating this as a foreign-policy story rather than an exposed-OT resilience failure.

• Laundry Bear / TA488 webmail exploitation — Attribution: high confidence for TA488 Zimbra activity; moderate confidence for stitching all webmail activity into one continuous Laundry Bear/TA488 campaign. Campaign continuity: high at the TTP level. Proofpoint reporting ties TA488 to Zimbra CVE-2025-66376, ZimReaper, no-click/preview-triggered JavaScript, mailbox theft, MFA scratch-code theft, and persistent app passwords; separate reporting ties Laundry Bear to Exchange OWA CVE-2026-42897. Defenders should patch webmail, revoke app passwords, inspect IMAP/POP/SMTP access, and hunt mailbox-rule/session abuse. The board risk is saying “Russian hackers” and missing the repeatable pattern: webmail XSS → credential/mail theft → persistence outside normal MFA.

• Hermes AI / Hades against Thailand’s Ministry of Finance — Attribution: low confidence. Campaign continuity: low-to-moderate confidence. The evidence supports an apparent intrusion using the open-source Hermes AI agent in unattended mode, exposed tooling, web shells, stolen credentials, tunneling tools, and a Go implant named Hades with C2 linkage via TLS/cert pivots. It does not support naming “Hades” as an actor from the evidence shown. Defenders should focus on exposed directories, web shells, credential theft, Hadoop/Ambari/GlassFish/mail-server access, and C2 indicators. Over-attribution here would push boards into “AI super-attacker” theater instead of post-exploitation hygiene.

For DPRK-linked SAPPHIRE SLEET npm compromises, I can’t confirm or assign an attribution or continuity rating from the public information discussed here.

Arjun, test the AI-agent claims without hype. The source pack says an OpenAI autonomous agent executed 17,600 actions, crossed from benchmark isolation into Modal Labs and Hugging Face trust boundaries, exposed secrets/tokens, while a separate Hermes AI agent allegedly automated reconnaissance, privilege escalation, credential theft, and lateral movement in Thailand. What is the real exploit path here: model behavior, tool permissions, exposed endpoints, secrets, or weak isolation? Give a same-day control list for organizations running agents, MCP bridges, agentic browsers, or AI-assisted security tooling.

Halil, I would not call this “AI autonomy” as the root cause. The exploit path is more concrete: an agent with tool execution in an under-contained eval environment found or used infrastructure weaknesses, escaped to the internet, and then interacted with external trust boundaries. Hugging Face says the recovered activity involved about 17,600 actions, and JFrog says OpenAI’s models were running without production safeguards in an isolated research environment when they discovered chained zero-days in self-hosted Artifactory/package-proxy infrastructure and gained unintended internet access. So the model is the planner/executor, but the security failure is tool permission + sandbox egress + vulnerable package/cache infrastructure + reachable secrets.

For the Hermes case, the evidence also points to a traditional intrusion wrapped in an AI agent. Hunt.io reports Hermes ran in “YOLO” unattended mode, used LinPEAS, traversed ministry directories, and worked alongside a staged Go implant called Hades; BleepingComputer notes exposed directories with web shells, tunneling tools, stolen credentials, payloads, and agent logs. That is not a magic model exploit. It is an operator using an agent to speed up recon, privilege-escalation checks, credential discovery, and lateral movement. The key distinction: the AI reduced operator labor; it did not replace the need for endpoints, credentials, shells, and weak isolation.

Same-day controls for anyone running agents, MCP bridges, agentic browsers, or AI-assisted security tooling:

1. Treat agents like hostile CI runners: no ambient cloud credentials, no shared home directories, no broad filesystem mounts, no default access to source repos or secrets.
2. Default-deny outbound network egress from agent sandboxes; allowlist only required domains, and block metadata endpoints, package mirrors, internal admin panels, and SaaS control planes.
3. Put MCP/tool calls behind a policy gateway: per-tool scopes, per-dataset scopes, human approval for credential access, browser navigation, file upload/download, shell execution, and cross-tenant access.
4. Rotate exposed tokens immediately if an agent touched logs, workspaces, browser profiles, notebooks, CI output, package caches, or eval harnesses.
5. Instrument agent telemetry: record prompts, tool calls, shell commands, browser actions, file reads, outbound destinations, and auth events in a tamper-resistant log.
6. Disable unattended “YOLO” modes for security tools unless they run in a disposable lab with no production reachability.
7. Patch and isolate package proxies/artifact systems such as Artifactory, because this case shows package/cache infrastructure can become the agent’s escape route.
8. Scan for secrets in files and configs, aligning with MITRE’s guidance on credentials stored in files: audit, restrict permissions, and eliminate plaintext secret storage.

My bottom line: the urgent risk is not that models “go rogue.” It is that organizations are giving probabilistic planners shell access, browsers, connectors, credentials, and network paths without the controls we already learned to apply to CI/CD and red-team infrastructure.

Marcus, look across Cisco FMC static credentials, Microsoft OAuth consent phishing, ShinyHunters SaaS/SSO pivots, Bank of Baroda email compromise, PennKey SSO breach, and AI-agent token exposure. What is the identity failure pattern today? Give a concrete containment sequence: session revocation, token/app-consent cleanup, credential rotation, trust-artifact review, and where teams commonly stop too early.

The pattern is not “password theft.” It is attacker-held trust surviving the first fix. The Microsoft case is the cleanest sourced example here: OAuth consent phishing gave an attacker-controlled app access to Microsoft 365 data, meaning the durable object is the OAuth grant/service principal relationship, not just a user password. For Cisco FMC static credentials, ShinyHunters SaaS/SSO pivots, Bank of Baroda, PennKey, and AI-agent token exposure, I don’t have source-grounded incident specifics in the evidence here, so I’ll treat them as identity failure classes: static/shared secrets, SaaS federation pivots, mailbox/session compromise, SSO session abuse, and exposed bearer/API tokens.

Concrete containment sequence:

1. Stop new trust creation first. Freeze user OAuth consent, require admin consent workflow, block unverified publishers, disable risky flows like Device Code Flow where not needed, and pause new SaaS integrations/AI-agent connectors.
2. Revoke sessions before rotating passwords. Kill IdP sessions, refresh tokens, SaaS sessions, mailbox sessions, VPN sessions, and device trust where applicable. A password reset without refresh-token/session revocation is theater.
3. Clean OAuth/app consent. Enumerate service principals, enterprise apps, delegated grants, application permissions, SCIM tokens, mailbox delegates, inbox rules, and third-party SaaS connectors. Remove malicious grants and over-broad scopes.
4. Rotate credentials and secrets. Only after revocation: rotate user passwords, static product credentials, API keys, AI-agent tokens, OAuth client secrets/certs, service-account credentials, and any hard-coded/shared admin secrets.
5. Review trust artifacts. Check SAML signing certs, OIDC client registrations, conditional-access exclusions, recovery codes, MFA device enrollments, passkeys, RMM enrollment, SaaS session cookies, and workload identity federation policies.

Where teams stop too early: they reset the password, disable the user, or remove one suspicious app — but leave refresh tokens, OAuth grants, SaaS-specific sessions, mailbox persistence, API keys, or AI-agent bearer tokens alive. My bias is obvious, but this is exactly why phishing-resistant auth matters: WebAuthn/passkeys for humans, short-lived workload identity for machines, and no long-lived bearer tokens sitting in agent configs.

Sara, take the Minnesota water case as an OT safety problem, not a headline. Source pack says alleged CyberAv3ngers access hit 30+ water/wastewater systems through Rockwell Logix PLC authentication-bypass weakness, with manual operations or contingency plans and drinking water reportedly safe; Virginia/CISA guidance also warns Iranian-affiliated PLC targeting across Rockwell, Schneider, and Siemens, including malicious project-file interactions and HMI/SCADA display manipulation. What should a small water utility do in the next 24 hours if it has internet-connected PLC/HMI/SCADA exposure? Be explicit about isolation, manual mode, engineering workstation checks, reusable code modules, project files, and what not to touch before evidence is preserved.

Sara: I would treat the first 24 hours as safe continuity plus evidence preservation, not a “patch everything now” drill. If a small water utility has internet-connected PLC/HMI/SCADA exposure, the immediate physical question is: can operators still verify pump status, tank levels, pressure, dosing, and alarms from trusted local indicators if the screen is lying? CISA’s AA26-097A says Iranian-affiliated actors targeted internet-facing OT devices, including Rockwell/Allen-Bradley PLCs, and interacted with project files, Add-On Instructions, and HMI/SCADA displayed data. Rockwell’s advisory for CVE-2021-22681 says exploitation could let a remote unauthenticated attacker connect to Logix controllers and potentially change controller configuration or application code.

In the next 24 hours, I’d do this in order:

1. Isolate external command paths, not the whole plant blindly. Remove direct internet exposure to PLCs, HMIs, SCADA servers, engineering workstations, vendor remote access, and cellular/VPN modems. Preserve local operator visibility and historian/telemetry needed for safe operation. Do not make untested firewall or VLAN changes that could break PLC-to-HMI, PLC-to-I/O, or alarm paths.

1. Move to controlled local/manual operation where needed. If operators cannot trust HMI/SCADA values, verify critical process state locally: pump run status, valve position, chemical feed, reservoir/tank levels, pressure, and alarms. Manual mode should be documented shift-by-shift; don’t leave one operator improvising from a notebook.

1. Freeze engineering changes. No downloads to PLCs, no “quick restore,” no online edits, no firmware updates, and no project-file cleanup until evidence is preserved. CISA specifically warns about malicious project-file interaction and AOI logic modification/deletion, so the project file itself is evidence.

1. Preserve and compare project files safely. Pull known-good offline backups from write-protected media if available. Hash and copy current PLC/HMI/SCADA project files, controller programs, AOIs/reusable code modules, tag databases, alarm configurations, and HMI screens before comparing. Look especially for changed AOIs, disabled interlocks, altered alarm thresholds, manipulated displayed values, and unexpected logic around pumps, dosing, or shutdown permissives.

1. Check engineering workstations as likely bridges. Disconnect them from external networks, preserve logs and recent project files, review use of vendor tools, recent downloads/uploads, USB activity, remote sessions, and unknown executables. Don’t wipe or rebuild them before forensic capture.

1. Credential and access containment. Disable exposed remote access accounts, rotate vendor/engineering credentials from a clean system, and review PLC/HMI authentication where supported. Rockwell’s advisory indicates the Logix weakness can allow non-Rockwell/unauthorized connection behavior, so credentials alone are not enough if the controller remains reachable.

The big “do not touch” list: don’t mass reboot PLCs, don’t push firmware during an incident shift, don’t restore yesterday’s project into a live controller without process validation, don’t delete suspicious files, don’t clear logs, and don’t sever networks in a way that blinds operators. In water, a false trip can interrupt service; a missed alarm or manipulated display can affect treatment safety. The first day is about making the plant locally observable, cutting hostile remote reach, and preserving enough truth to know whether the controller logic and operator screens still match the physical process.

James, listen across the source pack and turn it into a 24-hour defensive sequence for a CISO. Must include active-exploitation priorities: Arista VeloCloud Orchestrator CVE-2026-16812, Cisco FMC CVE-2026-20316 plus CVE-2026-20079, Oracle PeopleTools CVE-2026-35273 webshell uploads, Check Point SmartConsole CVE-2026-16232, Laundry Bear/TA488 webmail exploitation, and WordPress WP2Shell. What gets isolated before patched, what gets hunted, and what gets relegated to normal patch cadence?

Halil, for the first 24 hours I’d run this as an exposed-management-plane incident, not a normal patch push. First hour: isolate or strictly ACL any internet-reachable Arista VeloCloud Orchestrator CVE-2026-16812, Cisco FMC CVE-2026-20316/CVE-2026-20079, Oracle PeopleTools CVE-2026-35273, and Check Point SmartConsole CVE-2026-16232 before patching. If those systems are exposed, assume credential or session compromise until logs prove otherwise. For PeopleTools specifically, the visible evidence points to exploited RCE and webshell risk, so freeze the host state, collect web/app logs, file-system timestamps, and hunt for unexpected uploads before rebooting or overwriting evidence.

Today’s hunt order: PeopleTools webshell uploads first; Cisco FMC static-credential/management access second; Arista/VeloCloud command-injection follow-on activity third; Check Point SmartConsole admin/session misuse fourth. For Laundry Bear/TA488 webmail exploitation and WordPress WP2Shell, I would not let them wait for routine IT patching: webmail gets immediate mailbox-rule, OAuth/session, proxy, and webserver-log hunting; WordPress gets perimeter restriction, plugin/theme inventory, suspicious PHP upload checks, and WAF containment. I do not have current advisory or patch-version detail visible here for Check Point, TA488/Laundry Bear, or WP2Shell, so I would not invent detection signatures; use high-fidelity hunts around new admin creation, suspicious uploads, webshell-like PHP/JSP/ASPX writes, abnormal outbound callbacks, and authentication anomalies.

Normal cadence: only non-exposed instances with compensating access controls, no suspicious logs, and clean EDR/webroot review should move to staged patching this week. Everything internet-facing or showing exploitation indicators stays in the emergency lane: isolate first, preserve evidence, hunt, rotate exposed secrets, then patch through staging before restoring access.

Tomas, give the supply-chain trust read. We have AsyncAPI npm releases with Miasma malware tied to GitHub Actions pullrequesttarget secrets exposure, DPRK-linked SAPPHIRE SLEET compromises of maintainers and packages including axios/debug/chalk/typo-crypto, Joyfill malicious beta releases, a WordPress plugin backdoor CVE-2026-18072, JetBrains TeamCity unauthenticated RCE CVE-2026-63077, and new CISA SBOM guidance. What should engineering leaders do today beyond deleting bad packages? Where are CI tokens, publish rights, signed provenance, and build-system credentials at risk?

Engineering leaders should treat this as a publish-and-build trust failure, not just a “delete the bad version” problem. For AsyncAPI, the visible evidence says attackers abused a GitHub Actions workflow, obtained an npm publishing token, and published trojanized releases of trusted packages with roughly 2.9M weekly downloads; the malicious code could execute on import and fetch a second stage. That means the blast radius includes developer laptops, CI jobs, generated docs, build containers, package caches, and any downstream artifact built while the bad versions were present.

Today I’d do four things. First: freeze releases from affected repos and rotate every CI, npm, GitHub, cloud, signing, and deployment token that could have been reachable from those workflows. Second: audit publish rights—human maintainers, bot accounts, npm automation tokens, GitHub Actions environments, and any beta/dist-tag channel like the Joyfill case, which is described as a RAT and developer credential stealer. Third: rebuild critical artifacts from clean runners using pinned dependency hashes or lockfiles, then compare provenance; if you cannot prove what source and workflow produced an artifact, don’t promote it. Fourth: search SBOMs and lockfiles for direct and transitive exposure, not just top-level dependencies.

On TeamCity, I would be even more conservative: the evidence describes CVE-2026-63077 as a patched unauthenticated RCE in TeamCity On-Premises. A compromised build server can hold package registry tokens, cloud deploy keys, signing material, and downstream customer artifacts. Patch is step one; credential rotation, runner rebuild, artifact re-signing review, and provenance invalidation are the real containment steps. For the WordPress plugin backdoor, treat the plugin update channel as the failed distribution path and check whether any admin credentials, API keys, or deployment secrets were present on affected sites.

CISA’s updated SBOM guidance is the governance hook here: leaders should require SBOMs that are actually usable in incident response—component name, version, supplier, dependency relationship, and where the component was built or deployed. My rule: no unsigned provenance, no privileged publish token in general CI, no unreviewed pull_request_target-style workflow with secrets, and no maintainer or bot account publishing without MFA and scoped tokens.

Pierre, translate the day into board-level operational exposure. Compare the decision impact of: Minnesota water OT disruption, Arista/Cisco/Check Point management-plane compromise, AI-agent trust-boundary failures, Bank of Baroda/PennKey/Suno/DentaQuest privacy incidents, ransomware affecting healthcare and food production, and the npm supply-chain wave. Give a ranked top five by likely business disruption and name which items should be quick hits rather than board agenda.

From a board seat, I would not treat these as equal cyber items. The top operational-risk stack is:

1. Ransomware in healthcare and food production — highest likely business disruption: care delivery or production stoppage, spoilage, delayed shipments, contract penalties, and regulator attention. Board agenda.
2. Arista/Cisco/Check Point management-plane compromise — if network management is compromised, this becomes estate-wide control risk, not a device-ticket issue. Best case: emergency config review; worst case: forced network segmentation/outage. Board agenda.
3. Minnesota water OT disruption — the public framing is alleged access to 30+ Minnesota water systems via a Rockwell Logix authentication-bypass weakness, without public attribution. This is lower revenue scale than national healthcare/food, but higher public-safety and continuity sensitivity. Board agenda for utilities/municipal operators.
4. npm supply-chain wave — business impact depends on whether malicious packages reached build pipelines or production artifacts. For software vendors and SaaS firms, this can become customer-trust and recall exposure. Board agenda only if production builds are affected; otherwise rapid engineering action.
5. AI-agent trust-boundary failures — serious, but board-level only where agents can approve payments, change code, access customer data, or trigger production workflows. Otherwise this is a governance quick hit: restrict tool permissions, logging, and approval gates.

The quick hits, unless materiality is proven, are the Bank of Baroda / PennKey / Suno / DentaQuest privacy incidents and most AI-agent control gaps. They belong with legal, privacy, and security leadership first: notification, customer impact, contractual exposure, and access review. They become board agenda only if Sofia sees statutory notification or penalty exposure, or if James says remediation requires service interruption. My board message: spend meeting time on things that stop operations or create systemic supplier/customer exposure; handle standalone privacy notices and AI guardrails fast, but don’t let them crowd out OT, ransomware, network-management, and build-chain risk.

Claim: You ranked ransomware in healthcare and food production as the highest board-level disruption risk today. Counter-evidence: Alex and James both put exposed management/control planes first for same-day action: Arista VeloCloud Orchestrator CVE-2026-16812 has unauthenticated OS command injection with confirmed exploitation; Cisco FMC CVE-2026-20316/CVE-2026-20079 and Check Point SmartConsole sit at the center of firewall and policy administration. The source pack also leads with Minnesota water/OT disruption, not ransomware volume. Reconcile your ranking: are you ranking by realized business outage, by likelihood over the next 24 hours, or by blast radius if compromise is confirmed? Give the board a revised decision frame, not a generic risk list.

You’re right to challenge it: I mixed two lenses. If we are ranking by realized outage cost after an event lands, ransomware in healthcare and food production can be the biggest P&L hit. But if the board question is what needs same-day authority and interruption approval, Alex and James are right: exposed management/control planes move to number one.

My revised decision frame is:

1. Arista/Cisco/Check Point management/control plane compromise — #1 for next-24-hour action and blast radius if confirmed. Arista VeloCloud Orchestrator CVE-2026-16812 is reported as actively exploited unauthenticated command injection; Check Point SmartConsole is also in the exploited-vulnerability lane; and Cisco FMC / firewall policy administration is the kind of control layer that can turn one admin-plane compromise into multi-site disruption. Board decision: authorize emergency exposure reduction, change freezes, admin-plane isolation, and possible service windows today.

1. Minnesota water OT disruption — #1 for public-safety sensitivity, #2 for enterprise-style business disruption. The visible operational fact pattern is more than 30 Minnesota community water utilities disrupted, contingency/manual operations, and one utility briefly offline. It is not the largest revenue event on the table, but it is a board-level continuity and public-trust issue for utilities and municipal operators.

1. Ransomware in healthcare and food production — #1 for realized outage economics once encryption or operational stoppage is underway, but not automatically #1 for today’s preventive action. Hospitals and food producers face care delays, production downtime, spoilage, and shipment penalties. Board agenda if there is active intrusion, outage, or sector peer exposure; otherwise it is executive readiness, not the first emergency change item.

1. npm supply-chain wave — board-level only if malicious packages reached CI/CD, release artifacts, or customer-delivered software. If it is still dependency triage, this is a rapid engineering and supplier-assurance burn-down, not a full board meeting.

1. AI-agent trust-boundary failures — serious, but board-level only where agents can approve payments, alter production code, access customer data, or trigger operational workflows. Otherwise this is a governance quick hit: permission reduction, logging, human approval gates.

The quick hits are the Bank of Baroda / PennKey / Suno / DentaQuest privacy incidents, unless Sofia identifies material notification or penalty exposure, and most AI-agent control gaps unless they have operational authority. So the clean board answer is: same-day authority goes first to management/control planes, then Minnesota OT continuity, then active ransomware operations. Privacy, AI governance, and npm stay below the board line unless they cross into production, regulated data, or customer-impact materiality.

Alex, pressure-test Cisco FMC specifically before we close. Your first ranking put exposed VeloCloud first because the exploit path is clean unauthenticated command injection. For Cisco FMC CVE-2026-20316 static credentials and CVE-2026-20079 authentication bypass, what would make you treat an exposed FMC as assume-compromise rather than emergency-patch-and-monitor? Give the exact exposure/telemetry thresholds and the minimum hunt artifacts a team should preserve tonight.

Halil, for Cisco FMC, I would not use the same trigger as VeloCloud. VeloCloud is clean unauth command injection. FMC is more “key under the mat”: CVE-2026-20316 is static low-privileged web credentials enabling unauthenticated login, listed as actively exploited/KEV, and Cisco/NVD note it gets worse when chained with other FMC flaws. CVE-2026-20079 is reported as unauthenticated RCE only under specific conditions, so I care about whether the chain is actually present.

My threshold for assume-compromise tonight: exposed FMC web/API management reachable from the internet, partner networks, or broad VPN user ranges and any of these: successful login from unknown infrastructure, low-privileged account activity, failed-then-successful login clusters, unexpected API calls, config reads/exports, policy deployments, user/role changes, backup generation, unusual outbound connections, or evidence the host met the CVE-2026-20079 preconditions. If logs are missing, rotated, or unavailable for the vulnerable exposure window, I’d also assume compromise. No telemetry is not clean telemetry.

Patch-and-monitor is only acceptable if management access was tightly allowlisted, not internet-facing, patched fast, and complete logs show no odd login/API/config/policy activity during the exposure window. Minimum artifacts before rebooting or patching: FMC access/auth logs, web logs, audit/admin activity, config-change and deployment history, backup/export history, active sessions, local users/roles, API tokens, running processes, active network connections, suspicious files, and a safe export/copy of current FMC policy/config state. I checked with James, and he agrees: capture first, then isolate management, patch, rotate credentials/tokens, and verify managed firewall policy integrity.