A Clean Ivanti Check Won't Put the Appliance Back in Service

CVE-2026-104935 is the lead. Take the exploit-feasibility and compromise-assessment lens only: establish what is known about UTA0576's three-zero-day chain against Ivanti Connect Secure, which versions are implicated, what root-level access and log manipulation mean for evidence reliability, and the concrete threshold for isolate/preserve/rebuild rather than patch-and-monitor. End with the actions an exposed operator must complete tonight; separate confirmed facts from inference.

This is not CVSS theater. Confirmed: Volexity observed UTA0576 compromise a fully patched Connect Secure 22.8R2.4 appliance as early as October 3, 2026. The chain combined unauthenticated access, file-write-based code execution—tracked together as CVE-2026-104935—and a separate privilege-escalation zero-day to reach root. The actor used exploit-related HTTPS traffic for command execution, then accessed sensitive Active Directory material, including LAPS passwords and BitLocker recovery keys, and conducted password spraying. No persistent web shell or separate command-and-control channel was observed.

The version picture is branch-specific, not simply “everything older.” Reporting identifies 22.8R2.4 as demonstrably exploited and lists 22.8R2.5, 25.1.3.0, and 25.1.3.1 as unaffected; 22.7R2.14 and earlier are also listed as unaffected. Operators should verify their exact branch against Ivanti’s matrix rather than infer safety from version numbering. The first two stages have fixes, while reporting says the separate privilege-escalation fix was still pending. Confirmed stealth behavior: malicious library modification occurred only in memory and altered configuration data was restored, meaning the Integrity Checker Tool can return clean despite exploitation. Inference: once the attacker has root, appliance-local logs are like CCTV controlled from inside the security room; absence of evidence is not reliable evidence of absence. I cannot establish from the available evidence exactly which log records were modified on every victim.

My threshold is blunt: isolate, preserve, and rebuild if there is any matching exploit traffic or artifact—repeated requests to /dana-na/auth/url_default/welcome.cgi, anomalous X-DSCGI-PATH headers, /data/.icscap/, or traffic involving 108.165.147[.]64. Apply the same response where a vulnerable appliance was internet-exposed during the observed window but lacks independent, off-box network and identity telemetry capable of excluding exploitation. Patch-and-monitor is acceptable only where the appliance was not exposed, or complete external telemetry affirmatively rules out the chain. A clean ICT result alone does not clear it.

Tonight: disconnect suspect appliances from internet and internal identity services; preserve volatile state before reboot where operationally possible; export appliance data plus firewall, proxy, IdP, LDAP, AD, DNS, and endpoint logs; hunt the listed indicators and password-spraying activity; rebuild qualifying systems from a known-clean image onto an unaffected release before reconnection; and rotate every credential or secret the appliance stored or could reach—especially LDAP bind, administrator, API, and service credentials—while invalidating related sessions. Also review AD access to LAPS passwords and BitLocker recovery keys. Patch closes the door. It does not remove someone already inside.

For the Ivanti Connect Secure CVE-2026-104935 compromise thread, define the trust blast radius. The reporting includes stolen domain credentials, Active Directory metadata, recovery-secret searches, certificates, API keys, and license-server credentials. Specify which identities, sessions, keys, and trust relationships must be revoked or rotated, in what order, and when appliance compromise should trigger domain-wide escalation. Give a decision-ready answer, not a generic credential-reset list.

The appliance is an authentication broker under attacker control, not merely a vulnerable VPN. Fact: Volexity reported unauthenticated root execution on a fully patched appliance and targeting of LDAP credentials, Active Directory data, LAPS passwords, and BitLocker recovery keys. CISA separately confirms credential theft and data exfiltration, while warning that the Integrity Checker may miss memory-only activity. Assessment: treat every secret the appliance could store, decrypt, relay, or observe during the exposure window as compromised.

The response order should be:

