Common Weakness Enumeration

CWE-441

Allowed-with-Review

Unintended Proxy or Intermediary ('Confused Deputy')

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.

153 vulnerabilities reference this CWE, most recent first.

GHSA-3P68-RC4W-QGX5

Vulnerability from github – Published: 2026-04-09 17:32 – Updated: 2026-05-08 13:46
VLAI
Summary
Axios has a NO_PROXY Hostname Normalization Bypass that Leads to SSRF
Details

Axios does not correctly handle hostname normalization when checking NO_PROXY rules. Requests to loopback addresses like localhost. (with a trailing dot) or [::1] (IPv6 literal) skip NO_PROXY matching and go through the configured proxy.

This goes against what developers expect and lets attackers force requests through a proxy, even if NO_PROXY is set up to protect loopback or internal services.

According to RFC 1034 §3.1 and RFC 3986 §3.2.2, a hostname can have a trailing dot to show it is a fully qualified domain name (FQDN). At the DNS level, localhost. is the same as localhost. However, Axios does a literal string comparison instead of normalizing hostnames before checking NO_PROXY. This causes requests like http://localhost.:8080/ and http://[::1]:8080/ to be incorrectly proxied.

This issue leads to the possibility of proxy bypass and SSRF vulnerabilities allowing attackers to reach sensitive loopback or internal services despite the configured protections.

PoC

import http from "http";
import axios from "axios";

const proxyPort = 5300;

http.createServer((req, res) => {
  console.log("[PROXY] Got:", req.method, req.url, "Host:", req.headers.host);
  res.writeHead(200, { "Content-Type": "text/plain" });
  res.end("proxied");
}).listen(proxyPort, () => console.log("Proxy", proxyPort));

process.env.HTTP_PROXY = `http://127.0.0.1:${proxyPort}`;
process.env.NO_PROXY = "localhost,127.0.0.1,::1";

async function test(url) {
  try {
    await axios.get(url, { timeout: 2000 });
  } catch {}
}

setTimeout(async () => {
  console.log("\n[*] Testing http://localhost.:8080/");
  await test("http://localhost.:8080/"); // goes through proxy

  console.log("\n[*] Testing http://[::1]:8080/");
  await test("http://[::1]:8080/"); // goes through proxy
}, 500);

Expected: Requests bypass the proxy (direct to loopback). Actual: Proxy logs requests for localhost. and [::1].

Impact

  • Applications that rely on NO_PROXY=localhost,127.0.0.1,::1 for protecting loopback/internal access are vulnerable.

  • Attackers controlling request URLs can:

  • Force Axios to send local traffic through an attacker-controlled proxy.

  • Bypass SSRF mitigations relying on NO_PROXY rules.
  • Potentially exfiltrate sensitive responses from internal services via the proxy.

Affected Versions

  • Confirmed on Axios 1.12.2 (latest at time of testing).
  • affects all versions that rely on Axios’ current NO_PROXY evaluation.

