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.

6869 vulnerabilities reference this CWE, most recent first.

GHSA-RM22-VH4P-35M7

Vulnerability from github – Published: 2023-06-08 21:30 – Updated: 2024-04-04 04:40
VLAI
Details

Pydio Cells allows users by default to create so-called external users in order to share files with them. By modifying the HTTP request sent when creating such an external user, it is possible to assign the new user arbitrary roles. By assigning all roles to a newly created user, access to all cells and non-personal workspaces is granted.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-32749"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-08T20:15:09Z",
    "severity": "HIGH"
  },
  "details": "Pydio Cells allows users by default to create so-called external users in order to share files with them. By modifying the HTTP request sent when creating such an external user, it is possible to assign the new user arbitrary roles. By assigning all roles to a newly created user, access to all cells and non-personal workspaces is granted.",
  "id": "GHSA-rm22-vh4p-35m7",
  "modified": "2024-04-04T04:40:53Z",
  "published": "2023-06-08T21:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32749"
    },
    {
      "type": "WEB",
      "url": "https://www.redteam-pentesting.de/en/advisories/-advisories-publicised-vulnerability-analyses"
    },
    {
      "type": "WEB",
      "url": "https://www.redteam-pentesting.de/en/advisories/rt-sa-2023-003/-pydio-cells-unauthorised-role-assignments"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/172645/Pydio-Cells-4.1.2-Privilege-Escalation.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2023/May/18"
    }
  ],
  "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"
    }
  ]
}

GHSA-RM2P-J3R7-4X4J

Vulnerability from github – Published: 2026-03-03 19:50 – Updated: 2026-03-30 13:45
VLAI
Summary
OpenClaw's Slack reaction/pin sender-policy consistency issue in non-message ingress
Details

Summary

OpenClaw Slack monitor handled reaction_* and pin_* non-message events before applying sender-policy checks consistently.

In affected versions, these events could be added to system-event context even when sender policy would not normally allow them.

Affected Packages / Versions

  • Package: npm openclaw
  • Latest published affected version confirmed: 2026.2.24 (npm latest as of February 26, 2026)
  • Affected range: <= 2026.2.24
  • Patched version : 2026.2.25

Technical Details

  • reaction_* and pin_* handlers now route through shared sender authorization (authorizeSlackSystemEventSender).
  • Enforced checks now include:
  • DM dmPolicy / allowFrom
  • channel users allowlist enforcement for non-DM channels
  • channel-level allow checks before system-event enqueue
  • Regression coverage added for DM allow/deny and channel-user allowlist deny paths.

Fix Commit(s)

  • aedf62ac7e669a89c7b299201bf6537dc6b12e0e
  • 75dfb71e4e8b7c2feba5a8ca662f92ea840e0147

Impact

Low-severity policy-consistency issue in Slack non-message event ingress. This may introduce unexpected reaction/pin context signals from senders outside configured policy.

Release Process Note

patched_versions is pre-set to planned release 2026.2.25. Advisory published with npm release 2026.2.25.

OpenClaw thanks @tdjackey for reporting.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.24"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32899"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T19:50:26Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nOpenClaw Slack monitor handled `reaction_*` and `pin_*` non-message events before applying sender-policy checks consistently.\n\nIn affected versions, these events could be added to system-event context even when sender policy would not normally allow them.\n\n### Affected Packages / Versions\n- Package: npm `openclaw`\n- Latest published affected version confirmed: `2026.2.24` (npm latest as of February 26, 2026)\n- Affected range: `\u003c= 2026.2.24`\n- Patched version : `2026.2.25`\n\n### Technical Details\n- `reaction_*` and `pin_*` handlers now route through shared sender authorization (`authorizeSlackSystemEventSender`).\n- Enforced checks now include:\n  - DM `dmPolicy` / `allowFrom`\n  - channel `users` allowlist enforcement for non-DM channels\n  - channel-level allow checks before system-event enqueue\n- Regression coverage added for DM allow/deny and channel-user allowlist deny paths.\n\n### Fix Commit(s)\n- `aedf62ac7e669a89c7b299201bf6537dc6b12e0e`\n- `75dfb71e4e8b7c2feba5a8ca662f92ea840e0147`\n\n### Impact\nLow-severity policy-consistency issue in Slack non-message event ingress.\nThis may introduce unexpected reaction/pin context signals from senders outside configured policy.\n\n### Release Process Note\n`patched_versions` is pre-set to planned release `2026.2.25`. Advisory published with npm release `2026.2.25`.\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-rm2p-j3r7-4x4j",
  "modified": "2026-03-30T13:45:13Z",
  "published": "2026-03-03T19:50:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-rm2p-j3r7-4x4j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32899"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/75dfb71e4e8b7c2feba5a8ca662f92ea840e0147"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/aedf62ac7e669a89c7b299201bf6537dc6b12e0e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-sender-policy-bypass-in-slack-reaction-and-pin-event-handlers"
    }
  ],
  "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"
    },
    {
      "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw\u0027s Slack reaction/pin sender-policy consistency issue in non-message ingress"
}

