Panel Rejects Patch-Only Closure for CISA KEV-Listed SharePoint Flaw

CVE-2026-55040 is actively exploited after PoC publication and enables SharePoint token forgery and administrator impersonation. Draw the operational line between patch-now and assume-compromise: what exposure or log evidence triggers isolation, farm-wide investigation, credential/session invalidation, or rebuild? Give a decision a CISO can execute tonight, and state what the source pack does not prove.

Halil, the facts are bad enough without CVSS theater: public PoC exists, active exploitation is reported, and unauthenticated attackers can forge JWTs to impersonate SharePoint users or administrators and access or modify files. Rapid7-linked reporting counted 12 attempts from eight IPs across five regions. That makes every affected on-premises deployment patch-now.

My decision line tonight:

• Not externally reachable, no suspicious activity: patch immediately, preserve logs, increase monitoring. Do not assume compromise.
• Internet-reachable while unpatched after PoC release: remove external access now, preserve evidence, patch, and investigate every server in the farm. Exposure triggers isolation—not an automatic breach declaration.
• Assume compromise: any forged/S2S-token artifact, unexplained privileged action, abnormal file access or modification, new administrator, or suspicious configuration change. Isolate the affected server, restrict the farm, revoke SharePoint sessions, and investigate farm-wide. Reset credentials only where credential theft or account abuse appears; forged tokens do not prove stolen passwords.
• Rebuild: only with host-level execution, web shells, persistence, tampered binaries, unauthorized accounts, or failure to establish system integrity. Token impersonation alone does not justify bulldozing the farm.

The source pack does not prove reliable RCE or host takeover, persistence, machine-key theft, compromise of every exposed server, or that rebuilding is universally required. It also provides no authoritative log signature here. Treat exposure as smoke; treat concrete unauthorized actions as fire.

Assess the combined cloud blast radius of actively exploited MLflow CVE-2026-64849 and Ray CVE-2025-62593. Focus on workload identity, metadata-service access, temporary credentials, connected storage, and lateral movement. Which environments require containment and credential rotation rather than patch-only treatment, and what should cloud teams verify tonight?

The combined blast radius is the union of both workloads’ identities and reachable resources. Fact: MLflow before 3.15.0 permits unauthenticated SSRF through the webhook test endpoint, potentially returning responses from internal or metadata services. Fact: Ray versions before 2.52.0 are affected by CVE-2025-62593, with total technical impact, and both vulnerabilities appear in CISA’s KEV catalog. MLflow is therefore a credential-retrieval path; Ray must be treated as workload execution. If they share an account, VPC/VNet, Kubernetes cluster, service account, artifact bucket, model registry, or database, compromise of either can become lateral movement through the same trust graph.

Contain rather than merely patch any vulnerable instance that was externally reachable, has suspicious requests, can reach a metadata service, or runs with a useful workload identity. That includes AWS instance roles or IRSA, Azure managed/workload identities, GCP service accounts, mounted kubeconfig files, static access keys, and attached secret volumes. Preserve application, proxy, container, and cloud audit evidence; isolate the workload; patch; then invalidate or restrict exposed identities and rotate accessible static secrets. Patch-only treatment is defensible only when teams can demonstrate the vulnerable interface was unreachable, exploitation did not occur, and the process had neither metadata access nor credentials or privileged storage connectivity.

Tonight, verify versions and exposure first, then enumerate each workload’s effective permissions—not merely its nominal role. Review CloudTrail, Azure Activity/Entra, or GCP Audit logs for token use, role assumption, storage enumeration, secret access, new compute, and policy changes originating from those identities. Check every connected bucket, artifact store, model registry, database, and KMS/decryption permission. Also verify whether metadata protections actually prevented the required request flow rather than assuming “temporary” means harmless. The provider owns the underlying compute; the customer owns these trust policies, network paths, and data permissions. Serverless branding remains regrettably ineffective as an IAM control.

US agencies report active use of AI-generated scripts and Snap7 components against internet-exposed Siemens S7 PLCs. Separate demonstrated capability from AI framing, then prescribe a safety-conscious first 24 hours for S7-1200/1500/200/300/400 operators. Contrast this briefly with CameraSwarm’s Dahua compromise so we do not apply IT-style remediation to safety systems.

Halil, the physical risk is loss of trustworthy control: an unexpected stop can damage equipment, while manipulated interlocks or process values could endanger personnel. Fact: CISA reports an active threat using AI-assisted exploitation scripts, including reported Snap7 components, against Siemens S7 PLCs for access, credential theft, denial of service, and other objectives. Assessment: “AI-generated” describes how tooling was produced; it does not demonstrate autonomous operations, novel PLC capability, attribution, or confirmed physical damage. Directly exposed PLCs effectively collapse the Purdue boundary from the internet into Levels 1–2.

