the threat gazette
Morning Edition 2026-04-16
Vulnerabilities

Cisco Webex critical certificate-validation flaw requires customer-side remediation beyond patching

CVE-2026-20131 CVE-2026-20147 CVE-2026-20180 CVE-2026-20184 CVE-2026-20186 Interlock Ransomware

Cisco has released fixes for four critical vulnerabilities spanning Webex Services and ISE, with the Webex Services flaw — an improper certificate validation issue — explicitly requiring customer-side configuration remediation beyond passive patch application. Five CVEs are associated with this advisory batch: CVE-2026-20147, CVE-2026-20180, CVE-2026-20184, CVE-2026-20186, and CVE-2026-20131. The enriched intel for CVE-2026-20131 maps it to the Secure Firewall Management Center (KEV-listed with a remediation deadline of March 22, 2026, now elapsed) rather than Webex — suggesting this KEV entry originates from a concurrent Cisco advisory rather than the Webex flaws specifically, which as of this writing lack published CVSS scores in the enrichment data. Interlock Ransomware's association with this story cluster is consistent with that group's documented TTPs of targeting Cisco network infrastructure for initial access.

The 'requires customer action' framing from Cisco is the critical operational detail here — improper certificate validation in a unified communications platform has direct man-in-the-middle implications for internal call and messaging traffic, and automated patch deployment alone will not close the exposure. Confirm whether your Webex deployment is fully cloud-managed (Cisco-remediated) or contains any self-hosted components, and pull the specific customer remediation steps from Cisco's advisory before marking this resolved. The elapsed KEV deadline on CVE-2026-20131 for FMC is a separate but concurrent gap worth verifying independently.

Promoted from the analyst's notable rating because Webex sits squarely in the financial-sector collaboration stack and the 'customer action required' caveat means the standard patch-and-forget cadence will leave residual MitM exposure on internal voice and messaging traffic. Treat the Secure Firewall Management Center KEV entry (CVE-2026-20131) as a separate hygiene item — it appears to have been pulled into this cluster by a concurrent advisory rather than the Webex CVEs themselves, and the analyst flags this discrepancy worth verifying against your own Cisco bulletin intake.

2026-04-15
4 sources
+ CVE-2026-20147 · + CVE-2026-20148 · + CVE-2026-20184 · + CVE-2026-20186 · + CVE-2026-20180
Cisco Security Advisory, VulDB, VulDB, VulDB
2026-04-16
1 source
+ CVE-2026-20131 · + Interlock Ransomware
BleepingComputer

Editorial

The sleeper strategic item today is NIST's VulnCon26 confirmation that NVD will permanently stop enriching pre-March 2026 CVEs. That's a structural regression for every downstream tool that treats NVD metadata as ground truth — scanners, SBOM pipelines, risk-scoring engines — and it compounds the "vulnerability management scoring mis-calibrated for current threat reality" point from Thursday's editorial, where 17-year-old Excel bugs were landing in KEV. The Cisco Webex critical disclosure is the tactical expression of the same theme on a shorter horizon: patching is insufficient without customer-side certificate configuration changes, and Interlock Ransomware appearing on the story suggests the window between disclosure and operational abuse is closing fast.

The trust-layer thread continues to compound rather than resolve. McGraw-Hill has now progressed from Wednesday's Scattered Spider Salesforce misconfiguration story into a confirmed 13.5M-record HIBP-indexed breach with ShinyHunters attribution — treat the dataset as credential-stuffing fuel against corporate SSO regardless of direct customer overlap, and note the Booking.com Cl0p/Storm-1865 disclosure adds corporate-travel pretexting material to the same pool. The trojanized Slack typosquat spawning a hidden parallel Windows desktop that inherits live SSO tokens is the evolved form: attackers have stopped trying to defeat MFA and are instead stealing authenticated sessions from trusted collaboration installers, while Sophos's GOLD ENCOUNTER write-up on in-victim QEMU guests for hypervisor-blind staging (with CitrixBleed2 cited as initial access) shows the post-access tradecraft moving into legitimate virtualization to evade EDR entirely.