Remediation Axios should normalize hostnames before evaluating NO_PROXY, including:

  • Strip trailing dots from hostnames (per RFC 3986).
  • Normalize IPv6 literals by removing brackets for matching.
Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.15.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.31.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-62718"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-09T17:32:19Z",
    "nvd_published_at": "2026-04-09T15:16:08Z",
    "severity": "MODERATE"
  },
  "details": "Axios does not correctly handle hostname normalization when checking `NO_PROXY` rules.\nRequests to loopback addresses like `localhost.` (with a trailing dot) or `[::1]` (IPv6 literal) skip `NO_PROXY` matching and go through the configured proxy.\n\nThis goes against what developers expect and lets attackers force requests through a proxy, even if `NO_PROXY` is set up to protect loopback or internal services.\n\nAccording to [RFC 1034 \u00a73.1](https://datatracker.ietf.org/doc/html/rfc1034#section-3.1) and [RFC 3986 \u00a73.2.2](https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2), a hostname can have a trailing dot to show it is a fully qualified domain name (FQDN). At the DNS level, `localhost.` is the same as `localhost`. \nHowever, Axios does a literal string comparison instead of normalizing hostnames before checking `NO_PROXY`. This causes requests like `http://localhost.:8080/` and `http://[::1]:8080/` to be incorrectly proxied.\n\nThis issue leads to the possibility of proxy bypass and SSRF vulnerabilities allowing attackers to reach sensitive loopback or internal services despite the configured protections.\n\n---\n\n**PoC**\n\n```js\nimport http from \"http\";\nimport axios from \"axios\";\n\nconst proxyPort = 5300;\n\nhttp.createServer((req, res) =\u003e {\n  console.log(\"[PROXY] Got:\", req.method, req.url, \"Host:\", req.headers.host);\n  res.writeHead(200, { \"Content-Type\": \"text/plain\" });\n  res.end(\"proxied\");\n}).listen(proxyPort, () =\u003e console.log(\"Proxy\", proxyPort));\n\nprocess.env.HTTP_PROXY = `http://127.0.0.1:${proxyPort}`;\nprocess.env.NO_PROXY = \"localhost,127.0.0.1,::1\";\n\nasync function test(url) {\n  try {\n    await axios.get(url, { timeout: 2000 });\n  } catch {}\n}\n\nsetTimeout(async () =\u003e {\n  console.log(\"\\n[*] Testing http://localhost.:8080/\");\n  await test(\"http://localhost.:8080/\"); // goes through proxy\n\n  console.log(\"\\n[*] Testing http://[::1]:8080/\");\n  await test(\"http://[::1]:8080/\"); // goes through proxy\n}, 500);\n```\n\n**Expected:** Requests bypass the proxy (direct to loopback).\n**Actual:** Proxy logs requests for `localhost.` and `[::1]`.\n\n---\n\n**Impact**\n\n* Applications that rely on `NO_PROXY=localhost,127.0.0.1,::1` for protecting loopback/internal access are vulnerable.\n* Attackers controlling request URLs can:\n\n  * Force Axios to send local traffic through an attacker-controlled proxy.\n  * Bypass SSRF mitigations relying on NO\\_PROXY rules.\n  * Potentially exfiltrate sensitive responses from internal services via the proxy.\n  \n  \n---\n\n**Affected Versions**\n\n* Confirmed on Axios **1.12.2** (latest at time of testing).\n* affects all versions that rely on Axios\u2019 current `NO_PROXY` evaluation.\n\n---\n\n**Remediation**\nAxios should normalize hostnames before evaluating `NO_PROXY`, including:\n\n* Strip trailing dots from hostnames (per RFC 3986).\n* Normalize IPv6 literals by removing brackets for matching.",
  "id": "GHSA-3p68-rc4w-qgx5",
  "modified": "2026-05-08T13:46:43Z",
  "published": "2026-04-09T17:32:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-3p68-rc4w-qgx5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62718"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/pull/10661"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/pull/10688"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/commit/03cdfc99e8db32a390e12128208b6778492cee9c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/commit/fb3befb6daac6cad26b2e54094d0f2d9e47f24df"
    },
    {
      "type": "WEB",
      "url": "https://datatracker.ietf.org/doc/html/rfc1034#section-3.1"
    },
    {
      "type": "WEB",
      "url": "https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/releases/tag/v0.31.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/releases/tag/v1.15.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Axios has a NO_PROXY Hostname Normalization Bypass that Leads to SSRF"
}

GHSA-3RHH-97V9-2G42

Vulnerability from github – Published: 2024-02-16 00:30 – Updated: 2024-08-26 21:30
VLAI
Details

In setMediaButtonReceiver of MediaSessionRecord.java, there is a possible way to send a pending intent on behalf of system_server due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-40111"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-15T23:15:08Z",
    "severity": "HIGH"
  },
  "details": "In setMediaButtonReceiver of MediaSessionRecord.java, there is a possible way to send a pending intent on behalf of system_server due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.",
  "id": "GHSA-3rhh-97v9-2g42",
  "modified": "2024-08-26T21:30:31Z",
  "published": "2024-02-16T00:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40111"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/frameworks/base/+/55d3d57cbffc838c52d610af14a056dea87b422e"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2023-11-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3V2X-9XCV-2V2V

Vulnerability from github – Published: 2026-01-22 18:06 – Updated: 2026-01-29 03:45
VLAI
Summary
SurrealDB Affected by Confused Deputy Privilege Escalation through Future Fields and Functions
Details

Unprivileged users (for example, those with the database editor role) can create or modify fields in records that contain functions or futures. Futures are values which are only computed when the value is queried. The query executes in the context of the querying user, rather than the user who originally defined the future. Likewise, fields containing functions or custom-defined logic (closures) are executed under the privileges of the invoking user, not the creator.

This results in a confused deputy vulnerability: an attacker with limited privileges can define a malicious function or future field that performs privileged actions. When a higher-privileged user (such as a root owner or namespace administrator) executes the function or queries or modifies that record, the function executes with their elevated permissions.

Impact