1. Contain before rotating: remove the appliance from service, preserve logs and configuration for scope analysis, and replace or rebuild it onto Ivanti’s fixed release. Do not feed new credentials into the suspected image.
2. Kill appliance-established trust: terminate all VPN and administrator sessions; revoke persistent VPN cookies, client session tokens, refresh tokens, and remembered-device registrations where configured. Disable local appliance administrators and recreate them on the clean system.
3. Rotate machine identities from clean systems: first the LDAP bind/service account and any domain account stored on the appliance; then license-server credentials, API keys, monitoring/backup credentials, SSH keys, and automation secrets. Review each associated account for interactive logon, privilege escalation, and unexpected use before re-enabling it.
4. Replace cryptographic trust: reissue every certificate whose private key was stored on the appliance—TLS, VPN client-authentication, SAML service-provider, API-client, or management certificates—and revoke the old serials. If a CA private key, IdP signing key, or federation-signing key was accessible, escalate immediately: rotate that key and re-establish trust at every relying party. A certificate rotation without private-key revocation is cosmetic.
5. Clean up human identity: force password changes for users whose credentials may have traversed password-based LDAP, RADIUS, or appliance-local authentication, then invalidate their IdP sessions, refresh tokens, cached Kerberos tickets, and third-party OAuth grants as applicable. Prioritize privileged and recovery administrators. Move remote access to WebAuthn/FIDO2; push, SMS, and passwords remain susceptible to interception or replay.

Trigger domain-wide escalation if the compromised LDAP account had privileged or directory-replication rights; if logs show successful retrieval—not merely searches—of LAPS passwords or BitLocker recovery keys; if password spraying produced successful domain authentication; if domain-admin, AD CS, KDC, IdP-signing, backup, or recovery credentials were exposed; or if appliance-originated activity reached multiple hosts. At that point, rotate affected LAPS passwords, regenerate exposed BitLocker recovery material, reset privileged accounts in dependency order, revoke Kerberos tickets, and investigate AD CS and federation trust. Unknown: the public evidence cited here does not establish exactly which recovery secrets were successfully returned, what each reported certificate protected, or the privilege and scope of every API key; those distinctions determine whether escalation remains targeted or becomes forest-wide.

Assess the Danfoss refrigeration-controller attacks as an OT safety and continuity event. Identify what is confirmed about affected AK-SC 355, AK-SM 800, and AK-SM 800A deployments, likely exposure and control paths, and how operators should inventory, isolate, update or replace systems without destabilizing refrigeration. Translate spoilage, equipment damage, and reported fires into a 24-hour containment and evidence-preservation plan; flag any claims that remain uncertain.

Halil, the physical consequence is clear even though the intrusion mechanics are not. FACT: reporting describes attacks across hundreds of French supermarkets in which Danfoss refrigeration systems were placed into defrost mode, with temperatures reportedly reaching 50°C. Spoilage, equipment fires and losses in the tens of millions of euros were reported. The identified population includes end-of-life AK-SC 355 and AK-SM 800 systems, plus some AK-SM 800A units with outdated firmware. SOCRadar also reported 2,898 internet-exposed Danfoss StoreView interfaces in France. Those exposed interfaces are not necessarily compromised systems, and the reported fires should not yet be attributed to cyber manipulation without site-level fire-investigation evidence. SOCRadar (opens in new tab) | Nozomi Networks (opens in new tab)

ASSESSMENT: this most plausibly maps to a Purdue Level 2 supervisory/site-management compromise: abuse of remote management to change defrost commands, schedules or setpoints while lower-level refrigeration controls continue operating. Internet-exposed StoreView, poorly restricted vendor access, or compromised credentials are credible paths, but none is confirmed as the initial vector. There is currently no demonstrated evidence here that attackers rewrote compressor-controller logic, modified safety protections, or compromised every exposed interface. The actor, vulnerability or credential used, persistence mechanism, precise firmware versions and causal connection between manipulation and fires remain unknown.

For the first eight hours, treat this as both a fire-safety and food-safety event. Establish an OT incident lead with refrigeration engineering and store operations; inspect for overheating, smoke and abnormal compressor cycling; call emergency services where indicated; quarantine temperature-abused stock; and maintain manual temperature rounds if remote alarms may disappear. Inventory every AK-SC 355, AK-SM 800 and AK-SM 800A by site, serial number, firmware, StoreView exposure, NAT/firewall rule, VPN or vendor pathway, configuration backup and local fallback capability. Isolate the WAN-facing management path, not the refrigeration process: block unsolicited inbound access, suspend unnecessary vendor sessions and rotate remote-management credentials while preserving essential local controller communications. Validate every filtering change with the refrigeration engineer—breaking alarm or control traffic can create the very loss of cooling we are trying to prevent.

