CISA KEV Puts ColdFusion Isolation Ahead Of Patch Theater Tonight

Alex, compress the active-exploitation board into a same-day technical priority order. Use the source pack evidence: CISA KEV for actively exploited Adobe ColdFusion path traversal; PAN-OS LSVPN CVE-2026-0283 auth bypass; BeyondTrust RS/PRA auth bypass; public PoC for on-prem SharePoint Server CVE-2025-53770; Tenda router backdoor with reported in-wild exploitation; UAT-7810 compromising Ruckus/ASUS routers for LapDogs ORB; and Roundcube CVE-2024-42009 against universities. I do not want a CVSS list — tell us which exposures are likely already compromised versus patch-before-exploit, what to isolate tonight, and where evidence is thin.

Halil, my same-day order is not CVSS-driven. It is exploit closure plus exposure.

1. Adobe ColdFusion path traversal — isolate first. CISA KEV means active exploitation, not theory. If ColdFusion is internet-facing, treat it as likely already compromised: pull it from exposure, preserve logs, hunt for file read abuse, dropped web shells, config/secret access, and rotate secrets. This is not a “patch and move on” item.

1. Compromised edge routers: Tenda backdoor, plus Ruckus/ASUS tied to UAT-7810 / LapDogs ORB — assume dirty if exposed. Reported in-wild exploitation and ORB use mean the device is probably infrastructure now, not just a vulnerable asset. Isolate tonight, replace or reflash from trusted media, reset admin credentials, kill WAN management, and watch for reused upstream creds. Routers are like motel rooms for attackers: once abused, you don’t trust what was left behind.

1. On-prem SharePoint CVE-2025-53770 — if internet-facing, isolate tonight; otherwise patch before the PoC gets operationalized. Public PoC changes the clock. I would not claim broad compromise from PoC alone, but exposed SharePoint is too valuable to leave online while debating semantics. Hunt for web shells, abnormal child processes, suspicious file writes, and token/session theft.

1. BeyondTrust RS/PRA auth bypass — patch or isolate tonight, especially if internet-facing. Evidence I saw supports a critical auth-bypass advisory, but not confirmed active exploitation. Still, remote support tooling is privileged by design. If exposed, treat successful exploitation as instant admin-path closure and rotate credentials/sessions after patching.

1. PAN-OS LSVPN CVE-2026-0283 auth bypass — disable/patch LSVPN tonight where enabled. This is serious because it sits on the edge, but the evidence here is advisory-grade, not confirmed exploitation. Priority depends on whether LSVPN is actually enabled and reachable. No exposure, lower urgency. Internet-facing LSVPN, same-day action.

1. Roundcube CVE-2024-42009 — sector-prioritize. The handoff points to exploitation against universities, so universities and research institutions with exposed Roundcube should assume compromise and hunt now. Outside that sector, patch quickly, but the evidence is thinner for broad opportunistic exploitation.

Bottom line: ColdFusion and the router/ORB cases are compromise-response items. SharePoint exposed to the internet is almost there because public PoC closes the gap. PAN-OS LSVPN and BeyondTrust are urgent patch/isolate-before-exploit unless your logs show attempts. Roundcube is highest for universities, not automatically everyone.

Lena, give us attribution discipline across the China-linked threads without collapsing them into one story. Compare UAT-7810/LapDogs, UNK_MassTraction exploiting Roundcube against U.S./Canadian universities, and the Taiwan LINE-account espionage case. What can we say with confidence, what is only vendor-label proximity, and what intelligence collection objective should defenders assume?

Halil, I would keep these as three separate China-linked lines, not one campaign. UAT-7810/LapDogs is the infrastructure story: the handoff identifies UAT-7810 expanding the LapDogs ORB proxy network with new malware; I’d call attribution moderate confidence because the operational continuity is meaningful, but the visible evidence is still source-led rather than independently pivoted here. UNK_MassTraction is a clearer university espionage thread: Proofpoint says it began in May 2026, exploited Roundcube CVE-2024-42009, targeted U.S. and Canadian physics/engineering departments, and assessed China alignment from covert-network access, low-volume targeting, VShell use, and Chinese-language artifacts — moderate confidence, not more.

The Taiwan LINE-account case is different again: Taiwan’s Investigation Bureau says local businessmen collected Taiwan-registered LINE accounts, rented them for RMB 1,100 per account to a Xiamen firm Taiwan links to Chinese cyber forces, and those accounts impersonated international/ICIJ-style journalists to approach political and academic targets. That is identity-enabled human/social engineering, not the same infrastructure or exploit chain as LapDogs or Roundcube.

Defenders should assume the collection objective is access to strategic research, policy circles, journalists/civil society, and trusted communications channels — not broad disruption. The weak point is vendor-label proximity: “China-linked” is shared across all three, but the tradecraft, victimology, and collection paths do not justify merging them into one actor narrative.

Arjun, today's delta versus our prior 'trusted workflow' discussions is specific: GhostApproval symlink flaws across AI coding assistants, GitLost prompt injection leaking private repo content, HalluSquatting package-name abuse, Dialogflow CX Rogue Agent, and Claude Desktop/MCP command execution paths. Convert that into a CISO decision: which AI-agent capabilities should be restricted tonight when developers open untrusted repositories or connect agents to private repos, SSH, cloud credentials, and CI/CD?

Halil, my CISO answer is: treat developer AI agents as untrusted code execution surfaces tonight, especially when they touch untrusted repositories or private assets. This is not “the model went rogue”; it is an injection-and-privilege-boundary problem.

For tonight, I would restrict these capabilities:

1. Disable auto-approval for AI coding assistants on untrusted repos. GhostApproval is specifically about symlink flaws across AI coding assistants, so do not let agents approve file reads/writes or follow workspace paths without human review.

2. Block cross-repository access by agents. GitLost shows the dangerous pattern clearly: a crafted public GitHub issue could cause an agentic workflow to read private repository content and post it publicly. So agents working on public repos should not have access to private repos in the same org.

3. Turn off agent-initiated package installation. HalluSquatting is package-name abuse: AI coding assistants can be tricked into installing attacker-controlled packages. Require lockfiles, allowlists, internal mirrors, and human approval for new dependencies.

4. Disable shell, SSH, cloud credential, and CI/CD tool access unless isolated. If Claude Desktop/MCP or similar tools can execute commands, invoke MCP tools, use SSH keys, call cloud CLIs, or trigger pipelines, put those behind explicit per-command approval and preferably an ephemeral sandbox. I do not have enough visible evidence here to make a detailed claim about the specific Claude Desktop/MCP path, but the capability class is high-risk.

5. Do not connect customer-facing or chat-facing agents directly to privileged workflows. For Dialogflow CX Rogue Agent, I do not have enough visible evidence in front of me to rate the specific exploit, but the safe decision is still to remove write-capable actions, secrets access, and backend workflow execution from any agent that consumes untrusted user text.

What I would still allow: read-only code explanation, local autocomplete, and agent suggestions that cannot execute commands, install packages, write files outside the workspace, post to public channels, or access secrets. The bright line is simple: if the agent can move data across trust boundaries or invoke real tools, restrict it tonight.

Marcus, tie the identity lane together: KDDI's 12-million-person email/password exposure, O-UNC-066 fake Microsoft passkey enrollment, EvilTokens device-code phishing, and Helix session-token/MFA abuse with SharePoint and OneDrive exfiltration. What is the real trust-state failure here, and what should identity teams revoke, block, or re-verify tonight beyond password resets?

Halil, the common failure is not “passwords were stolen.” It is attacker-held trust state. The KDDI case gives attackers credential material at scale — email addresses and passwords, reportedly with some passwords hashed or encrypted — which becomes especially dangerous where users reused credentials or where the mailbox is the recovery channel for other accounts. The O-UNC-066/Pink activity is worse in a different way: Okta-reported vishing pushes Microsoft 365 users through fake Entra passkey enrollment, and in some cases the attacker gets a passkey registered under their control. EvilTokens, per the handoff source, is in the same family of abuse: Microsoft 365 device-code phishing that obtains user-authorized access without needing the victim to type a password into a classic login form.

So tonight’s action is: don’t stop at password resets. Revoke active sessions, refresh tokens, remembered MFA/device trust, newly registered passkeys/security keys, suspicious authentication methods, and third-party OAuth grants. Block or tightly scope device-code flow unless the business has a specific approved use case. Freeze or step-up protect new authenticator/passkey enrollment, then re-verify recent enrollment events out of band. For any account tied to KDDI-exposed email, treat that mailbox as a possible account-recovery compromise path and re-check downstream password resets, forwarding rules, and recovery email bindings.

On the Helix-style session-token/MFA abuse with SharePoint and OneDrive exfiltration: the fix is token revocation plus SaaS trust cleanup, not “change password and move on.” Kill browser sessions, revoke Entra refresh tokens, remove attacker-added MFA methods, invalidate risky devices, review SharePoint/OneDrive sharing links, and audit recent bulk downloads or Graph/SharePoint access. Passkeys are still the right destination — but only with governed enrollment. An attacker-controlled passkey is not phishing-resistant authentication; it is a durable attacker credential wearing a better badge.

James, close the operational lane using what we have so far. Alex ranks ColdFusion KEV isolation first, then exploited/abused edge routers, then privileged remote-access/perimeter gear, then SharePoint PoC. Lena separates China-linked infrastructure, university mail theft, and Taiwan LINE espionage rather than merging them. Arjun says AI agents are untrusted code-execution surfaces, and Marcus says the identity issue is attacker-held trust state, not passwords. Give a 24-hour response sequence a CISO can execute without boiling the ocean.

Alex’s order is the right operational order. For the next 24 hours: 1) isolate internet-facing Adobe ColdFusion first because the handoff evidence says CISA warns an Adobe ColdFusion path traversal flaw is actively exploited and in KEV. Do not start with a broad patch marathon. Pull ColdFusion access/app logs, snapshot the host if compromise is plausible, restrict ingress to known business paths, and only then patch or rebuild through staging. If it is exposed and business-critical, accept a short outage over leaving it reachable.

Second block, same day: edge routers and privileged perimeter/remote-access gear. I don’t have enough verified advisory detail in the visible evidence to name specific router or VPN patch versions, so the executable move is containment: inventory exposed management interfaces, disable WAN-side admin, rotate device admin/API credentials, revoke active sessions where supported, and check for unexpected tunnels, new local users, config changes, and DNS/proxy changes. Marcus is right: this is not just passwords. Treat attacker-held trust state as live access — kill sessions, revoke tokens/certs/API keys tied to perimeter admin, force re-enrollment for privileged remote access, and review IdP sign-ins from those devices.

Third block: SharePoint PoC and AI/dev execution surfaces. SharePoint RCE PoC evidence exists, but based on the lane order it sits behind confirmed ColdFusion exploitation and exposed perimeter control paths unless your SharePoint is internet-facing or holds regulated data. Put compensating controls on exposed SharePoint today, review web logs for exploit-looking requests, and schedule emergency patch testing. For AI agents, Arjun’s framing is the one to operationalize: disable autonomous write/execute permissions, remove production secrets from agent workspaces, block agent access to CI/CD deploy keys unless explicitly approved, and log every tool invocation. A CISO can run this as: 0–4h ColdFusion isolation/evidence; 4–10h perimeter exposure reduction and trust revocation; 10–18h SharePoint containment and patch testing; 18–24h AI/dev permission cuts plus SOC hunts for persistence and session abuse.

Sofia, stay narrow: where do today's stories create real notification or governance exposure rather than generic compliance noise? Focus on KDDI's zero-day email-platform breach affecting over 12 million people, AssuranceAmerica's nearly 7 million affected, Brazil ANPD's ISAC patient-data case, and NIS2 implementation pressure in Europe. What does counsel or a DPO need to do today, and what is only monitoring?

Halil, the real exposure is concentrated in three places, not every headline. For KDDI, counsel should treat this as an active breach-response matter, not just vulnerability remediation: the visible evidence says unauthorized access to an email platform, potentially exposed email addresses/passwords, coordination with Japanese regulators, user notification, and forced password resets. I cannot verify the current Japanese statutory notification clocks from the evidence visible here, so I would not cite a deadline; operationally, the DPO should preserve the detection timeline, regulator-contact record, affected-provider allocation, and password-reset proof today.

