Add VEX entry for CVE-2025-48924

[ppkarwasz]

This change introduces a VEX entry clarifying that Apache Commons Configuration is impacted by CVE-2025-48924 under some conditions.

Although parsing configuration files from untrusted sources is generally discouraged, the Commons Configuration Security Model was relaxed in February 2025 (see #540). These changes ensure that Commons Configuration is not vulnerable to remote code execution (RCE) or denial of service (DoS), even when processing untrusted input—provided safe usage patterns are followed.

This VEX entry documents those requirements and mitigation steps, helping downstream consumers assess the true impact of the vulnerability in their environments.

• I used AI to proofread the text of the statement.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

[garydgregory]

Hi @ppkarwasz
Lots of errors here... ;-)

[garydgregory]

Hi @ppkarwasz
Future me wants to update our commons-build-plugin to generate the security page (or a separate CVE page) using this XML file as its source. But, it's going to look pretty lame if we mix in whatever format this is, a flavor of Markdown? GitHub Markdown? It seems to me it would be more useful if this text was XML that we can transform like we transform our existing XML source for site pages. Or does the C-DX XML schema prescribe that Markdown be used inside XML here?
TY!

[ppkarwasz]

The CycloneDX XML Schema defines this element as xsd:string, which means it cannot contain nested XML elements and has no prescribed internal structure. Because of that, I chose Markdown, partly inspired by the fact that some CVE records (e.g., CVE-2025-24813) already seem to use Markdown formatting. When those CVEs are imported into GitHub (see GHSA-83qj-6fr2-vhqg), the descriptions look much cleaner and more readable.

I’m happy to help with publishing VEX documents on the Commons website, though my first priority is doing this for Apache Solr (see my proposal on “smuggling” Markdown into VEX-es). One complication is that different ASF projects use very different site generators:

• Commons → Maven Site plugin (Java)
• Log4j → Jekyll (Ruby)
• Solr → Pelican (Python)

That makes cross-project tooling tricky.

My plan is to start with Pelican plugins (Python) that can:

1. Generate VEX files (initially CycloneDX only).
2. Generate a CVE page—either directly in HTML or via a Markdown intermediate step.

Initially, it will likely be easier to use Pelican to generate a security page and style it to match the project’s existing site theme. Deeper integration with the Maven Site plugin could come in a later phase.

[ecki]

I don’t want you guys from maintaining VEX data but isn’t it easier to just fix the issue than documenting it? :)

[ecki]

(Ah ignore my comment I thought it was a downstream project with a missing c-c update)

[ppkarwasz]

In a sense, this is a downstream case: the actual vulnerable component for CVE-2025-48924 is Commons Lang, not Commons Configuration.

However, Commons Configuration is a library, so for each vulnerability in its dependencies we have a few options:

1. Do nothing: perfectly reasonable for me, since Commons Configuration doesn’t ship Commons Lang itself. Downstream applications can upgrade Commons Lang independently.
2. Release a new version with an updated POM (plus any unreleased changes) so that builds no longer select the vulnerable Commons Lang by default. Some users will appreciate this; others will (silently) complain about the resulting flood of Dependabot PRs.
3. Document exploitability (or non-exploitability): in my opinion the least costly option overall, at least for downstream consumers, not for Apache Commons. For example, I’ve already used this VEX statement to justify the non-exploitability of CVE-2025-48924 in Apache Solr ([SOLR-17822] Document non-exploitability of CVE-2025-48924 solr-site#152). Solr will upgrade Commons Lang eventually, but there’s no need to rush a release just for this.

[ecki]

In my mind a VEX file is much more costly than just fixing the dependency. It will generate lots of manual review work. I would limit them to cases where there is no fix easily available or for false positive cases where no fix is expected. We could provide a vex file analysing outdated dependencies (if somebody has done the work and contributes it), but then we maybe should have a separation in known vulnerabilities as of default configuration and known vulnerabilities in non-default dependency configurations.

In this case the prosa text is very extensive and you would need to pay very close attention that it does not apply to the default versions. Maybe one option would be to change the CPE to actual the affected commons-lang3 version instead?

Or at least start with the text "Commons-configuration is not vulnerable to CVE.. because it depends on the fixed version of commons-lang3. But if ..."

[garydgregory]

Hi @ppkarwasz

The CycloneDX XML Schema defines this element as xsd:string, which means it cannot contain nested XML elements and has no prescribed internal structure.

That should be a bug or feature request for the schema IMO (xsd:any is what you want I think). That leaves us with the CDATA option for now if we really wanted XML. CDATA or a whitespace preseving trick is what you want anyway, otherwise, an XML processor will likely collapse all the whitespace IIRC.

Commons → Maven Site plugin (Java)

We're not going to change that, it works well, and we also have a bunch of XML pages generated by the commons-build-plugin which are then picked up by the site plugin and turned into XHTML/HTML.

What will help a bit is that I've slowly been moving some documentation into the Javadoc overview and package pages. This reduces the amount of work the site plugin does, keeps the docs closer to the "truth" (the source), and gives us per-version documentation. Until we do our own, users can go to javadoc.io and see per-version Javadocs, which is really nice to have.

My plan is to start with Pelican plugins (Python) ...

Just not in Commons, we already have a website publishing stack, see above. All we need is to add another page for security and CVEs, either one or two pages, depending on what's nice/simple to do. A release manager shouldn't need to deal with yet another stack of tools to learn and maintain IMO.

Deeper integration with the Maven Site plugin could come in a later phase.

There is no "Deeper integration" needed IMO, we already have a site publishing process.

In summary, I think we can merge the PR and deal with the formatting of the text when we need to, IOW, when we generate the security page(s) from the commons-build-plugin.

HTH

[garydgregory]

In my mind a VEX file is much more costly than just fixing the dependency. It will generate lots of manual review work. I would limit them to cases where there is no fix easily available or for false positive cases where no fix is expected. We could provide a vex file analysing outdated dependencies (if somebody has done the work and contributes it), but then we maybe should have a separation in known vulnerabilities as of default configuration and known vulnerabilities in non-default dependency configurations.

In this case the prosa text is very extensive and you would need to pay very close attention that it does not apply to the default versions. Maybe one option would be to change the CPE to actual the affected commons-lang3 version instead?

Or at least start with the text "Commons-configuration is not vulnerable to CVE.. because it depends on the fixed version of commons-lang3. But if ..."

I share some of @ecki 's concerns.

From what I've seen from VEX/VDR so far in general is that it deals with the same issues as code: It's a complex document format with complex content.

Therefore, these files (regardless of whether they are encoded in XML or JSON), like code, will contain bugs.

Then, the tooling will also have growing pains and bugs of course.

I like the simplicity of releasing even if it's only to update dependencies: it's simpler to deal with across the tool chains.

That said, it's worth investigating and experimenting, so thank you to @ppkarwasz !

[ppkarwasz]

In my mind a VEX file is much more costly than just fixing the dependency. It will generate lots of manual review work.

That’s actually the bet the Alpha-Omega fund is taking on. They’re funding OpenRefactory to develop OSS tooling and funding me to integrate it into Apache Solr. The goal is to make producing VEX statements far cheaper and faster than cutting new releases. The tooling isn’t ready yet, so I’m exploring the real costs of manual VEX creation in the projects I work on. I wrote a Log4j blog post with more context.

Like many engineering trade-offs, this is a bet, similar to “is it cheaper to reconfigure the app correctly or just restart it?” I’ve seen those bets go both ways. 😜

In this case the prosa text is very extensive and you would need to pay very close attention that it does not apply to the default versions. Maybe one option would be to change the CPE to actual the affected commons-lang3 version instead?

Thanks for pointing that out. I tried to group the exploitability conditions at the start for clarity, but I also added extra explanation so that the statement is verifiable. I’d be happy to refine this if you have ideas on how to make it both concise and review-friendly.

Or at least start with the text "Commons-configuration is not vulnerable to CVE.. because it depends on the fixed version of commons-lang3. But if ..."

The current Commons Configuration release (2.12.0) actually does depend on a vulnerable commons-lang3.

However, your remark touches on a question I’ve been trying to resolve: should VEX files only be processed if a vulnerability is detected in the SBOM (making this kind of preemptive statement unnecessary), or should they be usable as standalone vulnerability guidance?

Right now, I’m assuming we do need such statements even if we upgrade the dependency, because downstream consumers might have commons-lang3 pinned via their own build or via their framework. Different frameworks take different approaches here: some will bump their managed dependencies to 3.18.0 quickly, while others (like Spring Boot, see spring-projects/spring-boot#46437) prioritize dependency stability over immediate vulnerability fixes.