EUVD-2026-102987
GHSA-jhvf-5wf6-hcgg
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privileged user
-
DeliveryCall datasource detail API
-
ExploitAbuse cross-workspace IDOR to fetch other tenants' ciphertext
-
ExecutionDecrypt offline with public hardcoded AES key
-
ImpactRecover plaintext database credentials
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Key management, no hard-coded keys
|
| Exploitation Conditions | Requires a valid authenticated account on the data-platform-open instance (any low-privileged workspace user, per PR:L). The attacker must be able to reach the datasource detail API and leverage the described cross-workspace IDOR to access datasources outside their own workspace; the AES key needed for decryption is hardcoded in AesPasswordEncAndDecServiceImpl and application-common.yml and is publicly known from the source repository, so no key-cracking is needed. Exploitation is limited to deployments running through commit efeacd3 (or earlier) and only exposes stored datasource passwords (confidentiality only); it does not by itself grant integrity or availability impact, and it depends on the multi-workspace/multi-tenant deployment mode for the cross-workspace escalation to be meaningful. |
| Impact | This is a moderate, authentication-gated information-disclosure issue rather than a widespread emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) scores 7.1 and correctly reflects a network-reachable but authenticated (PR:L) attack with high confidentiality impact and no integrity or availability impact. The root cause (CWE-321, hardcoded AES key in AesPasswordEncAndDecServiceImpl, with the key visible in the public GitHub repo and application-common.yml) means the cryptographic protection of stored datasource passwords is effectively nonexistent once ciphertext is obtained. No EPSS score, no CISA KEV listing, and no explicit POC/exploit-code flag were supplied in the input, so there is no confirmed active exploitation signal; however, a detailed public technical write-up (hackmd) and the referenced vulnerable source lines lower the practical barrier considerably. Signals are consistent rather than conflicting: the CVSS confirms network vector with low privileges, and the description confirms an authenticated attacker who can leverage a cross-workspace IDOR to reach other tenants' datasource details. The main risk amplifier is the chained IDOR allowing a low-privileged user to cross workspace/tenant boundaries; the main limiter is that an attacker must already hold a valid account. Net: a real but targeted-risk issue - prioritize for multi-tenant deployments of this product, but it is not a mass-exploitation, unauthenticated-RCE-class event. |
| Exploit ScenarioDerived | A low-privileged but authenticated user of a data-platform-open instance calls the datasource detail API and, abusing a cross-workspace IDOR, retrieves encrypted datasource passwords belonging to other workspaces. Because the AES key is hardcoded and publicly known from the source repository, the attacker decrypts the ciphertext offline to recover plaintext database credentials. A detailed public technical write-up describing this exact path exists, though no packaged exploit tool was indicated in the input. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 16, 2026
Stored datasource passwords in data-platform-open (through commit efeacd3) can be recovered in plaintext by any authenticated, low-privileged workspace user, because the service encrypts those passwords with a hardcoded AES key that is published in the project's own source repository. An attacker who reaches the datasource detail API - for example by abusing a cross-workspace IDOR to read datasources belonging to other tenants - can pull the ciphertext and decrypt it offline without any key-cracking effort, exposing the underlying database credentials. The issue is authentication-gated rather than remote-unauthenticated, is limited to confidentiality impact, and no public exploit code has been identified at time of analysis.
RemediationAI
No vendor-released patch has been identified at time of analysis, so operators must rely on compensating controls and code-level fixes. The highest-value code change is to remove the hardcoded key from AesPasswordEncAndDecServiceImpl and application-common.yml and source the AES key from an external secret manager or per-installation configuration, then re-encrypt all existing datasource passwords with the new key and rotate the underlying database credentials, since any credential ever stored under the public key must be treated as compromised; the trade-off is a migration window in which legacy ciphertext cannot be read until re-encrypted. Until that lands, close the exposure path by fixing the datasource detail API so it enforces workspace-scoped authorization on every request (rejecting cross-workspace IDs) and by restricting that endpoint to trusted networks or administrative roles; disabling or firewalling the endpoint breaks legitimate datasource management workflows for tenant users. Additional short-term mitigations include granting datasource read privileges only to users who genuinely need them, using least-privilege database accounts for the stored datasources so a recovered password yields minimal access, and alerting on anomalous cross-workspace access patterns in API logs; these reduce but do not eliminate the exposure while the key remains hardcoded. Reference material is available at the VulnCheck advisory (https://www.vulncheck.com/advisories/data-platform-open-through-commit-efeacd3-hardcoded-aes-key-for-datasource-passwords) and the researcher write-up (https://hackmd.io/@hieuPenguinnn/data-platform-open-datasource-cross-workspace-idor-and-hardcoded-aes-key).
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
CWE-321 (Use of Hardcoded Cryptographic Key) is the root cause: the AES key material used for reversible password storage is baked into AesPasswordEncAndDecServiceImpl (lines 21-25 of data-platform-open-web) and mirrored in data-platform-open-common/src/main/resources/application-common.yml (lines 104-106), so the key is cryptographically public to anyone who reads the open-source repository. Because the scheme is deterministic and reversible (the same static key both encrypts and decrypts datasource passwords), confidentiality collapses the moment an attacker obtains the ciphertext - no brute force, oracle, or side channel is required. The companion weakness is an authorization/IDOR gap in the datasource detail API, which lets a user in one workspace request the detail record (and thus the encrypted password field) of a datasource in another workspace. The affected artifact is tracked as cpe:2.3:a:shaiwz:data-platform-open:*:*:*:*:*:*:*:*, specifically deployments running through commit efeacd35e8450b7a084fa2134d292cd058cf605b or earlier. The CVSS:4.0 vector supplied by the reporter (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N, score 7.1) is consistent with an authenticated, network-reachable information-disclosure bug with no integrity or availability component.
Know when Data Platform Open gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Network-reachable API with a low-privileged authenticated account (PR:L, AV:N, AC:L); recovers plaintext DB credentials so C:H, with no integrity or availability impact and no scope change.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
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.
Executive ViewAI
Data-platform-open deployments at or before commit efeacd3 expose stored datasource passwords to low-privileged workspace users, creating a cross-tenant credential disclosure risk. Because the encryption key is embedded in the source repository, any user who can reach the datasource detail API can recover database credentials, potentially leading to unauthorized access to downstream systems and sensitive data. Leadership should prioritize credential rotation and access restrictions until a vendor fix is available.
No vendor-released patch identified at time of analysis. Interim mitigations: restrict datasource detail API access to trusted administrators, enforce strict tenant isolation to prevent cross-workspace IDOR reads, rotate all stored database credentials, migrate secret encryption to an external KMS/secrets manager, remove the hardcoded AES key from deployments, apply network segmentation, and monitor for anomalous datasource access. Apply vendor patch when available.
Threat Intelligence Overview
NVD
CVE.org
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB