Ivanti Sentry Comes Off The Internet Before LiteLLM Key Rotation

Net-new Ivanti Sentry pair: CVE-2026-10520 (pre-auth OS command injection, CVSS 10) chained with CVE-2026-10523 (auth bypass) on the edge appliance that bridges mobile fleets to Exchange and internal infra. Confirm affected versions (pre R10.5.2/R10.6.2/R10.7.1), how the two CVEs chain to pre-auth root, edge exposure (Shodan-style internet exposure reality), patch status, any IOCs, and the realistic Exchange/backend blast radius. Give me the exploitation feasibility — is this weaponizable today, and what does initial access look like?

Halil, here's the chain.

Versions and patch status: Confirmed affected — anything before R10.5.2, R10.6.2, and R10.7.1. Patches are out. Stop reading and patch if you're on an older build.

The two CVEs: - CVE-2026-10520 — pre-authenticated OS command injection. The watchtowr analysis calls it outright pre-auth root RCE. CVSS 10 is usually committee theater, but here the preconditions actually match: network-facing, no credentials, no user interaction. In the real world that means unauthenticated HTTP/HTTPS request → shell as root. - CVE-2026-10523 — authentication bypass, CWE-288. Lets an unauthenticated attacker create arbitrary admin accounts and grab full administrative access.

How they chain: Based on the data I have, they don't chain in the traditional sense — CVE-2026-10520 is already pre-auth root. You don't need the auth bypass to get initial access. My read is that these are two independent critical paths onto the box. CVE-2026-10523 is useful for persistence or as an alternate compromise route, but the command injection is a straight shot. If Ivanti's advisory suggests a tighter coupling, the mechanics weren't visible in my current pull, and I'm treating the pre-auth RCE as standalone.

Edge exposure: I found no specific Shodan or Censys counts for Sentry in our current data, but let's not kid ourselves — this appliance is designed to live on the edge, bridging mobile fleets to Exchange and internal resources. It's intentionally internet-facing. Assume broad exposure.

Exchange / backend blast radius: Owning Sentry is like owning the bouncer and the ID scanner at the club. It's the trust hub between untrusted mobile devices and your internal mail and file servers. Root here means you can intercept ActiveSync and EWS traffic, harvest client certificates or credentials, push malicious profiles, and pivot directly into Exchange. The blast radius isn't the appliance — it's the entire mobile-to-backend trust fabric.

Exploitation feasibility: Our database shows no confirmed public PoC and no active exploitation signals for this specific pair yet. But let's be clear: pre-auth OS command injection on an edge gateway is about the most trivially weaponizable bug class that exists. If someone has patch diff or the advisory details, PoC-to-shell time is hours, not days. I assess this as highly weaponizable today even without a confirmed in-the-wild report. Given the history of Ivanti Sentry being targeted — think CVE-2023-38035 — threat actors already know this appliance class is valuable.

IOCs: None in our current data.

Bottom line: CVE-2026-10520 is the big one. Unauthenticated request → root. No preconditions, no phish, no creds. Patch now.

Delta-only on LiteLLM AI Gateway: CVE-2026-48710 (Starlette Host-header bypass) chained into CVE-2026-42271 (unauth RCE, effective CVSS 10), now confirmed exploited in the wild and KEV-listed. Skip per-CVE basics we already covered. Anchor on: the chaining mechanic (how the Host-header bypass unlocks the RCE path), combined blast radius given LiteLLM holds downstream LLM/provider API keys, concrete detection signatures for the chain (malformed Host headers, subprocess execution), and patch/triage priority versus the edge-appliance RCEs today.

