CVE-2026-47842 in Spring Security
Summary
by MITRE • 08/26/2026
Applications using AesBytesEncryptor with the two-argument constructor or when passing a null IV generator and CBC as the encryption mode encrypt data with AES/CBC using a null (all-zero) initialization vector. Spring Security 7.1.0 Spring Security 7.0.0 - 7.0.6 Spring Security 6.5.0 - 6.5.11 Spring Security 6.4.0 - 6.4.18 Spring Security 5.8.0 - 5.8.27 Spring Security 5.7.0 - 5.7.25
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in the specified versions of Spring Security involves a critical misconfiguration within the AesBytesEncryptor component, specifically when utilizing the two-argument constructor or explicitly passing a null initialization vector generator while operating in Cipher Block Chaining mode. This flaw results in the encryption process defaulting to an all-zero initialization vector for every encrypted data block. In cryptographic operations involving AES/CBC, the initialization vector is intended to be random and unique for each encryption operation to ensure semantic security. By using a static null IV, the system fails to introduce randomness into the ciphertext, which fundamentally undermines the confidentiality guarantees provided by symmetric encryption algorithms like Advanced Encryption Standard.
From a technical perspective, this behavior creates a deterministic encryption scheme where identical plaintext inputs will always produce identical ciphertext outputs when encrypted under the same key. This determinism allows attackers to perform pattern analysis and frequency attacks against the encrypted data. If an adversary can observe multiple encrypted messages or gain access to previously encrypted data, they may be able to infer relationships between different pieces of information without ever decrypting them directly. For instance, if two users have identical session tokens or passwords that are stored using this vulnerable configuration, their ciphertexts will match exactly, revealing structural similarities in the underlying data and potentially facilitating brute-force attacks against specific values by comparing known plaintext candidates with observed ciphertext patterns.
The operational impact of this vulnerability is severe for any application relying on Spring Security to protect sensitive user credentials, session identifiers, or personal identifiable information stored within cookies or database fields. Attackers who gain read access to the encrypted data store can exploit the lack of randomness to identify common values across multiple records. This significantly reduces the entropy required to crack individual entries through offline dictionary attacks since the attacker does not need to account for varying IVs in their computations. Furthermore, this flaw violates fundamental cryptographic best practices outlined by industry standards such as CWE-329 which addresses the use of predictable or non-random initialization vectors, and aligns with ATT&CK techniques related to credential access where structured data analysis aids in compromising authentication mechanisms.
To mitigate this risk, developers must immediately upgrade Spring Security to a version that corrects the default behavior of AesBytesEncryptor when no IV generator is provided. The recommended approach involves ensuring that an explicit SecureRandom-based initialization vector generator is passed during instantiation or configuring the encryptor to generate unique random IVs for each encryption operation automatically. Additionally, applications should audit their usage of AES/CBC mode and consider migrating to authenticated encryption modes such as AES/GCM which provide both confidentiality and integrity protection while handling nonce management more robustly. Regular security assessments and code reviews focusing on cryptographic implementations are essential to prevent similar misconfigurations in future development cycles.