GHSA-RM4M-39FJ-288C

Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2023-10-27 13:46
VLAI
Summary
Incorrect permission checks in Jenkins Role-based Authorization Strategy Plugin may allow accessing some items
Details

Items (like jobs) can be organized hierarchically in Jenkins, using the Folders Plugin or something similar. An item is expected to be accessible only if all its ancestors are accessible as well.

Role-based Authorization Strategy Plugin 3.1 and earlier does not correctly perform permission checks to determine whether an item should be accessible.

This allows attackers with Item/Read permission on nested items to access them, even if they lack Item/Read permission for parent folders.

Role-based Authorization Strategy Plugin 3.1.1 requires Item/Read permission on parent items to grant Item/Read permission on an individual item.

As a workaround in older releases, do not grant permissions on individual items to users who do not have access to parent items.

In case of problems, the Java system property com.michelin.cio.hudson.plugins.rolestrategy.RoleMap.checkParentPermissions can be set to false, completely disabling this fix.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:role-strategy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21624"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-14T16:28:15Z",
    "nvd_published_at": "2021-03-18T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Items (like jobs) can be organized hierarchically in Jenkins, using the Folders Plugin or something similar. An item is expected to be accessible only if all its ancestors are accessible as well.\n\nRole-based Authorization Strategy Plugin 3.1 and earlier does not correctly perform permission checks to determine whether an item should be accessible.\n\nThis allows attackers with Item/Read permission on nested items to access them, even if they lack Item/Read permission for parent folders.\n\nRole-based Authorization Strategy Plugin 3.1.1 requires Item/Read permission on parent items to grant Item/Read permission on an individual item.\n\nAs a workaround in older releases, do not grant permissions on individual items to users who do not have access to parent items.\n\nIn case of problems, the [Java system property](https://www.jenkins.io/doc/book/managing/system-properties/) `com.michelin.cio.hudson.plugins.rolestrategy.RoleMap.checkParentPermissions` can be set to false, completely disabling this fix.",
  "id": "GHSA-rm4m-39fj-288c",
  "modified": "2023-10-27T13:46:00Z",
  "published": "2022-05-24T17:44:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21624"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/role-strategy-plugin/commit/2490ed51c30f6df9db809a7dcf637ac8ac08233a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/role-strategy-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2021-03-18/#SECURITY-2182"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2021/03/18/5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Incorrect permission checks in Jenkins Role-based Authorization Strategy Plugin may allow accessing some items"
}

GHSA-RM4P-54WJ-PX7W

Vulnerability from github – Published: 2022-10-17 19:00 – Updated: 2022-10-20 19:00
VLAI
Details

It was possible for a guest user to read a todo targeting an inaccessible note in Gitlab CE/EE affecting all versions from 15.0 prior to 15.2.5, 15.3 prior to 15.3.4, and 15.4 prior to 15.4.1.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-3330"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-17T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "It was possible for a guest user to read a todo targeting an inaccessible note in Gitlab CE/EE affecting all versions from 15.0 prior to 15.2.5, 15.3 prior to 15.3.4, and 15.4 prior to 15.4.1.",
  "id": "GHSA-rm4p-54wj-px7w",
  "modified": "2022-10-20T19:00:35Z",
  "published": "2022-10-17T19:00:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3330"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-3330.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/365827"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RMP9-MC8W-MQF3

Vulnerability from github – Published: 2022-05-24 17:17 – Updated: 2022-12-16 22:48
VLAI
Summary
Users with Overall/Read access can enumerate credentials IDs in Amazon EC2 Plugin
Details

Amazon EC2 Plugin provides a list of applicable credentials IDs to allow users configuring the plugin to select the one to use.

This functionality does not correctly check permissions in Amazon EC2 Plugin 1.50.1 and earlier, allowing any user with Overall/Read permission to get a list of valid credentials IDs. Those can be used as part of an attack to capture the credentials using another vulnerability.

