rn-fetch-blob: Maintenance Status, Risks, and Alternatives

The rn-fetch-blob npm package is effectively abandoned — its last release, 0.12.0, shipped in mid-2020, and the maintained continuation of the project is react-native-blob-util. If your React Native app still lists rn-fetch-blob in package.json, you're not running dangerous code today so much as running frozen code: no fixes for new Android and iOS API requirements, no patches if a vulnerability is found, and a growing pile of workarounds in your own codebase to compensate. This review lays out the lineage, what "unmaintained" concretely costs you in a native module, and a low-drama migration path.

A package with two forks in its family tree

The lineage matters because it explains both the popularity and the abandonment. The original project was react-native-fetch-blob, a hugely popular library for file access, file transfer, and blob handling in React Native — things the built-in fetch implementation historically handled poorly. When that project stalled, the community moved to the rn-fetch-blob fork under the joltup org, which carried development forward for a couple of years. Then that fork stalled too: version 0.12.0 in 2020 was the end of the line, and the repository's own documentation now points to the next continuation.

That continuation is react-native-blob-util, maintained by Ron Radtke. It began as a fork of rn-fetch-blob, kept API compatibility, and — crucially — kept shipping: recent releases track modern React Native versions, including the new architecture, with current releases supporting React Native 0.78+. Anyone searching npm fetch libraries for React Native today should treat react-native-blob-util as the canonical package in this family.

What "unmaintained" costs you in a native module

An abandoned pure-JavaScript utility mostly just gets stale. An abandoned native module rots faster and in more damaging ways, because it has platform code compiled into your app:

Platform API drift. Every Android target-SDK bump (scoped storage, notification permissions, foreground service rules) and iOS privacy change lands in native code that nobody is updating. Teams still on rn-fetch-blob typically carry patch-package diffs or vendored forks just to keep builds green — at which point you're maintaining the library yourself, without the upstream test suite.

New architecture incompatibility. React Native's TurboModules/Fabric migration requires active adaptation from native modules. A library frozen in 2020 predates all of it. As the old architecture is phased out, rn-fetch-blob moves from "stale" to "won't work."

No security response. File download, file system access, and network transfer code is exactly where path traversal, insecure temp file, and transport bugs live. With no maintainer, there is no advisory process, no patched release, and scanners can only tell you the package is old — not that someone will fix it. Unmaintained status is itself a finding: most dependency-health tooling, including SCA platforms like Safeguard, flag last-publish age and archived repositories as risk signals precisely because remediation options collapse when there's no upstream.

Dependency-resolution friction. Old native modules pin old Gradle/CocoaPods expectations. Each React Native upgrade turns into an archaeology session.

Concrete risk assessment if you're still on it

Being honest rather than alarmist: there is no widely publicized critical CVE that makes rn-fetch-blob an emergency to remove this week. The risk profile is structural:

1. Likelihood of future unpatched issues: elevated. File/network native code, zero maintenance.
2. Blast radius: high. The library commonly handles downloaded documents, cached media, and auth-bearing transfers — often with broad storage permissions.
3. Exploit prerequisites: usually app-specific (attacker-influenced URLs or filenames reaching the library), so audit your call sites: anywhere a server response or user input becomes a file path or download target deserves validation regardless of which blob library you use.
4. Compliance: if you attest to dependency-maintenance policies (SOC 2 vendor-management style controls, customer security questionnaires), a six-year-dormant native dependency is the kind of line item assessors ask about.

Migration: smaller than you fear

Because react-native-blob-util forked from rn-fetch-blob with compatibility as an explicit goal, migration is mostly mechanical:

npm uninstall rn-fetch-blob
npm install react-native-blob-util
cd ios && pod install

Then a codemod-grade rename:

// before
import RNFetchBlob from "rn-fetch-blob";

// after
import ReactNativeBlobUtil from "react-native-blob-util";

The config object, fetch progress API, and fs namespace carry over for typical usage (config({ fileCache: true }), .fetch("GET", url), fs.dirs.DocumentDir, and friends). Budget real testing time for the platform-specific corners: Android download-manager integration, content-URI handling under scoped storage, and iOS background transfers — these are where the maintained fork has diverged most, because that's where the OS changed most.

Two hygiene steps while you're in there:

• Grep for patch-package patches or vendored copies of rn-fetch-blob and delete them; carrying old patches onto the new package is a classic source of ghost bugs.
• Verify TLS and redirect behavior on your critical transfer paths after the swap — transport-layer defaults are the kind of thing that silently differs between a 2020 native stack and a current one. Exercising those flows with a dynamic scanner against your staging API is a cheap confidence check.

The general lesson: track liveness, not just CVEs

rn-fetch-blob is a case study in the gap between "no known vulnerabilities" and "safe to depend on." A scanner that only matches CVE ranges will pass it forever. The signals that actually predicted this situation — last publish date, repository archive status, open issue count with no maintainer responses, existence of an active fork absorbing the community — are all observable years before any CVE would be. Make at least one of them a gate in your dependency-review process, and revisit your React Native native-module inventory annually; the ecosystem's platform churn makes mobile trees rot faster than server-side ones.

FAQ

Is rn-fetch-blob deprecated?

It's unmaintained rather than formally deprecated on npm: the last release (0.12.0) shipped in 2020, and the project's own family of repositories points to react-native-blob-util as the continuation. Practically, treat it as deprecated.

Is react-native-blob-util a drop-in replacement?

Very nearly. It maintains API compatibility with rn-fetch-blob for standard usage, so most migrations are an install plus an import rename, with focused retesting on Android storage and iOS background-download flows.

Does rn-fetch-blob have known CVEs?

There's no headline CVE driving urgency; the risk is the absence of any patch path if one appears, combined with accumulating incompatibility with current Android/iOS requirements and React Native's new architecture.

How do I find other unmaintained packages in my app?

Check last-publish dates and repo activity for your direct dependencies (npm view <pkg> time.modified scripts work at small scale), or use dependency-health tooling that scores maintenance signals across your whole tree automatically — native modules first, since they age worst.