GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

5865 vulnerabilities reference this CWE, most recent first.

GHSA-4WPP-W5R4-7V5V

Vulnerability from github – Published: 2022-05-24 20:55 – Updated: 2022-05-24 20:55
VLAI
Summary
Server-Side Request Forgery in charm
Details

We've discovered a vulnerability in which attackers could forge HTTP requests to manipulate the charm data directory to access or delete anything on the server. This has been patched in https://github.com/charmbracelet/charm/commit/3c90668f955c7ce5ef721e4fc9faee7053232fd3 and is available in release v0.12.1. We recommend that all users running self-hosted charm instances update immediately.

This vulnerability was found in-house and we haven't been notified of any potential exploiters.

Additional notes

  • Encrypted user data uploaded to the Charm server is safe as Charm servers cannot decrypt user data. This includes filenames, paths, and all key-value data.
  • Users running the official Charm Docker images are at minimal risk because the exploit is limited to the containerized filesystem.

For more information

If you have any questions or comments about this advisory: * Open a discussion * Email us at vt100@charm.sh * Chat with us on Slack

the Charm logo

Charm热爱开源 • Charm loves open source

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/charmbracelet/charm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.0"
            },
            {
              "fixed": "0.12.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-29180"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-05-24T20:55:22Z",
    "nvd_published_at": "2022-05-07T04:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "We\u0027ve discovered a vulnerability in which attackers could forge HTTP requests to manipulate the `charm` data directory to access or delete anything on the server. This has been patched in https://github.com/charmbracelet/charm/commit/3c90668f955c7ce5ef721e4fc9faee7053232fd3 and is available in release [v0.12.1](https://github.com/charmbracelet/charm/releases/tag/v0.12.1). We recommend that all users running self-hosted `charm` instances update immediately.\n\nThis vulnerability was found in-house and we haven\u0027t been notified of any potential exploiters.\n\n### Additional notes\n\n* Encrypted user data uploaded to the Charm server is safe as Charm servers cannot decrypt user data. This includes filenames, paths, and all key-value data.\n* Users running the official Charm [Docker images](https://github.com/charmbracelet/charm/blob/main/docker.md) are at minimal risk because the exploit is limited to the containerized filesystem.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open a [discussion](https://github.com/charmbracelet/charm/discussions)\n* Email us at [vt100@charm.sh](mailto:vt100@charm.sh)\n* Chat with us on [Slack](https://charm.sh/slack)\n\n* * *\n\n\u003ca href=\"https://charm.sh/\"\u003e\u003cimg alt=\"the Charm logo\" src=\"https://stuff.charm.sh/charm-badge.jpg\" width=\"400\"\u003e\u003c/a\u003e\n\nCharm\u70ed\u7231\u5f00\u6e90 \u2022 Charm loves open source",
  "id": "GHSA-4wpp-w5r4-7v5v",
  "modified": "2022-05-24T20:55:22Z",
  "published": "2022-05-24T20:55:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/charmbracelet/charm/security/advisories/GHSA-4wpp-w5r4-7v5v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29180"
    },
    {
      "type": "WEB",
      "url": "https://github.com/charmbracelet/charm/commit/3c90668f955c7ce5ef721e4fc9faee7053232fd3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/charmbracelet/charm"
    }
  ],
  "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"
    }
  ],
  "summary": "Server-Side Request Forgery in charm"
}

GHSA-4WQV-6439-QQQ3

Vulnerability from github – Published: 2022-05-24 17:33 – Updated: 2022-05-24 17:33
VLAI
Details