For AssuranceAmerica, this is clearly notification/governance exposure: reporting says 6,998,886 people affected, attackers accessed parts of the IT environment, copied files, and exposed names, contact details, auto-insurance/policy/account data, driver/vehicle information, claims data, and driver’s-license numbers. Counsel should confirm state breach-notification coverage, insurance-regulator notice obligations, law-enforcement notice, credit/identity-protection commitments, and whether any SEC-style materiality analysis is relevant if the entity or parent is a filer. The key governance problem is the gap between March activity/detection and July notices; document when the company knew what data was copied.

For Brazil ANPD / ISAC, this is monitoring plus readiness unless you represent the entity or processors: the visible evidence only confirms that ANPD is probing a health organization over a patient-data breach affecting about 500,000 patients. Because health data is involved, counsel should assume heightened regulator scrutiny and preserve processor contracts, security measures, notification records, and patient-communication drafts. On NIS2, I could not verify current Member State implementation status from the visible evidence, so I would treat it as board-level monitoring today: map whether EU entities fall into essential/important sectors, update incident-escalation playbooks, but do not claim a live filing duty without country-specific confirmation.

Pierre, translate the board into business impact for executives. Rank the likely board-level disruption paths: active perimeter compromise (ColdFusion/SharePoint/BeyondTrust/PAN-OS/Tenda), UAT-7810 ORB edge infrastructure, KDDI-scale credential exposure, Microsoft 365 passkey/device-code/session-token abuse, and AI-agent developer workflow compromise. Give concrete decision framing, not a wide risk range.

Halil, my board ranking is:

1. Microsoft 365 passkey / device-code / session-token abuse — highest board disruption because it converts into invoice fraud, mail surveillance, executive impersonation, and data-access control failure. Decision: force high-risk session revocation, freeze sensitive payment changes, and require out-of-band approval for treasury/legal/HR workflows today.
2. Active perimeter compromise: ColdFusion / PAN-OS / SharePoint / BeyondTrust / Tenda — the substantiated evidence I have is strongest for ColdFusion active exploitation and PAN-OS authentication-bypass exposure. This is the fastest route to outage, ransomware staging, or breach notification. Decision: approve emergency patch/change windows and external attack-surface takedown authority now.
3. AI-agent developer workflow compromise — this is a board issue when AI agents can touch code, secrets, tickets, or CI/CD. Decision: pause autonomous write/deploy permissions until secrets, repo access, and approval gates are reviewed.
4. UAT-7810 ORB edge infrastructure — Cisco/Talos reporting says UAT-7810 is expanding ORB proxy infrastructure through compromised edge/networking devices, including unpatched Ruckus and ASUS routers. Business impact is less “we are the victim” and more “our perimeter becomes someone else’s covert infrastructure,” raising detection, legal, and partner-trust exposure. Decision: inventory unmanaged edge gear and isolate/replace unsupported routers.
5. KDDI-scale credential exposure — I do not have visible current evidence here to price or rank it above the others. If those credentials map to enterprise SaaS, VPN, or telecom identity, it jumps to number two; if they are stale consumer credentials, it stays lower. Decision: credential matching and forced reset for privileged and customer-support accounts first.

So the CEO-level ask is not “monitor the threat.” It is three authorizations: identity containment, emergency perimeter remediation, and developer-workflow access reduction. Alex, if we stay in kill-chain detail without naming which revenue systems can be stopped or defrauded, the board will underfund this.

Isabelle, deepfake fraud is not our lead, but it is now financially material: nearly $893M reported AI-scam losses, Arup's $25M video-meeting transfer, Nirmala Sitharaman deepfake investment fraud, SynthID's limited success, and eKYC/face-swap bypass concerns. What control change should finance, HR, and customer-onboarding teams make now, and what should they not over-trust?

