CWE-863
Allowed-with-ReviewIncorrect 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.
7194 vulnerabilities reference this CWE, most recent first.
GHSA-4XV5-48M7-9QHQ
Vulnerability from github – Published: 2025-04-11 18:31 – Updated: 2025-07-07 15:30Incorrect Authorization vulnerability in The Wikimedia Foundation Mediawiki - OAuth Extension allows Authentication Bypass.This issue affects Mediawiki - OAuth Extension: from 1.39 through 1.43.
{
"affected": [],
"aliases": [
"CVE-2025-32068"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-11T17:15:43Z",
"severity": "CRITICAL"
},
"details": "Incorrect Authorization vulnerability in The Wikimedia Foundation Mediawiki - OAuth Extension allows Authentication Bypass.This issue affects Mediawiki - OAuth Extension: from 1.39 through 1.43.",
"id": "GHSA-4xv5-48m7-9qhq",
"modified": "2025-07-07T15:30:32Z",
"published": "2025-04-11T18:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32068"
},
{
"type": "WEB",
"url": "https://gerrit.wikimedia.org/r/q/I27b61af2cdfb862a42432e7a87b863033d540cfc"
},
{
"type": "WEB",
"url": "https://phabricator.wikimedia.org/T336113"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-4XVH-24FG-V9XX
Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2022-05-13 01:48An Improper Authorization issue was discovered in OSIsoft PI Integrator for Business Analytics before 2016 R2, PI Integrator for Microsoft Azure before 2016 R2 SP1, and PI Integrator for SAP HANA before 2017. An attacker is able to gain privileged access to the system while unauthorized.
{
"affected": [],
"aliases": [
"CVE-2017-9653"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-14T16:29:00Z",
"severity": "CRITICAL"
},
"details": "An Improper Authorization issue was discovered in OSIsoft PI Integrator for Business Analytics before 2016 R2, PI Integrator for Microsoft Azure before 2016 R2 SP1, and PI Integrator for SAP HANA before 2017. An attacker is able to gain privileged access to the system while unauthorized.",
"id": "GHSA-4xvh-24fg-v9xx",
"modified": "2022-05-13T01:48:03Z",
"published": "2022-05-13T01:48:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9653"
},
{
"type": "WEB",
"url": "https://ics-cert.us-cert.gov/advisories/ICSA-17-220-01"
},
{
"type": "WEB",
"url": "https://techsupport.osisoft.com/Troubleshooting/Alerts/AL00324"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/100212"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5235-M374-99W3
Vulnerability from github – Published: 2025-01-31 00:30 – Updated: 2025-01-31 18:31This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Alpine Halo9 devices. An attacker must first obtain the ability to pair a malicious Bluetooth device with the target system in order to exploit this vulnerability.
The specific flaw exists within the PBAP_DecodeVCARD function. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of root.
{
"affected": [],
"aliases": [
"CVE-2024-23963"
],
"database_specific": {
"cwe_ids": [
"CWE-863",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-31T00:15:09Z",
"severity": "HIGH"
},
"details": "This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Alpine Halo9 devices. An attacker must first obtain the ability to pair a malicious Bluetooth device with the target system in order to exploit this vulnerability.\n\nThe specific flaw exists within the PBAP_DecodeVCARD function. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of root.",
"id": "GHSA-5235-m374-99w3",
"modified": "2025-01-31T18:31:05Z",
"published": "2025-01-31T00:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23963"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-24-850"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5256-R6G6-4J2J
Vulnerability from github – Published: 2026-09-15 21:31 – Updated: 2026-09-20 03:30Server-Side Request Forgery (SSRF) in the VMware synchronization feature in Devolutions Server 2026.2.16 and earlier allows a low-privileged authenticated user to obtain other users' credentials and reach internal or cloud-metadata network endpoints via a crafted connection definition submitted for datacenter discovery.
{
"affected": [],
"aliases": [
"CVE-2026-90971"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-15T19:17:47Z",
"severity": "MODERATE"
},
"details": "Server-Side Request Forgery (SSRF) in the VMware synchronization feature in\u00a0Devolutions Server 2026.2.16 and earlier allows a low-privileged authenticated user to obtain other users\u0027 credentials and reach internal or cloud-metadata network endpoints via a crafted connection definition submitted for datacenter discovery.",
"id": "GHSA-5256-r6g6-4j2j",
"modified": "2026-09-20T03:30:25Z",
"published": "2026-09-15T21:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90971"
},
{
"type": "WEB",
"url": "https://devolutions.net/security/advisories/DEVO-2026-0030"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5267-2GHV-2R3V
Vulnerability from github – Published: 2022-05-24 19:09 – Updated: 2022-05-24 19:09Insufficient policy enforcement in DevTools in Google Chrome prior to 92.0.4515.107 allowed an attacker who convinced a user to install a malicious extension to potentially perform a sandbox escape via a crafted HTML page.
{
"affected": [],
"aliases": [
"CVE-2021-30571"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-03T20:15:00Z",
"severity": "CRITICAL"
},
"details": "Insufficient policy enforcement in DevTools in Google Chrome prior to 92.0.4515.107 allowed an attacker who convinced a user to install a malicious extension to potentially perform a sandbox escape via a crafted HTML page.",
"id": "GHSA-5267-2ghv-2r3v",
"modified": "2022-05-24T19:09:44Z",
"published": "2022-05-24T19:09:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30571"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2021/07/stable-channel-update-for-desktop_20.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1101897"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5LVY4WIWTVVYKQMROJJS365TZBKEARCF"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IPJPUSAWIJMQFBQQQYXAICLI4EKFQOH6"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QW4R2K5HVJ4R6XDZYOJCCFPIN2XHNS3L"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-529H-VH3J-85HQ
Vulnerability from github – Published: 2026-07-01 18:55 – Updated: 2026-07-01 18:55Description
The per-template filter, tag and function allow-list check is compiled into the checkSecurity() method of each Template subclass and was invoked once from the constructor, gated by SandboxExtension::isSandboxed($source). Template instances are then cached on the Environment in $loadedTemplates, so the verdict computed at construction time was sticky for the rest of the process.
Any later change of sandbox state on the same Environment left that cached verdict in place: toggling SandboxExtension::enableSandbox()/disableSandbox(), swapping the policy via setSecurityPolicy(), a SourcePolicyInterface decision flip, or simply having a parent, macro or included template pre-instantiated outside the sandbox before a sandboxed render reached it. In all of these cases, the filters, tags and functions used by the affected template kept running with the original (typically empty) check, bypassing the SecurityPolicy allow-list.
Method, property and __toString allow-lists are not affected: they are enforced at every call site at runtime through SandboxExtension::checkMethodAllowed(), checkPropertyAllowed() and ensureToStringAllowed(), which re-read the current state on every call.
Long-lived workers (FrankenPHP, RoadRunner, Symfony Messenger consumers, FPM with hot autoloading) that share a single Environment between sandboxed and non-sandboxed renders are the most exposed: a single non-sandboxed render of a shared layout pre-warms its Template instance, after which any later sandboxed render that extends, uses, includes or imports from that layout silently skips the filter/tag/function allow-list for the pre-warmed instance.
Resolution
The allow-list check is no longer run from the constructor. Template gains a public ensureSecurityChecked() method that calls the compiled checkSecurity() only when SandboxExtension::isSandboxed($source) returns true for the current source, and it is invoked at every entry point that can reach a Template instance whose security has not yet been verified against the current state: Template::yield(), Template::yieldBlock() (on the resolved block template, which covers extends, use, traits and parent blocks), Template::getParent() (which evaluates user code when the parent name is dynamic) and Template::getTemplateForMacro() (on the resolved macro template).
The explicit checkSecurity() calls previously emitted by IncludeNode and CoreExtension::include() are removed: the included template's own yield() now re-runs the check against the current sandbox state. The compiled checkSecurity() body is a cheap walk over compile-time-static arrays, so the per-render cost is negligible. Old cached compiled PHP files keep working unchanged: the constructor-time call they still contain is idempotent.
Credits
Twig would like to thank Fabien Potencier for reporting and fixing the issue.
{
"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-49981"
],
"database_specific": {
"cwe_ids": [
"CWE-693",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T18:55:49Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Description\n\nThe per-template filter, tag and function allow-list check is compiled into the `checkSecurity()` method of each `Template` subclass and was invoked once from the constructor, gated by `SandboxExtension::isSandboxed($source)`. `Template` instances are then cached on the `Environment` in `$loadedTemplates`, so the verdict computed at construction time was sticky for the rest of the process.\n\nAny later change of sandbox state on the same `Environment` left that cached verdict in place: toggling `SandboxExtension::enableSandbox()`/`disableSandbox()`, swapping the policy via `setSecurityPolicy()`, a `SourcePolicyInterface` decision flip, or simply having a parent, macro or included template pre-instantiated outside the sandbox before a sandboxed render reached it. In all of these cases, the filters, tags and functions used by the affected template kept running with the original (typically empty) check, bypassing the `SecurityPolicy` allow-list.\n\nMethod, property and `__toString` allow-lists are not affected: they are enforced at every call site at runtime through `SandboxExtension::checkMethodAllowed()`, `checkPropertyAllowed()` and `ensureToStringAllowed()`, which re-read the current state on every call.\n\nLong-lived workers (FrankenPHP, RoadRunner, Symfony Messenger consumers, FPM with hot autoloading) that share a single `Environment` between sandboxed and non-sandboxed renders are the most exposed: a single non-sandboxed render of a shared layout pre-warms its `Template` instance, after which any later sandboxed render that extends, uses, includes or imports from that layout silently skips the filter/tag/function allow-list for the pre-warmed instance.\n\n### Resolution\n\nThe allow-list check is no longer run from the constructor. `Template` gains a public `ensureSecurityChecked()` method that calls the compiled `checkSecurity()` only when `SandboxExtension::isSandboxed($source)` returns true for the current source, and it is invoked at every entry point that can reach a `Template` instance whose security has not yet been verified against the current state: `Template::yield()`, `Template::yieldBlock()` (on the resolved block template, which covers `extends`, `use`, traits and parent blocks), `Template::getParent()` (which evaluates user code when the parent name is dynamic) and `Template::getTemplateForMacro()` (on the resolved macro template).\n\nThe explicit `checkSecurity()` calls previously emitted by `IncludeNode` and `CoreExtension::include()` are removed: the included template\u0027s own `yield()` now re-runs the check against the current sandbox state. The compiled `checkSecurity()` body is a cheap walk over compile-time-static arrays, so the per-render cost is negligible. Old cached compiled PHP files keep working unchanged: the constructor-time call they still contain is idempotent.\n\n### Credits\n\nTwig would like to thank Fabien Potencier for reporting and fixing the issue.",
"id": "GHSA-529h-vh3j-85hq",
"modified": "2026-07-01T18:55:49Z",
"published": "2026-07-01T18:55:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/twigphp/Twig/security/advisories/GHSA-529h-vh3j-85hq"
},
{
"type": "PACKAGE",
"url": "https://github.com/twigphp/Twig"
},
{
"type": "WEB",
"url": "https://github.com/twigphp/Twig/releases/tag/v3.27.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Twig: Sandbox filter, tag and function allow-list bypass when sandbox state changes between renders for a cached `Template`"
}
GHSA-52FH-662W-2PG3
Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2022-07-13 00:01Bootloader contains a vulnerability in access permission settings where unauthorized software may be able to overwrite NVIDIA MB2 code, which would result in limited denial of service.
{
"affected": [],
"aliases": [
"CVE-2021-34396"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-22T22:15:00Z",
"severity": "LOW"
},
"details": "Bootloader contains a vulnerability in access permission settings where unauthorized software may be able to overwrite NVIDIA MB2 code, which would result in limited denial of service.",
"id": "GHSA-52fh-662w-2pg3",
"modified": "2022-07-13T00:01:26Z",
"published": "2022-05-24T19:06:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34396"
},
{
"type": "WEB",
"url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5205"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-52FW-7FW2-FMV5
Vulnerability from github – Published: 2026-06-23 22:12 – Updated: 2026-07-20 21:22Impact
A user with only users.edit AND api permissions can send a PATCH to /api/v1/users/{their_own_id} and grant themselves any permission except admin and superuser — for example assets.view, assets.create, reports.view, import, etc.
Patches
Patched in https://github.com/grokability/snipe-it/pull/19024
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "snipe/snipe-it"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48493"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-23T22:12:11Z",
"nvd_published_at": "2026-06-23T23:16:49Z",
"severity": "MODERATE"
},
"details": "### Impact\nA user with only users.edit AND api permissions can send a PATCH to /api/v1/users/{their_own_id} and grant themselves any permission except admin and superuser \u2014 for example `assets.view`, `assets.create`, `reports.view`, import, etc.\n\n### Patches\nPatched in https://github.com/grokability/snipe-it/pull/19024",
"id": "GHSA-52fw-7fw2-fmv5",
"modified": "2026-07-20T21:22:29Z",
"published": "2026-06-23T22:12:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/grokability/snipe-it/security/advisories/GHSA-52fw-7fw2-fmv5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48493"
},
{
"type": "WEB",
"url": "https://github.com/grokability/snipe-it/pull/19024"
},
{
"type": "PACKAGE",
"url": "https://github.com/grokability/snipe-it"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Snipe-IT Vulnerable to Privilege Escalation for self via API Permissions Assignment"
}
GHSA-52GF-6RPQ-FGMX
Vulnerability from github – Published: 2026-09-02 23:44 – Updated: 2026-09-02 23:44Summary
The OpenChoreo API server (openchoreo-api) authorized requests to its exec and wirelogs endpoints against the project supplied by the caller in the request, rather than against the project that actually owns the target component. The target component was resolved by name only, and the authorization engine decided purely from the caller-supplied resource hierarchy — the component's real owning project was never checked. As a result, an authenticated user who holds a project-scoped exec or log-viewing grant on any single project could run commands in, and read the wirelogs of, components owned by other projects in the same namespace.
Impact
An authenticated tenant holding a project-scoped component:exec grant on just one project can execute arbitrary commands — including an interactive shell — inside the running pods of components owned by any other project in the same namespace. This exposes those workloads' environment variables and mounted Secrets (such as database credentials, API keys, and tokens), allows tampering with the workload, and enables further pivoting using the workload's own network position and credentials. The same flaw in the wirelogs endpoint lets a project-scoped wirelogs:view grant read any component's wirelogs in the namespace.
The blast radius is every component in the namespace, reachable from a single legitimate project grant. The boundary crossed is project-within-namespace: the request still pins the namespace, so the issue does not cross namespace boundaries. In effect this is a cross-project (cross-team) remote command-execution and data-access primitive available to any low-privileged tenant.
Patches
Fixed in 1.2.3 and 1.1.6. The fix aligns the exec and wirelogs endpoints with the pattern already used by other first-class component operations: the target component is fetched first and authorization is evaluated against its real owning project (comp.Spec.Owner.ProjectName) instead of the caller-supplied project query parameter.
Workarounds
If you cannot upgrade immediately:
- Restrict
component:execandwirelogs:viewgrants to trusted operators only. Any holder of such a grant on any project can reach every component in the same namespace. - Where stronger isolation is required, separate sensitive components into their own namespaces, since the flaw does not cross namespace boundaries.
Related advisories
GHSA-rh53-xvx2-j327— the cluster-gateway internal proxy applies no caller authorization, so this API-layer authorization bypass reaches the data-plane Kubernetes API with no compensating control: https://github.com/openchoreo/openchoreo/security/advisories/GHSA-rh53-xvx2-j327GHSA-c5f6-2rm9-2w8g— reported together as part of the same review.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/openchoreo/openchoreo"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0-m.1"
},
{
"fixed": "1.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/openchoreo/openchoreo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73841"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-02T23:44:51Z",
"nvd_published_at": "2026-08-13T22:17:28Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe OpenChoreo API server (`openchoreo-api`) authorized requests to its exec and wirelogs endpoints against the project supplied by the caller in the request, rather than against the project that actually owns the target component. The target component was resolved by name only, and the authorization engine decided purely from the caller-supplied resource hierarchy \u2014 the component\u0027s real owning project was never checked. As a result, an authenticated user who holds a project-scoped exec or log-viewing grant on any single project could run commands in, and read the wirelogs of, components owned by other projects in the same namespace.\n\n### Impact\n\nAn authenticated tenant holding a project-scoped `component:exec` grant on just one project can execute arbitrary commands \u2014 including an interactive shell \u2014 inside the running pods of components owned by any other project in the same namespace. This exposes those workloads\u0027 environment variables and mounted Secrets (such as database credentials, API keys, and tokens), allows tampering with the workload, and enables further pivoting using the workload\u0027s own network position and credentials. The same flaw in the wirelogs endpoint lets a project-scoped `wirelogs:view` grant read any component\u0027s wirelogs in the namespace.\n\nThe blast radius is every component in the namespace, reachable from a single legitimate project grant. The boundary crossed is project-within-namespace: the request still pins the namespace, so the issue does not cross namespace boundaries. In effect this is a cross-project (cross-team) remote command-execution and data-access primitive available to any low-privileged tenant.\n\n### Patches\n\nFixed in **1.2.3** and **1.1.6**. The fix aligns the exec and wirelogs endpoints with the pattern already used by other first-class component operations: the target component is fetched first and authorization is evaluated against its real owning project (`comp.Spec.Owner.ProjectName`) instead of the caller-supplied `project` query parameter.\n\n### Workarounds\n\nIf you cannot upgrade immediately:\n\n- Restrict `component:exec` and `wirelogs:view` grants to trusted operators only. Any holder of such a grant on any project can reach every component in the same namespace.\n- Where stronger isolation is required, separate sensitive components into their own namespaces, since the flaw does not cross namespace boundaries.\n\n### Related advisories\n\n- `GHSA-rh53-xvx2-j327` \u2014 the cluster-gateway internal proxy applies no caller authorization, so this API-layer authorization bypass reaches the data-plane Kubernetes API with no compensating control: https://github.com/openchoreo/openchoreo/security/advisories/GHSA-rh53-xvx2-j327\n- `GHSA-c5f6-2rm9-2w8g` \u2014 reported together as part of the same review.",
"id": "GHSA-52gf-6rpq-fgmx",
"modified": "2026-09-02T23:44:51Z",
"published": "2026-09-02T23:44:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/security/advisories/GHSA-52gf-6rpq-fgmx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73841"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/pull/4251"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/pull/4516"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/pull/4538"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/commit/4d372eaf1f07525663dcca5257062f4b051b9820"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/commit/9d77b64f747eba89247c47ebfeffec591c4cd2d8"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/commit/c9390e4fcb9953f43b07cb48197576182301593d"
},
{
"type": "PACKAGE",
"url": "https://github.com/openchoreo/openchoreo"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/releases/tag/v1.1.6"
},
{
"type": "WEB",
"url": "https://github.com/openchoreo/openchoreo/releases/tag/v1.2.3"
}
],
"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"
}
],
"summary": "OpenChoreo: Cross-project command execution and wirelog view access via OpenChoreo openchoreo-api exec and wirelogs endpoints"
}
GHSA-52J8-P7R3-733M
Vulnerability from github – Published: 2022-02-12 00:00 – Updated: 2022-03-30 00:01cmd/go in Go before 1.16.14 and 1.17.x before 1.17.7 can misinterpret branch names that falsely appear to be version tags. This can lead to incorrect access control if an actor is supposed to be able to create branches but not tags.
{
"affected": [],
"aliases": [
"CVE-2022-23773"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-11T01:15:00Z",
"severity": "HIGH"
},
"details": "cmd/go in Go before 1.16.14 and 1.17.x before 1.17.7 can misinterpret branch names that falsely appear to be version tags. This can lead to incorrect access control if an actor is supposed to be able to create branches but not tags.",
"id": "GHSA-52j8-p7r3-733m",
"modified": "2022-03-30T00:01:42Z",
"published": "2022-02-12T00:00:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23773"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/golang-announce/c/SUsQn0aSgPQ"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220225-0006"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
- 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
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
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
- 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
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.