An attacker who can create or update function/future fields can plant logic that executes with a privileged user’s context. If a privileged user performs a write that touches the malicious field, the attacker can achieve full privilege escalation (e.g., create a root owner and take over the server).

If a privileged user performs a read action on the malicious field, this attack vector could still be potentially be used to perform limited denial of service or, in the specific case where the network capability was explicitly enabled and unrestricted, exfiltrate database information over the network.

Patches

Versions prior to 2.5.0 and 3.0.0-beta.3 are vulnerable.

For SurrealDB 3.0, futures are no longer supported, replaced by computed fields, only available within schemaful tables.

Further to this patches for 2.5.0 and 3.0.0-beta.3: - Implements an auth_limit on defined apis, functions, fields and events, that limits execution to the permissions of the creating user or the invoking user, whichever is lower. - Prevents closures from being stored, that eliminates a potential attack surface. For 2.5.0 this can still be allowed by using the insecure_storable_closures capability - Ensures the proper auth level is used to compute expressions in signin & signup

For existing apis, events, fields and functions defined prior to upgrading to 2.5.0 or 3.0.0-beta.3 auth_limit will not apply, to avoid breaking changes. These will need to subsequently be redefined so that auth_limit can take effect.

Workarounds

Users unable to patch are advised to evaluate their use of the database to identify where low privileged users are able to define logic subsequently executed by privileged users, such as apis, functions, futures fields and events, and recommended to minimise these instances.

References

Futures Closures SurrealDB Environment Variables

Severity
7.5 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-alpha.1"
            },
            {
              "fixed": "3.0.0-beta.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-441"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-22T18:06:15Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Unprivileged users (for example, those with the database editor role) can create or modify fields in records that contain functions or `futures`. `Futures` are values which are only computed when the value is queried. The query executes in the context of the querying user, rather than the user who originally defined the future. Likewise, fields containing functions or custom-defined logic (`closures`) are executed under the privileges of the invoking user, not the creator.\n\nThis results in a confused deputy vulnerability: an attacker with limited privileges can define a malicious function or future field that performs privileged actions. When a higher-privileged user (such as a root owner or namespace administrator) executes the function or queries or modifies that record, the function executes with their elevated permissions. \n\n### Impact\nAn attacker who can create or update function/future fields can plant logic that executes with a privileged user\u2019s context. If a privileged user performs a write that touches the malicious field, the attacker can achieve full privilege escalation (e.g., create a root owner and take over the server). \n\nIf a privileged user performs a read action on the malicious field, this attack vector could still be potentially be used to perform limited denial of service or, in the specific case where the network capability was explicitly enabled and unrestricted, exfiltrate database information over the network.\n\n### Patches\n\nVersions prior to 2.5.0 and 3.0.0-beta.3 are vulnerable.\n\nFor SurrealDB 3.0, `futures` are no longer supported, replaced by `computed`  fields, only available within schemaful tables. \n\nFurther to this patches for 2.5.0 and 3.0.0-beta.3: \n- Implements an `auth_limit` on defined apis, functions, fields and events, that limits execution to the permissions of the creating user or the invoking user, whichever is lower.\n- Prevents `closures` from being stored, that eliminates a potential attack surface. For 2.5.0 this can still be allowed by using the `insecure_storable_closures` capability\n- Ensures the proper auth level is used to compute expressions in signin \u0026 signup\n\n**_For existing apis, events, fields and functions defined prior to upgrading to 2.5.0 or 3.0.0-beta.3 `auth_limit` will not apply, to avoid breaking changes. These will need to subsequently be redefined so that `auth_limit` can take effect._**\n\n### Workarounds\nUsers unable to patch are advised to evaluate their use of the database to identify where low privileged users are able to define logic subsequently executed by privileged users, such as apis, functions, futures fields and events, and recommended to minimise these instances.\n\n### References\n[Futures](https://surrealdb.com/docs/surrealql/datamodel/futures)\n[Closures](https://surrealdb.com/docs/surrealql/datamodel/closures)\n[SurrealDB Environment Variables](https://surrealdb.com/docs/surrealdb/cli/env)",
  "id": "GHSA-3v2x-9xcv-2v2v",
  "modified": "2026-01-29T03:45:36Z",
  "published": "2026-01-22T18:06:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-3v2x-9xcv-2v2v"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/commit/f515c91363ee735aa1bc08580d9e7fa0de6e736f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/surrealdb/surrealdb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/releases/tag/v2.5.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/releases/tag/v3.0.0-beta.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "SurrealDB Affected by Confused Deputy Privilege Escalation through Future Fields and Functions"
}

