Datadog dd-trace-java v1.51.2, the main version of OkHttp present in the agent’s runtime dependencies is still okhttp 3.12.15

[cjayacha]

Tracer Version(s)

1.51.2

Java Version(s)

Java 8 1.8

JVM Vendor

Oracle JDK

Bug Report

For CVE : CVE-2023-0833
in Datadog dd-trace-java v1.51.2, the main version of OkHttp present in the agent’s runtime dependencies is still okhttp 3.12.15 (as listed in gradle.lockfile).

Why is this?
OkHttp 4.x is a major breaking change from 3.x and requires Java 8+ and codebase updates.
While Datadog dd-trace-java does bundle/support OkHttp 4.x (since 0.106.0+) in some modules for its own internal HTTP communication and certain instrumentations, it also continues to bundle OkHttp 3.12.15 for backward compatibility—especially for instrumentation of applications that still use OkHttp 3.x.

Details:
Instrumentation Support:
The agent provides instrumentation modules for both OkHttp 3.x and OkHttp 4.x, so that it can trace apps that may use either version.

You see dependencies for both (but 3.x is often the main one in the agent jars).
See instrumentation/okhttp modules.
Backwards Compatibility:
Many legacy Java projects/applications still use OkHttp 3.x.

If Datadog dd-trace-java removed 3.x and shipped only 4.x, it would break auto-instrumentation for all those apps.
By providing both, the agent can seamlessly instrument both old and new OkHttp usage.
Agent-internal HTTP:
Internally, for communicating with the Datadog service, the agent may use a newer OkHttp version (4.x), but keeps 3.x for application instrumentation purposes.

Build Artifacts:
The primary dd-java-agent.jar will always include the versions needed for tracing your application, not just for agent internals.

Security Implications
If your application does NOT use OkHttp 3.x, the presence of 3.12.15 inside the agent does not mean your app is vulnerable—unless the agent is exposing it to your containers.
Anchore and other scanners may flag it simply because the .jar is present, even if it isn’t used by your runtime classpath.
What can you do?
If you are not running client code using OkHttp 3.x, you can ignore this finding (after validating it isn’t loaded via your app’s classpath).
If you are required to avoid shipping packages with any vulnerable libraries (even as dormant agent code), consider opening an issue with Datadog to request agent “slimming” for your use-case or track their community’s discussion.
For official agent remediation: You have to wait for the Datadog agent team to fully migrate all internal and compatibility usages to OkHttp 4.x and drop 3.x. You can monitor issue trackers for updates.
References:
dd-java-agent/gradle.lockfile at release/v1.51.x
Instrumenting OkHttp 3.x and 4.x modules
OkHttp 4.x upgrade considerations
Similar issue — DataDog/dd-trace-java#3664
Summary:
OkHttp 3.12.15 is still included in dd-trace-java 1.51.2 (and other recent versions) for application instrumentation compatibility. The presence does not necessarily imply it’s exploitable in your environment, but it may cause false positives in static scanners. Removal awaits broader ecosystem migration and agent changes by Datadog.

Expected Behavior

Should upgrade to the desired version to remove the CVE

Reproduction Code

No response

[mcculls]

Hi @cjayacha - dd-trace-java uses a fork of okhttp which includes a fix for that CVE:

• https://github.com/DataDog/dd-trace-java/blob/master/gradle/libs.versions.toml#L46
• fix: Hide header value if not valid okhttp#1

it also uses a fork of okio which includes a fix for a different CVE:

• Fix a bug where xlen larger than 0x7fff was rejected (1.x) okio#1

In terms of upgrading to later versions - OkHttp version 4.x is based on Kotlin, which brings packaging challenges as the Kotlin standard-library is a significant dependency to add and harder to embed in a way that won't conflict when dd-trace-java is added to an existing application.

In summary the fork of okhttp and okio that we bundle with dd-trace-java include fixes for those reported CVEs. We monitor all our tracing dependencies, which involves considering alternatives as our requirements change. While there is no immediate plan to replace the use of okhttp, it is something we may consider in the future.