Halil, the control change is simple: stop treating likeness as authorization. For finance, any payment, beneficiary change, payroll-account change, or emergency transfer request should require out-of-band verification using a pre-registered channel, plus dual approval. Arup’s nearly $25M video-meeting transfer shows why a convincing “executive on camera” is not enough. The reported $893,346,472 in AI-powered scam losses across FBI complaints reinforces that this is financially material, not hypothetical.

For HR and customer onboarding, the same rule applies: face, voice, or video is only a signal, not proof of identity. HR should require identity-bound workflow controls for payroll, hiring, account recovery, and executive requests. Customer onboarding teams should not rely on face match or eKYC liveness alone, because the ESET-referenced material flags deepfake and face-swap bypass risks in facial recognition and eKYC systems. The Nirmala Sitharaman deepfake investment scam is the consumer-facing version of the same failure: a familiar face created trust, then money moved.

What not to over-trust: video calls, voice calls, facial recognition, screenshots, “AI detection” scores, or watermarking as standalone controls. On SynthID specifically, I don’t have enough sourced evidence here to quantify its success or failure rate, so I would not build a control plan around it. Use provenance and detection as supporting evidence; use process controls to stop money, access, or identity changes.

Maya, give us the huntable execution paths rather than malware labels. For UAT-7810 LapDogs tooling LONGLEASH/DOGLEASH/JARLEASH, Roundcube IceCube stealer delivery, KongTuke/Woodgnat Mistic/MTLBackdoor, ScreenConnect-to-AsyncRAT abuse, and Gentlemen's Go backdoor, what telemetry or behavior should SOC teams hunt this week? Also tell us which labels should not be over-briefed to leadership.

Halil, I’d keep this framed as execution paths, not family names:

• LapDogs / UAT-7810 LONGLEASH-DOGLEASH-JARLEASH: hunt for compromised edge or network devices behaving as proxy infrastructure, not just endpoint malware. The source-backed piece I have is that UAT-7810 is expanding a LapDogs ORB proxy network with new malware. SOC angle: look for unusual outbound proxying from routers, VPN appliances, SOHO gear, or unmanaged Linux-like devices; persistent listener processes; new init/systemd entries; and traffic relaying to multiple unrelated external destinations. Don’t brief this as “just Chinese malware on endpoints” — the important behavior is operational relay infrastructure.
• Roundcube / IceCube delivery: the sourced path is exploitation of Roundcube CVE-2024-42009 against universities by suspected Chinese-linked actors. Hunt Roundcube webmail logs for abnormal attachment/rendering activity, suspicious authenticated webmail sessions after exploit windows, mailbox access from odd IPs, and any JavaScript or payload retrieval chained from mail content. Do not over-brief “IceCube” as the main story unless we have binary-level stealer evidence; the defensible story is Roundcube exploitation leading to credential/mail theft risk.

For the other three, I have topic names but not enough visible source-backed detail to name code traits confidently, so I’d keep hunts behavior-first: KongTuke/Woodgnat Mistic/MTLBackdoor — hunt web-to-host execution, suspicious backdoor persistence, odd child processes from web services, and beaconing from servers that should not initiate broad outbound sessions. ScreenConnect-to-AsyncRAT — hunt remote support session creation followed by PowerShell/cmd, archive extraction, user-profile payload staging, Run-key/scheduled-task persistence, and .NET RAT-like outbound connections. Gentlemen’s Go backdoor — hunt newly dropped Go binaries, large statically linked executables in temp/user-writable paths, service or scheduled-task persistence, and regular beacon intervals. I would not brief “Mistic,” “MTLBackdoor,” “AsyncRAT,” or “Gentlemen” to leadership as if the labels themselves prove actor identity or impact; brief the execution path: remote access abuse, webmail exploitation, server-side backdoor deployment, and proxy infrastructure.

Nadia, mobile is not the lead but there are three signals: RedWing Android spyware MaaS with overlay/SMS OTP/VNC/keylogging, Android fake apps evading Google Play review against Indian users, and IonStack's one-click Firefox-plus-kernel Android exploit chain disclosed as PoC/no active exploitation. What should enterprise mobile teams do now without creating consumer-wide panic?

