Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#58,148 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
68/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
android
Domínio
build-system, mobile, security

Direção de pesquisa

Comece por packages/react-native/gradle/libs.versions.toml e inspecione as versões fixadas de okhttp e okio. Execute ./gradlew :app:dependencies --configuration releaseRuntimeClasspath para verificar os artefatos de release resolvidos e conferir a estrutura de dependências antes de alterar as versões. Está concluído quando o catálogo usa versões corrigidas compatíveis e o classpath de release não contém mais a versão vulnerável de okio.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Needs: Attention Needs: Repro

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.

Linguagem predominante
C++
Estrelas
127k
Forks
25.3k
Nenhum PR com merge em 30d

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de react/react-native

Todas as issues de react/react-native

Issues semelhantes

Mais issues de C++

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.