Zero-Day Vulnerability

A zero-day vulnerability is a security flaw in software that is unknown to the vendor or security community, meaning defenders have no advance warning and no patch available when attackers begin exploiting it.

The name comes from the development context: when a vulnerability is first discovered, the software vendor has had zero days to prepare a fix. The window between attackers' discovery and the availability of a patch is when organizations are most exposed.

Why zero-days are uniquely dangerous

Most security controls defend against known threats: patching known CVEs, scanning for known vulnerability patterns, and blocking known malicious indicators. Zero-days undermine all of these because the flaw is, by definition, not yet cataloged.

Three conditions make zero-days particularly severe:

No patch exists

The vendor cannot release a fix for a vulnerability they do not know about. Until the vulnerability is discovered, disclosed, and patched, every system running the affected software is exposed.

Detection is difficult

Signature-based security tools detect known attack patterns. A zero-day exploit has no prior signature. Traditional scanning tools produce no alert because they have no pattern to match.

Exploitation windows are shrinking

Cloudflare observed an attempt to exploit a new zero-day vulnerability just 22 minutes after its proof of concept was published (Cloudflare State of Application Security 2024). By the time most organizations become aware of a disclosure, active exploitation has already begun.

The component visibility gap that makes zero-days devastating for mobile teams

When a zero-day drops, the critical question is which of your production apps contains the affected component. Without a binary SBOM, answering that requires manually auditing every compiled binary. A process that takes days. With a current SBOM, it takes minutes.

The zero-day lifecycle

Understanding where risk concentrates helps prioritize controls.

Discovery: A researcher, threat actor, or vendor's own team identifies an unknown flaw. State-sponsored actors and commercial spyware vendors actively invest in zero-day discovery and maintain private exploit inventories.

Exploitation window: Attackers use the vulnerability before it is known or patched. For targeted attacks, this window may last months or years. For widely disclosed vulnerabilities, exploitation begins within hours of public disclosure.

Disclosure: The vulnerability is reported publicly, either through coordinated disclosure (the researcher notifies the vendor first) or through full public disclosure. This is the moment most organizations first learn they are exposed.

Patch and response: The vendor releases a patch. Organizations must identify which systems and applications are affected and deploy the fix. This is where most enterprises struggle.

The gap: The time between public disclosure and confirmed remediation across all affected systems. For mobile apps, this gap is especially wide because identifying which apps contain the affected component requires knowing exactly what is inside each compiled binary.

Zero-days in mobile apps: the component visibility problem

Mobile apps are assembled from many components: first-party code, open-source libraries, commercial SDKs, and framework packages. When a zero-day is disclosed in any one of these components, every app that includes it is immediately at risk.

The problem is that most security teams cannot quickly answer the question a zero-day disclosure demands: which of our production apps contain this component?

This is the mobile-specific zero-day challenge. In a server environment, an admin can query an asset inventory. For mobile apps, the compiled binary contains dependencies that are not always visible in the source code manifest. Third-party SDKs ship as pre-compiled binary components. Their internal dependencies are not declared anywhere that a source code scanner can read.

In December 2025, Google patched two Android framework zero-days (CVE-2025-48633 and CVE-2025-48572) that were actively exploited before patches were available. In 2025, Samsung patched a zero-day in an image display library, discovered and privately reported by security teams at Meta and WhatsApp. In each case, the affected component was part of the platform layer beneath the app. Organizations had no way to know until the vendor disclosed.

When a third-party SDK used in a production mobile app carries a zero-day, the discovery path is even harder. Most organizations do not know which SDKs are in which apps, which versions are in use, or what dependencies those SDKs have introduced.

How SBOM closes the zero-day detection gap

An SBOM (Software Bill of Materials) is a machine-readable inventory of every component, library, and dependency in an application. When a zero-day is disclosed for a specific component version, an organization with a current SBOM can immediately query its inventory to see which apps contain the affected component.

Organizations without current SBOMs face a manual audit across every production binary. During Log4Shell (CVE-2021-44228), organizations with SBOMs identified affected applications in hours. Those without took weeks. The same dynamic applies to every zero-day that affects a component present in a mobile app's binary.

Appknox generates binary-based SBOMs from compiled .ipa and .apk files as part of every automated security scan. Because the SBOM is generated from the binary, it captures SDK components and transitive dependencies that do not appear in source manifests. When a new zero-day is disclosed, the inventory already exists.

