Maybe your organization has already made the investment. Maybe you have reviewed the threat landscape, updated your security configurations, and checked the box: quantum-resistant encryption - enabled. But there is a newly disclosed flaw in OpenSSL. OpenSSL is the cryptographic engine powering a vast portion of the internet's secure communications. This means your systems may have reverted to weaker protection without telling you. No alarm. No error message. No failed connection. Everything looks normal. The flaw is tracked as CVE-2026-2673, and it creates a gap between what you believe your encryption is doing and what it is actually doing. That gap is exactly what adversaries are counting on. Here is what happened, why the official severity rating understates the real business risk, and what you need to do now.
OpenSSL is not a product. It is the cryptographic substrate underneath a significant fraction of the internet's secure communications infrastructure. When something breaks in OpenSSL, it breaks quietly and at scale.
CVE-2026-2673 affects TLS 1.3 servers configured using DEFAULT in their group selection settings. Under specific negotiation conditions, the server fails to assert its intended preferred key exchange group. The expected mechanism, HelloRetryRequest which is the TLS 1.3 signal by which a server tells a client to retry with a different group, is suppressed. The handshake completes but using a weaker-than-intended group.
For servers that have configured hybrid post-quantum groups such as X25519MLKEM768 which combines classical X25519 elliptic curve with ML-KEM, the recent NIST-standardized post-quantum key encapsulation under FIPS 203, the practical result is a fallback to a classical-only group, without the indicators that standard TLS auditing are likely to surface.
CVE-2026-2673 does not enable catastrophic key recovery. No private keys are directly exposed. Sessions are not trivially decryptable. By conventional vulnerability scoring, this reads as moderate, and it will move through many patch cycles as a result.
That framing misses the point. The danger here is not what the flaw does. It is what the flaw hides.
The value of hybrid post-quantum groups is precisely that they provide quantum-resistant key exchange for communications whose confidentiality must hold against a future quantum-capable adversary. The harvest-now-decrypt-later threat model in which adversaries collect encrypted traffic today for decryption once a cryptographically relevant quantum computer is available, is not hypothetical. It is the threat driving the urgency behind NIST's completed standardization, and recent timeline updates by Google and Cloudflare.
If your TLS 1.3 deployment is configured to negotiate X25519MLKEM768 and CVE-2026-2673 is suppressing that negotiation in favor of a classical group, your communications are not receiving the quantum-resistant protection you believe they are receiving. For data with a long confidentiality horizon that is not a moderate severity issue. It is a direct exposure to the threat that the hybrid group was suppose to defend against.
CVE-2026-2673 surfaces a vulnerability class that will become more common as post-quantum deployment accelerates. Hybrid algorithm configurations are architecturally more complex than their classical-only counterparts. They introduce new negotiation semantics, new fallback behaviors, and new failure modes. All of these interact with existing infrastructure in ways that are difficult to fully anticipate.
This creates a specific risk profile that is particular to the transition period: organizations believe they have deployed quantum-resistant cryptography because they have configured the right parameters, but the actual negotiated cryptography turns out to be weaker than intended. The configuration looks correct. The logs show successful connections. The sessions are encrypted. Yet, the quantum protection is absent.
This is the class of problem that cannot be addressed through configuration management or periodic audits alone. Knowing what your systems are configured to do is not the same as knowing what your systems are actually doing. Verifying cryptographic posture at the negotiation layer in real time, across your environment is the operational capability the transition period demands.
Patch immediately. The OpenSSL fix is available. Apply it across your TLS infrastructure with the urgency appropriate to a flaw in your cryptographic foundation, regardless of how the NVD severity score reads.
Verify. Patching does not guarantee intended behavior is restored. Actively validate that X25519MLKEM768 or your intended hybrid group is being negotiated after the patch is applied. This requires inspection of negotiated session parameters, not configuration file review.
Establish continuous visibility. CVE-2026-2673 is not the last flaw of this type. The transition period will surface additional negotiation-layer vulnerabilities as hybrid configurations encounter edge cases in production infrastructure. Continuous visibility into what is actually being negotiated across your environment is an operational requirement.
The verification problem most organizations do not yet have a solution for. Step two above, verify, is where most organizations will stall. The tooling for configuration review is mature. The tooling for real-time negotiation-layer verification across a heterogeneous TLS environment is not. Arqit’s Encryption Intelligence is built to inspect this exact thing.
This gap is not unique to CVE-2026-2673. It is the gap that makes the entire class of flaws difficult to detect and quantify. Closing it requires ongoing cryptographic observability and the ability to see what is actually running, not just what was configured to run.
27 April 2026