An enumeration of credentials IDs in Amazon EC2 Plugin 1.50.2 now requires Overall/Administer permission.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.50.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:ec2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.50.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-2188"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-16T22:48:38Z",
    "nvd_published_at": "2020-05-06T13:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Amazon EC2 Plugin provides a list of applicable credentials IDs to allow users configuring the plugin to select the one to use.\n\nThis functionality does not correctly check permissions in Amazon EC2 Plugin 1.50.1 and earlier, allowing any user with Overall/Read permission to get a list of valid credentials IDs. Those can be used as part of an attack to capture the credentials using another vulnerability.\n\nAn enumeration of credentials IDs in Amazon EC2 Plugin 1.50.2 now requires Overall/Administer permission.",
  "id": "GHSA-rmp9-mc8w-mqf3",
  "modified": "2022-12-16T22:48:38Z",
  "published": "2022-05-24T17:17:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2188"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/ec2-plugin"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2020-05-06/#SECURITY-1844"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/05/06/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Users with Overall/Read access can enumerate credentials IDs in Amazon EC2 Plugin"
}

GHSA-RMXW-C48H-2VF5

Vulnerability from github – Published: 2023-11-07 23:03 – Updated: 2023-11-07 23:03
VLAI
Summary
XWiki Platform privilege escalation from script right to programming right through title displayer
Details

Impact

In XWiki Platform, it's possible for a user to write a script in which any velocity content is executed with the right of any other document content author.

To reproduce:

As a user with script but not programming right, create a document with the following content:

{{velocity}}
#set($main = $xwiki.getDocument('AppWithinMinutes.DynamicMessageTool'))
$main.setTitle('$doc.getDocument().getContentAuthor()')
$main.getPlainTitle()
{{/velocity}}

Since this API require programming right and the user does not have it, the expected result is $doc.document.authors.contentAuthor (not executed script), unfortunately with the security vulnerability we get XWiki.superadmin which shows that the title was executed with the right of the unmodified document.

Patches

This has been patched in XWiki 14.10.7 and 15.2-RC-1.

Workarounds

There are no known workarounds for it.

References

  • https://jira.xwiki.org/browse/XWIKI-20624
  • https://github.com/xwiki/xwiki-platform/commit/11a9170dfe63e59f4066db67f84dbfce4ed619c6
  • https://jira.xwiki.org/browse/XWIKI-20625
  • https://github.com/xwiki/xwiki-platform/commit/41d7dca2d30084966ca6a7ee537f39ee8354a7e3

For more information

If you have any questions or comments about this advisory: * Open an issue in Jira XWiki.org * Email us at Security Mailing List

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-display-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2-milestone-3"
            },
            {
              "fixed": "14.10.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-display-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.0"
            },
            {
              "fixed": "15.2-rc-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-46244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-11-07T23:03:57Z",
    "nvd_published_at": "2023-11-07T19:15:10Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nIn XWiki Platform, it\u0027s possible for a user to write a script in which any velocity content is executed with the right of any other document content author.\n\nTo reproduce:\n\nAs a user with script but not programming right, create a document with the following content:\n\n```\n{{velocity}}\n#set($main = $xwiki.getDocument(\u0027AppWithinMinutes.DynamicMessageTool\u0027))\n$main.setTitle(\u0027$doc.getDocument().getContentAuthor()\u0027)\n$main.getPlainTitle()\n{{/velocity}}\n```\n\nSince this API require programming right and the user does not have it, the expected result is `$doc.document.authors.contentAuthor` (not executed script), unfortunately with the security vulnerability we get `XWiki.superadmin` which shows that the title was executed with the right of the unmodified document.\n\n### Patches\n\nThis has been patched in XWiki 14.10.7 and 15.2-RC-1.\n\n### Workarounds\n\nThere are no known workarounds for it.\n\n### References\n\n* https://jira.xwiki.org/browse/XWIKI-20624\n* https://github.com/xwiki/xwiki-platform/commit/11a9170dfe63e59f4066db67f84dbfce4ed619c6\n* https://jira.xwiki.org/browse/XWIKI-20625\n* https://github.com/xwiki/xwiki-platform/commit/41d7dca2d30084966ca6a7ee537f39ee8354a7e3\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n* Email us at [Security Mailing List](mailto:security@xwiki.org)",
  "id": "GHSA-rmxw-c48h-2vf5",
  "modified": "2023-11-07T23:03:57Z",
  "published": "2023-11-07T23:03:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-rmxw-c48h-2vf5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46244"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/11a9170dfe63e59f4066db67f84dbfce4ed619c6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/41d7dca2d30084966ca6a7ee537f39ee8354a7e3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xwiki/xwiki-platform"
    },
    {
      "type": "WEB",
      "url": "https://jira.xwiki.org/browse/XWIKI-20624"
    },
    {
      "type": "WEB",
      "url": "https://jira.xwiki.org/browse/XWIKI-20625"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "XWiki Platform privilege escalation from script right to programming right through title displayer"
}