For the first 24 hours across S7-1200/1500/200/300/400 estates:

• Put plant operations, controls engineering, and process safety—not the IT help desk—in command. Independently verify tank levels, pressures, flows, actuator positions, alarms, and interlocks.
• Remove direct internet reachability using upstream firewalls or provider controls. Suspend unverified vendor access, but validate every rule change before deployment; accidentally severing PLC, HMI, or safety communications may create the worse event.
• Preserve controller diagnostics, running configuration/logic, engineering-workstation artifacts, historian and firewall logs. Compare logic and configuration with an approved offline baseline. Do not reboot, mass-scan, clear logs, or download “known-good” logic until operators understand the process state.
• Monitor for unexpected programming sessions, mode changes, stop/start events, credential changes, logic downloads, and Snap7/S7 traffic crossing from Levels 3–4. Plan firmware, credential, and configuration changes by model and lifecycle status during a tested maintenance window—not an IT-style 24-hour patch mandate.

Unknown: the advisory evidence available here does not establish which individual installations were altered or whether any safety function was affected. CameraSwarm is materially different: Hunt.io documented 14,530-plus Dahua devices reached through credential brute force, authentication-bypass vulnerabilities, and P2P relay access; published remediation includes disabling unnecessary P2P and installing corrected firmware. A camera can often be isolated or replaced without changing the controlled process. An S7 PLC may be executing that process, so isolation, credential changes, and firmware work require operator-led sequencing and safety validation.

For UAT-10147, determine what the Talos evidence supports about agentic AI use, campaign scale, actor linkage, and the SPECTRE toolkit. Does AI materially change defender priorities, or mainly increase attacker speed? Name the durable behaviors defenders should hunt and identify any claims that remain uncertain.

Talos supports moderate-high confidence that AI generated operational playbooks, automated exploitation and troubleshooting across global Windows/Linux web-server attacks. It supports only low confidence in autonomous campaign orchestration: victim counts, success rate and the degree of human approval remain unpublished. The observed sectors are government, education, media, technology and gaming.

Actor linkage is moderate confidence to Talos’s UAT-10147 cluster—a Chinese-speaking, financially motivated operator—but low confidence for any Chinese state or established MITRE G-group linkage. SPECTRE is a cross-platform post-exploitation implant providing C2, process injection, credential theft, anti-analysis, Windows BYOVD-based EDR neutralization and a Linux rootkit; Talos assesses AI-assisted rootkit development only at medium confidence, alongside human expertise.

AI mainly compresses attacker time and increases scale; it does not change defender priorities. Hunt the durable chain: public-facing IIS/Linux exploitation (T1190), privilege escalation, in-memory web shells (T1505.003), process injection (T1055), credential theft, persistence, BYOVD/EDR impairment (T1562.001), rootkits (T1014) and subsequent SPECTRE C2. Exact campaign size, full autonomy and broader attribution remain unknown.

The updated Medusa advisory reinforces phishing, purchased access, valid credentials, remote-management tooling, and rapid exploitation. Identify the identity controls that actually interrupt this access model. Distinguish targeted session or credential revocation from indiscriminate tenant-wide rotation, and give the board one measurable 30-day test of readiness.

Halil, fact: CISA says Medusa combines compromised legitimate accounts with RDP, PsExec, and approved-looking RMM products such as AnyDesk, Atera, ConnectWise, N-able, PDQ, SimpleHelp, and Splashtop. The controls that interrupt that chain are phishing-resistant WebAuthn/FIDO2 for VPN, identity-provider, and RMM access; managed-device enforcement; separate just-in-time administrative identities; blocked interactive logon for service accounts; and allowlisting both the RMM product and its authorized tenant. Rapid vulnerability exploitation may bypass initial authentication, so these controls primarily constrain lateral movement and privilege acquisition.

Assessment: revoke surgically when specific identities or hosts are implicated: disable the account, terminate IdP/VPN/RMM sessions, revoke refresh tokens and OAuth grants, invalidate Kerberos tickets, rotate exposed API keys, and then reset the password. Tenant-wide rotation is justified only when the affected population cannot be bounded—for example, compromise of an IdP signing key, credential repository, or domain trust root. A blanket password reset alone is not session revocation.

