thaidn

Chief at @calif_io | MAD Bugs:

[Calif @calif_io]

Big news: @lcamtuf has joined us.

Michal has been advising us since the earliest days of the company, helping us navigate everything from difficult strategic decisions to situations that were difficult primarily because we created them ourselves.

As the business has grown, so has the number of problems that can only be solved by asking, "What would Michal think of this?" We're delighted that he has now joined us officially and can no longer pretend not to see our messages.

We're also excited to share that Michal has granted us an exclusive world-wide license to commercialize his groundbreaking C/C++ remote dependency technology.

Existing customers are encouraged to begin planning their migration to our next-generation implementation, which has been carefully re-engineered with Claude in PHP to maximize nostalgia value for some of our hackers.

Welcome aboard, Michal!

[Alex Matrosov @matrosov]

Time-to-Exploit has changed significantly for n-days, especially in OSS projects, where the code changes in the fix can serve as a harness for PoC creation.

There’s effectively zero time to apply updates, the MTTR metric has a negative value nowadays. Defense in depth definitely helps by adding layers to buy some time, but in general, old threat models are becoming irrelevant.

[Justin Drake @drakefjustin]

Today a crazy quantum story just got wilder.

On March 31, the Google Quantum AI team published a landmark result on Shor's algorithm for elliptic curve cryptography. Technically, the paper was a bombshell: a dramatic 10x improvement over the state-of-the-art. As a stunt and wakeup call to the blockchain space, those optimisations were illustrated on secp256k1, the elliptic curve underlying Bitcoin and Ethereum signatures.

But perhaps the most striking part of the paper was sociological, not technical. Instead of following standard academic process, the optimisations were kept secret, hidden behind a zero-knowledge (ZK) proof. Google's accompanying blog post mentions they "engaged with the U.S. government". The ZK proof demonstrates the existence of algorithmic improvements without leaking details. Academic censorship with ZK, a historic first!

As a co-author of the Google paper I witnessed some of the context surrounding this censorship. To be honest, multiple aspects of that context don't sit well with me. As much as I believe the general public ought to know more, I am limited in my ability to whistleblow. Though let me be clear about one thing: the Google team's professionalism has been absolutely exemplary, and they deserve nothing but praise.

Censorship has a way of backfiring. The Streisand effect, where an attempt to bury something only draws more attention to it, is exactly what's unfolding today. First, Google's key optimisation has been rediscovered by the French. And in a thrilling turn of events, a collaborative Shor-at-home challenge just launched. The initiative, available at ecdsa[.]fail, breached a new Shor world record in a matter of hours.

Let's start with the rediscovery. Just two months after Google's paper, French quantum expert André Schrottenloher cracks the main secret optimisation. His paper, titled "Optimized Point Addition Circuits for Elliptic Curve Discrete Logarithms", landed on the arXiv today. Big congrats to André, who beat several other nerdsnipped experts to it. In a blog post also published today, Craig Gidney, the world expert on Shor optimisations, revealed that he'd been sitting on this very optimisation for a whole year under censorship pressure.

Interestingly, André missed a handful of minor optimisations, both from Google's original publication and from improvements found since. It's plausible there's still plenty of juice left to squeeze out of Shor, and this is exactly what the ecdsa[.]fail challenge is about. The verifier program developed for the ZK proof does double duty, automatically filtering for valid submissions. Dozens of compounding small and micro improvements are rolling in. As of the time of writing there's an 8.4% improvement to Google's circuit, as measured by the product of logical qubit count and Toffoli gate count. Nice!

The nerdsnipping ran deeper than anyone expected. Over the last few weeks it became clear it extended well beyond André and other quantum experts. Behind the scenes, a small army of amateurs quietly got to work. Inspired by Karpathy-style autoresearch, they turned AI on Shor. Ironically, the verifier program for the ZK proof makes an ideal reward function for AIs. The barrier to entry for this modern style of research is refreshingly low, with several non-experts, even a teenager, finding nice optimisations. Get in touch if you'd like to join a Telegram group with fellow autoresearchers :)

Part 2: neutral atoms and qday

The story doesn't end with Google. On the same day Google went public, a stealthy startup called Oratomic published its own Shor paper in a coordinated release. It made a splash, ultimately becoming the most upvoted paper on scirate[.]com, a website ranking arXiv papers.

Oratomic's claim was wild. By building on Google's logical optimisations and applying custom physical optimisations for neutral atoms, they claimed just 10K physical qubits were sufficient to run Shor's algorithm on secp256k1. That number is mind-bogglingly low.

