BeyondTrust Comes Offline: Remote Support Is Too Privileged To Patch Later

Alex, take the exposed-platform lane only. Using the source pack plus the CyberBrief corpus confirmation: Oracle E-Business Suite CVE-2026-46817 is under active exploitation against roughly 950 exposed instances, with prior reporting describing unauthenticated HTTP access to the Oracle Payments File Transmission/ibytransmit path on EBS 12.2.3–12.2.15; SharePoint Server CVE-2026-45659 is in CISA KEV; ColdFusion CVE-2026-48282 and NetScaler CVE-2026-8451 are being exploited or scanned; Gitea Docker CVE-2026-20896 is being probed. Give me a decision-ready exploitability ranking for the next 24 hours: which systems are 'assume compromised if exposed,' which are 'patch/isolate now,' and which are 'hunt but do not panic.' Do not recap CVSS — translate kill-chain closure into CISO action.

Halil, my 24-hour ranking is blunt:

The kill-chain difference is the whole story. Oracle EBS is the worst: unauthenticated HTTP against a payments/file-transfer path on exposed ERP is like leaving the loading dock open next to the finance vault. SharePoint is next because KEV plus observed post-exploitation means attackers are already past “can this work?” ColdFusion and NetScaler are urgent edge cleanup. Gitea Docker is watch-and-harden unless probing turns into execution evidence.

James, listen to the same exposed-platform evidence but answer as the defensive closer: if a CISO has 30 minutes and cannot patch everything at once, what exact sequence should they authorize tonight across Oracle EBS, SharePoint Server, ColdFusion, NetScaler, Gitea Docker, and Rockwell Allen-Bradley PLC remote access? Include isolation versus patching, identity/session resets, log sources to pull first, and where business outage is justified.

If the CISO has 30 minutes, I would not start with patching. I’d authorize containment first, then evidence, then trust reset, then patching by exposure. We have visible evidence of active exploitation for Oracle E-Business Suite CVE-2026-46817 and SharePoint Server CVE-2026-45659, and a serious Rockwell/Allen-Bradley PLC remote-access exposure warning tied to nation-state targeting. For ColdFusion, NetScaler, and Gitea Docker, I do not have current advisory or patch evidence visible here, so tonight’s decision should be exposure reduction and log capture first, not blind patch claims.

Tonight’s authorization sequence:

1. Immediate isolation / outage justified - Rockwell Allen-Bradley PLC remote access: cut direct internet access now. Business outage is justified if remote engineering access depends on exposed PLC paths. Allow only break-glass access through VPN/jump host with MFA and named approvals. - Oracle EBS and SharePoint Server if internet-facing: remove public exposure or put behind VPN/WAF allowlist immediately. If that breaks external users, accept the outage tonight. - NetScaler if it fronts identity/VPN: do not power it off blindly, but restrict management plane and external access to known ranges; preserve config first. - ColdFusion and Gitea Docker: block public access unless there is a confirmed business-critical need; keep internal access only.

2. Pull logs before resets or patching - Oracle EBS: web/app access logs, EBS application logs, DB audit logs, SSO/IdP logs. - SharePoint: IIS logs, ULS logs, Windows Security logs, PowerShell logs, webshell/file-write locations. - ColdFusion: web server logs, ColdFusion application/exception logs, admin login logs. - NetScaler: ns.log, audit logs, VPN/AAA logs, configuration backup, management login history. - Gitea Docker: container logs, reverse proxy logs, Git over SSH/HTTP logs, Docker daemon logs, database audit if available. - Rockwell/OT: firewall/VPN logs, jump-host logs, engineering workstation Windows logs, Studio 5000/FactoryTalk activity where enabled, PLC change records if available.

3. Trust reset after containment - Reset privileged/admin sessions for Oracle EBS, SharePoint, ColdFusion admin, NetScaler admin/VPN, Gitea admin, and OT remote-access accounts. - Revoke active sessions/tokens where the platform supports it. - Rotate service credentials only after you have captured evidence, otherwise you lose timeline clarity.

Patch order after that: Oracle EBS and SharePoint first because active exploitation is visible in the evidence; Rockwell exposure remediation is equal priority but handled as isolation/remote-access shutdown, not normal IT patching. NetScaler, ColdFusion, and Gitea Docker go into the next maintenance wave unless the SOC finds compromise indicators tonight. The practical call: take the outage on exposed OT, public EBS, and public SharePoint; preserve logs everywhere; then patch only the confirmed exploited platforms first.