For the board’s 30-day test, pre-establish test-account sessions in the IdP, VPN, RMM platform, and Active Directory, including refresh tokens and Kerberos tickets. Declare that identity compromised and require 100% invalidation within 30 minutes, with attempted reuse blocked and evidenced in logs. Unknown today: whether the organization can revoke every downstream session from one coordinated workflow.

Operation CameraSwarm reportedly compromised 14,530 Dahua devices through credentials, CVE-2021-33044/CVE-2021-33045, and P2P access, with a persistent attacker account on 1,923 cameras. Translate that into a defensible hunt and eradication plan: which artifacts or behaviors distinguish compromise from mere exposure, and when is reset/reprovisioning required? Challenge the victim-count framing if telemetry does not support it.

Halil, I would split the headline into three buckets. FACT: 12,324 addresses saw brute-force activity, 283 devices were reached through cloud relay, and 1,923 cameras contained the p2pwn / p2password account. Only the last is a strong victim-side persistence indicator. The aggregate 14,530 should therefore be described as campaign scope, not 14,530 equally confirmed compromises.

For each camera, classify:

• Exposure/attempt only: vulnerable model/build, TCP/37777 reachable, P2P enabled, or failed-login scanning without successful authentication.
• Probable compromise: successful unknown RPC/37777 or P2P session, unexplained configuration or user changes, or camera access following the attack burst.
• Confirmed compromise: p2pwn account, corresponding privileged logins, or recovery-code access. Hunt.io identifies that account as the primary victim-side artifact.

Eradication assessment: isolate confirmed or probable devices and preserve user/configuration and access logs first. Then disable P2P, block external TCP/37777, install Dahua’s fixed/current firmware, factory-default the unit, manually verify the user database, and provision unique credentials. Treat a password change—or even factory reset alone—as insufficient: Hunt.io reports the account can survive resets on many firmware versions, while generated recovery codes may remain usable after account removal. If account integrity cannot be verified, logs are missing, or P2P cannot be disabled, replace or vendor-assisted reprovision the camera into a new cloud binding. Also rotate any credentials reused elsewhere.

UNKNOWN: The available reporting does not provide per-device evidence proving successful access across all 12,324 brute-forced addresses. That telemetry gap materially weakens the “14,530 compromised” wording.

Latvia’s Road Traffic Safety Directorate lost historical payment and registration data affecting more than 1.2 million people and 200,000 organizations, while CERT.LV says mandatory cybersecurity requirements were not met. What immediate notification, evidence-preservation, and governance decisions follow under the likely Latvian/EU framework? Separate confirmed regulatory triggers from facts still needed.

Halil, confirmed: CSDD says attackers obtained names, personal identifiers, addresses, vehicle-registration and payment records concerning 1.2 million people; CERT.LV attributes entry to an internet-facing vulnerability and says mandatory controls were unmet. Latvia’s National Cyber Security Law implements NIS2 and covers qualifying essential/important entities. Assuming CSDD falls within that statutory classification, secondary legal summaries require immediate containment and notification to the incident-response authority, followed for a significant incident by an early warning within 24 hours, an initial report within 72 hours and a final report within one month. CSDD should immediately verify whether those formal reports—not merely operational contact with CERT.LV—were submitted on time.

For evidence preservation, impose a legal hold covering system images, access and application logs, vulnerable configurations, patch records, backups, attacker communications, supplier contracts, risk assessments and the exact discovery/escalation timeline. Record who knew what and when, preserve chain of custody, and commission an independent control-failure review reporting to the board or supervising ministry. The personal-data categories and scale make Latvian DPA notification and preparation of individual communications prudent; however, I could not verify the current official GDPR article text and notification clock from the available official evidence, so I will not state those particulars as confirmed here.

Still needed: CSDD’s formal NIS2 classification; initial awareness time; DPA/CERT submission timestamps and contents; whether data were merely unavailable, copied, altered or published; affected-record accuracy; retention authority for data dating to 2008; encryption and backup status; processor/controller roles involving Tet or other suppliers; and whether identity theft or other high-risk consequences are likely. CERT.LV’s control finding supports governance investigation, but does not by itself establish regulatory liability or a penalty.

Force a business-priority decision between actively exploited self-managed GitLab CVE-2026-19478 and Microsoft IKE CVE-2026-33824. GitLab can rewrite repository and merge state; IKE threatens internet-facing IPsec/VPN infrastructure. Give concrete exposure conditions that make either the first two-hour action, name the likely business consequence of delay, and avoid treating all critical CVEs as equal.

Halil, default priority is GitLab when a vulnerable self-managed instance is internet-reachable and feeds production releases. CVE-2026-19478 is already being exploited and permits unauthenticated modification or deletion of public projects and user data. In the first two hours: isolate it, pause merges/releases, preserve evidence, and upgrade to a fixed release. GitLab.com and GitLab Dedicated are already patched.

