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-5564-W272-R5VF
Vulnerability from github – Published: 2026-10-06 21:31 – Updated: 2026-10-07 21:33Incorrect authorization in PermissionElement in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Low)
{
"affected": [],
"aliases": [
"CVE-2026-106259"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-06T19:17:53Z",
"severity": "MODERATE"
},
"details": "Incorrect authorization in PermissionElement in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Low)",
"id": "GHSA-5564-w272-r5vf",
"modified": "2026-10-07T21:33:20Z",
"published": "2026-10-06T21:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106259"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/10/stable-channel-update-for-desktop_086471744.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/540076586"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5567-C6HM-CGJH
Vulnerability from github – Published: 2025-08-28 18:30 – Updated: 2025-08-28 18:30Incorrect authorization in Kibana can lead to privilege escalation via the built-in reporting_user role which incorrectly has the ability to access all Kibana Spaces.
{
"affected": [],
"aliases": [
"CVE-2025-25010"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-28T16:15:34Z",
"severity": "MODERATE"
},
"details": "Incorrect authorization in Kibana can lead to privilege escalation via the built-in reporting_user\u00a0role which incorrectly has the ability to access all Kibana Spaces.",
"id": "GHSA-5567-c6hm-cgjh",
"modified": "2025-08-28T18:30:38Z",
"published": "2025-08-28T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25010"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/kibana-9-0-6-9-1-3-security-update-esa-2025-13/381426"
}
],
"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-556J-5CHH-24CP
Vulnerability from github – Published: 2022-05-24 17:49 – Updated: 2022-05-24 17:49NVIDIA vGPU driver contains a vulnerability in the Virtual GPU Manager (vGPU plugin) where it allows guests to control unauthorized resources, which may lead to integrity and confidentiality loss or information disclosure. This affects vGPU version 12.x (prior to 12.2), version 11.x (prior to 11.4) and version 8.x (prior to 8.7).
{
"affected": [],
"aliases": [
"CVE-2021-1086"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-29T19:15:00Z",
"severity": "HIGH"
},
"details": "NVIDIA vGPU driver contains a vulnerability in the Virtual GPU Manager (vGPU plugin) where it allows guests to control unauthorized resources, which may lead to integrity and confidentiality loss or information disclosure. This affects vGPU version 12.x (prior to 12.2), version 11.x (prior to 11.4) and version 8.x (prior to 8.7).",
"id": "GHSA-556j-5chh-24cp",
"modified": "2022-05-24T17:49:13Z",
"published": "2022-05-24T17:49:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1086"
},
{
"type": "WEB",
"url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5172"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-558H-JH8F-PW9X
Vulnerability from github – Published: 2026-08-25 21:31 – Updated: 2026-08-31 18:31Incorrect authorization in Network in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2026-79186"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-25T21:18:12Z",
"severity": "LOW"
},
"details": "Incorrect authorization in Network in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: Medium)",
"id": "GHSA-558h-jh8f-pw9x",
"modified": "2026-08-31T18:31:17Z",
"published": "2026-08-25T21:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79186"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/08/stable-channel-update-for-desktop_0256176589.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/497646947"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-55GC-6FMC-FPX9
Vulnerability from github – Published: 2026-05-06 21:59 – Updated: 2026-05-14 20:53Summary
A missing authorization directive on the GET /api/v1/stable/dags/tasks endpoint caused Hatchet's tenant-membership check to be skipped for this route. A user authenticated to any tenant on the same Hatchet instance could query the endpoint with another tenant's UUID and a DAG UUID belonging to that tenant, and receive task metadata for that DAG.
This issue has been patched in v0.83.39. Hatchet Cloud has been patched and requires no action from users. Self-hosted users should upgrade.
Impact
Who is affected. Multi-tenant Hatchet instances reachable by an attacker who can obtain an account on that instance. On Hatchet Cloud, account creation is open by default. On self-hosted instances, the API must be reachable by the attacker and the hostname known; instances deployed inside a VPC or with signup restricted are not exposed to arbitrary external actors.
Prerequisites for exploitation. An attacker needed:
- An account on the target Hatchet instance.
- The victim tenant's UUID.
- At least one DAG UUID (
external_id) belonging to that tenant.
The two UUIDs are not treated as secrets — they appear in URLs, API responses, audit logs, invitation flows, shared run links, and dashboard screenshots — but an attacker does need to learn them through some out-of-band channel before exploitation is possible.
What could be disclosed. For each child task of a targeted DAG, the endpoint returned:
display_name,action_id,step_idworkflow_id,workflow_version_id,workflow_run_id,task_external_idtenant_id,retry_count,status, timestampsadditional_metadata(JSON)
The additional_metadata field is the most sensitive: Hatchet workflows commonly use it to carry domain context such as user identifiers, customer IDs, feature flags, or correlation tokens. Its contents vary by deployment.
What was not disclosed. The raw task input payload is not part of this endpoint's response shape and was not exposed through this issue. The scope is limited to task metadata, not task arguments or results.
Exploitation status. We have no evidence that this vulnerability was exploited prior to the patch.
Root cause
Hatchet's multi-tenant authorization relies on an OpenAPI-driven middleware pipeline. Each authenticated operation declares x-resources: ["tenant", ...] in its spec. The populator middleware reads the declared resources, looks up the corresponding entities from request parameters, and stores them on the request context. The authz middleware then verifies that the authenticated user is a member of the tenant found on the context.
The listTasksByDAGIds operation accepted a tenant UUID as a query parameter, but its OpenAPI definition did not declare x-resources: ["tenant"]. As a result:
- The populator, which early-returns when no resources are declared, did not populate the tenant onto the request context.
- The authz middleware, which runs its membership check only when a tenant is present on the context, silently passed the request through.
- The handler read the tenant UUID directly from the query parameter and used it as the filter in the downstream OLAP query.
The SQL query itself correctly filters by tenant_id, so it returned only rows matching the supplied UUID — but the UUID came from the caller rather than from an authorization-validated context, so the filter bounded the response to the attacker-named tenant rather than to a tenant the caller was authorized to read.
Every other authenticated operation in the same path file (tasks.yaml) correctly declared x-resources. This endpoint was the only authenticated operation in the file that did not.
Patch
The fix adds the missing resource authz checks inline on the handler, enforcing valid tenant membership before the handler runs.
Shipped in v0.83.39.
Remediation
Hatchet Cloud. No action required. The patch was deployed on April 23, 2026 within the same day it was reported.
Self-hosted — recommended. Upgrade to v0.83.39 or later.
Self-hosted — if you cannot upgrade immediately. Either of the following reduces exposure until you can upgrade:
- Restrict account creation by setting
SERVER_AUTH_RESTRICTED_EMAIL_DOMAINSto an allowlist of domains you control. This prevents arbitrary users from registering an account on your instance, which removes the most common path to the prerequisite account. - Ensure the Hatchet API is not exposed to untrusted networks. We generally recommend running Hatchet inside a VPC and fronting the API with authenticated network controls; deployments configured this way were not reachable by arbitrary external attackers.
Timeline
All times April 23, 2026.
- 14:05 — Reported to Hatchet.
- 16:28 — Patch deployed to Hatchet Cloud and released as v0.83.39.
- Public disclosure — this advisory.
Credit
Reported by @sajdakabir.
Hatchet thanks the reporter for responsibly disclosing this issue and for the clear, reproducible writeup.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.83.38"
},
"package": {
"ecosystem": "Go",
"name": "github.com/hatchet-dev/hatchet"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.83.39"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42572"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T21:59:05Z",
"nvd_published_at": "2026-05-14T18:16:47Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nA missing authorization directive on the `GET /api/v1/stable/dags/tasks` endpoint caused Hatchet\u0027s tenant-membership check to be skipped for this route. A user authenticated to any tenant on the same Hatchet instance could query the endpoint with another tenant\u0027s UUID and a DAG UUID belonging to that tenant, and receive task metadata for that DAG.\n\nThis issue has been patched in **v0.83.39**. Hatchet Cloud has been patched and requires no action from users. Self-hosted users should upgrade.\n\n## Impact\n\n**Who is affected.** Multi-tenant Hatchet instances reachable by an attacker who can obtain an account on that instance. On Hatchet Cloud, account creation is open by default. On self-hosted instances, the API must be reachable by the attacker and the hostname known; instances deployed inside a VPC or with signup restricted are not exposed to arbitrary external actors.\n\n**Prerequisites for exploitation.** An attacker needed:\n\n1. An account on the target Hatchet instance.\n2. The victim tenant\u0027s UUID.\n3. At least one DAG UUID (`external_id`) belonging to that tenant.\n\nThe two UUIDs are not treated as secrets \u2014 they appear in URLs, API responses, audit logs, invitation flows, shared run links, and dashboard screenshots \u2014 but an attacker does need to learn them through some out-of-band channel before exploitation is possible.\n\n**What could be disclosed.** For each child task of a targeted DAG, the endpoint returned:\n\n- `display_name`, `action_id`, `step_id`\n- `workflow_id`, `workflow_version_id`, `workflow_run_id`, `task_external_id`\n- `tenant_id`, `retry_count`, `status`, timestamps\n- `additional_metadata` (JSON)\n\nThe `additional_metadata` field is the most sensitive: Hatchet workflows commonly use it to carry domain context such as user identifiers, customer IDs, feature flags, or correlation tokens. Its contents vary by deployment.\n\n**What was not disclosed.** The raw task `input` payload is not part of this endpoint\u0027s response shape and was not exposed through this issue. The scope is limited to task metadata, not task arguments or results.\n\n**Exploitation status.** We have no evidence that this vulnerability was exploited prior to the patch.\n\n## Root cause\n\nHatchet\u0027s multi-tenant authorization relies on an OpenAPI-driven middleware pipeline. Each authenticated operation declares `x-resources: [\"tenant\", ...]` in its spec. The `populator` middleware reads the declared resources, looks up the corresponding entities from request parameters, and stores them on the request context. The `authz` middleware then verifies that the authenticated user is a member of the tenant found on the context.\n\nThe `listTasksByDAGIds` operation accepted a `tenant` UUID as a query parameter, but its OpenAPI definition did not declare `x-resources: [\"tenant\"]`. As a result:\n\n1. The populator, which early-returns when no resources are declared, did not populate the tenant onto the request context.\n2. The authz middleware, which runs its membership check only when a tenant is present on the context, silently passed the request through.\n3. The handler read the tenant UUID directly from the query parameter and used it as the filter in the downstream OLAP query.\n\nThe SQL query itself correctly filters by `tenant_id`, so it returned only rows matching the supplied UUID \u2014 but the UUID came from the caller rather than from an authorization-validated context, so the filter bounded the response to the *attacker-named* tenant rather than to a tenant the caller was authorized to read.\n\nEvery other authenticated operation in the same path file (`tasks.yaml`) correctly declared `x-resources`. This endpoint was the only authenticated operation in the file that did not.\n\n## Patch\n\nThe fix adds the missing resource authz checks inline on the handler, enforcing valid tenant membership before the handler runs.\n\nShipped in **v0.83.39**.\n\n## Remediation\n\n**Hatchet Cloud.** No action required. The patch was deployed on April 23, 2026 within the same day it was reported.\n\n**Self-hosted \u2014 recommended.** Upgrade to **v0.83.39** or later.\n\n**Self-hosted \u2014 if you cannot upgrade immediately.** Either of the following reduces exposure until you can upgrade:\n\n- Restrict account creation by setting `SERVER_AUTH_RESTRICTED_EMAIL_DOMAINS` to an allowlist of domains you control. This prevents arbitrary users from registering an account on your instance, which removes the most common path to the prerequisite account.\n- Ensure the Hatchet API is not exposed to untrusted networks. We generally recommend running Hatchet inside a VPC and fronting the API with authenticated network controls; deployments configured this way were not reachable by arbitrary external attackers.\n\n## Timeline\n\nAll times April 23, 2026.\n\n- **14:05** \u2014 Reported to Hatchet.\n- **16:28** \u2014 Patch deployed to Hatchet Cloud and released as v0.83.39.\n- Public disclosure \u2014 this advisory.\n\n## Credit\n\nReported by @sajdakabir.\n\nHatchet thanks the reporter for responsibly disclosing this issue and for the clear, reproducible writeup.",
"id": "GHSA-55gc-6fmc-fpx9",
"modified": "2026-05-14T20:53:43Z",
"published": "2026-05-06T21:59:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hatchet-dev/hatchet/security/advisories/GHSA-55gc-6fmc-fpx9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42572"
},
{
"type": "PACKAGE",
"url": "https://github.com/hatchet-dev/hatchet"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Hatchet affected by cross-tenant information disclosure in `listTasksByDAGIds`"
}
GHSA-55P7-GC6G-92XM
Vulnerability from github – Published: 2026-08-19 15:32 – Updated: 2026-08-19 15:32Dell Command Update (DCU), versions prior to 5.7.1, contain an Incorrect Authorization vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of privileges.
{
"affected": [],
"aliases": [
"CVE-2026-67266"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-19T15:17:51Z",
"severity": "MODERATE"
},
"details": "Dell Command Update (DCU), versions prior to 5.7.1, contain an Incorrect Authorization vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of privileges.",
"id": "GHSA-55p7-gc6g-92xm",
"modified": "2026-08-19T15:32:39Z",
"published": "2026-08-19T15:32:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67266"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000501378/dsa-2026-309-security-update-for-dell-command-update-for-multiple-vulnerabilities"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-55Q4-5XF4-RR34
Vulnerability from github – Published: 2026-09-30 03:31 – Updated: 2026-09-30 03:31Pexip Infinity before 38.2, plus 39.0, 39.1 and 40.0, is affected by improper access control on a product-internal API which allows an attacker with local access to a node within a Pexip Infinity installation to execute arbitrary code as an unprivileged user on another Pexip Infinity node.
{
"affected": [],
"aliases": [
"CVE-2026-103105"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-30T03:16:59Z",
"severity": "HIGH"
},
"details": "Pexip Infinity before 38.2, plus 39.0, 39.1 and 40.0, is affected by improper access control on a product-internal API which allows an attacker with local access to a node within a Pexip Infinity installation to execute arbitrary code as an unprivileged user on another Pexip Infinity node.",
"id": "GHSA-55q4-5xf4-rr34",
"modified": "2026-09-30T03:31:34Z",
"published": "2026-09-30T03:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-103105"
},
{
"type": "WEB",
"url": "https://docs.pexip.com/admin/security_bulletins.htm"
}
],
"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-55QQ-X3MF-MHR9
Vulnerability from github – Published: 2023-05-31 15:30 – Updated: 2024-04-04 04:25In JetBrains TeamCity before 2023.05 bypass of permission checks allowing to perform admin actions was possible
{
"affected": [],
"aliases": [
"CVE-2023-34218"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-31T14:15:10Z",
"severity": "CRITICAL"
},
"details": "In JetBrains TeamCity before 2023.05 bypass of permission checks allowing to perform admin actions was possible",
"id": "GHSA-55qq-x3mf-mhr9",
"modified": "2024-04-04T04:25:45Z",
"published": "2023-05-31T15:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34218"
},
{
"type": "WEB",
"url": "https://www.jetbrains.com/privacy-security/issues-fixed"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-5648-RGJ9-V224
Vulnerability from github – Published: 2026-09-15 20:48 – Updated: 2026-09-15 20:48Summary
@zereight/mcp-gitlab exposes GitLab to an LLM agent while relying on read-only mode, a project allow-list, and transport auth as its safety controls. Five defects defeat those controls. Under the MCP threat model, tool-call arguments/content can be shaped by untrusted input (prompt injection) or a malicious client.
Reviewed commit: 60adcc0de5b0e96c4c2029f7a25d2775946421d8 (package version 2.1.28). Source review only; PoCs are local/offline.
- F1 (HIGH) execute_graphql defeats BOTH read-only mode and GITLAB_ALLOWED_PROJECT_IDS.
- F2 (HIGH, deployment-conditional) Streamable HTTP /mcp unauthenticated under cookie-jar / device-flow credentials.
- F3 (MEDIUM) SSE unauthenticated by default, no Origin/Host validation (DNS rebinding).
- F4 (HIGH) unauthenticated session/transport-exhaustion DoS (token check is syntactic only).
- F5 (LOW) CI job trace returned verbatim (prompt-injection surface).
Details
F1 — index.ts:9194-9245 (case "execute_graphql"), guard at :9196, detector in utils/graphql-query.ts.
(a) Read-only bypass: graphqlQueryContainsWriteOperation() strips comments/strings then tests /(?:^|[};]\s*)(mutation|subscription)\b/. GraphQL treats commas as insignificant, and stripGraphQLCommentsAndStrings does not remove them, so a document beginning with ,mutation{...} executes as a write but is classified read-only. (b) Allow-list bypass: the handler never calls getEffectiveProjectId() or rejectIfProjectScopedDeployment() (unlike other tools), so a raw GraphQL body reaches /api/graphql with the server token against any project the token can access, regardless of GITLAB_ALLOWED_PROJECT_IDS. execute_graphql is listed in readOnlyTools (tools/registry.ts:1288).
F2 — index.ts:1048-1052 forces REMOTE_AUTHORIZATION/GITLAB_MCP_OAUTH only when started with a PAT or job token; hasCookie (:1029) and useOAuth (:1026) are absent from the gate. Started with --cookie-path or --use-oauth, validation passes and mcpBearerAuth degrades to next() (:12903). Every /mcp caller is unauthenticated while buildAuthHeaders() attaches the server's live session upstream.
F3 — index.ts:12276 requireSseAuth is a pass-through when SSE_AUTH_TOKEN is unset (default), and the SSE transport (:12290) is created with no enableDnsRebindingProtection/allowedHosts/allowedOrigins. On the default loopback bind, a malicious web page can DNS-rebind to drive the local server with the operator's GitLab credentials.
F4 — index.ts:12387 validateToken only checks length>=20 and charset (no upstream verification); parseAuthHeaders returns AuthData for any such string; new sessions are admitted purely on capacity (:12938, MAX_SESSIONS default 1000), and the per-session rate limiter only runs when a sessionId already exists. So garbage-token initialize floods fill all session slots for SESSION_TIMEOUT_SECONDS (default 3600s) -> 503 for legitimate users.
F5 — index.ts:10898-10911 (get_pipeline_job_output) returns the CI job trace to the model verbatim. Job logs are attacker-influenceable (e.g. a fork MR pipeline), so embedded instructions become model context and, combined with F1, can escalate to writes.
PoC (local, deterministic)
F1 detector (replicates the shipped logic, no network): isWrite("mutation{deleteProject(input:{id:1}){errors}}") -> DETECTED isWrite(",mutation{deleteProject(input:{id:1}){errors}}") -> BYPASS (executes as a write under read-only mode)
F2 (local GitLab + cookie file): STREAMABLE_HTTP=true GITLAB_AUTH_COOKIE_PATH=./cookies.txt GITLAB_API_URL=http://localhost:8080/api/v4 node build/index.js # starts without an auth error; from another shell with NO credentials: curl -s http://127.0.0.1:3002/mcp -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \ -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"poc","version":"0"}}}'
F4 (REMOTE_AUTHORIZATION mode): for i in $(seq 1 1000); do curl -s -o /dev/null http://127.0.0.1:3002/mcp \ -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \ -H 'Private-Token: aaaaaaaaaaaaaaaaaaaaaaaa' \ -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"x","version":"0"}}}'; done # subsequent legitimate initialize -> 503 "Maximum 1000 concurrent sessions allowed"
Impact
A semi-trusted client or a prompt-injected agent can perform arbitrary GitLab writes while the operator believes the server is read-only, against projects outside the allow-list, up to the token's privileges (F1). Anyone able to reach the port (directly or via DNS rebinding on loopback) can use the server's GitLab credentials with no authentication (F2/F3). An unauthenticated attacker can deny service with ~1000 trivial requests (F4). Attacker-influenced CI logs can steer the agent (F5).
Remediation
Parse execute_graphql with a real GraphQL parser and reject non-query operations; enforce project scope or disable the tool under an allow-list (F1). Extend the startup gate to (hasToken || hasJobToken || hasCookie || useOAuth) and ship a mandatory Streamable-HTTP auth token (F2). Enable SDK DNS-rebinding protection with allowedHosts/allowedOrigins and require SSE_AUTH_TOKEN by default (F3). Validate tokens upstream before allocating a session, rate-limit new-session creation per IP, lower idle timeout (F4). Frame externally-sourced content as untrusted and cap size (F5).
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@zereight/mcp-gitlab"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.30"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-15T20:48:22Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n@zereight/mcp-gitlab exposes GitLab to an LLM agent while relying on read-only mode, a project allow-list, and transport auth as its safety controls. Five defects defeat those controls. Under the MCP threat model, tool-call arguments/content can be shaped by untrusted input (prompt injection) or a malicious client.\n\nReviewed commit: 60adcc0de5b0e96c4c2029f7a25d2775946421d8 (package version 2.1.28). Source review only; PoCs are local/offline.\n\n- F1 (HIGH) execute_graphql defeats BOTH read-only mode and GITLAB_ALLOWED_PROJECT_IDS.\n- F2 (HIGH, deployment-conditional) Streamable HTTP /mcp unauthenticated under cookie-jar / device-flow credentials.\n- F3 (MEDIUM) SSE unauthenticated by default, no Origin/Host validation (DNS rebinding).\n- F4 (HIGH) unauthenticated session/transport-exhaustion DoS (token check is syntactic only).\n- F5 (LOW) CI job trace returned verbatim (prompt-injection surface).\n\n### Details\n\nF1 \u2014 index.ts:9194-9245 (case \"execute_graphql\"), guard at :9196, detector in utils/graphql-query.ts.\n(a) Read-only bypass: graphqlQueryContainsWriteOperation() strips comments/strings then tests /(?:^|[};]\\s*)(mutation|subscription)\\b/. GraphQL treats commas as insignificant, and stripGraphQLCommentsAndStrings does not remove them, so a document beginning with `,mutation{...}` executes as a write but is classified read-only. (b) Allow-list bypass: the handler never calls getEffectiveProjectId() or rejectIfProjectScopedDeployment() (unlike other tools), so a raw GraphQL body reaches /api/graphql with the server token against any project the token can access, regardless of GITLAB_ALLOWED_PROJECT_IDS. execute_graphql is listed in readOnlyTools (tools/registry.ts:1288).\n\nF2 \u2014 index.ts:1048-1052 forces REMOTE_AUTHORIZATION/GITLAB_MCP_OAUTH only when started with a PAT or job token; hasCookie (:1029) and useOAuth (:1026) are absent from the gate. Started with --cookie-path or --use-oauth, validation passes and mcpBearerAuth degrades to next() (:12903). Every /mcp caller is unauthenticated while buildAuthHeaders() attaches the server\u0027s live session upstream.\n\nF3 \u2014 index.ts:12276 requireSseAuth is a pass-through when SSE_AUTH_TOKEN is unset (default), and the SSE transport (:12290) is created with no enableDnsRebindingProtection/allowedHosts/allowedOrigins. On the default loopback bind, a malicious web page can DNS-rebind to drive the local server with the operator\u0027s GitLab credentials.\n\nF4 \u2014 index.ts:12387 validateToken only checks length\u003e=20 and charset (no upstream verification); parseAuthHeaders returns AuthData for any such string; new sessions are admitted purely on capacity (:12938, MAX_SESSIONS default 1000), and the per-session rate limiter only runs when a sessionId already exists. So garbage-token initialize floods fill all session slots for SESSION_TIMEOUT_SECONDS (default 3600s) -\u003e 503 for legitimate users.\n\nF5 \u2014 index.ts:10898-10911 (get_pipeline_job_output) returns the CI job trace to the model verbatim. Job logs are attacker-influenceable (e.g. a fork MR pipeline), so embedded instructions become model context and, combined with F1, can escalate to writes.\n\n### PoC (local, deterministic)\n\nF1 detector (replicates the shipped logic, no network):\n isWrite(\"mutation{deleteProject(input:{id:1}){errors}}\") -\u003e DETECTED\n isWrite(\",mutation{deleteProject(input:{id:1}){errors}}\") -\u003e BYPASS (executes as a write under read-only mode)\n\nF2 (local GitLab + cookie file):\n STREAMABLE_HTTP=true GITLAB_AUTH_COOKIE_PATH=./cookies.txt GITLAB_API_URL=http://localhost:8080/api/v4 node build/index.js\n # starts without an auth error; from another shell with NO credentials:\n curl -s http://127.0.0.1:3002/mcp -H \u0027Content-Type: application/json\u0027 -H \u0027Accept: application/json, text/event-stream\u0027 \\\n -d \u0027{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2024-11-05\",\"capabilities\":{},\"clientInfo\":{\"name\":\"poc\",\"version\":\"0\"}}}\u0027\n\nF4 (REMOTE_AUTHORIZATION mode):\n for i in $(seq 1 1000); do curl -s -o /dev/null http://127.0.0.1:3002/mcp \\\n -H \u0027Content-Type: application/json\u0027 -H \u0027Accept: application/json, text/event-stream\u0027 \\\n -H \u0027Private-Token: aaaaaaaaaaaaaaaaaaaaaaaa\u0027 \\\n -d \u0027{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2024-11-05\",\"capabilities\":{},\"clientInfo\":{\"name\":\"x\",\"version\":\"0\"}}}\u0027; done\n # subsequent legitimate initialize -\u003e 503 \"Maximum 1000 concurrent sessions allowed\"\n\n### Impact\nA semi-trusted client or a prompt-injected agent can perform arbitrary GitLab writes while the operator believes the server is read-only, against projects outside the allow-list, up to the token\u0027s privileges (F1). Anyone able to reach the port (directly or via DNS rebinding on loopback) can use the server\u0027s GitLab credentials with no authentication (F2/F3). An unauthenticated attacker can deny service with ~1000 trivial requests (F4). Attacker-influenced CI logs can steer the agent (F5).\n\n### Remediation\nParse execute_graphql with a real GraphQL parser and reject non-query operations; enforce project scope or disable the tool under an allow-list (F1). Extend the startup gate to (hasToken || hasJobToken || hasCookie || useOAuth) and ship a mandatory Streamable-HTTP auth token (F2). Enable SDK DNS-rebinding protection with allowedHosts/allowedOrigins and require SSE_AUTH_TOKEN by default (F3). Validate tokens upstream before allocating a session, rate-limit new-session creation per IP, lower idle timeout (F4). Frame externally-sourced content as untrusted and cap size (F5).",
"id": "GHSA-5648-rgj9-v224",
"modified": "2026-09-15T20:48:22Z",
"published": "2026-09-15T20:48:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/zereight/gitlab-mcp/security/advisories/GHSA-5648-rgj9-v224"
},
{
"type": "WEB",
"url": "https://github.com/zereight/gitlab-mcp/issues/596"
},
{
"type": "WEB",
"url": "https://github.com/zereight/gitlab-mcp/issues/748"
},
{
"type": "WEB",
"url": "https://github.com/zereight/gitlab-mcp/pull/571"
},
{
"type": "WEB",
"url": "https://github.com/zereight/gitlab-mcp/pull/624"
},
{
"type": "WEB",
"url": "https://github.com/zereight/gitlab-mcp/commit/69e784da33e96e64867b511c6f14d3f21f91ba8b"
},
{
"type": "PACKAGE",
"url": "https://github.com/zereight/gitlab-mcp"
},
{
"type": "WEB",
"url": "https://github.com/zereight/gitlab-mcp/releases/tag/v2.1.30"
}
],
"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"
}
],
"summary": "@zereight/mcp-gitlab has multiple safety-control bypasses: execute_graphql read-only + allow-list bypass, unauthenticated transports, session-exhaustion DoS"
}
GHSA-564F-J4MM-773M
Vulnerability from github – Published: 2022-05-13 01:37 – Updated: 2022-05-13 01:37Improper authorization vulnerability in Highlight Preview in Synology Universal Search before 1.0.5-0135 allows remote authenticated users to bypass permission checks for directories in POSIX mode.
{
"affected": [],
"aliases": [
"CVE-2017-16773"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-05T13:29:00Z",
"severity": "HIGH"
},
"details": "Improper authorization vulnerability in Highlight Preview in Synology Universal Search before 1.0.5-0135 allows remote authenticated users to bypass permission checks for directories in POSIX mode.",
"id": "GHSA-564f-j4mm-773m",
"modified": "2022-05-13T01:37:19Z",
"published": "2022-05-13T01:37:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-16773"
},
{
"type": "WEB",
"url": "https://www.synology.com/en-global/support/security/Synology_SA_18_27"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"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.