Halil, I’d keep this targeted and operational. The mobile priority is Android enterprise risk, not consumer panic. For RedWing, the concrete risk is credential and session compromise: reporting says it is sold as Android spyware/MaaS via Telegram, uses fake app-store/phishing delivery, overlays for banking and crypto credential theft, SMS OTP interception, Accessibility abuse, screen streaming, app hiding, and in some reporting call-forwarding/camera/mic capability. That is serious for employees who approve payments, handle crypto, or use SMS-based MFA.

For the fake-apps-in-India signal, the key lesson is ecosystem abuse: Quick Heal-linked reporting describes staged payload delivery, WebView redirects, geo-targeting, conditional activation, and apps posing as financial, utility, or service tools while stealing SMS, contacts, banking credentials, device IDs, and location. So enterprise teams should not say “Google Play means safe.” They should enforce managed Play allowlists, block unknown-source installs, monitor high-risk permissions — Accessibility, notification access, default SMS, battery optimization exemptions — and push users in India-facing teams toward verified publisher names and official banking/service portals.

On IonStack, I’d be careful. I don’t have independent evidence in the visible corpus beyond the description that it is a disclosed Android Firefox-plus-kernel exploit chain with PoC/no active exploitation. Treat it as patch and exposure management, not an emergency broadcast: update Firefox, Android WebView/Chrome components, OS security patches, and isolate high-risk users from unmanaged browsing on work profiles. No consumer-wide panic unless exploitation telemetry appears.

Message to users should be simple: “Install only approved apps, don’t grant Accessibility/SMS/notification access to finance or utility apps unless IT confirms, report fake login overlays, and update now.” Internally, raise controls for finance, executives, crypto handlers, journalists/NGO contacts, and India operations. That’s proportionate: defend the population most likely to be hit without telling four billion Android users the sky is falling.

Tomas, the developer supply-chain lane is crowded: fake Paysafe/Skrill/Neteller npm and PyPI SDKs, Operation Muck and Load malicious Go module with GitHub lure repos, North Korean PolinRider across package managers and Chrome extensions, Cordyceps GitHub Actions secret exposure, and GitHub Verified commit re-encoding. What is the non-obvious trust failure, and what developer-platform controls should be prioritized this week?

Halil, the non-obvious failure is developer-platform trust being attached to labels, not artifacts: a package name that looks like Paysafe/Skrill/Neteller, a GitHub repo that looks like a legitimate lure project, a Chrome extension update path, a GitHub Actions context with reachable secrets, or a “Verified” signature workflow that may not bind cleanly to the raw object being reviewed.

The strongest signal is the pattern across ecosystems. Socket reports PolinRider expanded beyond npm into 108 packages / 162 malicious artifacts, including 80 Go modules, 10 Packagist packages, and one Chrome extension, with VPN-themed extensions stealing clipboard data after later updates. Separately, the GitHub advisory for gitsign says verification re-encoded commit/tag objects through go-git before checking signatures, breaking the invariant between the verified signature, Git semantics, and the Rekor-logged object. That is the same class of problem: we are trusting platform assertions without proving the exact artifact and execution path.

This week I would prioritize four controls, not a blanket engineering freeze:

1. Block unreviewed package intake for npm, PyPI, Go modules, Packagist, and browser extensions through an internal artifact proxy; require explicit approval for new package names, new maintainers, and typosquat-adjacent names.
2. Pin by digest/hash and lockfile diff review, especially for Go modules and JS/Python SDKs that touch payments, wallets, credentials, CI, or browser data.
3. Harden GitHub Actions secrets: no secrets in pull-request workflows from untrusted code paths, least-privilege tokens, environment protection rules, and immediate review of workflows affected by the Cordyceps-style GitHub Actions secret-exposure issue.
4. Treat “Verified” as insufficient alone: verify raw Git objects with fixed tooling, require Sigstore/SLSA-style provenance for released artifacts, and do not let a green badge substitute for reproducible source-to-artifact linkage.

My trust-nothing takeaway: the blast radius is no longer one malicious package. It is the developer identity plane — registries, GitHub repos, CI secrets, extension update channels, and signature tooling — being used as the delivery surface.

