Crawlab’s JWT Secret Is Literally Hard-Coded — Admin Takeover Leads to Cluster RCE

• The Mess: Crawlab hard-coded its HMAC-SHA256 JWT signing secret as "crawlab". Anyone who can reach a vulnerable instance can forge administrator tokens without legitimate credentials.
• The Damage: A fake admin session can reach Crawlab’s task-management functions and turn an authentication bypass into arbitrary code execution on worker nodes.
• The Fix: Treat Crawlab 0.6.3 and earlier as compromised-by-design, restrict network exposure immediately, and move to a version containing the security fix once verified.

Sometimes a critical vulnerability needs a 20-page exploit chain.

CVE-2026-90945 doesn’t.

The problem is brutally simple:

Crawlab uses "crawlab" as its JWT signing secret.

Not a generated secret.

Not an environment variable.

Not a deployment-specific key.

A literal string embedded in the application.

The vulnerability affects Crawlab through 0.6.3 and carries a CVSS 3.1 score of 9.8. CVSS 4.0 rates it 9.3. The CVE classifies the issue as CWE-321 — Use of Hard-coded Cryptographic Key.

And because JWTs are only as trustworthy as the key used to sign them, the authentication boundary collapses.

The secret isn’t secret

The security report published in Crawlab’s own GitHub issue tracker is unusually explicit.

The JWT service initializes its signing key as:

jwtSecret: "crawlab"

The same report states that although Crawlab contains SetJwtSecret and WithJwtSecret helpers, they are not actually called by the application. The effective secret therefore remains hard-coded.

That creates a nasty cryptographic failure.

With HMAC-SHA256, the server verifies that the JWT signature was generated using the shared secret.

If the secret is known, an attacker doesn’t need to steal a valid administrator session.

They can create another one.

The server has no reliable way to distinguish the forged token from a legitimate token because both carry a mathematically valid HMAC signature.

This is not brute force.

There is nothing to brute-force.

The key is already known.

How the authentication bypass works

The high-level attack path is straightforward:

Attacker → Crawlab API → forged JWT → administrator identity → admin API → worker task execution → code execution

The CVE record explicitly describes the vulnerability as an authentication bypass caused by the hard-coded HMAC-SHA256 secret. An unauthenticated attacker can forge valid administrator tokens and reach administrative APIs.

The GitHub issue provides additional technical detail.

Crawlab’s token verification uses the application’s jwtSecret when parsing the token. Because that value is fixed, an attacker who knows it can generate a valid signature for a crafted JWT.

That means the attacker doesn’t need:

• the administrator’s password;
• a stolen API key;
• a leaked session cookie;
• a database password;
• an existing privileged account.

The authentication mechanism itself can be forged.

The administrator identity is the real target

A JWT isn’t magic.

The attacker still needs a token that represents a useful identity.

The security report explains that the administrator’s MongoDB ObjectID can be obtained through information already exposed in JWT payloads or, on a fresh installation, through Crawlab’s default authentication setup.

That makes another important point:

Changing the default admin password does not repair this vulnerability.

The problem isn’t the password.

The problem is the signing key.

If the application continues validating tokens with the same hard-coded secret, a password change does not repair the cryptographic trust relationship.

This is why treating CVE-2026-90945 as a “change your password” issue would be completely inadequate.

Then comes the worker cluster

This is where the vulnerability stops being an authentication bug and becomes an infrastructure problem.

Crawlab is a distributed web-crawler management platform.

The master component manages crawler tasks and worker nodes.

Those workers execute spider jobs.

That architecture creates a dangerous privilege transition:

web authentication → administrative task control → code execution on workers

The vulnerability report states that an attacker who gains administrative access can use Crawlab’s ability to execute spider scripts on worker nodes, resulting in arbitrary remote code execution across the cluster.

The worker nodes are therefore part of the attack surface.

If they have access to:

• internal databases;
• Redis;
• MongoDB;
• cloud credentials;
• private APIs;
• internal DNS;
• source repositories;
• filesystem secrets;

then compromising Crawlab may become the first step rather than the final objective.

This is why exposed Crawlab instances are dangerous

The CVSS vector is:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Translated:

• Network: remotely reachable;
• Low complexity: no exotic attack conditions;
• No privileges: no legitimate account required;
• No interaction: no victim click;
• High confidentiality impact;
• High integrity impact;
• High availability impact.

The CVE record assigns exactly those characteristics.

For a distributed crawler platform, the combination makes sense.

Compromise the controller.

Control the jobs.

Reach the workers.

Run code.

The GitHub issue is even worse than the CVE summary

The public issue was opened on June 13, 2026 and explicitly titled:

“Hardcoded JWT Secret Allows Arbitrary Token Forgery and Full Admin Takeover.”

The issue describes the exact source location where the secret is initialized and explains how token verification uses it.

That matters because CVE descriptions are often intentionally short.