From hours eight to 24, preserve configuration exports, controller and alarm logs, firewall/VPN records, available packet captures, temperature histories, panel photographs, operator actions and accurate timestamps before rebooting or resetting anything. For AK-SM 800A, stage the vendor-supported firmware in a representative test environment, confirm configuration and rollback procedures, then update during a controlled window. Treat end-of-life AK-SC 355 and AK-SM 800 units as replacement candidates: keep them behind strict allow-listing and monitored access until a parallel, tested migration can occur. Do not perform a fleet-wide emergency swap or power cycle. Restore remote management only after validating cooling, defrost, alarms and fail-safe behavior locally, preferably under two-person approval.

NICT says attackers reverse-engineer public Android apps to discover backend APIs, parameters, keys, and undocumented functions, then target authorization and injection weaknesses. Determine whether this is evidence of a defined active campaign or a documented attack class, what telemetry from August 2026 onward can reveal abuse, and what mobile/API owners should inventory and test tonight. Focus on server-side BOLA/IDOR, SQLi, SSRF and RCE exposure; do not imply that securing the app binary fixes backend authorization.

Halil, this is a documented attack class with incident linkage, not yet a publicly defined campaign. Fact: NICT says LETTICE connected A2B activity to multiple Japanese data-leak incidents and published related IoCs. Attackers derived API details from public Android apps, then targeted backend IDOR/BOLA, SQL injection, SSRF, and RCE weaknesses. Assessment: without a named actor, shared infrastructure, victim list, or bounded campaign timeline, we should not claim one coordinated campaign. Unknown: the public evidence available here does not establish how many incidents occurred or whether one operator caused them.

For the investigation, query retained telemetry from 1 August 2026 onward, not merely from NICT’s October advisory date. Correlate API-gateway, CDN/WAF, load-balancer, application, identity, database-audit, DNS/egress, cloud-metadata, and host/EDR logs. Hunt for one token or source enumerating object IDs or crossing tenant boundaries; low-privilege accounts receiving successful responses for other users’ records; SQL syntax, database errors, time-delay probes, or bulk reads; backend requests to loopback, private address space, metadata services, or attacker-controlled hosts; and application-server processes spawning shells, writing executables, or making unusual callbacks. Match NICT’s published IoCs, but behavioral searches matter because infrastructure can rotate.

Tonight, mobile and API owners should reverse-engineer their own current and archived APKs and inventory every hostname, route, method, parameter, object identifier, embedded key, authentication flow, feature flag, native library, remote configuration, and deprecated or undocumented function. Reconcile that with gateway routes and OpenAPI specifications, then test each endpoint server-side as unauthenticated, low-privilege, cross-user, and cross-tenant callers. Disable unnecessary APIs, restrict access, intensify monitoring, and invalidate or reissue exposed credentials where warranted—actions NICT explicitly recommends. Obfuscating or repackaging the APK does not repair backend authorization: every object and action needs authorization enforcement at the API, while SQLi, SSRF, and RCE require independent input-handling, egress, and execution controls.

Close the Ivanti decision thread after hearing these findings: Alex says CVE-2026-104935 gave UTA0576 unauthenticated root access on a fully patched 22.8R2.4 appliance, memory-only modification can leave a clean Integrity Checker result, and exposed systems without independent off-box telemetry may not be exonerated; Marcus treats the appliance as a compromised authentication broker with LDAP, LAPS, BitLocker, ... [arg clipped]

Alex and Marcus’s findings close this: an exposed, affected Ivanti appliance without trustworthy off-box telemetry cannot be declared clean—even if Integrity Checker passes. Volexity reports exploitation of fully patched 22.8R2.4, including memory-only anti-forensics; Ivanti fixes the affected 22.8 branch in 22.8R2.5. CISA added CVE-2026-104935 to KEV with an October 16, 2026 federal deadline. This is compromise-response territory, not a patch-only ticket.

CRITICAL—today: preserve volatile memory, crash data, configuration, and external VPN/firewall/EDR logs; then isolate or reroute around the appliance. Build a clean replacement on 22.8R2.5 or the appropriate fixed 25.1 release, testing authentication and routing in staging without delaying containment. From clean administrative systems, invalidate sessions and rotate every credential or key the appliance could access—LDAP bind/service accounts first, then privileged identity, LAPS and BitLocker-recovery access where permissions existed, plus certificates or private keys potentially exposed. HIGH—this week: hunt backward through off-box authentication, directory, endpoint, DNS, proxy, and egress telemetry; investigate anomalous account use and data transfer; rebuild rather than trusting an in-place upgrade on suspected systems. A clean Integrity Checker result is not an exoneration, and I would not close the incident on that basis.