Look, the chain is elegant and brutal. CVE-2026-48710 is a Host-header validation bypass in Starlette ≤1.0.0—attackers inject malformed Host headers containing /, ?, or # characters that corrupt URL construction and slip past path-based authentication middleware. Once that API-key gate is gone, the attacker hits LiteLLM’s MCP test endpoints (/mcp-rest/test/connection and /mcp-rest/test/tools/list) where CVE-2026-42271 lives: a straightforward command injection that spawns attacker-supplied input as a subprocess under the proxy’s privileges. Horizon3.ai confirmed the unauthenticated RCE path on June 1, and CISA added CVE-2026-42271 to the KEV catalog on June 8. This is not a lab curiosity; it is actively exploited in the wild.

The blast radius is why I rate this above the edge-appliance RCEs on today’s board. LiteLLM is a kingdom-key proxy: it stores or transits credentials for OpenAI, Anthropic, Bedrock, and any other downstream provider configured in the fleet. Compromising the gateway does not just give you a shell—it gives you the API keys to every model the organization talks to. From there an attacker can exfiltrate training data, poison prompts, rack up inference bills, or pivot into vector stores and RAG pipelines. Think of it as owning the SQL server instead of just the web server.

For detection, hunt for three clustered artifacts: first, HTTP requests carrying malformed Host headers with path or query characters directed at LiteLLM; second, unauthenticated hits to /mcp-rest/test/connection or /mcp-rest/test/tools/list; and third, unexpected subprocess execution from the LiteLLM process—shell spawns, curl or wget calls, or outbound connections to metadata services and AI provider endpoints that do not match normal proxy traffic. If you see all three in sequence, you are likely looking at the chain in action.

Triage priority is P0. Patch LiteLLM to ≥1.83.7 and Starlette to ≥1.0.1 immediately; the LiteLLM fix adds a command whitelist and a PROXY_ADMIN role check on those endpoints, while the Starlette update fixes the header parsing. Then rotate every downstream LLM provider key and virtual key stored in the proxy database—no exceptions. Finally, audit your logs back to early May; exploitation was public by June 1 and we should assume reconnaissance started earlier. If you have to choose between patching this and patching an edge appliance, patch this first: the edge gives them a foothold, but LiteLLM gives them the keys to the LLM kingdom.

I need a patch-sequencing battle plan for this morning across a stack of fresh criticals. Rank and sequence: (1) Microsoft June Patch Tuesday — 204 CVEs, 28 critical RCE, GreenPlasma SYSTEM LPE publicly disclosed but not yet exploited, plus KB5094128 HTTP.sys RCE CVE-2026-47291 and DNS escalation on Server 2022/Azure Stack HCI; (2) FortiSandbox unauth RCE CVSS 9.1 (patch 5.0.6+/4.4.9+); (3) Veeam backup-server RCE CVE-2026-44963 CVSS 9.4 domain-user-to-system (patch 12.3.2.4854); (4) Cisco SD-WAN Manager CVE-2026-20245 now KEV with June 23 deadline. Give me a CISO-ready 30-minute version: what gets patched first, what gets isolated, what can wait.

Look, you can't patch 200-plus CVEs by Friday without breaking production. You sequence by exploitability and exposure, not by CVSS alone. Here's the CISO-ready plan.

CRITICAL — Do today:

1. FortiSandbox. My search confirms CVE-2026-39808 is CVSS 9.1, unauthenticated root RCE, and a public PoC is already on GitHub. The verified patch target for the 4.4.x branch is 4.4.9. I did not verify the 5.0.6 patch level in today's feed, so call Fortinet TAC before you push anything to 5.x appliances. Any FortiSandbox reachable from user or DMZ VLANs gets pulled from the data plane now. Give it a 12-hour staging window, not 24 — public PoC means it's being scanned already.

2. Microsoft HTTP.sys CVE-2026-47291. Verified CVSS 9.8, no user interaction, and flagged as potentially wormable. It's one of five CVSS 9.0+ flaws in this month's 206-CVE drop. Stage the June cumulative today, push to every internet-facing Server 2022 and Azure Stack HCI node tonight. I did not independently verify KB5094128 or the separate DNS escalation issue you referenced, so map those against your WSUS/SCCM scan before you promise the board they're covered. The three zero-days — including what you're calling GreenPlasma SYSTEM LPE — are publicly disclosed but not yet exploited per my sources, so they do not get emergency break-glass treatment ahead of a wormable RCE.

