CVE-2026-94591 in One
Summary
by MITRE • 10/03/2026
Armatura One stores database and message-broker credentials in an install configuration file, encrypting them with AES-128-CBC when this protection is enabled. The encryption key and initialization vector are fixed values embedded in the software itself and are identical across every installation. An attacker with a copy of the installation package can recover this key and initialization vector, and can then decrypt the stored credentials of any specific installation to which the attacker separately obtains the encrypted configuration file.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/03/2026
The vulnerability identified in Armatura One represents a critical failure in cryptographic implementation, specifically falling under the category of hardcoded encryption keys as defined by CWE-798. The software is designed to protect sensitive database and message-broker credentials stored within an installation configuration file using AES-128-CBC encryption when this protection feature is enabled. However, the security model relies entirely on the secrecy of the algorithm parameters rather than a unique secret key per deployment. Specifically, both the encryption key and the initialization vector are static values hardcoded directly into the software binary or distribution package. This architectural decision means that every instance of Armatura One deployed by any customer utilizes the exact same cryptographic material for encrypting these sensitive configuration files.
From an operational perspective, this flaw fundamentally undermines the confidentiality guarantees provided by AES-128-CBC encryption. While Advanced Encryption Standard is a robust algorithm when implemented correctly with unique, randomly generated keys and initialization vectors per session or file, its security collapses completely if the key remains constant across all installations. An attacker who gains access to the installation package, which may be distributed publicly or obtained through other means such as unauthorized downloads or insider threats, can reverse-engineer the binary to extract these hardcoded credentials. Because the key and vector are identical for every user, compromising one instance allows an adversary to decrypt configuration files from any other instance of the software where they have managed to obtain the encrypted file. This transforms a local access issue into a widespread systemic risk affecting all users relying on this protection mechanism.
The impact of this vulnerability is severe, as it exposes sensitive infrastructure credentials including database passwords and message-broker authentication tokens. If an attacker successfully decrypts these files, they gain unauthorized access to backend data stores and messaging systems that Armatura One relies upon for its operations. This can lead to a complete compromise of the affected environment, allowing for data exfiltration, modification of critical records, or disruption of services through message injection or denial of service attacks against the underlying infrastructure components. The attacker does not need to exploit any runtime vulnerabilities in the application logic; they only require static access to the software distribution and the target configuration file, significantly lowering the barrier to entry for exploitation.
This vulnerability aligns with ATT&CK technique T1552.004, Unsecured Credentials: Private Keys, as it involves the exposure of cryptographic material that protects sensitive data. Furthermore, it reflects CWE-321, Use of a Hard-coded Cryptographic Key, which is widely recognized in security standards such as OWASP and NIST guidelines for secure software development. The presence of fixed keys violates the principle of key diversity, ensuring that compromise of one system does not lead to the compromise of others.
To mitigate this vulnerability, developers must immediately replace hardcoded cryptographic material with a mechanism that generates unique encryption keys per installation or user session. This can be achieved by deriving keys from a master secret stored securely in hardware security modules or operating-system-level key stores rather than embedding them in source code or binaries. Additionally, initialization vectors should always be randomly generated for each encryption operation and transmitted alongside the ciphertext to ensure semantic security of the cipher. For existing deployments where immediate patching is not possible, administrators should consider rotating credentials manually if feasible, although this does not address the underlying flaw that allows future decryption by anyone with access to the software package. Long-term remediation requires a comprehensive review of cryptographic practices within the application lifecycle to prevent similar implementation errors in other components.