Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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

5723 vulnerabilities reference this CWE, most recent first.

GHSA-8X9C-RMQH-456C

Vulnerability from github – Published: 2026-06-30 18:43 – Updated: 2026-06-30 18:43
VLAI
Summary
Twig: Sandbox `__toString()` policy bypass via `Traversable` in `join` and `replace` filters
Details

Description

This is a residual bypass of CVE-2026-47732 / GHSA-pr2w-4gpj-cpq4 left after the initial fix for unguarded __toString() calls. It covers two related coercion points that were not caught by the original patch.

Traversable in join and replace filters. SandboxExtension::ensureToStringAllowed() recurses into PHP arrays so that a Stringable object hidden inside an array argument cannot be string-coerced without consulting the security policy. The recursion stops at PHP arrays: a Traversable value passed at the same position is not materialised, so its contents are not policy-checked. CoreExtension::join() and CoreExtension::replace() later materialise such Traversable inputs through self::toArray() and feed them to implode() / strtr(), both of which implicitly call __toString() on contained Stringable objects. The bypass also reproduces when the container implements both Stringable and Traversable: the container's own __toString() is policy-checked, but the elements yielded by getIterator() are not, and the consuming filters still coerce them to string.

in and not in operators. InBinary and NotInBinary compile to CoreExtension::inFilter(), which falls through to PHP's <=> operator when comparing a string with a Stringable object. PHP coerces the object to string via __toString() without the sandbox policy being consulted. Beyond the direct side effect, in can also be used as a content-leak oracle: each probe against an attacker-chosen needle leaks one bit of equality, and chained probes can reconstruct the string returned by __toString() even when every method is denied. The bypass reproduces with both array and Traversable haystacks, and on both operand sides.

A sandboxed template author who is allowed to call join / replace, or to use the in / not in operators, can therefore trigger a disallowed __toString() method on objects reachable from the render context, even when that method is not on SecurityPolicy::$allowedMethods. The bypass reproduces both under global sandbox mode and when sandboxing is enabled through SourcePolicyInterface.

Resolution

SandboxExtension::ensureToStringAllowed() now also recurses into Traversable operands when sandboxing is active for the current source: each value is materialised once and run through the same array-recursion path, so the policy is consulted before the filter implementation can coerce contained objects to strings. This applies to plain Traversable operands as well as to containers that implement both Stringable and Traversable: the container's own __toString() is still policy-checked, and the yielded elements are additionally checked. The materialisation is guarded by isSandboxed($source) so that non-sandboxed code paths do not pay the cost or change generator-exhaustion semantics.

InBinary and NotInBinary now implement Twig\Node\CoercesChildrenToStringInterface and declare both operands as string-coerced, so SandboxNodeVisitor wraps each operand in CheckToStringNode. The policy is consulted before CoreExtension::inFilter() reaches PHP's <=> operator, matching the existing protection on the other comparison binaries (Equal, Less, Greater, Spaceship, ...).

Credits

