Yishai Greenberg created FLINK-40246:
----------------------------------------
Summary: flink-kubernetes-operator bundles vulnerable logback-core
1.2.13 (CVE-2024-12798, CVE-2025-11226, CVE-2026-1225)
Key: FLINK-40246
URL: https://issues.apache.org/jira/browse/FLINK-40246
Project: Flink
Issue Type: Bug
Components: Kubernetes Operator
Affects Versions: kubernetes-operator-1.15.0
Environment: Summary
-------
Since kubernetes-operator-1.15.0, the operator ships Logback as an optional
logging backend (added in FLINK-39501). The bundled version is
ch.qos.logback:logback-core:1.2.13 (the terminal release of the EOL 1.2.x line).
Downstream container/dependency scanners flag three known CVEs against this jar,
and there is currently no maintained-line version available to the operator
because 1.2.x no longer receives security fixes.
Affected CVEs
-------------
- CVE-2024-12798 (GHSA-pr98-23f8-jwxv), Medium
Vulnerable: < 1.3.15 (and 1.4.0-1.5.13) First fixed: 1.3.15 / 1.5.13
- CVE-2025-11226 (GHSA-25qh-j22f-pwp8), Medium
Vulnerable: < 1.3.16 (and 1.4.0-1.5.19) First fixed: 1.3.16 / 1.5.19
- CVE-2026-1225 (GHSA-qqpg-mvqg-649v), Low
Vulnerable: < 1.5.25 First fixed: 1.5.25
Bundled: logback-core 1.2.13. To clear all three, logback-core 1.5.25+ is
required (CVE-2026-1225 has no 1.3.x backport). Clearing only the two Medium
CVEs would need 1.3.16+.
Why it is not a trivial version bump
------------------------------------
Every fixed Logback line (1.3.x, 1.4.x, 1.5.x) targets SLF4J 2.0.x, whereas the
operator currently pins slf4j-api 1.7.36 and binds Log4j2 via log4j-slf4j-impl
(the SLF4J 1.7 binding). So bumping Logback to any non-vulnerable version also
requires migrating the operator's logging stack to SLF4J 2.0.x (e.g.
log4j-slf4j-impl -> log4j-slf4j2-impl, slf4j-api -> 2.0.x). That coupling is
presumably why logback.version is still 1.2.13 on main (1.16-SNAPSHOT).
Proposed fix (either option)
----------------------------
1. Bump + migrate: raise the bundled logback-core/logback-classic to 1.5.25+ and
move the operator modules' logging to SLF4J 2.0.x (log4j-slf4j2-impl +
slf4j-api 2.0.x).
2. Make Logback optional/excludable: if the SLF4J 2.x migration is out of scope
short-term, keep Log4j2 as the default (it already is) and allow
building/shipping the operator distribution and image without the Logback
jars, so security-sensitive deployments can drop the vulnerable artifacts.
Logback was introduced only as an alternative backend in FLINK-39501, so it
should be possible to gate it.
Verification
------------
After the change, the operator image / distribution should contain no
ch.qos.logback:logback-core < 1.5.25 (confirm via the module NOTICE files and
mvn dependency:tree), and the three CVEs above should no longer be reported by
scanners.
References
---------
- FLINK-39501 Logback Support in Flink Kubernetes Operator (introduced
logback, 1.15.0)
- FLINK-40104 Logging framework JARs placement (1.16.0)
- FLINK-18829 Remove logback-related codepaths (Flink core)
- https://logback.qos.ch/news.html (1.3.x/1.5.x require SLF4J 2.0.x)
Reporter: Yishai Greenberg
h2. Summary
Since \{{kubernetes-operator-1.15.0}}, the operator ships Logback as an optional
logging backend (added in FLINK-39501). The bundled version is
{\{ch.qos.logback:logback-core:1.2.13}} (the terminal release of the EOL 1.2.x
line). Downstream container/dependency scanners flag three known CVEs against
this jar, and there is currently no maintained-line version available to the
operator because 1.2.x no longer receives security fixes.
h2. Affected CVEs
||CVE||GHSA||Severity||Vulnerable range||First fixed||
|CVE-2024-12798|GHSA-pr98-23f8-jwxv|Medium|< 1.3.15 (and 1.4.0–1.5.13)|1.3.15
/ 1.5.13|
|CVE-2025-11226|GHSA-25qh-j22f-pwp8|Medium|< 1.3.16 (and 1.4.0–1.5.19)|1.3.16
/ 1.5.19|
|CVE-2026-1225 |GHSA-qqpg-mvqg-649v|Low|< 1.5.25|1.5.25|
Bundled: \{{logback-core 1.2.13}}. To clear *all three*, \{{logback-core
1.5.25+}}
is required (CVE-2026-1225 has no 1.3.x backport). Clearing only the two Medium
CVEs would need \{{1.3.16+}}.
h2. Why it is not a trivial version bump
Every fixed Logback line (1.3.x, 1.4.x, 1.5.x) targets *SLF4J 2.0.x*, whereas
the
operator currently pins \{{slf4j-api 1.7.36}} and binds Log4j2 via
{\{log4j-slf4j-impl}} (the SLF4J 1.7 binding). So bumping Logback to any
non-vulnerable version also requires migrating the operator's logging stack to
SLF4J 2.0.x (e.g. \{{log4j-slf4j-impl}} -> \{{log4j-slf4j2-impl}},
\{{slf4j-api}}
-> 2.0.x). That coupling is presumably why \{{logback.version}} is still
\{{1.2.13}}
on \{{main}} (1.16-SNAPSHOT).
h2. Proposed fix (either option)
# *Bump + migrate:* raise the bundled \{{logback-core}}/\{{logback-classic}} to
{\{1.5.25}}+ and move the operator modules' logging to SLF4J 2.0.x
(\{{log4j-slf4j2-impl}} + \{{slf4j-api 2.0.x}}).
# *Make Logback optional/excludable:* if the SLF4J 2.x migration is out of scope
short-term, keep Log4j2 as the default (it already is) and allow
building/shipping
the operator distribution and image *without* the Logback jars, so
security-sensitive deployments can drop the vulnerable artifacts. Logback was
introduced only as an alternative backend in FLINK-39501, so it should be
possible to gate it.
h2. Verification
After the change, the operator image / distribution should contain no
{\{ch.qos.logback:logback-core}} < 1.5.25 (confirm via the module \{{NOTICE}}
files
and \{{mvn dependency:tree}}), and the three CVEs above should no longer be
reported by scanners.
h2. References
* FLINK-39501 — Logback Support in Flink Kubernetes Operator (introduced
logback, 1.15.0)
* FLINK-40104 — Logging framework JARs placement (1.16.0)
* FLINK-18829 — Remove logback-related codepaths (Flink core)
* https://logback.qos.ch/news.html (1.3.x/1.5.x require SLF4J 2.0.x)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
