CVE-2023-54356 in Kyverno
Summary
by MITRE • 09/01/2026
Kyverno versions 1.9.4 and earlier support insecure 3DES cipher suites (TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_3DES_EDE_CBC_SHA) on their TLS endpoints. These 64-bit block ciphers are vulnerable to the Sweet32 attack (CVE-2016-2183), which, over very long-lived TLS connections carrying large volumes of traffic, could allow an attacker to recover small amounts of plaintext. The issue is fixed in Kyverno 1.9.5 and 1.10.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/01/2026
Kyverno versions prior to 1.9.5 and 1.10.0 contain a cryptographic weakness related to the configuration of Transport Layer Security (TLS) cipher suites on their API endpoints. Specifically, these older releases support legacy cipher suites that utilize Triple Data Encryption Standard with an Electronic Codebook or Cipher Block Chaining mode, such as TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_3DES_EDE_CBC_SHA. While 3DES was once considered a robust standard for symmetric encryption, its use of a 64-bit block size has been identified as a significant security liability in modern cryptographic practice. The presence of these cipher suites indicates that the Kyverno controller-manager or API server does not strictly enforce a policy requiring only high-strength algorithms with larger block sizes, thereby allowing clients to negotiate weaker encryption methods if they are available and supported by the client software.
The primary technical flaw associated with this configuration is susceptibility to the Sweet32 birthday attack, formally documented as CVE-2016-2183. This vulnerability exploits the mathematical properties of 64-bit block ciphers when used in Cipher Block Chaining mode over long-lived connections that transmit large volumes of data. As more encrypted blocks are processed using the same key, the probability of a collision occurring increases significantly due to the birthday paradox. An attacker positioned as a man-in-the-middle can leverage these collisions to deduce plaintext information from the encrypted stream without possessing the encryption key. Although 3DES uses three iterations of DES with different keys, effectively providing 168 bits of key material, the small block size remains the critical weakness that undermines its security against this specific type of statistical analysis attack.
The operational impact of this vulnerability is contingent upon several factors, primarily the duration and volume of TLS sessions established between clients and Kyverno endpoints. In environments where long-lived persistent connections are maintained for continuous monitoring or admission control operations, an attacker with network-level access could potentially recover small fragments of sensitive data transmitted over these channels. This might include authentication tokens, configuration details, or other metadata exchanged during the Kubernetes API interactions managed by Kyverno. While the attack requires substantial traffic and time to succeed, it represents a non-trivial risk in high-throughput production environments where connections are kept open for extended periods to reduce handshake overhead.
This vulnerability maps directly to CWE-326: Inadequate Encryption Strength, as the system relies on an algorithm with insufficient block size for modern security requirements. Furthermore, from a threat modeling perspective aligned with MITRE ATT&CK techniques, this flaw facilitates data exfiltration through cryptographic analysis (T1504) and potentially aids in credential harvesting if session tokens are compromised via plaintext recovery. The vulnerability also reflects CWE-327: Use of a Broken or Risky Cryptographic Algorithm, highlighting the failure to adhere to current best practices that mandate the deprecation of 64-bit block ciphers like DES and 3DES in favor of AES with 128-bit blocks or larger.
To mitigate this risk, organizations running Kyverno versions prior to 1.9.5 should upgrade immediately to version 1.9.5 or later, where the insecure cipher suites have been removed from the default configuration. For environments that cannot yet upgrade, administrators can manually configure TLS settings on the Kubernetes API server and Kyverno components to explicitly disable weak ciphers by specifying a secure cipher suite list in their respective configurations. It is also recommended to enforce strict TLS version policies, ensuring only TLS 1.2 or higher are permitted, as older protocol versions often pair with weaker cryptographic algorithms. Regular audits of certificate and cipher suite configurations against industry standards such as NIST SP 800-52 Rev. 2 should be conducted to ensure ongoing compliance and security posture integrity across all Kubernetes admission controllers and API endpoints.