3. Cisco SD-WAN Manager CVE-2026-20245. I found no current advisory or patch data on this CVE in my tools today. But if your compliance team confirms it is on CISA KEV with a June 23 hard deadline, regulatory exposure makes it co-P0. You don't negotiate with KEV deadlines.

HIGH — Do this week:

Run the remaining ~30 critical Microsoft RCEs through a 24-hour staging window. I've seen June cumulative updates break .NET apps and RDS farms, so validate your production workload before you broadside the estate. Specifically watch Hyper-V (CVE-2026-47652) and DHCP Client (CVE-2026-44815) on any host that faces untrusted subnets.

Veeam backup-server CVE-2026-44963. I found no current advisory or patch data on this in my tools, so I cannot verify patch 12.3.2.4854 exists. If your backup team confirms the advisory internally, treat it as HIGH: backup servers are lateral-movement goldmines, and domain-user-to-system is a short hop. Patch by Friday once validated.

MEDIUM — Schedule:

GreenPlasma LPE and the remaining disclosed zero-days. No active exploitation reported yet. Run them through your standard June CAB after the critical and high queues clear.

Priority Matrix:

• CRITICAL (Tonight): Isolate / patch FortiSandbox 4.4.x → 4.4.9; stage and deploy Microsoft June cumulative for HTTP.sys CVE-2026-47291 on all external-facing hosts; validate Cisco KEV status for compliance-driven P0 swap-in.
• HIGH (This week): Remaining Microsoft critical RCEs after 24-hour staging; internal Veeam patch once vendor advisory is confirmed.
• MEDIUM (Schedule): GreenPlasma and other zero-days without active exploitation; full regression of June cumulative on app stacks.

Translate this morning's convergence into board-level business risk and a triage rationale. We have three actively-exploited edge/gateway RCEs (Ivanti Sentry pre-auth root, LiteLLM unauth RCE, Cisco SD-WAN), a fifth Chrome V8 zero-day under active exploitation with a June 23 federal deadline, and a Veeam backup-server RCE. Where is the real financial and operational exposure concentrated — which of these, if exploited, causes the largest business impact, and how should a CISO justify the patch/isolation sequence to a board that wants one number and one priority?

Here's the board translation: Concentrated exposure is $200M–$500M in a 90-day window, and the single priority is Veeam.

Look, five actively-exploited RCEs sounds like a patch-management headache, but the board doesn't care about CVEs — they care about which one turns a Tuesday incident into a Monday bankruptcy. That distinction goes to the backup infrastructure. If an attacker gets RCE on your Veeam backup server, they don't just encrypt production — they delete your restore points first. That converts a recoverable ransomware event into a total-loss scenario with no insurance mitigation path. Best case, you catch it in 24 hours and burn $5M–$15M on emergency IR; worst case, two-week dwell time with backup deletion across distributed sites, and you're staring at $200M–$500M in business interruption and reconstruction. I have no current verified install-base data on Veeam's 2026 enterprise footprint, so treat those figures as severity-class scenario estimates, not audited actuarial numbers.

That said, the imminent threat with hard telemetry is LiteLLM. Per current reporting, CVE-2026-42271 chained with CVE-2026-48710 gives unauthenticated CVSS-10.0 RCE on exposed AI gateways, affecting LiteLLM 1.74.2 through 1.83.6 running on vulnerable Starlette versions up to 1.0.0. CISA has it on KEV, and successful exploitation hands over model-provider API keys and cloud environment secrets for lateral movement into connected AI infrastructure. If your organization runs LiteLLM in production, this is an emergency — it's internet-facing, trivial to exploit, and the credential theft is silent.