Notable

Privacy

ShinyHunters publishes 13.5M McGraw Hill Salesforce records; HIBP ingestion confirms full weaponization

Scattered Spider

BleepingComputer's coverage of the McGraw Hill breach provides the more technically specific attribution: ShinyHunters exfiltrated data from McGraw Hill's Salesforce environment in early April and has now published it publicly. McGraw Hill, operating at $2.2B in annual revenue, has a user base spanning students, instructors, and professionals, making the exposed PII a high-value targeting set for secondary social engineering campaigns. The exposed fields — booking-grade personal identifiers combined with educational context — enable highly plausible impersonation of IT support, institutional administrators, or subscription services.

The BleepingComputer attribution to ShinyHunters is the more credible of the two accounts given ShinyHunters' established pattern of Salesforce-adjacent data operations — their attribution is grounded in the group's own leak site activity, not inference. The sibling story (5131, The Register) tags Scattered Spider, likely reflecting the actor tag from the ranking pass rather than source-specific reporting. For financial institutions, the downstream credential stuffing risk is the immediate concern if any employees share credentials between McGraw Hill accounts and corporate SSO.

This is the more credibly-sourced half of a two-story cluster on the same incident — BleepingComputer's ShinyHunters attribution comes from the group's own leak-site activity rather than inference. Pair with the disputed Scattered Spider tag on the sibling Register coverage; the realistic read is the documented Scattered Spider → ShinyHunters access-and-extort handoff pattern that has driven the bulk of 2025–2026 Salesforce-adjacent breaches. Credential-stuffing exposure against corporate SSO is the immediate downstream risk if any staff reused McGraw Hill creds.

Ransomware

McGraw Hill Salesforce breach: 13.5M records leaked, 'limited webpage' framing implausible

Scattered Spider

Educational publisher McGraw Hill has confirmed a breach of its Salesforce-hosted infrastructure resulting in the public release of 13.5 million user records — names, email addresses, phone numbers, and physical addresses — across a 100GB dataset already indexed by Have I Been Pwned. The company's characterization of the source as a 'limited' hosted webpage is inconsistent with the data volume and exposure profile. Attribution is contested: this story's enrichment tags Scattered Spider, while the BleepingComputer coverage (story 5116) specifically names ShinyHunters as the exfiltrating party — a discrepancy that matters operationally, as both attributions may be partially correct given these groups' documented history of split-role collaboration on enterprise SaaS exfiltration operations.

The Scattered Spider / ShinyHunters split is consistent with a known division of labor: Scattered Spider provides initial access via SaaS social engineering and MFA manipulation, ShinyHunters handles downstream data aggregation and public extortion. The 100GB scale and HIBP ingestion confirm the dataset's authenticity and mean it is already fully weaponizable for credential stuffing and pretexted spear-phishing against the 13.5M affected users. McGraw Hill's 'limited webpage' statement is difficult to reconcile with the breach scope and warrants skepticism.

Same incident as the BleepingComputer dossier, surfaced separately because the attribution discrepancy itself is operationally relevant — the enrichment tagged Scattered Spider here while sibling reporting names ShinyHunters. McGraw Hill's 'limited webpage' euphemism for a 100GB exfil is the kind of corporate framing that ages badly; assume the full PII set is in the wild and price accordingly for downstream pretexting against the affected user base.

Social Engineering

Booking.com guest reservation data exposed; dual Cl0p/Storm-1865 attribution suggests post-exfil brokering

Cl0p Storm-1865

Booking.com began notifying customers on April 13 that threat actors accessed guest reservation data including names, email addresses, physical addresses, phone numbers, and booking details — a field set sufficient to construct highly convincing hotel payment redirect or refund fraud operations targeting affected guests. Attribution names both Cl0p and Storm-1865 simultaneously, which is analytically unusual: Cl0p is the Russian ransomware operation known for mass exploitation campaigns (MOVEit, GoAnywhere), while Storm-1865 is Microsoft's designation for a financially-motivated group with a specific focus on travel platform fraud via compromised hotel accounts and booking portal social engineering. The dual attribution more plausibly indicates data brokering between groups post-exfiltration than a joint operation.

