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

Bắt đầu với packages/react-native/gradle/libs.versions.toml và kiểm tra các phiên bản được ghim của okhttp và okio. Chạy ./gradlew :app:dependencies --configuration releaseRuntimeClasspath để xác minh các artifact release đã được phân giải và kiểm tra cấu trúc dependency trước khi thay đổi phiên bản. Hoàn tất khi catalog sử dụng các phiên bản đã được vá và tương thích, đồng thời release classpath không còn chứa phiên bản okio dễ bị tấn công.

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.