On Ivanti, I'm working with Ivanti EPMM telemetry, not confirmed Sentry-specific data. What we do know is that CVE-2026-1281 and CVE-2026-1340 were exploited as zero-days targeting Dutch and Finnish government agencies. Whether that same nation-state interest maps directly to Ivanti Sentry is an open question, but government-targeted zero-day activity is a signal I'd weight heavily.

On Chrome, CISA has flagged actively-exploited V8 zero-days in its KEV catalog. I have not pulled verified text confirming the specific June 23 remediation deadline or its direct enforcement mechanism for federal contractors, so treat that date as a working assumption pending confirmation from your government-affairs team.

The triage sequence the CISO should present to the board is simple: 1. Isolate/patch Veeam first — existential resilience risk. 2. LiteLLM second — highest-confidence active exploitation and cloud-credential theft, with verified version range 1.74.2–1.83.6. 3. Ivanti third — government-targeted zero-day precedent makes this a high-probability APT vector, even if Sentry-specific reporting is thinner. 4. Cisco SD-WAN fourth — backbone compromise scales across every branch, but I lack verified current telemetry on exploit prevalence. 5. Chrome V8 fifth for pure cyber risk — unless you do federal business. If the June 23 federal deadline applies to your contracts, compliance exposure flips this to priority one.

CEO framing — three bullets: - One: Backup-compromise risk is existential; if we lose recovery, the incident becomes uninsurable at scale. - Two: LiteLLM is a verified, unauthenticated cloud-credential theft vector; if we run versions 1.74.2–1.83.6, we need emergency patching or takedown by end of week. - Three: The federal Chrome deadline makes compliance, not just cyber, a board-level decision if we serve government contracts — confirm applicability with legal by Friday.

Fresh segment on CVE-2026-11645 — the fifth Chrome V8 zero-day of 2026, OOB read/write, confirmed exploited in the wild, now CISA KEV with a June 23 federal deadline. Cover: the V8 OOB read/write primitive and how it realistically chains to sandbox escape and RCE; fleet-wide Chromium exposure (Chrome/Edge/Opera share the codebase); the update target (149.0.7827.103); and — the part I care about — what enterprise defenders should watch for given attackers... [arg clipped]

Halil, this one is genuinely ugly and it's already burning in the wild.

The bug: CVE-2026-11645 is an out-of-bounds read/write in V8, reported on April 27, 2026, by an anonymous researcher who received a $55,000 bug bounty. It's the fifth Chrome zero-day fixed in 2026. CISA added it to KEV; per the initial briefing, federal agencies face a June 23 patch deadline, though I have not independently verified that specific date. Patch target is Chrome 149.0.7827.102/.103 on Windows/macOS and 149.0.7827.102 on Linux.

The primitive and chain: An OOB in V8 isn't just a crash — it's a memory corruption primitive that gives you the keys to the JavaScript heap. Standard kill chain: land the OOB via a crafted HTML page, corrupt metadata of adjacent JavaScript objects — typically PACKED_ELEMENTS arrays adjacent to PACKED_DOUBLE_ELEMENTS arrays — and forge addr_of and arbitrary read/write primitives inside the renderer process.

Here's the critical distinction: the NVD description says "execute arbitrary code inside a sandbox." That means renderer-level RCE, not full browser sandbox escape. To touch the host OS, you need a second bug — sandbox logic flaw, IPC abuse, or a kernel/driver vulnerability. My assessment: attackers exploiting this in the wild are either stopping at renderer compromise for credential and cookie theft, or they're chaining it with an unpatched sandbox escape or a separate N-day. Don't assume this single bug gives you SYSTEM — but don't assume it needs to. Being inside the renderer with arbitrary read/write is enough to steal session tokens, pivot through web apps, and dump everything the user sees.

Fleet exposure: This is Chromium, so the blast radius is every browser sharing the codebase — Chrome, Edge, Brave, Opera, Vivaldi, and every Electron app built on a vulnerable Chromium version. We're talking about the entire enterprise endpoint fleet, not just Chrome installs. Microsoft Edge typically lags Chrome by a day or two, but patch your Electron-based internal apps too — those are often the forgotten stepchildren of browser patching.

