Cloud

Scattered Spider Moves Vercel Data From Breach to Active Sale

Scattered Spider

Vercel confirmed a breach of its internal systems after Scattered Spider claimed exfiltration and began marketing the stolen data for sale — a escalation beyond the initial disclosure tracked in the companion story (5994). The supply chain risk profile here is substantially higher than a typical SaaS breach: Vercel manages deployment pipelines, CI/CD integrations, and environment variable storage for a large portion of the JavaScript/Next.js ecosystem, meaning the blast radius potentially extends to secrets and API keys belonging to Vercel's customer base. Scattered Spider's move to sell rather than ransom is consistent with a failed extortion attempt or a deliberate strategy to maximize monetization across multiple buyers.

The critical concern for financial institutions is not Vercel's own customer records — it's whether environment variables from Vercel-hosted build pipelines are in scope. Any .env contents, cloud provider credentials, or service account tokens stored in Vercel's infrastructure should be treated as potentially compromised until Vercel provides scope confirmation. If your organization or any critical third-party vendors use Vercel for deployment, treat this as a secret-rotation trigger event now, ahead of official notification.

This is the afternoon's actual news and the reason today's slate stopped being quiet — the morning's thesis of a weekend operational hold on ShinyHunters/Scattered Spider activity was wrong within four hours. The compressed breach-to-sale window (no public extortion step between story 5994's disclosure and this sale) is the tell: assume Vercel-hosted environment variables, CI tokens, and deploy secrets for any downstream customer are already in a buyer's hands, not pending negotiation. Watch for targeted phishing into Vercel customers over the next 2–3 weeks using project metadata lifted from the platform itself.

Editorial

Vercel's confirmation that Scattered Spider is inside their build platform — and is actively selling the take — is the structurally important item today, and it slots cleanly into the thread tracked all week: SDLC infrastructure emerging as a distinct target class. Trivy (April 18) compromised the scanner layer; Vercel compromises the deploy layer five days later, with the Buchanan plea in between doing precisely nothing to perturb cohort tempo — which closes out the "arrests as lagging indicator" read from Saturday. Treat any Vercel-hosted third-party pipeline as a preemptive secret-rotation trigger ahead of formal notification, and assume build-time env vars, OIDC tokens, and deploy hooks in that footprint are burned.

Two structural items close out quietly. NIST's NVD enrichment retreat became formal policy as of April 15, ending the ambiguity flagged since last week — any vuln program still treating NVD CVSS as canonical is now silently dropping non-priority CVEs from its queue, and the weighting pivot to EPSS / VulnCheck / vendor-native feeds is today's work, not next quarter's. The Apple-notification phishing abuse is a genuinely new class worth flagging to awareness teams: injected content rides inside legitimately Apple-signed mail, so SPF/DKIM/DMARC all pass and sender-domain heuristics fail silently — while Synnovis at 22 months post-Qilin (South London NHS trust still on paper pathology) gives us the empirical upper bound for third-party-dependency BCP modeling, not a pessimistic scenario.

Notable

Ransomware

Vercel Confirms Scattered Spider Compromise of Internal Systems

Scattered Spider

Vercel disclosed that Scattered Spider compromised internal systems, with a confirmed 'limited subset of customers' affected and an external IR firm engaged. This is the initial breach disclosure; story 6023 covers the subsequent escalation in which the same actor is actively selling the exfiltrated data. Scattered Spider's targeting of cloud infrastructure and developer platform companies is well-established — their documented playbook involves social engineering into internal tooling, lateral movement via cloud-native identity, and rapid exfiltration before detection. The 'limited subset' framing in early-stage IR disclosures should be read as a lower bound, not a ceiling.

The jump from internal access to active data sale (per story 6023) with no public extortion demand in between suggests either the extortion attempt failed quietly or was bypassed entirely — worth noting because it compresses the window between breach detection and data exposure for any affected customers. Watch for targeted phishing against Vercel customers in the coming weeks using any contact or project data extracted from their systems.

The initial-disclosure half of today's Vercel pair; read alongside story 6023, which is the same incident four hours later with the data already on the market. 'Limited subset of customers' in an early-stage IR statement from a platform that holds deployment secrets for much of the Next.js ecosystem is a lower bound, not a ceiling — and Scattered Spider's documented cloud-identity lateral-movement playbook means the interesting blast radius is downstream customer infrastructure, not Vercel's own records.

