Weekly briefing, 4 November 2026: the $6.3bn Binance heist, HTTP2Shell keeps spreading, and one robots.txt line for AI training

This is our weekly briefing for founders, CTOs and product leaders. It covers what changed in AI platforms, web and mobile, DevOps, security and regulation between 28 October and 4 November 2026, and what each change means for teams that build or buy software.

The week in brief

Security dominated the week. The biggest story was the theft of about $6.3bn from Binance. The attackers didn't break any cryptography. Over four months they worked through an engineering team's ordinary tools: a tampered installer for an AI coding tool, a fake job interview, an internal AI tool and deployment credentials stored on a laptop. Any company whose engineers can push code to production faces the same risk, so it's the subject of this week's deep analysis.

Several flaws in widely used software were also being exploited this week. WordPress core, GitLab and Drupal Commerce all had flaws under active attack. The HTTP2Shell bug in the Brotli decompression library kept turning up in more runtimes and tools. Android's November bulletin fixed a remote code execution flaw that needs no action from the user.

On the AI platform side, Google said it will honour a shared robots.txt signal that tells AI developers not to train on a site, and coverage reports OpenAI and others backing the same signal. Anthropic started watermarking text from its current Claude models and set a 30 November removal date for one feature.

At a glance

The roundup

1. Binance loses billions after a months-long intrusion through its engineers

On 29 October, an attacker moved about $6.36bn out of Binance wallets on ten blockchains, most of it in about 20 minutes. That figure comes from TRM Labs, a blockchain intelligence vendor. Binance's own report, summarised by Reuters, traces the attack back to a tampered AI tool installed in June and a fake job interview in September. Binance says it will cover user losses. For software buyers the lesson is that the theft ran through developer laptops and an internal AI tool, which almost every company has. The full analysis is below.

2. HTTP2Shell: the Brotli decoder bug keeps turning up in new places

The Node.js project disclosed CVE-2026-111497 on 21 October. It's an out-of-bounds write in Google's Brotli decoder, and Zscaler's analysis lists Node.js, Bun, Python Brotli bindings, .NET, Envoy, Istio, brotli4j and curl among the affected components. This week Check Point's 2 November report described it as actively exploited, with automated scanning seen. The hard part is that many apps decompress Brotli automatically without any code calling it. Zscaler also warns that updating the host's libbrotli package doesn't fix copies bundled inside container images or applications.

3. WordPress core upgrade flaw added to CISA's exploited list

CISA added CVE-2026-119977 (CVSS 8.1) to its Known Exploited Vulnerabilities catalogue. It's a race condition that lets an unauthenticated attacker run code during a full-package core upgrade, through predictable, web-accessible staging paths. Wordfence recorded more than 18,500 requests aimed at staged installer paths in the first 21 hours after disclosure, and exploitation was observed on 30 October. US federal agencies must patch by 6 November. If you run marketing sites or content hubs on WordPress, apply the late-October core patch rather than waiting for the next scheduled upgrade, because the upgrade is when the exposure happens.

4. GitLab's CVSS 10 CI/CD flaw is being exploited

CISA also listed CVE-2026-97229, an integer overflow in GitLab CE/EE that lets an unauthenticated user run code on the server through a crafted regular expression in CI/CD configuration. Its addition follows an attempt on Alpine Linux's GitLab instance on 20 and 21 October that crashed GitLab worker processes eight times. Alpine found no evidence that the attack worked but rebuilt the instance from scratch anyway. If you self-host GitLab, it holds your source code, pipelines and often your deployment secrets, so patch now. Treat any unpatched instance that was exposed to the internet as possibly compromised.

5. Drupal Commerce Core: an exploited access bypass on online stores

Drupal's security team rated SA-CONTRIB-2026-254 "highly critical" on 28 October. Commerce Core doesn't sufficiently protect certain routes and entity fields, and the flaw is being exploited in the wild. The fix is Commerce Core 3.3.13, or 8.x-2.41 for older branches. Drupal also tells sites to audit their orders for inconsistencies. For retailers, that makes it a finance and fulfilment problem as well as a patching one. Our e-commerce development guide covers how platform choice affects this kind of exposure.

6. Third-party code is still the easiest way in: Polymarket and Japan Airlines

Check Point's weekly report noted that Polymarket disclosed a compromised third-party service that served malicious JavaScript on its website. The script hijacked logged-in trading sessions, and about $2.7m in crypto was traced to a suspected attacker wallet. The same report covers a Japan Airlines breach through the Amadeus reservation system affecting about 92,000 passengers, about 2,000 of whom may have had passport details accessed. Every third-party script on a logged-in or checkout page can act with your users' sessions, so keep an inventory, a Content Security Policy and integrity checks.

7. Android's November bulletin fixes a remote code execution flaw that needs no user action

