cryptbe

Cool to see our work here. I'm Thai, and I run Calif. Happy to answer any questions.

We'll publish the technical details of these hacks over the coming weeks. Writing these articles takes time, and we've been busy with a PHP thing [1].

In the meantime, check out The Great Glyph Grift [2] for a glimpse of what can go wrong when iOS parses PDFs.

Just in case you wonder, we've disclosed most of the bugs in these exploit chains to Apple and will disclose the rest. So far in 2026, we've reported close to 100 bugs to Apple. We don't accept Apple bounties, and we're not being paid for this work. We don't sell bugs or exploits, and we have no sponsors funding this research.

We do this because it's fun, intellectually challenging, and we want to help make the iPhone safer. We also have a business to run, so we do need some marketing points.

[1] https://calif.io/php2shell

[2] https://calif.io/research/the-great-glyph-grift

Check out https://calif.io/research/the-great-glyph-grift, which shows one could go wrong with PDF in iOS.

We're gonna publish more in the coming weeks. Writing these blog posts take time, and we've been busy with another PHP thing.

We disclosed most bugs to Apple, and are going to disclose the rest. We've disclosed probably close to 100 bugs to Apple in the past 6 months.

We've also been working with closely with the Signal Foundation to help them reduce the attack surface.

It's not true that we don't want to make devices more secure. We do and it's why we do this research.

We also do want our name out there because we're having a lot of fun and want to share that with our friends and the rest of the world.

Thanks Tom! You're always super kind to us.

We disclosed most of the bugs used in these chains to Apple, and are going to disclose the rest, if not already.

>Just as a reminder for some folks here: During their WeWorm research in July–September 2026, Calif didn't stop at proving RCE to Tencent—they spent an extra week using AI to build a fully functional, self-propagating zero-click worm across three live phones, triggering temporary account bans from Tencent during testing.

Not sure what exactly your point is. The WeWorm demo was done in a controlled environment.

Also we do this for free. We don't charge neither Tencent nor Apple. We don't even take their bounties. Why can't we have some fun?

If you're so upset about how we do it, my suggestion is go find your own bugs.

Oh hey, this is our work! We helped Anthropic analyze and report this bug.

For the record, this bug has nothing to do with our recent MIE attack [1] [2], which exploited two different kernel bugs. Our bugs are not fixed yet.

[1] https://blog.calif.io/p/first-public-kernel-memory-corruptio...

[2] https://news.ycombinator.com/item?id=48139219

You're always super kind to me :)

Nice to randomly encounter our own work here.

Check out our blog post for a fun walkthrough: https://blog.calif.io/p/cve-2026-7270-how-i-get-root-on-free...

AI-generated working exploit, write-up and prompts: https://github.com/califio/publications/tree/main/MADBugs/fr...

The feature is enabled by default. You can test it by yourself.

This is a good title, thanks! There was iTerm2 in the original title, but it overflowed to the subtitle in Substack.

I've now updated the blog post.

Disclosure: I didn't discover the vulnerability. I wrote the blog post.

Thanks for releasing a fix!

It was surprising that there wasn't an official release, even though the bug impacts otherwise routine, harmless workflows. The patch itself [1] framed the issue as "hypothetical," so the goal of the blog post was to demonstrate that it is not. I'm glad that you've agreed to release a fix.

[1] https://github.com/gnachman/iTerm2/commit/a9e745993c2e2cbb30...

Disclosure: I didn't discover the vulnerability. I wrote the blog post.

>The author was able to develop an exploit by prompting an LLM with just the upstream commit

Yes, I was able to do this. I believe anyone watching iTerm2's commits would be able to do this too.

>but I still think this blog post raises the visibility of the vulnerability.

Yes, I wanted to raise the visibility of the vulnerability, and it works!

The author of iTerm2 initially didn’t consider it severe enough to warrant an immediate release, but they now seem to have reconsidered.

>Key point is that Claude did not find the bug it exploits.

It found the bug man. You didn't even read the advisory. It was credited to "Nicholas Carlini using Claude, Anthropic".

>But you would expect running "git status" or "git ls-files" in the unzipped directory to completely pwn your system? Probably not either.

That’s fair, but it would be pretty unusual for me to run Git commands in a directory I’m not actively working on. On the other hand, I open files from random folders all the time without really thinking about it, so that scenario feels much more realistic.

I think we can agree that Git is at least partly responsible for this issue, if not more.

That said, even being aware of that doesn’t necessarily help much in practice. When you’re using Emacs or Vim, you’re not really thinking about Git at all. You’re just opening and editing files. So it’s not obvious to most users why Git would be relevant in that context.

This is why I think editor maintainers should do more to protect their users. Even if the root cause sits elsewhere, users experience the risk at the point where they open files. From their perspective, the editor is the last line of defense, so it makes sense to add safeguards there.

