Satine Sentinel: June 26, 2026

This week the attackers didn’t need to write anything new. They needed a public PoC, a stale OAuth token, a hashing migration nobody finished, and one customer account that could see past its own boundaries. Cisco’s Unified CM flaw went from proof-of-concept to root-level webshell in under 24 hours. The FortiBleed credential dataset we covered last week nearly tripled in size and earned emergency advisories from CISA and the UK’s NCSC. A Salesforce integration vendor’s abandoned prototype credential turned into a CRM data leak across hundreds of downstream customers. And a Canadian electricity utility learned that a single account, exploiting an authorization flaw, could see information belonging to everyone else.

This week: how fast a published exploit chain actually gets weaponized in the wild, what changed in FortiBleed’s blast radius since last week, why a forgotten OAuth token is now a bigger supply chain risk than most zero-days, and what a thin utility disclosure tells you about its own incident response maturity.

In Less Than 24 Hours: Cisco Unified CM SSRF Flaw Weaponized Into Root-Level Webshells

What happened:

Cisco patched a critical SSRF vulnerability in Unified Communications Manager (CUCM) and Unified CM SME on June 3, rated CVSS 8.6 but classified Critical due to its path to root-level compromise. SSD Secure Disclosure published a full proof-of-concept and exploit chain this week, and attackers weaponized it inside 24 hours. Security firm Defused observed scanning activity for vulnerable CUCM systems days before disclosure, followed by full-scale automated attacks beginning the weekend of June 21-22 and intensifying on June 24. CISA added the flaw, tracked as CVE-2026-20230, to its Known Exploited Vulnerabilities catalog on June 25, with a mandatory remediation deadline of June 28.

Technical details that matter:

The vulnerability lives in CUCM’s WebDialer service, disabled by default but commonly enabled in enterprise deployments for browser-based click-to-call. The attack chain starts with reconnaissance against the WebDialer Version.jws WSDL endpoint to extract the appliance’s true short hostname, a prerequisite for bypassing SSRF host-header validation. From there, attackers hit the cmplatform installClusterStatusExecute endpoint, injecting a crafted hostname parameter that traverses directories to write a rogue Apache Axis deployment descriptor into a web-accessible directory. That malicious Axis service is then invoked to write a first-stage JSP file-writer, which drops a second-stage command-execution shell, password-protected using credentials lifted directly from the public PoC. Operators are running this through Tor exit nodes for obfuscation, and the activity so far looks like fully automated, opportunistic sweeping rather than targeted follow-on operations: no lateral movement or exfiltration confirmed yet in the initial wave. That can change quickly once a foothold like this is established and sold or handed off.

Why critical institutions should care:

CUCM sits at the center of enterprise voice infrastructure for an estimated 30 million users globally, holding user directories, call routing tables, voicemail data, and frequently a live connection into HR and directory services. A webshell here isn’t a perimeter problem, it’s an interior foothold with reach into identity infrastructure. The three-week gap between patch availability and active exploitation is the more uncomfortable detail: a fix existed and a meaningful share of the install base apparently didn’t apply it before a PoC turned the vulnerability into a same-day attack tool.

Key sources:

Update: FortiBleed Triples in Scale as CISA and UK NCSC Issue Emergency Guidance

What’s new since last week:

Last week’s edition covered FortiBleed at roughly 30,791 confirmed compromised devices. This week, that number nearly tripled. By June 19, independent researchers had confirmed 86,644 working FortiGate credentials across 194 countries, and the disclosure cycle accelerated sharply: CISA issued a formal emergency alert on June 18 urging affected organizations to terminate active sessions, reset all administrative and VPN credentials, and lock down management interfaces. The UK’s National Cyber Security Centre issued a parallel global warning the same day. Fortinet’s own PSIRT published an official analysis on June 19, and for the first time gave a precise technical root cause rather than the general “credential reuse” explanation circulating last week.

