Sunday, 7 June 2026

Magecart family runs its skimmer out of Stripe — payload in customer metadata, stolen cards exfiltrated back through api.stripe.com

Sansec's forensics team documented a card-skimming family that routes both payload delivery and exfiltration entirely through Stripe's legitimate API (Sansec, 2026-06-04). The actor creates a Stripe customer object and stores the skimmer JavaScript in that customer's metadata fields; at checkout the skimmer is fetched from api.stripe.com, captures full card number, CVV, expiry and billing address, then writes the stolen data back to Stripe by creating new fake customer records — so both inbound payload and outbound theft look like ordinary Stripe API traffic (BleepingComputer, 2026-06-04). The entry point is a malicious Google Tag Manager (GTM) container injected into checkout pages of Magento / Adobe Commerce stores; the skimmer-hosting Stripe customer record was created 2025-12-24, indicating a campaign running since at least late 2025. Maps to T1059.007 (JavaScript) and T1071.001 (Application Layer Protocol: Web). Why it matters to us: api.stripe.com is universally allow-listed in CSP script-src/connect-src and WAF egress rules on payment sites, so the standard "block unknown exfil endpoints" control is blind to this. Detection has to move server-side: inventory GTM container IDs against an approved list, alert on Stripe customer-creation events that don't map to real orders, inspect customer-metadata fields for encoded JavaScript, and run file-integrity monitoring on checkout-page tag configuration rather than relying on browser-side CSP.

Hijacked polyfill[.]io domain reactivates, surfacing native browser credential prompts on sites that never removed legacy script tags

The polyfill[.]io CDN domain — seized and weaponised in the June 2024 supply-chain attack that affected more than 100,000 sites — became active again in late May 2026 and began answering with HTTP 401 authentication challenges, which browsers render as native credential dialog boxes (BleepingComputer, 2026-06-05). Any site still loading a <script src="…polyfill[.]io…"> tag — a failure documented across many organisations since 2024 — now prompts visitors for credentials in a dialog that appears to originate from the trusted site. Toshiba published a warning on 2026-06-02 telling users to click Cancel without entering anything (Toshiba, 2026-06-02); Muji issued a parallel notice stating it had not confirmed unauthorised access or data leakage (BleepingComputer, 2026-06-05). This is mechanically distinct from the 2024 redirect-to-malicious-JavaScript attack: the harm here is HTTP-401-induced credential phishing, not script injection, so neither party has confirmed exfiltration — but both advised affected users to change passwords. Maps to T1195.002 (Compromise Software Supply Chain). Why it matters to us: The exposure is entirely a function of stale third-party references, which most organisations underestimate. Grep all rendered HTML, CMS templates, and CDN-inclusion lists for polyfill[.]io with any subdomain or path; replace with the legitimate polyfill.com / polyfill.top mirrors or self-hosted polyfills, and enforce Subresource Integrity (SRI) on all third-party scripts. Web-proxy/SWG logs showing 401 responses from polyfill[.]io pinpoint pages that still load the script.

CVE-2026-10881 — Google Chrome (ANGLE graphics engine): out-of-bounds read/write enabling sandbox escape (CVSS 9.6)

Google shipped Chrome 149 (stable 149.0.7827.53/54) on 2026-06-02, patching 429 vulnerabilities — the largest single-release count in Chrome's history, with over 100 rated critical or high (Google Chrome Releases, 2026-06-02; SecurityWeek, 2026-06-05). The highest-severity externally-reported fix is CVE-2026-10881 (CVSS 9.6), an out-of-bounds read and write in ANGLE — Chrome's graphics-translation layer that maps WebGL/GPU calls to the host graphics API — which SecurityWeek reports remote attackers could exploit to escape Chrome's sandbox via a crafted HTML page, with no interaction beyond visiting the page. The sandbox-escape class is the consequential one for enterprises: a renderer compromise chained through ANGLE yields code execution in the browser process, the launch point for subsequent host privilege-escalation chains. No in-the-wild exploitation has been reported. Chrome auto-updates, but managed and extended-stable fleets routinely lag; verify deployment has reached 149.0.7827.53+ via asset inventory or the ADMX update policy, and confirm no MDM version-pin is holding endpoints back. Maps to T1203 (Exploitation for Client Execution).