Here we have enough source-level evidence to understand the root cause without relying solely on a vulnerability aggregator.

The actual failure is architectural:

A cryptographic signing key that must be secret was treated like a static application constant.

Crawlab’s release history makes version checking important

Crawlab’s official repository currently lists v0.6.3 as its latest tagged release, while the CVE says versions through 0.6.3 are affected.

There is therefore an unpleasant deployment situation.

The normal advice — “upgrade to the latest version” — isn’t enough if the latest official release is itself within the affected range.

The vulnerability data references a security-fixing commit, but the public release information does not provide a clearly documented newer stable release that Bugstoday can safely identify as the fixed version.

So don’t invent a version number.

If you’re running Crawlab, check the upstream repository and security issue for the actual remediation state before assuming that upgrading to 0.6.3 solves anything.

It doesn’t.

Do not just rotate the password

This deserves repetition.

Changing:

admin / old-password

to:

admin / new-password

doesn’t fix a JWT signing secret embedded in application code.

Likewise, changing MongoDB credentials doesn’t repair the token-validation mechanism.

The problem exists before the application reaches normal password-based authorization.

If a forged administrator JWT is accepted, the attacker has already crossed that boundary.

What to do with an exposed instance

If Crawlab is reachable from the Internet, reduce exposure first.

Put the management interface behind:

• VPN;
• private network access;
• an authenticated reverse proxy;
• strict firewall rules;
• an allowlist of administrative networks.

Do not treat this as a permanent replacement for patching.

It’s containment.

If the instance has been publicly reachable while vulnerable, assume the authentication boundary may have been bypassable.

That means the incident-response question becomes:

What could an attacker have reached after obtaining administrator access?

Hunt for forged administrative activity

Look for unusual:

• administrator logins;
• JWT authentication events;
• newly created users;
• privilege changes;
• spider creation;
• spider modification;
• unexpected task execution;
• new worker registrations;
• unusual worker commands;
• outbound network connections from workers;
• filesystem changes;
• credential access;
• MongoDB activity;
• Redis activity.

The most interesting telemetry may not exist on Crawlab itself.

It may be sitting on the worker nodes.

If an attacker used Crawlab to launch a malicious spider, the controller may show a legitimate-looking task while the actual malicious behavior occurs on the worker.

Don’t assume changing the JWT secret is supported

The code contains helpers for setting the JWT secret, but the security report explicitly notes that those mechanisms are not actually wired into the application’s initialization path.

That distinction matters.

Finding a SetJwtSecret() function in source code and assuming:

“I’ll just configure it.”

is not the same as verifying that production startup actually uses it.

Until a fixed release or documented patch changes the authentication implementation, administrators should not rely on configuration folklore.

What a proper fix needs to accomplish

A real remediation needs to break the static trust relationship.

At minimum, the application needs:

1. a deployment-specific secret;
2. secure secret injection;
3. no universal default signing key;
4. proper key rotation;
5. secure initialization;
6. token invalidation after compromise;
7. protection against forged administrator identities.

And if an instance has already been exposed while vulnerable, simply deploying corrected code may not be enough.

Existing credentials and secrets accessible from the compromised environment should be rotated.

That includes:

• cloud credentials;
• database passwords;
• API tokens;
• repository credentials;
• SSH keys;
• service-account secrets.

The vulnerability gives an attacker a route into the application.

What they can steal after that depends on the environment.

Is it actively exploited?

This is where the reporting needs some discipline.

One commercial vulnerability feed currently claims exploitation has been observed, but the primary CVE record does not document confirmed exploitation, and the vulnerability is not currently confirmed in the CISA KEV data reviewed for this article.

Bugstoday therefore isn’t going to turn an unverified third-party threat-intelligence claim into:

“Crawlab is being actively exploited.”

What we can say with confidence is more useful:

The authentication bypass is remotely reachable, requires no privileges according to the CVSS vector, and the signing secret is hard-coded in the affected application.

That’s already enough to justify immediate exposure reduction.

Bugstoday’s take

This is the kind of vulnerability that makes security engineers stare at the code and ask:

How did "crawlab" become a production cryptographic key?

The scary part isn’t the sophistication.

There isn’t much.

The attacker doesn’t need to break HMAC-SHA256. They don’t need to find a side-channel. They don’t need to crack a password.

They need to know the key.

And the key is sitting in the application source.

Once the attacker gets administrator-level JWT authentication, Crawlab’s distributed architecture does the rest: management API, crawler jobs, worker nodes, arbitrary code execution.

If you expose Crawlab to the Internet, don’t wait for a polished exploit to appear.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

• MITRE/CVE — CVE-2026-90945.
• Crawlab GitHub repository — source and release history.
• Crawlab GitHub Issue #1622 — hard-coded JWT secret technical disclosure.
• OSV — CVE-2026-90945 affected/fixed commit metadata.
• NVD — CVE-2026-90945.