Update dependency org.apache.logging.log4j:log4j-core to v2.25.4 [SECURITY] - autoclosed#100
Conversation
Summary
Pure dependency version bump for log4j-core from 2.17.1 to 2.25.4 in pom.xml (two locations), addressing two security vulnerabilities:
The 8-version jump reflects accumulated security fixes across the stable v2 series since the project's last update (2.17.1 was released in Dec 2021; 2.25.4 is current). What reviewers should knowWhat to check:
No code changes: This is purely a dependency version update in two pom.xml sections. The large version jump is expected and safe—stable v2 releases maintain binary compatibility. Testing note: This is a
|
|
Renovate Jira issue ID: JAVASE-214 |
![sonar-review-alpha[bot]](https://avatars.githubusercontent.com/in/3025063?s=60&v=4){kind=small}
There was a problem hiding this comment.
Straightforward security upgrade. Both log4j-core declarations (annotation processor path at line 59, provided dependency at line 830) are correctly updated to 2.25.4. Version 2.25.4 covers both CVEs: CVE-2025-68161 (fixed in 2.25.3) and CVE-2026-34480 (fixed in 2.25.4). The dependency is provided scope throughout — it doesn't ship in the plugin artifact, so there is no runtime exposure in released artifacts.
| <version>2.25.4</version> | ||
| <scope>provided</scope> | ||
| </dependency> | ||
| <dependency> |
There was a problem hiding this comment.
The log4j-api artifact immediately below this point remains at 2.17.1 while log4j-core is now at 2.25.4. Neither CVE in this PR affects log4j-api, so there is no security gap. However, Apache Log4j recommends keeping the two artifacts at the same version within the same major line, and a future vulnerability scan could report a stale log4j-api independently. Bumping it to 2.25.4 here avoids that confusion.
- Mark as noise
|
renovate
Bot
changed the title
renovate
Bot
deleted the
renovate/maven-org.apache.logging.log4j-log4j-core-vulnerability
branch
This PR contains the following updates:
2.17.1→2.25.4Apache Log4j does not verify the TLS hostname in its Socket Appender
CVE-2025-68161 / GHSA-vc5p-v9hr-52mj
More information
Details
The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the verifyHostName configuration attribute or the log4j2.sslVerifyHostName system property is set to true.
This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions:
Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue.
As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates.
Severity
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Apache Log4j Core: Silent log event loss in XmlLayout due to unescaped XML 1.0 forbidden characters
CVE-2026-34480 / GHSA-3pxv-7cmr-fjr4
More information
Details
Apache Log4j Core's
XmlLayout, in versions up to and including 2.25.3, fails to sanitize characters forbidden by the XML 1.0 specification, producing invalid XML output whenever a log message or MDC value contains such characters.The impact depends on the StAX implementation in use:
Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue by sanitizing forbidden characters before XML output.
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Apache Log4j Core:
verifyHostNameattribute silently ignored in TLS configurationCVE-2026-34477 / GHSA-6hg6-v5c8-fphq
More information
Details
The fix for CVE-2025-68161 was incomplete: it addressed hostname verification only when enabled via the
log4j2.sslVerifyHostNamesystem property, but not when configured through theverifyHostNameattribute of the<Ssl>element.Although the
verifyHostNameconfiguration attribute was introduced in Log4j Core 2.12.0, it was silently ignored in all versions through 2.25.3, leaving TLS connections vulnerable to interception regardless of the configured value.A network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met:
This issue does not affect users of the HTTP appender, which uses a separate
verifyHostnameattribute that was not subject to this bug and verifies host names by default.Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.
Severity
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Configuration
📅 Schedule: (in timezone Europe/Berlin)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Never, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR was generated by Mend Renovate. View the repository job log.