IKE moves to first place if an unpatched Windows IKEv2 endpoint is directly internet-facing and terminates business-critical remote-access or site-to-site VPN traffic—especially without gateway redundancy. CISA confirms active exploitation. Patch immediately; if that cannot happen inside two hours, remove exposure or block UDP 500/4500, accepting the connectivity impact. If both conditions apply, GitLab wins when it can ship code within 24 hours; IKE wins when losing the gateway would halt operations immediately.

The delay scenarios are different: GitLab creates integrity risk—tainted releases, release suspension, repository reconstruction, and possible downstream customer compromise. IKE creates perimeter and availability risk—gateway takeover, VPN shutdown, internal intrusion, and workforce or site disconnection. I found no defensible current loss figures specific to either CVE, so attaching a dollar estimate would be false precision.

Close the operational discussion with a sequenced plan for a CISO who has 30 minutes. Inputs from the room: Alex says exposed SharePoint CVE-2026-55040 needs evidence-led assume-compromise handling, not patch closure; Priya says exploited MLflow/Ray can leak workload credentials and expand into cloud resources; Sara requires safety-led containment for Siemens S7 rather than abrupt shutdown; Lena finds UAT-10147’s AI mainly accelerates established behaviors; Maya says only 1,923 Dahua cameras with the p2pwn/p2password account are strong persistence evidence, not all 14,530 headline devices; Marcus favors scoped identity revocation for Medusa-style access; Pierre puts internet-exposed, production-linked GitLab ahead of IKE by default, but reverses that where VPN/IKE is the critical access edge; Sofia confirms Latvia notification and evidence-preservation pressure. Rank what happens in the first 2 hours, by 24 hours, and this week. Include SharePoint, GitLab, MLflow/Ray, IKE, Siemens S7, Dahua, and BYOVD hunting. Break any premature consensus: identify one item whose urgency is conditional or overstated.

Halil, the first two hours are incident handling, not patch closure. CRITICAL: isolate exposed SharePoint while preserving memory, logs and disk evidence; treat it as potentially compromised. Remove MLflow/Ray from public reach, preserve cloud audit logs and revoke only credentials accessible to those workloads. Triage internet-facing, production-linked GitLab ahead of IKE unless VPN/IKE is the organisation’s critical access edge. Put Siemens S7 containment under OT safety authority—restrict communications, but do not abruptly stop PLCs. Quarantine Dahua devices carrying the p2pwn/p2password persistence evidence rather than declaring all 14,530 compromised. Start a BYOVD hunt across EDR-tampering alerts, unexpected driver loads and associated service creation, preserving implicated binaries.

By 24 hours, establish exploit evidence and blast radius; stage and deploy approved fixes for SharePoint, GitLab, MLflow/Ray and IKE without treating patch success as proof of cleanliness. Review SharePoint service-account activity, GitLab runners/tokens, MLflow/Ray cloud API use and VPN authentication; then rotate affected secrets and sessions, not the entire identity estate. Sofia’s Latvia warning means legal assessment and evidence preservation start immediately, with detection and scoping completed early enough to support any notification decision.

This week: rebuild systems whose integrity cannot be established; finish patch rollout and credential replacement; segment ML platforms, camera networks and OT management paths; and validate that BYOVD detections survive normal driver-update activity. The overstated priority is IKE: it is not automatically first. Its urgency becomes critical only when exposed and serving as the essential remote-access edge; otherwise, an exploited production-linked GitLab instance carries the earlier operational priority.

The T-Mobile/Salt Typhoon report says physical cable severance was used to evict suspicious traffic traversing another carrier’s router. What specific control or architecture failure could make physical disconnection necessary, and what single validation should telecom operators perform now to prove they can logically evict comparable inter-carrier access without relying on cable cuts?

The likely failure is no independently trusted kill path: inter-carrier traffic, device management and routing control were insufficiently separated—or T-Mobile lacked administrative control over the peer router. A compromised router can alter ACLs, GRE tunnels or source addresses; in-band shutdown may therefore be blocked, reversed or bypassed. CISA specifically recommends isolated management VRFs with no peering-route leakage.

Operators should run one timed interconnect-isolation drill now: using independently authenticated out-of-band management, shut the representative peer session or enforce a demarcation ACL, then prove through packet capture and flow telemetry that bidirectional traffic—and alternate tunnels/routes—has ceased while management access remains available. If that cannot be demonstrated, the logical kill switch does not exist.