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.

5537 vulnerabilities reference this CWE, most recent first.

GHSA-P279-63M3-GP38

Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2022-07-13 00:01
VLAI
Details

Improper access control vulnerability in Bulletin Board of Cybozu Office 10.0.0 to 10.8.4 allows an authenticated attacker to bypass access restriction and alter the data of Bulletin Board via unspecified vectors.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-20625"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-18T01:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper access control vulnerability in Bulletin Board of Cybozu Office 10.0.0 to 10.8.4 allows an authenticated attacker to bypass access restriction and alter the data of Bulletin Board via unspecified vectors.",
  "id": "GHSA-p279-63m3-gp38",
  "modified": "2022-07-13T00:01:05Z",
  "published": "2022-05-24T17:44:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20625"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN45797538/index.html"
    },
    {
      "type": "WEB",
      "url": "https://kb.cybozu.support/article/36874"
    }
  ],
  "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-P28R-F42X-QMM2

Vulnerability from github – Published: 2023-01-11 03:30 – Updated: 2025-04-07 21:31
VLAI
Details

In the GrowthExperiments extension for MediaWiki through 1.39, the growthmanagementorlist API allows blocked users (blocked in ApiManageMentorList) to enroll as mentors or edit any of their mentorship-related properties.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-22945"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-11T01:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In the GrowthExperiments extension for MediaWiki through 1.39, the growthmanagementorlist API allows blocked users (blocked in ApiManageMentorList) to enroll as mentors or edit any of their mentorship-related properties.",
  "id": "GHSA-p28r-f42x-qmm2",
  "modified": "2025-04-07T21:31:40Z",
  "published": "2023-01-11T03:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22945"
    },
    {
      "type": "WEB",
      "url": "https://gerrit.wikimedia.org/r/q/Id1b83fcd58eccb8b2dfea44a3ab2f72314860d88"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/AP65YEN762IBNQPOYGUVLTQIDLM5XD2A"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AP65YEN762IBNQPOYGUVLTQIDLM5XD2A"
    },
    {
      "type": "WEB",
      "url": "https://phabricator.wikimedia.org/T321733"
    }
  ],
  "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-P2C8-CRG8-P2J7

Vulnerability from github – Published: 2025-09-10 00:31 – Updated: 2025-09-10 00:31
VLAI
Details