Twig would like to thank Vincent55 Yang and Fabien Potencier for reporting the issues and Fabien Potencier for providing the fix.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.26.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "twig/twig"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48807"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-30T18:43:23Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Description\n\nThis is a residual bypass of CVE-2026-47732 / GHSA-pr2w-4gpj-cpq4 left after the initial fix for unguarded `__toString()` calls. It covers two related coercion points that were not caught by the original patch.\n\n**`Traversable` in `join` and `replace` filters.** `SandboxExtension::ensureToStringAllowed()` recurses into PHP arrays so that a `Stringable` object hidden inside an array argument cannot be string-coerced without consulting the security policy. The recursion stops at PHP arrays: a `Traversable` value passed at the same position is not materialised, so its contents are not policy-checked. `CoreExtension::join()` and `CoreExtension::replace()` later materialise such `Traversable` inputs through `self::toArray()` and feed them to `implode()` / `strtr()`, both of which implicitly call `__toString()` on contained `Stringable` objects. The bypass also reproduces when the container implements both `Stringable` and `Traversable`: the container\u0027s own `__toString()` is policy-checked, but the elements yielded by `getIterator()` are not, and the consuming filters still coerce them to string.\n\n**`in` and `not in` operators.** `InBinary` and `NotInBinary` compile to `CoreExtension::inFilter()`, which falls through to PHP\u0027s `\u003c=\u003e` operator when comparing a string with a `Stringable` object. PHP coerces the object to string via `__toString()` without the sandbox policy being consulted. Beyond the direct side effect, `in` can also be used as a content-leak oracle: each probe against an attacker-chosen needle leaks one bit of equality, and chained probes can reconstruct the string returned by `__toString()` even when every method is denied. The bypass reproduces with both array and `Traversable` haystacks, and on both operand sides.\n\nA sandboxed template author who is allowed to call `join` / `replace`, or to use the `in` / `not in` operators, can therefore trigger a disallowed `__toString()` method on objects reachable from the render context, even when that method is not on `SecurityPolicy::$allowedMethods`. The bypass reproduces both under global sandbox mode and when sandboxing is enabled through `SourcePolicyInterface`.\n\n### Resolution\n\n`SandboxExtension::ensureToStringAllowed()` now also recurses into `Traversable` operands when sandboxing is active for the current source: each value is materialised once and run through the same array-recursion path, so the policy is consulted before the filter implementation can coerce contained objects to strings. This applies to plain `Traversable` operands as well as to containers that implement both `Stringable` and `Traversable`: the container\u0027s own `__toString()` is still policy-checked, and the yielded elements are additionally checked. The materialisation is guarded by `isSandboxed($source)` so that non-sandboxed code paths do not pay the cost or change generator-exhaustion semantics.\n\n`InBinary` and `NotInBinary` now implement `Twig\\Node\\CoercesChildrenToStringInterface` and declare both operands as string-coerced, so `SandboxNodeVisitor` wraps each operand in `CheckToStringNode`. The policy is consulted before `CoreExtension::inFilter()` reaches PHP\u0027s `\u003c=\u003e` operator, matching the existing protection on the other comparison binaries (`Equal`, `Less`, `Greater`, `Spaceship`, ...).\n\n### Credits\n\nTwig would like to thank Vincent55 Yang and Fabien Potencier for reporting the issues and Fabien Potencier for providing the fix.",
  "id": "GHSA-8x9c-rmqh-456c",
  "modified": "2026-06-30T18:43:23Z",
  "published": "2026-06-30T18:43:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/twigphp/Twig/security/advisories/GHSA-8x9c-rmqh-456c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/twig/twig/CVE-2026-48807.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/twigphp/Twig"
    },
    {
      "type": "WEB",
      "url": "https://github.com/twigphp/Twig/releases/tag/v3.27.0"
    },
    {
      "type": "WEB",
      "url": "https://symfony.com/blog/cve-2026-48807-sandbox-tostring-policy-bypass-via-traversable-in-join-replace-and-in-not-in-operators"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Twig: Sandbox `__toString()` policy bypass via `Traversable` in `join` and `replace` filters"
}

GHSA-8XCG-H5QG-922H

Vulnerability from github – Published: 2022-08-26 00:03 – Updated: 2022-09-03 00:00
VLAI
Details