GHSA-RMXW-PQ4X-3FVH

Vulnerability from github – Published: 2026-07-28 21:59 – Updated: 2026-07-28 21:59
VLAI
Summary
goshs: File-based .goshs ACL authorization bypass via the ?bulk zip-download route (unauthenticated read; residual of GHSA-wvhv-qcqf-f3cx)
Details

GHSA-wvhv-qcqf-f3cx fixed the per-folder .goshs ACL bypass on the state-changing routes (PUT/POST upload/?mkdir/?delete) and added recursive ACL resolution, and its description states the read/list path correctly enforces .goshs. That premise does not hold for the ?bulk zip-download route. bulkDownload (httpserver/updown.go) takes one or more ?file= parameters, runs each through sanitizePath(fs.Webroot, file), and streams the contents back as a ZIP without ever calling findEffectiveACL/applyCustomAuth. It is dispatched from earlyBreakParameters (?bulk) before the normal doDir/doFile/sendFile flow that performs the ACL check. An unauthenticated attacker can therefore read any file under the webroot protected solely by a .goshs ACL, bypassing both the folder auth (401 on the normal path) and the per-file block list (404 on the normal path). Same authorization-inconsistency root cause as the original advisory, surviving on a read route the fix did not cover.

Proof of concept (live, against the fixed v2.1.0 build which includes fix commit f212c4f4, served with no global -b auth, only a per-folder .goshs): GET /protected/secret.txt -> 401 (ACL enforced on normal path) GET /protected/secret.txt -u admin:admin -> 200 GET /?bulk&file=/protected/secret.txt -> 200, zip contains the protected file contents (BYPASS) GET /?bulk&file=/protected/blocked.txt -> 200, zip contains the block-listed file (block bypass) GET /protected/secret.txt?share -> 403 'Sharing disabled when auth is disabled' (correctly gated, NOT a bypass)

Impact: any unauthenticated network attacker can read files an operator protected with the documented per-folder .goshs ACL/basic-auth feature, by requesting them through ?bulk. Confidentiality only (the write/delete equivalents were closed by GHSA-wvhv-qcqf-f3cx). Applies to deployments relying on .goshs as the access boundary (a server-wide -b basic auth, if configured, also gates ?bulk via its middleware).

Remediation: enforce the effective .goshs ACL inside bulkDownload for every requested file exactly as sendFile/processDir do (resolve findEffectiveACL(filepath.Dir(absPath)) + applyCustomAuth + honor acl.Block), or route ?bulk through the same authorization gate as the normal read path. Audit ?cbDown and other alternate read routes for the same gap.

