CVE-2026-7018
Hard-Coded Cryptographic Key in Datavines JWT Token Handler
Publication date: 2026-04-26
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| datavane | datavines | to 13607645e14a4982468cfdbcf75c85cde63bae71 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-320 | Key Management Errors |
| CWE-321 | The product uses a hard-coded, unchangeable cryptographic key. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows an attacker to bypass authentication entirely by exploiting a hardcoded JWT secret and flawed token validation logic. As a result, unauthorized users can access protected API endpoints, including administrative functions and sensitive data such as workspace and datasource configurations that contain database credentials.
Such unauthorized access to sensitive data and administrative controls can lead to violations of common standards and regulations like GDPR and HIPAA, which require strict access controls and protection of personal and sensitive information.
Therefore, the vulnerability undermines the security controls necessary for compliance with these regulations by enabling credential exposure and unauthorized data access.
Can you explain this vulnerability to me?
CVE-2026-7018 is a vulnerability in the Datavane Datavines project related to its JWT (JSON Web Token) authentication mechanism. The issue arises from the use of a hardcoded cryptographic key (secret) in the JWT Token Handler and flawed token validation logic.
Specifically, the token validation method improperly compares the password extracted from the token against itself rather than against a stored or expected password, allowing attackers to bypass authentication.
Additionally, the JWT tokens carry plaintext passwords in their claims, which is a critical security risk. The hardcoded secret is a default value "asdqwe" that is used because the configuration key for the secret is missing, making it easy for attackers to forge tokens.
An attacker can remotely exploit this by crafting a JWT token signed with the known hardcoded secret and any arbitrary password, gaining unauthorized access without needing valid credentials.
How can this vulnerability impact me? :
This vulnerability allows an attacker to completely bypass authentication in the Datavines platform.
- Unauthorized access to all protected API endpoints.
- Ability to list all workspaces and their datasource configurations, which include sensitive database credentials.
- Execution of arbitrary operations as any impersonated user, including administrative functions.
- No valid password or user account is required to exploit this vulnerability.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by attempting to forge a JWT token using the known hardcoded secret and then using that token to access protected API endpoints. If access is granted without valid credentials, the system is vulnerable.
A practical detection method is to generate a forged JWT token with the default secret "asdqwe" and use it to call an API endpoint that requires authentication.
- Generate a forged JWT token using Python:
- ```python import jwt, time token = jwt.encode({ 'un': 'admin', 'up': 'FAKE_PASSWORD', 'ct': int(time.time()*1000), 'sub': 'admin', 'exp': int(time.time()) + 315360000 }, 'asdqwe', algorithm='HS256') print(token) ```
- Use the forged token to access a protected API endpoint, for example:
- ```bash curl -s http://TARGET:5600/api/v1/workspace/list -H "Authorization: Bearer <forged_token>" ```
If the response returns HTTP 200 with workspace data, it confirms the authentication bypass vulnerability.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include:
- Remove or properly configure the hardcoded JWT secret to prevent use of the default secret "asdqwe".
- Apply the patch that fixes the token validation logic by:
- - Adding null and blank checks for token claims.
- - Changing password validation to use BCrypt password hash verification instead of plaintext comparison.
- - Eliminating the use of hardcoded secrets in the JWT token handler.
- - Removing plaintext passwords from JWT claims and instead validating tokens using standard JWT claims and signature verification.
Since the project uses a rolling release model and version information is unavailable, it is advisable to monitor the official repository for the patch identified by commit e540d6dc04e2e6ad11907fb655f3728a13e7b939 and apply it as soon as possible.