AI Weekly Malaysia

Cloudflare Workers now exposes post-quantum algorithms through Web Crypto: ML-KEM-768/1024 for key encapsulation and ML-DSA-44/65/87 for signatures, plus encapsulateBits(), decapsulateBits(), encapsulateKey(), decapsulateKey(), getPublicKey(), SubtleCrypto.supports(), and JWK import/export. The feature is opt-in behind the webcrypto_modern_algorithms compatibility flag because the underlying 'Modern Algorithms in the Web Cryptography API' draft community group report is still moving. Cloudflare's post by Thibault Meunier states explicitly that this is not a full migration path, only building blocks for validating an integration, and that ML-KEM output still needs to be fed into a key schedule and AEAD such as AES-GCM via something like HPKE.

Why: If you already bundle a JavaScript or WebAssembly post-quantum library into a Workers project, this is a chance to delete that dependency and test ML-KEM/ML-DSA against the runtime's own implementation instead. But the flag is named webcrypto_modern_algorithms and the spec is a draft, so treat it as an experiment branch, not a production key-exchange swap — Cloudflare itself says there is no complete migration path here. There is no Malaysian or Southeast Asian angle in this text; the relevance is purely for teams already running Workers.

Cloudflare added per-connection post-quantum TLS visibility to Logpush, Log Explorer, and the HTTP Traffic Analytics dashboard, exposing the key-exchange algorithm negotiated on every incoming request so customers can audit PQ posture per domain. Its Radar data shows roughly 70% of browser-generated traffic to Cloudflare is already protected with hybrid ML-KEM (FIPS 203), but only about 15% of the origins Cloudflare connects to use it. Cloudflare is targeting full post-quantum security by 2029, and says many customers face quantum-readiness deadlines around 2030; it also recently launched Automatic Key Exchange for the Cloudflare-to-origin connection to reveal which algorithms an origin supports.

Why: The 70% visitor vs 15% origin gap is the actionable number: if you run an origin behind Cloudflare, your visitors are probably already negotiating hybrid ML-KEM while your own origin likely is not, so the weak link is on your side of the connection. You can now pull the negotiated key-exchange field from Logpush or Log Explorer per domain to find which of your origins still fall back to classical cryptography, and check whether outdated origin TLS config is downgrading a connection that could support PQ. There is no Malaysia-specific or regional detail in this post; treat it as a general infrastructure item.