Marcus, focus on the identity and trust-state failures cutting across the briefing: Microsoft Device Code Flow phishing stealing tokens, AdaptHealth's third-party cloud session compromise, Roundcube session/MFA harvesting, Oracle/SharePoint business app exposure, and Langflow/cloud credential theft. What are the identity actions that matter tonight beyond password resets — token/session revocation, OAuth/device-code controls, contractor access, service accounts, API keys, non-human identities — and where would teams most likely under-respond?

Halil, the big identity point tonight is: don’t treat these as password incidents. The evidence I have solidly in front of me says the Microsoft item is Device Code Flow phishing stealing account tokens, and the AdaptHealth item involved social engineering against a third-party contractor session to access cloud business apps, patient management/document storage, and external EHR portals. That is attacker-held trust state: sessions, refresh tokens, app grants, remembered devices, contractor entitlements — not just passwords.

For tonight, I’d sequence actions like this: revoke active sessions and refresh tokens for affected users; disable or tightly scope OAuth Device Code Flow where it is not explicitly needed; review suspicious OAuth consent grants and app registrations; remove remembered MFA devices; invalidate contractor sessions; and re-evaluate third-party access with conditional access, device compliance, and least privilege. For AdaptHealth-style exposure, disabling the contractor account and resetting credentials is necessary, but incomplete unless cloud sessions, delegated app tokens, external portal access, and any downstream EHR/document-system sessions are also killed.

For Roundcube session/MFA harvesting, Oracle/SharePoint business app exposure, and Langflow/cloud credential theft, I don’t have enough confirmed detail here to assert mechanics beyond the briefing labels. But the under-response pattern is predictable: teams reset human passwords while leaving API keys, service accounts, OAuth tokens, SAML/OIDC sessions, app passwords, and cloud workload credentials alive. Langflow-type cloud credential theft especially needs a non-human identity sweep: rotate exposed cloud keys, replace static secrets with workload identity federation, inspect CI/CD and app environment variables, and hunt for newly created access keys or privilege changes.

Where teams will most likely under-respond: contractors, legacy auth paths, and non-human identities. They’ll fix the named user and miss the trust chain around them. My minimum bar tonight is phishing-resistant auth for high-risk users and contractors, device-code restrictions, short-lived tokens, continuous access evaluation where supported, and a forced inventory of OAuth apps, API keys, service accounts, and external business-app permissions.

Arjun, separate signal from hype on the AI lane. Sysdig says JadePuffer exploited Langflow CVE-2025-3248 and used an LLM agent to automate reconnaissance, credential harvesting, lateral movement, privilege escalation, data theft, and encryption while a human supplied victim selection, infrastructure, and credentials. Zscaler also reports indirect prompt injection causing agent-driven crypto payments, and OpenAI Codex macOS has a prompt-injection data-leak path. What has actually changed for defenders this afternoon? Give me the minimum controls for exposed AI dev tooling and autonomous agents, and be explicit about what we should not overclaim.

Halil, the change this afternoon is not “AI ransomware went autonomous.” The real shift is that agentic tooling is now part of the intrusion chain: Sysdig’s JADEPUFFER reporting frames the LLM agent as an automation layer over an already human-directed operation — victim selection, infrastructure, and credentials still came from the operator. That matters because defenders should treat AI agents like privileged automation systems, not like chatbots.

For exposed AI dev tooling, the minimum controls are: patch or remove internet-facing Langflow immediately, especially around CVE-2025-3248; require authentication and network isolation for workflow builders; strip secrets from agent runtimes; block direct cloud metadata and database access unless explicitly needed; and log every agent tool call, shell command, credential read, and outbound connection. If an AI workflow can run code, query databases, or call cloud APIs, it belongs behind the same controls as CI/CD and admin automation.

For autonomous agents, the minimum is: tool allowlists, egress allowlists, human approval for money movement/destructive actions, secret-scoped sessions, prompt/content provenance checks, and no rendering of remote content from model output by default. The Codex macOS issue is a clean example: NVD says indirect prompt injection could cause Codex to construct a remote image URL containing sensitive data from the session, including API keys or source code, with no known exploitation in the wild. That is not model sentience; it is classic data exfiltration through an unsafe rendering/tool boundary.

