CVE-2026-90945 in Crawlab
Summary
by MITRE • 09/14/2026
Crawlab through 0.6.3 uses a hard-coded HMAC-SHA256 secret for JWT token signing that cannot be overridden via configuration or environment variables. Unauthenticated attackers can forge valid administrator tokens to access administrative APIs and execute code on worker nodes.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in Crawlab versions through 0.6.3 represents a critical failure in authentication mechanism design, specifically classified under CWE-798: Use of Hard-coded Credentials. The core technical flaw lies in the implementation of JSON Web Token (JWT) signing, where the system relies on a static, hard-coded HMAC-SHA256 secret key rather than generating or accepting a unique secret from configuration files or environment variables during deployment. This architectural decision means that every instance of Crawlab running these vulnerable versions shares the same cryptographic key for validating and issuing administrative tokens. In secure systems, JWT secrets must be high-entropy values known only to the specific server instance to ensure that token forgery is computationally infeasible without knowledge of that secret. By hardcoding this value, the developers have effectively removed the element of secrecy required for asymmetric or symmetric cryptographic verification, turning a robust authentication layer into a trivially bypassable gatekeeper.
From an operational perspective, this flaw allows unauthenticated attackers to forge valid administrator tokens with minimal effort. Since the signing algorithm and the secret key are publicly known or easily discoverable through source code analysis or reverse engineering of the binary, any actor can construct a JWT payload claiming administrative privileges and sign it using the hard-coded HMAC-SHA256 key. Once this forged token is presented to the Crawlab API, the system accepts it as legitimate because the signature validates correctly against the known secret. This bypasses all authentication checks, granting the attacker full control over the application interface. The impact extends beyond mere administrative access; because Crawlab facilitates task execution on worker nodes, obtaining an administrator token allows the attacker to submit arbitrary tasks that are executed by these workers. Consequently, this leads to Remote Code Execution (RCE) on any connected node within the cluster, effectively compromising the entire infrastructure managed by the platform.
This vulnerability aligns with several entries in the MITRE ATT&CK framework, particularly T1078: Valid Accounts and T1190: Exploit Public-Facing Application. The exploitation path involves first exploiting a public-facing application to gain initial access via forged credentials, followed by lateral movement or privilege escalation within the environment through the execution of malicious tasks on worker nodes. The severity is heightened because it affects both confidentiality and integrity, as well as availability if destructive commands are executed. Attackers can exfiltrate sensitive data processed by the workers, modify configurations to maintain persistence, or disrupt services by terminating critical processes.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The most urgent action is to upgrade Crawlab to a version later than 0.6.3 where this hard-coded secret has been replaced with a configurable mechanism that allows administrators to define their own high-entropy secrets during installation or configuration. If upgrading is not immediately possible, organizations should isolate the Crawlab instance from untrusted networks and restrict access to internal IP ranges only, although this does not fully mitigate the risk if an attacker gains initial foothold through other means such as social engineering or exploiting adjacent vulnerabilities. Furthermore, security teams should audit all JWT implementations across their infrastructure to ensure no other services rely on hard-coded secrets for cryptographic operations. Implementing strict input validation and monitoring for anomalous API usage patterns can also help detect potential exploitation attempts in real-time while patches are being applied.