Bump ch.qos.logback:logback-core from 1.3.15 to 1.5.19 in /log4j-parent

[dependabot]

Bumps ch.qos.logback:logback-core from 1.3.15 to 1.5.19.

Release notes

Sourced from ch.qos.logback:logback-core's releases.

Logback 1.5.19

2025-09-30 Release of logback version 1.5.19

• Disallow "new" operator in the condition attribute of <if> elements. This fixes an ACE vulnerability recorded as CVE-2025-11226.

• At initialization time, slightly better reporting about watched configuration files.

• Softer message regarding usage of ConsoleAppender and its potential impact on performance.

• In ViewStatusMessagesServlet, restrict processing of "Clear" button to POST method. This change was proposed by Ralf Wiebicke who also provided the relevant PR.

• A bit-wise identical binary of this version can be reproduced by building from source code at commit e572d4f87f06674788eb3ca7148e8d1dffc615fa associated with the tag v_1.5.19. Release built using Java "21" 2023-10-17 LTS build 21.0.1.+12-LTS-29 under Linux Debian 11.6.

Logback 1.5.18

2025-03-18 Release of logback version 1.5.18

• Added support for XZ compression for archived log files. Note that XZ compression requires Tukaani project's XZ library for Java. In case XZ compression is requested but the XZ library is missing, then logback will substitute GZ compression as a fallback. This feature was requested in issues/755.

• Removed references to java.security.AccessController class. This class has been deprecated for some time and is slated for removal in future JDK versions.

• A bit-wise identical binary of this version can be reproduced by building from source code at commit b2a02f065379a9b1ba5ff837fc08913b744774bc associated with the tag v_1.5.18. Release built using Java "21" 2023-10-17 LTS build 21.0.1.+12-LTS-29 under Linux Debian 11.6.

Logback 1.5.17

2025-02-25 Release of logback version 1.5.17

• Fixed Jansi 2.4.0 color-coded output not working on Windows CMD.exe console when the default terminal application is set to "Windows Console Host". This problem was reported in issues/753 by Michael Lyubkin.

• Fixed race condition occurring in case MDC class is initialized while org.slf4j.LoggerFactory is initializing logback-classic's LoggerContext. When this race conditions occurs, the MDCAdapter instance used by MDC does not match the instance used by logback-classic. This issue was reported in SLF4J issues/450. While logback-classic version 1.5.17 remains compatible with SLF4J versions in the 2.0.x series, fixing this particular MDC issue requires SLF4J version 2.0.17.

• A bit-wise identical binary of this version can be reproduced by building from source code at commit 10358724ed723b3745c010aa40cb02a2dfed4593 associated with the tag v_1.5.17. Release built using Java "21" 2023-10-17 LTS build 21.0.1.+12-LTS-29 under Linux Debian 11.6.

Logback 1.5.16

2025-01-05 Release of logback version 1.5.16

• In order to ease the migration of configuration files depending on JaninoEventEvaluator, logback-classic will emit a warning about the removal of JaninoEventEvaluator in version 1.5.13 and suggest an online migration tool.

• A bit-wise identical binary of this version can be reproduced by building from source code at commit 74c9ebd0e784d9e9ffc6c627cf5016d0157956b2 associated with the tag v_1.5.16. Release built using Java "21" 2023-10-17 LTS build 21.0.1.+12-LTS-29 under Linux Debian 11.6.

Commits

• e572d4f skip deployment of blackbox and example modules, published as version 1.5.9
• 4adae8b add plugin for Maven Central deployment
• ee70cf4 prepare release 1.5.19
• 20802cf mindor javadoc changes
• 8116069 comment out code in COWArrayListConcurrencyTest to make IDE happy
• 7f65340 minor changes
• 8d2262d soften warning on using ConsoleAppender
• c76fed3 ViewStatusMessagesServlet requires method POST for button 'Clear' (#971)
• 61f6a25 disallow new in if condition attribute in config files
• a07cfd5 logback-core: fix spelling errors (#956)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[vy]

Logback started requiring Java 11 with version 1.4.0 – long live semver!

I'll issue a PR to amend our dependabot rules.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

[vy]

It is getting even more interesting:

logging-log4j2/.github/dependabot.yaml

Lines 114 to 116 in 13e37d8

	# Keep Logback version 1.2.x
	- dependency-name: "ch.qos.logback:*"
	versions: [ "[1.3,)" ]

[ppkarwasz]

Dependabot opened this PR to address CVE-2025-11226 by upgrading a test dependency on Logback. However, after reviewing the details, I don’t believe this CVE is relevant to our test suite.

First, Logback does not publish an official security model. The only available third-party threat model, produced by 7ASecurity, does not classify configuration files as untrusted inputs. In absence of guidance from the Logback maintainer, it is reasonable to assume a security model consistent with the one used by the Apache Logging Services project:

• Java system properties and environment variables are trusted.
• Configuration files are trusted and it is the responsibility of the user to secure them.

Based on this model:

• The CVE claims a configuration injection risk via crafted Logback XML, but configuration files are trusted by design and must not be modifiable by attackers. Treating them as untrusted would contradict common logging system assumptions (including our own model).
• Therefore, in my opinion this CVE does not describe a genuine vulnerability and was disclosed based on an incorrect threat model.

Even if we were to consider it a valid issue, it is not exploitable in our test environment:

• Test runs execute in a controlled CI environment (GitHub-hosted or maintainer-owned hardware) where JVM properties and environment variables are well defined and sanitized.
• The Logback test configuration file is stored in this repository and writable only by trusted committers.
• There is no attack path where an untrusted party could modify test configuration.

Additionally, for completeness:

• Remote Code Execution via pull requests is not a meaningful threat in our environment. PRs already execute untrusted code by design in isolated runners. They cannot compromise CI infrastructure or access secrets. The worst-case impact is resource abuse (e.g., cryptomining), which is mitigated by rate limits and PR review requirements.

For these reasons, I do not support merging this dependency change purely for CVE-2025-11226. It introduces noise without improving security.