Credit: anir0y (independent security research).

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/patrickhener/goshs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/patrickhener/goshs/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "goshs.de/goshs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "goshs.de/goshs/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54719"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T21:59:48Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "GHSA-wvhv-qcqf-f3cx fixed the per-folder .goshs ACL bypass on the state-changing routes (PUT/POST upload/?mkdir/?delete) and added recursive ACL resolution, and its description states the read/list path correctly enforces .goshs. That premise does not hold for the ?bulk zip-download route. bulkDownload (httpserver/updown.go) takes one or more ?file= parameters, runs each through sanitizePath(fs.Webroot, file), and streams the contents back as a ZIP without ever calling findEffectiveACL/applyCustomAuth. It is dispatched from earlyBreakParameters (?bulk) before the normal doDir/doFile/sendFile flow that performs the ACL check. An unauthenticated attacker can therefore read any file under the webroot protected solely by a .goshs ACL, bypassing both the folder auth (401 on the normal path) and the per-file block list (404 on the normal path). Same authorization-inconsistency root cause as the original advisory, surviving on a read route the fix did not cover.\n\nProof of concept (live, against the fixed v2.1.0 build which includes fix commit f212c4f4, served with no global -b auth, only a per-folder .goshs):\n  GET /protected/secret.txt              -\u003e 401 (ACL enforced on normal path)\n  GET /protected/secret.txt -u admin:admin -\u003e 200\n  GET /?bulk\u0026file=/protected/secret.txt  -\u003e 200, zip contains the protected file contents  (BYPASS)\n  GET /?bulk\u0026file=/protected/blocked.txt -\u003e 200, zip contains the block-listed file        (block bypass)\n  GET /protected/secret.txt?share        -\u003e 403 \u0027Sharing disabled when auth is disabled\u0027    (correctly gated, NOT a bypass)\n\nImpact: any unauthenticated network attacker can read files an operator protected with the documented per-folder .goshs ACL/basic-auth feature, by requesting them through ?bulk. Confidentiality only (the write/delete equivalents were closed by GHSA-wvhv-qcqf-f3cx). Applies to deployments relying on .goshs as the access boundary (a server-wide -b basic auth, if configured, also gates ?bulk via its middleware).\n\nRemediation: enforce the effective .goshs ACL inside bulkDownload for every requested file exactly as sendFile/processDir do (resolve findEffectiveACL(filepath.Dir(absPath)) + applyCustomAuth + honor acl.Block), or route ?bulk through the same authorization gate as the normal read path. Audit ?cbDown and other alternate read routes for the same gap.\n\nCredit: anir0y (independent security research).",
  "id": "GHSA-rmxw-pq4x-3fvh",
  "modified": "2026-07-28T21:59:48Z",
  "published": "2026-07-28T21:59:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/goshs-labs/goshs/security/advisories/GHSA-rmxw-pq4x-3fvh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/goshs-labs/goshs/commit/7cf911a26ace737e1a55b7dc073e307a25f7fd1d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/goshs-labs/goshs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/goshs-labs/goshs/releases/tag/v2.1.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "goshs: File-based .goshs ACL authorization bypass via the ?bulk zip-download route (unauthenticated read; residual of GHSA-wvhv-qcqf-f3cx)"
}

GHSA-RP3C-5XMM-FM73

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

Insufficient access control in the firmware for the Intel(R) 722 Ethernet Controllers before version 1.4.3 may allow a privileged user to potentially enable denial of service via local access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-24494"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-17T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient access control in the firmware for the Intel(R) 722 Ethernet Controllers before version 1.4.3 may allow a privileged user to potentially enable denial of service via local access.",
  "id": "GHSA-rp3c-5xmm-fm73",
  "modified": "2022-05-24T17:42:29Z",
  "published": "2022-05-24T17:42:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24494"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00456.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-RP44-3JP7-V7HV

Vulnerability from github – Published: 2026-09-09 03:30 – Updated: 2026-09-10 18:31
VLAI
Details

Incorrect authorization in Network in Google Chrome prior to 153.0.8010.36 allowed a remote attacker leveraging social engineering to bypass web origin policy via a crafted Chrome extension. (Chromium security severity: High)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-87447"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-09T01:17:01Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect authorization in Network in Google Chrome prior to 153.0.8010.36 allowed a remote attacker leveraging social engineering to bypass web origin policy via a crafted Chrome extension. (Chromium security severity: High)",
  "id": "GHSA-rp44-3jp7-v7hv",
  "modified": "2026-09-10T18:31:38Z",
  "published": "2026-09-09T03:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87447"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_0808145027.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/503464711"
    }
  ],
  "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-RP5M-XQ4P-5F64

Vulnerability from github – Published: 2023-07-06 21:15 – Updated: 2024-04-04 05:49
VLAI
Details

Palantir discovered a software bug in a recently released version of Foundry’s Lime2 service, one of the services backing the Ontology. The software bug has been fixed and the fix has been deployed to your hosted Foundry environment. The vulnerability allowed authenticated users within a Foundry organization to potentially bypass discretionary or mandatory access controls under certain circumstances.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-22833"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-304",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-06T19:15:10Z",
    "severity": "MODERATE"
  },
  "details": "Palantir discovered a software bug in a recently released version of Foundry\u2019s Lime2 service, one of the services backing the Ontology. The software bug has been fixed and the fix has been deployed to your hosted Foundry environment. The vulnerability allowed authenticated users within a Foundry organization to potentially bypass discretionary or mandatory access controls under certain circumstances.",
  "id": "GHSA-rp5m-xq4p-5f64",
  "modified": "2024-04-04T05:49:07Z",
  "published": "2023-07-06T21:15:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22833"
    },
    {
      "type": "WEB",
      "url": "https://palantir.safebase.us/?tcuUid=7f1fd834-805d-4679-85d0-9d779fa064ae"
    }
  ],
  "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:L",
      "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.