Session CRT-20260607 — 7 June 2026 · Afternoon Edition

This Belgian ruling is procedurally bold but doctrinally orthodox. The summary-proceedings judge ordered immediate reimbursement under Belgian Economic Law Code Article VII.44 — the national transposition of PSD2’s liability framework — while preserving the bank’s right to prove gross negligence in subsequent full proceedings. Crucially, the court rejected the premise that simply entering credentials on a fraudulent website automatically satisfies the high threshold for gross negligence. Under PSD2 provisions on unauthorized transactions — reflected in Article 73 and echoed in the EBA’s guidance — the payment service provider already bears the burden of proving fraud or gross negligence. This is not a reversal of the burden of proof; it is a judicial correction of the banking sector’s routine practice of treating any phishing incident as de facto gross negligence.

I assess this as an early enforcement signal rather than a national outlier. PSD2 already allocates primary liability to the PSP, but member states have applied the negligence exception unevenly. The trajectory under the upcoming Payment Services Regulation is toward even tighter constraints on that exception. Industry opposition — visible in ESBG position papers arguing that PSD2 already sufficiently protects payers — confirms that Brussels is actively considering stronger consumer-redress obligations, and the shift from directive to directly applicable regulation will eliminate lingering national variance.

For concrete compliance actions: First, stop auto-denying phishing claims on “gross negligence” grounds without objective, documented evidence. Second, establish liquid reserves for summary-judgment reimbursements, because these orders are provisionally enforceable — cash must leave the house before any final merits determination. Third, rebuild evidence-collection protocols around objectively provable negligence indicators, as courts are now demanding proof rather than inference. Fourth, task your regulatory affairs team with tracking the PSD3/PSR trilogue; the momentum is toward near-automatic reimbursement with only a narrow fraud/negligence carve-out.

Look, if the Antwerp liability standard propagates across the EU, I model an annual cost migration from retail customers to banks of roughly €800 million–€1.2 billion. Here is the base: the EBA/ECB joint 2025 fraud report puts 2024 EU credit-transfer fraud losses at €2.2 billion, up 16 percent year-on-year, and explicitly flags APP scams as the high-damage-per-transaction growth engine. In more than half of reporting countries—including Belgium—payment service users currently bore over 70 percent of reported fraud losses. The ruling reimburses €49,958 immediately and shifts the burden to the bank to prove gross negligence in court.

To get to sector exposure, I take the APP-heavy slice of that €2.2 billion credit-transfer pool. If roughly €1.2 billion–€1.5 billion ties back to phishing, vishing, and APP-type schemes—and banks suddenly swallow the 70 percent share customers previously absorbed—that lands at €840 million–€1.05 billion. Call it roughly €1 billion annually.

For trajectory: the EBA reports a 16 percent year-on-year increase in actual credit-transfer fraud losses, while transaction-data from Tietoevry shows attempted fraud rising 43 percent in 2024. If the liability standard spreads while social-engineering volumes grow, best case is confined to unauthorized transaction pools in a handful of jurisdictions, maybe €200 million–€400 million a year. Worst case is APP and real-time vishing payments falling under the same reimbursement logic, pushing the annual shift toward €1.5 billion.

On reserves and insurance: large EU banks would need to roughly double provisions for affected retail channels. I have no current market-wide data on premium repricing for this specific shift, and from my insurance-sector experience, crime-policy deductibles for major banks typically sit in the single-digit to low-double-digit millions of euros—meaning a billion-euro annual migration lands mainly in self-insured layers and will tighten capacity at renewal.

On the business case for controls: if a Tier-1 bank's incremental annual fraud burden under this regime is €75 million–€100 million, a large-scale phishing-resistant-authentication rollout in the €30 million–€40 million range pays back in under two years on a straight loss-avoidance basis. Those are illustrative engineering estimates, not cited figures.