SAP Commerce Cloud (Accelerator Payment Mock), versions - 1808, 1811, 1905, 2005, allows an unauthenticated attacker to submit a crafted request over a network to a particular SAP Commerce module URL which will be processed without further interaction, the crafted request leads to Server Side Request Forgery attack which could lead to retrieval of limited pieces of information about the service with no impact on integrity or availability.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-26811"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-10T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "SAP Commerce Cloud (Accelerator Payment Mock), versions - 1808, 1811, 1905, 2005, allows an unauthenticated attacker to submit a crafted request over a network to a particular SAP Commerce module URL which will be processed without further interaction, the crafted request leads to Server Side Request Forgery attack which could lead to retrieval of limited pieces of information about the service with no impact on integrity or availability.",
  "id": "GHSA-4wqv-6439-qqq3",
  "modified": "2022-05-24T17:33:59Z",
  "published": "2022-05-24T17:33:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26811"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/2975170"
    },
    {
      "type": "WEB",
      "url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=562725571"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/163143/SAP-Hybris-eCommerce-Server-Side-Request-Forgery.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2021/Jun/26"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-4X48-CGF9-Q33F

Vulnerability from github – Published: 2026-04-14 23:22 – Updated: 2026-04-14 23:22
VLAI
Summary
Novu has SSRF via conditions filter webhook bypasses validateUrlSsrf() protection
Details

Summary

The conditions filter webhook at libs/application-generic/src/usecases/conditions-filter/conditions-filter.usecase.ts line 261 sends POST requests to user-configured URLs using raw axios.post() with no SSRF validation. The HTTP Request workflow step in the same codebase correctly uses validateUrlSsrf() which blocks private IP ranges. The conditions webhook was not included in this protection.

Root Cause

conditions-filter.usecase.ts line 261:

return await axios.post(child.webhookUrl, payload, config).then((response) => {
  return response.data as Record<string, unknown>;
});

No call to validateUrlSsrf(). The webhookUrl comes from the workflow condition configuration with zero validation.

Protected Code (for contrast)

execute-http-request-step.usecase.ts line 130:

const ssrfValidationError = await validateUrlSsrf(url);
if (ssrfValidationError) {
  // blocked
}

This function resolves DNS and checks against private ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16). It exists in the codebase but is not applied to the conditions webhook path.

Proof of Concept

  1. Create a workflow with a condition step
  2. Configure the condition's webhook URL to http://169.254.169.254/latest/meta-data/iam/security-credentials/
  3. Trigger the workflow by sending a notification event
  4. The worker evaluates the condition and calls axios.post() to the metadata endpoint
  5. The response data is stored in execution details and accessible via the execution details API

Impact

Full-read SSRF. The response body is returned as Record<string, unknown> for condition evaluation and stored in the execution details raw field. The GET /execution-details API returns this data.

The POST method limits some metadata endpoints (GCP requires GET, Azure requires GET), but AWS IMDSv1 accepts POST and returns credentials. Internal services accepting POST are also reachable.

Suggested Fix

Extract validateUrlSsrf() to a shared utility and call it before the axios.post in conditions-filter.usecase.ts:

const ssrfError = await validateUrlSsrf(child.webhookUrl);
if (ssrfError) {
  throw new Error('Webhook URL blocked by SSRF protection');
}
return await axios.post(child.webhookUrl, payload, config)...
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@novu/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.15.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T23:22:48Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe conditions filter webhook at `libs/application-generic/src/usecases/conditions-filter/conditions-filter.usecase.ts` line 261 sends POST requests to user-configured URLs using raw `axios.post()` with no SSRF validation. The HTTP Request workflow step in the same codebase correctly uses `validateUrlSsrf()` which blocks private IP ranges. The conditions webhook was not included in this protection.\n\n## Root Cause\n\n`conditions-filter.usecase.ts` line 261:\n```typescript\nreturn await axios.post(child.webhookUrl, payload, config).then((response) =\u003e {\n  return response.data as Record\u003cstring, unknown\u003e;\n});\n```\n\nNo call to `validateUrlSsrf()`. The `webhookUrl` comes from the workflow condition configuration with zero validation.\n\n## Protected Code (for contrast)\n\n`execute-http-request-step.usecase.ts` line 130:\n```typescript\nconst ssrfValidationError = await validateUrlSsrf(url);\nif (ssrfValidationError) {\n  // blocked\n}\n```\n\nThis function resolves DNS and checks against private ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16). It exists in the codebase but is not applied to the conditions webhook path.\n\n## Proof of Concept\n\n1. Create a workflow with a condition step\n2. Configure the condition\u0027s webhook URL to `http://169.254.169.254/latest/meta-data/iam/security-credentials/`\n3. Trigger the workflow by sending a notification event\n4. The worker evaluates the condition and calls `axios.post()` to the metadata endpoint\n5. The response data is stored in execution details and accessible via the execution details API\n\n## Impact\n\nFull-read SSRF. The response body is returned as `Record\u003cstring, unknown\u003e` for condition evaluation and stored in the execution details `raw` field. The `GET /execution-details` API returns this data.\n\nThe POST method limits some metadata endpoints (GCP requires GET, Azure requires GET), but AWS IMDSv1 accepts POST and returns credentials. Internal services accepting POST are also reachable.\n\n## Suggested Fix\n\nExtract `validateUrlSsrf()` to a shared utility and call it before the axios.post in conditions-filter.usecase.ts:\n\n```typescript\nconst ssrfError = await validateUrlSsrf(child.webhookUrl);\nif (ssrfError) {\n  throw new Error(\u0027Webhook URL blocked by SSRF protection\u0027);\n}\nreturn await axios.post(child.webhookUrl, payload, config)...\n```",
  "id": "GHSA-4x48-cgf9-q33f",
  "modified": "2026-04-14T23:22:48Z",
  "published": "2026-04-14T23:22:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/novuhq/novu/security/advisories/GHSA-4x48-cgf9-q33f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/novuhq/novu/commit/87d965eb88340ac7cd262dd52c8015acd092dc68"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/novuhq/novu"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Novu has SSRF via conditions filter webhook bypasses validateUrlSsrf() protection"
}