An issue was discovered in Blue Prism Enterprise 6.0 through 7.01. In a misconfigured environment that exposes the Blue Prism Application server, it is possible for an authenticated user to reverse engineer the Blue Prism software and circumvent access controls for the setValidationInfo administrative function. Removing the validation applied to newly designed processes increases the chance of successfully hiding malicious code that could be executed in a production environment.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-36116"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-25T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Blue Prism Enterprise 6.0 through 7.01. In a misconfigured environment that exposes the Blue Prism Application server, it is possible for an authenticated user to reverse engineer the Blue Prism software and circumvent access controls for the setValidationInfo administrative function. Removing the validation applied to newly designed processes increases the chance of successfully hiding malicious code that could be executed in a production environment.",
  "id": "GHSA-8xcg-h5qg-922h",
  "modified": "2022-09-03T00:00:18Z",
  "published": "2022-08-26T00:03:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36116"
    },
    {
      "type": "WEB",
      "url": "https://blueprism.com"
    },
    {
      "type": "WEB",
      "url": "https://community.blueprism.com/discussion/security-vulnerability-notification-ssc-blue-prism-enterprise"
    },
    {
      "type": "WEB",
      "url": "https://portal.blueprism.com/security-vulnerabilities-august-2022"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8XG4-XQ2V-V6J7

Vulnerability from github – Published: 2022-05-24 19:19 – Updated: 2022-12-16 20:36
VLAI
Summary
Multiple vulnerabilities allow bypassing path filtering of agent-to-controller access control in Jenkins
Details

The agent-to-controller security subsystem limits which files on the Jenkins controller can be accessed by agent processes.

Multiple vulnerabilities in the file path filtering implementation of Jenkins 2.318 and earlier, LTS 2.303.2 and earlier allow agent processes to read and write arbitrary files on the Jenkins controller file system, and obtain some information about Jenkins controller file systems.

SECURITY-2538 / CVE-2021-21692: The operations FilePath#renameTo and FilePath#moveAllChildrenTo only check read permission on the source path.

We expect that most of these vulnerabilities have been present since SECURITY-144 was addressed in the 2014-10-30 security advisory.

Jenkins 2.319, LTS 2.303.3 addresses these security vulnerabilities.

SECURITY-2538 / CVE-2021-21692: The operations FilePath#renameTo and FilePath#moveAllChildrenTo check both read and delete permissions on the source path.

As some common operations are now newly subject to access control, it is expected that plugins sending commands from agents to the controller may start failing. Additionally, the newly introduced path canonicalization means that instances using a custom builds directory (Java system property jenkins.model.Jenkins.buildsDir) or partitioning JENKINS_HOME using symbolic links may fail access control checks. See the documentation for how to customize the configuration in case of problems.

If you are unable to immediately upgrade to Jenkins 2.319, LTS 2.303.3, you can install the Remoting Security Workaround Plugin. It will prevent all agent-to-controller file access using FilePath APIs. Because it is more restrictive than Jenkins 2.319, LTS 2.303.3, more plugins are incompatible with it. Make sure to read the plugin documentation before installing it.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.303.2"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.main:jenkins-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.303.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.318"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.main:jenkins-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.304"
            },
            {
              "fixed": "2.319"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21692"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-23T06:47:32Z",
    "nvd_published_at": "2021-11-04T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The agent-to-controller security subsystem limits which files on the Jenkins controller can be accessed by agent processes.\n\nMultiple vulnerabilities in the file path filtering implementation of Jenkins 2.318 and earlier, LTS 2.303.2 and earlier allow agent processes to read and write arbitrary files on the Jenkins controller file system, and obtain some information about Jenkins controller file systems.\n\nSECURITY-2538 / CVE-2021-21692: The operations `FilePath#renameTo` and `FilePath#moveAllChildrenTo` only check read permission on the source path.\n\nWe expect that most of these vulnerabilities have been present since [SECURITY-144 was addressed in the 2014-10-30 security advisory](https://www.jenkins.io/security/advisory/2014-10-30/).\n\nJenkins 2.319, LTS 2.303.3 addresses these security vulnerabilities.\n\nSECURITY-2538 / CVE-2021-21692: The operations `FilePath#renameTo` and `FilePath#moveAllChildrenTo` check both read and delete permissions on the source path.\n\nAs some common operations are now newly subject to access control, it is expected that plugins sending commands from agents to the controller may start failing. Additionally, the newly introduced path canonicalization means that instances using a custom builds directory ([Java system property jenkins.model.Jenkins.buildsDir](https://www.jenkins.io/doc/book/managing/system-properties/#jenkins-model-jenkins-buildsdir)) or partitioning `JENKINS_HOME` using symbolic links may fail access control checks. See [the documentation](https://www.jenkins.io/doc/book/security/controller-isolation/agent-to-controller/#file-access-rules) for how to customize the configuration in case of problems.\n\nIf you are unable to immediately upgrade to Jenkins 2.319, LTS 2.303.3, you can install the [Remoting Security Workaround Plugin](https://www.jenkins.io/redirect/remoting-security-workaround/). It will prevent all agent-to-controller file access using `FilePath` APIs. Because it is more restrictive than Jenkins 2.319, LTS 2.303.3, more plugins are incompatible with it. Make sure to read the plugin documentation before installing it.",
  "id": "GHSA-8xg4-xq2v-v6j7",
  "modified": "2022-12-16T20:36:35Z",
  "published": "2022-05-24T19:19:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21692"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/jenkins/commit/104c751d907919dd53f5090f84d53c671a66457b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/jenkins/commit/5a245e42979abe4a26d41727c839521e36cedd74"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/jenkins/commit/63cde2daadc705edf086f2213b48c8c547f98358"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/jenkins"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2021-11-04/#SECURITY-2455"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Multiple vulnerabilities allow bypassing path filtering of agent-to-controller access control in Jenkins"
}

GHSA-8XP8-GMMJ-XC8W

Vulnerability from github – Published: 2024-12-25 18:30 – Updated: 2025-04-25 21:31
VLAI
Details

oc_huff_tree_unpack in huffdec.c in libtheora in Theora through 1.0 7180717 has an invalid negative left shift.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-56431"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-25T17:15:05Z",
    "severity": "CRITICAL"
  },
  "details": "oc_huff_tree_unpack in huffdec.c in libtheora in Theora through 1.0 7180717 has an invalid negative left shift.",
  "id": "GHSA-8xp8-gmmj-xc8w",
  "modified": "2025-04-25T21:31:32Z",
  "published": "2024-12-25T18:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56431"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xiph/theora/issues/17#issuecomment-2480630603"
    },
    {
      "type": "WEB",
      "url": "https://github.com/UnionTech-Software/libtheora-CVE-2024-56431-PoC"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xiph/theora/blob/7180717276af1ebc7da15c83162d6c5d6203aabf/lib/huffdec.c#L193"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2025/04/25/6"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/04/25/4"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/04/25/6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8XQ7-P39F-M287

Vulnerability from github – Published: 2023-12-20 00:32 – Updated: 2023-12-20 00:32
VLAI
Details

An attacker could create malicious requests to obtain sensitive information about the web server.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-50705"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-20T00:15:09Z",
    "severity": "MODERATE"
  },
  "details": "\n\n\n\n\n\n\n\n\nAn attacker could create malicious requests to obtain sensitive information about the web server.\n\n\n\n\n\n\n",
  "id": "GHSA-8xq7-p39f-m287",
  "modified": "2023-12-20T00:32:45Z",
  "published": "2023-12-20T00:32:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50705"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-353-03"
    }
  ],
  "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"
    }
  ]
}

GHSA-8XQ9-G7CH-35HG

Vulnerability from github – Published: 2024-10-04 18:50 – Updated: 2024-10-04 18:50
VLAI
Summary
Parse Server's custom object ID allows to acquire role privileges
Details

Impact

If the Parse Server option allowCustomObjectId: true is set, an attacker that is allowed to create a new user can set a custom object ID for that new user that exploits the vulnerability and acquires privileges of a specific role.

Patches

Improved validation for custom user object IDs. Session tokens for existing users with an object ID that exploits the vulnerability are now rejected.

Workarounds

  • Disable custom object IDs by setting allowCustomObjectId: false or not setting the option which defaults to false.
  • Use a Cloud Code Trigger to validate that a new user's object ID doesn't start with the prefix role:.

