Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

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.

5562 vulnerabilities reference this CWE, most recent first.

GHSA-R95X-QFJJ-FJJ2

Vulnerability from github – Published: 2026-05-13 01:36 – Updated: 2026-06-08 23:53

Summary

Authlib OIDC Implicit/Hybrid Authorization Vulnerable to Open Redirect

Details

Summary

An unauthenticated open redirect in Authlib's OpenIDImplicitGrant and OpenIDHybridGrant authorization endpoint lets a remote attacker cause the authorization server to issue an HTTP 302 to an attacker-chosen URL by submitting an authorization request that omits the openid scope.

Details

Vulnerable code

OpenIDImplicitGrant.validate_authorization_request in authlib/oidc/core/grants/implicit.py:

def validate_authorization_request(self):
    if not is_openid_scope(self.request.payload.scope):
        raise InvalidScopeError(
            "Missing 'openid' scope",
            redirect_uri=self.request.payload.redirect_uri,  # ← raw, unvalidated
            redirect_fragment=True,
        )
    redirect_uri = super().validate_authorization_request()
    ...

OpenIDHybridGrant.validate_authorization_request in authlib/oidc/core/grants/hybrid.py shares the same pattern.

Root cause

Both methods perform the openid scope presence check before delegating to super().validate_authorization_request(), which is where AuthorizationEndpointMixin.validate_authorization_redirect_uri validates the requested redirect_uri against the client's check_redirect_uri(...). The InvalidScopeError thrown by the scope check therefore carries attacker-controlled self.request.payload.redirect_uri.

OAuth2Error.__call__ in authlib/oauth2/base.py renders any error with a non-empty redirect_uri as an HTTP 302:

def __call__(self, uri=None):
    if self.redirect_uri:
        params = self.get_body()
        loc = add_params_to_uri(self.redirect_uri, params, self.redirect_fragment)
        return 302, "", [("Location", loc)]
    return super().__call__(uri=uri)

A malformed authorization request that selects OpenIDImplicitGrant or OpenIDHybridGrant and omits the openid scope is therefore redirected to a fully attacker-chosen URL.

This is a variant of the issue fixed in commit 3be08468 ("fix: redirecting to unvalidated redirect_uri on UnsupportedResponseTypeError") that was missed in the OIDC Implicit and Hybrid grants.

Preconditions

The server registers OpenIDImplicitGrant or OpenIDHybridGrant (standard OIDC Implicit or Hybrid flow support).
The attacker's request uses a response_type that matches either grant: id_token, id_token token, code id_token, code token, or code id_token token.
scope does not contain openid.
Any redirect_uri value.

No user authentication, no consent, no valid session, no CSRF token, and — notably — no valid client_id are required. The scope check runs before any client lookup, so any client_id value (including nonexistent ones) reaches the vulnerable code path.

PoC

The following unauthenticated GET is sufficient to induce the authorization server to redirect a victim's browser to an attacker-controlled URL:

GET /oauth/authorize
    ?response_type=id_token
    &client_id=anything
    &scope=profile
    &redirect_uri=https%3A%2F%2Fevil.example.com%2Fphish
    &state=s&nonce=n  HTTP/1.1
Host: victim-op.example

Server response:

HTTP/1.1 302 Found
Location: https://evil.example.com/phish#error=invalid_scope&error_description=Missing+%27openid%27+scope&state=s

Impact

Open redirect from a trusted authorization server origin. Victims receiving a phishing link see the legitimate OIDC provider's domain in the URL bar at the moment they click. The authorization server itself issues the 302 to the attacker's page, lending the attacker's landing page the OP's reputation and potentially satisfying domain-allow-list controls that trust the OP.
Phishing / credential harvesting leverage. The attacker's page can mimic the legitimate OP's consent screen or a relying-party error page to solicit credentials, MFA codes, or to continue a downstream confused-deputy attack.
RFC violation. RFC 6749 §4.1.2.1 and RFC 9700 (OAuth 2.0 Security BCP) §4.11 both state that an authorization server MUST NOT perform redirection to a redirect_uri that has not been validated against the client's registered URIs, even in error responses. The state parameter is echoed back, giving the attacker site a stable correlator.
No direct token/code leak. This flaw fires before any authorization decision, so no authorization codes, ID tokens, or access tokens are disclosed. The impact is limited to open-redirect phishing leverage. Combined with other issues (e.g., downstream SSO trust chains) it may contribute to account-takeover chains; on its own it is a Medium-severity open redirect.

Affected deployments

Any application using Authlib as an OIDC provider that registers OpenIDImplicitGrant and/or OpenIDHybridGrant — i.e. anyone supporting the Implicit flow or the Hybrid flow (response_type=code id_token, etc.) — is affected. Clients of an Authlib-based OP are not directly affected; this is a server-side issue.

Authorization servers that only register the plain AuthorizationCodeGrant (code flow, with or without PKCE and the OpenIDCode extension) are not affected by this specific variant: the code-flow grant validates redirect_uri before raising scope errors. If you were affected by the sibling issue fixed in 3be08468 (UnsupportedResponseTypeError), you should already be on 1.6.10 or later; this advisory is independent of that fix.

Suggested fix

The attached fix-oidc-open-redirect.patch reorders each method to delegate to its super (or call validate_code_authorization_request for Hybrid) first, and then performs the openid-scope check with the validated redirect_uri variable.

# authlib/oidc/core/grants/implicit.py
def validate_authorization_request(self):
    redirect_uri = super().validate_authorization_request()   # runs client + redirect_uri validation
    if not is_openid_scope(self.request.payload.scope):
        raise InvalidScopeError(
            "Missing 'openid' scope",
            redirect_uri=redirect_uri,                         # validated
            redirect_fragment=True,
        )
    try:
        validate_nonce(self.request, self.exists_nonce, required=True)
    except OAuth2Error as error:
        error.redirect_uri = redirect_uri
        error.redirect_fragment = True
        raise error
    return redirect_uri

An equivalent transform is applied to OpenIDHybridGrant.validate_authorization_request, invoking validate_code_authorization_request first and only then checking is_openid_scope.

Alternatively, inline a client = query_client(request.payload.client_id) + client.check_redirect_uri(request.payload.redirect_uri) guard before populating redirect_uri on the error — the pattern used in 3be08468.

The patch also adds regression tests analogous to test_unsupported_response_type_does_not_redirect from commit 3be08468, asserting rv.status_code == 400 and rv.headers.get("Location") is None for an unregistered redirect_uri with a non-openid scope.

Workarounds

No clean server-side workaround exists short of patching. Partial mitigations:

Unregister OpenIDImplicitGrant and OpenIDHybridGrant if the Implicit and Hybrid flows are not required. (RFC 9700 deprecates the Implicit flow and discourages Hybrid flows, so this is recommended anyway.)
Front the /authorize endpoint with a reverse proxy rule that rejects requests containing both a redirect_uri parameter and a scope that does not include openid when response_type matches the vulnerable set. This is fragile and not recommended as a primary control.

References

RFC 6749, §4.1.2.1 — Error Response (OAuth 2.0 authorization endpoint)
RFC 9700, §4.11 — Redirect URI validation
OpenID Connect Core 1.0, §3.2.2.6 / §3.3.2.6 — Authentication Error Response
Authlib commit 3be08468 — prior fix for the same class of issue in UnsupportedResponseTypeError (Authlib 1.6.10)
Authlib source (by symbol; verified in commit 5d2e603e):
OpenIDImplicitGrant.validate_authorization_request — authlib/oidc/core/grants/implicit.py
OpenIDHybridGrant.validate_authorization_request — authlib/oidc/core/grants/hybrid.py
OAuth2Error.__call__ — authlib/oauth2/base.py (renders errors with redirect_uri as HTTP 302)
AuthorizationEndpointMixin.validate_authorization_redirect_uri — authlib/oauth2/rfc6749/grants/base.py (the validation that is bypassed)

Severity

6.1 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "authlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.7.0"
            },
            {
              "fixed": "1.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.7.0"
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.6.11"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "authlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44681"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-13T01:36:03Z",
    "nvd_published_at": "2026-05-27T20:16:37Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nAn unauthenticated open redirect in Authlib\u0027s `OpenIDImplicitGrant` and `OpenIDHybridGrant` authorization endpoint lets a remote attacker cause the authorization server to issue an HTTP 302 to an attacker-chosen URL by submitting an authorization request that omits the `openid` scope.\n\n### Details\n\n#### Vulnerable code\n\n`OpenIDImplicitGrant.validate_authorization_request` in `authlib/oidc/core/grants/implicit.py`:\n\n```python\ndef validate_authorization_request(self):\n    if not is_openid_scope(self.request.payload.scope):\n        raise InvalidScopeError(\n            \"Missing \u0027openid\u0027 scope\",\n            redirect_uri=self.request.payload.redirect_uri,  # \u2190 raw, unvalidated\n            redirect_fragment=True,\n        )\n    redirect_uri = super().validate_authorization_request()\n    ...\n```\n\n`OpenIDHybridGrant.validate_authorization_request` in `authlib/oidc/core/grants/hybrid.py` shares the same pattern.\n\n#### Root cause\n\nBoth methods perform the `openid` scope presence check before delegating to `super().validate_authorization_request()`, which is where `AuthorizationEndpointMixin.validate_authorization_redirect_uri` validates the requested `redirect_uri` against the client\u0027s `check_redirect_uri(...)`. The `InvalidScopeError` thrown by the scope check therefore carries attacker-controlled `self.request.payload.redirect_uri`.\n\n`OAuth2Error.__call__` in `authlib/oauth2/base.py` renders any error with a non-empty `redirect_uri` as an HTTP 302:\n\n```python\ndef __call__(self, uri=None):\n    if self.redirect_uri:\n        params = self.get_body()\n        loc = add_params_to_uri(self.redirect_uri, params, self.redirect_fragment)\n        return 302, \"\", [(\"Location\", loc)]\n    return super().__call__(uri=uri)\n```\n\nA malformed authorization request that selects `OpenIDImplicitGrant` or `OpenIDHybridGrant` and omits the `openid` scope is therefore redirected to a fully attacker-chosen URL.\n\nThis is a variant of the issue fixed in commit [`3be08468`](https://github.com/authlib/authlib/commit/3be08468) (\"fix: redirecting to unvalidated `redirect_uri` on `UnsupportedResponseTypeError`\") that was missed in the OIDC Implicit and Hybrid grants.\n\n#### Preconditions\n\n1. The server registers `OpenIDImplicitGrant` or `OpenIDHybridGrant` (standard OIDC Implicit or Hybrid flow support).\n2. The attacker\u0027s request uses a `response_type` that matches either grant: `id_token`, `id_token token`, `code id_token`, `code token`, or `code id_token token`.\n3. `scope` does not contain `openid`.\n4. Any `redirect_uri` value.\n\nNo user authentication, no consent, no valid session, no CSRF token, and \u2014 notably \u2014 no valid `client_id` are required. The scope check runs before any client lookup, so any `client_id` value (including nonexistent ones) reaches the vulnerable code path.\n\n### PoC\n\nThe following unauthenticated GET is sufficient to induce the authorization server to redirect a victim\u0027s browser to an attacker-controlled URL:\n\n```\nGET /oauth/authorize\n    ?response_type=id_token\n    \u0026client_id=anything\n    \u0026scope=profile\n    \u0026redirect_uri=https%3A%2F%2Fevil.example.com%2Fphish\n    \u0026state=s\u0026nonce=n  HTTP/1.1\nHost: victim-op.example\n```\n\nServer response:\n\n```\nHTTP/1.1 302 Found\nLocation: https://evil.example.com/phish#error=invalid_scope\u0026error_description=Missing+%27openid%27+scope\u0026state=s\n```\n\n### Impact\n\n- Open redirect from a trusted authorization server origin. Victims receiving a phishing link see the legitimate OIDC provider\u0027s domain in the URL bar at the moment they click. The authorization server itself issues the 302 to the attacker\u0027s page, lending the attacker\u0027s landing page the OP\u0027s reputation and potentially satisfying domain-allow-list controls that trust the OP.\n- Phishing / credential harvesting leverage. The attacker\u0027s page can mimic the legitimate OP\u0027s consent screen or a relying-party error page to solicit credentials, MFA codes, or to continue a downstream confused-deputy attack.\n- RFC violation. RFC 6749 \u00a74.1.2.1 and RFC 9700 (OAuth 2.0 Security BCP) \u00a74.11 both state that an authorization server MUST NOT perform redirection to a `redirect_uri` that has not been validated against the client\u0027s registered URIs, even in error responses. The `state` parameter is echoed back, giving the attacker site a stable correlator.\n- No direct token/code leak. This flaw fires before any authorization decision, so no authorization codes, ID tokens, or access tokens are disclosed. The impact is limited to open-redirect phishing leverage. Combined with other issues (e.g., downstream SSO trust chains) it may contribute to account-takeover chains; on its own it is a Medium-severity open redirect.\n\n#### Affected deployments\n\nAny application using Authlib as an OIDC provider that registers `OpenIDImplicitGrant` and/or `OpenIDHybridGrant` \u2014 i.e. anyone supporting the Implicit flow or the Hybrid flow (`response_type=code id_token`, etc.) \u2014 is affected. Clients of an Authlib-based OP are not directly affected; this is a server-side issue.\n\nAuthorization servers that only register the plain `AuthorizationCodeGrant` (code flow, with or without PKCE and the `OpenIDCode` extension) are not affected by this specific variant: the code-flow grant validates `redirect_uri` before raising scope errors. If you were affected by the sibling issue fixed in `3be08468` (`UnsupportedResponseTypeError`), you should already be on `1.6.10` or later; this advisory is independent of that fix.\n\n### Suggested fix\n\nThe attached `fix-oidc-open-redirect.patch` reorders each method to delegate to its super (or call `validate_code_authorization_request` for Hybrid) first, and then performs the `openid`-scope check with the validated `redirect_uri` variable.\n\n```python\n# authlib/oidc/core/grants/implicit.py\ndef validate_authorization_request(self):\n    redirect_uri = super().validate_authorization_request()   # runs client + redirect_uri validation\n    if not is_openid_scope(self.request.payload.scope):\n        raise InvalidScopeError(\n            \"Missing \u0027openid\u0027 scope\",\n            redirect_uri=redirect_uri,                         # validated\n            redirect_fragment=True,\n        )\n    try:\n        validate_nonce(self.request, self.exists_nonce, required=True)\n    except OAuth2Error as error:\n        error.redirect_uri = redirect_uri\n        error.redirect_fragment = True\n        raise error\n    return redirect_uri\n```\n\nAn equivalent transform is applied to `OpenIDHybridGrant.validate_authorization_request`, invoking `validate_code_authorization_request` first and only then checking `is_openid_scope`.\n\nAlternatively, inline a `client = query_client(request.payload.client_id)` + `client.check_redirect_uri(request.payload.redirect_uri)` guard before populating `redirect_uri` on the error \u2014 the pattern used in `3be08468`.\n\nThe patch also adds regression tests analogous to `test_unsupported_response_type_does_not_redirect` from commit `3be08468`, asserting `rv.status_code == 400` and `rv.headers.get(\"Location\") is None` for an unregistered `redirect_uri` with a non-`openid` scope.\n\n### Workarounds\n\nNo clean server-side workaround exists short of patching. Partial mitigations:\n\n- Unregister `OpenIDImplicitGrant` and `OpenIDHybridGrant` if the Implicit and Hybrid flows are not required. (RFC 9700 deprecates the Implicit flow and discourages Hybrid flows, so this is recommended anyway.)\n- Front the `/authorize` endpoint with a reverse proxy rule that rejects requests containing both a `redirect_uri` parameter and a `scope` that does not include `openid` when `response_type` matches the vulnerable set. This is fragile and not recommended as a primary control.\n\n### References\n\n- RFC 6749, \u00a74.1.2.1 \u2014 Error Response (OAuth 2.0 authorization endpoint)\n- RFC 9700, \u00a74.11 \u2014 Redirect URI validation\n- OpenID Connect Core 1.0, \u00a73.2.2.6 / \u00a73.3.2.6 \u2014 Authentication Error Response\n- Authlib commit [`3be08468`](https://github.com/authlib/authlib/commit/3be08468) \u2014 prior fix for the same class of issue in `UnsupportedResponseTypeError` (Authlib 1.6.10)\n- Authlib source (by symbol; verified in commit `5d2e603e`):\n  - `OpenIDImplicitGrant.validate_authorization_request` \u2014 `authlib/oidc/core/grants/implicit.py`\n  - `OpenIDHybridGrant.validate_authorization_request` \u2014 `authlib/oidc/core/grants/hybrid.py`\n  - `OAuth2Error.__call__` \u2014 `authlib/oauth2/base.py` (renders errors with `redirect_uri` as HTTP 302)\n  - `AuthorizationEndpointMixin.validate_authorization_redirect_uri` \u2014 `authlib/oauth2/rfc6749/grants/base.py` (the validation that is bypassed)",
  "id": "GHSA-r95x-qfjj-fjj2",
  "modified": "2026-06-08T23:53:47Z",
  "published": "2026-05-13T01:36:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-r95x-qfjj-fjj2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44681"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/releases/tag/v1.6.12"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/releases/tag/v1.7.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-188.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Authlib OIDC Implicit/Hybrid Authorization Vulnerable to Open Redirect"
}

GHSA-R979-3CMV-8P2V

Vulnerability from github – Published: 2022-05-13 01:36 – Updated: 2022-05-13 01:36

Details

Foreman since version 1.5 is vulnerable to an incorrect authorization check due to which users with user management permission who are assigned to some organization(s) can do all operations granted by these permissions on all administrator user object outside of their scope, such as editing global admin accounts including changing their passwords.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2017-7505"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-26T16:29:00Z",
    "severity": "HIGH"
  },
  "details": "Foreman since version 1.5 is vulnerable to an incorrect authorization check due to which users with user management permission who are assigned to some organization(s) can do all operations granted by these permissions on all administrator user object outside of their scope, such as editing global admin accounts including changing their passwords.",
  "id": "GHSA-r979-3cmv-8p2v",
  "modified": "2022-05-13T01:36:20Z",
  "published": "2022-05-13T01:36:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7505"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theforeman/foreman/pull/4545"
    },
    {
      "type": "WEB",
      "url": "http://projects.theforeman.org/issues/19612"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/98607"
    }
  ],
  "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-R97V-6JQR-X4GV

Vulnerability from github – Published: 2022-06-08 00:00 – Updated: 2022-06-12 00:00

Details

Improper caller check in AR Emoji prior to SMR Jun-2022 Release 1 allows untrusted applications to use some camera functions via deeplink.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-30717"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-07T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "Improper caller check in AR Emoji prior to SMR Jun-2022 Release 1 allows untrusted applications to use some camera functions via deeplink.",
  "id": "GHSA-r97v-6jqr-x4gv",
  "modified": "2022-06-12T00:00:47Z",
  "published": "2022-06-08T00:00:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30717"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2022\u0026month=6"
    }
  ],
  "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"
    }
  ]
}

GHSA-R989-CJHX-3V49

Vulnerability from github – Published: 2026-06-17 18:35 – Updated: 2026-06-18 14:32

Summary

Apache DolphinScheduler: DataSource API Missing Authorization Check Leads to Arbitrary Data Source Metadata Disclosure

Details

DataSource API Missing Authorization Check Leads to Arbitrary Data Source Metadata Disclosure in Apache DolphinScheduler.

This issue affects Apache DolphinScheduler: before 3.4.2.

Users are recommended to upgrade to version 3.4.2, which fixes the issue.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.dolphinscheduler:dolphinscheduler-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32966"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:32:18Z",
    "nvd_published_at": "2026-06-17T13:20:16Z",
    "severity": "CRITICAL"
  },
  "details": "DataSource API Missing Authorization Check Leads to Arbitrary Data Source Metadata Disclosure in Apache DolphinScheduler.\n\nThis issue affects Apache DolphinScheduler: before 3.4.2.\n\nUsers are recommended to upgrade to version 3.4.2, which fixes the issue.",
  "id": "GHSA-r989-cjhx-3v49",
  "modified": "2026-06-18T14:32:19Z",
  "published": "2026-06-17T18:35:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32966"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/dolphinscheduler"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/4f1fojpj26z9y5nd1ko845gcknpn75g2"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/06/17/2"
    }
  ],
  "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"
    }
  ],
  "summary": "Apache DolphinScheduler: DataSource API Missing Authorization Check Leads to Arbitrary Data Source Metadata Disclosure "
}

GHSA-R9R2-6P7X-XRRR

Vulnerability from github – Published: 2023-07-17 18:31 – Updated: 2024-04-04 06:10

Details

Mattermost fails to verify channel membership when linking a board to a channel allowing a low-privileged authenticated user to link a Board to a private channel they don't have access to,

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-3582"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-17T16:15:10Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost fails to verify channel membership when linking a board to a channel allowing a low-privileged authenticated user to link a Board to a private channel they don\u0027t have access to,\u00a0\n\n",
  "id": "GHSA-r9r2-6p7x-xrrr",
  "modified": "2024-04-04T06:10:45Z",
  "published": "2023-07-17T18:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3582"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "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"
    }
  ]
}

GHSA-R9VR-4RJX-2PXV

Vulnerability from github – Published: 2023-05-08 21:31 – Updated: 2024-04-04 03:51

Details

The issue was addressed with improved checks. This issue is fixed in macOS Ventura 13.3, macOS Monterey 12.6.4, macOS Big Sur 11.7.5. An archive may be able to bypass Gatekeeper

Severity

5.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-27951"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-08T20:15:18Z",
    "severity": "MODERATE"
  },
  "details": "The issue was addressed with improved checks. This issue is fixed in macOS Ventura 13.3, macOS Monterey 12.6.4, macOS Big Sur 11.7.5. An archive may be able to bypass Gatekeeper",
  "id": "GHSA-r9vr-4rjx-2pxv",
  "modified": "2024-04-04T03:51:59Z",
  "published": "2023-05-08T21:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27951"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213670"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213675"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213677"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R9W6-RHH9-7V53

Vulnerability from github – Published: 2021-07-28 17:57 – Updated: 2021-07-27 15:08

Summary

Incorrect Authorization in HashiCorp Consul

Details

HashiCorp Consul and Consul Enterprise 1.4.1 through 1.6.2 did not uniformly enforce ACLs across all API endpoints, resulting in potential unintended information disclosure. Fixed in 1.6.3.

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

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.6.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hashicorp/consul"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.1"
            },
            {
              "fixed": "1.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-7955"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-07-27T15:08:01Z",
    "nvd_published_at": "2020-01-31T13:15:00Z",
    "severity": "MODERATE"
  },
  "details": "HashiCorp Consul and Consul Enterprise 1.4.1 through 1.6.2 did not uniformly enforce ACLs across all API endpoints, resulting in potential unintended information disclosure. Fixed in 1.6.3.",
  "id": "GHSA-r9w6-rhh9-7v53",
  "modified": "2021-07-27T15:08:01Z",
  "published": "2021-07-28T17:57:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7955"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashicorp/consul/issues/7160"
    },
    {
      "type": "WEB",
      "url": "https://www.hashicorp.com/blog/category/consul"
    }
  ],
  "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"
    }
  ],
  "summary": "Incorrect Authorization in HashiCorp Consul"
}

GHSA-RC4R-WH2Q-Q6C4

Vulnerability from github – Published: 2022-09-16 21:00 – Updated: 2025-01-17 15:55

Summary

Docker supplementary group permissions not set up properly, allowing attackers to bypass primary group restrictions

Details

Moby is an open-source project created by Docker to enable software containerization. A bug was found in Moby (Docker Engine) where supplementary groups are not set up properly. If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container. This bug is fixed in Moby (Docker Engine) 20.10.18. Users should update to this version when it is available. Running containers should be stopped and restarted for the permissions to be fixed. For users unable to upgrade, this problem can be worked around by not using the "USER $USERNAME" Dockerfile instruction. Instead by calling ENTRYPOINT ["su", "-", "user"] the supplementary groups will be set up properly.

Thanks to Steven Murdoch for reporting this issue.

Impact

If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container.

Patches

This bug is fixed in Moby (Docker Engine) 20.10.18. Users should update to this version when it is available.

Workarounds

This problem can be worked around by not using the "USER $USERNAME" Dockerfile instruction. Instead by calling ENTRYPOINT ["su", "-", "user"] the supplementary groups will be set up properly.

References

https://www.benthamsgaze.org/2022/08/22/vulnerability-in-linux-containers-investigation-and-mitigation/

For more information

If you have any questions or comments about this advisory:

Open an issue
Email us at security@docker.com

Severity

5.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "20.10.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-36109"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-16T21:00:46Z",
    "nvd_published_at": "2022-09-09T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Moby is an open-source project created by Docker to enable software containerization. A bug was found in Moby (Docker Engine) where supplementary groups are not set up properly. If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container.  This bug is fixed in Moby (Docker Engine) 20.10.18. Users should update to this version when it is available. Running containers should be stopped and restarted for the permissions to be fixed. For users unable to upgrade, this problem can be worked around by not using the `\"USER $USERNAME\"` Dockerfile instruction. Instead by calling `ENTRYPOINT [\"su\", \"-\", \"user\"]` the supplementary groups will be set up properly.\n\nThanks to Steven Murdoch for reporting this issue.\n\n----\n\n### Impact\n\nIf an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container. \n\n### Patches\n\n This bug is fixed in Moby (Docker Engine) 20.10.18. Users should update to this version when it is available.\n\n### Workarounds\n\nThis problem can be worked around by not using the `\"USER $USERNAME\"` Dockerfile instruction. Instead by calling `ENTRYPOINT [\"su\", \"-\", \"user\"]` the supplementary groups will be set up properly.\n\n### References\n\nhttps://www.benthamsgaze.org/2022/08/22/vulnerability-in-linux-containers-investigation-and-mitigation/\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* [Open an issue](https://github.com/moby/moby/issues/new)\n* Email us at [security@docker.com](mailto:security@docker.com)\n",
  "id": "GHSA-rc4r-wh2q-q6c4",
  "modified": "2025-01-17T15:55:20Z",
  "published": "2022-09-16T21:00:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-rc4r-wh2q-q6c4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36109"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/commit/de7af816e76a7fd3fbf06bffa6832959289fba32"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moby/moby"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/releases/tag/v20.10.18"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/O7JL2QA3RB732MLJ3RMUXB3IB7AA22YU"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RQQ4E3JBXVR3VK5FIZVJ3QS2TAOOXXTQ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/O7JL2QA3RB732MLJ3RMUXB3IB7AA22YU"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RQQ4E3JBXVR3VK5FIZVJ3QS2TAOOXXTQ"
    },
    {
      "type": "WEB",
      "url": "https://www.benthamsgaze.org/2022/08/22/vulnerability-in-linux-containers-investigation-and-mitigation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Docker supplementary group permissions not set up properly, allowing attackers to bypass primary group restrictions"
}

GHSA-RC5C-4C27-CG98

Vulnerability from github – Published: 2022-05-12 00:01 – Updated: 2022-05-20 00:00

Details

Under certain conditions, the SAP Host Agent logfile shows information which would otherwise be restricted.

Severity

5.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-28774"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-532",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-11T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Under certain conditions, the SAP Host Agent logfile shows information which would otherwise be restricted.",
  "id": "GHSA-rc5c-4c27-cg98",
  "modified": "2022-05-20T00:00:40Z",
  "published": "2022-05-12T00:01:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28774"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/3158188"
    },
    {
      "type": "WEB",
      "url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RC8X-G2JF-PCR5

Vulnerability from github – Published: 2022-05-13 01:18 – Updated: 2022-05-13 01:18

Details

Microsoft Edge in Microsoft Windows 10 Gold, 1511, 1607, 1703, 1709, and Windows Server 2016 allows an attacker to access information from one domain and inject it into another domain, due to how Microsoft Edge enforces cross-domain policies, aka "Microsoft Edge Elevation of Privilege Vulnerability".

Severity

4.2 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2018-0803"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-01-04T14:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Microsoft Edge in Microsoft Windows 10 Gold, 1511, 1607, 1703, 1709, and Windows Server 2016 allows an attacker to access information from one domain and inject it into another domain, due to how Microsoft Edge enforces cross-domain policies, aka \"Microsoft Edge Elevation of Privilege Vulnerability\".",
  "id": "GHSA-rc8x-g2jf-pcr5",
  "modified": "2022-05-13T01:18:30Z",
  "published": "2022-05-13T01:18:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0803"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-0803"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/102384"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1040100"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/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