CVE-2026-62241: Hard-Coded JWT Secret Enables Session Forgery
TL;DR -
clawvetself-hostedapps/apibefore 0.7.5 uses a known fallback JWT secret. - Attackers can pulluserIdvalues from an unauthenticated endpoint and forgecg_sessioncookies offline. - Upgrade to 0.7.5 immediately and rotate JWT secrets, sessions, and exposed API keys.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-62241 |
| CVSS score | 9.1 |
| Attack vector | Network |
| Auth required | No |
| Patch available | Yes, upgrade to 0.7.5 |
CVE-2026-62241 is a critical authentication and session forgery issue in the clawvet self-hosted API server component, specifically apps/api before version 0.7.5. The issue is notable because it combines two weaknesses into a practical attack chain: a hard-coded fallback JWT secret and an unauthenticated endpoint that discloses userId values. Together, those conditions allow a remote attacker to mint a valid session cookie without first compromising credentials.
From a defender perspective, this is more than a theoretical JWT hygiene problem. The public description states that a forged session can be used against GET /api/v1/auth/me to retrieve victim account details including email address, subscription plan, and a secret apiKey. Even without confirmed in-the-wild exploitation, the prerequisites are so minimal that exposed self-hosted instances should be treated as high priority for remediation and review.
What Is This Vulnerability?
The root cause is a compound design and implementation failure in authentication and data exposure controls. According to the published description, clawvet apps/api hard-codes a fallback JWT secret, clawvet-dev-secret-change-me, in auth.ts, and the same value is also shipped as the default in .env.example. If that fallback is reachable in production code paths, an attacker does not need to guess or crack the signing key used to verify session tokens.
That weakness alone would already be serious, but the exploit chain becomes practical because GET /api/v1/scans reportedly returns scan records containing userId values without authentication. In other words, the application exposes the identifier needed to impersonate another account and also makes the JWT signing secret predictable. An attacker can therefore harvest a victim userId, generate an HS256 cg_session cookie offline using the known secret, and then present that cookie to the application as if it were a legitimate authenticated session.
The impact flows from trust in the forged cookie. Once the application accepts the attacker-supplied session, the attacker can call GET /api/v1/auth/me and retrieve sensitive account-level data. The available description specifically mentions exposure of the victim’s email address, subscription plan, and secret apiKey. In many environments, API keys are far more operationally sensitive than profile data because they can enable follow-on access, automation abuse, or integration compromise.
Technical Notes
The published attack chain references these application elements:
Fallback JWT secret: clawvet-dev-secret-change-me
Unauthenticated endpoint: GET /api/v1/scans
Post-forgery endpoint: GET /api/v1/auth/me
Cookie name: cg_session
JWT algorithm: HS256
A generic representation of the attack flow is:
1. Request /api/v1/scans without authentication
2. Extract a victim userId from returned scan records
3. Create an HS256 JWT signed with the known fallback secret
4. Set the forged JWT as the cg_session cookie
5. Request /api/v1/auth/me
6. Receive victim account metadata and secret apiKey
Who Is Affected?
The affected product is the self-hosted clawvet API server component, identified as apps/api, in versions before 0.7.5. That means any self-hosted deployment running 0.7.4 or earlier should be assumed vulnerable unless there is verifiable evidence that the vulnerable code path was removed or independently patched. The fixed version number stated in the available records is 0.7.5.
It is important to be precise about scope. The published clawvet npm package, described as the CLI only, is explicitly stated as not affected. That matters for triage because some organizations may use the CLI package in developer workflows while separately operating the self-hosted API server. The server-side component is the exposure point here, not the standalone npm-distributed CLI.
If you are unsure whether your deployment includes the vulnerable component, start by identifying whether you run the self-hosted application stack with an apps/api service. In the absence of more detailed vendor release notes in the source material, defenders should assume any internet-reachable self-hosted apps/api instance below 0.7.5 is exploitable and should be prioritized accordingly.
| Product | Component | Affected versions | Fixed version | Notes |
|---|---|---|---|---|
| clawvet | self-hosted API server (apps/api) |
before 0.7.5 |
0.7.5 |
Vulnerable |
| clawvet npm package | CLI only | not affected | n/a | Explicitly not affected |
Technical Notes
Useful version-check approaches will depend on how you deployed clawvet. Common checks include package manifests, container tags, or application startup logs.
# Example: inspect a local package manifest
grep -R "version" apps/api/package.json
# Example: if deployed via container, inspect image tags
docker ps --format "table {{.Names}} {{.Image}}"
docker inspect <container_name_or_id> | grep -i image
# Example: if source-managed through git
git describe --tags
git rev-parse HEAD
CVSS Score Breakdown
The published base score is 9.1, which places this issue firmly in critical territory. A CVSS vector string was not available in the provided record, so defenders should avoid inventing exact subcomponent values. Still, the score is consistent with what the description tells us: the issue is remotely reachable, does not require prior authentication, and exposes sensitive data through session impersonation.
The most important practical interpretation of the 9.1 score is that exploitability is high even if public exploit code is not yet widely circulated. The attacker does not need valid credentials, local access, or user interaction. The required inputs are obtainable from the application itself if the unauthenticated scan endpoint is exposed as described. That combination sharply lowers the effort needed to exploit the flaw and raises the urgency for external-facing deployments.
Because the vector string is unavailable in the source data, security teams should not overfit their risk model to assumed CVSS dimensions. Instead, anchor on the observed properties: network exposure, no authentication requirement, direct access to secret-bearing account data, and likely potential for follow-on abuse through exposed API keys.
| CVSS element | What we can state with confidence |
|---|---|
| Base score | 9.1 |
| Severity | Critical |
| Vector string | Not provided in the available NVD output |
| Attack path implication | Remote, unauthenticated exploitation is described |
| Business impact | Exposure of account data and secret API keys |
Technical Notes
In the absence of a published vector string, document the uncertainty explicitly in internal tickets or change records:
CVSS base score confirmed: 9.1
CVSS vector string: not available in source record at time of review
Defender assumption: treat as remotely exploitable, no-auth, high confidentiality impact
Exploitation Status
At the time of the available research, no confirmed in-the-wild exploitation was established from the cited sources. The CVE is not listed in the CISA Known Exploited Vulnerabilities catalog, which means there is no KEV entry indicating confirmed exploitation for federal prioritization purposes. That said, absence from KEV is not evidence of safety. Many readily exploitable issues are abused before they appear in formal catalogs, and some never receive a KEV listing despite active opportunistic scanning.
Also based on the available research, no direct public proof-of-concept repository was confirmed in the retrieved references. That is an important distinction: defenders should say “no confirmed public PoC found in reviewed sources” rather than “no PoC exists.” Given the quality of the public technical description, a capable attacker would not need much additional information to reproduce the exploit chain.
The prudent security assumption is therefore: exploitation is not confirmed, a public PoC is not confirmed from the reviewed sources, but the issue is highly actionable because the JWT secret is known and the user identifier can reportedly be obtained without authentication. This is exactly the kind of vulnerability that can move from disclosure to opportunistic exploitation quickly.
| Question | Status |
|---|---|
| Public PoC confirmed? | No confirmed public PoC in reviewed sources |
| Active exploitation confirmed? | No confirmed in-the-wild exploitation in reviewed sources |
| In CISA KEV? | No |
| Practical exploitability | High, based on published technical details |
Technical Notes
Track for changes in status after disclosure:
Monitor:
- NVD change history
- CISA KEV additions
- Vendor advisory updates
- GitHub searches for CVE-2026-62241 and clawvet session forgery
How to Detect It
Detection should focus on the described attack sequence: unauthenticated access to GET /api/v1/scans, followed by requests to GET /api/v1/auth/me carrying a cg_session cookie that may not correspond to a legitimate login flow. If your application or reverse proxy logs include request paths, response codes, source IPs, and headers or cookie metadata, you can often identify suspicious pairings quickly.
A strong signal is repeated anonymous enumeration of /api/v1/scans, especially from internet IPs that do not typically use the application, followed soon after by access to /api/v1/auth/me. Another useful signal is any sudden access to /api/v1/auth/me from clients that have no preceding authentication events in your normal telemetry. Since the token can be forged offline, there may be no login attempt, no password reset, and no MFA event associated with the session.
Because the public description says the attack exposes secret API keys, defenders should also review whether any extracted keys were subsequently used from new IP ranges, autonomous systems, geographies, or user agents. If the API keys permit downstream service use, those logs may provide better compromise confirmation than application logs alone.
Technical Notes
Example path-based web log patterns to investigate:
GET /api/v1/scans
GET /api/v1/auth/me
Cookie: cg_session=
Example grep workflow against reverse proxy or app logs:
grep -E 'GET /api/v1/(scans|auth/me)' /var/log/nginx/access.log
# Look for auth/me access patterns
grep 'GET /api/v1/auth/me' /var/log/nginx/access.log
# If cookie logging is enabled, search for cg_session
grep 'cg_session=' /var/log/nginx/access.log
Example Splunk query:
index=web sourcetype=access_combined
(uri_path="/api/v1/scans" OR uri_path="/api/v1/auth/me")
| stats count min(_time) as first max(_time) as last values(status) values(clientip) values(user_agent) by uri_path, clientip
| sort - last
Example Elasticsearch / Kibana KQL:
url.path : "/api/v1/scans" or url.path : "/api/v1/auth/me"
Example Sigma-style logic sketch for investigation:
title: Possible clawvet CVE-2026-62241 exploitation sequence
logsource:
category: webserver
detection:
selection_scans:
cs-uri-stem: "/api/v1/scans"
cs-method: "GET"
selection_me:
cs-uri-stem: "/api/v1/auth/me"
cs-method: "GET"
condition: selection_scans or selection_me
level: medium
If your logs do not currently capture these paths or cookie presence, assume detection coverage is incomplete. In that case, patch first, then improve telemetry.
Mitigation and Patching
The primary remediation is to upgrade the clawvet self-hosted API server (apps/api) to version 0.7.5 or later. This is the only fixed version boundary that can be stated confidently from the available records. If you operate a vulnerable version below 0.7.5, patching should be treated as urgent, especially for internet-exposed deployments.
Patching alone is not enough if the instance was reachable while vulnerable. Because the fallback JWT secret was known and the attack includes session forgery, defenders should also rotate JWT secrets, invalidate existing sessions, and rotate potentially exposed user API keys. If any users had their apiKey exposed via a forged /api/v1/auth/me request, those keys should be considered compromised. Review access logs for evidence of abuse, but do not wait for perfect confirmation before rotating secrets.
If immediate upgrade is not operationally possible, temporary workarounds should focus on breaking the documented chain. Restrict external access to the self-hosted API, block unauthenticated access to GET /api/v1/scans if feasible, and ensure the application is not using the known fallback JWT secret in any production path. These are temporary containment measures, not substitutes for upgrading to 0.7.5.
Technical Notes
Specific upgrade and containment examples will vary by deployment method. Use the one that matches your environment.
# Example: source-based/node deployment
# Update to the fixed release and reinstall dependencies
git fetch --tags
git checkout 0.7.5
cd apps/api
npm install
npm run build
# Example: if managed with npm in a package-based workflow
npm install clawvet@0.7.5
# Example: restart the service after upgrade
systemctl restart clawvet-api
# Or with Docker Compose
docker compose pull
docker compose up -d
Rotate the JWT secret and invalidate sessions. Exact variable names may differ by deployment, so verify your configuration before change:
# Generate a new random secret
openssl rand -hex 32
Example .env hardening concept:
# Do not use known defaults
JWT_SECRET=<new-random-secret>
Temporary reverse-proxy block for the unauthenticated endpoint if you cannot patch immediately:
location = /api/v1/scans {
deny all;
return 403;
}
Post-remediation checklist:
1. Upgrade apps/api to 0.7.5 or later
2. Replace any default or fallback JWT secret
3. Invalidate all existing sessions/cookies
4. Rotate potentially exposed user apiKeys
5. Review logs for /api/v1/scans and /api/v1/auth/me access
6. Confirm the published clawvet CLI package is not in scope for this server-side issue
References
The primary public references for CVE-2026-62241 align on the affected component, affected versions, and the attack chain. The NVD record provides the most concise consolidated description and confirms the fixed version boundary of 0.7.5. The CVE.org entry and the GitHub Security Advisory help validate product naming and advisory provenance, while the VulnCheck advisory title corroborates the vulnerability class and affected range.
For defenders documenting remediation, it is worth preserving both the NVD summary and the project advisory URL in change records. The available public material is sufficient to justify emergency patching for exposed self-hosted clawvet API instances even without a published public PoC or confirmed KEV listing.
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-62241
- CVE.org: https://www.cve.org/CVERecord?id=CVE-2026-62241
- GitHub Security Advisory: https://github.com/MohibShaikh/clawvet/security/advisories/GHSA-9mww-p953-jfc9
- VulnCheck advisory: https://www.vulncheck.com/advisories/clawvet-hard-coded-jwt-secret-session-forgery
- CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
For further insights on incident response, refer to our guide on incident response for network appliances and best practices in Linux patch management.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.