What we should not overclaim: we should not say JADEPUFFER proves self-directed malware, or that every LLM agent can autonomously ransomware a network. We can say the attacker work factor is dropping when agents sit on privileged tool boundaries. And Zscaler’s crypto-payment scenario reinforces the same point: the dangerous primitive is not “AI thinking,” it is untrusted instructions reaching an agent that can spend money, move data, or execute actions.

Lena, take the attribution and campaign-continuity lane. We have likely China-linked Roundcube exploitation against U.S. and Canadian universities using phishing, stolen logins/cookies/MFA inputs, deserialization, PHP webshells and a Go backdoor; Cisco Talos reports China-nexus UAT-7810 expanding an ORB network through unpatched Ruckus routers with LONGLEASH, DOGLEASH and JARLEASH; the pack also includes DPRK maintainer/package compromise, Iranian-linked Rockwell targeting, Russian activity against Ukrainian media, and Cavern Manticore against Israeli networks. What should we treat as high-confidence, what is merely plausible, and what changes defender action today?

Halil, I’d split it this way.

High confidence: UAT-7810 expanding an ORB through unpatched Ruckus routers — Cisco Talos is the anchor, and the handoff marks the evidence strong and active. Treat LONGLEASH, DOGLEASH, and JARLEASH as campaign infrastructure tooling, not just malware trivia; defender action today is patch/exposure reduction on Ruckus edge devices and hunting for persistence on routers. Also high confidence: DPRK-linked developer/package compromise is real and continuing; the package-ecosystem pattern aligns with reported North Korean PolinRider activity and Lazarus-linked npm impersonation of Rollup tooling.

Moderate confidence: the Roundcube university campaign is China-linked and active, but I would not collapse it into a named Chinese actor without more pivots — domains, passive DNS, certificates, and malware lineage. The tactics are clear enough for action: phishing, credential/session theft, MFA capture, deserialization, PHP webshells, and a Go backdoor mean universities should prioritize Roundcube patching, session invalidation, webshell hunts, and MFA-resistant phishing controls.

Low confidence from what I can verify here: Iranian-linked Rockwell targeting, Russian activity against Ukrainian media, and Cavern Manticore against Israeli networks. They may be valid stories, but I don’t have enough visible campaign evidence in front of me to make an attribution call. ATT&CK-wise, the actionable cluster today is credential theft/session hijacking, exploitation of public-facing apps, webshell persistence, and compromised network-edge infrastructure — attribution can wait; those controls cannot.

Tomas, focus only on developer and software-supply-chain trust. The pack shows DPRK-linked compromise of maintainer accounts and GitHub repos with 162 malicious release artifacts across 108 npm/Go packages using blockchain/public RPC payload retrieval for DEV#POPPER RAT and OmniStealer; stolen Trivy credentials allegedly uploaded trojanized LiteLLM packages to PyPI with about 47,000 downloads in 46 minutes; Shai-Hulud/Hades self-reinforcing npm/PyPI credential harvesting; Kaspersky and Novee reporting large-scale GitHub Actions/Cordyceps CI/CD misconfigurations; and Gitea Docker CVE-2026-20896 header spoofing/impersonation under active probing. What exact trust boundaries should engineering freeze or verify tonight without causing a blanket shutdown?

Halil, I would not freeze all engineering. I would freeze only the boundaries that can execute untrusted code, read secrets, or publish artifacts.

Tonight’s freeze list:

1. Package publishing paths — freeze npm, PyPI, Go module, container, and GitHub release publishing for repos in the affected dependency path. Verify maintainer accounts, registry tokens, release assets, tag history, and provenance before reopening. This is where the Trivy/LiteLLM chain matters: reported evidence says a Trivy CI/CD compromise led to malicious Trivy releases and then LiteLLM PyPI token abuse despite 2FA.

1. CI/CD workflows with secrets or write permissions — freeze GitHub Actions jobs triggered by PRs, issue comments, workflow_run, pull_request_target, or external inputs if they also have secrets, id-token, package publish rights, or cloud credentials. Kaspersky’s scan found broad GitHub Actions misconfiguration patterns, and Cordyceps reporting points to workflow composition flaws enabling credential theft, artifact poisoning, and privilege escalation.