Storm-1865 has a documented playbook of using legitimate booking data to impersonate hotel staff and redirect payments from guests — the Booking.com breach data maps almost perfectly to that actor's operational requirements. Cl0p's involvement, if accurate, likely represents the initial exfiltration event with subsequent data sale to Storm-1865 or similar fraud operators. For financial institutions, the corporate travel exposure angle is directly relevant: employees who used Booking.com for business travel now have their itinerary details in threat actor hands, enabling high-credibility pretexted attacks using travel context.

The combined Cl0p + Storm-1865 attribution is the analytically interesting wrinkle — Cl0p does mass exploitation, Storm-1865 runs the hotel-impersonation fraud playbook this dataset is purpose-built for, and the overlap reads as data sale rather than joint op. Direct corporate-travel exposure: any employee booking through Booking.com now has itinerary context sitting in actor inventories, which is exactly the raw material for high-credibility refund and payment-redirect lures aimed at finance and travel desks.

Social Engineering

Trojanized Slack installer spawns hidden parallel Windows desktop session inheriting victim auth state

RDAT

Malwarebytes has documented a campaign distributing a trojanized Slack desktop installer via typosquatting domains that installs a working copy of Slack as cover while simultaneously establishing a hidden parallel Windows desktop session fully interactive to the attacker but invisible to the local user. The technique creates a separate Windows session that inherits the victim's existing authentication state — meaning the attacker gains access to active SSO tokens, browser sessions, and in-memory credentials without needing to perform a separate credential theft step. Delivery relies on typosquat domains reaching users via direct navigation or search engine poisoning; the campaign has no affiliation with Slack the company.

The hidden session mechanism is what elevates this beyond a commodity remote access campaign. By operating within a separate Windows session rather than injecting into the user's active session, it sidesteps both user-observable anomalies and some classes of behavioral endpoint detection that key on the active foreground session. For environments where Slack is in the approved application stack, MDM-enforced application allowlisting and verified download source policies are the structural controls; user training on verifying installer sources matters here but is an incomplete defense given search engine poisoning as the delivery vector.

The hidden-session pivot is what makes this more than another typosquat installer story — by operating in a separate Windows session rather than injecting into the foreground one, the operator inherits live SSO tokens, browser state, and in-memory credentials with no observable user disruption and reduced behavioral-EDR signal. MDM allowlisting of the installer source is the structural control; user-side 'verify the download' guidance is necessary but insufficient against SEO poisoning as the entry vector.

Ransomware

GOLD ENCOUNTER hides PayoutsKing ransomware staging in QEMU guests; 'CitrixBleed2' cited as initial access

Sophos has published research documenting a ransomware campaign attributed to the GOLD ENCOUNTER cluster that abuses QEMU to spin up hidden virtual machines within compromised hosts, using the guest VM as a persistent attacker-controlled environment for credential harvesting, data exfiltration, and eventual PayoutsKing ransomware deployment — all operating beneath host-level endpoint detection visibility. CitrixBleed2 is referenced as an apparent initial access vector, indicating exploitation of a Citrix vulnerability class in the compromise chain. The source entry is extremely content-sparse at 29 words of extractable text, limiting confident technical assessment of the full attack chain.

The QEMU-in-victim technique has precedent in nation-state espionage tooling, but its operationalization in a ransomware deployment chain represents a meaningful capability transfer to the criminal ecosystem — it specifically targets the coverage gap between hypervisor-level visibility and host endpoint agent monitoring. The CitrixBleed2 reference deserves urgent attention if Citrix infrastructure is in your environment; if this references a newly identified Citrix vulnerability class rather than a variant of the original CitrixBleed (CVE-2023-4966), that warrants a separate investigation thread. The Sophos full report should be pulled for detection signatures and IOCs before relying on this thin entry alone.

Hypervisor-in-victim is a nation-state technique now firmly in the criminal toolkit, and it specifically targets the gap between host-EDR and hypervisor-layer telemetry — your guest-VM-in-host hunt logic should not be theoretical at this point. The 'CitrixBleed2' reference is the urgent open question: pull the full Sophos report before treating this as a CVE-2023-4966 retread, because if it points to a new Citrix vulnerability class the access-layer exposure model changes materially.