GHSA-47RQ-88XV-GPXV

Vulnerability from github – Published: 2026-05-10 00:33 – Updated: 2026-05-10 00:33
VLAI
Details

GrapheneOS before 2026050400 allows attackers to discover the real IP address of a VPN user as a consequence of a registerQuicConnectionClosePayload optimization, because an application can let system_server transmit UDP traffic on its behalf. This occurs when the "Block connections without VPN" and "Always-on VPN" settings are enabled.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-45182"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-09T23:16:32Z",
    "severity": "LOW"
  },
  "details": "GrapheneOS before 2026050400 allows attackers to discover the real IP address of a VPN user as a consequence of a registerQuicConnectionClosePayload optimization, because an application can let system_server transmit UDP traffic on its behalf. This occurs when the \"Block connections without VPN\" and \"Always-on VPN\" settings are enabled.",
  "id": "GHSA-47rq-88xv-gpxv",
  "modified": "2026-05-10T00:33:20Z",
  "published": "2026-05-10T00:33:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45182"
    },
    {
      "type": "WEB",
      "url": "https://cyberinsider.com/grapheneos-fixes-android-vpn-leak-google-refused-to-patch"
    },
    {
      "type": "WEB",
      "url": "https://grapheneos.org/releases#2026050400"
    },
    {
      "type": "WEB",
      "url": "https://lowlevel.fun/posts/tiny-udp-cannon-android-vpn-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4MHR-CXR4-2PRM

Vulnerability from github – Published: 2026-05-11 18:31 – Updated: 2026-05-18 15:30
VLAI
Summary
Duplicate Advisory: OpenClaw: Workspace dotenv MiniMax host override could redirect credentialed requests
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-h2vw-ph2c-jvwf. This link is maintained to preserve external references.

Original Description

OpenClaw versions 2026.4.5 before 2026.4.20 contain an environment variable injection vulnerability allowing workspace dotenv to override MINIMAX_API_HOST. Attackers can redirect credentialed MiniMax API requests to attacker-controlled origins, exposing the MiniMax API key in Authorization headers.

Severity
5.0 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N
4.1 (Medium)
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2026.4.5"
            },
            {
              "fixed": "2026.4.20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-441"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T15:30:29Z",
    "nvd_published_at": "2026-05-11T18:16:38Z",
    "severity": "MODERATE"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-h2vw-ph2c-jvwf. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw versions 2026.4.5 before 2026.4.20 contain an environment variable injection vulnerability allowing workspace dotenv to override MINIMAX_API_HOST. Attackers can redirect credentialed MiniMax API requests to attacker-controlled origins, exposing the MiniMax API key in Authorization headers.",
  "id": "GHSA-4mhr-cxr4-2prm",
  "modified": "2026-05-18T15:30:29Z",
  "published": "2026-05-11T18:31:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-h2vw-ph2c-jvwf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44992"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/2f06696579a1ab0cb5bbbbb6a900414a6b2e3cd1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-minimax-api-host-override-via-workspace-dotenv"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/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"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw: Workspace dotenv MiniMax host override could redirect credentialed requests",
  "withdrawn": "2026-05-18T15:30:29Z"
}

GHSA-4QCW-5W3M-2HFG

Vulnerability from github – Published: 2022-05-13 01:31 – Updated: 2025-08-15 21:31
VLAI
Details

MikroTik RouterOS before 6.43.12 (stable) and 6.42.12 (long-term) is vulnerable to an intermediary vulnerability. The software will execute user defined network requests to both WAN and LAN clients. A remote unauthenticated attacker can use this vulnerability to bypass the router's firewall or for general network scanning activities.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-3924"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-02-20T20:29:00Z",
    "severity": "HIGH"
  },
  "details": "MikroTik RouterOS before 6.43.12 (stable) and 6.42.12 (long-term) is vulnerable to an intermediary vulnerability. The software will execute user defined network requests to both WAN and LAN clients. A remote unauthenticated attacker can use this vulnerability to bypass the router\u0027s firewall or for general network scanning activities.",
  "id": "GHSA-4qcw-5w3m-2hfg",
  "modified": "2025-08-15T21:31:11Z",
  "published": "2022-05-13T01:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3924"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/46444"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/research/tra-2019-07"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/107177"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4V84-GVMH-336P

Vulnerability from github – Published: 2022-05-17 02:48 – Updated: 2025-04-20 03:36
VLAI
Details