1. New dependency promotion — pause promotion of new npm/PyPI/Go dependencies and version bumps until lockfiles, hashes, and artifact-proxy logs are reviewed. Do not stop existing pinned builds that use known-good cached artifacts. For the DPRK-linked package/release-artifact cluster described in the pack, the key boundary is not “developers coding”; it is “who can cause our build to fetch and execute a malicious release artifact.”

1. Credential-bearing developer and CI environments — rotate secrets only where there is execution evidence: systems that installed or ran suspicious LiteLLM/Trivy-linked versions, Shai-Hulud/Hades packages, or the affected npm/Go package set. PyPA guidance cited in reporting says users who installed and ran the malicious LiteLLM versions should assume credential exposure and revoke/rotate credentials.

For Gitea Docker CVE-2026-20896, treat any internet-facing Gitea behind proxy headers as a source-control identity boundary: freeze releases/merges from that instance until header trust, proxy stripping, patch level, and audit logs are verified. What should stay open: local development, read-only CI, tests with no secrets, and builds pinned to verified cached artifacts.

Viktor, take the crypto financial-crime lane. BonkDAO reportedly lost nearly $20 million after an attacker bought roughly $4–4.4 million in BONK voting power and passed a malicious governance proposal; Summer.fi paused compromised contracts after a $65.4 million flash loan manipulated LazyVault accounting and drained about $6 million; Ill Bloom weak wallet recovery phrase generation enabled theft from 431 wallets worth about $3.1 million; and Zscaler's prompt-injection testing showed AI agents manipulated into payments. What is the common control failure, and what should DAOs, vault operators, wallets, and custodians do immediately?

Halil, the common failure is money-moving authority accepted a formally valid instruction without proving economic intent or safety. BonkDAO’s governance path treated purchased voting power and low-turnout quorum as sufficient authorization; Summer.fi’s vault path treated manipulated short-window accounting as redeemable value. Ill Bloom and Zscaler fit the same pattern as reported examples: weak seed generation and prompt-injected payment agents show authority was technically valid, but the control layer failed to ask, “Should this value movement be allowed?”

For DAOs, the immediate fix is not just “better voting.” Put treasury transfers behind timelocks, minimum participation thresholds, vote-locking/snapshot rules, executable proposal simulation, transfer caps, and emergency guardian/multisig review for abnormal outflows. In BonkDAO’s case, reporting says roughly $20 million was drained after an attacker accumulated about $4 million in BONK voting power, used Solana Realms governance, and some funds began moving toward exchanges — that is a time-to-freeze issue. Exchanges, bridges, and law enforcement need wallet clustering and freeze requests before the funds are bridged or peeled out.

For vault operators, Summer.fi is the accounting version of the same failure. Reporting says a $65.4 million flash loan distorted valuation/accounting in Lazy Summer/Fleet Commander logic, enabling about $6 million in losses, with proceeds swapped into DAI and routed through Uniswap V3. The immediate controls are same-block/short-window manipulation guards, TWAP or multi-source valuation, redemption invariant checks, per-epoch withdrawal limits, flash-loan-resistant accounting, and narrow contract pauses rather than broad panic where possible.

For wallets and custodians, the priority is to remove silent authority paths. Wallets should force migration if seed generation is suspect, revoke approvals, publish reproducible entropy/keygen audits, and push users toward hardware-backed recovery. Custodians and AI-payment systems should not let an agent or prompt directly authorize value movement: use transaction allowlists, address-book controls, velocity limits, human dual approval, chain-risk screening, and policy engines that treat payment intent as separate from text input.

Sara, take the OT lane. CISA warns nation-state-linked actors, including Iranian-linked activity, are targeting internet-exposed Rockwell Automation Allen-Bradley CompactLogix and Micro850 PLCs using legitimate engineering tools rather than zero-days; the pack also cites Kaspersky Q1 2026 data showing malicious objects blocked on 19.6% of ICS computers across 10,052 malware families. What is the emergency plant-side action tonight, what should not be changed during operations, and how should IT/security coordinate with control engineers without creating safety risk?