CEO framing—three bullets:
One: stress-test for a €1 billion annual sector-level cost migration if the Antwerp gross-negligence reversal spreads; a bank with mid-single-digit EU market share should model €40 million–€80 million in incremental fraud costs.
Two: reserve impact is front-loaded because claims currently abandoned by customers will now be filed; P&L hit begins the quarter the standard takes hold.
Three: phishing-resistant authentication stops looking like compliance spend and starts looking like loss avoidance with payback inside eighteen months—budget it now.

Here is how these actually work, and why both break the same mental model.

Miasma: AI agents as the trigger, credentials as the propagation engine

The Miasma worm — attributed to threat group TeamPCP — plants a 4.3 MB Bun-based payload in compromised repos, often under .github/setup.js or npm test hooks. The novel part is the execution trigger: it does not wait for a human to run npm install. Instead, it auto-executes the moment a developer opens the repository in an AI coding agent — Claude Code, Cursor, Gemini CLI, or within VS Code Copilot contexts. These agents routinely execute setup scripts, run tests, or build indexes on clone to "understand" the codebase. The agent becomes the unwitting execution environment.

Once running, the payload harvests AWS, Azure, GCP, Kubernetes, npm, and GitHub credentials from the developer’s machine. It then uses stolen tokens to commit itself to other repositories the victim has write access to. I checked with James Okafor, and he confirmed the telemetry problem: EDR might catch the agent spawning an unexpected Bun process hitting cloud metadata endpoints, but the subsequent Git push is an authenticated, properly-tokenized commit. Your CI/CD pipeline sees a legitimate developer action, not an intrusion. That is why containment fails — the worm propagates through compromised identity, not malware. GitHub disabled the 73 affected repos within 105 seconds, but the worm only needs moments to harvest and fork itself across the victim’s accessible repo graph.

Hugging Face Transformers: trust_remote_code=False is not a sandbox

CVE-2026-4372 is a critical flaw in versions 4.56.0 through 5.2.x — a six-month exposure window impacting an estimated 232 million installations. The root cause is the "Hub Kernels" performance feature, which lets from_pretrained() dynamically load optimized attention implementations. Attackers can set _attn_implementation_internal inside a crafted config.json, and that value gets passed unsafely to the kernel loader — triggering arbitrary code execution when the victim simply loads the model.

This is a direct bypass of trust_remote_code=False, because that flag was designed to block custom modeling files, not configuration-driven kernel loading. Pluto Security published a direct comparison table drawing the parallel to PyTorch’s weights_only=True bypass tracked as CVE-2025-32434 — in both cases, loading a model in the presumed "safe mode" is enough to compromise the host.

Tying it to the prior ML supply-chain thread

ChromaToast, LeRobot, and LiteLLM established the template: ML model hubs are code execution surfaces, not passive data registries. CVE-2026-4372 is the latest iteration inside Transformers itself. The pattern is that every time the ML stack adds a shortcut for performance — dynamic kernel loading, automatic model format conversion, agent-driven repo setup — it re-introduces arbitrary code execution around the "safe" flag. My recommendation is to treat from_pretrained() with the same sandboxing you would apply to pip install from an unverified index: isolated network, no secrets in scope, and pinned versions. For the Miasma worm, the fix is pre-execution, not detection: sandbox AI agents so they cannot auto-execute scripts on clone, and enforce commit signing so authentically-tokenized malicious commits cannot merge.

Look, both of these are supply-chain attacks with different physics. Miasma is a living worm that turns your developers’ AI assistants into its replication engine. The Hugging Face issue is a library-level RCE where a supposedly safe flag gets bypassed, which breaks the trust model for anyone running from_pretrained() in a pipeline.

Miasma — detection and containment

