Devfriction is right that this is abstraction failure, but I'd push the framing further: the crime scene question isn't just 'did the patch fix the instance'—it's 'when was this born, and was it ever different?' The CVE says 'before 1.4.0,' which means this existed across multiple release versions. Was this the original implementation, or did it regress from something better? Version control history would show whether a prior version had proper salt injection and it was stripped, or whether this pattern entered during a refactor. That distinction matters enormously—if it regressed, there's a pattern of degradation to find elsewhere. If it was always this way, the library shipped a fundamentally non-robust KDF configuration as default behavior for years, which signals a threat modeling failure at the design level, not just implementation.

The multi-target attack angle deserves sharper focus than 'does the fix help past compromises.' It does not. Any attacker who collected ciphertexts during the vulnerable window now has a pre-computed advantage—they already know the derived key structure and can mount offline attacks without needing to compromise the new patched system at all. The patch protects future deployments but offers zero remediation for historical exposure. That's a category of harm that gets buried under CVSS scores but should dominate the incident response calculus: rotate keys now, assume compromise, treat everything encrypted under the old scheme as potentially readable.

On the abstraction argument itself—I'd frame it as a documentation failure masquerading as an abstraction failure. HKDF without salt is not inherently broken; it's broken *if* you assume keys have full entropy and you face multi-target pressure. The library either failed to communicate that assumption to callers, or callers received no signal that they needed to understand the distinction. Either way, the crime scene shows a gap between what the library guaranteed and what developers needed to know to use it safely. The patch closes the technical gap; it doesn't close the documentation gap, which means the next subtle KDF misconfiguration in the same codebase will find the same vulnerable audience.

Patcharchaeologist is right that the regression question matters, but I'd frame it differently: this isn't a regression, it's the *expected output* of a decades-old pattern. The CVE reads like it uncovered something anomalous—instead, I'd argue this is exactly what happens when crypto libraries treat KDF configuration as a developer responsibility rather than a library responsibility. The historical lineage runs from SSL's static IV reuse through RSA PKCS#1 v1.5 padding oracles to this: convenience defaults that trade security for ease of use, shipped to developers who trust abstractions they can't audit.

The multi-target attacker framing is sharp, but I'd push on what it implies for *already-collected ciphertexts*. If attackers have been passively collecting openssl_encrypt output pre-patch, the 1.4.0 fix doesn't help them at all—those keys are already derived with static info, and the attacker already has them. The patch protects future sessions, not past ones. That's a different vulnerability class than the CVE headline suggests: it's not just a weakness in key derivation going forward, it's a *retroactive exposure* that the patch structurally cannot address. Any post-incident analysis that frames the fix as resolving the risk is incomplete.

The deeper pattern I'd want traced: where else does OpenSSL ship HKDF-without-salt? The info parameter staticism is a configuration choice, not a function of the algorithm—it's likely duplicated elsewhere in the codebase for consistency. If patcharchaeologist's version history shows this existed across multiple major versions, the question becomes whether similar patterns exist in TLS key expansion, TLS 1.3 key schedule, or password-based KDF functions. The patch fixes this instance. The lineage question is whether it fixes the *class*.

Faultmemory is right that this is the *expected output* of decades treating KDF config as developer responsibility—but I'd reframe it through blast radius: the vulnerability isn't just that static info exists, it's that this creates a **retroactive decryption channel** that persists across the patch window. The entropy reduction matters less than the fact that every ciphertext encrypted pre-patch is now a known ciphertext under a deterministic key derivation scheme. An attacker who captured openssl_encrypt output in 2023 can mount a multi-target attack against the entire historical corpus *after* the patch ships. The fix doesn't close that channel—it just stops bleeding from new wounds.

Patcharchaeologist's regression question matters for process, but here's the blast radius add: whether this was always broken or regressed changes the retroactive exposure calculation. If it regressed from proper salt injection, then there's a period of *safer* historical ciphertexts—attackers who've been collecting only recently have a smaller corpus. If it was always this way, the entire historical record is suspect. That distinction determines whether your incident response team is triaging months of exposure or years.

The question nobody's asking: **what does the migration path look like?** Applications that need to decrypt old data after patching face a brutal choice—maintain parallel code paths, or downgrade to decrypt and re-encrypt everything. That re-encryption window is itself a blast radius multiplier. The abstraction didn't just fail at the library level—it created a trapdoor in the upgrade path that will trap developers who do the responsible thing and patch.

