Ivanti Connect Secure Gets Incident Response, Not a Patch-Only Fix

CVE-2026-104935 is being chained on Ivanti Connect Secure 22.8R2.4 and earlier for unauthenticated root execution; reporting says UTA0576 stole LAPS passwords and BitLocker recovery keys, deleted logs, and attempted to evade integrity checks, while one privilege-escalation fix remained pending. Separate confirmed facts from assumptions, define when an exposed appliance should be treated as compromised despite a clean Integrity Checker result, and give the exact first-shift response sequence. Take a position a CISO can act on tonight, and identify what evidence would justify a less aggressive response.

Halil, the confirmed chain is ugly: Volexity observed UTA0576 repeatedly exploiting a then-current 22.8R2.4 appliance beginning October 3. The chain combined authentication bypass, file-write/RCE behavior, and a separate privilege-escalation flaw to reach root. Volexity also observed targeting of LAPS passwords and BitLocker recovery keys; CISA warns that commands can execute in memory and therefore escape Integrity Checker detection. Ivanti fixed CVE-2026-104935 in 22.8R2.5 and specified 25.x releases, while Volexity says the separate privilege-escalation fix remained pending. Attribution, exploitation beyond the documented activity, and whether any particular exposed appliance was accessed remain assumptions—not confirmed facts.

My position tonight: an affected, internet-facing appliance exposed since October 3 should enter incident response—not routine patch management—if independent telemetry cannot exclude exploitation. A clean Integrity Checker result is not exculpatory when the burglar operates in memory, erases footprints, and knows where the alarm sensors are. Treat it as compromised if there is unexplained process or network activity, missing or altered logs, credential access, anomalous LDAP/AD queries, password spraying, packet capture, or any telemetry gap covering the exposure period. Exposure alone does not prove compromise, but exposure plus inadequate off-box evidence is enough to presume it operationally.

First shift, in order: (1) remove the appliance from internet service without destroying evidence; (2) preserve configuration, available volatile evidence, and external firewall, DNS, authentication, LDAP/AD, EDR, and flow logs; (3) activate incident response and hunt from off-box telemetry rather than trusting Integrity Checker; (4) rebuild or recover the appliance through Ivanti’s recovery procedure and place it on a fixed release—do not merely patch the potentially controlled system in place; (5) from clean systems, rotate the appliance’s AD/service credentials, administrator credentials, relevant LAPS passwords, and exposed BitLocker recovery keys, then revoke active sessions; (6) hunt downstream systems for use of those secrets and restore access only after validation. A less aggressive patch-and-monitor response is defensible only with evidence that the appliance was not internet-reachable during the exploitation window, or complete independent telemetry showing no exploit requests, command execution, suspicious egress, directory-secret access, or log gaps.

Hundreds of French supermarkets reportedly suffered manipulated refrigeration controllers, defrost cycles, temperatures near 50°C, fires, food loss, and equipment damage, apparently through a service-provider path involving aging Danfoss controllers. Determine the most plausible control and trust failures without inventing an unproven intrusion path. Specify immediate safety, containment, recovery, and third-party-access decisions for retailers and refrigeration providers, including the point at which remote connectivity should remain disabled.

The immediate risk is physical, not merely cyber: uncontrolled defrost can spoil food, overheat equipment, and create an electrical or fire hazard. Fact: reporting describes remotely forced defrost and loss of chilled and frozen stock. Separately, Claroty documented vulnerabilities in affected Danfoss AK‑SM 800A controllers and recommends firmware R4.3.1 or later plus removal of Internet-exposed management; that research does not prove which controller, vulnerability, credential, or service-provider mechanism was used here. Unknown: the initial-access path, exact fleet size, and whether attackers changed controller logic or only supervisory setpoints and schedules.

My assessment is a Level 2 supervisory-control compromise reached through an inadequately bounded remote-management trust relationship crossing the Level 3/OT perimeter. The scale is consistent with—though does not prove—shared credentials, an over-privileged provider account, a common management platform, poor customer/site isolation, or directly exposed administration. The deeper control failure was allowing remote authority to command hazardous operating states without sufficiently independent local temperature limits, alarms, and authorization controls. We should not assume that Level 1 controller logic or safety safeguards were modified.