Fortinet’s account narrows the mechanism considerably: the company introduced PBKDF2-based password hashing in FortiOS 7.2.11, 7.4.8, and 7.6.1, replacing legacy SHA-256 storage, but administrator passwords on upgraded devices remain stored as SHA-256 hashes until that administrator logs in again post-upgrade. Organizations that upgraded FortiOS without forcing a subsequent admin login left themselves holding cracked-hash-vulnerable credentials on fully patched software. Researcher Kevin Beaumont, working with Hudson Rock, independently verified that a sample of the credentials are authentic and current, and confirmed many of the affected devices remain online and internet-exposed with no indication of remediation as of disclosure. Researchers also confirmed targeting of at least one NATO defense contractor, sharpening last week’s “possible espionage motive” assessment into something closer to confirmed dual-use: financially motivated criminals monetizing access opportunistically, while more capable actors appear to be drawing from the same credential pool for targeted intrusion.

Why critical institutions should care:

This is a patch-doesn’t-fix-it scenario. A device can be running the latest FortiOS and still be sitting on a crackable legacy hash if no admin has logged in since the upgrade. If your organization runs Fortinet perimeter devices and hasn’t specifically verified that every administrator has logged in post-upgrade to force the PBKDF2 conversion, “we’re patched” is not the same claim as “we’re not in this dataset.”

Key sources:

Icarus Extortion Group: A Forgotten OAuth Token Cascades Through Hundreds of Salesforce Customers

What happened:

On June 11, attackers gained access to market intelligence platform Klue’s integration infrastructure using a compromised legacy credential tied to an abandoned third-party integration prototype. They used that foothold to push a code update harvesting OAuth tokens Klue’s customers use to connect to their own Salesforce environments. Klue detected the activity the next day and disabled affected integrations, but by June 16, extortion emails were landing in targeted inboxes giving recipients 48 hours to respond. Salesforce disabled the Klue Battlecards integration platform-wide on June 17. This week, on June 23, the previously unknown extortion group Icarus began publishing stolen data on its leak site, and the confirmed victim list grew to include Huntress, Recorded Future, Tanium, Jamf, Gong, HackerOne, Kudelski Security, Snyk, Insurity, and Sprout Social, with Huntress stating it was among “hundreds” of affected Klue customers.

Technical details that matter:

No malware, no exploited software vulnerability: this ran entirely on credential and token abuse. The initial access vector was a long-disused but still-active credential, originally created for a Klue integration prototype the company had abandoned and apparently never deprovisioned. From there, attackers pivoted into Klue’s backend, stole the OAuth tokens issued to Klue’s customers, and used those tokens to query customer Salesforce instances directly. Because OAuth tokens authenticate the application rather than re-verifying the human behind it, Salesforce had no reason to flag the activity: from the platform’s perspective, Klue was making the request, because Klue’s token was. ReliaQuest observed the attackers generating tokens and running Python scripts to automate API queries against the /services/data/v59.0/query endpoint over an extended period, using blank or generic User-Agent strings to blend into normal integration traffic. Attribution to “Icarus” rests on matching Session Messenger IDs and consistent extortion tactics; the group has no MITRE ATT&CK profile, and researchers have explicitly said they see no evidence linking it to ShinyHunters despite surface-level similarities to prior Salesforce OAuth abuse campaigns.

Why critical institutions should care:

The stolen data, business contacts, sales communications, pricing details, and free-form opportunity notes, looks unremarkable in isolation. At the scale of hundreds of organizations, it’s a ready-made targeting list for spear-phishing aimed precisely at the people managing vendor and partner relationships inside critical institutions. The structural lesson matters more than the specific vendor: a credential created for a project that was abandoned, and never formally revoked, became the single point of failure for every downstream organization that trusted that integration, most of whom had no idea the credential still existed.

Key sources:

London Hydro: An Authorization Flaw Lets One Customer Account See Everyone Else’s Data

What happened:

London Hydro, the electricity distributor serving roughly 170,000 customers in London, Ontario, detected suspicious activity on a single customer account on June 18 and disclosed the resulting breach on June 20. The utility’s CEO stated plainly that “the account was used to exploit a system vulnerability, which allowed access to certain information about other customers.” Exposed data includes names, addresses, email addresses, phone numbers, account and billing numbers, service addresses, pricing plans, contract start dates, and meter information. London Hydro says no financial information, banking details, or government identification numbers were involved.

Technical details that matter:

This is worth being direct about: the public disclosure is thin on offensive specifics, and I’m not going to pretend otherwise. What the CEO’s own description suggests, a single authenticated customer account being used to “exploit a system vulnerability” to reach other customers’ records, is consistent with an authorization flaw such as an Insecure Direct Object Reference in the customer self-service portal, where manipulating an identifier in a request (an account number, a session parameter) returns another customer’s data without the system verifying the requester actually owns it. That’s a reasonable inference from the language used, not a confirmed technical finding, and London Hydro has not disclosed the discovery timeline in detail, whether data was exfiltrated or only viewed, the total number of affected customers, whether extortion was involved, or whether any third party was implicated.

Why critical institutions should care:

This incident is the unglamorous counterweight to the other three stories this week. No nation-state tooling, no public exploit chain, no extortion campaign with a leak site, just an authorization logic flaw in a customer-facing web application, the kind of vulnerability that security teams chase down in nearly every penetration test and the kind that’s trivially easy to miss in production if access checks aren’t enforced consistently across every endpoint. For any institution running a customer or patient self-service portal, billing system, or account management tool, this is a reminder that the unglamorous stuff (does this endpoint actually verify the requester owns the record they’re asking for) remains one of the most common ways PII walks out the door. The sparse public disclosure is also itself informative: it suggests either an investigation still genuinely in early stages, or a level of public communication maturity that critical infrastructure operators should be benchmarking themselves against and improving on.

Key sources:

The Pattern This Week

Every story this week is a variation on the same failure: something that should have been deprovisioned, rotated, or properly scoped wasn’t. Cisco’s flaw needed a maintained patch cadence that a meaningful share of the CUCM install base didn’t keep up with. FortiBleed needed administrators who logged in after a hashing migration to actually finish converting their credentials, and most apparently didn’t. Icarus needed one abandoned integration credential that nobody remembered to kill. London Hydro needed an authorization check that verified the requester actually owned the record being requested.

None of these required a sophisticated adversary. They required defenders to leave a door slightly open, sometimes for years, and attackers who were patient or lucky enough to find it. The Cisco story is the only one here that moved at genuine exploit speed, 24 hours from PoC to active attack, which is the one piece of this week’s pattern that should change how fast your organization treats “patch available” as “patch urgent.”

See you next week.

What Your Business Can Do This Week

If you run Cisco Unified CM with WebDialer enabled, patch now, not on your normal cycle. CVE-2026-20230 went from public PoC to active exploitation in under 24 hours, and CISA’s KEV deadline has already passed. If patching isn’t immediately possible, disable WebDialer entirely; it’s not required for core telephony and the click-to-call convenience isn’t worth the exposure right now. Audit Unified CM logs for unexpected file writes or anomalous outbound requests regardless of patch status.
If you run Fortinet FortiGate devices, verify the hash conversion actually completed, don’t just confirm the firmware version. Being on FortiOS 7.2.11+ doesn’t mean your administrator credentials converted to PBKDF2; that only happens after an admin logs in post-upgrade. Force every administrator to log in now, rotate all administrative and VPN credentials regardless, and enable MFA on every remote-access and admin account if you haven’t already.
Inventory and kill every dormant third-party integration credential, especially OAuth tokens for tools you no longer actively use. The Klue/Icarus breach started with a credential nobody remembered existed. Pull a list of every connected app and integration token tied to your CRM, your cloud platforms, and your collaboration tools, and revoke anything tied to a project that was piloted and abandoned, a vendor relationship that ended, or an integration nobody on the current team can explain.
Test your own customer-facing portals for authorization flaws, not just authentication ones. London Hydro’s incident is a reminder that a valid, authenticated login is not the same as a safe one if the application doesn’t verify ownership on every record request. If you run any self-service portal handling customer or patient data, confirm your last access-control test specifically probed for IDOR-class issues across every account-scoped endpoint, not just login security.

In Less Than 24 Hours: Cisco Unified CM SSRF Flaw Weaponized Into Root-Level Webshells

Update: FortiBleed Triples in Scale as CISA and UK NCSC Issue Emergency Guidance

Icarus Extortion Group: A Forgotten OAuth Token Cascades Through Hundreds of Salesforce Customers

London Hydro: An Authorization Flaw Lets One Customer Account See Everyone Else’s Data

The Pattern This Week

What Your Business Can Do This Week

Like this:

Ready to Strengthen Your Defenses?