ppkarwasz commented on PR #3962:
URL: https://github.com/apache/logging-log4j2/pull/3962#issuecomment-3431696669

   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](https://ostif.org/logback-audit-complete/), 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.
   


-- 
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