See:What is SBOM? |Appknox SBOM

How KnoxIQ applies exploitability scoring to zero-day findings

Not every app that contains a vulnerable component is equally at risk. How the component is used, which code paths invoke the vulnerable function, and what binary-level protections are in place all affect whether a zero-day is actually exploitable in a specific app.

KnoxIQ, Appknox's AI-powered exploitability validation layer, validates findings against real-device DAST results: does this vulnerability trigger in an authenticated session on a real device running this specific build? This validation applies to both known CVEs and newly disclosed zero-days, allowing security teams to distinguish between apps that are theoretically exposed and apps where the vulnerability is confirmed exploitable.

When a zero-day is disclosed, and an organization knows which apps contain the component, KnoxIQ answers the next question: which of those apps are actually exploitable right now?

Zero-days, OWASP, and compliance obligations

Zero-day vulnerabilities intersect with compliance frameworks in two ways.

Detection: OWASP Mobile Top 10 2024 M2 (Inadequate Supply Chain Security) specifically addresses the risk of third-party SDK components carrying undisclosed vulnerabilities. A binary SBOM-based component inventory is the foundational control for this category.

Response timelines: PCI-DSS requires remediation of critical vulnerabilities within 30 days of disclosure and immediately for actively exploited vulnerabilities. HIPAA requires organizations to identify and mitigate risks to ePHI. The speed at which a team can assess zero-day exposure across their mobile app portfolio directly determines whether they can meet these response windows.

Frequently asked questions

What is the difference between a zero-day and an n-day vulnerability?

A zero-day is a vulnerability that is not yet publicly known or patched. An n-day (or known vulnerability) is a previously disclosed vulnerability for which a patch exists. The "n" represents the number of days since the vulnerability was publicly disclosed. N-day vulnerabilities are still dangerous because many organizations have not yet applied available patches, but defenders at least have the option to patch. Zero-days offer no such option.

How are zero-day vulnerabilities discovered?

Zero-days are discovered through security research (both defensive and offensive), fuzzing and reverse engineering techniques, exploitation in the wild by threat actors, and bug bounty programs. State-sponsored groups and commercial spyware vendors actively research and stockpile zero-day exploits. Researchers who discover zero-days responsibly typically notify the affected vendor before public disclosure.

How long does a zero-day typically remain unpatched?

The window varies significantly. A vendor notified through responsible disclosure typically has 90 days to release a patch before the researcher publishes their findings publicly (the Google Project Zero standard). Zero-days discovered and used exclusively by attackers may remain unknown for months or years. Once publicly disclosed, patch deployment across all affected systems takes additional days to weeks.

How does SBOM help with zero-day response?

When a zero-day is disclosed in a specific software component, an organization with a current SBOM can immediately search its component inventory to determine which systems and applications contain the affected version. Without an SBOM, the same assessment requires manual inspection of each binary. During the Log4Shell incident in December 2021, organizations with SBOMs completed their impact assessments within hours. Those without took weeks.

For mobile apps specifically, binary-based SBOMs capture SDK dependencies that source code manifests do not declare.

Are mobile apps particularly vulnerable to zero-days?

Mobile apps face a compounded zero-day challenge. The underlying platform (iOS and Android frameworks) is subject to zero-days, as are the third-party SDKs embedded in every app. When a zero-day affects a component present in a mobile app binary, the developer of that app may have no visibility into the exposure without a binary-level component inventory. Platform zero-days (like the December 2025 Android framework vulnerabilities) are the responsibility of the OS vendor, but SDK zero-days are the responsibility of every team whose app includes that SDK.

Related:What is Penetration Testing? |What is SBOM? |What is a Vulnerability Assessment? |SBOM for Incident Response |What is MAST? |Appknox KnoxIQ

By Aadarsh Anand, Security Researcher, Appknox Security Research Team

Appknox is an enterprise mobile application security testing platform. This page was written by Appknox's security research team based on direct experience assessing zero-day exposure across mobile app portfolios, responding to critical CVE disclosures affecting third-party mobile SDKs, and triaging component risk using binary-based SBOM generation.

This page was drafted with AI assistance and reviewed and verified by the Appknox security research team.