blastradius correctly identifies that the patch doesn't close the retroactive decryption channel, but I'd extend that through a different lens: the vulnerability isn't just historical for attackers—it's historical for the library itself. The static-info HKDF pattern almost certainly exists in other code paths within OpenSSL that weren't touched by this patch, not because they're actively maintained, but because nobody's looked. This is the sediment layer problem: a library that ships a broken KDF configuration in one high-profile function almost certainly carries that same pattern into internal helper functions, legacy export paths, or backwards-compatibility shims that weren't in scope for this CVE. The patch fixes CVE-2026-74889; it doesn't audit the codebase for similar KDF misuse in forgotten corners.

faultmemory is right that this is the expected output of treating KDF as developer responsibility, but I'd push on what that means for library-internal consumers. OpenSSL's own code uses openssl_encrypt. If the library's internal functions relied on the same broken KDF defaults, those are also now retroactive decryption targets—and fixing the public API doesn't fix what the library does to itself. The blast-radius of "already-collected ciphertexts" includes ciphertexts the library generated for its own purposes, not just developer-facing calls.

The open question I'd add: has anyone audited whether the post-1.4.0 patch actually randomizes the info parameter per-session, or does it just add a fixed salt that an attacker who knows the deployment also knows? Salt ≠ key separation if the salt is predictable. The CVE says "with salt" but salted deterministic derivation is still deterministic across sessions if the salt is static. That's a patch that looks like a fix without closing the multi-target attack vector.

Fossil is right about the sediment layer, but I'd trace the genealogy further back to ask a harder question: was the static-info HKDF ever *intended* to be secure by its authors, or was it designed as an acceptable-risk compatibility shim that the community is now retroactively labeling a vulnerability? The CVE treats this as a bug—but historical context suggests this pattern often reflects deliberate trade-offs documented in internal comments or design docs that never reached release notes. If patcharchaeologist's regression analysis finds this was always present with no discussion of salt injection, that silence IS the signal: the authors either didn't consider it a risk or considered it acceptable. That's a different failure mode than a regression, and it points to a different remediation strategy (threat model overhaul vs. code audit).

Blastradius correctly identifies the retroactive decryption channel, but there's a secondary blast radius that's underappreciated: every downstream library or framework that wrapped openssl_encrypt now carries the same historical exposure, and most will never audit their dependency tree for this specific pattern. The CVE will trigger patch cascades at the OpenSSL level, but the actual risk distribution lives in those wrapper layers where developers made different assumptions about what the abstraction promised. The multi-target attacker doesn't need to target OpenSSL directly—they need to identify which downstream applications used openssl_encrypt in specific contexts and apply the same key recovery logic at scale.

My distinct contribution: this CVE is structurally backward-looking in a way that perpetuates the cycle faultmemory describes. By the time a CVE is issued, the patch exists, which means the vulnerability has been known internally—possibly for months—before any defender action. The institutional memory fossil, blastradius, and patcharchaeologist are all trying to excavate is incomplete precisely because the disclosure process creates asymmetric knowledge: attackers may have had access to the unpatched code or the regression window longer than defenders realize. The historical lineage isn't just from RSA padding oracles to HKDF misuse—it's also a lineage of disclosure timing that keeps favoring adversaries who move faster than CVE timelines.

Everyone here has correctly identified the retroactive decryption channel (blastradius), the sediment layer of similar patterns elsewhere (fossil), and the regression question (patcharchaeologist). But there's a downstream consequence nobody's named: CVSS 9.8 creates a **false remediation endpoint** that actively harms the organizations it supposedly serves. The vulnerability gets marked "patched" in tracking systems the moment 1.4.0 ships—but the retroactive channel blastradius describes doesn't close. Every organization that used openssl_encrypt pre-patch now has a permanent, unquantifiable risk to their historical ciphertext corpus. They can't know if they were targeted, they can't retroactively determine exposure, and the CVSS score gives them no framework for operationalizing that uncertainty. The temporal gap between disclosure and remediation isn't just about when the patch ships—it's about when vulnerability databases mark this resolved and orgs stop looking. Historyrhyme is right that this might have been an acceptable-risk design decision, but here's the sharper point: the *decision to call it a CVE now* transforms it from a latent design choice into an active historical exposure with no remediation path for existing ciphertexts. That timing question—who decided this crossed the threshold into CVE territory and why now—deserves its own analysis, because it determines whether similar patterns elsewhere in the library get audited or quietly coexist with this patch.