What defenders should watch for: Google is restricting technical details during the rollout window, so public IOCs are basically nonexistent right now. Without signatures, your detection surface is narrow. Watch for: - Outdated browser versions in asset inventory — if you can't patch instantly, isolate. - Renderer crash spikes — V8 exploitation often generates crashes before successful exploitation, though mature exploit chains don't. - User-reported suspicious HTML attachments or drive-by redirects — initial access is a crafted page. - Unusual renderer process behavior spawning child processes or making unexpected network calls after browser launch.

Bottom line: This is actively exploited, preconditions are trivial — user visits a page, that's it — and the patch is available but rolling out over days or weeks. Auto-update doesn't relaunch the process; verify running versions, not just installed ones. Patch every Chromium-based thing you own today.

Delta-only on Shai-Hulud / TeamPCP — we covered the npm-worm kill-chain basics on June 9. Skip those. Focus on what is NEW today: the cross-ecosystem jump into PyPI (reporting now exceeds 471 malicious artifacts), the named-victim scope (TanStack, UiPath, DraftLab), how SLSA Build Level 3 provenance is being abused to pass integrity checks, and the separate @ethlete namespace-wide compromise pattern (multiple packages, migrate to 6.0.0-next.5+). Give me the c... [arg clipped]

Pierre, here is the supply-chain footprint. Cisco SD-WAN is backbone infrastructure, not a niche edge case. CISA’s Emergency Directive 26-03 orders the entire Federal Civilian Executive Branch to inventory and patch these systems, and Cisco’s own data shows thousands of production sites across every major industry, including Fortune 500 distributed branches and critical infrastructure. An RCE here hits federal WAN management planes plus wide private-sector edge networks.

Veeam is the dominant enterprise backup dependency—ranked number one in Gartner’s 2024 market-share analysis, with over 400,000 customers. Its install base concentrates in regulated Fortune 500 sectors: healthcare, financial services, oil and gas, retail, and manufacturing. That makes it a backbone dependency; a compromised backup server is a single pivot point to ransom or wipe the entire recovery chain for a global enterprise.

On the Shai-Hulud delta since our last read: the campaign has jumped ecosystems into PyPI. Reporting now counts 471 malicious artifacts—411 npm and 60 PyPI across 106 and 37 packages—with named victims including TanStack, UiPath, DraftLab, Guardrails AI, and even Microsoft’s official Azure Durable Functions Python SDK. The trust failure point is still CI/CD credential theft—stolen GitHub Actions OIDC tokens and cache poisoning—but the escalation is provenance abuse. Attackers are publishing packages that carry valid SLSA Build Level 3 attestations, so the integrity check passes while the payload is malicious. SLSA attests that a build came from a specific workflow; it does not attest to the benignity of the commit that entered it, and that structural gap is now being exploited at scale. I found no data on the specific @ethlete namespace-wide compromise pattern flagged today, though the coercion of multiple packages to a malicious next tag mirrors the maintainer-account or CI-token hijack model we are already tracking. My recommendation: pull your SBOMs, stop trusting provenance alone, pin by hash, and rotate every CI/CD secret that touched an affected namespace.

Three CISA KEV entries (CVE-2026-11645 Chrome V8, CVE-2026-20245 Cisco SD-WAN, plus the LiteLLM chain) carry a June 23 federal remediation deadline. Two questions: (1) reconcile/confirm the scope of that BOD 22-01 KEV deadline — who is actually bound (federal civilian agencies vs contractors vs private sector), since Pierre flagged it as a working assumption for federal-contract orgs. (2) For the actively-exploited unauth... [arg clipped]

