fix CVE-2026-1225 to 1.3.x branch

[DmN-dev]

Hi, are there plans to 1f97ae to the 1.3.x branch ?
Thanks.

[ceki]

@DmN-dev Hey there! Just a quick heads-up: version 1.3 has now reached its end-of-life, which means we won't be releasing any more updates or patches for it. If you're still running 1.3, upgrading to version 1.5 should be easy. Have you encountered an impediment to upgrading?

[hazendaz]

@ceki If I'm not mistaken, 1.3 is javax namespace. While users can overcome, if they need the EE features, they are stuck here. With tomcat and others keeping alive javax, its going to be around for years. Its really easy to say take the 1.3.x branch, make a new branch from it such as javax-support, then merge master into it. It will fail the merge, then you just adjust the dependencies for javax namespace, any imports, and keep the rest. From then, every release is a dual release, cut latest master, then merge to javax-support, then cut that. I could so that separately if interested in what that would look like. Many repos take this approach. Its not fancy or difficult but could squash a lot of these requests outright.

[ceki]

@hazendaz Hi, thank you for your comments.

If I'm not mistaken, 1.3 is javax namespace. While users can overcome, if they need the EE features, they are stuck here. With tomcat and others keeping alive javax, its going to be around for years.

Yes, 1.3 uses the javax namespace.

Its really easy to say take the 1.3.x branch, make a new branch from it such as javax-support, then merge master into it. It will fail the merge, then you just adjust the dependencies for javax namespace, any imports, and keep the rest. From then, every release is a dual release, cut latest master, then merge to javax-support, then cut that. I could so that separately if interested in what that would look like. Many repos take this approach. Its not fancy or difficult but could squash a lot of these requests outright.

I am not sure I understand. Do you mean back-porting changes from master to 1.3?

For a few years, changes from the master branch (1.5) were back-ported into 1.3. It might sound easy but it takes time. If one is time/resource constrained, then one has to make choices.

I should add that the components that depend on javax or jakarta, SMTPAppender, are optional components.

At first glance, an efficient solution would be to extract these optional components into separate modules. However, these components are split into parts located in lobgack-core, in logback-classic and logback-access. Thus, creating separate modules for javax and for jakarta would mean six new modules, just for SMTPAppender.

[eric-systex]

@ceki

We reviewed the changes made to address CVE-2025-11226 and CVE-2026-1225 (as referenced in the commits below). However, the classes modified in these commits do not appear to exist in Logback 1.2.13.

61f6a25
1f97ae1

Could you please clarify whether any mitigation or code changes are required for CVE-2025-11226 and CVE-2026-1225 when using Logback 1.2.13?

Since upgrading Logback is not currently an option for us and we are restricted to version 1.2.13, we would appreciate any guidance on how to address this vulnerability in our environment, including any recommended backports, configuration changes, or code modifications that we can apply ourselves.

Thank you for your assistance.

[ceki]

@eric-systex As mentioned in both CVEs, in addition the modification of configuration files, a successful attack requires the presence of janino.jar on the class path.

[eric-systex]

@eric-systex As mentioned in both CVEs, in addition the modification of configuration files, a successful attack requires the presence of janino.jar on the class path.

@ceki Thank you for the clarification.