Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Product launch: Appknox now checks every uploaded build against Apple App Store and Google Play submission requirements, so blockers surface while you can still fix them. Many mobile release processes have a security gate. Fewer have a store gate, so the first full check against Apple's and Google's rules often happens after the build is final and the date is public. That's the gap Appknox Store Release Readiness closes.

A security scan and an app store review ask different questions. Here's why app store rejection happens to secure builds, and what enterprise mobile teams check before they submit. Your build passed binary SAST. DAST ran clean on real devices. QA signed off, and the launch date went out to customers. Then the store console said no. Nothing in the security report was wrong. It was answering a different question.

In this blog, I'll explain how I found the LinkPresentation out-of-bounds write, later assigned CVE-2026-112621 and fixed in iOS 27.2 and macOS Golden Gate 27.2. LinkPresentation is the framework Apple uses to build link previews, and on an unpatched Mac, one crafted preview in Messages was enough to crash it. That fix shipped on October 26, 2026, and Apple credited me, Vinay Kumar Rasala (Xplo8E) of Appknox, alongside an anonymous researcher.

KnoxIQ is the agentic triage layer in Appknox. It takes the findings from your SAST and DAST scans, filters out the ones that aren't real and ranks the rest by how exploitable they are in your build. For each one, it shows you how to reproduce it and writes a fix for your app, including a prompt for Claude Code, Cursor, Github Copilot or any AI coding agent.

On October 21, 2026, PHP shipped emergency fixes for two flaws that let anyone on the internet run code on a PHP web server, with no login. The weakness behind them had been flagged in 2024 and then sat, partly because nobody had proved it was exploitable. In 2026, researchers working with AI models proved it within days. Exploit attempts started before the fix shipped, and details leaked a day ahead of schedule. That sequence is the real story of PHP2Shell. The bug matters, but speed matters more.

Appknox MCP agent connects your AI coding agent to your Appknox scan results and KnoxIQ analysis. Your agent triages findings by exploitability, fixes the code in your repo and verifies each fix with a re-scan, inside Claude Code, Cursor, GitHub Copilot, Codex or Windsurf. Your AI coding agent already writes features, refactors code and fixes bugs. It can't see your security findings. So when a scan flags a vulnerability in your mobile app, the fix still starts by hand.

Since 11 September 2026, an actively exploited flaw in your app starts a 24-hour reporting clock under the EU's Cyber Resilience Act. That's expensive if you don't know what's running, and an edge if you do. For most companies, an app is a channel. For a mobile-first company, it is the business: the bank branch, the checkout counter, the boarding gate, the clinic waiting room. Until this year, however, the law mostly treated it like a channel.

AI has lowered the cost of building mobile security tooling to near zero. However, it has not lowered the cost of operating it. Building a scanner is now a weekend project, while sustaining detection accuracy, threat research, real-device infrastructure, and developer trust across years remains a full organizational commitment. That distinction is the entire build-versus-buy question in 2026, and most evaluations get it wrong by measuring the wrong thing.

Annual testing secures a moment. Your app keeps changing. Here is how to cover the interval between assessments. An annual penetration test answers a precise question. Was this version of this application secure when a skilled tester examined it? That answer has real value. It is independent, deep, and finds business logic flaws that no scanner will ever surface. It is also a photograph.

DORA compliance for mobile applications is the process of identifying, testing, and documenting mobile ICT risks in line with Regulation (EU) 2022/2554, covering Articles 8, 9, 10, 24, and 25, through vulnerability assessments, security testing, and audit-ready evidence generation that financial institutions can present to regulators, auditors, and internal governance bodies.