UNKNOWN: the evidence visible here does not establish a dependable network signature or a complete IOC set, so I would not deploy an improvised rule with an invented false-positive estimate. If historical telemetry is absent, record that gap explicitly and keep the identity environment under heightened monitoring after rotation.

Translate the Danfoss refrigeration-controller incident into an exact executive decision. Sara reports hundreds of French supermarkets affected, temperatures reportedly reaching 50°C, spoilage and equipment damage, reported fires, and losses described only as tens of millions of euros; the precise exploit and fire causation remain unconfirmed. Define operational shutdown, stock quarantine, insurance/evidence, and board-escalation thresholds. Give... [arg clipped]

Sara, the reports put roughly 530 stores across several groups in scope, with one cold room reportedly reaching 50°C; aggregate losses are described only as tens of millions of euros. The exploit path and any causal link to reported fires remain unconfirmed. Executive decision: activate a group-wide food-safety and cyber crisis now. Immediately remove affected controllers from internet or remote access and place refrigeration under verified local/manual control. Do not shut working refrigeration merely because it uses Danfoss equipment. Shut the affected cabinet, plant, or store zone—and call fire services—if there is smoke, scorching, sprinkler activation, breaker trips, abnormal compressor pressure/cycling, or if a technician cannot establish a safe local state within 15 minutes. Best case is aisle-level closure for hours; worst case is full-store closure until fire, electrical, refrigeration, and food-safety personnel sign off.

Stock rule: stop sale and physically quarantine every chilled or frozen SKU where trustworthy temperature history is missing or exceeds its prescribed limit. French guidance sets 0–4°C for highly perishable chilled food, below 8°C for other perishables, generally −18°C for quick-frozen products, and −12°C for other frozen products. Release requires QA approval using independent calibrated measurements and intact time-temperature records—not controller telemetry alone. Product exposed to a reported 50°C environment, or with an unverifiable excursion, should be treated as loss pending food-safety assessment. Preserve controller logs, configurations, firmware versions, network records, alarm history, photographs, probe readings, SKU quantities and landed cost, disposal certificates, repair invoices, fire reports, and lost-sales records; notify the broker and relevant insurers the same day, without asserting cyber or fire causation prematurely.

The board chair and CEO should be notified immediately if any one of these occurs: more than one store is affected; fire, sprinkler activation, injury, or evacuation occurs; potentially unsafe food may have been sold; trading interruption exceeds four hours; projected loss exceeds the insurance retention or internal disclosure threshold; or the company cannot attest that the remaining controller fleet is clean. This incident already crosses several of those thresholds. I cannot responsibly narrow the loss beyond the reported “tens of millions” without inventory, downtime, repair, and insurance-retention data.

Pressure-test the NICT App-to-Backend story. Nadia assesses it as a documented attack class linked by LETTICE to multiple Japanese data-leak incidents, with IoCs, but not yet a named or bounded campaign. State what the evidence supports about victim scope, actor continuity, and activity since August 2026; identify the strongest overclaim in the source-pack framing; and give one collection requirement that would justify elevating this from systemic exposure... [arg clipped]

Nadia’s boundary is right. Moderate confidence: LETTICE documents A2B as one cause of multiple Japanese leakage incidents beginning around late August 2026, but provides no victim names, count, sectors, or evidence of uninterrupted activity through October. Low confidence in actor continuity: three shared IP IoCs and a common method do not establish that one operator conducted every incident; this maps broadly to T1190 Exploit Public-Facing Application, not yet to a bounded campaign or named actor. NICT (opens in new tab) LETTICE report (opens in new tab)

The strongest overclaim is the source-pack tag “named victim or sector impact”—neither is disclosed. To elevate this from systemic exposure to a campaign, collect cross-victim API and authentication telemetry showing the same distinctive request sequence or exploit payload, tied to shared infrastructure across at least two victims and multiple dates; IP overlap alone is insufficient.

Treat Microsoft's October 2026 patch wave as a prioritization problem, not a vulnerability count. For actively exploited Windows Shell flaw CVE-2026-96951, establish the required victim interaction, realistic attack path and affected estate, what CISA's October 16 deadline does and does not mean outside U.S. federal agencies, and the telemetry or mitigations available where deployment cannot finish tonight. End with a defensible place for this flaw behind or... [arg clipped]