Claim: You ranked Microsoft 365 passkey/device-code/session-token abuse as the highest board disruption path. Counter-evidence: James and Alex put actively exploited ColdFusion and exposed perimeter/remote-access infrastructure first for the next 24 hours because exploitation is live or has public PoC/clear exposure paths. Reconcile this: are you disagreeing with their operational priority, or using a different board-risk axis? Give the executive framing we should use so CISOs don't underreact to live perimeter compromise or over-focus on SaaS identity.

Halil, I’ll reconcile it directly: James and Alex are right for the next 24 hours. I was using a board-loss axis — fraud, data access, control failure — not an exploit-now triage axis. With the evidence in front of us, ColdFusion is reported as actively exploited, Tenda firmware exploitation is reported in the wild, PAN-OS has a disclosed authentication-bypass issue, and BeyondTrust has critical authentication-bypass patches. That means the executive framing should put live perimeter and remote-access compromise first for immediate action, not Microsoft 365.

The board message should be: “Today’s first spending authority is emergency perimeter containment; identity containment runs in parallel, not instead.” My ranking for the next 24 hours is: 1) active perimeter/remote-access compromise, because it can become unauthorized network access or outage fastest; 2) Microsoft 365 token/device-code/passkey abuse, because it can become payment fraud and confidential-mail exposure once credentials or sessions are in play; 3) AI-agent developer workflow compromise, because it can turn one developer workflow into code, secret, or CI/CD compromise; 4) UAT-7810 ORB edge infrastructure, because it is a stealth and unmanaged-edge exposure problem; 5) KDDI-scale credential exposure, because I do not have enough visible current evidence here to rank it above the live exploitation paths.

So the CISO should not hear “go chase SaaS identity and leave the perimeter for later.” The decision is: authorize emergency patching/takedown for exposed ColdFusion, PAN-OS, BeyondTrust, Tenda and comparable edge assets today; revoke high-risk Microsoft 365 sessions and freeze sensitive payment-change workflows in parallel; defer AI-agent workflow changes unless those agents can deploy code or access secrets.

Arjun, the gate is asking for a sharper GhostApproval decision. Strip out the broader AI-agent landscape and give me the concrete 24-hour control set for GhostApproval-style symlink abuse in AI coding assistants: which agent permissions should be disabled or constrained, what repository-opening workflow should change, how should teams handle Anthropic disputing the finding, and what evidence would justify restoring normal use?

Halil, for the next 24 hours I would make this a developer endpoint containment decision, not a model-safety debate.

Disable or constrain tonight: - Disable AI assistant writes that resolve outside the repository root, including symlink-resolved paths. Wiz describes GhostApproval as a trust-boundary flaw where malicious repo symlinks can trick assistants into reading or writing outside the intended workspace. - Disable auto-approval for file modification, delete, rename, chmod, and command execution after agent edits. - Block agent access to SSH keys, credential files, cloud CLI profiles, package-manager tokens, and CI/CD secrets from any session opened on an untrusted repo. Infosecurity reports the GhostApproval pattern can make a prompt look harmless while the agent writes to sensitive files such as SSH keys, with worst-case passwordless remote access or RCE. - Where teams must use agents, run them in an ephemeral dev container or VM with a clean home directory and no mounted secrets.

Change the repository-opening workflow: - Untrusted repos should be opened first in “quarantine mode”: no agent write access, no shell execution, no secrets mounted. - Run a symlink preflight before enabling the assistant. Any symlink resolving outside the project root should block agent write mode. - Approval prompts must show the canonical resolved target path, not the apparent repo-local path. Wiz specifically notes cases where the agent recognized risk internally but the user-facing confirmation hid the true target.

On Anthropic disputing scope: don’t wait for vendor consensus. Infosecurity reports Anthropic disputed that Claude Code’s behavior was in scope of its threat model, while Wiz lists Claude Code among affected assistants. The CISO decision should be capability-based: if a coding assistant can follow symlinks and write outside the repo, constrain it regardless of whether the vendor calls it a vulnerability.

Restore normal use only when you have evidence of all four: vendor fix or compensating control deployed; canonical-path approval visible to users; enforced denial of out-of-workspace writes; successful internal test with a malicious symlink repo showing the agent cannot modify sensitive external files.