Immediately, affected stores should disable the suspect inbound vendor-management path, not sever local controller communications. Put trained refrigeration personnel onsite; inspect for heat, smoke, damaged wiring, abnormal refrigerant pressures, stuck heaters or valves; quarantine temperature-abused food; and establish local alarm monitoring or a fire watch where necessary. Preserve provider, firewall, controller, and configuration logs before rotating provider credentials, API keys, certificates, and shared accounts from clean systems. Recovery should use a known-good configuration, physical equipment inspection, setpoint and defrost-schedule verification, alarm/interlock testing, and staged reconnection under temperature trending. Any firmware or segmentation change must first be validated against the specific model and process—an untested network change that interrupts refrigeration control can worsen the hazard.

Remote provider access should remain disabled until the provider can bound the compromise, rebuild or attest the administration environment, rotate every relevant trust secret, eliminate shared cross-customer access, and demonstrate per-site least privilege, MFA, approved jump-host access, session logging, and an emergency disconnect. Each store must then pass local functional and safety testing before reconnection. If those conditions cannot be demonstrated—especially for unsupported controllers—keep remote access off, operate locally with increased staffing, and prioritize controller replacement rather than restoring the old trust path.

Assess the SlugFest weakness in which abandoned GitHub repository names could be reclaimed and valid OIDC tokens exchanged for npm Trusted Publishing credentials, potentially affecting more than 1,500 packages. Explain what GitHub's configuration-expiration and immutable-repository-binding changes close, what residual risk remains for package maintainers and consumers, and what must be audited now. Distinguish demonstrated feasibility from evidence of malicious package publication, and challenge the idea that the platform fix alone ends the incident.

Halil, the key distinction is publication authority, not package ownership. Reporting on SlugFest says npm accepted a valid GitHub OIDC identity tied to mutable owner/repository names. If a Trusted Publishing configuration remained unused and the original repository slug became available, a researcher-controlled repository and matching workflow could obtain an OIDC token and exchange it for short-lived npm publishing credentials. The cited “1,500-plus packages” and “10 million downloads” describe the potential blast radius; the reporting demonstrates the chain on controlled assets but does not establish malicious publication to third-party packages.

The platform changes break that chain in two places. Configuration expiration removes unused Trusted Publisher entries after 48 hours, collapsing what had been an indefinite repository-reclamation window. Immutable repository binding then associates established trust with GitHub repository and owner IDs rather than relying solely on reusable names, so deleting, renaming, transferring, or recreating a repository under the same slug should not inherit the original publication authority. That addresses the stale namespace binding, but it does not prove that nothing happened before enforcement, remove any version already published, or address ordinary compromise of a legitimate maintainer or GitHub Actions workflow.

Maintainers should now audit every npm package’s Trusted Publisher entry against the canonical GitHub repository, especially configurations created but never successfully used. Review repository deletions, renames, transfers and ownership changes; compare npm publication timestamps and provenance with expected GitHub Actions runs, commit SHAs, tags, immutable repository IDs and workflow files; and investigate unexpected versions, install scripts, maintainers or dist-tags. Also restrict id-token: write, protect release environments and tags, and remove dormant publishing configurations rather than relying on expiration.

Consumers need to trace this through lockfiles, SBOMs, artifact caches and deployed images: identify newly introduced versions of potentially exposed packages, validate hashes and provenance against the legitimate source history, and quarantine unexplained releases. A platform fix is containment of the trust primitive—not incident closure. Closure requires evidence that historical package versions and downstream artifacts match maintainer-authorized source and workflows.

Autheo's suspected Hyperlane configuration exploit reportedly minted 19 million unbacked THEO on Base, preceded a roughly 92% price collapse, and was followed by about 700.8 ETH reportedly bridged to Ethereum. Establish what is actually verified, distinguish minted amount, attacker proceeds, token-market destruction, and recoverable assets, and define the technical, governance, exchange, and on-chain reconciliation gates required before bridge or token operations resume. Do not accept the headline loss figure without proving it.

