I'm clearly old and stupid. I can't figure out how to submit an issue for #GnuTLS on their gitlab anymore. (I did in the past.)

So here it comes instead: gnutls_certificate_verify_peers2() does not seem to verify ExtendedKeyUsage but gnutls_certificate_verify_peers() does.

Neither case is documented clearly. This has already lead to people submitting vuln reports to gnutls-using apps for this omission.

🚨 CVE-2026-45185 (Dead.Letter)

Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code.

ℹ️ Additional info on ZEN SecDB https://secdb.nttzen.cloud/cve/detail/CVE-2026-45185

#nttdata #zen #secdb #infosec
#deadletter #cve202645185 #exim #gnutls

Exim BDAT Flaw Exposes GnuTLS Builds to Code Execution Risk

A newly discovered vulnerability, dubbed Dead.Letter, threatens Exim builds that use GnuTLS, allowing attackers to exploit a use-after-free flaw in BDAT handling and potentially execute malicious code. This critical flaw can be triggered when a specific sequence of BDAT and TLS commands is sent, leading to heap corruption and a heightened…

https://osintsights.com/exim-bdat-flaw-exposes-gnutls-builds-to-code-execution-risk?utm_source=mastodon&utm_medium=social

#EximVulnerability #Gnutls #Cve202645185 #Deadletter #Useafterfree

RE: https://mamot.fr/@smortex/116219434637755665

Request for help

I am stuck trying to identify the root cause of an issue with a program using #GnuTLS to communicate with a #Java service. It stopped working last summer when updating from OpenJDK 17.0.16+8-1 to 17.0.17~5ea-1 (Debian 12 packages). It also fail with all newer versions of OpenJDK.

I am not sure if this is caused by a misuse of the GnuTLS API, a regression in OpenJDK or an issue with GnuTLS itself.

Boosts appreciated! Thanks!

#fedihelp

1/6

I'm investigating a regression that appeared after upgrading #OpenJDK in a setup where #syslog_ng communicates with a #Riemann server (a Java application).

My investigation led me to a C library (riemann-c-client, used by syslog-ng) that uses #GnuTLS to establish a mutually authenticated TLS connection to the Java service. The library provides a CLI utility that allows me to reproduce the problem, which suggests that the issue lies in this library rather than in syslog-ng itself.

If you're using #GnuTLS please note that GnuTLS defaults to weak security profile:

"The message authenticity security level is of 64 bits or more, and the certificate verification profile is set to GNUTLS_PROFILE_LOW (80-bits)."

This means for example that Diffie-Hellman group size of 1024-bits is allowed. This was deemed insufficient already 10 years ago. See https://weakdh.org/

This issue will be remedied in future GnuTLS release. Meanwhile the fix is to inject %PROFILE_MEDIUM as part of the priority string, for example "NORMAL:foo" becomes "NORMAL:%PROFILE_MEDIUM:foo". See https://gnutls.org/manual/html_node/Priority-Strings.html for details.

#insecuredefaults #cybersecurity #infosec #development

It's not just @bagder who gets incorrect bug reports generated by #AI for #curl. This time, it's #GnuTLS at https://gitlab.com/gnutls/gnutls/-/issues/1711.

What a waste of time :/