GHSA-4X7W-PWQ5-598Q

Vulnerability from github – Published: 2026-08-20 12:31 – Updated: 2026-09-01 21:31
VLAI
Details

n8n before 1.123.69, 2.33.4, and 2.34.1 contains an SSRF protection bypass in the OAuth2 credential authorization-code-to-access-token exchange. While OAuth2 discovery and dynamic-client-registration requests use n8n's SSRF-protected HTTP client, the token exchange uses a separate client with no SSRF guard. A user with credential-creation permissions can set the access-token URL to an internal address and complete the OAuth2 flow, causing n8n to send a fixed-shape token-exchange POST to that target and reflect its response body back to the attacker (limited to what the target returns to this specific request).

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-77069"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-20T12:16:38Z",
    "severity": "LOW"
  },
  "details": "n8n before 1.123.69, 2.33.4, and 2.34.1 contains an SSRF protection bypass in the OAuth2 credential authorization-code-to-access-token exchange. While OAuth2 discovery and dynamic-client-registration requests use n8n\u0027s SSRF-protected HTTP client, the token exchange uses a separate client with no SSRF guard. A user with credential-creation permissions can set the access-token URL to an internal address and complete the OAuth2 flow, causing n8n to send a fixed-shape token-exchange POST to that target and reflect its response body back to the attacker (limited to what the target returns to this specific request).",
  "id": "GHSA-4x7w-pwq5-598q",
  "modified": "2026-09-01T21:31:19Z",
  "published": "2026-08-20T12:31:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-c4f6-59xq-95ww"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77069"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/n8n-before-ssrf-protection-bypass-via-oauth2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/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"
    }
  ]
}

GHSA-4X9J-CJQ3-HXHF

Vulnerability from github – Published: 2024-07-22 12:30 – Updated: 2024-07-22 12:30
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Noor alam Magical Addons For Elementor.This issue affects Magical Addons For Elementor: from n/a through 1.1.41.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-38730"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-22T11:15:04Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Noor alam Magical Addons For Elementor.This issue affects Magical Addons For Elementor: from n/a through 1.1.41.",
  "id": "GHSA-4x9j-cjq3-hxhf",
  "modified": "2024-07-22T12:30:38Z",
  "published": "2024-07-22T12:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38730"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/magical-addons-for-elementor/wordpress-magical-addons-for-elementor-plugin-1-1-40-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4XHM-Q9H6-MQ38

Vulnerability from github – Published: 2023-11-13 03:30 – Updated: 2026-04-28 21:33
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Dimitar Ivanov HTTP Headers.This issue affects HTTP Headers: from n/a through 1.18.11.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-37978"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-13T03:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Dimitar Ivanov HTTP Headers.This issue affects HTTP Headers: from n/a through 1.18.11.",
  "id": "GHSA-4xhm-q9h6-mq38",
  "modified": "2026-04-28T21:33:07Z",
  "published": "2023-11-13T03:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37978"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/http-headers/wordpress-http-headers-plugin-1-18-11-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4XP8-858J-G46W

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

