Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

5732 vulnerabilities reference this CWE, most recent first.

GHSA-9FG6-4JC3-M2X8

Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2022-05-24 17:40
VLAI
Details

newbee-mall all versions are affected by incorrect access control to remotely gain privileges through NewBeeMallIndexConfigServiceImpl.java. Unauthorized changes can be made to any user information through the userID.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-23449"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-26T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "newbee-mall all versions are affected by incorrect access control to remotely gain privileges through NewBeeMallIndexConfigServiceImpl.java. Unauthorized changes can be made to any user information through the userID.",
  "id": "GHSA-9fg6-4jc3-m2x8",
  "modified": "2022-05-24T17:40:06Z",
  "published": "2022-05-24T17:40:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-23449"
    },
    {
      "type": "WEB",
      "url": "https://github.com/newbee-ltd/newbee-mall/issues/35"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9FHM-53XW-H9C3

Vulnerability from github – Published: 2026-07-21 21:32 – Updated: 2026-07-21 21:32
VLAI
Details

Incorrect Authorization (CWE-863) in Elasticsearch can allow an authenticated user with limited index privileges to exploit insufficient authorization controls in the ingest simulation feature. By targeting indices they are not authorized to access directly, the user can cause those indices' configured ingest pipelines to execute and return their output, potentially disclosing data processed or enriched by those pipelines. Additionally, the same feature can be used to retrieve index mapping metadata for indices the user are not authorized to access directly.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-56144"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T20:17:02Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect Authorization (CWE-863) in Elasticsearch can allow an authenticated user with limited index privileges to exploit insufficient authorization controls in the ingest simulation feature. By targeting indices they are not authorized to access directly, the user can cause those indices\u0027 configured ingest pipelines to execute and return their output, potentially disclosing data processed or enriched by those pipelines. Additionally, the same feature can be used to retrieve index mapping metadata for indices the user are not authorized to access directly.",
  "id": "GHSA-9fhm-53xw-h9c3",
  "modified": "2026-07-21T21:32:40Z",
  "published": "2026-07-21T21:32:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56144"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/elasticsearch-8-19-18-9-3-7-9-4-4-security-update-esa-2026-56/388555"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9G2Q-W3W2-VF7Q

Vulnerability from github – Published: 2026-05-06 18:28 – Updated: 2026-05-06 18:28
VLAI
Summary
Kimai has Missing Voter Check that Allows Cross-Team Timesheet Manipulation
Details

Summary

Any ROLE_TEAMLEAD user can enumerate, read, modify, and permanently delete timesheets belonging to any other user in the system — regardless of team membership. This enables data destruction (deleted billable hours), data tampering (forged timesheet durations), and full authorization bypass on timesheet resources. Verified against Kimai 2.52.0.

Details

TimesheetVoter::voteOnAttribute() maps permissions to own_timesheet or other_timesheet without checking team membership. The voter's own comment confirms this is a known gap:

// extend me for "team" support later on
if ($subject->getUser()?->getId() === $user->getId()) {
    $permission .= 'own';
} else {
    $permission .= 'other';
}

PoC

Tested against Kimai 2.52.0 Docker instance.

Setup: - User A (usera, ROLE_TEAMLEAD) owns timesheet ID 2 with description "Private timesheet - UserA only" - User B (userb, ROLE_TEAMLEAD) is NOT on any team with User A

User B reads User A's timesheet data:

GET /api/timesheets/2 HTTP/1.1
X-AUTH-USER: userb
X-AUTH-TOKEN: <userb_api_token>

Response: HTTP 200 — returns full timesheet record including description "Private timesheet - UserA only".

User B deletes User A's timesheet:

DELETE /api/timesheets/3 HTTP/1.1
X-AUTH-USER: userb
X-AUTH-TOKEN: <userb_api_token>

Response: HTTP 204 No Content — timesheet permanently deleted.

User B tampers User A's timesheet:

PATCH /api/timesheets/6 HTTP/1.1
X-AUTH-USER: userb
X-AUTH-TOKEN: <userb_api_token>
Content-Type: application/json

{"begin":"2026-03-24T08:00:00","end":"2026-03-24T18:00:00","project":1,"activity":1,"description":"TAMPERED","exported":false,"billable":false}

Response: HTTP 200 OK — duration inflated from 3600s to 36000s, description overwritten.

Note: ROLE_USER (userc) is correctly blocked — DELETE returns 403 and the actions endpoint returns an empty array. The vulnerability only affects ROLE_TEAMLEAD and above. Timesheet IDs are sequential integers, trivially enumerable.

Impact

Any authenticated user with ROLE_TEAMLEAD or above can:

  1. Permanently delete timesheets belonging to any user system-wide — destroying billable hours, payroll data, and project billing history
  2. Silently alter timesheet descriptions, hours, and billing flags — forging hours up or down, directly affecting invoicing and payroll
  3. Enumerate all timesheet IDs (sequential integers) and access action metadata for arbitrary records

No user interaction required. ROLE_USER accounts are correctly restricted; the vulnerability is specific to ROLE_TEAMLEAD receiving global scope instead of team-scoped access.

Maintainers answer: why this is not eligible for a CVE

The behavior described matches the documented permission model. Per the Kimai documentation, the relevant permissions granted to ROLE_TEAMLEAD are:

  • edit_other_timesheet — Edit existing records of other users
  • delete_other_timesheet — Delete existing records of other users

These permissions were global by design, not team-scoped. The UI surfaces only the teamlead's own team timesheets, but the API has historically honored these permissions as documented: a role holding *_other_timesheet can act on any other user's timesheet. The inline comment // extend me for "team" support later on reflects this accurately — team-scoped enforcement was a planned enhancement, not a security control that existed and failed.

The report frames this as authorization bypass, but no authorization boundary is being crossed: ROLE_TEAMLEAD is operating within its documented permissions.

Kimai acknowledges that this behavior might not be expected, so while it will be treated as a feature request for team-scoped permission enforcement and not a vulnerability, it still track it as having security implications.

Solution

Team-scoped timesheet permission checks were added in 2.56.0.

Operators of Kimai <= 2.55 who need stricter isolation between teamleads should not grant ROLE_TEAMLEAD to users who must not act on other teams' timesheets.

Severity
5.7 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.55.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "kimai/kimai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.56.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T18:28:45Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nAny ROLE_TEAMLEAD user can enumerate, read, modify, and permanently delete timesheets belonging to any other user in the system \u2014 regardless of team membership. This enables data destruction (deleted billable hours), data tampering (forged timesheet durations), and full authorization bypass on timesheet resources. Verified against Kimai 2.52.0.\n\n### Details\n\n`TimesheetVoter::voteOnAttribute()` maps permissions to `own_timesheet` or `other_timesheet` without checking team membership. The voter\u0027s own comment confirms this is a known gap:\n\n```php\n// extend me for \"team\" support later on\nif ($subject-\u003egetUser()?-\u003egetId() === $user-\u003egetId()) {\n    $permission .= \u0027own\u0027;\n} else {\n    $permission .= \u0027other\u0027;\n}\n```\n\n### PoC\n\nTested against Kimai 2.52.0 Docker instance.\n\nSetup:\n- User A (usera, ROLE_TEAMLEAD) owns timesheet ID 2 with description \"Private timesheet - UserA only\"\n- User B (userb, ROLE_TEAMLEAD) is NOT on any team with User A\n\n**User B reads User A\u0027s timesheet data:**\n\n```\nGET /api/timesheets/2 HTTP/1.1\nX-AUTH-USER: userb\nX-AUTH-TOKEN: \u003cuserb_api_token\u003e\n```\n\nResponse: HTTP 200 \u2014 returns full timesheet record including description \"Private timesheet - UserA only\".\n\n**User B deletes User A\u0027s timesheet:**\n\n```\nDELETE /api/timesheets/3 HTTP/1.1\nX-AUTH-USER: userb\nX-AUTH-TOKEN: \u003cuserb_api_token\u003e\n```\n\nResponse: HTTP 204 No Content \u2014 timesheet permanently deleted.\n\n**User B tampers User A\u0027s timesheet:**\n\n```\nPATCH /api/timesheets/6 HTTP/1.1\nX-AUTH-USER: userb\nX-AUTH-TOKEN: \u003cuserb_api_token\u003e\nContent-Type: application/json\n\n{\"begin\":\"2026-03-24T08:00:00\",\"end\":\"2026-03-24T18:00:00\",\"project\":1,\"activity\":1,\"description\":\"TAMPERED\",\"exported\":false,\"billable\":false}\n```\n\nResponse: HTTP 200 OK \u2014 duration inflated from 3600s to 36000s, description overwritten.\n\n**Note:** ROLE_USER (userc) is correctly blocked \u2014 DELETE returns 403 and the actions endpoint returns an empty array. The vulnerability only affects ROLE_TEAMLEAD and above. Timesheet IDs are sequential integers, trivially enumerable.\n\n### Impact\n\nAny authenticated user with ROLE_TEAMLEAD or above can:\n\n1. Permanently delete timesheets belonging to any user system-wide \u2014 destroying billable hours, payroll data, and project billing history\n2. Silently alter timesheet descriptions, hours, and billing flags \u2014 forging hours up or down, directly affecting invoicing and payroll\n3. Enumerate all timesheet IDs (sequential integers) and access action metadata for arbitrary records\n\nNo user interaction required. ROLE_USER accounts are correctly restricted; the vulnerability is specific to ROLE_TEAMLEAD receiving global scope instead of team-scoped access.\n\n### Maintainers answer: why this is not eligible for a CVE\n\nThe behavior described matches the documented permission model. Per the Kimai documentation, the relevant permissions granted to `ROLE_TEAMLEAD` are:\n\n- `edit_other_timesheet` \u2014 Edit existing records of other users\n- `delete_other_timesheet` \u2014 Delete existing records of other users\n\nThese permissions were global by design, not team-scoped. The UI surfaces only the teamlead\u0027s own team timesheets, but the API has historically honored these permissions as documented: a role holding `*_other_timesheet` can act on any other user\u0027s timesheet. The inline comment `// extend me for \"team\" support later on` reflects this accurately \u2014 team-scoped enforcement was a planned enhancement, not a security control that existed and failed.\n\nThe report frames this as authorization bypass, but no authorization boundary is being crossed: `ROLE_TEAMLEAD` is operating within its documented permissions.\n\nKimai acknowledges that this behavior might not be expected, so while it will be treated as a feature request for team-scoped permission enforcement and not a vulnerability, it still track it as having security implications.\n\n### Solution\n\nTeam-scoped timesheet permission checks were added in 2.56.0.\n\nOperators of Kimai \u003c= 2.55 who need stricter isolation between teamleads should not grant `ROLE_TEAMLEAD` to users who must not act on other teams\u0027 timesheets.",
  "id": "GHSA-9g2q-w3w2-vf7q",
  "modified": "2026-05-06T18:28:46Z",
  "published": "2026-05-06T18:28:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kimai/kimai/security/advisories/GHSA-9g2q-w3w2-vf7q"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kimai/kimai"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kimai has Missing Voter Check that Allows Cross-Team Timesheet Manipulation"
}

