druid/35.0.1-r1: cve remediation

[octo-sts]

druid/35.0.1-r1: fix GHSA-vc5p-v9hr-52mj

Advisory data: https://github.com/wolfi-dev/advisories/blob/main/druid.advisories.yaml

---

"Breadcrumbs" for this automated service

• Source Code: https://go/cve-remedy-automation-source
• Logs: https://go/cve-remedy-automation-logs
• Docs: (not provided yet)

Inspected git repositories: https://github.com/apache/druid.git@druid-35.0.1

[octo-sts]

🧪 Build Failed: Runtime Test Failure

Exception in thread "main" java.lang.NoSuchFieldError: INSTANCE at org.apache.logging.log4j.core.LoggerContext.(LoggerContext.java:108)

Build Details

Category	Details
Build System	Maven
Failure Point	org.codehaus.mojo:exec-maven-plugin:3.5.1:exec (pull-deps) on project distribution

Root Cause Analysis 🔍

NoSuchFieldError indicates a runtime compatibility issue between log4j dependencies. The INSTANCE field is missing from the LoggerContext class, suggesting incompatible versions of log4j-core and related log4j libraries are present on the classpath. This is likely caused by conflicting versions of log4j dependencies after the pombump version updates applied earlier in the build process.

---

🔍 Build failure fix suggestions

Found similar build failures that have been fixed in the past and analyzed them to suggest a fix:

Suggested Changes

File: pom.xml

• addition (properties section)
  Replacement:

<log4j.version>2.24.1</log4j.version>

Content:

Add log4j version property to ensure consistent versioning across all log4j components

File: pom.xml

• addition (dependencyManagement section)
  Replacement:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-bom</artifactId>
      <version>${log4j.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Content:

Add dependency management entries to force consistent log4j versions

File: extensions-core/druid-pac4j/pombump-deps.yaml

• addition (dependencies section)
  Replacement:

- groupId: org.apache.logging.log4j
  artifactId: log4j-core
  version: 2.24.1
- groupId: org.apache.logging.log4j
  artifactId: log4j-api
  version: 2.24.1
- groupId: org.apache.logging.log4j
  artifactId: log4j-slf4j-impl
  version: 2.24.1

Content:

Add log4j version constraints to prevent version conflicts in pac4j extension

Click to expand fix analysis

Analysis

No similar fixed build failures were provided for analysis. However, the error indicates a NoSuchFieldError for the INSTANCE field in log4j's LoggerContext class, which is a classic symptom of log4j version conflicts on the classpath. This typically occurs when different log4j components (log4j-core, log4j-api, log4j-slf4j-impl, etc.) have mismatched versions after dependency updates. The pombump operations likely introduced version conflicts between log4j dependencies.

Click to expand fix explanation

Explanation

The NoSuchFieldError for the INSTANCE field in LoggerContext indicates that incompatible versions of log4j components are present on the classpath. This typically happens when log4j-core and log4j-api have different versions, causing binary incompatibility. The suggested fix addresses this by: 1) Adding a centralized log4j.version property to ensure version consistency, 2) Using log4j-bom (Bill of Materials) in dependencyManagement to enforce consistent versions across all log4j artifacts, and 3) Explicitly constraining log4j versions in the pac4j extension's pombump configuration since that module had specific pombump operations applied. The log4j-bom approach is the recommended way to manage log4j dependencies and prevents version mismatches that cause NoSuchFieldError exceptions. Version 2.24.1 is used as it's a recent stable release that should be compatible with the current Druid codebase.

Click to expand alternative approaches

Alternative Approaches

• Add explicit exclusions for log4j dependencies in problematic transitive dependencies and then add direct dependencies with consistent versions
• Use Maven's enforcer plugin with dependency convergence rules to detect and prevent version conflicts at build time
• Downgrade all log4j dependencies to a known working version that was used before the pombump operations
• Use Maven dependency resolution strategies like 'nearest wins' by declaring log4j dependencies directly in the root pom with specific versions

---

Was this comment helpful? Please use 👍 or 👎 reactions on this comment.