CVE-2025-14651
Hard-Coded Cryptographic Key in MartialBE Docker Configuration
Publication date: 2025-12-14
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 |
|---|---|---|
| martialbe | one-hub | * |
| martialbe | one-hub | 0.14.27 |
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
Can you explain this vulnerability to me?
CVE-2025-14651 is a vulnerability in MartialBE one-hub (up to version 0.14.27) caused by a hard-coded SESSION_SECRET key in the docker-compose.yml file. This default secret is used in Docker's one-click deployment, allowing attackers to forge JSON Web Tokens (JWTs) and bypass authentication. Exploiting this flaw grants attackers system administrator privileges, enabling unauthorized access to sensitive data and system controls. The vulnerability arises because the default secret is predictable and not changed by users deploying the system, and one-hub lacks safeguards to detect or replace this default secret. [1, 2, 3]
How can this vulnerability impact me? :
This vulnerability can allow attackers to bypass authentication and gain critical system administrator privileges remotely. They can access sensitive data, add or delete users, and retrieve cloud keys, compromising the confidentiality and integrity of the system. Since the exploit is publicly available, attackers can use the hard-coded SESSION_SECRET to forge session tokens and access backend interfaces without authorization, potentially leading to severe security breaches. [1, 2, 3]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by checking if the default hard-coded SESSION_SECRET value "random_string" is being used in the docker-compose.yml file of the one-hub deployment. You can inspect the docker-compose.yml file, especially line 15, to verify the SESSION_SECRET environment variable. For example, use the command: `grep SESSION_SECRET docker-compose.yml` to find the secret. If the output shows the default value "random_string", the system is vulnerable. Additionally, monitoring logs for warnings about default SESSION_SECRET is recommended, but one-hub currently lacks such logging. There is also a proof-of-concept exploit that forges session tokens using this secret, so detecting forged JWTs or session cookies signed with the default secret could indicate exploitation attempts. [2]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include changing the SESSION_SECRET environment variable in the docker-compose.yml file from the default hard-coded value "random_string" to a strong, unique, and random secret. Avoid using the default docker-compose example file in production without modification. It is recommended to carefully review and modify all configuration settings and environment variables before deployment. Since one-hub lacks automatic detection or replacement of the default secret, manual intervention is necessary. Applying these changes will prevent attackers from forging session tokens and bypassing authentication. [2, 3]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows attackers to bypass authentication by exploiting a hard-coded session secret, enabling unauthorized access to sensitive data and administrative functions. Such unauthorized access and potential data breaches can lead to non-compliance with data protection regulations like GDPR and HIPAA, which require strict controls over access to personal and sensitive information. Therefore, the vulnerability poses a risk to compliance by undermining confidentiality and access controls mandated by these standards. [1, 3]