In Kotlin

Last updated: Aug 10, 2026

The following strategies are listed in escalation order: try each one in sequence and move to the next only if the previous one does not resolve the issue.

Identify the dependency chain

Strategies 2 and 3 require knowing which direct or intermediate dependency pulls in the vulnerable package. Ask Gradle:

./gradlew dependencyInsight --dependency <package> --configuration runtimeClasspath

In a multi-module build, prefix the task with the module, as in :app:dependencyInsight, and use that module's configuration (releaseRuntimeClasspath or debugRuntimeClasspath on Android).

Strategy 1: Update the transitive dependency

The first and simplest approach is to raise the minimum acceptable version of the vulnerable dependency through a constraint. Gradle resolves version conflicts by picking the highest requested version, so a constraint raises the floor without taking the decision away from the resolver.

Add the following to your build.gradle.kts:

dependencies {
  constraints {
    implementation("group:<package>:<safe-version>") {
      because("<advisory id>")
    }
  }
}

This works when nothing in the dependency tree pins the package to an exact vulnerable version. A dependency declaring a strict version will conflict with the constraint, and Gradle will fail the resolution instead of upgrading, in which case this strategy is insufficient.

Strategy 2: Update the direct or intermediate dependency

If the transitive dependency was not updated in the previous step, the direct or intermediate dependency is likely constraining its version. Update the version of the direct dependency in your build.gradle.kts:

implementation("group:direct-or-intermediate-artifact:new-version")

This may pull in a newer version of the transitive dependency that includes the security fix. Note that the direct dependency may already be at its latest version and still reference the vulnerable transitive package, in which case this strategy will also be insufficient.

Strategy 3: Use dependency overrides

When the constraint of strategy 1 is not enough, you can force a specific version. Unlike a constraint, force bypasses conflict resolution altogether: Gradle stops negotiating and imposes the version you name.

Add a resolution strategy to your build.gradle.kts:

configurations.all {
  resolutionStrategy {
    force("group:<package>:<safe-version>")
  }
}

Strategy 4: Wait for maintainers

If the override introduces breaking changes, the safest path is to wait for the upstream maintainers to resolve the vulnerability. This involves two separate releases:

1. The maintainers of the vulnerable package publish a patched version.
2. The maintainers of the direct or intermediate dependency release a new version that adopts the patched transitive dependency.

This process can take days or longer. In the meantime, you may accept the risk through your vulnerability management workflow and track the upstream activity to act as soon as a safe version is available.