Knowing essentially nothing about neutral atoms when Oratomic's paper landed, I was intrigued and decided to learn more about the tech. I fell straight down the rabbit hole and spent a couple hundred hours on the topic. I got a little obsessed and watched every YouTube video I could find and spoke to a bunch of experts.

My conclusion? The tech is real, very real. Even Google recently decided to start a neutral atom lab, a notable pivot from their sole focus on superconducting qubits. If you care about qday, i.e. the day a quantum computer will break the first piece of cryptography in production, neutral atoms demand your attention. I shared some of my learnings on Shor and neutral atoms in a 30min talk at the ZKProof cryptography conference. You can find it on YouTube by searching "zkproof neutral atom".

Here's an interesting observation about this duo of breakthrough papers: neither Google nor Oratomic say a word about what their results mean for qday. No timelines. Zero. Nada. That is especially baffling given that the whole point of whitehat quantum cryptanalysis is to inform qday estimations and help the general public make good decisions.

So let me attempt to partially fill the silence, similarly to what Scott Aaronson did in his April 29 post. Given everything I know, including scary non-public information, I now put the odds of qday by 2032 at 50%. 10% by 2030.

Anecdotally, the US government has its own date: 2035. Originating at the NSA and later adopted by NIST, it's when branches of the US government will be disallowed from using quantum-vulnerable cryptography. In plain language: with hindsight, that date is a joke and should be discounted entirely. I don't see how NIST avoids being forced to pull it forward by years.

Part 3: post-quantum cryptography

There are good reasons to sound the alarm today, but please do not panic. Rushing carelessly towards immature post-quantum cryptography is a recipe for disaster. IMO a good target date for migration is 2029, roughly 3.5 years out. 2029 happens to be the date selected by Google, Cloudflare, and the Ethereum Foundation.

These days most of my time goes to safely migrating Ethereum towards post-quantum cryptography as part of the broader lean Ethereum effort. There's a lot to do. We need to rip out and replace BLS signatures at the consensus layer, KZG commitments at the data layer, and ECDSA signatures at the execution layer.

The plan to get there is compelling, and is based on hash-based cryptography. Within the Ethereum Foundation we've developed a Swiss army knife called leanVM (github[.]com/leanEthereum/leanVM) powered by the magic of hash-based SNARKs. Thanks to truly exceptional work by Emile, Thomas, and others, its performance is derisked. Regarding security, leanVM is a jewel, a minimal zkVM crafted for end-to-end formal verification and maximum security.

Want to help? There are two $1M initiatives. First, the Proximity Prize (proximityprize[.]org). Solve a long-standing mathematical conjecture in coding theory, improve hash-based SNARKs, and go home a millionaire. Second, the Poseidon Initiative (poseidon-initiative[.]info), offers $1M for breaking Poseidon, the SNARK-friendly hash function.

[Calif @calif_io]

Introducing HTTP/2 Bomb: a remote DoS in nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora. A single client pins 32GB of server memory in 10s. Found by Codex.

Blog post: https://t.co/WO9MeExoun

PoCs: https://t.co/NpVgEHBHPl

[thaidn @XorNinja]

When the team walked me through this research, I found myself back in 2012. That year, @julianor and I discovered CRIME, a compression oracle that recovered cookies from compressed HTTP headers. I was at Google at the time, so I was asked to review the fix, which became part of HTTP/2. I just re-read my notes from that review: I never once considered this attack. I was too fixated on fighting CRIME and missed the bomb.

[Calif @calif_io]

Introducing HTTP/2 Bomb: a remote DoS in nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora. A single client pins 32GB of server memory in 10s. Found by Codex.

Blog post: https://t.co/WO9MeExoun

PoCs: https://t.co/NpVgEHBHPl

[Hexacon @hexacon_fr]

🔥 Excited to announce our keynote!

We are thrilled to welcome Bruce Dang (@brucedang) and Thai Duong (@XorNinja) from @calif_io! With all their recent AI buzz, we had to check they aren't just LLMs in a trench coat. 🤖🧥

🎟️ Ticketing opens this Thursday at 2:00 PM CEST ⏰

[Nightmare Eclipse @ChaoticEclipse0]

Everyone except me ? We are in fact still in court over this.

[Calif @calif_io]

RedSun: Exploiting Windows Defender's Remediation Workflow for Local Privilege Escalation

Just showing some appreciation for @ChaoticEclipse0's excellent work. Hopefully this won't get us banned!

https://t.co/Z4zbaa2Jcd

[thaidn @XorNinja]

@Little_34306 Happy birthday! Trust me it's just gonna get older from here.

[Coiffeur @Coiffeur0x90]