A security vulnerability has been detected in jina-ai reader up to 1574bfd380d249c86c82db4dace0d9c8fe17e2b1. This issue affects the function isValidTLD of the file /backend/functions/src/cloud-functions/crawler.ts of the component Crawler/Puppeteer. The manipulation leads to server-side request forgery. Remote exploitation of the attack is possible. The exploit has been disclosed publicly and may be used. This product follows a rolling release approach for continuous delivery, so version details for affected or updated releases are not provided. The vendor was contacted early about this disclosure but did not respond in any way.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-18647"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-03T21:16:37Z",
    "severity": "MODERATE"
  },
  "details": "A security vulnerability has been detected in jina-ai reader up to 1574bfd380d249c86c82db4dace0d9c8fe17e2b1. This issue affects the function isValidTLD of the file /backend/functions/src/cloud-functions/crawler.ts of the component Crawler/Puppeteer. The manipulation leads to server-side request forgery. Remote exploitation of the attack is possible. The exploit has been disclosed publicly and may be used. This product follows a rolling release approach for continuous delivery, so version details for affected or updated releases are not provided. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-4xp8-858j-g46w",
  "modified": "2026-08-03T21:31:37Z",
  "published": "2026-08-03T21:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18647"
    },
    {
      "type": "WEB",
      "url": "https://github.com/orionyan520/cve_report/issues/8"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-18647"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/855011"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/385566"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/385566/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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-4XRF-JV44-H6HH

Vulnerability from github – Published: 2026-08-03 19:59 – Updated: 2026-08-03 19:59
VLAI
Summary
ip-address: a CIDR suffix on the parsed address suppresses special-use classification and can bypass SSRF and trust-boundary checks
Details

Summary

Every special-use classification method is built on isInSubnet, which short-circuits to false whenever the address's own subnet mask is shorter than the reference range's mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as /0 suppresses classification entirely: isLoopback(), isPrivate(), isLinkLocal(), isCGNAT(), isMulticast(), isUnspecified(), isBroadcast(), isULA(), and getType() all report an internal address as unremarkable, while correctForm() and address still return the real internal target.

An application that builds a network trust-boundary decision on these checks (for example a filter intended to block Server-Side Request Forgery, or SSRF) may therefore treat an internal target as external and allow the request. SSRF is an attack in which a user-supplied address coaxes the server into making a request to an internal destination the user could not otherwise reach, such as a loopback service or a cloud metadata endpoint.

Details

isInSubnet in src/common.ts opens with a guard that compares the two prefix lengths:

export function isInSubnet(this, address) {
  if (this.subnetMask < address.subnetMask) {
    return false;                                  // <-- reached before any bit comparison
  }

  if (this.mask(address.subnetMask) === address.mask()) {
    return true;
  }

  return false;
}

That guard is correct for the question isInSubnet is named for — whether one network is contained in another, where a /0 network genuinely is not inside a /8. It is wrong for classification, which asks a question about the address itself and must not depend on the prefix the caller happened to write. /0 is shorter than every reference prefix in the special-use tables (loopback /8, link-local /16, CGNAT /10, ULA /7, multicast /4), so for a classification call the bit comparison is never reached and the method returns false.

The underlying bit comparison is correct, and mask(n) already returns the first n bits of the full parsed address independently of subnetMask — the defect is solely that the containment guard sits in the classification path. Host bits are retained through parsing, so correctForm() still yields the real target and the address remains fully usable for connecting.

/0 is the universal case because it is shorter than every reference prefix, but any suffix shorter than the specific range being tested has the same effect: 10.0.0.5/7 defeats isPrivate() for 10.0.0.0/8.

Affected versions

>= 10.1.1, <= 10.2.1. The is* classification API was introduced for Address4 in 10.1.1 and extended to Address6 in 10.2.0; releases before 10.1.1 do not expose it and are not affected through this vector. The containment guard itself is much older, but isInSubnet alone is a subnet-containment predicate whose behavior here is correct.

This also defeats the fix released in 10.2.1 for GHSA-22jq-vg5j-6vgg: that release classifies IPv4-mapped and NAT64 addresses by their embedded IPv4 address, but the normalization is reached through isInSubnet, so ::ffff:127.0.0.1/0 reverts to being reported as non-internal.

Impact

Every classifier is affected on both Address4 and Address6. The sole exception is Address6.isLinkLocal() for native fe80::/10 addresses, which compares raw bits directly; its IPv4-mapped path is still affected.

Address Reported as Actually points at
127.0.0.1/0 not loopback loopback (127.0.0.0/8)
10.0.0.1/0, 10.0.0.5/7 not private RFC 1918 10/8
172.16.5.5/0 not private RFC 1918 172.16/12
192.168.1.1/0 not private RFC 1918 192.168/16
169.254.169.254/0 not link-local link-local / cloud metadata (IMDS)
100.64.0.1/0 not CGNAT CGNAT 100.64/10
0.0.0.0/0, 255.255.255.255/0 not unspecified / not broadcast unspecified / broadcast
::1/0 not loopback IPv6 loopback
fc00::1/0 not ULA, not private IPv6 ULA fc00::/7
ff02::1/0 not multicast IPv6 multicast
::ffff:127.0.0.1/0 not loopback loopback, via IPv4-mapped
::ffff:169.254.169.254/0 not link-local IMDS, via IPv4-mapped
64:ff9b::7f00:1/0 not loopback loopback, via NAT64

getType() returns Global unicast for all of the IPv6 cases above, and getScope() follows it.

Reachability

A CIDR suffix is not legal in a URL host, so this is not reachable through the most common SSRF shape. new URL('http://127.0.0.1/0') parses hostname as 127.0.0.1 and pathname as /0, and a guard that classifies the extracted hostname is unaffected. Exploitation requires an application that accepts a bare address string that may carry a suffix and passes it to the constructor before classifying — for example an allow/deny field, a webhook target, or a proxy destination taken as a plain host rather than parsed out of a URL.

Proof of concept

npm i ip-address@10.2.1, then:

const { Address4, Address6 } = require('ip-address');

// true => block as internal, false => allow outbound
function isBlocked(host) {
  try {
    const a = new Address4(host);
    return a.isPrivate() || a.isLoopback() || a.isLinkLocal() || a.isCGNAT()
        || a.isMulticast() || a.isUnspecified() || a.isBroadcast();
  } catch {}
  try {
    const a = new Address6(host);
    return a.isPrivate() || a.isLoopback() || a.isLinkLocal() || a.isULA()
        || a.isMulticast() || a.isUnspecified();
  } catch {}
  return false;
}

for (const h of ['127.0.0.1', '10.0.0.1', '::1',
                 '127.0.0.1/0', '10.0.0.5/7', '169.254.169.254/0',
                 '::1/0', '::ffff:127.0.0.1/0', '64:ff9b::7f00:1/0']) {
  console.log(isBlocked(h) ? 'BLOCK ' : 'ALLOW ', h, '->', new (h.includes(':') ? Address6 : Address4)(h).correctForm());
}

On affected versions every suffixed internal target is allowed, and correctForm() shows the request would reach the real internal address:

BLOCK  127.0.0.1 -> 127.0.0.1
BLOCK  10.0.0.1 -> 10.0.0.1
BLOCK  ::1 -> ::1
ALLOW  127.0.0.1/0 -> 127.0.0.1
ALLOW  10.0.0.5/7 -> 10.0.0.5
ALLOW  169.254.169.254/0 -> 169.254.169.254
ALLOW  ::1/0 -> ::1
ALLOW  ::ffff:127.0.0.1/0 -> ::ffff:7f00:1
ALLOW  64:ff9b::7f00:1/0 -> 64:ff9b::7f00:1

The first three lines are blocked as expected; the same destinations with a CIDR suffix are allowed through.

Remediation

Upgrade to the patched release. In the fix, classification no longer consults the address's own prefix: a new isHostInSubnet() compares the address's host bits against the reference range only, and every classifier (isLoopback, isPrivate, isLinkLocal, isCGNAT, isMulticast, isUnspecified, isBroadcast, isULA, isMapped4, isTeredo, is6to4, isDocumentation, getType, and the IPv4-mapped/NAT64 normalization behind embeddedIPv4) uses it. isInSubnet keeps its subnet-containment semantics unchanged, including the guard that a wider network is not contained in a narrower one. After upgrading, new Address4('127.0.0.1/0').isLoopback() returns true.

If you cannot upgrade immediately, strip the suffix before classifying by re-parsing addressMinusSuffix:

const parsed = new Address4(userInput);
const host = new Address4(parsed.addressMinusSuffix);   // classify this one

A note on SSRF defense

These methods are address classifiers, not a complete SSRF defense. Regardless of this fix, a robust SSRF guard must resolve the hostname and validate the resolved IP against the socket it connects to, and account for DNS rebinding and redirects. Treat these checks as one layer, not the only one.

Credit

Reported by @hi-im-glitchless.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.2.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "ip-address"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.1.1"
            },
            {
              "fixed": "10.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-69198"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-03T19:59:33Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nEvery special-use classification method is built on `isInSubnet`, which short-circuits to `false` whenever the address\u0027s own subnet mask is *shorter* than the reference range\u0027s mask. That mask comes verbatim from the CIDR suffix on the parsed input, so appending a suffix such as `/0` suppresses classification entirely: `isLoopback()`, `isPrivate()`, `isLinkLocal()`, `isCGNAT()`, `isMulticast()`, `isUnspecified()`, `isBroadcast()`, `isULA()`, and `getType()` all report an internal address as unremarkable, while `correctForm()` and `address` still return the real internal target.\n\nAn application that builds a network trust-boundary decision on these checks (for example a filter intended to block Server-Side Request Forgery, or SSRF) may therefore treat an internal target as external and allow the request. SSRF is an attack in which a user-supplied address coaxes the server into making a request to an internal destination the user could not otherwise reach, such as a loopback service or a cloud metadata endpoint.\n\n### Details\n\n`isInSubnet` in `src/common.ts` opens with a guard that compares the two prefix lengths:\n\n```js\nexport function isInSubnet(this, address) {\n  if (this.subnetMask \u003c address.subnetMask) {\n    return false;                                  // \u003c-- reached before any bit comparison\n  }\n\n  if (this.mask(address.subnetMask) === address.mask()) {\n    return true;\n  }\n\n  return false;\n}\n```\n\nThat guard is correct for the question `isInSubnet` is named for \u2014 whether one *network* is contained in another, where a `/0` network genuinely is not inside a `/8`. It is wrong for classification, which asks a question about the address itself and must not depend on the prefix the caller happened to write. `/0` is shorter than every reference prefix in the special-use tables (loopback `/8`, link-local `/16`, CGNAT `/10`, ULA `/7`, multicast `/4`), so for a classification call the bit comparison is never reached and the method returns `false`.\n\nThe underlying bit comparison is correct, and `mask(n)` already returns the first `n` bits of the full parsed address independently of `subnetMask` \u2014 the defect is solely that the containment guard sits in the classification path. Host bits are retained through parsing, so `correctForm()` still yields the real target and the address remains fully usable for connecting.\n\n`/0` is the universal case because it is shorter than every reference prefix, but any suffix shorter than the specific range being tested has the same effect: `10.0.0.5/7` defeats `isPrivate()` for `10.0.0.0/8`.\n\n### Affected versions\n\n`\u003e= 10.1.1, \u003c= 10.2.1`. The `is*` classification API was introduced for `Address4` in 10.1.1 and extended to `Address6` in 10.2.0; releases before 10.1.1 do not expose it and are not affected through this vector. The containment guard itself is much older, but `isInSubnet` alone is a subnet-containment predicate whose behavior here is correct.\n\nThis also defeats the fix released in 10.2.1 for GHSA-22jq-vg5j-6vgg: that release classifies IPv4-mapped and NAT64 addresses by their embedded IPv4 address, but the normalization is reached through `isInSubnet`, so `::ffff:127.0.0.1/0` reverts to being reported as non-internal.\n\n### Impact\n\nEvery classifier is affected on both `Address4` and `Address6`. The sole exception is `Address6.isLinkLocal()` for *native* `fe80::/10` addresses, which compares raw bits directly; its IPv4-mapped path is still affected.\n\n| Address | Reported as | Actually points at |\n|---|---|---|\n| `127.0.0.1/0` | not loopback | loopback (`127.0.0.0/8`) |\n| `10.0.0.1/0`, `10.0.0.5/7` | not private | RFC 1918 `10/8` |\n| `172.16.5.5/0` | not private | RFC 1918 `172.16/12` |\n| `192.168.1.1/0` | not private | RFC 1918 `192.168/16` |\n| `169.254.169.254/0` | not link-local | link-local / cloud metadata (IMDS) |\n| `100.64.0.1/0` | not CGNAT | CGNAT `100.64/10` |\n| `0.0.0.0/0`, `255.255.255.255/0` | not unspecified / not broadcast | unspecified / broadcast |\n| `::1/0` | not loopback | IPv6 loopback |\n| `fc00::1/0` | not ULA, not private | IPv6 ULA `fc00::/7` |\n| `ff02::1/0` | not multicast | IPv6 multicast |\n| `::ffff:127.0.0.1/0` | not loopback | loopback, via IPv4-mapped |\n| `::ffff:169.254.169.254/0` | not link-local | IMDS, via IPv4-mapped |\n| `64:ff9b::7f00:1/0` | not loopback | loopback, via NAT64 |\n\n`getType()` returns `Global unicast` for all of the IPv6 cases above, and `getScope()` follows it.\n\n### Reachability\n\nA CIDR suffix is not legal in a URL host, so this is not reachable through the most common SSRF shape. `new URL(\u0027http://127.0.0.1/0\u0027)` parses `hostname` as `127.0.0.1` and `pathname` as `/0`, and a guard that classifies the extracted hostname is unaffected. Exploitation requires an application that accepts a bare address string that may carry a suffix and passes it to the constructor before classifying \u2014 for example an allow/deny field, a webhook target, or a proxy destination taken as a plain host rather than parsed out of a URL.\n\n### Proof of concept\n\n`npm i ip-address@10.2.1`, then:\n\n```js\nconst { Address4, Address6 } = require(\u0027ip-address\u0027);\n\n// true =\u003e block as internal, false =\u003e allow outbound\nfunction isBlocked(host) {\n  try {\n    const a = new Address4(host);\n    return a.isPrivate() || a.isLoopback() || a.isLinkLocal() || a.isCGNAT()\n        || a.isMulticast() || a.isUnspecified() || a.isBroadcast();\n  } catch {}\n  try {\n    const a = new Address6(host);\n    return a.isPrivate() || a.isLoopback() || a.isLinkLocal() || a.isULA()\n        || a.isMulticast() || a.isUnspecified();\n  } catch {}\n  return false;\n}\n\nfor (const h of [\u0027127.0.0.1\u0027, \u002710.0.0.1\u0027, \u0027::1\u0027,\n                 \u0027127.0.0.1/0\u0027, \u002710.0.0.5/7\u0027, \u0027169.254.169.254/0\u0027,\n                 \u0027::1/0\u0027, \u0027::ffff:127.0.0.1/0\u0027, \u002764:ff9b::7f00:1/0\u0027]) {\n  console.log(isBlocked(h) ? \u0027BLOCK \u0027 : \u0027ALLOW \u0027, h, \u0027-\u003e\u0027, new (h.includes(\u0027:\u0027) ? Address6 : Address4)(h).correctForm());\n}\n```\n\nOn affected versions every suffixed internal target is allowed, and `correctForm()` shows the request would reach the real internal address:\n\n```\nBLOCK  127.0.0.1 -\u003e 127.0.0.1\nBLOCK  10.0.0.1 -\u003e 10.0.0.1\nBLOCK  ::1 -\u003e ::1\nALLOW  127.0.0.1/0 -\u003e 127.0.0.1\nALLOW  10.0.0.5/7 -\u003e 10.0.0.5\nALLOW  169.254.169.254/0 -\u003e 169.254.169.254\nALLOW  ::1/0 -\u003e ::1\nALLOW  ::ffff:127.0.0.1/0 -\u003e ::ffff:7f00:1\nALLOW  64:ff9b::7f00:1/0 -\u003e 64:ff9b::7f00:1\n```\n\nThe first three lines are blocked as expected; the same destinations with a CIDR suffix are allowed through.\n\n### Remediation\n\nUpgrade to the patched release. In the fix, classification no longer consults the address\u0027s own prefix: a new `isHostInSubnet()` compares the address\u0027s host bits against the reference range only, and every classifier (`isLoopback`, `isPrivate`, `isLinkLocal`, `isCGNAT`, `isMulticast`, `isUnspecified`, `isBroadcast`, `isULA`, `isMapped4`, `isTeredo`, `is6to4`, `isDocumentation`, `getType`, and the IPv4-mapped/NAT64 normalization behind `embeddedIPv4`) uses it. `isInSubnet` keeps its subnet-containment semantics unchanged, including the guard that a wider network is not contained in a narrower one. After upgrading, `new Address4(\u0027127.0.0.1/0\u0027).isLoopback()` returns `true`.\n\nIf you cannot upgrade immediately, strip the suffix before classifying by re-parsing `addressMinusSuffix`:\n\n```js\nconst parsed = new Address4(userInput);\nconst host = new Address4(parsed.addressMinusSuffix);   // classify this one\n```\n\n### A note on SSRF defense\n\nThese methods are address classifiers, not a complete SSRF defense. Regardless of this fix, a robust SSRF guard must resolve the hostname and validate the *resolved* IP against the socket it connects to, and account for DNS rebinding and redirects. Treat these checks as one layer, not the only one.\n\n### Credit\n\nReported by @hi-im-glitchless.",
  "id": "GHSA-4xrf-jv44-h6hh",
  "modified": "2026-08-03T19:59:33Z",
  "published": "2026-08-03T19:59:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-4xrf-jv44-h6hh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/beaugunderson/ip-address/commit/488fe9bc7c35363b4b090494fc38c266d217740d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/beaugunderson/ip-address"
    },
    {
      "type": "WEB",
      "url": "https://github.com/beaugunderson/ip-address/releases/tag/v10.2.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "ip-address: a CIDR suffix on the parsed address suppresses special-use classification and can bypass SSRF and trust-boundary checks"
}