Halil, the defensible baseline is 19 million unauthorized THEO minted on Base, not a proven $1.7 million protocol loss. Reporting ties that mint to a Hyperlane message from origin domain 2127 invoking the token’s handle function, followed by roughly 54 swaps through THEO/USDC, Uniswap v4, and Hydrex pools. PeckShield-linked reporting says the swaps yielded 700.8 ETH, but the public evidence shown here confirms only one bridge leg—280.45 ETH leaving Base and 278.52 ETH reaching the corresponding Ethereum wallet. The separate 119 million THEO claim remains unconfirmed by Autheo. CryptoTimes (opens in new tab) Crypto.news (opens in new tab) CryptoRank (opens in new tab)

These are four different ledgers: 19 million THEO is unauthorized issuance; 700.8 ETH is alleged gross attacker proceeds; the roughly 92% price collapse is market-value destruction; recoverable assets are only traceable balances still held by the attacker or frozen by an intermediary. They cannot be added together as “loss.” We currently cannot establish net proceeds after execution costs, total liquidity-provider losses, holder losses, the attacker’s current ETH balance, or any KYC-exchange exposure. Until every swap and bridge receipt reconciles, I would describe 700.8 ETH as reported—not proved end to end.

Before resumption, I want four gates closed: technical—reproduce the malicious message, establish the incident-block TrustedRelayerIsm configuration, identify who controlled the relayer key, rotate all relevant keys, and replace any single-relayer production trust; governance—publish deployment artifacts, administrator and signer history, configuration-change logs, and a supply snapshot; exchange—keep deposits, withdrawals, and conversions suspended until venues receive the canonical contract, compromised-address list, and treatment of tainted balances; on-chain—reconcile every zero-address mint, all approximately 54 swaps, LP asset outflows, Base-to-Ethereum transfers, residual balances, and any subsequent exchange deposits. Autheo’s own warning was not to buy, sell, or bridge THEO while the investigation continued. Crypto.news (opens in new tab)

My assessment remains route-specific: the evidence points toward an unsafe deployment or trusted-relayer/configuration failure, not yet a demonstrated Hyperlane core vulnerability. No bridge or token-market restart should occur until an independent party can reproduce that conclusion and the 19 million versus 119 million supply discrepancy is resolved.

Alex confirms that UTA0576 combined an Ivanti authentication bypass, file-write/RCE behavior, and a separate privilege-escalation flaw to reach root, with reported access to LAPS passwords and BitLocker recovery keys. Define the identity blast radius: which directory, local-admin, recovery, service, session, certificate, and appliance trust artifacts require rotation or invalidation, in what order, and what evidence would justify narrowing that... [arg clipped]

Alex, FACT: Volexity reports root-level execution on the Ivanti appliance, targeting device-stored credentials and Active Directory material including LAPS passwords and BitLocker recovery keys, followed by log deletion. CISA’s Ivanti guidance says to assume user and service-account credentials stored on a compromised gateway are exposed. ASSESSMENT: this is compromise of an authentication broker—the blast radius includes anything the appliance could store, decrypt, relay, or authenticate during the dwell window.

My revocation order would be:

1. Contain and preserve evidence: isolate the appliance while capturing memory, disk/core data, configuration, and surrounding network telemetry. Replace or rebuild it from trusted media.
2. Terminate live access: invalidate VPN and administrator sessions and cookies. For implicated identities, revoke IdP sessions, refresh tokens, cached Kerberos tickets, and third-party OAuth grants—not merely passwords.
3. Replace appliance trust: reset local administrators and the enable password; rotate API keys, LDAP bind and other service credentials, RADIUS shared secrets, SAML/OIDC client credentials, SSH keys, and integration secrets. Revoke and reissue exposed TLS, SAML signing/decryption, client/device, and appliance certificates before trusting the rebuilt gateway.
4. Rotate privileged directory access: start with Tier-0/domain administrators and service accounts whose credentials were stored on or traversed the gateway. Force new LAPS passwords for affected endpoints. For exposed BitLocker recovery passwords, create and escrow new recovery protectors, then remove the old protectors.
5. Finish the downstream estate: rotate remaining user, service, automation, and workload credentials associated with observed appliance sessions or lateral movement. Re-enroll the rebuilt appliance only after all dependencies use new secrets.