🐘 Fully working PHP sandbox escape via a Use After Free demonstrated on PHP 8.5.6 (Homebrew macOS) and PHP 8.6.0 (latest).

Interestingly, some internal structures evolved since my 2023 exploit 🏴‍☠️.

[Alex Matrosov @matrosov]

Previous generations of software protection (DRM perspective) have always relied on code complexity (for RE), compute limitations, and human limitations as the guarantees that kept hacking timelines reasonably long.

That's changed now. Beyond the acceleration in vulnerability research and malware analysis, the same new reality applies to software protection, and security by obscurity, or assuming the attacker is limited in compute and motivation, no longer works.

[Robert Graham @robertgraham]

We know what probably happened.

From what we see publicly, NightmareEclipse doesn't communicate well, is emotionally immature, and appears to want to extort Microsoft.

Almost certainly, this played a part in the conflict between them and Microsoft -- it's probably as much NightmareEclipse's fault as Microsoft's.

With that said, everything Florian says is correct. It doesn't excuse Microsoft's failures. They are supposed to be the responsible one,

When there is miscommunication or dispute, it's always allowable to drop 0day, regardless whose fault it is. It's Microsoft's job to avoid that, even when they really aren't at fault for the miscommunication.

But Microsoft has convinced themselves of the opposite, that "responsible" disclosure means only the responsibilities of the vuln finder.

Vuln finders have no responsibility. Dropping 0day is responsible. Responsible companies don't have so many bugs.

We let industry subvert the disclosure process. Instead of working to secure their code, vendors have tricked people into believing in the myth of "responsible disclosure", that vendors should be given time to fix and patch their bugs so they are never to blame for the bugs to begin with.

That's why you have customers still buying Fortinet appliances even though their bugs continue to be major sources of customers getting hacked. Customers shrug their shoulders: as long as Fortinet has a vulnerability disclosure program and releases patches, they aren't responsible for when hackers keep breaking into their boxes.

This is garbage. Vendors are still responsible for preventing bugs in the first place, a responsibility that doesn't go away just because they patch.

Regardless of what happened, Microsoft's threats are a gross violation of ethics in the industry.

[johnny @zeroxjf]

New writeup with PoCs! I used Codex to follow breadcrumbs from @calif_io’s Mythos-assisted Apple M5 memory-integrity bypass demo & see what I could recreate from the outside.

Didn’t rebuild the chain, but did find 2 new macOS kernel bugs along the way.

https://t.co/H9QJUCpgSf

[Thomas H. Ptacek @tqbf]

Just talked to @lcamtuf for @SCWpod and was tOdAy YeArS oLd when I learned that I could buy and download his new book, which looks amazing, right now. Which is what I'm doing. https://t.co/ESYWvKJawn

[Robert Graham @robertgraham]

@HackingLZ Maybe we need a "Month of Microsoft Bugs" where everyone drops their 0days.

[Calif @calif_io]

Needle in a haystack: measuring the impact of two nginx RCEs

We had a lot of fun hacking nginx earlier this year. We know from experience that finding a real RCE in nginx is hard, especially one that triggers in a default or commonly-used configuration.

So when F5 disclosed CVE-2026-42945 (better known as nginx-rift) and CVE-2026-9256 (possibly nginx-poolslip), two critical heap buffer overflows in the nginx rewrite engine, the natural question was: how many real-world configurations are actually vulnerable?

To answer that, we built and open sourced ngxray, a static vulnerability scanner for nginx configs, and scanned nearly 36K configs we found on GitHub.

The scanner flagged configs across several dozen repositories. The majority turned out to be PoC reproductions, scanner test fixtures, and tutorial snippets.

Out of 35,633 configs, we found one vulnerable config, in an abandoned project.

https://t.co/2H9F53VB5n

[LCFR @lcfr_eth]

@impost0r_ @XorNinja https://t.co/udLCOFIHRD
https://t.co/zxmp5AFkR1
https://t.co/N0MnORRaGu
https://t.co/heO0igFNAL

The 5th one is another UAF (in6) which should be coming out next patch set.

[lazyming @vn_lazyming]

I want to sharing with you guys my first 0day on linux kernel, the bug its self not in rds module but need go through rds module to trigger :D i notice that RDS is from oracle and dont got blacklist on Unbreakable Enterprise Kernel (UEK) Lets Break some things call unbreakable :D

[thaidn @XorNinja]

How about we all start dropping M$ 0days? Asking for @taviso.

[thaidn @XorNinja]

An AI audit of FreeBSD: 15 kernel bugs, including 3 RCEs, 5 LPEs, and 1 bhyve escape

https://t.co/WeTcKahGZj