Skip to content

Conversation

@henricook
Copy link

Summary

  • Migrate commons-email2-jakarta from com.sun.mail:jakarta.mail:2.0.2 to org.eclipse.angus:jakarta.mail:2.0.4 - the patched successor of the EOL com.sun.mail implementation
  • Bump commons-email2-javax from com.sun.mail:jakarta.mail:1.6.7 to 1.6.8

Both versions prior to this change are vulnerable to CVE-2025-7962, an SMTP injection flaw allowing attackers to inject arbitrary SMTP commands via \r\n characters in UTF-8 encoded input.

Context

The com.sun.mail:jakarta.mail implementation has been superseded by Eclipse Angus, which is described as the "direct successor of JavaMail/JakartaMail". The CVE fix was only released under the Angus coordinates (org.eclipse.angus:jakarta.mail:2.0.4), while the old com.sun.mail 2.x line remains unpatched.

For the commons-email2-javax module, a backported fix is available at com.sun.mail:jakarta.mail:1.6.8.

References

@henricook
Copy link
Author

It'd be amazing if anyone had information to help me figure out how to backport this to the 1.6.x series - and maybe get it released as a patch?

@garydgregory
Copy link
Member

Hello @henricook

For 1.x, keep in mind that we can't break binary compatibility.

@henricook
Copy link
Author

Hello @henricook

For 1.x, keep in mind that we can't break binary compatibility.

Thanks Gary, would I raise a PR to the 1.x branch to propose a patch to it if binary compatibility was ok?

@henricook
Copy link
Author

I'm reasonably confident that 1.6.7 -> 1.6.8 doesn't include any binary compatibility breaking changes.

The internals of SMTPTransport.java were changed, and the only other non test changes were:

  • Internal: Fix to NTLM auth
  • Internal: Logging improvements
  • Version bumps in POMs

@garydgregory
Copy link
Member

Hello @henricook
For 1.x, keep in mind that we can't break binary compatibility.

Thanks Gary, would I raise a PR to the 1.x branch to propose a patch to it if binary compatibility was ok?

I'd like to see a PR before I make any promises 😉

@garydgregory
Copy link
Member

Hello @henricook
Odd, the build here fails on Java >= 25 due to test failures:

Error:  Failures: 
Error:    MultiPartEmailTest.testAttachFile:138 Expected org.apache.commons.mail2.core.EmailException to be thrown, but nothing was thrown.
Error:    MultiPartEmailTest.testAttachPath:181 Expected org.apache.commons.mail2.core.EmailException to be thrown, but nothing was thrown.
[INFO] 
Error:  Tests run: 200, Failures: 2, Errors: 0, Skipped: 3

<dependency>
<groupId>org.eclipse.angus</groupId>
<artifactId>jakarta.mail</artifactId>
<version>2.0.4</version>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because I must be blind 😢 - on the way

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed now @garydgregory

@sebbASF
Copy link
Contributor

sebbASF commented Feb 11, 2026

The tests that fail in Java 25 and 26 have code like the following:

// test bad file
attachment.setPath("");

Maybe an empty Path is now allowed?

Migrate commons-email2-jakarta from com.sun.mail:jakarta.mail:2.0.2
to org.eclipse.angus:jakarta.mail:2.0.5 - the patched successor of
the EOL com.sun.mail implementation.

Bump commons-email2-javax from com.sun.mail:jakarta.mail:1.6.7 to
1.6.8.

Both prior versions are vulnerable to CVE-2025-7962, an SMTP
injection flaw allowing attackers to inject arbitrary SMTP commands
via \r\n characters in UTF-8 encoded input.
@henricook henricook force-pushed the fix/CVE-2025-7962-jakarta-mail-smtp-injection branch from 4d2fe24 to 5922190 Compare February 11, 2026 15:43
@henricook
Copy link
Author

henricook commented Feb 11, 2026

The tests that fail in Java 25 and 26 have code like the following:

// test bad file
attachment.setPath("");

Maybe an empty Path is now allowed?

I think that File("") has different semantics in Java 25. Rather than being false it is the primary working directory. Here's an example. Which means this test is probably failing on master? Is there a scheduled run of tests on master or similar I could check? Or I could open a new PR with no changes.

# Java 21
echo 'System.out.println("Java " + System.getProperty("java.version") + ": new File(\"\").exists() = " + new java.io.File("").exists());' | docker run --rm -i eclipse-temurin:21-jdk jshell -s -                                          
   
# Java 25
echo 'System.out.println("Java " + System.getProperty("java.version") + ": new File(\"\").exists() = " + new java.io.File("").exists());' | docker run --rm -i eclipse-temurin:25-jdk jshell -s -  

gives:

~ ❯ echo 'System.out.println("Java " + System.getProperty("java.version") + ": new File(\"\").exists() = " + new java.io.File("").exists());' | docker run --rm -i eclipse-temurin:21-jdk jshell -s -
Feb 11, 2026 3:58:08 PM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
Java 21.0.10: new File("").exists() = false

~ ❯ echo 'System.out.println("Java " + System.getProperty("java.version") + ": new File(\"\").exists() = " + new java.io.File("").exists());' | docker run --rm -i eclipse-temurin:25-jdk jshell -s -
Feb 11, 2026 3:58:24 PM java.util.prefs.FileSystemPreferences setupUserRoot
INFO: Created user preferences directory.
Java 25.0.2: new File("").exists() = true

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants