Banked: 2026-07-14, cycle314 (Vault->OpenBao HCSEC-2026-06 ACME SSRF: real unported gap, but disclosure-adjacent).
A cross-fork port-lag gap can be REAL (fork HEAD genuinely lacks the upstream security fix, shared lineage) yet NOT clean-undisclosed, because a feature-request issue on the fork already names the exact missing config/behavior + cites the upstream fix - filed as "please add capability X" (not "security bug"), but it publicly surfaces "the port is missing." A triaging maintainer instantly connects it to the upstream advisory. Per the complete-degraded-gate + saturation doctrine, treat this as DISCLOSURE-ADJACENT (weakened novelty), an operator-decision, not a clean stage.
- Concrete: OpenBao issue #3249 (2026-06-09, feature) asks for challenge_permitted/excluded_ip_ranges (the exact fields Vault's HCSEC-2026-06 SSRF fix added) - so OpenBao's ACME-SSRF port is publicly known-missing even though no OpenBao GHSA/CVE names it.
When set-differencing a port-lag: after confirming the fix is absent at fork HEAD, ALSO grep the fork's OPEN issues/PRs for the fix's CONFIG-FIELD NAMES / capability, not just the CVE/HCSEC id. A feature request naming the missing config = disclosure-adjacent. (The CVE-id search alone would have missed #3249 - it doesn't mention CVE-2026-5052.)
OpenBao HAS a reserved-block reject for explicit IP-type ACME identifiers - which LOOKS like the fix but ISN'T: it doesn't cover the DNS-name SSRF vector (attacker controls DNS to resolve a name to an internal IP). A partial guard on an adjacent code path is not the fix. Always confirm the guard covers the ACTUAL attack vector (DNS-identifier here), not a sibling (IP-identifier).