Session CRT-20260610 — 10 June 2026 · Morning Edition

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.

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.

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.

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.