UBUNTU-CVE-2026-119078: Medium severity ubuntu/libcommons-codec-java vulnerability
Apache Commons Codec's Blake3 class documented the output of its doFinalize methods as depending on any previously finalized bytes, so that consecutive calls would return different output. In fact, doFinalize does not change the hash state: calling it again without supplying more input returns the same bytes. The key-derivation example in the class Javadoc, shipped since 1.16.0, derives two keys with two consecutive doFinalize calls. Code that follows it gets identical keys, so the separation between the derived keys is lost. The same applies to any application that calls doFinalize more than once on one instance and expects new output each time. This issue affects Apache Commons Codec from 1.16.0 before 1.23.0. Version 1.23.0 corrects the documentation, but the behavior of doFinalize is unchanged. Upgrading alone does not fix affected code. Users should check their applications for repeated doFinalize calls on the same Blake3 instance and derive multiple keys by requesting the combined length in one call and splitting the output, as the updated Javadoc shows.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache Commons Codecto a version that resolves this vulnerability.Fixed in 1.23.0 - Compensating control
Check applications for repeated doFinalize calls on the same Blake3 instance. To derive multiple keys, request the combined output length in one call and split the resulting bytes, as shown in the updated Javadoc; upgrading alone does not fix affected code.
Event History
Frequently Asked Questions
Who is affected by this issue?
Applications using Apache Commons Codec Blake3 from 1.16.0 before 1.23.0 are affected if they call doFinalize more than once on the same Blake3 instance and expect each call to produce new output. This includes code based on the key-derivation example previously published in the class Javadoc.
What does an attacker need to exploit this?
The provided information does not describe an external attacker interaction or a separate exploitation prerequisite. The risk arises when affected application code uses supposedly distinct outputs from consecutive doFinalize calls as different derived keys.
Does upgrading to version 1.23.0 fix existing application code?
No. Version 1.23.0 corrects the documentation, but doFinalize behavior is unchanged, so code that makes repeated calls on one instance will still receive the same bytes unless it is changed.
What should be done if affected code is found?
Request the total required output length in a single doFinalize call, then split that output into the required keys or values. Review applications for multiple doFinalize calls on the same Blake3 instance.
How can I determine whether an application is already affected?
Inspect Blake3 usage for consecutive or repeated doFinalize calls on the same instance without additional input between calls. If the application treats those outputs as separate derived keys or otherwise expects them to differ, it is affected.