TL;DR
A Debian maintainer flagged a widespread OpenSSL error handling problem across the open-source ecosystem. It surfaced when apt failed HTTPS repository access on FIPS-only systems, then traced back to a common coding shortcut. No CVE and no active exploitation are attached to this report.
Why It Matters
OpenSSL sits under much of the internet’s TLS traffic. So a shared bad habit in error handling can ripple across many tools. Julian Andres Klode, who maintains apt, warns that the pattern touches significant portions of the ecosystem. The impact ranges from benign to critical, because some discarded errors may be security-relevant. A dropped error queue entry could mask a real certificate or signature failure. That risk turns a security stop into a silent pass. In the oss-security disclosure, Klode urges developers to audit their code.
How the Bug Works
The trouble starts with OpenSSL’s per-thread error queue. During a TLS handshake, libssl tries to fetch legacy MD5 digests. Under a FIPS-only setup, that fetch fails and leaves a stale, benign error on the queue. The handshake still completes fine.
Then apt makes it worse. Its TLS read and write paths call SSL_get_error() without first clearing the queue. However, the manual requires an empty queue before each TLS operation. So when a read returns early for a harmless reason, apt sees the old error and reports a fatal failure. It then maps that to an I/O error and aborts the download. The OpenSSL issue thread documents the full trace.
Two bad patterns
Klode names two habits. First, some code calls ERR_clear_error() before every operation to bury an earlier mistake. Second, other code checks only the top error, then clears the rest. Both patterns silently drop unrelated errors.
Affected Scope
The concrete trigger appears on Debian 13 with apt 3.0 and OpenSSL 3.5.6. Earlier apt used GnuTLS, so it never touched this queue. Klode then found the same shortcut across Debian using code search. Beyond apt, this OpenSSL error handling pattern shows up across many projects.
Fix and Mitigation
The safe fix is narrow, not blanket. Developers should clear the queue only around known-benign operations, as libpq does. Better yet, guard blocks with ERR_set_mark and ERR_pop_to_mark. Above all, fix the code that raised the error in the first place. For apt itself, the proposed patch adds one queue-clearing call before each read and write. Maintainers are still weighing whether libssl should clear the queue on its own. For apt users hit today, enabling the default OpenSSL provider restores repository access.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.