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.

6275 vulnerabilities reference this CWE, most recent first.

GHSA-VXHC-C4QM-647P

Vulnerability from github – Published: 2021-08-11 15:18 – Updated: 2021-10-21 13:35
VLAI
Summary
Improper Access Control in Dolibarr
Details

In “Dolibarr” application, 2.8.1 to 13.0.4 don’t restrict or incorrectly restricts access to a resource from an unauthorized actor. A low privileged attacker can modify the Private Note which only an administrator has rights to do, the affected field is at “/adherents/note.php?id=1” endpoint.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "dolibarr/dolibarr"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.1"
            },
            {
              "fixed": "14.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-25954"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-10T17:28:01Z",
    "nvd_published_at": "2021-08-09T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In \u201cDolibarr\u201d application, 2.8.1 to 13.0.4 don\u2019t restrict or incorrectly restricts access to a resource from an unauthorized actor. A low privileged attacker can modify the Private Note which only an administrator has rights to do, the affected field is at \u201c/adherents/note.php?id=1\u201d endpoint.",
  "id": "GHSA-vxhc-c4qm-647p",
  "modified": "2021-10-21T13:35:03Z",
  "published": "2021-08-11T15:18:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25954"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Dolibarr/dolibarr/commit/8cc100012d46282799fb19f735a53b7101569377"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Dolibarr/dolibarr"
    },
    {
      "type": "WEB",
      "url": "https://www.whitesourcesoftware.com/vulnerability-database/CVE-2021-25954"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Access Control in Dolibarr"
}

GHSA-VXR6-PWVM-CF57

Vulnerability from github – Published: 2022-10-21 19:01 – Updated: 2023-01-25 03:30
VLAI
Details

A vulnerability has been identified in Siveillance Video Mobile Server V2022 R2 (All versions < V22.2a (80)). The mobile server component of affected applications improperly handles the log in for Active Directory accounts that are part of Administrators group. This could allow an unauthenticated remote attacker to access the application without a valid account.

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-2022-43400"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1390",
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-21T14:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability has been identified in Siveillance Video Mobile Server V2022 R2 (All versions \u003c V22.2a (80)). The mobile server component of affected applications improperly handles the log in for Active Directory accounts that are part of Administrators group. This could allow an unauthenticated remote attacker to access the application without a valid account.",
  "id": "GHSA-vxr6-pwvm-cf57",
  "modified": "2023-01-25T03:30:32Z",
  "published": "2022-10-21T19:01:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43400"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-640732.pdf"
    }
  ],
  "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-VXV2-8J6R-PCPG

Vulnerability from github – Published: 2026-07-21 20:21 – Updated: 2026-07-21 20:21
VLAI
Summary
Gitea: OAuth token introspection returns metadata of tokens issued to other clients (RFC 7662 section 4 violation)
Details

Live reproduction against Gitea 1.26.1

Setup: Gitea 1.26.1 docker stack with two users (admin and victim) and two OAuth applications owned by different users:

Client A: id=5dda747d-7fdd-4694-85ff-ce4f893ce51e   owner=admin
Client B: id=588f778f-4a41-4914-ae01-85d776c369db   owner=victim