References

  • https://github.com/parse-community/parse-server/security/advisories/GHSA-8xq9-g7ch-35hg
  • https://github.com/parse-community/parse-server/pull/9317 (fix for Parse Server 7)
  • https://github.com/parse-community/parse-server/pull/9318 (fix for Parse Server 6)
Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
8.6 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.5.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47183"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-04T18:50:56Z",
    "nvd_published_at": "2024-10-04T15:15:13Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nIf the Parse Server option `allowCustomObjectId: true` is set, an attacker that is allowed to create a new user can set a custom object ID for that new user that exploits the vulnerability and acquires privileges of a specific role.\n\n### Patches\n\nImproved validation for custom user object IDs. Session tokens for existing users with an object ID that exploits the vulnerability are now rejected.\n\n### Workarounds\n\n- Disable custom object IDs by setting `allowCustomObjectId: false` or not setting the option which defaults to `false`.\n- Use a Cloud Code Trigger to validate that a new user\u0027s object ID doesn\u0027t start with the prefix `role:`.\n\n### References\n\n- https://github.com/parse-community/parse-server/security/advisories/GHSA-8xq9-g7ch-35hg\n- https://github.com/parse-community/parse-server/pull/9317 (fix for Parse Server 7)\n- https://github.com/parse-community/parse-server/pull/9318 (fix for Parse Server 6)",
  "id": "GHSA-8xq9-g7ch-35hg",
  "modified": "2024-10-04T18:50:56Z",
  "published": "2024-10-04T18:50:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-8xq9-g7ch-35hg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47183"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/pull/9317"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/pull/9318"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/commit/13ee52f0d19ef3a3524b3d79aea100e587eb3cfc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/commit/1bfbccf9ee7ea77533b2b2aa7c4c69f3bd35e66f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/parse-community/parse-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Parse Server\u0027s custom object ID allows to acquire role privileges"
}

GHSA-8XR4-8V2F-PQRX

Vulnerability from github – Published: 2025-03-27 15:31 – Updated: 2025-03-27 15:31
VLAI
Details

An improper access control vulnerability in GitLab CE/EE affecting all versions from 17.4 prior to 17.8.6, 17.9 prior to 17.9.3, and 17.10 prior to 17.10.1 allows a user who was an instance admin before but has since been downgraded to a regular user to continue to maintain elevated privileges to groups and projects.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-2242"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-27T13:15:36Z",
    "severity": "HIGH"
  },
  "details": "An improper access control vulnerability in GitLab CE/EE affecting all versions from 17.4 prior to 17.8.6, 17.9 prior to 17.9.3, and 17.10 prior to 17.10.1 allows a user who was an instance admin before but has since been downgraded to a regular user to continue to maintain elevated privileges to groups and projects.",
  "id": "GHSA-8xr4-8v2f-pqrx",
  "modified": "2025-03-27T15:31:08Z",
  "published": "2025-03-27T15:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2242"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/516271"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8XRX-Q7V8-89J4

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