Confirmed: Microsoft’s October reporting identifies CVE-2026-96951 as an actively exploited Windows Shell vulnerability, and CISA placed it in KEV with an October 16, 2026 remediation date. Exploitation requires victim interaction with a crafted file; the available evidence does not establish mere receipt—or Preview Pane alone—as sufficient. The realistic path is delivery through email, browser download, collaboration software, or a share, followed by the user opening the file and the Shell flaw enabling the next execution stage. That makes it a practical phishing-chain component, not a network worm or a one-packet server takeover. Public reporting places supported Windows client and server systems in scope; administrators should use Microsoft’s affected-product table and October cumulative-update applicability rather than assume one Windows edition is exempt. I do not have sufficiently reliable branch-by-branch evidence to enumerate every affected build.

The CISA deadline is binding operational direction for U.S. Federal Civilian Executive Branch agencies under the KEV process. Outside that population, October 16 is not automatically a statutory deadline. It is still strong evidence of observed exploitation and a defensible risk-prioritization signal—not proof that every organization is being targeted, not an exploit-volume measurement, and not permission to ignore local exposure and threat modeling.

Where deployment cannot finish tonight, watch the chain rather than the CVE label: internet-origin or externally delivered files followed by unusual children of explorer.exe or document/archive clients; execution of powershell.exe, cmd.exe, mshta.exe, rundll32.exe, regsvr32.exe, or script hosts immediately after a file-open event; unexpected outbound connections; and subsequent credential access or persistence. Preserve email, download, file-origin, process-tree, and network telemetry. Temporarily tighten attachment and archive handling, detonate suspicious files, enforce WDAC/AppLocker or equivalent application control, enable applicable attack-surface-reduction rules, and prioritize high-risk users. Those controls add guardrails; they are not substitutes for the update. Unknown: the cited public material does not provide a dependable exploit-specific IOC set, so absence of one filename or hash clears nothing.

My ranking: put CVE-2026-96951 ahead of the unexploited remainder of the October patch count, but behind confirmed compromise and behind an exposed, pre-authentication path to root such as the exploited Ivanti Connect Secure chain. Patch high-interaction Windows endpoints tonight—email-heavy users, administrators, developers, and systems accepting external files—then the broader estate. A user-open requirement is a speed bump, not a locked door, but it still matters when compared with an internet-facing root exploit that requires no victim at all.

Claim: Your Ivanti version assessment says exploitation was demonstrated on 22.8R2.4, fixed 22.8R2.5 and 25.1.3.x are unaffected, and 22.7R2.14 and earlier are also listed as unaffected; you warned against reading the issue as simply affecting everything below 25.1.3. Counter-evidence: The source pack summarizes the chain as affecting 'releases before 25.1.3' and recommends patching Ivanti Connect Secure broadly. Reconcile these statements using the vendor branch logic. Give one version statement safe enough for the executive summary, and explain what an operator on an older unsupported or end-of-life branch should do rather than assuming that a numerically lower release is either vulnerable or safe.

The source-pack phrase “before 25.1.3” is overbroad when read across all branches. Ivanti’s detailed matrix—not the headline description—controls: 25.1.1.1 and prior in that applicable line → 25.1.1.2; 25.1.2.2 and prior in that line → 25.1.3.0/25.1.3.1; 22.8R2.4 and prior in the 22.8 line → 22.8R2.5. Ivanti explicitly says 22.7R2.14 and earlier do not contain CVE-2026-104935. The hardware mapping also matters: reporting associates the 25.1.1 line with ISA6000/ISA8000 and the 25.1.2 line with ISA4500/ISA6500/ISA8500. Version numbers are not odometers; a numerically older branch can lack code introduced into a newer branch.

Executive-summary-safe statement: “CVE-2026-104935 affects specified Ivanti Connect Secure 22.8 and 25.1 code lines—including the exploited 22.8R2.4 release—and operators must apply the vendor-designated fixed release for their exact hardware and branch; Ivanti states that 22.7R2.14 and earlier are not affected by this specific CVE.”

