Upgrade commons-lang3 to 3.18.0 to fix CVE (Uncontrolled Recursion)

[SandraAhlgrimm]

Summary

This PR upgrades commons-lang3 from 3.17.0 to 3.18.0 to fix a High Severity security vulnerability.

Vulnerability Details

• CVE: SNYK-JAVA-ORGAPACHECOMMONS-10734078
• Type: Uncontrolled Recursion
• Severity: High
• Fixed in: commons-lang3 3.18.0

Description

Uncontrolled recursion occurs when a function calls itself repeatedly without proper termination conditions, which can lead to:

• Stack overflow crashes
• Denial of Service (DoS) attacks

Affected Dependency Paths

The vulnerability was introduced through multiple transitive dependency paths:

1. org.apache.tika:tika-parsers-standard-package → tika-parser-code-module → [email protected]
2. com.azure:azure-spring-data-cosmos → [email protected]
3. io.rest-assured:json-path → rest-assured-common → [email protected]

Affected Modules (24 modules with compile-scope dependency)

The following modules had commons-lang3 as a compile dependency:

• spring-ai-tika-document-reader
• spring-ai-azure-cosmos-db-store
• spring-ai-cassandra-store
• spring-ai-weaviate-store
• spring-ai-milvus-store
• spring-ai-anthropic
• spring-ai-elevenlabs
• spring-ai-model-chat-memory-repository-cosmos-db
• spring-ai-spring-boot-docker-compose
• spring-ai-spring-boot-testcontainers
• spring-ai-autoconfigure-vector-store-weaviate
• spring-ai-autoconfigure-vector-store-milvus
• spring-ai-autoconfigure-vector-store-cassandra
• spring-ai-autoconfigure-vector-store-azure-cosmos-db
• spring-ai-autoconfigure-model-anthropic
• spring-ai-autoconfigure-model-elevenlabs
• spring-ai-autoconfigure-model-chat-memory-repository-cosmos-db
• spring-ai-starter-vector-store-azure-cosmos-db
• spring-ai-starter-vector-store-cassandra
• spring-ai-starter-vector-store-milvus
• spring-ai-starter-vector-store-weaviate
• spring-ai-starter-model-anthropic
• spring-ai-starter-model-elevenlabs
• spring-ai-starter-model-chat-memory-repository-cosmos-db

Many additional modules had the dependency in test scope.

Solution Approach

Why Parent POM vs Per-Module?

The fix is applied in the parent pom.xml dependencyManagement section rather than in individual modules because:

1. Single point of management - Easier to update when newer versions are released
2. Consistency - Ensures all 24+ modules use the same fixed version
3. Future-proofing - Automatically covers any new modules that might transitively depend on commons-lang3
4. Reduced maintenance - Avoids duplicating the override in 24+ module pom.xml files
5. Maven best practice - Central dependency version management is the recommended approach for multi-module projects

Verification

Snyk scan after the fix shows no commons-lang3 vulnerabilities.

[ilayaperumalg]

@SandraAhlgrimm Thanks for the PR!

The main branch already uses commons-lang3 3.19.0 via Spring Boot 4.0.0. Perhaps, this is meant for 1.1.x branch only. In that case, Could you submit the PR against 1.1.x branch instead? Thanks!

[ilayaperumalg]

Pushed the changes into 1.1.x via af6496a