KanColleViewer versions 3.8.1 and earlier operates as an open proxy which allows remote attackers to trigger outbound network traffic.

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

{
  "affected": [],
  "aliases": [
    "CVE-2015-2947"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-04-13T17:59:00Z",
    "severity": "CRITICAL"
  },
  "details": "KanColleViewer versions 3.8.1 and earlier operates as an open proxy which allows remote attackers to trigger outbound network traffic.",
  "id": "GHSA-4v84-gvmh-336p",
  "modified": "2025-04-20T03:36:04Z",
  "published": "2022-05-17T02:48:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-2947"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/vu/JVNVU98282440"
    },
    {
      "type": "WEB",
      "url": "http://grabacr.net/kancolleviewer"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5G4W-3VW9-478W

Vulnerability from github – Published: 2026-07-06 21:05 – Updated: 2026-07-06 21:05
VLAI
Summary
Coder's subdomain workspace app routing trusts unauthenticated X-Forwarded-Host header, enabling cross-app data access
Details

Summary

The workspace app proxy resolves the target app from httpapi.RequestHost() which prefers the X-Forwarded-Host header over the real Host header. No middleware strips X-Forwarded-Host before routing and the header is not browser-forbidden so client-side JavaScript can set it on fetch() calls.

Note: Practical exploitation requires subdomain app routing (wildcard hostname) enabled, a victim who visits the attacker's shared app and a deployment whose upstream proxy does not strip X-Forwarded-Host.

Impact

App session cookies are scoped to the wildcard parent domain so the browser attaches them to any app subdomain. An attacker who controls a shared workspace app can serve JavaScript that sends same-site requests with a forged X-Forwarded-Host pointing at a victim's private app. The server routes by the attacker-controlled header but authorizes with the victim's cookie which lets the attacker read the victim's private app responses. Subdomain app routing must be enabled and no upstream proxy may strip X-Forwarded-Host.

Patches

The fix trusts X-Forwarded-Host only from configured trusted proxies and otherwise resolves the routing host from the verified request host.

The fix was backported to all supported release lines:

Release line Patched version
2.34 v2.34.2
2.33 v2.33.8
2.32 v2.32.7
2.29 (ESR) v2.29.17

Workarounds

Place an upstream reverse proxy that strips or overwrites X-Forwarded-Host on untrusted requests.

Resources

  • Fix: #26204

Credits

Coder would like to thank Anthropic's Security Team (ANT-2026-22435) for independently disclosing this issue!

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.34.0"
            },
            {
              "fixed": "2.34.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.33.0"
            },
            {
              "fixed": "2.33.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.30.0"
            },
            {
              "fixed": "2.32.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.29.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55430"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-441"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-06T21:05:31Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe workspace app proxy resolves the target app from `httpapi.RequestHost()` which prefers the `X-Forwarded-Host` header over the real `Host` header. No middleware strips `X-Forwarded-Host` before routing and the header is not browser-forbidden so client-side JavaScript can set it on `fetch()` calls.\n\n\u003e **Note:** Practical exploitation requires subdomain app routing (wildcard hostname) enabled, a victim who visits the attacker\u0027s shared app and a deployment whose upstream proxy does not strip `X-Forwarded-Host`.\n\n### Impact\n\nApp session cookies are scoped to the wildcard parent domain so the browser attaches them to any app subdomain. An attacker who controls a shared workspace app can serve JavaScript that sends same-site requests with a forged `X-Forwarded-Host` pointing at a victim\u0027s private app. The server routes by the attacker-controlled header but authorizes with the victim\u0027s cookie which lets the attacker read the victim\u0027s private app responses. Subdomain app routing must be enabled and no upstream proxy may strip `X-Forwarded-Host`.\n\n### Patches\n\nThe fix trusts `X-Forwarded-Host` only from configured trusted proxies and otherwise resolves the routing host from the verified request host.\n\nThe fix was backported to all supported release lines:\n\n| Release line | Patched version |\n|---|---|\n| 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) |\n| 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) |\n| 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) |\n| 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) |\n\n### Workarounds\n\nPlace an upstream reverse proxy that strips or overwrites `X-Forwarded-Host` on untrusted requests.\n\n### Resources\n\n- Fix: #26204\n\n### Credits\n\nCoder would like to thank Anthropic\u0027s Security Team (ANT-2026-22435) for independently disclosing this issue!",
  "id": "GHSA-5g4w-3vw9-478w",
  "modified": "2026-07-06T21:05:31Z",
  "published": "2026-07-06T21:05:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/security/advisories/GHSA-5g4w-3vw9-478w"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/pull/26204"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/coder/coder"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Coder\u0027s subdomain workspace app routing trusts unauthenticated X-Forwarded-Host header, enabling cross-app data access"
}