Brocade Fabric OS versions before v9.0.0 and after version v8.1.0, configured in Virtual Fabric mode contain a weakness in the ldap implementation that could allow a remote ldap user to login in the Brocade Fibre Channel SAN switch with "user" privileges if it is not associated with any groups.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-15376"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-11T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Brocade Fabric OS versions before v9.0.0 and after version v8.1.0, configured in Virtual Fabric mode contain a weakness in the ldap implementation that could allow a remote ldap user to login in the Brocade Fibre Channel SAN switch with \"user\" privileges if it is not associated with any groups.",
  "id": "GHSA-8xrx-q7v8-89j4",
  "modified": "2022-05-24T17:36:00Z",
  "published": "2022-05-24T17:36:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15376"
    },
    {
      "type": "WEB",
      "url": "https://www.broadcom.com/support/fibre-channel-networking/security-advisories/brocade-security-advisory-2020-1158"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-8XV7-G2Q3-FQGC

Vulnerability from github – Published: 2025-02-26 20:08 – Updated: 2025-10-16 20:41
VLAI
Summary
Mautic allows Improper Authorization in Reporting API
Details

Summary

This advisory addresses an authorization vulnerability in Mautic's HTTP Basic Authentication implementation. This flaw could allow unauthorized access to sensitive report data.

  • Improper Authorization: An authorization flaw exists in Mautic's API Authorization implementation. Any authenticated user, regardless of assigned roles or permissions, can access all reports and their associated data via the API. This bypasses the intended access controls governed by the "Reporting Permissions > View Own" and "Reporting Permissions > View Others" permissions, which should restrict access to non-System Reports.

Mitigation

Please update to Mautic 5.2.3 or later

Workarounds

Disable the API in Mautic. See documentation.

References

https://cwe.mitre.org/data/definitions/285.html https://docs.mautic.org/en/5.2/configuration/settings.html#api-settings

If you have any questions or comments about this advisory:

Email us at security@mautic.org

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "mautic/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.1"
            },
            {
              "fixed": "5.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47053"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-26T20:08:30Z",
    "nvd_published_at": "2025-02-26T13:15:40Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThis advisory addresses an authorization vulnerability in Mautic\u0027s HTTP Basic Authentication implementation. This flaw could allow unauthorized access to sensitive report data.\n\n* **Improper Authorization:** An authorization flaw exists in Mautic\u0027s API Authorization implementation. Any authenticated user, regardless of assigned roles or permissions, can access all reports and their associated data via the API.  This bypasses the intended access controls governed by the \"Reporting Permissions \u003e View Own\" and \"Reporting Permissions \u003e View Others\" permissions, which should restrict access to non-System Reports. \n\n### Mitigation\n\nPlease update to Mautic 5.2.3 or later\n\n### Workarounds\n\n Disable the API in Mautic. See [documentation](https://docs.mautic.org/en/5.2/configuration/settings.html#api-settings).\n\n### References\nhttps://cwe.mitre.org/data/definitions/285.html\nhttps://docs.mautic.org/en/5.2/configuration/settings.html#api-settings\n\nIf you have any questions or comments about this advisory:\n\nEmail us at [security@mautic.org](mailto:security@mautic.org)",
  "id": "GHSA-8xv7-g2q3-fqgc",
  "modified": "2025-10-16T20:41:31Z",
  "published": "2025-02-26T20:08:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mautic/mautic/security/advisories/GHSA-8xv7-g2q3-fqgc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47053"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mautic/mautic/commit/9d7ee57c92502ef77cddb091011c5ffef14b11ee"
    },
    {
      "type": "WEB",
      "url": "https://cwe.mitre.org/data/definitions/287.html"
    },
    {
      "type": "WEB",
      "url": "https://docs.mautic.org/en/5.2/configuration/settings.html#api-settings"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mautic/mautic"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mautic allows Improper Authorization in Reporting API"
}

GHSA-8XVP-7HJ6-MCJ9

Vulnerability from github – Published: 2026-05-29 15:30 – Updated: 2026-06-09 10:30
VLAI
Summary
GitHub CLI has an incorrect authorization header in API requests to TUF repository mirrors via `gh attestation`, `gh release verify`, and `gh release verify-asset` commands
Details

Summary

GitHub CLI incorrectly includes an authorization header in API requests to TUF repository mirrors via gh attestation, gh release verify, and gh release verify-asset commands.

Affected users:

  • Authenticated github.com users who previously ran gh attestation commands, gh release verify, or gh release verify-asset: the github.com token was included in requests to tuf-repo.github.com, a GitHub Pages domain that is not a GitHub API endpoint. All authentication types are affected.
  • Users with GH_ENTERPRISE_TOKEN or GITHUB_ENTERPRISE_TOKEN set who previously ran gh attestation commands, gh release verify, or gh release verify-asset: the enterprise token was included in requests to external hosts tuf-repo-cdn.sigstore.dev and tmaproduction.blob.core.windows.net. These hosts are not operated by GitHub.

Details

The CLI uses a shared HTTP client with an authentication layer that automatically attaches tokens to outgoing requests. This layer lacks accurate host detection and can incorrectly attribute the target host, providing it with a token it should never receive.

Specifically, the host normalization logic collapses any *.github.com subdomain to github.com, so a request to tuf-repo.github.com (a GitHub Pages site, not a GitHub API endpoint) is treated as a request to github.com and receives the user's github.com token. For hosts that don't match github.com or a known GHES instance at all, the resolver falls back to GH_ENTERPRISE_TOKEN if set.

The gh attestation, gh release verify and gh release verify-asset commands fetch data from several external hosts as part of their normal operation (TUF metadata from tuf-repo.github.com and tuf-repo-cdn.sigstore.dev, artifact bundles from Azure Blob Storage). Because these requests go through the same authenticated HTTP client, the token is sent to all of them.

