OpenSSL Patches High-Severity Stack Overflow (CVE-2025-15467)

[nicolaasjan]

Content source

https://securityonline.info/pre-auth-rce-risk-openssl-patches-high-severity-stack-overflow-cve-2025-15467/

The maintainers of OpenSSL, the cryptographic library that underpins a vast portion of the secure web, have released a sweeping security update to address a dozen vulnerabilities ranging from memory corruption to logic errors. The headline flaw in this batch is a High-severity stack buffer overflow (CVE-2025-15467) that could potentially allow remote attackers to execute code on vulnerable systems.
The advisory, released to the public, details a mix of issues affecting various components, including PKCS#12 handling, CMS parsing, and TLS 1.3 certificate compression.

• OpenSSL 3.6 users should upgrade to 3.6.1.
• OpenSSL 3.5 users should upgrade to 3.5.5.
• OpenSSL 3.4 users should upgrade to 3.4.4.
• OpenSSL 3.3 users should upgrade to 3.3.6.
• OpenSSL 3.0 users should upgrade to 3.0.19.

OpenSSL Release Announcement for 3.6.1, 3.5.5, 3.4.4, 3.3.6, 3.0.19, 1.1.1ze and 1.0.2zn | OpenSSL Library

 

[Bot]

OpenSSL Release Announcement for 3.6.1, 3.5.5, 3.4.4, 3.3.6, 3.0.19, 1.1.1ze and 1.0.2zn | OpenSSL Library

The official OpenSSL release announcement dated 27 January 2026 confirms the new patch releases (3.6.1 / 3.5.5 / 3.4.4 / 3.3.6 / 3.0.19, plus 1.1.1ze and 1.0.2zn for premium support customers).

The “headline” issue in that batch is indeed CVE-2025-15467, rated High: a stack buffer overflow in CMS AuthEnvelopedData parsing which can cause a crash (DoS) and could potentially be exploitable for code execution depending on platform/toolchain mitigations.

Important context (to avoid over-alarmist takes)

• CVE-2025-15467 is not a “generic TLS web server gets RCE by default” type of bug. It affects applications/services that parse untrusted CMS/PKCS#7 AuthEnvelopedData content (for example, some S/MIME / CMS processing workflows) and encounter malicious AEAD parameters.
• OpenSSL’s own advisory notes the overflow happens before authentication/tag verification, which is part of why it is treated seriously (High).
• OpenSSL also documents that its FIPS modules are not affected by this CMS issue because CMS is outside the FIPS module boundary.

The “TLS 1.3 certificate compression” point
There is a TLS 1.3 CompressedCertificate-related issue in this release set: CVE-2025-66199, but OpenSSL rates it Low severity (excessive memory allocation). OpenSSL also lists a mitigation knob (disabling receiving certificate compression via SSL_OP_NO_RX_CERTIFICATE_COMPRESSION) if someone needs a temporary workaround while waiting for a vendor patch.

Practical advice for users/admins

• If you consume OpenSSL via your OS/vendor packages (most Linux/BSD users): update through the normal package mechanism. Don’t “mix” upstream OpenSSL builds into a distro-managed system unless you fully control the dependency chain.
• If you are on Windows/macOS and asking “am I impacted?”: many products bundle their own OpenSSL (or don’t use it at all). The safest action is updating the affected application/service rather than trying to update a system-wide OpenSSL.
• If you build software or appliances that embed OpenSSL: upgrade to the fixed branch release for your line (3.6.1 / 3.5.5 / 3.4.4 / 3.3.6 / 3.0.19) and rebuild/redeploy.

Bottom line: the OpenSSL upstream info supports the existence and High severity of CVE-2025-15467, but it’s best described as a serious CMS parsing vulnerability that matters most where untrusted CMS/PKCS#7 content is processed; patching should be done via your OS/app vendor update path whenever possible.

Sources

• 
  [] OpenSSL Release Announcement for 3.6.1, 3.5.5, 3.4.4, 3.3.6, 3.0.19, 1.1.1ze and 1.0.2zn | OpenSSL Library
  [] Vulnerabilities | OpenSSL Library

 

[nicolaasjan]

If you build software or appliances that embed OpenSSL: upgrade to the fixed branch release for your line (3.6.1 / 3.5.5 / 3.4.4 / 3.3.6 / 3.0.19) and rebuild/redeploy.

Already done that for yt-dlp.

./yt-dlp_linux -v
[debug] Command-line config: ['-v']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version local@2026.01.28 [5bf91072b] (linux_exe)
[debug] Python 3.14.2 (CPython x86_64 64bit) - Linux-5.15.0-164-generic-x86_64-with-glibc2.35 (OpenSSL 3.6.1 27 Jan 2026, glibc 2.35)
[debug] exe versions: ffmpeg N-121974-g041d4f010e-Nico-20251204 (fdk,setts), ffprobe N-121974-g041d4f010e-Nico-20251204, rtmpdump 2.4
[debug] Optional libraries: Cryptodome-3.23.0, brotli-1.2.0, certifi-2026.01.04, curl_cffi-0.13.0, mutagen-1.47.0, requests-2.32.5, secretstorage-3.5.0, sqlite3-3.37.2, urllib3-2.6.3, websockets-16.0, yt_dlp_ejs-0.3.2
[debug] JS runtimes: deno-2.6.6
[debug] Proxy map: {}
[debug] Request Handlers: urllib, requests, websockets, curl_cffi
[debug] Plugin directories: /home/nico/.config/yt-dlp/plugins/bgutil-ytdlp-pot-provider/yt_dlp_plugins
[debug] Loaded 1856 extractors

 

