CVE-2026-111696 in data-platform-open
Summary
by MITRE • 10/16/2026
data-platform-open through commit efeacd3 uses a hardcoded, publicly known default AES key in AesPasswordEncAndDecServiceImpl, allowing authenticated attackers to decrypt stored datasource passwords. Attackers can obtain ciphertext passwords from the datasource detail API, for example via cross-workspace IDOR, and decrypt them offline to recover plaintext database credentials.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in data-platform-open through commit efeacd3 represents a critical failure in cryptographic key management that fundamentally undermines the confidentiality of stored sensitive information. The core technical flaw resides within the AesPasswordEncAndDecServiceImpl component, which utilizes a hardcoded Advanced Encryption Standard AES key for encrypting and decrypting datasource passwords. This implementation choice violates fundamental security principles by embedding secret material directly into the application source code or configuration rather than deriving it from secure, dynamic sources such as hardware security modules or dedicated vaults. Because this default AES key is publicly known, any individual with access to the software artifacts possesses the necessary cryptographic primitives to reverse the encryption process without requiring additional authentication for the decryption operation itself.
The operational impact of this flaw allows authenticated attackers to compromise database credentials through a multi-step exploitation path. First, an attacker leverages their existing valid session within the application to interact with the datasource detail API endpoint. By exploiting insecure direct object references or cross-workspace identifier inconsistencies, often categorized under CWE-639, the attacker can enumerate and access configuration details belonging to other users or workspaces they are not authorized to view. This provides them with the encrypted ciphertext of various database passwords stored within the platform's backend systems.
Once these ciphertext values are obtained, the attacker utilizes the publicly known hardcoded AES key to decrypt the data offline. Since the decryption algorithm is standard and the key is static, this process requires no interaction with the vulnerable application server after the initial data exfiltration phase. The result is the recovery of plaintext database credentials for potentially multiple backend systems connected to the platform. This compromise enables further lateral movement within an organization's infrastructure, as these recovered credentials may grant access to production databases containing sensitive customer data or critical business logic.
From a classification perspective, this vulnerability aligns with CWE-798: Use of Hard-coded Credentials and CWE-321: Use of a Key Past its Expiration Date if the key was intended for temporary use but remained static. In terms of attack vectors, it relates to MITRE ATT&CK techniques involving Credential Access via Unsecured Data Storage or Discovery through API manipulation. The severity is exacerbated by the fact that the weakness persists across all instances using this version unless explicitly patched, affecting every tenant on a multi-tenanted deployment model.
Mitigation strategies must prioritize immediate remediation of the cryptographic implementation. Developers should remove the hardcoded AES key from the AesPasswordEncAndDecServiceImpl class entirely and replace it with a dynamic key management solution. This could involve generating unique keys per workspace or user, storing them in a secure secrets manager such as HashiCorp Vault or AWS Secrets Manager, or utilizing environment variables injected at runtime that are not present in source control repositories. Additionally, the application must enforce strict access controls on the datasource detail API to prevent cross-workspace enumeration and ensure that only authorized entities can retrieve encrypted credential data. Regular security audits of cryptographic implementations should be conducted to detect similar patterns where secrets are embedded within codebases rather than managed externally.