Current reporting from StepSecurity and SafeDep confirms the attack chain: the worm plants a 4.3 MB obfuscated Bun-based payload into repos. When a developer opens the repo in Claude Code, Cursor, VS Code, Gemini CLI, or even runs npm test, the payload executes, harvests AWS, Azure, GCP, K8s, npm and GitHub tokens, then uses stolen write tokens to commit itself to every other repo that developer can access, enabling self-propagation across the open-source ecosystem. The commits spoof github-actions <[email protected]> and are unsigned. SafeDep’s analysis flags one malicious commit as f72462d9e5fa90a483062a83e9ffcb2edc57bf7e on mantine-datatable, authored as github-actions.

What actually stops the propagation:

1. Mandatory commit signing at the org level. Unsigned github-actions commits should auto-reject. The worm relies on unsigned spoofing.
2. Pre-commit size gates. Block commits of JS files > 500KB or with high entropy unless human-reviewed. A 4.3 MB obfuscated payload is not subtle.
3. PAT and fine-grained token purge. List every GitHub PAT with repo scope and every fine-grained token with Contents:write. Anything created in the last 72 hours that touches Microsoft/Azure orgs gets rotated tonight.
4. Kill AI agent auto-execution. Disable “run on clone” and npm test autopilot in AI coding tools until repos are audited. That is the trigger.
5. EDR/Suricata rules for Bun exfiltration. Alert when Bun or node processes hit cloud metadata (169.254.169.254) or spawn unexpected child processes. In my experience, expect roughly 10–20% false positives in dev environments — annoying but manageable.

What the CISO does tonight: Run a global org search for unsigned commits authored by github-actions. Cross-reference the known bad hash f72462d9e5fa90a483062a83e9ffcb2edc57bf7e. Rotate every CI/CD secret for any team that forked or contributed to Azure-Samples, Azure, Microsoft, or MicrosoftDocs repos in the last 30 days. Check your GitHub audit log for unexpected git.push events from unknown IPs.

Hugging Face Transformers RCE — decision-ready remediation

Disclosed RCE vulnerabilities in the Transformers library are actively exploitable, and the trust_remote_code=False bypass is especially dangerous because teams treat that flag as a hard boundary.

Patch priority: Treat any internet-facing inference pipeline or CI/CD runner that loads models from Hugging Face Hub as CRITICAL — patch now. But test in staging for 24 hours. I have seen emergency ML library patches break CUDA compatibility and take down inference farms harder than the CVE would have.

What to rotate given CI/CD exposure: Hugging Face Hub tokens (especially write and org tokens), AWS/Azure/GCP credentials embedded in training or inference pods, Docker registry credentials for ML images, Kubernetes service account tokens for namespaces running Transformers, and any SSH deploy keys on model hosting servers. Also inspect .cache/huggingface/ for malicious code/ subdirectories from previous model loads.

Compensating controls if you cannot patch today:

1. Network sandbox model loading. Set TRANSFORMERS_OFFLINE=1 and HF_HUB_OFFLINE=1. Use an internal vetted model mirror only.
2. Model provenance gating. Pin to specific commit hashes. Run picklescan or equivalent before load.
3. Subprocess monitoring. Alert if the Python process loading Transformers spawns bash, sh, curl, or wget. False-positive rate in legitimate inference workloads is effectively zero.
4. Read-only inference containers. Mount the Transformers installation read-only. If the bypass tries to drop a payload, it fails.

Priority matrix — both incidents

• CRITICAL (do today): Miasma — audit unsigned github-actions commits, rotate all affected PATs/CI secrets, disable AI agent auto-execution; Hugging Face — patch staging, rotate HF Hub and cloud pipeline credentials, enable subprocess monitoring on inference hosts.
• HIGH (do this week): Miasma — deploy mandatory commit signing, pre-commit size hooks, remove npm test auto-run on clone; Hugging Face — network-sandbox all model pulls, implement model hash allow-listing.
• MEDIUM (schedule): Miasma — tune EDR for Bun metadata-exfil behavior; Hugging Face — full cache/huggingface hygiene scan, migrate inference to read-only containers.