Cloudflare's Sharon Goldberg and Tiago Silva describe the company's push to full post-quantum readiness by a 2029 deadline, under a self-described 'PQ everything' maximalist stance. Most Cloudflare products already use post-quantum encryption over TLS 1.3, but post-quantum authentication is still early, so they built an internal tool called CryptoLabe (named after the mariner's astrolabe) to inventory where classical vs post-quantum crypto is used per repository and per product. A third goal is surfacing prerequisites early: protocols, standards, and libraries that have no PQ migration plan yet, so they can push those stakeholders before the 2029 clock runs out. The excerpt cuts off before explaining the specific AI techniques used.

Why: The concrete split is worth acting on: encryption over TLS 1.3 is largely handled on Cloudflare's side, but authentication — cert signing, code signing, SSH, key management — is where they admit it's still early days and where your own stack likely has no PQ plan. If you terminate TLS on Cloudflare, you are already riding their PQ encryption defaults; that does not extend to anything you sign or verify yourself. Their 2029 internal deadline is also a useful reference point when vendors ask you about crypto roadmaps.

Cloudflare says it worked with the IETF to develop a mitigation against quantum downgrade attacks on IPsec, and has shipped it in beta across Cloudflare IPsec, Cloudflare WAN, and Magic Transit. The attack class: because endpoints must keep classical crypto for backwards compatibility, an on-path attacker can tamper with handshake messages so each side believes its peer doesn't support post-quantum algorithms, silently dropping the connection back to classical crypto that a future quantum computer could break. The post frames this as the next frontier of the PQ migration, after swapping Diffie-Hellman for ML-KEM and ECDSA/RSA for ML-DSA. The excerpt is truncated before the actual mitigation mechanism is described.

Why: If you terminate IPsec tunnels (site-to-site VPN, Cloudflare WAN, Magic Transit), enabling ML-KEM on both ends is not sufficient — the handshake itself can be manipulated to strip PQ. The concrete action is to ask your IPsec vendor or your Cloudflare account team whether downgrade protection is in the beta and how you'd verify a tunnel actually negotiated PQ rather than silently falling back. The write-up does not include the mechanism or test procedure in the excerpt, so treat the beta as something to evaluate, not a solved problem.

Simon Willison quotes cryptographer Matthew Green reacting to Anthropic's recent cryptography work. Green argues the field is mid-transition from EC and RSA public-key algorithms to post-quantum schemes built on newer hard problems — hence the number of standards under consideration such as HAWK — and that this makes it an unusually good moment for AI to get good at cryptanalysis. In the best case, he says, AI failing to break these problems gives real confidence in them and makes the cryptanalysis literature more robust.

Why: There is no Malaysia or Southeast Asia angle in this text, and no detail about what Anthropic actually did or published — it is a single quoted opinion. The one concrete decision-relevant point for builders is the migration context Green names: if you have a post-quantum migration on your roadmap (EC/RSA to newer schemes), his argument is that AI-assisted cryptanalysis during this window is more likely to validate the new problems than to break them, so the standards churn around candidates like HAWK is expected rather than alarming. Treat the 'Anthropic cryptography work' claim as unverified from this item alone.

Bitget confirmed that the $387.5 million drained from its hot and warm wallets on September 24, 2026 was enabled by a zero-day in unnamed third-party security products, per a SlowMist investigation. Attackers used the flaw to read a database password from an environment variable, run hidden scripts on at least three nodes starting August 31, 2026, obtain high-level internal credentials, and issue withdrawal commands that bypassed existing risk controls. Funds were taken across 11 blockchains and 13 assets, and only about $632,700 was frozen by Circle, Tether, and NEAR Intents.

Why: If you or a Malaysian client keep operating funds on a centralized exchange or rely on crypto rails for payouts, the concrete number here is the recovery rate: roughly $632,700 frozen against $387.5 million taken, under 0.2%. The breach did not come from Bitget's own code — it came from a third-party security product that had database credentials reachable as an environment variable — so the decision that changes is how you vet and segment vendors that sit inside your credential path, and how much you leave in hot wallets versus cold.

MetaMask said on Thursday (Oct 1, 2026) it is responding to an "ongoing security incident" affecting part of its infrastructure, stating it found "no immediate threat to MetaMask wallets" but disclosing no further details. As a precaution it is proactively exiting affected validators in its non-custodial staking operations; Lido said relevant validators have begun exiting and the final ones are expected to be exited (but not fully withdrawn) by the end of October 7, 2026, which will likely mean foregone rewards and possible downtime penalties. MetaMask stressed the staking operation is non-custodial and it does not hold clients' withdrawal keys.

Why: If you hold ETH staked through MetaMask's Lido-based non-custodial staking, the concrete near-term effects are reward loss on exited validators and possible downtime penalties, with exits completing by end of Oct 7, 2026 — and 'exited but not fully withdrawn' means the stake is not instantly liquid. For everyone else, the actionable point is that MetaMask has published no technical detail, so the 'no immediate threat to wallets' statement is currently unverified; treat it as an open incident rather than a resolved one and check back for the vendor's postmortem before deciding anything about self-custody holdings.

Bitget CEO Gracy Chen told CNBC that only about $1.1 million of the roughly $388 million stolen in a cyberattack last week has been frozen, and that she is 'not expecting to recover a lot of funds' based on recovery rates from previous exchange hacks. Bitget has refilled its Protection Fund to $300 million from its own reserves to cover losses, and Chen declined to name the third-party vendors that were breached, citing security risk.

Why: The recovery number is the useful one: ~$1.1M frozen out of ~$388M, and frozen does not mean returned — so roughly 0.3% at best, with the shortfall absorbed by Bitget's own reserves rather than recovered. If you or your users keep funds on a centralised exchange, that ratio is the realistic planning assumption, not the $300M Protection Fund headline. The undisclosed third-party vendor breach is the second takeaway: you cannot check your own exposure against a named vendor, so any dependency on exchange or custody vendors has to be treated as unverified until Bitget says who was hit.

Bitget is reported to have lost $387 million in a crypto hack, with investigators naming North Korea as the primary suspect based on IP addresses tied to VPN infrastructure previously used by North Korean hacker groups. The stolen funds were stablecoins that the thieves swapped into ETH within minutes, apparently to outrun issuer freeze mechanisms. Note: the supplied article body is only Tom's Hardware site navigation and paywall boilerplate, so no attack vector, timeline, or exchange confirmation is actually in the text.

Why: The one operational detail here is the minutes-long stablecoin-to-ETH swap, which implies issuer freeze and blacklist responses did not land fast enough to matter. If your product or treasury plan treats stablecoin freezing as a recovery mechanism for fraudulent or stolen transfers, that assumption needs re-checking against a minutes-scale window rather than an hours-scale one. Beyond that, this excerpt carries no Malaysian, Southeast Asian, or AI/tooling angle, so there is little for local builders to act on.