Post cover image

July 6, 2026

CVE-2026–38075: API keys remained valid after account suspension in RocketAdmin

Advisory details

By Prath

4 min read

Advisory details

CVE: CVE-2026–38075 Product: RocketAdmin Affected versions: 1.6.10 and earlier Vulnerability type: Improper Access Control CWE: CWE-284 Researcher-assessed severity: High CVSS v3.1: 8.1 CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N Researcher: Prathamesh Bagul Vendor status: Acknowledged and fixed

Summary

RocketAdmin 1.6.10 and earlier contained an improper access control vulnerability in its API key authentication middleware.

When an administrator suspended a user account, RocketAdmin blocked password-based authentication. API keys that had already been issued to that user remained valid.

A suspended user who still possessed an API key could continue accessing protected API endpoints. The key retained the permissions of the associated account.

The issue did not grant new privileges. It prevented account suspension from fully revoking existing access.

RocketAdmin acknowledged the report, confirmed that the issue had been fixed, and authorized the researcher to request a CVE identifier. The CVE Assignment Team assigned CVE-2026–38075.

Vulnerability description

RocketAdmin supports API keys as an authentication method.

An active user can generate an API key and use it to access protected endpoints. RocketAdmin resolves the key to a user account and applies the permissions associated with that user.

The application also allows administrators to suspend accounts.

Suspension correctly prevented the affected user from signing in with a password. The API key authentication path did not apply the same account-status check.

As a result, the following two authentication paths behaved differently:

Authentication methodResult after account suspensionPassword authenticationRejectedExisting API keyAccepted

This made account suspension incomplete.

Affected component

The vulnerable logic was located in:

backend/src/authorization/auth-with-api.middleware.ts

The relevant method was:

authenticateWithApiKey

Technical root cause

The middleware retrieved the user associated with the supplied API key:

const foundUserByApiKey = await this.userRepository
  .createQueryBuilder('user')
  .innerJoinAndSelect('user.api_keys', 'api_key')
  .where('api_key.hash = :hash', { hash: apiKeyHash })
  .getOne();

if (!foundUserByApiKey) {
  throw new NotFoundException(Messages.NO_AUTH_KEYS_FOUND);
}

req.decoded = {
  sub: foundUserByApiKey.id,
  email: foundUserByApiKey.email,
};

This code verified that the API key existed and belonged to a user.

It then populated the authenticated request identity using the associated user record.

The middleware did not check whether that user was currently suspended before accepting the key.

The authentication decision therefore depended on the validity of the API key, but not on the current status of the account behind it.

Preconditions

Exploitation required:

  1. A valid RocketAdmin user account.
  2. An API key issued while that account was active.
  3. The account to be suspended without the API key being revoked.

An attacker could also satisfy these conditions by compromising an account and creating an API key before the account was suspended.

Proof of concept

The vulnerability was reproduced in an authorized local RocketAdmin 1.6.10 environment.

No production deployment or customer data was used.

1. Authenticate as an active user

POST /api/user/login
Content-Type: application/json

{
  "email": "user@example.com",
  "password": "password123"
}

2. Create an API key

POST /api/apikey
Cookie: rocketadmin_cookie=<SESSION_TOKEN>
Content-Type: application/json

{
  "title": "Suspension Test"
}

Example response:

{
  "hash": "sk_REDACTED",
  "title": "Suspension Test"
}

3. Verify that the API key works

GET /api/connections
x-api-key: sk_REDACTED

Observed response:

HTTP/1.1 200 OK

This was expected because the user account was active.

4. Suspend the associated account

In the local test environment, the account was marked as suspended:

UPDATE "user"
SET suspended = true
WHERE email = 'user@example.com';

Password-based authentication was rejected after this change.

5. Reuse the existing API key

GET /api/connections
x-api-key: sk_REDACTED

Expected response:

HTTP/1.1 401 Unauthorized

Observed response:

HTTP/1.1 200 OK

The previously issued API key continued to authenticate the suspended user.

Security impact

The vulnerability allowed a suspended account to retain API access.

The practical impact depended on the role and permissions of the affected user. The key did not automatically provide administrative privileges.

A regular user's key retained the permissions assigned to that user. An administrative user's key could preserve broader administrative access.

Possible consequences included:

  • Continued access by suspended or terminated users
  • Persistence after account compromise
  • Continued access to protected database connections
  • Unauthorized reading of data available to the affected account
  • Unauthorized modification of resources where the account had write permission
  • Incomplete containment during incident response
  • Failure to enforce internal offboarding and access-revocation procedures

Example attack scenarios

Suspended employee

An employee generates an API key while their account is active.

The organization later suspends the employee's RocketAdmin account during offboarding. Password login stops working, but the previously issued key remains valid.

The former employee can continue using the API until the key is separately revoked.

Compromised account

An attacker gains access to a RocketAdmin account and creates an API key.

The compromise is detected, and the account is suspended. The security team assumes that suspension has contained the incident.

The attacker's API key remains valid and continues providing the permissions associated with the compromised account.

CVSS assessment

The researcher-assessed CVSS v3.1 score is 8.1 High:

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

Metric rationale

Attack Vector: Network

The API key can be used through remotely reachable HTTP endpoints.

Attack Complexity: Low

The attack does not require a race condition, unusual timing, or a specific deployment mistake.

Privileges Required: Low

The attacker must possess a valid API key issued while the account was active.

User Interaction: None

No action from another user is required.

Scope: Unchanged

The impact remains within RocketAdmin's security authority.

Confidentiality: High

The retained account may continue accessing sensitive information available through RocketAdmin.

Integrity: High

Users with write permissions may continue modifying accessible resources.

Availability: None

The demonstrated vulnerability did not independently establish an availability impact.

The environmental severity may vary according to the permissions of the affected account and the sensitivity of the connected data sources.

Remediation

RocketAdmin confirmed that the issue was fixed.

The API key authentication path should reject a key when the associated account is suspended or otherwise prohibited from authenticating.

A simplified check would look like this:

if (!foundUserByApiKey) {
  throw new UnauthorizedException('Invalid API key');
}

if (foundUserByApiKey.suspended) {
  throw new UnauthorizedException('User account is suspended');
}

If RocketAdmin supports additional account states, such as disabled, deleted, or inactive, the same authentication path should validate those states before accepting the key.

Credential validity and account validity should be treated as separate checks.

A credential can be correctly signed, correctly stored, and correctly associated with a user while still being invalid for authentication because the user is no longer permitted to access the system.

Additional defensive controls

Applications that support API keys should consider revoking all active credentials when an account is suspended.

Administrators should also have a single action that revokes:

  • API keys
  • Active sessions
  • Refresh tokens
  • Personal access tokens
  • Other persistent credentials

Authentication logs should record API key usage, revocation attempts, and requests made by inactive accounts.

Automated tests should verify that every supported credential type stops working after account suspension.

Affected and fixed versions

CVE-2026–38075 affects:

RocketAdmin 1.6.10 and earlier

The vulnerability was confirmed in version 1.6.10.

RocketAdmin stated that it had implemented a fix. The first release containing the fix was not identified in a public vendor reference provided to the researcher.

Users should upgrade to the latest available RocketAdmin release and verify that API keys associated with suspended accounts are rejected.

Researcher credit

CVE-2026–38075 was discovered and responsibly disclosed by:

Prathamesh Bagul Offensive security researcher

RocketAdmin is credited for acknowledging the report and implementing a fix.

CVE.org record for CVE-2026–38075