For unsupported or end-of-life installations, “unaffected by this CVE” is not the same as “safe to operate.” Verify the exact appliance model, branch, and build with Ivanti; do not force-install a fix intended for another line. If the vendor confirms the branch lacks the vulnerable code, this CVE alone does not prove compromise or justify a rebuild. But the operator should restrict external exposure, preserve independent logging, perform the published compromise checks, and migrate urgently to a supported fixed branch. If Ivanti cannot validate the old build—or the appliance was exposed and telemetry cannot establish what happened—treat that uncertainty as an incident-response problem, not as a numeric-version exemption.

Give the concise operational judgment on self-managed GitLab CE/EE CVE-2026-97229. Rapid7 reportedly reproduced unauthenticated RCE in pipeline processing against an unpatched official image, but there is no confirmed in-the-wild exploitation. Explain the preconditions and likely blast radius for source, CI runners, signing or publishing credentials, and downstream artifacts; state what internet-facing operators shou... [arg clipped]

Operational judgment: this is an emergency patch for internet-facing, self-managed GitLab—not yet a presumed-breach event. Rapid7 reproduced code execution as the GitLab git user on CE 19.4.1, while 19.4.2 resisted the same input; no in-the-wild exploitation was confirmed at publication. The demonstrated chain requires attacker-controlled .gitlab-ci.yml, a repository path containing UTF-8 characters, and a branch in a public project. Open registration and permissive public-project creation or write access make those preconditions substantially easier.

CRITICAL—today: upgrade affected installations to GitLab’s fixed releases—19.4.2, 19.3.4, 19.2.8, or later supported versions—using a rapid canary before production rollout. If patching cannot finish today, restrict anonymous access, disable untrusted project creation, and remove untrusted write access to public projects; these controls only obstruct Rapid7’s demonstrated path. Hunt for newly created public projects, UTF-8 repository paths, unusual .gitlab-ci.yml changes, unexpected pipeline activity, and child processes from the GitLab service account. Escalate to full incident response only when those artifacts or unexplained execution appear.

The likely blast radius starts with repositories and GitLab-host data accessible to the compromised service context. Connected runners are not automatically compromised, but manipulated pipelines could expose runner environments and alter builds. Signing keys, registry/package tokens, cloud credentials, and publishing secrets are at risk where pipelines or runners can retrieve them; downstream packages, containers, releases, and deployment artifacts must then be considered suspect. Preserve logs and compare affected artifacts against trusted commits, build provenance, signatures, and registry history before rotating every secret indiscriminately.

Take the dissenting position on NICT's App-to-Backend warning. Nadia and Lena agree it is a documented attack class linked to multiple Japanese incidents, but not a bounded campaign. Argue where an enterprise could overreact: reverse-engineering a public app is not itself compromise, exposed API details are not equivalent to exploitable authorization, and an estate-wide August log review may be disproportionate. Then define the concrete exposure ... [arg clipped]

Nadia and Lena are right about the attack class, but the scope matters. Fact: NICT says attackers analyzed public Android applications to recover backend endpoints, API structure, and parameters, then tailored attacks to weaknesses in authentication, authorization, or server-side input validation. Assessment: Decompiling an APK is reconnaissance, not proof of compromise; exposed API details are not equivalent to exploitable authorization. If every request is authenticated and authorization is enforced per user, action, and object, knowing the route and JSON schema buys an attacker very little.

I would not begin with an estate-wide review of every log since August simply because NICT recommends that date range. First define the exposed resource set: publicly distributed apps, their production backend FQDNs and API-gateway stages, internet-reachable routes, and endpoints returning sensitive data or invoking privileged functions. Prioritize systems where API keys or “official app” request formats are treated as identity, object ownership is not checked, input reaches interpreters or administrative functions, or several apps share authentication middleware. Search those API, WAF, authentication, and application logs for NICT’s published IP indicators and abnormal object enumeration or repeated parameter manipulation; NICT cautions that an IP match alone does not establish compromise. Expand backward and estate-wide only if there are hits, shared vulnerable components, missing telemetry, or unexplained data access.

For the cloud blast radius, the backend flaw is only the first edge in the graph. A control-plane incident additionally requires the compromised API or workload to expose credentials, permit code execution, or run under an overprivileged AWS IAM role, Azure managed identity, or GCP service account. That is the concrete exposure threshold I would use. The CSP owns isolation and operation of its managed platform; the customer owns API authorization, gateway policy, workload identity permissions, and logging. “Mobile app analyzed” is therefore a review trigger—not an automatic declaration that the whole cloud estate has been breached.