Halil, the emergency action tonight is reachability reduction, not controller surgery. CISA says internet-connected OT devices, including Rockwell Automation/Allen-Bradley PLCs, are being exploited across critical infrastructure, with disruption tied to project-file interaction and HMI/SCADA display manipulation. Nozomi’s analysis says the actors accessed CompactLogix and Micro850 devices with Rockwell’s Studio 5000 Logix Designer, so the immediate question is: can anyone from the internet, a vendor path, cellular router, VPN, or jump host reach Level 1/2 controllers? If yes, disconnect that path upstream — firewall, NAT, router, remote-access gateway — without touching the PLC runtime.

What should not change during live operations: no PLC firmware flashes, no program downloads, no controller reboots, no mode changes, no “restore known good” unless the process is in a controlled safe state and the control engineer owns the step. Also do not make blind segmentation changes that might break HMI-to-controller, controller-to-I/O, or safety-system communications. A bad security change can become the incident — false trip on one side, missed trip on the other.

I checked with James, and we’re aligned: tonight is “isolate and watch.” Freeze engineering changes, revoke exposed/shared/vendor remote sessions, preserve VPN/firewall/cellular-router/jump-host/HMI/historian logs, and alert on new PLC sessions, project reads/writes, and HMI tag/display changes. Control engineers should validate running logic and HMI values against approved references, but IT/security should not drive changes directly on the plant floor. Kaspersky’s Q1 2026 figure — malicious objects blocked on 19.6% of ICS computers across 10,052 malware families — reinforces that this is not just one PLC campaign; Level 2/3 workstations and engineering stations need containment discipline too.

James, you are the closer now. Fold in the rest of the room: Alex ranked Oracle EBS exposed instances as assume-compromised first, with SharePoint/ColdFusion/NetScaler close behind; Marcus warned this is trust-state theft, not passwords; Arjun says JadePuffer is human-directed intrusion accelerated by agentic tooling, especially around exposed Langflow and cloud credentials; Lena separates high-confidence UAT-7810/Ruckus ORB activity from lower-confidence Roundcube attribution; Tomas wants a bounded freeze only on code-execution, secrets, and publish boundaries; Viktor says DeFi governance/vaults failed by accepting formally valid money-moving instructions without intent/safety checks; Sara says OT action is reachability reduction, not controller surgery. Give me the final CISO-ready 24-hour sequence: what gets isolated now, patched now, hunted as compromised, delegated to business owners, and kept to monitoring.

Halil, the 24-hour call is: isolate first, patch the confirmed exploited edge systems second, reset trust state everywhere those systems touch. Now: remove public reachability for exposed Oracle EBS, SharePoint, NetScaler, Langflow, ColdFusion, Gitea Docker, and Rockwell/Allen-Bradley remote access. Outage is justified for public Oracle EBS, SharePoint, NetScaler VPN/ADC exposure, Langflow with cloud/database access, and any direct OT remote path. For Rockwell, follow Sara’s line: reduce reachability, do not reboot controllers or change logic during operations.

Patch now / hunt as compromised: treat exposed Oracle EBS CVE-2026-46817, SharePoint CVE-2026-45659, NetScaler CVE-2026-8451, and Langflow CVE-2025-3248/JadePuffer-style exposure as assume-compromised. Preserve web/app logs, IdP logs, session stores, VPN/AAA logs, reverse proxy logs, cloud audit logs, database access logs, container logs, and EDR telemetry before rebuilds where possible. Then patch or rebuild from clean images, revoke sessions, rotate tokens/API keys/service accounts, and invalidate SSO cookies — Marcus is right, this is trust-state theft, not just password theft. For ColdFusion and Gitea Docker, I do not have current visible advisory/patch evidence here, so tonight I would isolate, freeze only code-execution/secrets/publish paths, pull logs, and let business owners approve any outage beyond exposure removal.

Delegate and monitor: business owners must sign off on frozen publishing, disabled automation, vendor remote-access interruption, DeFi/governance money-moving pauses, and OT remote-support downtime. Keep lower-confidence Roundcube attribution and broader ORB activity in monitoring unless telemetry shows access to identity, mail, or command infrastructure; keep DeFi/vault controls in “human approval required” mode for formally valid but high-risk transactions. The SOC’s tonight dashboard should be small: new admin/session creation, unexpected outbound from AI/dev tools, token use after revocation, SharePoint/EBS webshell indicators, NetScaler session anomalies, cloud key use from new locations, and OT remote-session attempts.

