>
av.Amit VijayanCYBERSECURITY & RESEARCHLet\u2019s connect
Back to the library

Cyber news

Daily Cyber Threat Brief — November 9, 2026: French bank loses ~€118 million in supplier-platform heist

AV
Amit Vijayan
10 min read
Thumbnail for: Daily Cyber Threat Brief — November 9, 2026: French bank loses ~€118 million in supplier-platform heist

Case file — Lead incident: Crédit Mutuel Arkéa, a French cooperative banking group with €211.5 billion in assets and more than 5.8 million members, has confirmed a cyberattack that let attackers move money out of the bank's own accounts. Blockchain investigator ZachXBT first flagged suspicious withdrawals from centralized crypto-exchange accounts on November 2, estimating that up to €118 million (about $133 million) had left as USDC and USDT stablecoins. On November 4 the bank confirmed the attack, saying the intruders reached its network through a service provider's platform — which it has not named — then used the bank's own account, not customers' accounts, to send transfers to other banks and convert the funds into cryptocurrency. The bank says customer assets are unaffected, some transfers were delayed while systems were suspended, and some funds were blocked. It has not confirmed the €118 million figure, saying only that it can validate the order of magnitude; AFP reported a provisional bank estimate of about €100 million. The attacker is unidentified; ZachXBT says it is highly unlikely to be North Korea's Lazarus Group. Status: incident contained, investigation ongoing with police and judicial authorities; the amount recovered is unknown.

Incident timeline

DateDevelopment
October 5, 2026Layer3 Intel's observation window opens; residential proxy exits begin appearing on the White House network (AS2650).
October 28, 2026Iris Ohyama finds a suspicious file in an external cloud service and suspends Iris Plaza and related systems the same day.
October 29, 2026Iris Ohyama discloses the incident and notifies Japan's Personal Information Protection Commission and police.
November 1–2, 2026About $108.8 million in stablecoins leaves OKX, Kraken, and Crypto.com accounts to 15 wallets (Bitquery); ZachXBT flags more than $106 million in suspicious withdrawals on November 2.
November 3, 2026ZachXBT raises the estimate to more than $133 million and names Crédit Mutuel Arkéa.
November 4, 2026Arkéa confirms the attack and fraudulent transfers; Layer3's window ends with 236 proxy exits recorded; the last White House proxy activity is observed that night.
November 5, 2026Iris Ohyama's detailed notice puts up to 7.7 million people at risk; Apiiro publishes its Claude Code research; the US State Department asks Layer3 for its logs; The Register reports White House proxy activity has stopped.
November 7, 2026The Hacker News and iTWire report Apiiro's findings on Claude Code secret leaks.
November 8, 2026BleepingComputer reports the Iris Ohyama breach; SecurityAffairs covers the Arkéa heist.
November 9, 2026The Register reports Iris Plaza's online store is still down, with no reopening date.

1. French bank loses ~€118 million in supplier-platform heist

Crédit Mutuel Arkéa, a cooperative banking group headquartered near Brest in Brittany, has confirmed that attackers used a third-party service provider's platform to reach its network and then moved the bank's own money. The news broke on the blockchain before it came from the bank: ZachXBT, a pseudonymous investigator who traces stolen funds across public ledgers, flagged suspicious withdrawals of more than $106 million from accounts at several centralized exchanges on November 2, then raised the estimate to more than $133 million (€118 million) on November 3 and named Arkéa. Blockchain analytics firm Bitquery counted about $108.8 million in USDC leaving OKX, Kraken, and Crypto.com in 178 transactions to 15 wallets over roughly 21 hours between November 1 and 2, with about $63 million swapped into 27,553 ether in four hours through the decentralized exchange UniswapX.

Arkéa's November 4 statement confirmed the attack and the fraudulent operations, said the incident was under control, and stressed that customer deposits were fully protected and no customer lost money — the bank's own treasury took the hit. The bank has not named the supplier, explained how the attackers authenticated to its platform, or said which approval controls were bypassed. It has also ruled out its subsidiary Fortuneo as the entry point and ruled out human error. The incident is an early test of the EU's Digital Operational Resilience Act (DORA), in full application since January 2025, which sets strict incident-reporting and third-party-risk rules for financial firms. ZachXBT says about $30 million had been laundered by November 3 — his claim, not an established fact — and argues the lack of public disclosure limited law enforcement's ability to freeze funds.

Investigation notes

Three numbers circulate for the same theft, and they measure different things: ZachXBT's €118 million ($133 million) is an estimate of total withdrawals, including over-the-counter trades he says could push it higher; Bitquery's $108.8 million covers only USDC paid by three exchanges to 15 addresses; and the bank itself has confirmed only the order of magnitude, with AFP reporting a provisional figure of about €100 million. The net loss depends on how much is frozen or recovered, and nobody knows that yet. The structural point is the entry: the attackers did not breach the bank's perimeter directly — they came through a supplier's platform, the same third-party pattern behind the Iris Ohyama breach in this same brief. DORA was written for exactly this failure mode, and regulators will be watching how fast Arkéa reports the supplier and the control gaps.

2. Iris Ohyama cloud breach may expose 7.7 million people