GHSA-5JGM-F9WR-9QM7

Vulnerability from github – Published: 2026-05-11 18:31 – Updated: 2026-05-18 15:29
VLAI
Summary
Duplicate Advisory: OpenClaw: Workspace dotenv files cannot override connector endpoint hosts
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-55cf-xx38-4p9p. This link is maintained to preserve external references.

Original Description

OpenClaw before 2026.4.22 allows workspace dotenv files to override connector endpoint hosts for Matrix, Mattermost, IRC, and Synology connectors. Attackers with workspace access can redirect runtime traffic to malicious endpoints by setting endpoint variables in dotenv files.

Severity
5.0 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N
4.1 (Medium)
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-441"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T15:29:02Z",
    "nvd_published_at": "2026-05-11T18:16:40Z",
    "severity": "MODERATE"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-55cf-xx38-4p9p. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.4.22 allows workspace dotenv files to override connector endpoint hosts for Matrix, Mattermost, IRC, and Synology connectors. Attackers with workspace access can redirect runtime traffic to malicious endpoints by setting endpoint variables in dotenv files.",
  "id": "GHSA-5jgm-f9wr-9qm7",
  "modified": "2026-05-18T15:29:02Z",
  "published": "2026-05-11T18:31:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-55cf-xx38-4p9p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45003"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/0623079e98abf7202591f1b04a89755eb7ec9272"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-connector-endpoint-host-override-via-workspace-dotenv-files"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/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"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw: Workspace dotenv files cannot override connector endpoint hosts",
  "withdrawn": "2026-05-18T15:29:02Z"
}

GHSA-5RR4-8452-HF4V

Vulnerability from github – Published: 2026-07-07 20:56 – Updated: 2026-07-07 20:56
VLAI
Summary
@better-auth/sso provider registration has server-side request forgery via unvalidated OIDC endpoints
Details

Am I affected?

