The React Native CVE list you should actually monitor
React Native itself has had a handful of CVEs, mostly in dev-time tooling. The framework's user-facing runtime is rarely the vulnerable layer.
The real exposure is the dependency graph — JavaScript packages, Cocoapods, Android Gradle dependencies. The same CVEs hit React Native apps that hit Node.js services, because they share so much of the JS ecosystem.
Monitor at three layers (JS, iOS native, Android native). Triage by reachability, not just CVSS score. Pre-release scans catch what monthly audits miss.
If you ask "is React Native secure?" you're asking the wrong question. The framework is mostly fine. The question worth asking is "which of the 800 transitive dependencies in your lockfile have known vulnerabilities, and do any of them reach the network path?"
This post is the curated list. The categories of CVE that consistently hit React Native apps, how to monitor each, and how to triage what actually matters.
The React Native framework itself
Direct CVEs against the react-native package on npm are uncommon. The handful that have appeared cluster around:
- Development server vulnerabilities (Metro bundler, local debug endpoints)
- WebView misconfigurations in the bundled component
- Build-time tooling issues
What's almost never the source of a CVE: the runtime that ships in your app's binary. The bridge, the renderer, the core component library — these have been audited extensively and don't tend to surface vulnerabilities.
This is good news on the framework, but it's the wrong place to focus security attention. The framework is the small surface; the dependency graph is the large one.
JavaScript dependency CVEs
This is the dominant source. A typical React Native app's lockfile lists 800–1500 packages, including transitive dependencies. CVEs surface in this graph constantly.
The recurring offenders:
| Package category | Why it matters | How it reaches your app |
|---|---|---|
| HTTP libraries (Axios, node-fetch) | Sees every outbound request | Direct install or transitive through analytics/Firebase |
| XML/JSON parsers (xml2js, JSON5) | Often handles untrusted input | Transitive through deep dependency chains |
| Crypto wrappers (older crypto-js, etc.) | Wrong defaults can leak data | Direct install for auth flows |
| Utility libraries (lodash, semver) | Prototype pollution, ReDoS | Transitive everywhere |
| Dev tooling (Webpack plugins, bundler add-ons) | Affects CI rather than production | devDependencies |
The Axios chain in 2024 was the highest-impact recent example. Multiple successive Axios CVEs propagated through Firebase, Sentry, and analytics wrappers. Teams that hadn't bumped Axios in 18 months had exposure they didn't know about until npm audit started flagging it.
iOS / Cocoapods CVEs
Less attention than JS, but real. The pod graph for a typical React Native iOS project pulls in 30–80 native dependencies. CVEs in this layer are reported through Apple's security disclosures and through the upstream projects' own advisories — but npm audit doesn't see them.
Common categories:
- Networking stacks (AFNetworking historically, Alamofire occasionally) — older versions had TLS verification issues
- JSON parsers (SBJSON variants, JSONKit) — usually only in older apps
- Crypto libraries (CommonCrypto wrappers, third-party crypto pods)
- WebSocket libraries (older SocketRocket forks)
- Image decoding (SDWebImage has had a few)
The pattern: a React Native app installs react-native-firebase, which installs the Firebase iOS pod, which depends on a specific version of some underlying networking library. The vulnerability is three levels deep. Your Podfile.lock shows it; npm audit doesn't.
Android / Gradle CVEs
Similar story on the Android side. Gradle dependencies pulled in transitively through React Native's own pinning and through third-party libraries.
The categories that matter:
- OkHttp — direct CVEs occasionally, plus the transitive impact of the JS HTTP client choices
- Gson / Moshi / Jackson — parser CVEs that affect anywhere JSON is deserialized
- Older Apache Commons libraries — surface in legacy SDKs
- Conscrypt and BoringSSL variants — TLS implementations bundled into some pods
Android's tooling is somewhat better here — Gradle Enterprise and the dependency-vulnerability scanning that integrates with Android Studio surface a lot of this. But the React-Native-side awareness usually isn't wired into the same monitoring.
Supply-chain incidents
Not all CVEs come from accidental bugs. Some come from malicious package publication.
The 2025 @react-native-aria typosquat is the most recent React-Native-relevant example. A malicious package was published with a name close enough to a real React Native library that developers installed it by mistake. The package executed arbitrary code on install — affecting the developer machine and any CI that ran npm install against the malicious version.
Other supply-chain patterns to watch:
- Compromised maintainer accounts. A real library gets a malicious update because the maintainer's npm account was phished.
- Dependency confusion. An internal package name gets registered on public npm and your package manager pulls the malicious public version.
- Postinstall scripts that exfiltrate. Less subtle, but still appears in libraries from time to time.
The defense is the same in each case: pinned lockfiles, scoped names, suspicious-package monitoring, and a habit of looking at what's about to be installed before running npm install on something new.
How to monitor at each layer
| Layer | Tools | Frequency |
|---|---|---|
| JavaScript dependencies | npm audit, yarn audit, GitHub Dependabot, Snyk, our free scanner | Every PR, plus weekly batch |
| iOS Cocoapods | Cocoapods-audit projects, commercial scanners, our scanner | Monthly + pre-release |
| Android Gradle | Android Studio's built-in checks, OWASP dependency-check, commercial tools | Monthly + pre-release |
| Framework / native modules | React Native release notes, GitHub Security Advisories | Each React Native bump |
| Supply chain | Lockfile diff review on every PR, npm publish notifications | Continuous |
The thing teams most commonly miss: the JS-only audits don't see native CVEs. If npm audit is your only check, your iOS and Android native dependencies are unmonitored.
Triage: severity vs reachability
A CVSS score isn't an action item. The same CVE can be critical in one app and irrelevant in another, depending on whether the vulnerable code path is reachable.
Triage questions:
- Is the vulnerable code path actually called? A CVE in
lodash.templatedoesn't matter if you don't use templates. - Does the input come from an attacker? A JSON parsing CVE matters more in code that parses network responses than in code that parses bundled config.
- What's the impact? Remote code execution beats denial-of-service beats information disclosure. Within each category, the actual exposure varies.
- Is the CVE in a dev dependency or a production one? Dev-only CVEs affect your build system; production CVEs affect users.
- Is there a fix available, and how disruptive is upgrading? Sometimes the fix is a patch release. Sometimes it requires a major version bump that's a project.
The output of triage is one of four actions: upgrade now, schedule for next release, document and accept, or no action needed. Most CVEs end up in "schedule" — they're real, but not on-fire.
A practical monitoring rhythm
- Per-PR:
npm auditin CI on every PR. Block merges on critical issues in production dependencies. Warn on others. - Weekly: Triage Dependabot alerts. Most are routine library bumps; a few will need real attention.
- Monthly: Run a native-aware scan (iOS Cocoapods, Android Gradle). Catch the layer that JS audits miss.
- Pre-release: Comprehensive scan across all layers. The release is the moment to be paranoid.
- Quarterly: Dependency hygiene pass — abandoned libraries, accumulated patches, dependency graph health.
- On news: When a major CVE makes the rounds (Axios chain, Log4Shell-shaped incidents), do an emergency audit for that specific issue and any related dependencies.
The teams that get caught off-guard by CVEs are usually the ones who treat security as a project rather than a rhythm. A monthly cadence with clear triage rules beats a heroic quarterly audit that doesn't happen on schedule.
Run a multi-layer scan now
The free scanner checks JavaScript dependencies, iOS pods, and Android Gradle dependencies against the known-CVE databases for each. About 90 seconds, no signup. Gives you the multi-layer view that npm audit alone doesn't.
Frequently Asked Questions
Does React Native itself have CVEs?
Yes, but they're rare. The framework has had a handful of CVEs over its lifetime, mostly in development-time tooling rather than the runtime that ships to users. The much larger exposure is the dependency graph React Native pins — Cocoapods, Gradle dependencies, JavaScript packages — where CVEs are common and patches require keeping the framework current.
How do I check for CVEs in a React Native app?
Three layers. npm audit (or yarn audit) covers JavaScript dependencies. GitHub Dependabot alerts cover the same on the JS side plus some native dependency awareness. For iOS Cocoapods and Android Gradle/Maven, you need a tool that understands those ecosystems — a few commercial tools cover this, and our free scanner covers it for React Native projects specifically. Run all three at least monthly; the JS-only audits miss native CVEs.
What's the most common CVE category in React Native apps?
Transitive JavaScript dependencies in network and parsing libraries. Axios, xml2js, semver, lodash, and similar foundational packages have had recurring CVE cycles. The vulnerabilities usually reach React Native apps via library dependency chains, not direct installs. The 2024 Axios chain was the highest-impact recent example.
Does a high CVSS score mean a CVE is urgent for my app?
Not necessarily. CVSS measures theoretical severity in a default context. A "high" or "critical" CVE in a server-side dependency may have little impact in a mobile app where the vulnerable code path isn't exercised. Conversely, a "medium" CVE in a library handling untrusted input from the network may be more urgent than a "critical" one in a dev-only package. Triage by reachability, not by raw score.
What was the @react-native-aria typosquat?
A 2025 incident where a malicious package was published with a name similar to a real React Native library. Apps that installed the typosquat ran malicious code on the developer's machine and potentially in CI. The fix was straightforward — uninstall the bad package, audit npm install logs for the time window when it could have been installed. The lesson was the broader one: lockfile hygiene and dependency-name vigilance matter more than most React Native teams treat them.
How often should I scan my React Native app for CVEs?
At minimum, on every release. Realistically, on every dependency change — most CI systems can run npm audit and a native-aware scanner on every PR. Quarterly deep audits are reasonable for the lower-tier issues that don't block CI. Pre-release, run the most thorough check you have, including the iOS and Android native dependencies that the JS-only audits miss.