Impact

Tokens were transmitted in HTTP headers to the listed hosts during normal gh attestation, gh release verify, and gh release verify-asset operations. There is no evidence that tokens were logged, retained, or accessed by unauthorized parties. If a token were captured, it would grant the same access as the token holder, potentially including private repositories, organization resources, or enterprise administration depending on token type and permissions.

Remediation and mitigation

  1. Revoke authentication tokens used with the GitHub CLI:
  2. Upgrade gh to 2.93.0.
  3. Review personal security logs and any relevant audit logs for actions associated with personal or enterprise accounts.
Severity
7.4 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.92.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cli/cli/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.93.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48501"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T15:30:13Z",
    "nvd_published_at": "2026-05-29T16:16:31Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nGitHub CLI incorrectly includes an authorization header in API requests to TUF repository mirrors via `gh attestation`, `gh release verify`, and `gh release verify-asset` commands.\n\n **Affected users:**\n\n  - Authenticated `github.com` users who previously ran `gh attestation` commands, `gh release verify`, or `gh release verify-asset`: the `github.com` token was included in requests to `tuf-repo.github.com`, a GitHub Pages domain that is not a GitHub API endpoint. All authentication types are affected.\n  - Users with `GH_ENTERPRISE_TOKEN` or `GITHUB_ENTERPRISE_TOKEN` set who previously ran `gh attestation` commands, `gh release verify`, or `gh release verify-asset`: the enterprise token was included in requests to external hosts `tuf-repo-cdn.sigstore.dev` and `tmaproduction.blob.core.windows.net`. These hosts are not operated by GitHub.\n\n### Details\n\nThe CLI uses a shared HTTP client with an authentication layer that automatically attaches tokens to outgoing requests. This layer lacks accurate host detection and can incorrectly attribute the target host, providing it with a token it should never receive.\n\nSpecifically, the host normalization logic collapses any `*.github.com` subdomain to `github.com`, so a request to `tuf-repo.github.com` (a GitHub Pages site, not a GitHub API endpoint) is treated as a request to `github.com` and receives the user\u0027s github.com token. For hosts that don\u0027t match `github.com` or a known GHES instance at all, the resolver falls back to `GH_ENTERPRISE_TOKEN` if set.\n\nThe `gh attestation`, `gh release verify` and `gh release verify-asset` commands fetch data from several external hosts as part of their normal operation (TUF metadata from `tuf-repo.github.com` and `tuf-repo-cdn.sigstore.dev`, artifact bundles from Azure Blob Storage). Because these requests go through the same authenticated HTTP client, the token is sent to all of them.\n\n### Impact\n\nTokens were transmitted in HTTP headers to the listed hosts during normal `gh attestation`, `gh release verify`, and `gh release verify-asset` operations. There is no evidence that tokens were logged, retained, or accessed by unauthorized parties. If a token were captured, it would grant the same access as the token holder, potentially including private repositories, organization resources, or enterprise administration depending on token type and permissions.\n\n### Remediation and mitigation\n\n1. Revoke authentication tokens used with the GitHub CLI: \n    - [Personal access tokens](https://docs.github.com/en/enterprise-cloud@latest/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)\n    - [GitHub CLI OAuth app](https://docs.github.com/en/apps/using-github-apps/reviewing-and-revoking-authorization-of-github-apps#reviewing-your-authorized-github-apps)\n2. Upgrade `gh` to `2.93.0`.\n3. Review personal [security logs](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/reviewing-your-security-log) and any relevant [audit logs](https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/identifying-audit-log-events-performed-by-an-access-token) for actions associated with personal or enterprise accounts.",
  "id": "GHSA-8xvp-7hj6-mcj9",
  "modified": "2026-06-09T10:30:16Z",
  "published": "2026-05-29T15:30:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cli/cli/security/advisories/GHSA-8xvp-7hj6-mcj9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48501"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cli/cli"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cli/cli/releases/tag/v2.93.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "GitHub CLI has an incorrect authorization header in API requests to TUF repository mirrors via `gh attestation`, `gh release verify`, and `gh release verify-asset` commands"
}
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