Users are affected if all of the following are true:

  • Their application uses @better-auth/sso at a version >= 0.1.0, < 1.6.11 on the stable line, or any 1.7.0-beta.x on the pre-release line.
  • The sso() plugin is added to their application's betterAuth({ plugins: [...] }) array.
  • Any user with a valid Better Auth session can reach POST /sso/register (the plugin's default gate accepts any session).

For the non-blind SSRF impact (full IAM credential or internal HTTP body exfiltration), no further configuration is required.

For the account takeover escalation, additionally:

  • Developers set sso({ trustEmailVerified: true, ... }).
  • The developer's application deployment has accounts whose email overlaps with attacker-chosen domains.

If developers do not enable the SSO plugin, their application is not affected.

Fix:

  1. Upgrade to @better-auth/sso@1.6.11 or later.
  2. If developers cannot upgrade, see workarounds below.

Summary

The @better-auth/sso plugin's POST /sso/register endpoint accepts attacker-controlled oidcConfig.userInfoEndpoint, tokenEndpoint, and jwksEndpoint URLs when skipDiscovery: true is set, persists them on the ssoProvider row without origin validation, then issues server-side fetches to those URLs during the OIDC callback. The fetched response body is reflected through the user profile, producing a non-blind SSRF reachable by any authenticated session. The same primitive exists on POST /sso/update-provider.

Details

The schema field types accept bare strings: no .url() validator, no origin gate. The discovery branch (skipDiscovery: false) routes URLs through validateDiscoveryUrl; the skip-discovery branch persists them as-is. At callback time three fetch sites read the stored URLs: validateAuthorizationCode for the token endpoint, betterFetch for the userInfo endpoint, and validateToken for the JWKS endpoint.

When trustEmailVerified: true is configured, the attacker can escalate to account linking. A malicious userInfo response with emailVerified: true and a chosen email triggers OAuth auto-link against any pre-existing user row with that email, compounding the SSRF into account takeover.

Patches

Fixed in @better-auth/sso@1.6.11. Provider registration (POST /sso/register with skipDiscovery: true) and every POST /sso/update-provider request now validate each supplied OIDC endpoint URL (authorizationEndpoint, tokenEndpoint, userInfoEndpoint, jwksEndpoint, discoveryEndpoint) at registration time. A URL is rejected unless it satisfies one of two conditions:

  1. Its host is publicly routable on the internet, evaluated through the @better-auth/core/utils/host.isPublicRoutableHost gate. RFC 1918 private ranges, RFC 4193 unique-local addresses, link-local addresses (including the cloud-metadata IP 169.254.169.254), loopback, multicast, broadcast, and reserved ranges are rejected, along with cloud-metadata FQDNs.
  2. Its origin is already listed in the application's trustedOrigins configuration. This preserves the documented escape hatch for customers running internal IdPs intentionally on private networks.

The schema also tightens from z.string() to z.url() on those fields, so malformed URLs fail at parse time rather than at fetch time. Deployments running internal IdPs that previously worked must add the IdP's origin to trustedOrigins to keep working after upgrade.

Workarounds

If developers cannot upgrade immediately:

  • Disable provider self-registration: set sso({ providersLimit: 0 }). The limit is enforced before the schema branch, blocking every /sso/register regardless of skipDiscovery.
  • Reverse-proxy gate: block POST /sso/register and POST /sso/update-provider at the edge, or restrict to a denylist of source IPs and a small admin user list.
  • Network-level egress controls: block egress from the auth server to RFC 1918, RFC 4193, link-local ranges (169.254.0.0/16, fe80::/10), and the cloud-metadata FQDN list at the firewall or VPC level. AWS users should additionally enforce IMDSv2 (HttpTokens: required).
  • Set trustEmailVerified: false until upgrade. This caps the impact at non-blind SSRF and removes the account-takeover escalation, but does not stop the SSRF.

Impact

  • Server-Side Request Forgery (non-blind): the attacker reads response bodies from any HTTP endpoint reachable from the auth server, including cloud metadata services (AWS IMDS, GCP metadata FQDN), internal-only APIs, and infrastructure services such as Redis or admin panels bound to localhost.
  • Account takeover (when trustEmailVerified: true): the attacker mints a malicious userInfo response asserting emailVerified: true for an arbitrary email, triggering OAuth auto-link against pre-existing user rows.

Credit

Reported by Vaadata.

Resources

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@better-auth/sso"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.0"
            },
            {
              "fixed": "1.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53513"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-345",
      "CWE-441",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-07T20:56:19Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Am I affected?\n\nUsers are affected if all of the following are true:\n\n- Their application uses `@better-auth/sso` at a version `\u003e= 0.1.0, \u003c 1.6.11` on the stable line, or any `1.7.0-beta.x` on the pre-release line.\n- The `sso()` plugin is added to their application\u0027s `betterAuth({ plugins: [...] })` array.\n- Any user with a valid Better Auth session can reach `POST /sso/register` (the plugin\u0027s default gate accepts any session).\n\nFor the non-blind SSRF impact (full IAM credential or internal HTTP body exfiltration), no further configuration is required.\n\nFor the account takeover escalation, additionally:\n\n- Developers set `sso({ trustEmailVerified: true, ... })`.\n- The developer\u0027s application deployment has accounts whose `email` overlaps with attacker-chosen domains.\n\nIf developers do not enable the SSO plugin, their application is not affected.\n\nFix:\n\n1. Upgrade to `@better-auth/sso@1.6.11` or later.\n2. If developers cannot upgrade, see workarounds below.\n\n### Summary\n\nThe `@better-auth/sso` plugin\u0027s `POST /sso/register` endpoint accepts attacker-controlled `oidcConfig.userInfoEndpoint`, `tokenEndpoint`, and `jwksEndpoint` URLs when `skipDiscovery: true` is set, persists them on the `ssoProvider` row without origin validation, then issues server-side fetches to those URLs during the OIDC callback. The fetched response body is reflected through the user profile, producing a non-blind SSRF reachable by any authenticated session. The same primitive exists on `POST /sso/update-provider`.\n\n### Details\n\nThe schema field types accept bare strings: no `.url()` validator, no origin gate. The discovery branch (`skipDiscovery: false`) routes URLs through `validateDiscoveryUrl`; the skip-discovery branch persists them as-is. At callback time three fetch sites read the stored URLs: `validateAuthorizationCode` for the token endpoint, `betterFetch` for the userInfo endpoint, and `validateToken` for the JWKS endpoint.\n\nWhen `trustEmailVerified: true` is configured, the attacker can escalate to account linking. A malicious userInfo response with `emailVerified: true` and a chosen `email` triggers OAuth auto-link against any pre-existing user row with that email, compounding the SSRF into account takeover.\n\n### Patches\n\nFixed in `@better-auth/sso@1.6.11`. Provider registration (`POST /sso/register` with `skipDiscovery: true`) and every `POST /sso/update-provider` request now validate each supplied OIDC endpoint URL (`authorizationEndpoint`, `tokenEndpoint`, `userInfoEndpoint`, `jwksEndpoint`, `discoveryEndpoint`) at registration time. A URL is rejected unless it satisfies one of two conditions:\n\n1. Its host is publicly routable on the internet, evaluated through the `@better-auth/core/utils/host.isPublicRoutableHost` gate. RFC 1918 private ranges, RFC 4193 unique-local addresses, link-local addresses (including the cloud-metadata IP `169.254.169.254`), loopback, multicast, broadcast, and reserved ranges are rejected, along with cloud-metadata FQDNs.\n2. Its origin is already listed in the application\u0027s `trustedOrigins` configuration. This preserves the documented escape hatch for customers running internal IdPs intentionally on private networks.\n\nThe schema also tightens from `z.string()` to `z.url()` on those fields, so malformed URLs fail at parse time rather than at fetch time. Deployments running internal IdPs that previously worked must add the IdP\u0027s origin to `trustedOrigins` to keep working after upgrade.\n\n### Workarounds\n\nIf developers cannot upgrade immediately:\n\n- **Disable provider self-registration**: set `sso({ providersLimit: 0 })`. The limit is enforced before the schema branch, blocking every `/sso/register` regardless of `skipDiscovery`.\n- **Reverse-proxy gate**: block `POST /sso/register` and `POST /sso/update-provider` at the edge, or restrict to a denylist of source IPs and a small admin user list.\n- **Network-level egress controls**: block egress from the auth server to RFC 1918, RFC 4193, link-local ranges (`169.254.0.0/16`, `fe80::/10`), and the cloud-metadata FQDN list at the firewall or VPC level. AWS users should additionally enforce IMDSv2 (`HttpTokens: required`).\n- **Set `trustEmailVerified: false`** until upgrade. This caps the impact at non-blind SSRF and removes the account-takeover escalation, but does not stop the SSRF.\n\n### Impact\n\n- **Server-Side Request Forgery (non-blind)**: the attacker reads response bodies from any HTTP endpoint reachable from the auth server, including cloud metadata services (AWS IMDS, GCP metadata FQDN), internal-only APIs, and infrastructure services such as Redis or admin panels bound to localhost.\n- **Account takeover** (when `trustEmailVerified: true`): the attacker mints a malicious userInfo response asserting `emailVerified: true` for an arbitrary email, triggering OAuth auto-link against pre-existing user rows.\n\n### Credit\n\nReported by Vaadata.\n\n### Resources\n\n- [CWE-918: Server-Side Request Forgery (SSRF)](https://cwe.mitre.org/data/definitions/918.html)\n- [CWE-20: Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html)\n- [CWE-441: Unintended Proxy or Intermediary](https://cwe.mitre.org/data/definitions/441.html)\n- [CWE-345: Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html)",
  "id": "GHSA-5rr4-8452-hf4v",
  "modified": "2026-07-07T20:56:19Z",
  "published": "2026-07-07T20:56:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-5rr4-8452-hf4v"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/better-auth/better-auth"
    },
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@better-auth/sso provider registration has server-side request forgery via unvalidated OIDC endpoints"
}
Mitigation
Architecture and Design