admin runs an OAuth flow against Client A and obtains an access token. victim (acting through Client B's credentials) calls the introspection endpoint with Client A's access token in the body:

$ curl -s -u "$B_ID:$B_SEC" -X POST http://localhost:3001/login/oauth/introspect \
       --data-urlencode "token=$CLIENT_A_ACCESS_TOKEN"
{
    "active": true,
    "username": "admin",
    "iss": "http://localhost:3001",
    "sub": "1",
    "aud": [
        "5dda747d-7fdd-4694-85ff-ce4f893ce51e"
    ]
}

Note the aud claim: the server explicitly states the token's audience is Client A, yet returns the full metadata to Client B. Per RFC 7662 section 4 ("The authorization server SHOULD also limit the information it discloses about each token to the resources that are authorized to receive it") the introspection result must not be disclosed to clients other than the token's audience.

Full reproduction script attached as poc.sh. Full session log attached as live_run.log.

Root cause

routers/web/auth/oauth2_provider.go:130-175 IntrospectOAuth:

func IntrospectOAuth(ctx *context.Context) {
    clientIDValid := false
    authHeader := ctx.Req.Header.Get("Authorization")
    if parsed, ok := httpauth.ParseAuthorizationHeader(authHeader); ok && parsed.BasicAuth != nil {
        clientID, clientSecret := parsed.BasicAuth.Username, parsed.BasicAuth.Password
        app, err := auth.GetOAuth2ApplicationByClientID(ctx, clientID)
        if err != nil && !auth.IsErrOauthClientIDInvalid(err) {
            log.Error("Error retrieving client_id: %v", err)
            ctx.HTTPError(http.StatusInternalServerError)
            return
        }
        clientIDValid = err == nil && app.ValidateClientSecret([]byte(clientSecret))
    }
    if !clientIDValid {
        ctx.Resp.Header().Set("WWW-Authenticate", `Basic realm="Gitea OAuth2"`)
        ctx.PlainText(http.StatusUnauthorized, "no valid authorization")
        return
    }

    var response struct {
        Active   bool   `json:"active"`
        Scope    string `json:"scope,omitempty"`
        Username string `json:"username,omitempty"`
        jwt.RegisteredClaims
    }

    form := web.GetForm(ctx).(*forms.IntrospectTokenForm)
    token, err := oauth2_provider.ParseToken(form.Token, oauth2_provider.DefaultSigningKey)
    if err == nil {
        grant, err := auth.GetOAuth2GrantByID(ctx, token.GrantID)
        if err == nil && grant != nil {
            app, err := auth.GetOAuth2ApplicationByID(ctx, grant.ApplicationID)  // shadows the introspecting client's `app`
            if err == nil && app != nil {
                response.Active = true
                response.Scope = grant.Scope
                response.RegisteredClaims = oauth2_provider.NewJwtRegisteredClaimsFromUser(app.ClientID, grant.UserID, nil)
            }
            if user, err := user_model.GetUserByID(ctx, grant.UserID); err == nil {
                response.Username = user.Name
            }
        }
    }

    ctx.JSON(http.StatusOK, response)
}

The handler:

  1. Authenticates the introspecting client via HTTP Basic (app.ValidateClientSecret). The local variable app at this point references the introspecting client.
  2. Loads the grant for form.Token via auth.GetOAuth2GrantByID(ctx, token.GrantID).
  3. Reassigns app to auth.GetOAuth2ApplicationByID(ctx, grant.ApplicationID) (line 162). After this point, app is the token's issuing client, not the introspecting client.
  4. Populates response from the reassigned app and the grant.

There is no comparison between the introspecting client's id and grant.ApplicationID. The endpoint will return metadata for any token whose JWT signature validates, regardless of which client is asking.

Patch parity with PR #37704

The same file contains two recently-hardened handlers in commit 7e54514316 ("fix(oauth): bind token exchanges to the original client request", PR #37704, 2026-05-15) that added exactly this missing check:

handleRefreshToken (routers/web/auth/oauth2_provider.go:561-568):

if grant.ApplicationID != app.ID {
    handleAccessTokenError(ctx, oauth2_provider.AccessTokenError{
        ErrorCode:        oauth2_provider.AccessTokenErrorCodeInvalidGrant,
        ErrorDescription: "refresh token belongs to a different client",
    })
    return
}

handleAuthorizationCode (routers/web/auth/oauth2_provider.go:640-647):

if authorizationCode.RedirectURI != "" && form.RedirectURI != authorizationCode.RedirectURI {
    handleAccessTokenError(ctx, oauth2_provider.AccessTokenError{ ... })
    return
}
// later in the same function:
if authorizationCode.Grant.ApplicationID != app.ID {
    handleAccessTokenError(ctx, ...)
    return
}

IntrospectOAuth shares the same problem space (it consumes a token bound to a grant whose application may differ from the requesting client) but did not receive the parallel patch.

Impact

Any authenticated OAuth client can call /login/oauth/introspect with another client's access or refresh token in the body and learn:

  • active (true or false). A token-validity oracle that survives across application boundaries without consuming or "using" the token.
  • scope. The scope of the token.
  • username. The user the token belongs to.
  • iss, sub, aud. Standard JWT registered claims. aud reveals the issuing client_id, making it obvious to the introspecting client that the token does not belong to them. The server returns the data anyway.

Practical scenarios:

  1. Stolen-token validation oracle. An attacker who exfiltrates an access token from logs, traffic capture, browser memory, or a leaked dump can verify the token is still active before using it for higher-noise actions like API calls. The probe does not consume the grant counter, so it does not appear in audit trails of "actual token use".
  2. Cross-tenant metadata enumeration. Any user can register their own OAuth application on a Gitea instance (web UI: /user/settings/applications). The attacker uses their own valid credentials to introspect tokens belonging to other tenants' clients. They learn which user/scope each token corresponds to without ever using it.
  3. Token-confusion reconnaissance. Before chaining a separate vulnerability (e.g., a future token-replay or session-fixation bug), the attacker can use introspection to map the token universe.

Suggested remediation

A one-line fix matching the PR #37704 pattern:

 grant, err := auth.GetOAuth2GrantByID(ctx, token.GrantID)
 if err == nil && grant != nil {
+    if grant.ApplicationID != app.ID {
+        // do not reveal token metadata for tokens not issued to this client
+        ctx.JSON(http.StatusOK, response)  // response is zero-valued, active=false
+        return
+    }
     app, err := auth.GetOAuth2ApplicationByID(ctx, grant.ApplicationID)

Or, equivalently, replace the inner app reassignment with a check that uses the introspecting client's app.ClientID directly for the response claims.

Affected versions

Confirmed at Gitea v1.26.1 (latest release, 2026-04-24, docker image gitea/gitea:1.26.1). The vulnerable code path has been in place since the introspection endpoint was introduced; the recent PR #37704 / #37706 OAuth hardening landed in master May 15-16 2026 but did not touch this endpoint.

Attachments

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58425"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:21:33Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Live reproduction against Gitea 1.26.1\n\nSetup: Gitea 1.26.1 docker stack with two users (`admin` and `victim`) and two OAuth applications owned by different users:\n\n```\nClient A: id=5dda747d-7fdd-4694-85ff-ce4f893ce51e   owner=admin\nClient B: id=588f778f-4a41-4914-ae01-85d776c369db   owner=victim\n```\n\n`admin` runs an OAuth flow against Client A and obtains an access token. `victim` (acting through Client B\u0027s credentials) calls the introspection endpoint with Client A\u0027s access token in the body:\n\n```\n$ curl -s -u \"$B_ID:$B_SEC\" -X POST http://localhost:3001/login/oauth/introspect \\\n       --data-urlencode \"token=$CLIENT_A_ACCESS_TOKEN\"\n{\n    \"active\": true,\n    \"username\": \"admin\",\n    \"iss\": \"http://localhost:3001\",\n    \"sub\": \"1\",\n    \"aud\": [\n        \"5dda747d-7fdd-4694-85ff-ce4f893ce51e\"\n    ]\n}\n```\n\nNote the `aud` claim: the server explicitly states the token\u0027s audience is Client A, yet returns the full metadata to Client B. Per RFC 7662 section 4 (\"The authorization server SHOULD also limit the information it discloses about each token to the resources that are authorized to receive it\") the introspection result must not be disclosed to clients other than the token\u0027s audience.\n\nFull reproduction script attached as `poc.sh`. Full session log attached as `live_run.log`.\n\n## Root cause\n\n`routers/web/auth/oauth2_provider.go:130-175` `IntrospectOAuth`:\n\n```go\nfunc IntrospectOAuth(ctx *context.Context) {\n    clientIDValid := false\n    authHeader := ctx.Req.Header.Get(\"Authorization\")\n    if parsed, ok := httpauth.ParseAuthorizationHeader(authHeader); ok \u0026\u0026 parsed.BasicAuth != nil {\n        clientID, clientSecret := parsed.BasicAuth.Username, parsed.BasicAuth.Password\n        app, err := auth.GetOAuth2ApplicationByClientID(ctx, clientID)\n        if err != nil \u0026\u0026 !auth.IsErrOauthClientIDInvalid(err) {\n            log.Error(\"Error retrieving client_id: %v\", err)\n            ctx.HTTPError(http.StatusInternalServerError)\n            return\n        }\n        clientIDValid = err == nil \u0026\u0026 app.ValidateClientSecret([]byte(clientSecret))\n    }\n    if !clientIDValid {\n        ctx.Resp.Header().Set(\"WWW-Authenticate\", `Basic realm=\"Gitea OAuth2\"`)\n        ctx.PlainText(http.StatusUnauthorized, \"no valid authorization\")\n        return\n    }\n\n    var response struct {\n        Active   bool   `json:\"active\"`\n        Scope    string `json:\"scope,omitempty\"`\n        Username string `json:\"username,omitempty\"`\n        jwt.RegisteredClaims\n    }\n\n    form := web.GetForm(ctx).(*forms.IntrospectTokenForm)\n    token, err := oauth2_provider.ParseToken(form.Token, oauth2_provider.DefaultSigningKey)\n    if err == nil {\n        grant, err := auth.GetOAuth2GrantByID(ctx, token.GrantID)\n        if err == nil \u0026\u0026 grant != nil {\n            app, err := auth.GetOAuth2ApplicationByID(ctx, grant.ApplicationID)  // shadows the introspecting client\u0027s `app`\n            if err == nil \u0026\u0026 app != nil {\n                response.Active = true\n                response.Scope = grant.Scope\n                response.RegisteredClaims = oauth2_provider.NewJwtRegisteredClaimsFromUser(app.ClientID, grant.UserID, nil)\n            }\n            if user, err := user_model.GetUserByID(ctx, grant.UserID); err == nil {\n                response.Username = user.Name\n            }\n        }\n    }\n\n    ctx.JSON(http.StatusOK, response)\n}\n```\n\nThe handler:\n\n1. Authenticates the introspecting client via HTTP Basic (`app.ValidateClientSecret`). The local variable `app` at this point references the introspecting client.\n2. Loads the grant for `form.Token` via `auth.GetOAuth2GrantByID(ctx, token.GrantID)`.\n3. **Reassigns** `app` to `auth.GetOAuth2ApplicationByID(ctx, grant.ApplicationID)` (line 162). After this point, `app` is the token\u0027s issuing client, not the introspecting client.\n4. Populates `response` from the reassigned `app` and the grant.\n\nThere is no comparison between the introspecting client\u0027s id and `grant.ApplicationID`. The endpoint will return metadata for any token whose JWT signature validates, regardless of which client is asking.\n\n## Patch parity with PR #37704\n\nThe same file contains two recently-hardened handlers in commit `7e54514316` (\"fix(oauth): bind token exchanges to the original client request\", PR #37704, 2026-05-15) that added exactly this missing check:\n\n`handleRefreshToken` (routers/web/auth/oauth2_provider.go:561-568):\n\n```go\nif grant.ApplicationID != app.ID {\n    handleAccessTokenError(ctx, oauth2_provider.AccessTokenError{\n        ErrorCode:        oauth2_provider.AccessTokenErrorCodeInvalidGrant,\n        ErrorDescription: \"refresh token belongs to a different client\",\n    })\n    return\n}\n```\n\n`handleAuthorizationCode` (routers/web/auth/oauth2_provider.go:640-647):\n\n```go\nif authorizationCode.RedirectURI != \"\" \u0026\u0026 form.RedirectURI != authorizationCode.RedirectURI {\n    handleAccessTokenError(ctx, oauth2_provider.AccessTokenError{ ... })\n    return\n}\n// later in the same function:\nif authorizationCode.Grant.ApplicationID != app.ID {\n    handleAccessTokenError(ctx, ...)\n    return\n}\n```\n\n`IntrospectOAuth` shares the same problem space (it consumes a token bound to a grant whose application may differ from the requesting client) but did not receive the parallel patch.\n\n## Impact\n\nAny authenticated OAuth client can call `/login/oauth/introspect` with another client\u0027s access or refresh token in the body and learn:\n\n* `active` (true or false). A token-validity oracle that survives across application boundaries without consuming or \"using\" the token.\n* `scope`. The scope of the token.\n* `username`. The user the token belongs to.\n* `iss`, `sub`, `aud`. Standard JWT registered claims. `aud` reveals the issuing client_id, making it obvious to the introspecting client that the token does not belong to them. The server returns the data anyway.\n\nPractical scenarios:\n\n1. **Stolen-token validation oracle.** An attacker who exfiltrates an access token from logs, traffic capture, browser memory, or a leaked dump can verify the token is still active before using it for higher-noise actions like API calls. The probe does not consume the grant counter, so it does not appear in audit trails of \"actual token use\".\n2. **Cross-tenant metadata enumeration.** Any user can register their own OAuth application on a Gitea instance (web UI: /user/settings/applications). The attacker uses their own valid credentials to introspect tokens belonging to other tenants\u0027 clients. They learn which user/scope each token corresponds to without ever using it.\n3. **Token-confusion reconnaissance.** Before chaining a separate vulnerability (e.g., a future token-replay or session-fixation bug), the attacker can use introspection to map the token universe.\n\n## Suggested remediation\n\nA one-line fix matching the PR #37704 pattern:\n\n```diff\n grant, err := auth.GetOAuth2GrantByID(ctx, token.GrantID)\n if err == nil \u0026\u0026 grant != nil {\n+    if grant.ApplicationID != app.ID {\n+        // do not reveal token metadata for tokens not issued to this client\n+        ctx.JSON(http.StatusOK, response)  // response is zero-valued, active=false\n+        return\n+    }\n     app, err := auth.GetOAuth2ApplicationByID(ctx, grant.ApplicationID)\n```\n\nOr, equivalently, replace the inner `app` reassignment with a check that uses the introspecting client\u0027s `app.ClientID` directly for the response claims.\n\n## Affected versions\n\nConfirmed at Gitea v1.26.1 (latest release, 2026-04-24, docker image `gitea/gitea:1.26.1`). The vulnerable code path has been in place since the introspection endpoint was introduced; the recent PR #37704 / #37706 OAuth hardening landed in master May 15-16 2026 but did not touch this endpoint.\n\n## Attachments\n-  [poc.sh](https://github.com/user-attachments/files/28182098/poc.sh): Full reproduction script.\n-  [live_run.log](https://github.com/user-attachments/files/28182115/live_run.log): Full session log.",
  "id": "GHSA-vxv2-8j6r-pcpg",
  "modified": "2026-07-21T20:21:33Z",
  "published": "2026-07-21T20:21:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-vxv2-8j6r-pcpg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38042"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/c9920b7bd0f6ec1f7590f104711b09d55917f9e8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: OAuth token introspection returns metadata of tokens issued to other clients (RFC 7662 section 4 violation)"
}

GHSA-VXX6-78XM-PW3X

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

GistPad before 0.2.7 allows a crafted workspace folder to change the URL for the Gist API, which leads to leakage of GitHub access tokens.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-29642"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-30T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "GistPad before 0.2.7 allows a crafted workspace folder to change the URL for the Gist API, which leads to leakage of GitHub access tokens.",
  "id": "GHSA-vxx6-78xm-pw3x",
  "modified": "2022-05-24T17:45:53Z",
  "published": "2022-05-24T17:45:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29642"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lostintangent/gistpad/commit/230b05e8dea8d7ac5aae998bbe0a591d7f081b70"
    },
    {
      "type": "WEB",
      "url": "https://vuln.ryotak.me/advisories/7"
    },
    {
      "type": "WEB",
      "url": "https://vuln.ryotak.me/advisories/7.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-VXXJ-78QM-2X3M

Vulnerability from github – Published: 2022-05-13 01:21 – Updated: 2022-05-13 01:21
VLAI
Details

An elevation of privilege exists in Windows COM Desktop Broker, aka "Windows COM Elevation of Privilege Vulnerability." This affects Windows Server 2012 R2, Windows RT 8.1, Windows Server 2019, Windows Server 2016, Windows 8.1, Windows 10, Windows 10 Servers.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-0552"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-01-08T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "An elevation of privilege exists in Windows COM Desktop Broker, aka \"Windows COM Elevation of Privilege Vulnerability.\" This affects Windows Server 2012 R2, Windows RT 8.1, Windows Server 2019, Windows Server 2016, Windows 8.1, Windows 10, Windows 10 Servers.",
  "id": "GHSA-vxxj-78qm-2x3m",
  "modified": "2022-05-13T01:21:16Z",
  "published": "2022-05-13T01:21:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0552"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0552"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/46162"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/106407"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W222-M46C-MGH6

Vulnerability from github – Published: 2025-04-30 16:43 – Updated: 2025-05-01 13:30
VLAI
Summary
OpenFGA Authorization Bypass
Details

Overview OpenFGA v1.8.10 or previous (Helm chart <= openfga-0.2.28, docker <= v.1.8.10) are vulnerable to authorization bypass when certain Check and ListObject calls are executed.

Am I Affected? If you are using OpenFGA v1.8.10 or previous, specifically under the following conditions, you are affected by this authorization bypass vulnerability: - Calling Check API or ListObjects with an authorization model that has tuple cycle. - Check query cache is enabled, and - There are multiple check / list objects requests involving the tuple cycle within the check query TTL

Fix Upgrade to v1.8.11. This upgrade is backwards compatible.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openfga/openfga"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.6"
            },
            {
              "fixed": "1.8.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-46331"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-30T16:43:33Z",
    "nvd_published_at": "2025-04-30T19:15:55Z",
    "severity": "MODERATE"
  },
  "details": "Overview\nOpenFGA v1.8.10 or previous (Helm chart \u003c= openfga-0.2.28, docker \u003c= v.1.8.10) are vulnerable to authorization bypass when certain Check and ListObject calls are executed.\n\nAm I Affected?\nIf you are using OpenFGA v1.8.10 or previous, specifically under the following conditions, you are affected by this authorization bypass vulnerability:\n- Calling Check API or ListObjects with an [authorization model](https://openfga.dev/docs/concepts#what-is-an-authorization-model) that has tuple cycle.\n- [Check query cache](https://github.com/openfga/openfga/blob/9b5974458b777707ed2a30ba6303699499e655ee/.config-schema.json#L528) is enabled, and\n- There are multiple check / list objects requests involving the tuple cycle within the check query TTL\n\nFix\nUpgrade to v1.8.11. This upgrade is backwards compatible.",
  "id": "GHSA-w222-m46c-mgh6",
  "modified": "2025-05-01T13:30:18Z",
  "published": "2025-04-30T16:43:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/security/advisories/GHSA-w222-m46c-mgh6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46331"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/commit/244302e7a8b979d66cc1874a3899cdff7d47862f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openfga/openfga"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenFGA Authorization Bypass"
}

GHSA-W248-FFJ2-4V5Q

Vulnerability from github – Published: 2022-06-09 23:47 – Updated: 2022-06-20 21:59
VLAI
Summary
Fix failure to strip Authorization header on HTTP downgrade
Details

Impact

Authorization headers on requests are sensitive information. On making a request using the https scheme to a server which responds with a redirect to a URI with the http scheme, we should not forward the Authorization header on. This is much the same as to how we don't forward on the header if the host changes. Prior to this fix, https to http downgrades did not result in the Authorization header being removed, only changes to the host.

Patches

Affected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4.

Workarounds

An alternative approach would be to use your own redirect middleware, rather than ours, if you are unable to upgrade. If you do not require or expect redirects to be followed, one should simply disable redirects all together.

References

For more information

If you have any questions or comments about this advisory, please get in touch with us in #guzzle on the PHP HTTP Slack. Do not report additional security advisories in that public channel, however - please follow our vulnerability reporting process.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "guzzlehttp/guzzle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "6.5.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "guzzlehttp/guzzle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-31043"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-212",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-09T23:47:23Z",
    "nvd_published_at": "2022-06-10T00:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\n`Authorization` headers on requests are sensitive information. On making a request using the `https` scheme to a server which responds with a redirect to a URI with the `http` scheme, we should not forward the `Authorization` header on. This is much the same as to how we don\u0027t forward on the header if the host changes. Prior to this fix, `https` to `http` downgrades did not result in the `Authorization` header being removed, only changes to the host.\n\n### Patches\n\nAffected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4.\n\n### Workarounds\n\nAn alternative approach would be to use your own redirect middleware, rather than ours, if you are unable to upgrade. If you do not require or expect redirects to be followed, one should simply disable redirects all together.\n\n### References\n\n* [RFC9110 Section 15.4](https://www.rfc-editor.org/rfc/rfc9110.html#name-redirection-3xx)\n\n### For more information\n\nIf you have any questions or comments about this advisory, please get in touch with us in `#guzzle` on the [PHP HTTP Slack](https://php-http.slack.com/). Do not report additional security advisories in that public channel, however - please follow our [vulnerability reporting process](https://github.com/guzzle/guzzle/security/policy).\n",
  "id": "GHSA-w248-ffj2-4v5q",
  "modified": "2022-06-20T21:59:37Z",
  "published": "2022-06-09T23:47:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/security/advisories/GHSA-w248-ffj2-4v5q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31043"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/commit/e3ff079b22820c2029d4c2a87796b6a0b8716ad8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/guzzlehttp/guzzle/CVE-2022-31043.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/guzzle/guzzle"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2022/dsa-5246"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/sa-core-2022-011"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/rfc/rfc9110.html#name-redirection-3xx"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fix failure to strip Authorization header on HTTP downgrade"
}

GHSA-W24R-5266-9C3C

Vulnerability from github – Published: 2026-04-30 18:20 – Updated: 2026-06-09 10:49
VLAI
Summary
Clerk has an authorization bypass when combining organization, billing, or reverification checks
Details

Summary

has(), auth.protect(), and related authorization predicates in @clerk/shared, @clerk/nextjs, @clerk/backend, and other framework SDKs can return true for certain combined authorization checks when the result should be false, allowing a gated action to proceed for a user who does not satisfy the full set of requested conditions.

Sessions are not compromised and no existing user can be impersonated. The bypass is limited to the authorization decision returned by the predicate. clerkMiddleware continues to authenticate requests correctly, auth() reflects the real authentication state, and token verification is unaffected.

Who is affected

All apps that combine more than one authorization dimension in a single has() or auth.protect() call should upgrade to the patched versions. Patches are drop-in with no API changes. The information below describes the scope of the bypass and helps developers understand whether their apps are potentially affected, but is not a reason to delay the upgrade.

This call shape can be bypassed if certain conditions are met: a has() or auth.protect() call that combines a reverification check with any of role, permission, feature, or plan, or that combines a billing check (feature or plan) with a role or permission check.

// Reverification combined with role / permission / feature / plan
await auth.protect({ permission: 'org:settings:delete', reverification: 'strict' });
const canAct = has({ role: 'org:admin', reverification: 'strict' });

// Billing (feature / plan) combined with role / permission
const canAct = has({ permission: 'org:admin', feature: 'premium' });

Single-condition checks are not affected and continue to fail closed as expected:

await auth.protect({ permission: 'org:settings:delete' });
has({ reverification: 'strict' });

The callback form of auth.protect is not affected unless the callback itself invokes one of the affected shapes:

await auth.protect(has => has({ permission: 'org:X' }) && has({ reverification: 'strict' }));

App patterns that rely only on single-condition checks, or that combine them via the callback form, are unaffected. Authentication, session state, and token verification continue to work correctly regardless of this bypass.

@clerk/shared is usually not imported directly in application code, but the fix lives there and reaches an app through its framework package. If developers import createCheckAuthorization from @clerk/shared directly, their apps are also affected. Run npm why @clerk/shared (or the app's package manager's equivalent) to check the installed version.

Additional auth.protect() bypass

A second, related bypass lives in @clerk/nextjs: auth.protect() silently discarded authorization params (role, permission, feature, plan, reverification) whenever the same argument object also contained unauthenticatedUrl, unauthorizedUrl, or token.

Recommended actions

Upgrade to the latest patch release of the consuming app's framework package on its current major. Both Core 2 and Core 3 release lines have patches. See the "Affected packages" section above for the exact vulnerable ranges and patched versions per package.

If a consuming app pins @clerk/clerk-js directly, upgrade it to the patched version. Most apps load @clerk/clerk-js from Clerk's CDN through their framework package and will receive the fix automatically, with no upgrade step required.

Workaround

If developers cannot upgrade immediately, split combined has() or auth.protect() calls into sequential single-condition checks:

// Replace
await auth.protect({ permission: 'org:X', reverification: 'strict' });
// With
await auth.protect({ reverification: 'strict' });
await auth.protect({ permission: 'org:X' });

Each single-condition check fails closed as expected, so evaluating them independently and denying if either fails produces the correct result.

Timeline

This issue was reported on 18 APR 2026, patched on 22 APR 2026, and publicly disclosed on 22 APR 2026.

Thanks to AISafe for the responsible disclosure of this vulnerability.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.47.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/shared"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.47.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.8.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/shared"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.33.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/backend"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.33.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.2.13"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/backend"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.2.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.39.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/nextjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.39.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.2.3"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/nextjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.125.9"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/clerk-js"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.22.0"
            },
            {
              "fixed": "5.125.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.7.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/clerk-js"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.7.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.61.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/clerk-react"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.9.0"
            },
            {
              "fixed": "5.61.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.4.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/react"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.17.20"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/vue"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.17.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.15"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/vue"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.17.10"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/astro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.17.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.17"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/astro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.0.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.13.28"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.13.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.2.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.19.35"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/clerk-expo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.11"
            },
            {
              "fixed": "2.19.36"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.2.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/expo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.4.12"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/react-router"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.1"
            },
            {
              "fixed": "2.4.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.3"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/react-router"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.29.10"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/tanstack-react-start"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.1"
            },
            {
              "fixed": "0.29.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.1.3"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/tanstack-react-start"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.9.14"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/chrome-extension"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.5"
            },
            {
              "fixed": "2.9.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.14"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/chrome-extension"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.6.30"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/fastify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.42"
            },
            {
              "fixed": "2.6.31"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.15"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/fastify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.7.78"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/express"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.0"
            },
            {
              "fixed": "1.7.79"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/express"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.1.15"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/hono"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.2"
            },
            {
              "fixed": "0.1.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42349"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-30T18:20:02Z",
    "nvd_published_at": "2026-05-11T17:16:33Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`has()`, `auth.protect()`, and related authorization predicates in `@clerk/shared`, `@clerk/nextjs`, `@clerk/backend`, and other framework SDKs can return true for certain combined authorization checks when the result should be false, allowing a gated action to proceed for a user who does not satisfy the full set of requested conditions.\n\nSessions are not compromised and no existing user can be impersonated. The bypass is limited to the authorization decision returned by the predicate. `clerkMiddleware` continues to authenticate requests correctly, `auth()` reflects the real authentication state, and token verification is unaffected.\n\n### Who is affected\n\nAll apps that combine more than one authorization dimension in a single `has()` or `auth.protect()` call should upgrade to the patched versions. Patches are drop-in with no API changes. The information below describes the scope of the bypass and helps developers understand whether their apps are potentially affected, but is not a reason to delay the upgrade.\n\nThis call shape can be bypassed if certain conditions are met: a `has()` or `auth.protect()` call that combines a `reverification` check with any of `role`, `permission`, `feature`, or `plan`, or that combines a billing check (`feature` or `plan`) with a role or permission check.\n\n\n```ts\n// Reverification combined with role / permission / feature / plan\nawait auth.protect({ permission: \u0027org:settings:delete\u0027, reverification: \u0027strict\u0027 });\nconst canAct = has({ role: \u0027org:admin\u0027, reverification: \u0027strict\u0027 });\n\n// Billing (feature / plan) combined with role / permission\nconst canAct = has({ permission: \u0027org:admin\u0027, feature: \u0027premium\u0027 });\n```\n\nSingle-condition checks are not affected and continue to fail closed as expected:\n\n```ts\nawait auth.protect({ permission: \u0027org:settings:delete\u0027 });\nhas({ reverification: \u0027strict\u0027 });\n```\n\nThe callback form of `auth.protect` is not affected unless the callback itself invokes one of the affected shapes:\n\n```ts\nawait auth.protect(has =\u003e has({ permission: \u0027org:X\u0027 }) \u0026\u0026 has({ reverification: \u0027strict\u0027 }));\n```\n\nApp patterns that rely only on single-condition checks, or that combine them via the callback form, are unaffected. Authentication, session state, and token verification continue to work correctly regardless of this bypass.\n\n`@clerk/shared` is usually not imported directly in application code, but the fix lives there and reaches an app through its framework package. If developers import `createCheckAuthorization` from `@clerk/shared` directly, their apps are also affected. Run `npm why @clerk/shared` (or the app\u0027s package manager\u0027s equivalent) to check the installed version.\n\n### Additional `auth.protect()` bypass\n\nA second, related bypass lives in `@clerk/nextjs`: `auth.protect()` silently discarded authorization params (`role`, `permission`, `feature`, `plan`, `reverification`) whenever the same argument object also contained `unauthenticatedUrl`, `unauthorizedUrl`, or `token`.\n\n### Recommended actions\n\nUpgrade to the latest patch release of the consuming app\u0027s framework package on its current major. Both Core 2 and Core 3 release lines have patches. See the \"Affected packages\" section above for the exact vulnerable ranges and patched versions per package.\n\nIf a consuming app pins `@clerk/clerk-js` directly, upgrade it to the patched version. Most apps load `@clerk/clerk-js` from Clerk\u0027s CDN through their framework package and will receive the fix automatically, with no upgrade step required.\n\n### Workaround\n\nIf developers cannot upgrade immediately, split combined `has()` or `auth.protect()` calls into sequential single-condition checks:\n\n```ts\n// Replace\nawait auth.protect({ permission: \u0027org:X\u0027, reverification: \u0027strict\u0027 });\n// With\nawait auth.protect({ reverification: \u0027strict\u0027 });\nawait auth.protect({ permission: \u0027org:X\u0027 });\n```\n\nEach single-condition check fails closed as expected, so evaluating them independently and denying if either fails produces the correct result.\n\n### Timeline\n\nThis issue was reported on 18 APR 2026, patched on 22 APR 2026, and publicly disclosed on 22 APR 2026.\n\nThanks to AISafe for the responsible disclosure of this vulnerability.",
  "id": "GHSA-w24r-5266-9c3c",
  "modified": "2026-06-09T10:49:55Z",
  "published": "2026-04-30T18:20:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/clerk/javascript/security/advisories/GHSA-w24r-5266-9c3c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42349"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/clerk/javascript"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Clerk has an authorization bypass when combining organization, billing, or reverification checks"
}

GHSA-W279-72W5-RRQ7

Vulnerability from github – Published: 2023-10-16 21:30 – Updated: 2024-04-04 08:41
VLAI
Details

An Access Control issue discovered in Extreme Networks Switch Engine (EXOS) before 32.5.1.5, also fixed in 22.7, 31.7.2 allows attackers to gain escalated privileges using crafted telnet commands via Redis server.

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-43119"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-16T20:15:15Z",
    "severity": "CRITICAL"
  },
  "details": "An Access Control issue discovered in Extreme Networks Switch Engine (EXOS) before 32.5.1.5, also fixed in 22.7, 31.7.2 allows attackers to gain escalated privileges using crafted telnet commands via Redis server.",
  "id": "GHSA-w279-72w5-rrq7",
  "modified": "2024-04-04T08:41:25Z",
  "published": "2023-10-16T21:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43119"
    },
    {
      "type": "WEB",
      "url": "https://extreme-networks.my.site.com/ExtrArticleDetail?an=000114378"
    }
  ],
  "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-W29C-VPJF-6HX4

Vulnerability from github – Published: 2025-06-09 15:31 – Updated: 2025-10-06 21:30
VLAI
Details

Incorrect authorization vulnerability in TCMAN's GIM v11. This vulnerability allows an attacker, with low privilege level, to change the password of other users through a POST request using the parameters idUser, PasswordActual, PasswordNew and PasswordNewRepeat in /PC/WebService.aspx/validateChangePassword%C3%B1a. To exploit the vulnerability the PasswordActual parameter must be empty.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
7.1 (High)
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
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-40668"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-09T13:15:22Z",
    "severity": "HIGH"
  },
  "details": "Incorrect authorization vulnerability in TCMAN\u0027s GIM v11. This vulnerability allows an attacker, with low privilege level, to change the password of other users through a POST request using the parameters idUser, PasswordActual, PasswordNew and PasswordNewRepeat in /PC/WebService.aspx/validateChangePassword%C3%B1a. To exploit the vulnerability the PasswordActual parameter must be empty.",
  "id": "GHSA-w29c-vpjf-6hx4",
  "modified": "2025-10-06T21:30:43Z",
  "published": "2025-06-09T15:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40668"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-tcman-gim-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "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:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}
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