GHSA-9G39-JGF9-9MXX

Vulnerability from github – Published: 2022-05-24 17:14 – Updated: 2022-05-24 17:14
VLAI
Details

A remote authenticated authorization-bypass vulnerability in Wowza Streaming Engine 4.7.8 (build 20191105123929) allows any read-only user to issue requests to the administration panel in order to change functionality. For example, a read-only user may activate the Java JMX port in unauthenticated mode and execute OS commands under root privileges.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-9004"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-14T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "A remote authenticated authorization-bypass vulnerability in Wowza Streaming Engine 4.7.8 (build 20191105123929) allows any read-only user to issue requests to the administration panel in order to change functionality. For example, a read-only user may activate the Java JMX port in unauthenticated mode and execute OS commands under root privileges.",
  "id": "GHSA-9g39-jgf9-9mxx",
  "modified": "2022-05-24T17:14:18Z",
  "published": "2022-05-24T17:14:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9004"
    },
    {
      "type": "WEB",
      "url": "https://github.com/DrunkenShells/Disclosures/tree/master/CVE-2020-9004-Authenticated%20Remote%20Authorization%20Bypass%20Leading%20to%20RCE-Wowza"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/WowzaMediaSystems/public_cve/main/wowza-streaming-engine/CVE-2020-9004.txt"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/WowzaMediaSystems/public_cve/master/wowza-streaming-engine/CVE-2020-9004.txt"
    },
    {
      "type": "WEB",
      "url": "https://www.wowza.com/docs/wowza-streaming-engine-4-8-5-release-notes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9G52-R87C-973Q

Vulnerability from github – Published: 2024-12-04 03:31 – Updated: 2024-12-04 03:31
VLAI
Details

A vulnerability in Veeam Backup & Replication allows a low-privileged user to start an agent remotely in server mode and obtain credentials, effectively escalating privileges to system-level access. This allows the attacker to upload files to the server with elevated privileges. The vulnerability exists because remote calls bypass permission checks, leading to full system compromise.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-42452"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-04T02:15:04Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in Veeam Backup \u0026 Replication allows a low-privileged user to start an agent remotely in server mode and obtain credentials, effectively escalating privileges to system-level access. This allows the attacker to upload files to the server with elevated privileges. The vulnerability exists because remote calls bypass permission checks, leading to full system compromise.",
  "id": "GHSA-9g52-r87c-973q",
  "modified": "2024-12-04T03:31:15Z",
  "published": "2024-12-04T03:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42452"
    },
    {
      "type": "WEB",
      "url": "https://www.veeam.com/kb4693"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9G7M-MW8W-MQC5

Vulnerability from github – Published: 2022-05-24 17:24 – Updated: 2022-05-24 17:24
VLAI
Details

OMERO.server before 5.6.1 allows attackers to bypass the security filters and access hidden objects via a crafted query.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-16244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-22T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "OMERO.server before 5.6.1 allows attackers to bypass the security filters and access hidden objects via a crafted query.",
  "id": "GHSA-9g7m-mw8w-mqc5",
  "modified": "2022-05-24T17:24:01Z",
  "published": "2022-05-24T17:24:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16244"
    },
    {
      "type": "WEB",
      "url": "https://www.openmicroscopy.org/security/advisories/2019-SV5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9GF3-6WPF-HGPX

Vulnerability from github – Published: 2023-02-14 21:30 – Updated: 2025-10-22 00:32
VLAI
Details

Microsoft Publisher Security Features Bypass Vulnerability

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-21715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-14T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Microsoft Publisher Security Features Bypass Vulnerability",
  "id": "GHSA-9gf3-6wpf-hgpx",
  "modified": "2025-10-22T00:32:41Z",
  "published": "2023-02-14T21:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21715"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21715"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-21715"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9GG4-742M-CC8X

Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2025-05-30 18:30
VLAI
Details

An issue was discovered in Vaultize Enterprise File Sharing 17.05.31. There is improper authorization leading to creation of folders within another account via a modified device value.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-10212"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-04-25T18:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Vaultize Enterprise File Sharing 17.05.31. There is improper authorization leading to creation of folders within another account via a modified device value.",
  "id": "GHSA-9gg4-742m-cc8x",
  "modified": "2025-05-30T18:30:34Z",
  "published": "2022-05-13T01:48:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10212"
    },
    {
      "type": "WEB",
      "url": "https://cds.thalesgroup.com/en/tcs-cert/CVE-2018-10212"
    },
    {
      "type": "WEB",
      "url": "https://www.excellium-services.com/cert-xlm-advisory/cve-2018-10212"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9GGR-2464-2J32

Vulnerability from github – Published: 2025-09-22 14:42 – Updated: 2025-11-03 18:31
VLAI
Summary
Authlib: JWS/JWT accepts unknown crit headers (RFC violation → possible authz bypass)
Details

Summary

Authlib’s JWS verification accepts tokens that declare unknown critical header parameters (crit), violating RFC 7515 “must‑understand” semantics. An attacker can craft a signed token with a critical header (for example, bork or cnf) that strict verifiers reject but Authlib accepts. In mixed‑language fleets, this enables split‑brain verification and can lead to policy bypass, replay, or privilege escalation.

Affected Component and Versions

  • Library: Authlib (JWS verification)
  • API: authlib.jose.JsonWebSignature.deserialize_compact(...)
  • Version tested: 1.6.3
  • Configuration: Default; no allowlist or special handling for crit

Details

RFC 7515 (JWS) §4.1.11 defines crit as a “must‑understand” list: recipients MUST understand and enforce every header parameter listed in crit, otherwise they MUST reject the token. Security‑sensitive semantics such as token binding (e.g., cnf from RFC 7800) are often conveyed via crit.

Observed behavior with Authlib 1.6.3: - When a compact JWS contains a protected header with crit: ["cnf"] and a cnf object, or crit: ["bork"] with an unknown parameter, Authlib verifies the signature and returns the payload without rejecting the token or enforcing semantics of the critical parameter. - By contrast, Java Nimbus JOSE+JWT (9.37.x) and Node jose v5 both reject such tokens by default when crit lists unknown names.

Impact in heterogeneous fleets: - A strict ingress/gateway (Nimbus/Node) rejects a token, but a lenient Python microservice (Authlib) accepts the same token. This split‑brain acceptance bypasses intended security policies and can enable replay or privilege escalation if crit carries binding or policy information.

Proof of Concept (PoC)

This repository provides a multi‑runtime PoC demonstrating the issue across Python (Authlib), Node (jose v5), and Java (Nimbus).

Prerequisites

  • Python 3.8+
  • Node.js 18+
  • Java 11+ with Maven

Setup

Enter the directory authlib-crit-bypass-poc & run following commands.

make setup
make tokens

Tokens minted

  • tokens/unknown_crit.jwt with protected header: { "alg": "HS256", "crit": ["bork"], "bork": "x" }
  • tokens/cnf_header.jwt with protected header: { "alg": "HS256", "crit": ["cnf"], "cnf": {"jkt": "thumb-42"} }

Reproduction

Run the cross‑runtime demo:

make  demo

Expected output for each token (strict verifiers reject; Authlib accepts):

For tokens/unknown_crit.jwt:

Strict(Nimbus): REJECTED (unknown critical header: bork)
Strict(Node jose): REJECTED (unrecognized crit)
Lenient(Authlib): ACCEPTED -> payload={'sub': '123', 'role': 'user'}

For tokens/cnf_header.jwt:

Strict(Nimbus): REJECTED (unknown critical header: cnf)
Strict(Node jose): REJECTED (unrecognized crit)
Lenient(Authlib): ACCEPTED -> payload={'sub': '123', 'role': 'user'}

Environment notes: - Authlib version used: 1.6.3 (from PyPI) - Node jose version: ^5 - Nimbus JOSE+JWT version: 9.37.x - HS256 secret is 32 bytes to satisfy strict verifiers: 0123456789abcdef0123456789abcdef

Impact

  • Class: Violation of JWS crit “must‑understand” semantics; specification non‑compliance leading to authentication/authorization policy bypass.
  • Who is impacted: Any service that relies on crit to carry mandatory security semantics (e.g., token binding via cnf) or operates in a heterogeneous fleet with strict verifiers elsewhere.
  • Consequences: Split‑brain acceptance (gateway rejects while a backend accepts), replay, or privilege escalation if critical semantics are ignored.

References

  • RFC 7515: JSON Web Signature (JWS), §4.1.11 crit
  • RFC 7800: Proof‑of‑Possession Key Semantics for JWTs (cnf)
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "authlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59420"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-22T14:42:12Z",
    "nvd_published_at": "2025-09-22T18:15:46Z",
    "severity": "HIGH"
  },
  "details": "## Summary\nAuthlib\u2019s JWS verification accepts tokens that declare unknown critical header parameters (`crit`), violating RFC 7515 \u201cmust\u2011understand\u201d semantics. An attacker can craft a signed token with a critical header (for example, `bork` or `cnf`) that strict verifiers reject but Authlib accepts. In mixed\u2011language fleets, this enables split\u2011brain verification and can lead to policy bypass, replay, or privilege escalation.\n\n## Affected Component and Versions\n- Library: Authlib (JWS verification)\n- API: `authlib.jose.JsonWebSignature.deserialize_compact(...)`\n- Version tested: 1.6.3\n- Configuration: Default; no allowlist or special handling for `crit`\n\n## Details\nRFC 7515 (JWS) \u00a74.1.11 defines `crit` as a \u201cmust\u2011understand\u201d list: recipients MUST understand and enforce every header parameter listed in `crit`, otherwise they MUST reject the token. Security\u2011sensitive semantics such as token binding (e.g., `cnf` from RFC 7800) are often conveyed via `crit`.\n\nObserved behavior with Authlib 1.6.3:\n- When a compact JWS contains a protected header with `crit: [\"cnf\"]` and a `cnf` object, or `crit: [\"bork\"]` with an unknown parameter, Authlib verifies the signature and returns the payload without rejecting the token or enforcing semantics of the critical parameter.\n- By contrast, Java Nimbus JOSE+JWT (9.37.x) and Node `jose` v5 both reject such tokens by default when `crit` lists unknown names.\n\nImpact in heterogeneous fleets:\n- A strict ingress/gateway (Nimbus/Node) rejects a token, but a lenient Python microservice (Authlib) accepts the same token. This split\u2011brain acceptance bypasses intended security policies and can enable replay or privilege escalation if `crit` carries binding or policy information.\n\n## Proof of Concept (PoC)\nThis repository provides a multi\u2011runtime PoC demonstrating the issue across Python (Authlib), Node (`jose` v5), and Java (Nimbus).\n\n### Prerequisites\n- Python 3.8+\n- Node.js 18+\n- Java 11+ with Maven\n\n### Setup\n\nEnter the directory **authlib-crit-bypass-poc** \u0026 run following commands.\n```bash\nmake setup\nmake tokens\n```\n\n### Tokens minted\n- `tokens/unknown_crit.jwt` with protected header:\n  `{ \"alg\": \"HS256\", \"crit\": [\"bork\"], \"bork\": \"x\" }`\n- `tokens/cnf_header.jwt` with protected header:\n  `{ \"alg\": \"HS256\", \"crit\": [\"cnf\"], \"cnf\": {\"jkt\": \"thumb-42\"} }`\n\n### Reproduction\nRun the cross\u2011runtime demo:\n```bash\nmake  demo\n```\n\nExpected output for each token (strict verifiers reject; Authlib accepts):\n\nFor `tokens/unknown_crit.jwt`:\n```\nStrict(Nimbus): REJECTED (unknown critical header: bork)\nStrict(Node jose): REJECTED (unrecognized crit)\nLenient(Authlib): ACCEPTED -\u003e payload={\u0027sub\u0027: \u0027123\u0027, \u0027role\u0027: \u0027user\u0027}\n```\n\nFor `tokens/cnf_header.jwt`:\n```\nStrict(Nimbus): REJECTED (unknown critical header: cnf)\nStrict(Node jose): REJECTED (unrecognized crit)\nLenient(Authlib): ACCEPTED -\u003e payload={\u0027sub\u0027: \u0027123\u0027, \u0027role\u0027: \u0027user\u0027}\n```\n\nEnvironment notes:\n- Authlib version used: `1.6.3` (from PyPI)\n- Node `jose` version: `^5`\n- Nimbus JOSE+JWT version: `9.37.x`\n- HS256 secret is 32 bytes to satisfy strict verifiers: `0123456789abcdef0123456789abcdef`\n\n## Impact\n- Class: Violation of JWS `crit` \u201cmust\u2011understand\u201d semantics; specification non\u2011compliance leading to authentication/authorization policy bypass.\n- Who is impacted: Any service that relies on `crit` to carry mandatory security semantics (e.g., token binding via `cnf`) or operates in a heterogeneous fleet with strict verifiers elsewhere.\n- Consequences: Split\u2011brain acceptance (gateway rejects while a backend accepts), replay, or privilege escalation if critical semantics are ignored.\n\n## References\n- RFC 7515: JSON Web Signature (JWS), \u00a74.1.11 `crit`\n- RFC 7800: Proof\u2011of\u2011Possession Key Semantics for JWTs (`cnf`)",
  "id": "GHSA-9ggr-2464-2j32",
  "modified": "2025-11-03T18:31:42Z",
  "published": "2025-09-22T14:42:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-9ggr-2464-2j32"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59420"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/6b1813e4392eb7c168c276099ff7783b176479df"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00032.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Authlib: JWS/JWT accepts unknown crit headers (RFC violation \u2192 possible authz bypass)"
}

GHSA-9GHC-6JGP-H734

Vulnerability from github – Published: 2023-11-14 21:30 – Updated: 2023-11-14 21:30
VLAI
Details

Improper authorization in PushClientProvider of Samsung Push Service prior to version 3.4.10 allows attacker to access unique id.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-42541"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-07T08:15:19Z",
    "severity": "MODERATE"
  },
  "details": "Improper authorization in PushClientProvider of Samsung Push Service prior to version 3.4.10 allows attacker to access unique id.",
  "id": "GHSA-9ghc-6jgp-h734",
  "modified": "2023-11-14T21:30:53Z",
  "published": "2023-11-14T21:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42541"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2023\u0026month=11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list