UNKNOWN: public reporting does not identify exactly which accounts, keys, or recovery records were copied. Narrowing therefore requires affirmative evidence: a complete inventory proving a secret was neither resident on nor transmitted through the appliance; directory audit evidence showing precisely which LAPS and BitLocker attributes were read; VPN/IdP/RADIUS logs mapping every session to an identity; endpoint and domain-controller telemetry excluding lateral authentication; and evidence that private keys were hardware-protected and non-exportable. Missing appliance logs cannot justify narrowing because UTA0576 reportedly deleted evidence. Password rotation without session, token, certificate, and recovery-key invalidation is only half an eviction.

Triage the evidence—not CVSS alone—across today's urgent patch lane: actively exploited FortiMail CVE-2026-104286, exploited Windows Shell CVE-2026-96951, and the five KEV additions affecting ProFTPD, ISC BIND, Apache Struts, Strapi, and ONLYOFFICE Docs. Tell a CISO what must be acted on during the current shift, what can enter accelerated normal patching, and where KEV status does not establish local co... [arg clipped]

The current-shift lane is FortiMail CVE-2026-104286 and Windows Shell CVE-2026-96951: identify affected systems, apply vendor mitigation or updates immediately, and review pre-patch telemetry because exploitation is confirmed. Fortinet’s fixed FortiMail releases are still described as upcoming for affected 8.0 and 7.6 branches; until available, containment and vendor mitigations cannot wait. Windows Shell has broad endpoint reach and enables Mark-of-the-Web bypass, so prioritize high-risk user and administrative endpoints first.

For ProFTPD, BIND, Struts, Strapi, and ONLYOFFICE Docs, inventory and exposure validation belong in this shift. Patch any vulnerable internet-facing instance now; internally isolated instances with verified controls can enter accelerated normal patching. KEV confirms exploitation somewhere—it does not prove your system was targeted, compromised, or linked to a named actor. Attribution confidence is low, and no responsible ATT&CK campaign mapping is possible from KEV status alone.

Now separate from Autheo, assess the Startale ERC-7579 reusable-initialization attack and the Safe module-permission failure that exposed an approximately $7.73 million rsETH position. Identify the verified loss/exposure for each, explain why ordinary signature security did not prevent these events, account for the reported MEV front-running without confusing it with recovery, and define the account-by-account freeze, reconciliation, module-rem... [arg clipped]

These are separate authorization failures. For Startale, the available evidence demonstrates an exploitable ERC-7579 initialization path but does not establish a defensible aggregate loss. The reproduced attack deploys prefunded counterfactual accounts through the factory and performs malicious re-initialization in the same transaction while transient authorization remains active. Loss must therefore be reconciled per account from deposits, unauthorized outflows, and surviving or returned balances. DeFiHackLabs (opens in new tab) Shattered (opens in new tab)

For Safe, Bitquery reports that a 2,900-rsETH position was affected: 2,882.37 rsETH transferred to 0xC70f00…, while 17.63 rsETH was sold for 18.95 ETH, with a separate recipient receiving the skim. Treat those figures as source-reported until transaction-by-transaction reconciliation establishes ownership, net proceeds, and current custody. Bitquery also reports a later copycat transaction involving 50 aEthrsETH; that is a separate incident entry, not part of the 2,900-rsETH total. Bitquery (opens in new tab)

Reported MEV front-running is not recovery. It may have redirected assets away from the original exploiter, but funds count as recovered only when returned to the victim or frozen under enforceable custodial control. Ordinary signatures did not prevent either event because no signature forgery was required: Startale’s authorization failed during initialization, while the Safe’s enabled module provided an execution route outside the normal owner-threshold path. ERC-7579 requires installation authorization and reversion when a module is already enabled. ERC-7579 (opens in new tab)

Before reopening, reconcile every account’s opening balance, prefunding transaction, deployment salt and implementation, initialization or module events, approvals, transfers, swaps, MEV recipients, and ending balance. Startale needs a one-time initialization invariant tested against same-transaction batching, plus migration of exposed accounts. Each affected Safe needs the implicated module and gateway removed, Permit2 and token approvals revoked, all module-originated calls reviewed, and remaining assets migrated where necessary. Resumption requires independent review, account-level reconciliation, and proof that any claimed recovery is back under victim or cooperating-custodian control.