Social Engineering

BlobPhish: year-long campaign renders phishing UI entirely in-browser via blob: URIs, defeating network detection

UPPERCUT

ANY.RUN has documented an active credential phishing campaign, running since 2024 and dubbed BlobPhish, that abuses the browser Blob API to construct phishing pages client-side via JavaScript — the malicious HTML content is generated in-process from a `blob:` URI and is never transmitted over the network as a conventional URL fetch after initial page load. This architecture fundamentally bypasses URL reputation systems, transparent web proxies, and network-based phishing detection controls, as the phishing content materializes entirely within the browser process with no external reach-back for the page itself. The campaign has maintained operational continuity for over a year, confirming effective evasion across diverse enterprise security stacks.

This is a genuine detection architecture gap, not vendor noise dressing up a known technique. The `blob:` URI scheme is a first-class browser feature used legitimately by countless web applications for file handling, so blanket blocking is off the table. The realistic detection surface is endpoint-level browser telemetry that observes in-process navigation events and form submission destinations within `blob:` contexts — specifically requiring security tools with deep browser process visibility rather than network or proxy layer controls. Standard SIEM network telemetry will be structurally blind to the phishing page content by design.

Genuine architectural gap rather than vendor scarewriting — the malicious DOM never crosses the wire after initial bootstrap, so URL reputation, transparent proxies, and network DLP are structurally blind by design. Detection moves into in-process browser telemetry, which most enterprise stacks underweight relative to network signal. Worth a specific question to your endpoint vendor on blob:-context form-submission visibility before relying on existing controls.

Geopolitical

NIST confirms NVD will permanently abandon enrichment of pre-March 2026 CVEs

At VulnCon26 on April 15, NIST computer scientist Harold Booth formally confirmed that the National Vulnerability Database will cease enriching CVEs published before March 2026, a capacity decision driven by record CVE volume growth that the agency cannot scale analyst resources to match. This means the overwhelming majority of the CVE corpus will have permanently incomplete or absent CVSS scores, CPE/CPE-A affected product mappings, and associated metadata in NVD going forward, with no announced remediation path. Any vulnerability management workflow that treats NVD as a canonical or authoritative enrichment source inherits these gaps structurally, not as a transient data lag.

This is a quietly systemic problem because the NVD's CVSS scores and CPE mappings are the foundational data that scanner vendors, SIEM enrichment pipelines, SBOM tooling, and SSVC workflows all inherit — often without explicit dependency declaration. The practical impact is sharpest for automated workflows processing older CVEs surfaced in legacy system audits, penetration tests, or SBOM analysis, where a missing CVSS score or CPE mapping will silently degrade risk scoring accuracy. CISA's Vulnrichment project, OSV, and vendor-direct advisories are the realistic supplementary sources; EPSS scores remain usable for exploitation likelihood prioritization regardless of NVD completeness.

Quietly one of the more consequential structural changes of the year for vulnerability management — every SBOM tool, scanner, and SSVC workflow that treats NVD as authoritative has just inherited a permanent metadata gap on the long tail of historical CVEs, with no scheduled remediation. CISA Vulnrichment, OSV, and vendor-direct advisories become load-bearing rather than supplementary; EPSS remains intact and arguably becomes the more reliable prioritization signal for older CVEs going forward.

Briefs

Vulnerabilities

Path traversal in HKUDS OpenHarness

CVE entry for path traversal vulnerability in HKUDS OpenHarness with minimal technical detail or exploitation context.

CVE-2026-40503
Vulnerabilities

XSS in WSO2 API Manager

CVE entry for cross-site scripting vulnerability in WSO2 API Manager with minimal technical context provided.

CVE-2024-4867
Vulnerabilities

XXE in WSO2 API Manager Publisher

CVE entry for XML external entity reference vulnerability in WSO2 API Manager Publisher with limited technical detail.

CVE-2024-8010