okhttp/okio pinned at vulnerable versions (CVE-2023-3635) in gradle/libs.versions.toml, unchanged through current main

Start with packages/react-native/gradle/libs.versions.toml and inspect the okhttp and okio pins. Run ./gradlew :app:dependencies --configuration releaseRuntimeClasspath to verify the resolved release artifacts and check the dependency layout before changing versions. Done means the catalog uses patched compatible versions and the release classpath no longer contains the vulnerable okio version.

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.