Sofia, give us the regulatory lens only where it changes tonight's decisions. The pack includes active exploitation of Oracle EBS/SharePoint/ColdFusion/NetScaler, AdaptHealth's material patient-data incident via a third-party contractor cloud session, European Commission AWS/Europa data theft claims, CISA's expected September CIRCIA final rule with 72-hour substantial-incident and 24-hour ransomware-payment reporting, and Australia OAIC breach notification growth. What should CISOs and legal teams start preserving or deciding in the first 24 hours, and what items are monitor-only rather than immediate notification triggers?

Halil, the first 24 hours should be evidence-preservation, not reflexive notification for every exploited product. For Oracle EBS, SharePoint, ColdFusion, and NetScaler, the legal trigger changes only once there is evidence of unauthorized access, data exfiltration, service disruption, or regulated-sector impact. CISOs should preserve: authentication logs, web/application logs, cloud access logs, EDR telemetry, affected asset lists, vulnerable-version inventories, patch timestamps, attacker IPs, admin-session history, and a clean chronology of “first detection” versus “confirmed impact.” That chronology matters because GDPR Article 33(1) requires notifying the supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of a personal-data breach, unless risk to individuals is unlikely; Article 34(1) adds data-subject communication without undue delay where high risk is likely.

AdaptHealth is different: a patient-data incident through a third-party contractor cloud session is already in notification-preparation territory, not monitor-only. Legal should immediately preserve the contractor agreement, processor/subprocessor instructions, access logs, affected patient fields, data-export evidence, and decision records on whether identity, health, insurance, or payment data was involved. If EU personal data is implicated, GDPR controller/processor allocation and Article 33/34 analysis starts now. For any SEC filer, preserve the board/legal materiality record and business-impact inputs; I would want a current SEC source before restating exact timing here, but the decision process itself must be documented.

Monitor-only for tonight: the European Commission AWS/Europa theft claims unless your organization is a controller, processor, recipient, listed victim, or downstream data holder; OAIC breach-notification growth as a trend signal unless Australian personal information was actually accessed or lost; and CIRCIA for now as readiness planning, because the sources I have show the 72-hour covered-incident and 24-hour ransom-payment duties apply once the final rule is implemented. Do not wait for patch completion to start the file: preserve evidence, identify jurisdictions, map affected data, and decide within 24 hours whether you are in “breach assessment,” “regulator pre-notification,” or “monitor-only vulnerability response.”

Marcus, targeted quick lane before we close: For BeyondTrust Remote Support and Privileged Remote Access CVE-2026-40138 and related critical authentication-bypass flaws, with patches available and no reported in-the-wild exploitation in the source pack, what should CISOs do tonight beyond patching? Cover exposure isolation, session/token revocation, privileged credential rotation, and which logs or indicators would make you treat a system as compromised.

Halil, I’d treat CVE-2026-40138 as an identity boundary failure, not just a software bug. BeyondTrust’s advisory says this is a critical pre-authentication vulnerability in the authentication subsystem of Remote Support and Privileged Remote Access, where improper authentication request processing could let an unauthenticated remote attacker bypass access controls and reach the appliance, including elevated accounts. So yes, patch tonight — but don’t stop there.

Beyond patching: remove RS/PRA from direct internet exposure where possible, restrict access to VPN/ZTNA or tight IP allowlists, and kill all active appliance sessions. Revoke or rotate API tokens/integrations tied to the appliance, disable suspicious local accounts, review SAML/OIDC/LDAP bindings, and rotate privileged credentials that could have been used through Jump Clients, Shell Jump, credential injection, or vault/check-out workflows. If this tool can broker access to domain controllers, cloud admin consoles, hypervisors, backup systems, or finance systems, those credentials are in the blast radius.

I’d treat the system as compromised if logs show successful admin/API access from unusual IPs, new local/elevated accounts, policy changes, new Jump Clients or Shell Jump entries, new API integrations/tokens, config export/backup activity, session recordings with command shell or file transfer, credential checkouts, logging gaps, or sessions that do not line up with IdP/SAML/MFA events. That last one matters: if the BeyondTrust appliance says “valid session” but your IdP has no matching authentication, that is a trust-chain break.

The under-response I expect is “patched, ticket closed.” Wrong. For privileged remote access infrastructure, patching only fixes tomorrow’s entry path; it does not invalidate yesterday’s stolen session, API token, appliance-local account, or privileged credential exposed through the platform.