Japanese manufacturer Iris Ohyama has disclosed that personal information belonging to about 7.7 million people may have been exposed after unauthorized access to a third-party cloud service used by its Iris Plaza online store. Staff found a suspicious file in the external cloud service on October 28, suspended Iris Plaza and related systems the same day, and disclosed the incident on October 29, notifying Japan's Personal Information Protection Commission and police. A detailed notice on November 5 said the data at risk covers up to 5.8 million registered members and former members, plus 1.9 million non-members who bought as guests or entered campaigns. The data may include names, addresses, phone numbers, email addresses, dates of birth, gender, and passwords — stored encrypted, though the encryption method is undisclosed. Credit card data was not stored in the affected service and is confirmed unaffected.

The company has received no reports of misuse or financial loss as of November 5, has not identified the attacker or the cloud provider, and has not established whether any records actually left its systems. Its online store remains down with no reopening date, while its storefronts on Rakuten, Yahoo! Shopping, and auPAY Market keep operating. Customers are being contacted individually by email.

Investigation notes

The 7.7 million figure is the total data held in the compromised cloud service, confirmed as possibly viewed or obtained — not a confirmed leak count. Iris Ohyama says it is still investigating whether a leak occurred at all, and no ransom demand or attacker contact has been reported. Treat the number as the ceiling of exposure, not the size of a breach. The other fact to note is the entry point: an external cloud service, not the company's own network — the same supplier-side pattern as the Arkéa heist above. Two major incidents in one week, both through a third party the victim has not named, is a reminder that vendor access is now a primary attack path, not an edge case.

3. Claude Code's 'Don't Ask Again' leaked secrets into 1,122 public GitHub files

Security firm Apiiro has found that Claude Code's approval feature can save passwords and API keys into public GitHub repositories. When a developer approves a shell command with "Yes, and don't ask again," Claude Code stores the exact command text — secrets included — as an allow rule in .claude/settings.local.json inside the project folder. If that file is committed, the secret goes with it. Apiiro scanned 104,185 public copies of the file on GitHub, using data collected November 1–3, and classified 1,122 of them (about 1.1%) as containing real secrets — 1,379 distinct values, including 379 database passwords, 23 AWS keys, 43 SSH logins, and 42 GitHub, GitLab, and npm tokens. Counting git history, shared settings files, and agent transcripts, the total rises to 2,539 secrets across 1,994 repositories and 63 organizations. One notified company confirmed its exposed key was live.

Apiiro did not test the credentials, so the research shows exposure risk rather than demonstrated compromise. Claude Code adds the file to the user's global git excludes when it creates it, but that does not protect copies already committed, clones, or other machines — and standard scanners miss many of them: Gitleaks flagged 564 of the 1,122 files and TruffleHog 643, while neither flagged 215. Apiiro compared 16 coding agents and found Claude Code the only one confirmed to write the full approved command into a project file by default. As of November 8, Anthropic had made no public statement on the findings. The research was published November 5 by Shmulik Cohen and Matan Giladi.

Investigation notes

This is a workflow failure, not a prompt injection — an ordinary approval click that turns a typed secret into a committed file. The fix is operational, not a patch: search your GitHub organization for .claude/settings.local.json and .claude/settings.json, rotate anything found, and remember that deleting the file does not help — 734 secrets sat only in git history and 211 forks carried copies. A clean scanner report tells you little here, since more than a fifth of the affected files evaded both Gitleaks and TruffleHog. The deeper lesson is about agent design: any tool that persists approved commands verbatim is one careless approval away from publishing credentials, and Claude Code is currently the only one of 16 agents Apiiro checked that does it by default.

4. Residential proxy traffic was exiting through the White House network

Security firm Layer3 Intel has found residential proxy traffic exiting through the network registered to the Executive Office of the President — the White House network (AS2650). Between October 5 and November 3, its Residential Proxy Observatory recorded 236 proxy exits through six IP addresses on 26 of 30 days, and 28 separate residential proxy services were able to route traffic through the network. The discovery was accidental: Layer3 found the addresses while buying routine rotating proxy access from commercial providers, not by targeting the White House. Spur and Synthient independently classified the six addresses as residential proxy exits, and Synthient believes multiple Windows 10 and 11 devices on the network likely have the Infatica SDK installed — software that turns a device into a proxy exit node. Most activity fell between 5 p.m. and midnight Eastern time.

Layer3 stresses its data cannot identify the device, its owner, or whether any device was infected, and no breach or compromise of White House systems is confirmed. The activity stopped after the findings were published: the last observed activity was the night of November 4, and the US State Department contacted Layer3 on November 5 to request its logs. Layer3's retained data goes back to July 10 and shows continuous activity over a period of months.

Investigation notes

The evidence establishes proxy exits, not a breach — and the distinction matters. What it does establish is that devices inside one of the world's most sensitive networks were reachable as commercial proxy exits, rentable for under a dollar per gigabyte, and that the activity ran for months before a new observatory tool surfaced it. A January 2026 Spur survey found residential proxies operating inside nearly 300 government networks, 318 utilities, and 141 banking and finance organizations, so this is a sector-wide hygiene problem, not an isolated case. The open question is how the SDK got onto those machines — bundled software, a careless install, or something worse — and Layer3's data cannot answer it. A halt in observed traffic does not establish why it stopped or whether the underlying software was removed.

Sources

Keep exploring.

All articles