Social Engineering

Phishing Lures Riding Inside Legitimate Apple Notification Mail

CALENDAR

Threat actors are embedding phishing lures within Apple's own legitimate account change notification emails, originating from Apple's mail infrastructure and therefore passing SPF, DKIM, and DMARC cleanly. The technique abuses Apple's account update notification flow to deliver what appear to be purchase confirmation scams or credential harvesting lures embedded in the body of an otherwise authentic email. This completely bypasses sender-domain and header authentication heuristics — the most common technical controls deployed against phishing. No specific threat actor has been attributed to this campaign.

This matters specifically because it defeats the security awareness heuristic most trained users rely on: checking that the sender domain is legitimate. It is legitimate — that's the whole point. Apple could close this by restricting the content that appears in notification emails, but there's no indication that's imminent. The mitigating factor is that the lure payload still needs to be convincing on its own merits; this isn't a one-shot compromise, just a significantly elevated delivery mechanism.

Novel in that it structurally defeats the 'check the sender domain' user-training heuristic that most awareness programs still lean on — the mail is genuinely from Apple's infrastructure, authentication all passes, and the payload rides in the body of an authentic account-change notification. Mitigation is on Apple to restrict notification content, and there's no indication that's imminent. Expect copycat abuse of equivalent transactional-notification flows from other large consumer platforms once the technique gets documented more widely.

Vulnerabilities

NIST Formalizes End of Full NVD Enrichment for Non-Priority CVEs

Effective April 15, NIST's National Vulnerability Database will no longer provide CVSS scores, CPE product lists, or severity analysis for CVEs that don't meet an internally-defined 'priority' threshold. This formalizes what had been a de facto situation since early 2024, when NVD quietly fell behind on enrichment without explanation. The criteria for 'priority' classification remain opaque in available reporting, meaning the proportion of new CVEs that will receive no official severity rating is currently unknown — but historical NVD backlog analysis suggests it is substantial.

Any vuln management program using NVD as the canonical severity source needs to audit that dependency. The practical alternatives — EPSS, VulnCheck, OSV, vendor-native advisories — have been filling this gap operationally for a while, but NVD's formal retreat makes the failure mode structural and permanent rather than a recoverable backlog. The asymmetric risk here is that 'lower priority' CVEs without NVD scores still get exploited in the wild; your tooling just silently drops them from queue.

The de facto situation since early 2024 is now formal policy — the failure mode is permanent, not a recoverable backlog. The real operational risk is asymmetric: CVEs that miss NIST's opaque 'priority' bar still get exploited in the wild, they just arrive at your vuln queue without a severity score and get silently deprioritized by tooling. Audit anything in your stack that treats NVD CVSS as the canonical ingestion field; EPSS, VulnCheck NVD++, OSV, and vendor-native advisories are the operational replacements, each with different coverage gaps.

Ransomware

Qilin's Synnovis Attack Still Disrupting NHS Pathology Into Year Two

Qilin Qilin

South London and Maudsley NHS Foundation Trust (SLaM) remains on paper-based pathology workflows nearly two years after Qilin ransomware hit Synnovis, their pathology vendor, in June 2024 — electronic requesting and reporting are still offline as of publication. This is a long-form operational impact report rather than a new incident, but the continued disruption timeline is analytically significant. The recovery lag reflects the structural problem of healthcare organizations being downstream of a compromised vendor they cannot directly control or accelerate the recovery of.

For financial institutions with critical third-party dependencies, the 18-plus-month recovery horizon here is a useful upper-bound data point for business continuity planning — particularly for vendors providing real-time data or processing services where manual fallback is operationally painful. Qilin is not a documented financial services targeter, but the vendor-dependency failure pattern is directly applicable to any sector.

Not a new incident but a rare clean data point for third-party-dependency recovery modelling: 22 months in and SLaM is still on paper requesting and reporting because the vendor — not the trust — is the failure domain. Qilin doesn't target financial services as a priority, but the structural lesson (you cannot accelerate a vendor's recovery from the customer side) applies directly to any real-time processing dependency where manual fallback is operationally painful. Worth pulling into the next round of critical-vendor BCP tabletop inputs as an explicit upper bound.