NICT links reverse engineering of public Android applications to discovery and exploitation of backend APIs through SSRF, RCE, SQL injection, IDOR, and BOLA in recent Japanese corporate intrusions. Translate that into a bounded enterprise test plan: how to inventory app-exposed endpoints and protocols, test authorization safely, hunt for server-side exploitation, and avoid treating an indicator match as proof of compromise. State what mu... [arg clipped]

Halil, FACT: NICT’s LETTICE team describes attackers analyzing publicly available Android apps to identify backend interfaces and then pursuing server-side weaknesses. That means the Android binary is the reconnaissance surface; it does not by itself establish that the app or a handset was compromised. UNKNOWN: the material available here does not provide enough victim-level telemetry or universal indicators to infer compromise at any specific enterprise.

1. Build the app-to-backend inventory. Under written authorization, collect every production APK/version—including regional and legacy releases—and statically extract hostnames, URL paths, deep links, network-security configuration, native-library strings, embedded schemas, and authentication references. Dynamically exercise only enterprise-owned test accounts on an instrumented device, recording HTTP(S), HTTP/2 or gRPC, WebSocket, and any proprietary traffic. For each discovered interface, register the endpoint, method, environment, owning team, authentication scheme, permitted roles, object identifiers, data class, and available logs. Reconcile that list against API gateways, DNS, cloud load balancers, and service catalogs; unknown or abandoned endpoints are the priority.

2. Test authorization without turning assessment into intrusion. Use two isolated tenants, multiple roles, and sacrificial records. Replay valid requests while changing one control at a time: authentication absent or expired; token audience or scope; another test user’s object ID for BOLA/IDOR; lower-privileged roles for function-level authorization; and unadvertised methods or parameters. Keep production testing read-only, rate-limited, monitored, and equipped with a kill switch. Validate SSRF, SQL injection, and RCE in staging or a production-identical clone: use a controlled callback domain for SSRF, non-destructive database canaries, and inert execution markers rather than shells. Do not probe cloud-metadata addresses, access real customer objects, dump tables, or establish persistence.

3. Hunt and set a hard evidentiary threshold. Correlate API-gateway/WAF, application, identity, database-audit, DNS, egress, cloud-control-plane, and workload/EDR telemetry by timestamp and request ID. Hunt for endpoint enumeration, abnormal methods or encodings, sequential cross-user object access, authorization mismatches, injection errors, unexpected outbound callbacks, application processes spawning interpreters, bulk database reads, new credentials, and unexplained administrative changes. A matching IP, user-agent, URI, payload fragment, or public endpoint is only a lead. Call it an attempted exploit when the request reached the service; call it confirmed compromise only when corroborating evidence shows an unauthorized server-side effect—data access, state change, command execution, credential creation, or outbound activity attributable to that request. A WAF block alone is not compromise, and missing logs mean unknown, not clean. Preserve evidence first; then restrict the endpoint, revoke affected tokens or embedded credentials, enforce authorization server-side, and redeploy the fixed service.

Close the operational discussion after hearing the table. Alex confirms active Ivanti chaining to root and says a clean integrity check cannot clear exposure; Marcus says identity recovery must cover LAPS, BitLocker, appliance and directory trust artifacts. Sara puts the French refrigeration event in the safety lane, not ordinary IT restoration. Tomas says SlugFest compromised publication authority through mutable GitHub repository identity, while GitHub's expiration and immutable-binding mitigations reduce but do not erase downstream risk. Viktor distinguishes Autheo's verified 19 million unauthorized THEO mint from unproven net loss, and treats Startale and Safe as separate initialization and module-authorization failures. Lena places FortiMail CVE-2026-104286 and Windows CVE-2026-96951 in the current-shift lane, while the five other KEVs require exposure-led prioritization rather than automatic incident declarations. Nadia calls for an app-to-backend inventory and authorization test plan rather than treating NICT indicator matches as compromise. Produce a decision-ready current-shift playbook, ordered by urgency. For each subject, state the first containment action, the compromise-assessment threshold, and the condition for safe return to service. Break with the panel if any item has been over- or under-prioritized, and preserve separate treatment for each product or incident thread.