Enforce the use of strong mutual authentication mechanism between the two parties.

Mitigation
Architecture and Design

Whenever a product is an intermediary or proxy for transactions between two other components, the proxy core should not drop the identity of the initiator of the transaction. The immutability of the identity of the initiator must be maintained and should be forwarded all the way to the target.

CAPEC-219: XML Routing Detour Attacks

An attacker subverts an intermediate system used to process XML content and forces the intermediate to modify and/or re-route the processing of the content. XML Routing Detour Attacks are Adversary in the Middle type attacks (CAPEC-94). The attacker compromises or inserts an intermediate system in the processing of the XML message. For example, WS-Routing can be used to specify a series of nodes or intermediaries through which content is passed. If any of the intermediate nodes in this route are compromised by an attacker they could be used for a routing detour attack. From the compromised system the attacker is able to route the XML process to other nodes of their choice and modify the responses so that the normal chain of processing is unaware of the interception. This system can forward the message to an outside entity and hide the forwarding and processing from the legitimate processing systems by altering the header information.

CAPEC-465: Transparent Proxy Abuse

A transparent proxy serves as an intermediate between the client and the internet at large. It intercepts all requests originating from the client and forwards them to the correct location. The proxy also intercepts all responses to the client and forwards these to the client. All of this is done in a manner transparent to the client.

← Back to the CWE list