CVE Summary Table

The table consolidates the CVE-bearing items across this brief; only CVE-2026-10881 is a § 2 trending-vulnerability entry — the Keycloak and FFmpeg rows are cross-references to § 5 and § 3 respectively.

An autonomous AI agent finds 21 zero-days in FFmpeg for ~$1,000 — nine numbered (CVE-2026-39210 to -39218), parser bugs up to 23 years old

Security startup depthfirst ran an autonomous AI analysis agent over FFmpeg's ~1.5 million lines of C and produced 21 confirmed, reproducible zero-days — each with a proof-of-concept input — for an estimated compute cost of about $1,000 (depthfirst, 2026-06-02; The Hacker News, 2026-06-06). Nine carry CVE identifiers (CVE-2026-39210 through CVE-2026-39218); twelve more are fixed but unnumbered. The classes are predominantly heap and stack overflows in parsers and demuxers — the TS (transport-stream) demuxer, VP9 decoder, and the AV1 RTP depacketizer — and several had been latent for 15–20 years, with one service-description-table stack overflow dating to 2003. The AV1-over-RTP overflow is the most operationally pointed because it is network-reachable without special flags, which matters for any service that ingests untrusted RTSP/RTP media. All bugs are fixed upstream; downstream and embedded copies vary. Why it matters to us: Two things for defenders. First, FFmpeg is embedded far beyond the obvious media players — browser stacks, Electron apps, conferencing clients (Teams/Zoom), surveillance/VMS transcoders, and Python wheels — and many ship their own non-auto-updating build, so SBOM/runtime inventory of bundled libavcodec/libavformat is the most reliable way to find exposure. Prioritise hosts that parse externally-sourced media or accept RTP/RTSP streams, and isolate media-processing services from internal networks. The open verification step for each environment is twofold: confirm whether your distribution has shipped the FFmpeg release carrying the upstream fixes (the fixes are upstream; distro packaging lag varies), and establish whether the network-reachable AV1-over-RTP path is actually exercised by any service you run (for example a WebRTC or RTP media pipeline) rather than assuming the parser is dormant. Second, the $1,000-for-21-bugs cost ratio is a signal that parser-class discovery against widely-embedded C libraries (libpng, zlib, libxml2) is now cheap enough to expect more of — treat embedded-parser memory safety as an accelerating attack surface. Maps to T1203 (Exploitation for Client Execution).

SANS ISC: WeTransfer-delivered JavaScript stages a steganographic image loader ("Evil MSI background") on Cloudflare Workers and R2

