This is a dependency/security report, not a runtime crash — there's no code reproducer, since the issue is a static pinned version, not a behavior bug. Evidence is the dependency tree below instead.
Description
packages/react-native/gradle/libs.versions.toml pins:
okhttp = "4.9.2"
okio = "2.9.0"
okio 2.9.0 is affected by CVE-2023-3635 / GHSA-w33c-445m-f8w7 ("Okio Signed to Unsigned Conversion Error"), fixed in okio 3.4.0.
This isn't a transitive/incidental pull-in — it's explicitly pinned in RN's own version catalog, and it lands on the actual shipped release classpath of a consuming app (confirmed via ./gradlew :app:dependencies --configuration releaseRuntimeClasspath), not just test tooling:
com.squareup.okhttp3:okhttp:{strictly 4.9.2}
com.squareup.okio:okio:{strictly 2.9.0}
I checked whether a newer RN version already fixes this before filing — it doesn't. I compared the same file across:
v0.79.6 (a currently-supported release): okhttp = "4.9.2", okio = "2.9.0"main (current unreleased development branch, 0.87.0-main): okhttp = "4.9.2", okio = "2.9.0" — identical, no bump even in active development
So there's no RN version, released or in development, that resolves this by upgrading.
I also tried working around it downstream, in case that's a viable interim path for consumers: resolutionStrategy.force 'com.squareup.okio:okio:3.4.0' in a consuming app's build.gradle. This fails resolution — okio 3.x split into a separate okio-jvm artifact, and something in RN's own OkHttp/Fresco dependency graph (which strictly pins okio) can't resolve against that new layout. So this isn't something a consuming app can safely patch around either; it needs to be addressed in RN's own version catalog (bumping okhttp to a release built against a patched okio, and updating the okio pin to reflect that).
Steps to reproduce
Not applicable in the usual crash-reproduction sense — this is a static dependency pin, reproducible by inspecting the file directly:
curl -s https://raw.githubusercontent.com/facebook/react-native/main/packages/react-native/gradle/libs.versions.toml | grep -E '^okhttp|^okio'
Or from any consuming app: ./gradlew :app:dependencies --configuration releaseRuntimeClasspath | grep -i okio
React Native Version
Confirmed present on 0.79.6 (currently-supported release) and on main (0.87.0-main, current development).
Affected Platforms
- Runtime - Android
- Build - MacOS
Output of npx @react-native-community/cli info
Not applicable — this is a static analysis of RN's own committed version catalog file, not an environment-specific issue.
This is a dependency/security report, not a runtime crash — there's no code reproducer, since the issue is a static pinned version, not a behavior bug. Evidence is the dependency tree below instead.
Description
packages/react-native/gradle/libs.versions.tomlpins:okio2.9.0 is affected by CVE-2023-3635 / GHSA-w33c-445m-f8w7 ("Okio Signed to Unsigned Conversion Error"), fixed in okio 3.4.0.This isn't a transitive/incidental pull-in — it's explicitly pinned in RN's own version catalog, and it lands on the actual shipped release classpath of a consuming app (confirmed via
./gradlew :app:dependencies --configuration releaseRuntimeClasspath), not just test tooling:I checked whether a newer RN version already fixes this before filing — it doesn't. I compared the same file across:
v0.79.6(a currently-supported release):okhttp = "4.9.2",okio = "2.9.0"main(current unreleased development branch,0.87.0-main):okhttp = "4.9.2",okio = "2.9.0"— identical, no bump even in active developmentSo there's no RN version, released or in development, that resolves this by upgrading.
I also tried working around it downstream, in case that's a viable interim path for consumers:
resolutionStrategy.force 'com.squareup.okio:okio:3.4.0'in a consuming app'sbuild.gradle. This fails resolution — okio 3.x split into a separateokio-jvmartifact, and something in RN's own OkHttp/Fresco dependency graph (whichstrictlypins okio) can't resolve against that new layout. So this isn't something a consuming app can safely patch around either; it needs to be addressed in RN's own version catalog (bumpingokhttpto a release built against a patched okio, and updating theokiopin to reflect that).Steps to reproduce
Not applicable in the usual crash-reproduction sense — this is a static dependency pin, reproducible by inspecting the file directly:
Or from any consuming app:
./gradlew :app:dependencies --configuration releaseRuntimeClasspath | grep -i okioReact Native Version
Confirmed present on 0.79.6 (currently-supported release) and on
main(0.87.0-main, current development).Affected Platforms
Output of
npx @react-native-community/cli infoNot applicable — this is a static analysis of RN's own committed version catalog file, not an environment-specific issue.