renovate-bot opened a new pull request, #6691:
URL: https://github.com/apache/jmeter/pull/6691

   This PR contains the following updates:
   
   | Package | Change | [Age](https://docs.renovatebot.com/merge-confidence/) | 
[Confidence](https://docs.renovatebot.com/merge-confidence/) |
   |---|---|---|---|
   | 
[org.apache.logging.log4j:log4j-core](https://logging.apache.org/log4j/2.x/) 
([source](https://redirect.github.com/apache/logging-log4j2)) | `2.25.3` → 
`2.25.4` | 
![age](https://developer.mend.io/api/mc/badges/age/maven/org.apache.logging.log4j:log4j-core/2.25.4?slim=true)
 | 
![confidence](https://developer.mend.io/api/mc/badges/confidence/maven/org.apache.logging.log4j:log4j-core/2.25.3/2.25.4?slim=true)
 |
   
   ### GitHub Vulnerability Alerts
   
   #### [CVE-2026-34480](https://nvd.nist.gov/vuln/detail/CVE-2026-34480)
   
   Apache Log4j Core's 
[`XmlLayout`](https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout),
 in versions up to and including 2.25.3, fails to sanitize characters forbidden 
by the [XML 1.0 specification](https://www.w3.org/TR/xml/#charsets), producing 
invalid XML output whenever a log message or MDC value contains such characters.
   
   The impact depends on the StAX implementation in use:
   
     *  **JRE built-in StAX**: Forbidden characters are silently written to the 
output, producing malformed XML. Conforming parsers must reject such documents 
with a fatal error, which may cause downstream log-processing systems to drop 
the affected records.
     *  **Alternative StAX implementations** (e.g., 
[Woodstox](https://redirect.github.com/FasterXML/woodstox), a transitive 
dependency of the Jackson XML Dataformat module): An exception is thrown during 
the logging call, and the log event is never delivered to its intended 
appender, only to Log4j's internal status logger.
   
   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 Score: 6.9 / 10 (Medium)
   - Vector String: 
`CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N`
   
   #### [CVE-2026-34477](https://nvd.nist.gov/vuln/detail/CVE-2026-34477)
   
   The fix for  CVE-2025-68161 was incomplete: it addressed hostname 
verification only when enabled via the  
[`log4j2.sslVerifyHostName`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName)
 system property, but not when configured through the 
[`verifyHostName`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName)
 attribute of the `<Ssl>` element.
   
   Although the `verifyHostName` configuration 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:
   
     *  An SMTP, Socket, or Syslog appender is in use.
     *  TLS is configured via a nested <Ssl> element.
     *  The attacker can present a certificate issued by a CA trusted by the 
appender's configured trust store, or by the default Java trust store if none 
is configured.
   
   This issue does not affect users of the HTTP appender, which uses a separate 
[`verifyHostname`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName)
 attribute 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 Score: 6.3 / 10 (Medium)
   - Vector String: 
`CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N`
   
   #### [CVE-2026-34478](https://nvd.nist.gov/vuln/detail/CVE-2026-34478)
   
   Apache Log4j Core's 
[`Rfc5424Layout`](https://logging.apache.org/log4j/2.x/manual/layouts.html#RFC5424Layout),
 in versions 2.21.0 through 2.25.3, is vulnerable to log injection via CRLF 
sequences due to undocumented renames of security-relevant configuration 
attributes.
   
   Two distinct issues affect users of stream-based syslog services who 
configure Rfc5424Layout directly:
   
     *  The `newLineEscape` attribute was silently renamed, causing newline 
escaping to stop working for users of TCP framing (RFC 6587), exposing them to 
CRLF injection in log output.
     *  The `useTlsMessageFormat` attribute was silently renamed, causing users 
of TLS framing (RFC 5425) to be silently downgraded to unframed TCP (RFC 6587), 
without newline escaping.
   
   Users of the `SyslogAppender` are not affected, as its configuration 
attributes were not modified.
   
   Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects 
this issue.
   
   ##### Severity
   - CVSS Score: 6.9 / 10 (Medium)
   - Vector String: 
`CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N`
   
   ---
   
   ### Configuration
   
   📅 **Schedule**: (UTC)
   
   - Branch creation
     - ""
   - Automerge
     - At any time (no schedule defined)
   
   🚦 **Automerge**: Disabled by config. Please merge this manually once you are 
satisfied.
   
   ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry 
checkbox.
   
   🔕 **Ignore**: Close this PR and you won't be reminded about this update 
again.
   
   ---
   
    - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this 
box
   
   ---
   
   This PR was generated by [Mend Renovate](https://mend.io/renovate/). View 
the [repository job log](https://developer.mend.io/github/apache/jmeter).
   
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xMjAuMiIsInVwZGF0ZWRJblZlciI6IjQzLjEyMC4yIiwidGFyZ2V0QnJhbmNoIjoibWFzdGVyIiwibGFiZWxzIjpbImRlcGVuZGVuY2llcyJdfQ==-->
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to