Google's November bulletin lists 216 vulnerabilities, 23 of them Critical. The headline flaw, CVE-2026-58868, allows remote code execution with no user interaction on Android 14 to 17 and is fixed at patch level 2026-11-01. As of 4 November no exploitation had been reported. A separate Critical flaw in WAP Push handling, CVE-2026-58882, allows a remote denial of service. It sits in the same function as a public "SMS of Death" proof of concept, though neither the bulletin nor the CVE record says they are the same bug. If your app handles sensitive data on managed devices, check fleet patch levels. Device makers ship fixes on their own schedules.

8. A single robots.txt signal for opting out of AI training

On 30 October Google said it plans to support a shared AI training control in robots.txt, based on an IETF AIPREF working-group draft. If a site opts out with the shared token and doesn't mention Google-Extended separately, Google will treat that as disallowing Google-Extended. Google is aiming for support "along with other AI providers in 2027", and coverage from PPC Land reports Microsoft, OpenAI and Anthropic backing the same approach. Google links the proposal to the EU's General-Purpose AI Code of Practice, which treats robots.txt as a primary way to state machine-readable preferences. Nothing needs to change today. Do decide who in your company owns the policy for your docs, blog and help centre.

9. Claude Platform: watermarked output, server-side threads and a 30 November deadline

Anthropic shipped several changes this week that matter to teams building on the Claude API. They are listed in its platform release notes.

The watermark matters for regulation. According to a timeline compiled by FutureAGI (an AI tooling vendor, and not legal advice), the EU AI Act's Article 50 transparency rules have applied since 2 August 2026. From 2 December 2026, older generative systems must also mark their output under Article 50(2). Provider-side watermarking may help, but check with counsel what your product still has to do as a deployer. If you change sampling settings, test whether the watermark survives. Our guide to evaluating LLM features in production covers how to build that kind of check into your test suite.

Patch priority table

Deep analysis: how the Binance heist worked, and what it means for every team that ships software

What happened

Binance published an initial incident report on 3 November. Combined with Reuters' summary and TechStartups' account, it shows a patient attack with several stages and no single point of failure. Co-CEO Richard Teng said the attackers "spent months building their way in". He rejected the idea that one compromised laptop caused the breach.

The stages were:

1. June: a poisoned tool download. A Wallet DevOps engineer searched online for a popular AI coding tool and installed a tampered Homebrew package. Binance detected this, replaced the computer and rotated credentials. By then the attackers had learnt the engineer's role and who else worked on the wallet infrastructure.
2. September: a fake job interview. A second engineer was approached through a legitimate recruitment platform and interviewed with a recruiter and the "CEO" of a company that didn't exist. The coding exercise, downloaded onto a work computer, contained malware that Binance's endpoint security didn't detect.
3. 20 October: moving between machines. Using that computer and an internal AI tool, the attackers reached the machines of two wallet engineers. One of them held deployment credentials that led to the wallet-signing infrastructure.
4. 29 October: the theft. Using credentials stolen from the first engineer, the attackers deployed malicious code into the wallet environment. Funds left Binance wallets within minutes.

TRM Labs' on-chain analysis adds the final step. On Ethereum, the attacker used an EIP-7702 delegation to turn a Binance hot wallet into a sweeper it controlled, with 50 authorisations signed in advance. On the other nine chains, Binance wallets sent funds through ordinary signed transfers. TRM reads this as a compromise of Binance's hot-wallet signing infrastructure. The vendor says preparation began at least 36 hours before the theft, when Tornado Cash withdrawals funded the attacker's operating wallet.

"This should not have happened." That was Binance's own verdict in its report, as quoted by Reuters. The attackers didn't need to break cryptography. They needed one engineer to install the wrong file and another to take a job interview.

Timeline

The numbers

Valued at the moment each transfer happened, TRM puts the total at about $6.36bn. Binance's own figure is about $6.34bn. The breakdown below is TRM's on-chain view as of 30 October, so treat it as a vendor estimate.

Elliptic's chief scientist called it "almost certainly the single largest-known theft of any kind". The FBI attributed it to North Korea's TraderTraitor group. North Korea rejects the claim.

Context: the same pattern keeps appearing

Two other items from the past fortnight show that Binance isn't an isolated case.

First, Microsoft Threat Intelligence published research on North Korean actors' use of AI on 29 October, the day of the heist. It describes several groups that run job- and interview-themed social engineering and use AI to produce tailored recruiter lures and malicious repository lures. It also describes another group that uses fake identities to get hired into remote jobs. The hiring process is an attack route both ways: your engineers interviewing elsewhere, and your company hiring candidates who aren't who they claim to be.