GHSA-4XRQ-5CGC-J65H

Vulnerability from github – Published: 2022-12-29 21:30 – Updated: 2023-01-09 18:30
VLAI
Details

Protections against potential Server-Side Request Forgery (SSRF) vulnerabilities in Esri Portal for ArcGIS versions 10.8.1 and below were not fully honored and may allow a remote, unauthenticated attacker to forge requests to arbitrary URLs from the system, potentially leading to network enumeration or reading from hosts inside the network perimeter, a different issue than CVE-2022-38211 and CVE-2022-38203.

Severity
7.5 (High)
CVSS:3.1/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-2022-38212"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-29T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Protections against potential Server-Side Request Forgery (SSRF) vulnerabilities in Esri Portal for ArcGIS versions 10.8.1 and below were not fully honored and may allow a remote, unauthenticated attacker to forge requests to arbitrary URLs from the system, potentially leading to network enumeration or reading from hosts inside the network perimeter, a different issue than CVE-2022-38211 and CVE-2022-38203.",
  "id": "GHSA-4xrq-5cgc-j65h",
  "modified": "2023-01-09T18:30:18Z",
  "published": "2022-12-29T21:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38212"
    },
    {
      "type": "WEB",
      "url": "https://www.esri.com/arcgis-blog/products/trust-arcgis/administration/portal-for-arcgis-security-2022-update-2-patch-is-now-available"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5227-22F5-M93M

Vulnerability from github – Published: 2025-01-11 03:30 – Updated: 2025-01-11 03:30
VLAI
Details

HCL MyXalytics is affected by out-of-band resource load (HTTP) vulnerability. An attacker can deploy a web server that returns malicious content, and then induce the application to retrieve and process that content.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-42168"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-610",
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-11T03:15:21Z",
    "severity": "HIGH"
  },
  "details": "HCL MyXalytics is affected by out-of-band resource load (HTTP) vulnerability.  An attacker can deploy a web server that returns malicious content, and then induce the application to retrieve and process that content.",
  "id": "GHSA-5227-22f5-m93m",
  "modified": "2025-01-11T03:30:40Z",
  "published": "2025-01-11T03:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42168"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0118149"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.

← Back to the CWE list