The React Native CVE list you should actually monitor
Few advisories target the react-native package itself. A notable recent critical one, CVE-2025-11953, hit the React Native CLI's development server, a development-time tool. Most exposure sits in the dependency graph.
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
Advisories against the react-native package itself on npm are uncommon. Watch the tooling around it too. The clearest recent example is CVE-2025-11953 (GHSA-399j-vxmf-hjvr), a critical OS command injection in @react-native-community/cli and @react-native-community/cli-server-api. The development server could be reached from the network, so the risk is to developer machines and CI, not to users of the shipped app. The advisory lists affected versions 18.0.0, 19.0.0 prereleases through 19.1.1, and 20.0.0 prereleases, fixed in 18.0.1, 19.1.2, and 20.0.0. It has been in CISA's Known Exploited Vulnerabilities catalog since February 5, 2026, which means CISA has evidence of exploitation in the wild. If a project still resolves an affected CLI version, treat it as urgent.
That example shows why "where does the vulnerable code run?" is the first triage question: a critical advisory in development tooling calls for a different response than one in code that ships to users.
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 React Native app's lockfile often lists hundreds or thousands of packages once transitive dependencies are counted, and new advisories land in that graph regularly.
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 |
Popular HTTP clients are a good example of why this matters: Axios has accumulated many advisories across its 0.x line, so an app pinned to an old version can match a long list at once. Whether each one matters depends on how your app uses the client.
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. Vulnerabilities in this layer are reported through the upstream projects' own advisories and vulnerability databases, and npm audit doesn't see them because it only reads JavaScript packages.
Common categories:
- Networking stacks and TLS handling
- Parsers for JSON, XML, and other untrusted input
- Crypto wrappers and third-party crypto pods
- WebSocket libraries
- Image decoding libraries
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:
- HTTP and TLS libraries
- JSON and XML deserializers
- Older utility libraries that surface through legacy SDKs
- Bundled native code in third-party SDKs
Android has more tooling for this layer, such as OWASP Dependency-Check and dependency graph alerts on GitHub, but it usually isn't wired into the same monitoring as the JavaScript side. Check which ecosystems your chosen tool actually supports.
Supply-chain incidents
Not all CVEs come from accidental bugs. Some come from malicious package publication.
The June 2025 compromise of @react-native-aria and gluestack-ui packages is the most React-Native-relevant recent example. According to the maintainers' incident report, an attacker used a compromised publishing token to push modified versions of 17 packages containing a remote access trojan, and the incident was contained within 48 hours. Machines that installed those versions during the window, including developer laptops and CI, were the ones at risk.
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 | Upstream advisories and changelogs for each pod, commercial scanners that support CocoaPods | 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, and is it exploited? Weigh what an attacker gains in your app, and check exploitation evidence such as the CISA Known Exploited Vulnerabilities catalog or EPSS scores. Both cover CVEs only, so advisories with just a GHSA ID won't appear there.
- 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 (for example the June 2025 package compromise above, or Log4Shell-scale 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 the JavaScript packages in your lockfile against published npm security advisories. It does not check iOS pods or Android Gradle dependencies, so pair it with tools for those ecosystems.
Frequently Asked Questions
Does React Native itself have CVEs?
Yes, but they're rare. Advisories against the react-native package itself are uncommon; a notable recent critical advisory, CVE-2025-11953, affected the React Native CLI's development server rather than the shipped app. The much larger exposure is the dependency graph: JavaScript packages, CocoaPods, and Gradle dependencies, where advisories are common and some fixes require keeping React Native 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 JavaScript side and other ecosystems GitHub's dependency graph supports; check its supported-ecosystems list for your native setup. For iOS CocoaPods and Android Gradle/Maven, you need a tool that understands those ecosystems. Our free scanner covers only the JavaScript packages in your lockfile. 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 advisories. They usually reach React Native apps through dependency chains rather than direct installs.
Does a high CVSS score mean a CVE is urgent for my app?
Not necessarily. FIRST's CVSS user guide says CVSS measures severity, not risk. 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 and exploitation evidence, not by raw score.
What was the @react-native-aria package compromise?
In June 2025, an attacker used a compromised publishing token to release modified versions of 17 @react-native-aria and gluestack-ui packages containing a remote access trojan, according to the maintainers' incident report. It was not a typosquat: the real package names were affected. Teams that installed the affected versions needed to check their lockfiles, rebuild from clean versions, and rotate credentials on affected machines. The lesson: committed lockfiles, reviewed dependency updates, and fast advisory monitoring matter.
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.