Second, the LiteLLM incident disclosed on 24 October followed a similar path. A master key for an agent platform was committed to a public repository on 27 May. The commit was force-pushed over, but, in LiteLLM's words, "key revocation did not occur for the master key." On 10 October an attacker used the key to pull a GitHub token that had not been scoped down and carried owner-level access. On 21 October they published a malicious LiteLLM release to PyPI. LiteLLM says releases normally needed approval from an account tied to a physical device, and the attacker got around this by overriding branch protection and changing the release pipeline.

Both incidents have the same shape. An AI or agent tool with broad, standing access sat between an ordinary developer foothold and the systems that sign, deploy or release. In both cases, a clean-up that looked complete left something behind.

Who is affected

• Fintech, payments and crypto teams with hot wallets, payout APIs or treasury integrations. Here, deployment access is effectively the ability to move money. Our fintech work starts from that assumption.
• Any SaaS company whose engineers can deploy from a laptop. If a laptop holds a token that can push to production, that laptop is part of production.
• Companies rolling out internal AI assistants and agents connected to code, tickets, chat and cloud consoles. Binance rebuilt its internal AI tool after the incident, according to Teng.
• Companies hiring remotely, and companies whose engineers are job-hunting while using work machines.
• Buyers of outsourced development. Your supplier's laptops and pipelines are part of your attack surface too.

What it means for companies building or running software

1. Developer endpoints are production infrastructure. The attackers reached the signing system because one engineer's device held deployment credentials. Short-lived credentials issued to CI through OIDC, combined with deploys that can only run from the pipeline, would have removed that step. They're a few days of DevOps work for most teams, not a programme.

2. Internal AI tools are privileged accounts and need the same controls. An assistant that can read repos, run commands or reach other machines needs least-privilege scopes, its own identity, logs that someone actually reviews, and no standing admin tokens. In both Binance and LiteLLM, the AI or agent layer was how the attackers reached further. Treat it with the same discipline you'd apply to a service account. Our LLMOps and DevOps work starts with that inventory.

3. Incident clean-up has to assume the attacker learnt something. Binance replaced the June device and rotated credentials, but the attackers had already mapped the team. Good remediation also asks what the attacker now knows: who has access to what, which colleagues to target next, and what to watch for.

4. Hiring and job-seeking are now part of your security perimeter. Microsoft's research shows interview lures produced at scale with AI. The practical rule is that no take-home assignment, repository or "quick setup script" from an outside party runs on a machine that holds company credentials.

5. High-value actions need a second, independent check. Moving funds, deploying to signing systems or releasing packages should need approval from a separate device or a separate person, checked by a policy that the deploying machine can't change. LiteLLM had a device-bound approval in place, and the attacker changed the release pipeline instead. So protect the pipeline definition as well as the approval step.

Checklist: what to do now

This week

• Find every place a production, signing or release credential lives on an engineer's laptop, and plan to move each one to short-lived, pipeline-issued credentials.
• List every internal AI tool and agent, the tokens it holds, and what it can reach. Revoke anything not scoped to the task.
• Search your Git history, including force-pushed and deleted commits, for keys. Revoke anything you find, even if the commit is gone.
• Write down a rule that engineers don't run third-party interview tasks or unknown repositories on company devices. Give them a disposable VM or cloud sandbox instead.
• Patch the five vulnerabilities in the table above, and rebuild container images rather than relying on host updates.

This month

• Require phishing-resistant authentication (FIDO2 security keys or passkeys) for source control, cloud consoles and CI. Our passkeys guide explains how to roll them out.
• Limit where software can be installed from: approved package sources, pinned versions and checksums. Make it routine for engineers to avoid installer links from search ads.
• Protect the pipeline definition. Changes to release workflows, branch protection or deployment targets should need review from a second person.
• Add identity checks and a live technical conversation to remote hiring, and verify identity again before granting production access.
• Run a tabletop exercise: "a deploy credential has leaked and we have 20 minutes." Time how long revocation, freezing and rollback actually take.

This quarter

• Put an independent policy check on high-value actions (payouts, signing, releases) that the deploying machine can't change.
• Get an outside review of your developer-to-production path. A focused software audit or security review costs far less than an incident.
• Include developer endpoints, AI tools and supplier access in your maintenance and support plan, so they're covered after the audit ends.

Keep the response proportionate

Most companies don't hold billions in hot wallets, and copying an exchange's controls wholesale would slow a ten-person team for little benefit. The proportionate version is small: no long-lived production credentials on laptops, scoped tokens for AI tools, phishing-resistant sign-in, and a second approval for the few actions that could seriously hurt you. Those four steps take days of engineering time, not months. If you can't name your highest-value actions, list them before you buy any new security tool.

How Authect fits in

We're a founder-led studio, so you talk directly to the founders who will build your project, never a salesperson or account manager. Every project is led by a senior engineer, and delivery is AI-accelerated with an engineer reviewing every line, including the access each AI tool gets. Clients own their code, infrastructure and designs from day one. If you want a second opinion on your deploy path, AI tool access or patching backlog, start a conversation online.