Alex’s confirmation moves Ivanti into confirmed-incident handling, while Sara’s safety constraint puts refrigeration first operationally. I would run the current shift in this order:

I break with any attempt to treat all seven KEVs as seven confirmed incidents; that would swamp response capacity without evidence. I also break with treating SlugFest as routine package cleanup—the compromised publication authority makes it a current-shift supply-chain incident. Operations should open three command lanes now: refrigeration safety, Ivanti/enterprise identity, and software/crypto containment, each with its own evidence log and restoration authority.

Your ordering puts the French refrigeration incident first operationally because of immediate physical safety, while Ivanti remains the most urgent enterprise compromise thread. Reconcile those priorities explicitly rather than forcing one universal ranking. Give me concise stop-work, escalation, and safe-return criteria for (1) a retailer with affected refrigeration, (2) an organization with exposed Ivanti Connect Secure, and (3) organizations triaging FortiMail CVE-2026-104286 and Windows CVE-2026-96951 during the same shift. State what evidence changes each decision.

There are two queues, not one universal ranking: refrigeration leads the physical-safety queue, while Ivanti leads the enterprise-compromise queue. During the same shift, FortiMail receives immediate exposure reduction because active exploitation is reported; Windows remains current-shift work but should not trigger an estate-wide shutdown without product-specific evidence.

Complete the remaining NICT app-to-backend decision. Nadia says public Android apps should be treated as maps of backend interfaces, then tested safely for SSRF, RCE, SQL injection, IDOR, and BOLA, with indicator matches treated only as leads. Define the minimum current-week control and hunting package for an enterprise that publishes Android apps: ownership, endpoint discovery, authorization testing, server-side telemetry, escalation thresholds, and the evidence required before declaring compromise.

NICT’s reporting justifies a current-week validation sprint, not automatic incident declaration. Nadia is right: the public APK is an interface map, while compromise must be proven from server-side evidence.

Minimum current-week package

1. Ownership — Day 1: Assign one accountable application owner and one backend service owner for every Play Store package ID. Map each to API gateway, service account, datastore, data owner and on-call team. Freeze releases for orphaned endpoints until ownership is established.
2. Endpoint discovery — Days 1–2: Decompile the enterprise’s production APK/AAB and extract URLs, API routes, deep links, GraphQL endpoints, third-party SDK destinations and deprecated API versions. Reconcile these against DNS, API-gateway, WAF, load-balancer and cloud-service inventories. Every discovered endpoint needs an owner, authentication method, data classification and expected mobile-app version.
3. Authorization testing — Days 2–4: Using approved test accounts, test horizontal and vertical access by changing object IDs, tenant IDs, roles, HTTP methods and tokens. Include undocumented and older endpoints. Use controlled callback domains for SSRF; perform SQL-injection and RCE testing in staging unless production testing is explicitly authorized and non-destructive. A client-side user-ID comparison is not sufficient protection against BOLA; authorization must be enforced for each object and function server-side.
4. Server telemetry — this shift: Record request/trace ID, endpoint template, method, authenticated subject, tenant, authorization decision, application version, token issuer/audience, source address, response status and outbound destination. Add database-error, unexpected process-creation, cloud-metadata access and unusual DNS/egress visibility. Do not log raw access tokens or unnecessary personal data.
5. Hunting: Look for sequential or cross-tenant object access; repeated 401/403 responses followed by a successful 2xx; deprecated endpoints receiving new traffic; token audience mismatches; URLs targeting localhost, private ranges or cloud metadata; database syntax errors; application-server child processes; and unexplained outbound callbacks.

Escalation threshold: An NICT indicator, exposed endpoint or scanner match is only a lead. Escalate containment when server telemetry shows sustained authorization probing, SSRF attempts, injection attempts or token abuse. Declare compromise only when correlated evidence demonstrates a crossed security boundary: successful unauthorized object or cross-tenant access, protected-data retrieval, attacker-controlled backend egress, database execution, command/process execution, unauthorized state changes or forged session use. Preserve API, identity, database and cloud audit records before blocking; then revoke affected tokens, restrict the specific endpoint and widen containment according to the backend trust path.