Dear founder,
I'm writing this as a letter because I think the format will land harder than another structured guide. We've spent the past two years inside the codebases of dozens of mobile apps belonging to companies that look very much like yours. I want to tell you what we keep finding, why your normal security work isn't catching it, and what the conversation with your CTO needs to look like when you finish reading.
The bug class is memory corruption. You may have heard the term. You probably associate it with operating-system kernel work — the stuff Apple and Google's security teams handle, the kind of thing that shows up in news stories about Pegasus and Pegasus's successors. You're not wrong about that. But you are missing a piece, and the missing piece is your app.
Here's the part that's worth your attention.
The premise nobody tells you about modern mobile
Your iOS app is mostly Swift. Your Android app is mostly Kotlin. Your engineers will tell you that those languages are memory-safe — which is technically true. Swift and Kotlin (mostly) protect you from the specific bug class I'm about to describe.
But your app does not run only in Swift or Kotlin. Beneath the surface, in code that ships in your binary and runs on your users' phones, you have:
- An image processing library that almost certainly traces back to
libjpeg,libpng,libwebp, or one of their cousins. Written in C, decades old, maintained by volunteers. - A video and audio codec stack — likely FFmpeg or a derivative. Written in C, dauntingly complex, with a history of memory-corruption CVEs by the year.
- An encryption library — OpenSSL, BoringSSL, libsodium. C code, audited heavily but not perfectly.
- A SQLite database, embedded directly into your app's process.
- A handful of vendor SDKs — analytics, crash reporting, ads, push notifications. Several of these ship native code that runs inside your process with your permissions.
If you asked your CTO to enumerate every piece of C or C++ code that ships in your app, including transitively through every SDK, the answer would surprise you. Most teams have never produced that inventory. The first time we do it for a client, the line count usually runs into the millions. Of code your team didn't write. In a memory-unsafe language. Processing input your users hand it every day.
That is the surface I want to talk about.
Why I'm writing this letter now, in 2026
Three things happened in the last eighteen months that should be on your radar.
First, CVE-2023-4863 — a heap buffer overflow in libwebp. The library is everywhere. Apple's ImageIO uses it. Google Chrome uses it. Signal uses it. Slack uses it. Your app, if it handles images from any source, almost certainly uses it. A maliciously crafted WebP image, processed automatically, could compromise the parsing process. The fix shipped quickly. The fix did not reach every app simultaneously, because every app embedding libwebp had to update independently. Some apps still ship vulnerable versions today.
Second, in December 2025, Apple shipped emergency patches for two actively exploited memory-corruption bugs in WebKit — CVE-2025-43529 (a use-after-free) and CVE-2025-14174 (an out-of-bounds memory access in ANGLE). Both were used in what Apple described as "extremely sophisticated attacks against specific targeted individuals." Both triggered through malicious web content. If your app embeds a WebView, those bugs reached your users until they updated iOS.
Third, the commercial spyware industry — Pegasus, Predator, Graphite — continues to build its entire business model on memory corruption bugs in mobile platforms. Their toolchains chain a memory bug to a sandbox escape to a kernel privilege escalation. The initial bug almost always lives in a parser. Image, font, video, document, font, or message-format parser. The same parsers your app calls every time a user opens a photo.
What I want you to understand is that these are not three separate stories. They are one story. The memory-unsafe code that ships in modern mobile apps — yours included — is the playing field for the highest-stakes mobile security incidents of our era. The bugs in your dependencies are the bugs the high-end attackers chain.
What your security work is currently catching
If you've commissioned a mobile pentest in the last two years, the report probably contained findings like these: insecure data storage, missing certificate pinning, weak deep link handling, exposed activities, broken authorization on backend APIs. Useful work. Real findings. Worth fixing.
Notice what's not on that list.
Memory corruption testing requires different tools, different expertise, and different time. It's not what a typical "mobile pentest" — the four-day-fixed-price kind that most firms sell — covers. The reasons are honest: finding memory bugs in production native code requires reverse engineering, custom fuzzing harnesses, ASAN-instrumented rebuilds when source is available, and patient analysis of inputs that reach native code. A typical engagement budget doesn't accommodate the work.
The consequence is that the highest-impact bug class in mobile is also the one your security spending least likely covers. We see this gap on most engagements. The team has invested heavily in the bugs that are findable in three days, and not at all in the bugs that are findable in three weeks. The attacker is in no such hurry.
The categories where this gap matters most
Not every mobile app has the same exposure here. The math is roughly:
If your app processes media from untrusted sources — image uploads, video sharing, document previews, sticker handling, OCR, augmented reality — the memory corruption surface is large and the consequences are immediate. A malicious image arrives, your parser processes it, your app may execute attacker code in whatever sandbox your process has. The most public examples in the last decade — FORCEDENTRY, BlastPass, the recent Graphite chain — all started in this category.
If you ship messaging, video calling, photo sharing, social, dating, document collaboration, or anything with file attachments, you are in this category whether you wanted to be or not.
If your app embeds any third-party SDK that ships native code — and almost every app does — you have inherited those SDKs' memory safety record. The analytics SDK that crashed mysteriously last quarter may have had a memory bug. Or it may have had a memory bug that didn't crash quite as politely. Most teams have no visibility into this. The SDK runs in your process. Your process has access to the keychain. The math writes itself.
If your app has a backend protocol handler that runs in the background — push notifications, sync, WebRTC peer connections, P2P file transfer — the memory corruption surface fires before the user knows anything happened. The same dynamics that make iOS zero-clicks work apply, in smaller form, to your app's background processing. If your notification service extension parses arbitrary bytes from a push payload, you have a 0-click attack surface of your own.
If your app is none of these — a calculator, a to-do list, a simple e-commerce client — your exposure is genuinely lower. Not zero, because the third-party SDKs are still in your binary. But lower. You're paying for the exposure of the SDKs you ship, not the exposure of your own code.
The first three categories are where the conversation with your CTO is overdue.
What I'd ask your CTO this week
I am not going to give you a checklist with twenty items. I am going to give you four questions. Each one will produce a useful conversation regardless of the answer.
One: What native libraries ship in our app, including transitively through SDKs? When was each one last updated? The honest answer for most teams is "we don't have that list." Producing it is a week of engineering work. It is the foundation for every other answer in this letter. If your team can't tell you what's in the binary, they can't tell you which CVEs reach your users.
Two: For our highest-risk processing paths — image upload, video transcoding, document preview, push notification handling — do those run in stripped-down processes with limited permissions, or in the main app context with full access? Apple ships BlastDoor for system iMessage parsing because the parsing surface is dangerous. The same logic applies to your app's parsing surfaces. Most apps run them in the main process because nobody thought to do otherwise.
Three: When CVE-2023-4863 (libwebp) was disclosed, how long did it take us to ship an update with the fix? When CVE-2025-43529 was disclosed, how quickly did our app become safe? The answer here is your patch cadence, which is the most reliable defense you have against the bug class you can't test for directly. If the answer is "I'd have to check," check.
Four: What would it take for us to detect that one of our users had been compromised through our app's native code? What signal would we see, where, and how fast? The honest answer for most teams is "we wouldn't." That answer is fine, as long as everyone in the room knows it.
If you ask these four questions and your CTO has confident, specific answers — including line items and timelines — your team is ahead of most. If the answers are vague, that vagueness is the work you need to commission.
What this all costs to actually fix
I'll be honest with you about the trade-off, because most security writing isn't.
Memory safety on mobile is, in 2026, a real engineering investment. Doing it well looks like: a dependency inventory and update pipeline that catches every CVE in native libraries within a fixed SLA. A process sandbox for image and document parsing so a bug in those parsers doesn't compromise the full app. Native code review for any SDK before it ships in your binary. Periodic third-party native code assessments — not the four-day kind, the four-week kind — for high-risk apps.
That work is in the range of one to three engineer-quarters of effort, depending on your app's surface, plus the cost of the external review. For a typical Series B SaaS, this is meaningful budget but not capital-expense-meaningful. For a typical mobile app that handles user-generated media, it should not feel optional.
For most companies, the framing that lands is not "you should do this because security." It's "you should do this because the alternative is being the cheap link in someone else's chain, and the public record on what that looks like is right there in the Pegasus and Graphite disclosures." Your name does not have to appear in the next one. The companies whose names appear there did not, in most cases, know they were participating until after the disclosure.
What I want you to do tomorrow
Forward this letter to your CTO with a note that says, in your own words, "let's spend thirty minutes on this when you have time this week."
You do not have to make a decision in that meeting. You have to start the conversation. The dependency inventory question, on its own, will surface things that need attention. The patch cadence question will produce uncomfortable answers that are worth being uncomfortable about. The "would we detect this" question will tell you whether your detection layer matches your threat model, which is a useful thing to know regardless.
Most mobile app companies never have this conversation. The companies that do, in our experience, get materially safer over the next twelve months. Not because they patch every bug — that's not possible — but because they shift the focus of their security work from the bugs that are easy to test for to the bugs that are likely to bite them.
If, after the conversation, your team concludes that the gap is real and would benefit from outside help, we know how to find the right people. (We have, occasionally, been those people.) That is not the point of this letter, though.
The point of this letter is that there is a bug class running quietly underneath your app, in code your team did not write, with an attack record that is genuinely scary, and your normal security work is not catching it. That is the conversation worth having. The cost of having it is small. The cost of skipping it is the one I don't want to be the person writing about, two years from now, when somebody asks how the breach happened.
Yours,
— The team you'd hire if you ever decided this conversation was worth having
P.S. If you're a CTO reading this rather than the founder it's addressed to, the questions are the same. The honesty about your own answers is what matters. Most of the teams we work with start, by their own admission, with "we don't know" on at least two of the four. The "we don't know" is the diagnosis. The conversation is the treatment.