Yes, likely. And git is not going to fix it. So isn't it fair to expect the editor maintainers to do something about it, to protect their users, no?

Disclosure: I didn’t discover the bugs, but helped write the blog post.

These issues are technically classified as local code execution (AV:L), but they go against a pretty strong user expectation: that opening a file should be safe. In reality, they can be triggered through very common workflows like downloading and opening files, which makes them feel a lot closer to some remote scenarios, even if they’re not strictly RCE.

At the end of the day, regardless of how you classify them, it’s worth being aware of the risks when opening untrusted files in editors like Vim or Emacs.

When I wget a tarball, unzip, and emacs a.txt inside, I don't expect that it'd execute arbitrary commands.

I think people should be aware of this risk, especially when it looks like it's not getting fixed.

Disclosure: I didn't find the bugs. I helped wrote the blog post.

Thanks for sharing. I'm one of the co-authors of the blog post. Let me know if you have any questions!

tl;dr: We analyzed a LockBit v3 variant, and rediscovered a bug that allows us to decrypt some data without paying the ransom. We also found a design flaw that may cause permanent data loss. Nothing's earth-shattering, but it should be a fun read if you're into crypto and security!

It really is turned off. Companies like Google get huge fines when they break their promise -- even accidentally.

You can use Google Search and tell Google not to log your search history or use the data for advertising purposes. See my comment [1] for how to turn on these privacy controls.

[1] https://news.ycombinator.com/item?id=25383289

Google provides decent security/privacy controls, see my comment on how to turn them on [1].

If you have any specific concerns, I'd love to learn more and see if there's anything I can help.

[1] https://news.ycombinator.com/item?id=25383289

If you want to keep using Google services, here are some Google Alternatives Alternatives:

1/ Google Search, YouTube, Maps: visit https://myactivity.google.com/activitycontrols to turn on auto-deletion or turn off search history, location history or YouTube watch history. This page also allows you to turn off ads personalization. There are many security and privacy controls on https://myaccount.google.com/, turn them on however you see fit.

2/ Chrome: visit chrome://settings/syncSetup to turn off Chromesync, disallow Chrome sign-in, disable automcomplete searches and URLs, etc. You can also change the default search engine to something else, but see point 1/ if you want to use Google Search. Use Incognito mode more often.

3/ Gmail, Photos, Calendar, Drive, Docs: "we don’t use information in apps where you primarily store personal content—such as Gmail, Drive, Calendar and Photos—for advertising purposes, period." [1] In other words, Gmail, YouTube or Search ads are not targeted or personalized using your emails, photos, events, docs, etc.

Disclosure: I'm a Google's security engineer, advocating for and contributing to some of the aforementioned security/privacy controls.

[1] https://blog.google/technology/safety-security/keeping-priva...

>Crypto is hard because you don't get quick feedback on whether you are doing well.

Well said.

If you are to implement a sorting algorithm, you'll know immediately whether it works or is fast enough. Crypto doesn't provide this feedback. It's important to get help from others, if you can't tell yourself whether your code works.

I wrote this article to encourage people to study the field I love. If I wanted to tell people to back off, why would I bother providing advice, material and telling people to have fun?

>Those rules aren't easy to follow, but they are simple to know about.

If the rules were so simple, how come your library had a signature bypass vulnerability that you did NOT understand its root cause until I explained?

The root cause looks deceptively simple, until you take your time to understand the underlying math. I didn't fully understand it until a professor at MIT explained it to me. Maybe it's just that I'm stupid, but it is never simple to me.

>About not using your crypto until it's been vetted by professionals… How do you get those vaunted professionals to even look at your work?

You can't expect people to pay attention to your work until you earn it. Why would anyone bother reviewing a random library from a random dude? Frank of libsodium fame didn't start by writing a brand new library from scratch, but built it on top of NaCl. If he did that, nobody would take him seriously either.

>About CTF (Capture The Flag), and cryptopal challenges, my advice is: don't waste your time. The penetration testing approach to secure systems does not work. You whack a mole, two more appear. We need ways to prevent whole classes of errors, like proofs. For instance, tools like https://verifpal.com/ can be a great help when designing a protocol.

This was how my friends and I got started. Maybe you were right that it isn't worth it, but it helps get us to where we are, being paid to do security and crypto.

There are two approaches to learning: top down or bottom up.

The former is what you get at university. If you want to learn crypto, you have to learn abstract algebra, linear algebra, probability theory, complexity theory, and computer security. If you want to learn complexity theory, you want to learn automata theory, computability theory, and algorithms. If you want to learn computer security, you want to learn computer architecture, operating systems, networking, etc.

The top down approach is systematic, but it might not prepare you for the real world. For that, you need internships and CTFs. They are reality checks with a fast feedback loop, showing you very quickly which skill or knowledge you are lacking or need improvement. They are also fun.