[Bot]

Already done that for yt-dlp.

./yt-dlp_linux -v
[debug] Command-line config: ['-v']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version local@2026.01.28 [5bf91072b] (linux_exe)
[debug] Python 3.14.2 (CPython x86_64 64bit) - Linux-5.15.0-164-generic-x86_64-with-glibc2.35 (OpenSSL 3.6.1 27 Jan 2026, glibc 2.35)
[debug] exe versions: ffmpeg N-121974-g041d4f010e-Nico-20251204 (fdk,setts), ffprobe N-121974-g041d4f010e-Nico-20251204, rtmpdump 2.4
[debug] Optional libraries: Cryptodome-3.23.0, brotli-1.2.0, certifi-2026.01.04, curl_cffi-0.13.0, mutagen-1.47.0, requests-2.32.5, secretstorage-3.5.0, sqlite3-3.37.2, urllib3-2.6.3, websockets-16.0, yt_dlp_ejs-0.3.2
[debug] JS runtimes: deno-2.6.6
[debug] Proxy map: {}
[debug] Request Handlers: urllib, requests, websockets, curl_cffi
[debug] Plugin directories: /home/nico/.config/yt-dlp/plugins/bgutil-ytdlp-pot-provider/yt_dlp_plugins
[debug] Loaded 1856 extractors

That output is exactly what you want to see: your yt-dlp self-contained build is running on a Python runtime that reports it was built/linked against OpenSSL 3.6.1 (27 Jan 2026), so at least the Python TLS stack in that binary is on the patched OpenSSL line.

A couple of practical nuances (so you don’t get a false sense of “everything is patched”)

• yt-dlp doesn’t only do TLS one way. Your log shows multiple request handlers (urllib/requests/websockets/curl_cffi). Depending on your options and runtime behavior, some traffic can go via libcurl (curl_cffi) rather than Python’s ssl module.
• Different components can have different crypto/TLS backends. For example, libcurl might be built against OpenSSL, GnuTLS, or something else; FFmpeg can also be built with different TLS backends. Your OpenSSL 3.6.1 line confirms what Python is using, not necessarily every dependency in your environment.
• For the specific OpenSSL CMS overflow (CVE-2025-15467): even before patching, yt-dlp’s typical workload (HTTPS + parsing media manifests) is not the classic “untrusted CMS/PKCS#7 AuthEnvelopedData parsing” scenario. Updating is still the right call, but the practical exposure for yt-dlp itself is usually limited.

Low-risk verification steps (optional, but useful)

• Check what the yt-dlp executable links to at runtime: run ldd on ./yt-dlp_linux and confirm whether it uses system libssl/libcrypto or bundled ones (and from where).
• If you rely on curl_cffi, confirm your system curl backend and its TLS library (curl -V will typically show the TLS backend).
• Still update system packages normally (OpenSSL, curl, FFmpeg) so other software on the machine isn’t left behind even if yt-dlp is already patched.

Bottom line: your yt-dlp build is already on OpenSSL 3.6.1 for Python’s TLS, which is the important part for the common yt-dlp use case; the only remaining “gotchas” are other optional backends (curl/ffmpeg) that may have their own separate TLS stacks.

 

[nicolaasjan]

• Check what the yt-dlp executable links to at runtime: run ldd on ./yt-dlp_linux and confirm whether it uses system libssl/libcrypto or bundled ones (and from where).

yt-dlp uses the bundled ones.

• If you rely on curl_cffi, confirm your system curl backend and its TLS library (curl -V will typically show the TLS backend).

curl -V
curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.19
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd

System OpenSSL was updated this morning on Linux Mint.

libssl-dev (3.0.2-0ubuntu1.20) to 3.0.2-0ubuntu1.21
libssl3 (3.0.2-0ubuntu1.20) to 3.0.2-0ubuntu1.21
openssl (3.0.2-0ubuntu1.20) to 3.0.2-0ubuntu1.21

Now, the only thing left to do, is build my custom FFmpeg again (though it's usually only used for merging purposes, not downloading).

 

[Bot]

yt-dlp uses the bundled ones.

Good — if yt-dlp is using bundled libssl/libcrypto and your debug output shows “OpenSSL 3.6.1 27 Jan 2026”, then that specific yt-dlp binary is already on the fixed OpenSSL branch for the vulnerabilities addressed in that release set.

What this does and does not mean

• Does mean: Updating your OS OpenSSL won’t change (or “unpatch”) this yt-dlp executable; its OpenSSL is carried with it.
• Does not mean: Your whole system is patched. Other apps/services that link to system OpenSSL still need the normal distro updates.

Practical next step
Keep the old yt-dlp binary replaced/removed (so you don’t accidentally run an older OpenSSL build later) and continue patching OpenSSL via your distro as usual.