Incorrect authorization in certain Zoom Workplace Clients for Windows may allow an authenticated user to conduct an impact to integrity via network access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-58134"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-09T22:15:33Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect authorization in certain Zoom Workplace Clients for Windows may allow an authenticated user to conduct an impact to integrity via network access.",
  "id": "GHSA-p2c8-crg8-p2j7",
  "modified": "2025-09-10T00:31:01Z",
  "published": "2025-09-10T00:31:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58134"
    },
    {
      "type": "WEB",
      "url": "https://www.zoom.com/en/trust/security-bulletin/ZSB-25035"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P2F6-35C3-Q43F

Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-08-16 00:00
VLAI
Details

IOMMU page mapping issues on x86 T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Both AMD and Intel allow ACPI tables to specify regions of memory which should be left untranslated, which typically means these addresses should pass the translation phase unaltered. While these are typically device specific ACPI properties, they can also be specified to apply to a range of devices, or even all devices. On all systems with such regions Xen failed to prevent guests from undoing/replacing such mappings (CVE-2021-28694). On AMD systems, where a discontinuous range is specified by firmware, the supposedly-excluded middle range will also be identity-mapped (CVE-2021-28695). Further, on AMD systems, upon de-assigment of a physical device from a guest, the identity mappings would be left in place, allowing a guest continued access to ranges of memory which it shouldn't have access to anymore (CVE-2021-28696).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-28696"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-27T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IOMMU page mapping issues on x86 T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Both AMD and Intel allow ACPI tables to specify regions of memory which should be left untranslated, which typically means these addresses should pass the translation phase unaltered. While these are typically device specific ACPI properties, they can also be specified to apply to a range of devices, or even all devices. On all systems with such regions Xen failed to prevent guests from undoing/replacing such mappings (CVE-2021-28694). On AMD systems, where a discontinuous range is specified by firmware, the supposedly-excluded middle range will also be identity-mapped (CVE-2021-28695). Further, on AMD systems, upon de-assigment of a physical device from a guest, the identity mappings would be left in place, allowing a guest continued access to ranges of memory which it shouldn\u0027t have access to anymore (CVE-2021-28696).",
  "id": "GHSA-p2f6-35c3-q43f",
  "modified": "2022-08-16T00:00:44Z",
  "published": "2022-05-24T19:12:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28696"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2VQCFAPBNGBBAOMJZG6QBREOG5IIDZID"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/FZCNPSRPGFCQRYE2BI4D4Q4SCE56ANV2"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LPRVHW4J4ZCPPOHZEWP5MOJT7XDGFFPJ"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202208-23"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4977"
    },
    {
      "type": "WEB",
      "url": "https://xenbits.xenproject.org/xsa/advisory-378.txt"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2021/09/01/1"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2021/09/01/5"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2021/09/01/6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P2FR-6HMX-4528

Vulnerability from github – Published: 2026-07-07 20:54 – Updated: 2026-07-07 20:54
VLAI
Summary
@better-auth/oauth-provider may provide access tokens for unauthorized audiences via unbound resource indicators
Details

Am I affected?

Users are affected if all of the following hold:

  • Their application depends on @better-auth/oauth-provider on any stable 1.6.x release (the stable line is not patched) or on a pre-release before 1.7.0-beta.4.
  • Their application either configures validAudienceswith more than one audience, or it issues JWT access tokens whoseaud`  (resource) claim is consumed by their resource servers.
  • Their resource servers make authorization decisions based on that aud or resource value.

A deployment with a single validAudiences entry (or the default, their server's base URL) cannot mint a token for a different audience. The provider rejects any resource outside the allowlist. Such a deployment still does not bind the resource to the authorization grant, so the spec-compliance gap remains even where cross-audience escalation does not apply.

Fix:

  1. Upgrade to @better-auth/oauth-provider@1.7.0-beta.4 (then 1.7.0), then run the schema migration (npx auth migrate). This is a breaking change: a token or refresh request may only narrow the authorized resource, an uncovered resource returns invalid_target, and customAccessTokenClaims receives a resources array in place of resource.
  2. The 1.6.x stable line is not patched. If an application stays on it, developers should apply the workarounds below.

Summary

@better-auth/oauth-provider lets an OAuth client choose the access-token audience through the RFC 8707 resource parameter at the token endpoint. It does not bind that choice to the authorization grant. A client that completes a normal authorization flow can request a JWT access token whose audience targets a resource server the authorization never covered. The only constraint is that the resource appears in the server's validAudiences allowlist. The same gap applies to the refresh grant: a refresh token issued in a flow targeting one resource can be redeemed for an access token bound to a different allow-listed resource.

Details

The provider accepts resource only at the token endpoint, never at the authorization endpoint. At /oauth2/token it validates each requested resource against the server-wide validAudiences allowlist and writes the result into the JWT aud claim. It does not record the requested resources on the authorization code, and it does not store them on the refresh-token row.

Two consequences follow. For the authorization-code grant, the resource a client states at /oauth2/authorize is discarded, and the resource it sends at /oauth2/token is honored on its own, checked only against the allowlist. For the refresh grant, the audience is re-derived from the refresh request body alone, because no resource from the original grant is retained to constrain it. In both cases the audience becomes a per-request, client-chosen value rather than a property of the authorization.

This diverges from RFC 8707. The specification expects the authorization server to record the resources requested at authorization, then let the token endpoint narrow them but never widen them. A refresh token should stay bound to the resources of the original grant.

Patches

Fixed in @better-auth/oauth-provider@1.7.0-beta.4 (then 1.7.0). The fix records the requested resources at authorization, stores them with the authorization code, enforces subset narrowing at the token endpoint, retains the original resource set across refresh, and exposes aud at introspection. The 1.6.x stable line is not patched.

The fix is a breaking change. It replaces customAccessTokenClaims.resource with a resources array, returns invalid_target for a resource the authorization did not cover, and adds a schema field that requires a migration. After upgrading, run npx auth migrate (or npx auth generate if developers manage the schema themselves).

Workarounds

If developers cannot upgrade their applications:

  • Set validAudiences to a single audience, or leave it unset so it defaults to their application's base URL. The provider then rejects any other requested resource, which removes cross-audience selection.
  • Configure each resource server to accept a token only when its own identifier is the expected audience, and to reject tokens whose aud is an array that also lists other audiences.
  • Do not rely on the resource indicator as an authorization boundary until developers run a release that contains the fix.

Impact

An attacker who can complete an OAuth flow for a registered client can obtain an access token whose audience points at a resource server that the user's authorization never covered. Where resource servers enforce the aud or resource value for authorization, a token granted for one resource becomes usable at another. The reachable data and operations stay limited to the scopes granted to that client, since the provider checks scopes independently of the resource.

Credit

Reported and fixed by @dvanmali.

Resources

  • RFC 8707, "Resource Indicators for OAuth 2.0", Section 2.2 "Access Token Request": https://www.rfc-editor.org/rfc/rfc8707#section-2.2
  • RFC 9068, "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", Section 2.2 "Data Structure": https://www.rfc-editor.org/rfc/rfc9068#section-2.2
  • CWE-863, "Incorrect Authorization": https://cwe.mitre.org/data/definitions/863.html
  • CWE-285, "Improper Authorization": https://cwe.mitre.org/data/definitions/285.html
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@better-auth/oauth-provider"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.8"
            },
            {
              "fixed": "1.7.0-beta.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-07T20:54:32Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Am I affected?\n\nUsers are affected if all of the following hold:\n\n-  Their application depends on `@better-auth/oauth-provider` on any stable `1.6.x` release (the stable line is not patched) or on a pre-release before `1.7.0-beta.4`.\n- Their application either configures validAudiences` with more than one audience, or it issues JWT access tokens whose `aud`\u00a0 (resource) claim is consumed by their resource servers.\n- Their resource servers make authorization decisions based on that `aud` or resource value.\n\nA deployment with a single `validAudiences` entry (or the default, their server\u0027s base URL) cannot mint a token for a different audience. The provider rejects any resource outside the allowlist. Such a deployment still does not bind the resource to the authorization grant, so the spec-compliance gap remains even where cross-audience escalation does not apply.\n\nFix:\n\n1. Upgrade to `@better-auth/oauth-provider@1.7.0-beta.4` (then `1.7.0`), then run the schema migration (`npx auth migrate`). This is a breaking change: a token or refresh request may only narrow the authorized `resource`, an uncovered resource returns `invalid_target`, and `customAccessTokenClaims` receives a `resources` array in place of `resource`.\n2. The `1.6.x` stable line is not patched. If an application stays on it, developers should apply the workarounds below.\n\n### Summary\n\n`@better-auth/oauth-provider` lets an OAuth client choose the access-token audience through the RFC 8707 `resource` parameter at the token endpoint. It does not bind that choice to the authorization grant. A client that completes a normal authorization flow can request a JWT access token whose audience targets a resource server the authorization never covered. The only constraint is that the resource appears in the server\u0027s `validAudiences` allowlist. The same gap applies to the refresh grant: a refresh token issued in a flow targeting one resource can be redeemed for an access token bound to a different allow-listed resource.\n\n### Details\n\nThe provider accepts `resource` only at the token endpoint, never at the authorization endpoint. At `/oauth2/token` it validates each requested resource against the server-wide `validAudiences` allowlist and writes the result into the JWT `aud` claim. It does not record the requested resources on the authorization code, and it does not store them on the refresh-token row.\n\nTwo consequences follow. For the authorization-code grant, the resource a client states at `/oauth2/authorize` is discarded, and the resource it sends at `/oauth2/token` is honored on its own, checked only against the allowlist. For the refresh grant, the audience is re-derived from the refresh request body alone, because no resource from the original grant is retained to constrain it. In both cases the audience becomes a per-request, client-chosen value rather than a property of the authorization.\n\nThis diverges from RFC 8707. The specification expects the authorization server to record the resources requested at authorization, then let the token endpoint narrow them but never widen them. A refresh token should stay bound to the resources of the original grant.\n\n### Patches\n\nFixed in `@better-auth/oauth-provider@1.7.0-beta.4` (then `1.7.0`). The fix records the requested resources at authorization, stores them with the authorization code, enforces subset narrowing at the token endpoint, retains the original resource set across refresh, and exposes `aud` at introspection. The `1.6.x` stable line is not patched.\n\nThe fix is a breaking change. It replaces `customAccessTokenClaims.resource` with a `resources` array, returns `invalid_target` for a resource the authorization did not cover, and adds a schema field that requires a migration. After upgrading, run `npx auth migrate` (or `npx auth generate` if developers manage the schema themselves).\n\n### Workarounds\n\nIf developers cannot upgrade their applications:\n\n- Set `validAudiences` to a single audience, or leave it unset so it defaults to their application\u0027s base URL. The provider then rejects any other requested resource, which removes cross-audience selection.\n- Configure each resource server to accept a token only when its own identifier is the expected audience, and to reject tokens whose `aud` is an array that also lists other audiences.\n- Do not rely on the `resource` indicator as an authorization boundary until developers run a release that contains the fix.\n\n### Impact\n\nAn attacker who can complete an OAuth flow for a registered client can obtain an access token whose audience points at a resource server that the user\u0027s authorization never covered. Where resource servers enforce the `aud` or resource value for authorization, a token granted for one resource becomes usable at another. The reachable data and operations stay limited to the scopes granted to that client, since the provider checks scopes independently of the resource.\n\n### Credit\n\nReported and fixed by @dvanmali.\n\n### Resources\n\n- RFC 8707, \"Resource Indicators for OAuth 2.0\", Section 2.2 \"Access Token Request\": https://www.rfc-editor.org/rfc/rfc8707#section-2.2\n- RFC 9068, \"JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens\", Section 2.2 \"Data Structure\": https://www.rfc-editor.org/rfc/rfc9068#section-2.2\n- CWE-863, \"Incorrect Authorization\": https://cwe.mitre.org/data/definitions/863.html\n- CWE-285, \"Improper Authorization\": https://cwe.mitre.org/data/definitions/285.html",
  "id": "GHSA-p2fr-6hmx-4528",
  "modified": "2026-07-07T20:54:32Z",
  "published": "2026-07-07T20:54:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-p2fr-6hmx-4528"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/better-auth/better-auth"
    },
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/releases/tag/v1.7.0-beta.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@better-auth/oauth-provider may provide access tokens for unauthorized audiences via unbound resource indicators"
}

GHSA-P2GR-HM8G-Q772

Vulnerability from github – Published: 2025-12-30 21:30 – Updated: 2025-12-31 22:08
VLAI
Summary
Temporal has a namespace policy bypass allowing requests to be authorized for incorrect contexts
Details

When frontend.enableExecuteMultiOperation is enabled, the server can apply namespace-scoped validation and feature gates for the embedded StartWorkflowExecutionRequest using its Namespace field rather than the outer, authorized ExecuteMultiOperationRequest.Namespace. This allows a caller authorized for one namespace to bypass that namespace's limits/policies by setting the embedded start request's namespace to a different namespace. The workflow is still created in the outer (authorized) namespace; only validation/gating is performed under the wrong namespace context. This issue affects Temporal: from 1.24.0 through 1.29.1. Fixed in 1.27.4, 1.28.2, 1.29.2.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.temporal.io/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.24.0"
            },
            {
              "fixed": "1.27.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.temporal.io/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.28.0"
            },
            {
              "fixed": "1.28.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.temporal.io/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.29.0"
            },
            {
              "fixed": "1.29.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-14986"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-31T22:08:24Z",
    "nvd_published_at": "2025-12-30T21:15:42Z",
    "severity": "LOW"
  },
  "details": "When frontend.enableExecuteMultiOperation is enabled, the server can apply namespace-scoped validation and feature gates for the embedded StartWorkflowExecutionRequest using its Namespace field rather than the outer, authorized ExecuteMultiOperationRequest.Namespace. This allows a caller authorized for one namespace to bypass that namespace\u0027s limits/policies by setting the embedded start request\u0027s namespace to a different namespace. The workflow is still created in the outer (authorized) namespace; only validation/gating is performed under the wrong namespace context.\nThis issue affects Temporal: from 1.24.0 through 1.29.1. Fixed in 1.27.4, 1.28.2, 1.29.2.",
  "id": "GHSA-p2gr-hm8g-q772",
  "modified": "2025-12-31T22:08:24Z",
  "published": "2025-12-30T21:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14986"
    },
    {
      "type": "WEB",
      "url": "https://github.com/temporalio/temporal/pull/8839"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/temporalio/temporal"
    },
    {
      "type": "WEB",
      "url": "https://github.com/temporalio/temporal/releases/tag/v1.27.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/temporalio/temporal/releases/tag/v1.28.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/temporalio/temporal/releases/tag/v1.29.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Temporal has a namespace policy bypass allowing requests to be authorized for incorrect contexts"
}

GHSA-P2H2-C6C9-9WPX

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

HUAWEI P30 versions Versions earlier than 10.1.0.160(C00E160R2P11);HUAWEI P30 Pro versions Versions earlier than 10.1.0.160(C00E160R2P8) have a denial of service vulnerability. Certain system configuration can be modified because of improper authorization. The attacker could trick the user installing and executing a malicious application, successful exploit could cause a denial of service condition of PHONE function.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-9245"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-10T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "HUAWEI P30 versions Versions earlier than 10.1.0.160(C00E160R2P11);HUAWEI P30 Pro versions Versions earlier than 10.1.0.160(C00E160R2P8) have a denial of service vulnerability. Certain system configuration can be modified because of improper authorization. The attacker could trick the user installing and executing a malicious application, successful exploit could cause a denial of service condition of PHONE function.",
  "id": "GHSA-p2h2-c6c9-9wpx",
  "modified": "2022-05-24T17:25:14Z",
  "published": "2022-05-24T17:25:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9245"
    },
    {
      "type": "WEB",
      "url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20200805-01-smartphone-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-P2JC-8HC7-J466

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

An issue was discovered in the XCloner Backup and Restore plugin before 4.2.13 for WordPress. It gave authenticated attackers the ability to modify arbitrary files, including PHP files. Doing so would allow an attacker to achieve remote code execution. The xcloner_restore.php write_file_action could overwrite wp-config.php, for example. Alternatively, an attacker could create an exploit chain to obtain a database dump.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-35948"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-732",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-01T04:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in the XCloner Backup and Restore plugin before 4.2.13 for WordPress. It gave authenticated attackers the ability to modify arbitrary files, including PHP files. Doing so would allow an attacker to achieve remote code execution. The xcloner_restore.php write_file_action could overwrite wp-config.php, for example. Alternatively, an attacker could create an exploit chain to obtain a database dump.",
  "id": "GHSA-p2jc-8hc7-j466",
  "modified": "2022-05-24T17:37:50Z",
  "published": "2022-05-24T17:37:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35948"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Hacker5preme/Exploits/tree/main/Wordpress/CVE-2020-35948"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/10412"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/blog/2020/09/critical-vulnerabilities-patched-in-xcloner-backup-and-restore-plugin"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/163336/WordPress-XCloner-4.2.12-Remote-Code-Execution.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-P2JG-Q8HW-P7GC

Vulnerability from github – Published: 2022-09-07 00:01 – Updated: 2022-09-15 03:22
VLAI
Summary
Barbican authorization flaw before v14.0.0
Details

An authorization flaw was found in openstack-barbican. The default policy rules for the secret metadata API allowed any authenticated user to add, modify, or delete metadata from any secret regardless of ownership. This flaw allows an attacker on the network to modify or delete protected data, causing a denial of service by consuming protected resources.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "barbican"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-23451"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-15T03:22:08Z",
    "nvd_published_at": "2022-09-06T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "An authorization flaw was found in openstack-barbican. The default policy rules for the secret metadata API allowed any authenticated user to add, modify, or delete metadata from any secret regardless of ownership. This flaw allows an attacker on the network to modify or delete protected data, causing a denial of service by consuming protected resources.",
  "id": "GHSA-p2jg-q8hw-p7gc",
  "modified": "2022-09-15T03:22:08Z",
  "published": "2022-09-07T00:01:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23451"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openstack/barbican/commit/7d270bacbe29a90a10f1855abc3b50dac0f08022"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2022:5114"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2022:8874"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2022-23451"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2022878"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2025089"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openstack/barbican"
    },
    {
      "type": "WEB",
      "url": "https://review.opendev.org/c/openstack/barbican/+/811236"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Barbican authorization flaw before v14.0.0"
}

GHSA-P2X9-XRXX-X6W7

Vulnerability from github – Published: 2024-02-16 21:31 – Updated: 2024-02-16 21:31
VLAI
Details

SnapCenter versions 4.8 prior to 5.0 are susceptible to a vulnerability which could allow an authenticated SnapCenter Server user to modify system logging configuration settings

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-21987"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-16T21:15:08Z",
    "severity": "MODERATE"
  },
  "details": "SnapCenter versions 4.8 prior to 5.0 are susceptible to a \nvulnerability which could allow an authenticated SnapCenter Server user \nto modify system logging configuration settings\n\n",
  "id": "GHSA-p2x9-xrxx-x6w7",
  "modified": "2024-02-16T21:31:32Z",
  "published": "2024-02-16T21:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21987"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240216-0001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/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.