SANS ISC handler Xavier Mertens documented a resurgence of an image-steganography delivery chain (SANS ISC, 2026-06-05). A >2 MB JavaScript file ("Remittance Advice.js"), distributed via a legitimate WeTransfer link and padded with do-nothing junk loops, hides functional code that: decodes a ROT13-obfuscated payload into an environment variable; fetches an MSI-installer background image (a JPEG) from a Cloudflare Workers (*.workers.dev) subdomain that carries the next stage via steganography (Base64 with A→# substitution to evade naive scanners, delimited by IN-/-in1); loads a decoded .NET DLL that is a trojanised fork of the open-source Microsoft.Win32.TaskScheduler library to establish Scheduled Task persistence at logon; then pulls a further payload from a Cloudflare R2 (*.r2.dev) bucket. The final payload was still under analysis at publication. The infrastructure choice — Cloudflare Workers + R2 — leans on Cloudflare's reputation to bypass category-based web filtering. This is a single-source SANS ISC diary [SINGLE-SOURCE]; the chain (not a specific actor) is the takeaway. Maps to T1027.003 (Steganography), T1059.007 (JavaScript), T1059.001 (PowerShell) and T1053.005 (Scheduled Task). Why it matters to us: Detection concepts: alert on wscript.exe/cscript.exe spawning PowerShell with environment-variable-expanded or Base64 payloads (Sysmon EID 1); flag first-seen *.workers.dev and *.r2.dev connections immediately following a WeTransfer download in proxy logs; hunt for scheduled tasks created by wscript/mshta parents; and EDR-rule on .NET assembly loads from a TaskScheduler-derived DLL outside the genuine Windows Task Scheduler path.

Keycloak 26.6.3: privilege escalation via OAuth token-exchange and SSRF in the EU public sector's reference identity platform

Why this is the deep dive. Keycloak is the open-source IAM that underpins SSO, SAML and OIDC federation across a large share of EU public-sector and EU-institution deployments, and it is the upstream for the Red Hat build of Keycloak common in DACH government estates. On 2026-06-04 the project released 26.6.3, fixing 16 CVEs as documented in the release notes (Keycloak, 2026-06-04). There is no reported in-the-wild exploitation, so this is a patch-and-harden item rather than an active-incident one — but the failure modes sit precisely in the identity-protocol machinery (OAuth token exchange, OIDC token endpoint, WebAuthn registration, refresh-token rotation) that this audience builds detections around, and an internet-reachable Keycloak is by definition exposed.

The token-exchange privilege escalation (CVE-2026-9704). The release notes describe this lead issue as "Privilege escalation via silent subject_token removal in token exchange" (Keycloak, 2026-06-04). Keycloak's standard (RFC 8693) token-exchange grant takes a subject_token identifying the principal whose token is being exchanged; per the release-notes title, silently removing that parameter is not rejected as it should be but instead yields a privilege escalation — a low-privilege client obtains a token it should have had to supply and prove a subject for. The relevant prerequisite is that the token-exchange feature is enabled (it is not on by default in all profiles, but is widely turned on for service-to-service and impersonation flows). Maps to T1550.001 (Use Alternate Authentication Material: Application Access Token) and T1078.004 (Valid Accounts: Cloud Accounts).

SSRF via the OIDC token endpoint (CVE-2026-4874). An attacker able to reach the OIDC token endpoint can coerce Keycloak into issuing server-side HTTP requests to attacker-chosen targets, turning the identity server — which typically sits with network reachability into sensitive internal segments — into an SSRF pivot for internal-service reconnaissance. Because Keycloak is usually permitted to talk to internal directories, databases and admin endpoints, the blast radius of SSRF here is larger than on a typical edge web app.

The rest of the cluster worth knowing. CVE-2026-8830 is a missing server-side validation of WebAuthn credential registration — a malicious authenticator can submit unvalidated attestation data, which can undercut the assurance of phishing-resistant MFA enrolment (T1556.006, Modify Authentication Process: Multi-Factor Authentication). CVE-2026-9802 is a refresh-token replay window: a server restart resets startupTime, allowing reuse of rotated refresh tokens even when revokeRefreshToken=true, giving a post-restart replay opportunity (T1550.001). CVE-2026-9792 is a Resource-Owner-Password-Credentials (ROPC) grant bypass of client-policy enforcement. CVE-2026-37977 reflects Access-Control-Allow-Origin from an unverified JWT azp claim on the UMA endpoint when Authorization Services / UMA is enabled — a CORS-trust break.

Detection concepts (no IOCs). Token-exchange abuse is visible in Keycloak's own event log: alert on token_exchange events where the subject_token is absent yet a token is issued, and on exchanges that cross a privilege boundary (low-privilege client → high-privilege service-account audience). For the SSRF, watch for outbound connections originating from the Keycloak service account/host to non-allow-listed internal or external addresses correlated with token-endpoint requests. For the WebAuthn flaw, audit credential-registration events for attestation formats that do not match your enrolment policy. For the refresh-token window, correlate refresh-token-grant successes immediately following a Keycloak restart against the expected revocation state.

Hardening / remediation. Upgrade to 26.6.3 across all editions including the Red Hat build. If token exchange is not required, disable the feature flag — that removes the CVE-2026-9704 path entirely. Place the OIDC/admin endpoints behind network restrictions and enforce strict egress filtering from the Keycloak host to blunt the SSRF. Re-validate that phishing-resistant MFA enrolment is gated by an attestation policy, and review revokeRefreshToken behaviour around maintenance restarts. CVSS scores for the individual CVEs were not yet published at the time of the release notes; treat exposure by reachability and feature-enablement, not by a score.