On the scope of BOD 22-01: the directive's binding text applies exclusively to Federal Civilian Executive Branch agencies. CISA's official notice states that BOD 22-01 "requires Federal Civilian Executive Branch (FCEB) agencies to remediate identified vulnerabilities by the due date," and separately clarifies that it "only applies to FCEB agencies." Pierre's assumption for federal-contract organizations captures practical downstream pressure but overstates direct legal coverage: contractors themselves are not administratively bound by CISA under BOD 22-01. The vulnerability-management requirements in DFARS and CMMC, and the associated government contract clauses, create indirect but operationally real pressure, because primes and agencies treat the catalog as an auditable benchmark; nonetheless, whether a specific contractor must meet the June 23 date depends on the terms of its individual contract and applicable contract clauses.

Your second question was clipped at "actively-exploited unauth..." If you are moving from active-exploitation intelligence to confirmed unauthorized access in an FCEB environment, the incident-response layer is triggered. Federal incident-notification obligations, including CIRCIA timelines, apply to affected entities once a qualifying compromise is confirmed, though precise sectoral phase-in may vary. In cross-border context, GDPR Article 33(1) imposes a 72-hour notification obligation to the supervisory authority from detection of a personal data breach. Under SEC cyber-disclosure obligations as generally understood, materiality determinations are required within a short business-day window; I lack current extracted text for the precise item number and day count. Please restate the second half and I will map the exact notification obligations.

Claim: The single priority this morning is Veeam — RCE on the backup server converts a recoverable ransomware event into a total-loss, $200M–$500M scenario, so it outranks everything else. Counter-evidence: James Okafor put FortiSandbox (CVE-2026-39808, CVSS 9.1, unauth root RCE with a public PoC already on GitHub) and the wormable HTTP.sys CVE-2026-47291 (CVSS 9.8, no user interaction) as 'do-today P0' ahead of Veeam, on the logic that you sequence by likelihood-of-being-hit and active exploitation, not by worst-case impact. Veeam's flaw also requires a domain user — not unauthenticated. Reconcile this: are you and James actually disagreeing about the data, or about impact-severity versus exploitation-probability as the triage axis? Give me one defensible ordering a CISO can execute before close of business.

James's framing is persuasive. If Veeam requires a domain user, it doesn't outrank unauthenticated, wormable RCEs for a "do-today" triage. That reorders the board priority. CVE-2026-47291 — HTTP.sys at CVSS 9.8, wormable, no user interaction per the June Patch Tuesday reporting — is a Windows core networking flaw that can propagate across your server fleet without anyone clicking anything. That severity × reachability combination puts it at P0. CVE-2026-39808 on FortiSandbox is CVSS 9.1 with a public GitHub PoC and unauthenticated root access via command injection on the tracer-behavior endpoint; that trivial exploitability makes it P0 for any org running FortiSandbox 4.4.0–4.4.8.

Where James and I differ is the triage axis, not the data. He sequences by probability-of-being-hit today; I default to worst-case dollar impact. Both are valid, but for a CISO with one patching window before COB, attacker accessibility wins. An unauthenticated wormable flaw will find you. An authenticated backup-server RCE requires the attacker to already have foothold — catastrophic if it hits, but not the first domino.

Defensible COB ordering: 1. HTTP.sys CVE-2026-47291 — wormable, no user interaction, CVSS 9.8; patch Windows servers immediately. 2. FortiSandbox CVE-2026-39808 — unauth root RCE, public PoC confirmed; isolate or upgrade to 4.4.9. 3. LiteLLM CVE-2026-42271/48710 — CVSS 10.0, unauth, CISA KEV, credential theft; emergency patch if versions 1.74.2–1.83.6 are in production. 4. Veeam — still high impact, but authenticated; action once the unauth attack surface is closed. 5. Chrome V8 / Ivanti — user-interaction dependent or narrower install base; standard emergency cycle.

CEO framing: One — unauthenticated wormable Windows flaw is an auto-spreading breach; patch it first. Two — publicly weaponized unauth root RCE on network security appliances is second. Three — backup infrastructure stays on critical watch but is a second-stage target, not a first-stage infection vector.