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.

4590 vulnerabilities reference this CWE, most recent first.

GHSA-XRWR-FCW6-FMQ8

Vulnerability from github – Published: 2026-04-16 20:43 – Updated: 2026-04-16 20:43
VLAI
Summary
Weblate: SSRF via Project-Level Machinery Configuration
Details

Impact

A user with the project.edit permission (granted by the per-project "Administration" role) can configure machine translation service URLs pointing to arbitrary internal network addresses. During configuration validation, Weblate makes an HTTP request to the attacker-controlled URL and reflects up to 200 characters of the response body back to the user in an error message. This constitutes a Server-Side Request Forgery (SSRF) with partial response read.

Patches

  • https://github.com/WeblateOrg/weblate/pull/18684
  • The solution then has been cleaned up in followup patches

Workarounds

Limiting available machinery services via WEBLATE_MACHINERY setting can avoid this.

References

Thanks to @DavidCarliez for disclosing this via GitHub private vulnerability reporting.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "weblate"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T20:43:38Z",
    "nvd_published_at": "2026-04-15T19:16:35Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nA user with the `project.edit` permission (granted by the per-project \"Administration\" role) can configure machine translation service URLs pointing to arbitrary internal network addresses. During configuration validation, Weblate makes an HTTP request to the attacker-controlled URL and reflects up to 200 characters of the response body back to the user in an error message. This constitutes a Server-Side Request Forgery (SSRF) with partial response read.\n\n### Patches\n\n* https://github.com/WeblateOrg/weblate/pull/18684\n* The solution then has been cleaned up in followup patches\n\n### Workarounds\nLimiting available machinery services via WEBLATE_MACHINERY setting can avoid this.\n\n### References\n\nThanks to @DavidCarliez for disclosing this via GitHub private vulnerability reporting.",
  "id": "GHSA-xrwr-fcw6-fmq8",
  "modified": "2026-04-16T20:43:38Z",
  "published": "2026-04-16T20:43:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WeblateOrg/weblate/security/advisories/GHSA-xrwr-fcw6-fmq8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34244"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WeblateOrg/weblate/pull/18684"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WeblateOrg/weblate/commit/e619e9090202e4886b844c110d39308e7e882c0e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WeblateOrg/weblate"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Weblate: SSRF via Project-Level Machinery Configuration "
}

GHSA-XRXM-CP7J-8XF6

Vulnerability from github – Published: 2026-06-15 16:39 – Updated: 2026-06-15 16:39
VLAI
Summary
@angular/platform-server: URL Parser Differential leading to SSRF Allowlist Bypass
Details

An issue in the @angular/platform-server package allows remote attackers to bypass host allowlist constraints and direct server-side outgoing requests to arbitrary external endpoints. This occurs due to a parser differential between the strict WHATWG URL parser used for allowlist validation and the lenient Domino URL parser used to initialize the server emulated DOM.

When a server-side request contains a malformed URL with a double port structure (e.g., http://evil.com:80:80/path), Node's strict URL.canParse(url) logic returns false and skips host check validation entirely. However, the same malformed URL is later accepted and parsed leniently by Domino's internal parser, which resolves the origin to http://evil.com:80. The Angular SSR HTTP request interceptor (relativeUrlsTransformerInterceptorFn) then resolves all relative backend HTTP requests against this adopted origin, executing the SSRF attack.

Impact

Any Angular application utilizing server-side rendering (@angular/platform-server) that configures host routing allowlists (allowedHosts) is vulnerable to this allowlist bypass.

By sending an HTTP request with a malformed Host header (e.g. Host: evil.com:80:80) or an absolute-form request URI, an attacker can bypass the allowlist logic completely (even when configured with a strict default deny setup). The SSR application will then route all relative HttpClient outgoing API queries—which commonly carry sensitive credentials, session cookies, and internal authorization tokens—to the attacker-controlled server instead of the intended backend services. Additionally, the attacker can supply custom payloads back to the emulated DOM, leading to response injection and content poisoning within the rendered HTML served to users.

Attack Preconditions

To successfully exploit this vulnerability, the following environment parameters and application states must all concurrently exist:

  1. Active Server-Side Rendering (SSR): The application must be configured to run with Angular Server-Side Rendering (@angular/platform-server).
  2. Host Header/URI Propagation: The SSR handler must reconstruct the request URL using raw client inputs (such as request Host headers or absolute-form URIs) and pass it as config.url to the rendering API (renderApplication or renderModule).
  3. Outbound Relative HTTP Requests: The server application must perform outbound backend API requests using relative paths (e.g., this.http.get('/api/data')) that undergo base-URL interceptor rewriting.
  4. Enabled Allowed Hosts Check: The server must use the framework-provided allowedHosts options to limit valid server locations.

Patches

  • 22.0.0-rc.2
  • 21.2.15
  • 20.3.22
  • 19.2.23
Severity
8.8 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/platform-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "22.0.0-next.0"
            },
            {
              "fixed": "22.0.0-rc.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/platform-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "20.0.0-next.0"
            },
            {
              "fixed": "20.3.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/platform-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.0.0-next.0"
            },
            {
              "fixed": "19.2.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/platform-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "18.2.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/platform-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "21.0.0-next.0"
            },
            {
              "fixed": "21.2.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50168"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T16:39:20Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "An issue in the `@angular/platform-server` package allows remote attackers to bypass host allowlist constraints and direct server-side outgoing requests to arbitrary external endpoints. This occurs due to a parser differential between the strict WHATWG URL parser used for allowlist validation and the lenient Domino URL parser used to initialize the server emulated DOM.\n\nWhen a server-side request contains a malformed URL with a double port structure (e.g., `http://evil.com:80:80/path`), Node\u0027s strict `URL.canParse(url)` logic returns `false` and skips host check validation entirely. However, the same malformed URL is later accepted and parsed leniently by Domino\u0027s internal parser, which resolves the origin to `http://evil.com:80`. The Angular SSR HTTP request interceptor (`relativeUrlsTransformerInterceptorFn`) then resolves all relative backend HTTP requests against this adopted origin, executing the SSRF attack.\n\n### Impact\n\nAny Angular application utilizing server-side rendering (`@angular/platform-server`) that configures host routing allowlists (`allowedHosts`) is vulnerable to this allowlist bypass. \n\nBy sending an HTTP request with a malformed Host header (e.g. `Host: evil.com:80:80`) or an absolute-form request URI, an attacker can bypass the allowlist logic completely (even when configured with a strict default deny setup). The SSR application will then route all relative `HttpClient` outgoing API queries\u2014which commonly carry sensitive credentials, session cookies, and internal authorization tokens\u2014to the attacker-controlled server instead of the intended backend services. Additionally, the attacker can supply custom payloads back to the emulated DOM, leading to response injection and content poisoning within the rendered HTML served to users.\n\n### Attack Preconditions\n\nTo successfully exploit this vulnerability, the following environment parameters and application states must all concurrently exist:\n\n1. **Active Server-Side Rendering (SSR):** The application must be configured to run with Angular Server-Side Rendering (`@angular/platform-server`).\n2. **Host Header/URI Propagation:** The SSR handler must reconstruct the request URL using raw client inputs (such as request Host headers or absolute-form URIs) and pass it as `config.url` to the rendering API (`renderApplication` or `renderModule`).\n3. **Outbound Relative HTTP Requests:** The server application must perform outbound backend API requests using relative paths (e.g., `this.http.get(\u0027/api/data\u0027)`) that undergo base-URL interceptor rewriting.\n4. **Enabled Allowed Hosts Check:** The server must use the framework-provided `allowedHosts` options to limit valid server locations.\n\n### Patches\n\n* 22.0.0-rc.2\n* 21.2.15\n* 20.3.22\n* 19.2.23",
  "id": "GHSA-xrxm-cp7j-8xf6",
  "modified": "2026-06-15T16:39:20Z",
  "published": "2026-06-15T16:39:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/security/advisories/GHSA-xrxm-cp7j-8xf6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/pull/68928"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/angular/angular"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@angular/platform-server: URL Parser Differential leading to SSRF Allowlist Bypass"
}

GHSA-XV9C-V5PW-JXVF

Vulnerability from github – Published: 2026-07-13 09:31 – Updated: 2026-07-13 09:31
VLAI
Details

A Server-Side Request Forgery (SSRF) protection bypass existed in the html_to_markdown expansion module of misp-modules.

The module attempts to prevent requests to loopback, private, link-local, and other restricted IP address ranges. However, IP addresses were compared against the blocked ranges without first normalising IPv4-mapped IPv6 addresses.

An authenticated attacker able to invoke the module could supply an IPv4-mapped IPv6 address, such as:

http://[::ffff:127.0.0.1]/ http://[::ffff:169.254.169.254]/

Alternatively, the attacker could use a hostname that resolves to an IPv4-mapped IPv6 address. These addresses were treated as IPv6 addresses and therefore did not match the corresponding blocked IPv4 ranges.

Successful exploitation could cause the misp-modules server to connect to services available through its loopback interface, internal network, or link-local network. This could expose internal web services, administrative interfaces, or cloud instance metadata, with retrieved content potentially returned to the attacker as converted Markdown.

The vulnerability has been addressed by normalising IPv4-mapped IPv6 addresses to their underlying IPv4 representation before applying the blocked-range checks. URLs without a valid hostname are now also rejected.

Severity
8.3 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/AU:Y/RE:M/U:Green
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-62143"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-13T09:16:24Z",
    "severity": "HIGH"
  },
  "details": "A Server-Side Request Forgery (SSRF) protection bypass existed in the html_to_markdown expansion module of misp-modules.\n\nThe module attempts to prevent requests to loopback, private, link-local, and other restricted IP address ranges. However, IP addresses were compared against the blocked ranges without first normalising IPv4-mapped IPv6 addresses.\n\nAn authenticated attacker able to invoke the module could supply an IPv4-mapped IPv6 address, such as:\n\nhttp://[::ffff:127.0.0.1]/\nhttp://[::ffff:169.254.169.254]/\n\nAlternatively, the attacker could use a hostname that resolves to an IPv4-mapped IPv6 address. These addresses were treated as IPv6 addresses and therefore did not match the corresponding blocked IPv4 ranges.\n\nSuccessful exploitation could cause the misp-modules server to connect to services available through its loopback interface, internal network, or link-local network. This could expose internal web services, administrative interfaces, or cloud instance metadata, with retrieved content potentially returned to the attacker as converted Markdown.\n\nThe vulnerability has been addressed by normalising IPv4-mapped IPv6 addresses to their underlying IPv4 representation before applying the blocked-range checks. URLs without a valid hostname are now also rejected.",
  "id": "GHSA-xv9c-v5pw-jxvf",
  "modified": "2026-07-13T09:31:43Z",
  "published": "2026-07-13T09:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62143"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/misp-modules/commit/3bae4108a3ba1e507727d5264697fd7303ba0b89"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/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:Y/R:X/V:X/RE:M/U:Green",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-XVJ8-FGFH-F3GX

Vulnerability from github – Published: 2025-10-27 03:30 – Updated: 2026-01-20 15:31
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Codeless Slider Templates slider-templates allows Server Side Request Forgery.This issue affects Slider Templates: from n/a through <= 1.0.3.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-62988"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-27T02:15:59Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Codeless Slider Templates slider-templates allows Server Side Request Forgery.This issue affects Slider Templates: from n/a through \u003c= 1.0.3.",
  "id": "GHSA-xvj8-fgfh-f3gx",
  "modified": "2026-01-20T15:31:39Z",
  "published": "2025-10-27T03:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62988"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/slider-templates/vulnerability/wordpress-slider-templates-plugin-1-0-3-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://vdp.patchstack.com/database/Wordpress/Plugin/slider-templates/vulnerability/wordpress-slider-templates-plugin-1-0-3-server-side-request-forgery-ssrf-vulnerability"
    },
    {
      "type": "WEB",
      "url": "https://vdp.patchstack.com/database/Wordpress/Plugin/slider-templates/vulnerability/wordpress-slider-templates-plugin-1-0-3-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XVPJ-P677-68R9

Vulnerability from github – Published: 2026-01-01 18:30 – Updated: 2026-01-01 18:30
VLAI
Details

The WP Import – Ultimate CSV XML Importer for WordPress plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 7.35. This is due to inadequate validation of the resolved URL after following Bitly shortlink redirects in the upload_function() method. While the initial URL is validated using wp_http_validate_url(), when a Bitly shortlink is detected, the unshorten_bitly_url() function follows redirects to the final destination URL without re-validating it. This makes it possible for authenticated attackers with Contributor-level access or higher to make the server perform HTTP requests to arbitrary internal endpoints, including localhost, private IP ranges, and cloud metadata services (e.g., 169.254.169.254), potentially exposing sensitive internal data.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-14627"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-01T17:15:42Z",
    "severity": "MODERATE"
  },
  "details": "The WP Import \u2013 Ultimate CSV XML Importer for WordPress plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 7.35. This is due to inadequate validation of the resolved URL after following Bitly shortlink redirects in the `upload_function()` method. While the initial URL is validated using `wp_http_validate_url()`, when a Bitly shortlink is detected, the `unshorten_bitly_url()` function follows redirects to the final destination URL without re-validating it. This makes it possible for authenticated attackers with Contributor-level access or higher to make the server perform HTTP requests to arbitrary internal endpoints, including localhost, private IP ranges, and cloud metadata services (e.g., 169.254.169.254), potentially exposing sensitive internal data.",
  "id": "GHSA-xvpj-p677-68r9",
  "modified": "2026-01-01T18:30:27Z",
  "published": "2026-01-01T18:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14627"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wp-ultimate-csv-importer/tags/7.34/uploadModules/UrlUpload.php#L290"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wp-ultimate-csv-importer/tags/7.34/uploadModules/UrlUpload.php#L73"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3421699/wp-ultimate-csv-importer/trunk/uploadModules/UrlUpload.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/87040f2b-4de0-4a8d-ae30-b340638a6df2?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XVXP-PJ7J-GMJJ

Vulnerability from github – Published: 2026-05-12 18:30 – Updated: 2026-05-12 18:30
VLAI
Details

Server-Side Request Forgery vulnerability allows Privilege Escalation via API Checker extension. This issue affects Pandora FMS: from 777 through 800

Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:L/SI:L/SA:N/S:N/AU:Y/R:U/V:C/RE:M/U:Amber
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-30810"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-12T16:16:13Z",
    "severity": "HIGH"
  },
  "details": "Server-Side Request Forgery vulnerability allows Privilege Escalation via API Checker extension. This issue affects Pandora FMS: from 777 through 800",
  "id": "GHSA-xvxp-pj7j-gmjj",
  "modified": "2026-05-12T18:30:37Z",
  "published": "2026-05-12T18:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30810"
    },
    {
      "type": "WEB",
      "url": "https://pandorafms.com/en/security/common-vulnerabilities-and-exposures"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:L/SI:L/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:N/AU:Y/R:U/V:C/RE:M/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-XW3G-F28M-3Q7J

Vulnerability from github – Published: 2025-04-17 21:31 – Updated: 2025-04-21 18:32
VLAI
Details

An issue in personal-management-system Personal Management System 1.4.65 allows a remote attacker to obtain sensitive information via the Travel Ideas" function.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-29455"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-17T21:15:50Z",
    "severity": "MODERATE"
  },
  "details": "An issue in personal-management-system Personal Management System 1.4.65 allows a remote attacker to obtain sensitive information via the Travel Ideas\" function.",
  "id": "GHSA-xw3g-f28m-3q7j",
  "modified": "2025-04-21T18:32:08Z",
  "published": "2025-04-17T21:31:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29455"
    },
    {
      "type": "WEB",
      "url": "https://www.yuque.com/morysummer/vx41bz/hfonnxwggi2kfgmw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XW4P-CRPJ-VJX2

Vulnerability from github – Published: 2021-08-25 14:46 – Updated: 2022-02-08 20:43
VLAI
Summary
A Server-Side Forgery Request can be activated unmarshalling with XStream to access data streams from an arbitrary URL referencing a resource in an intranet or the local host
Details

Impact

The vulnerability may allow a remote attacker to request data from internal resources that are not publicly available only by manipulating the processed input stream with a Java runtime version 14 to 8. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types.

Patches

If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.18.

Workarounds

See workarounds for the different versions covering all CVEs.

References

See full information about the nature of the vulnerability and the steps to reproduce it in XStream's documentation for CVE-2021-39152.

Credits

m0d9 of the Security Team of Alibaba Cloud found and reported the issue to XStream and provided the required information to reproduce it.

For more information

If you have any questions or comments about this advisory: * Open an issue in XStream * Contact us at XStream Google Group

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.thoughtworks.xstream:xstream"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-39152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-502",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-23T18:22:29Z",
    "nvd_published_at": "2021-08-23T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nThe vulnerability may allow a remote attacker to request data from internal resources that are not publicly available only by manipulating the processed input stream with a Java runtime version 14 to 8. No user is affected, who followed the recommendation to setup XStream\u0027s security framework with a whitelist limited to the minimal required types.\n\n### Patches\nIf you rely on XStream\u0027s default blacklist of the [Security Framework](https://x-stream.github.io/security.html#framework), you will have to use at least version 1.4.18.\n\n### Workarounds\nSee [workarounds](https://x-stream.github.io/security.html#workaround) for the different versions covering all CVEs.\n\n### References\nSee full information about the nature of the vulnerability and the steps to reproduce it in XStream\u0027s documentation for [CVE-2021-39152](https://x-stream.github.io/CVE-2021-39152.html).\n\n### Credits\nm0d9 of the Security Team of Alibaba Cloud found and reported the issue to XStream and provided the required information to reproduce it.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [XStream](https://github.com/x-stream/xstream/issues)\n* Contact us at [XStream Google Group](https://groups.google.com/group/xstream-user)\n",
  "id": "GHSA-xw4p-crpj-vjx2",
  "modified": "2022-02-08T20:43:14Z",
  "published": "2021-08-25T14:46:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/x-stream/xstream/security/advisories/GHSA-xw4p-crpj-vjx2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39152"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/x-stream/xstream"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/09/msg00017.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/22KVR6B5IZP3BGQ3HPWIO2FWWCKT3DHP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PVPHZA7VW2RRSDCOIPP2W6O5ND254TU7"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QGXIU3YDPG6OGTDHMBLAFN7BPBERXREB"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210923-0003"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-5004"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2022.html"
    },
    {
      "type": "WEB",
      "url": "https://x-stream.github.io/CVE-2021-39152.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "A Server-Side Forgery Request can be activated unmarshalling with XStream to access data streams from an arbitrary URL referencing a resource in an intranet or the local host"
}

GHSA-XW57-23P8-9WC5

Vulnerability from github – Published: 2026-07-02 19:07 – Updated: 2026-07-02 19:07
VLAI
Summary
@asymmetric-effort/specifyjs: Localhost bypass incomplete (IPv6, 0.0.0.0, 127.x range)
Details

Finding

Location: core/src/shared/secure-fetch.ts:52-54

The localhost exception allowed localhost and 127.0.0.1 but did not cover 0.0.0.0, [::1] (IPv6 localhost), or the full 127.0.0.0/8 loopback range.

Status

Fixed in v0.2.136 — Localhost detection now covers localhost, 127.0.0.1, [::1], 0.0.0.0, and the full 127.x.x.x range.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@asymmetric-effort/specifyjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.136"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T19:07:22Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Finding\n\n**Location**: `core/src/shared/secure-fetch.ts:52-54`\n\nThe localhost exception allowed `localhost` and `127.0.0.1` but did not cover `0.0.0.0`, `[::1]` (IPv6 localhost), or the full `127.0.0.0/8` loopback range.\n\n## Status\n\n**Fixed in v0.2.136** \u2014 Localhost detection now covers `localhost`, `127.0.0.1`, `[::1]`, `0.0.0.0`, and the full `127.x.x.x` range.",
  "id": "GHSA-xw57-23p8-9wc5",
  "modified": "2026-07-02T19:07:22Z",
  "published": "2026-07-02T19:07:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/asymmetric-effort/specifyjs/security/advisories/GHSA-xw57-23p8-9wc5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/asymmetric-effort/specifyjs/commit/25d1fb491d99479efdf501f5f75e0bb80c908f0a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/asymmetric-effort/specifyjs/commit/293124c51bf797c0f5cdae32981110545850a893"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/asymmetric-effort/specifyjs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@asymmetric-effort/specifyjs: Localhost bypass incomplete (IPv6, 0.0.0.0, 127.x range)"
}

GHSA-XW9Q-2MV6-9FR8

Vulnerability from github – Published: 2026-07-14 18:15 – Updated: 2026-07-14 18:15
VLAI
Summary
Fedify has an incomplete SSRF mitigation after GHSA-p9cg-vqcc-grcx: validatePublicUrl allows special-use IPv4 ranges
Details

Summary

Fedify previously addressed SSRF/internal network access in GHSA-p9cg-vqcc-grcx by adding public URL validation before runtime document and media fetching. However, the current IPv4 validation logic appears incomplete.

The validatePublicUrl() protection relies on isValidPublicIPv4Address() to reject non-public IPv4 destinations. The function blocks common private and local ranges such as 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, and 192.168.0.0/16, but it still treats several special-use, reserved, multicast, benchmarking, and carrier-grade NAT IPv4 ranges as valid public destinations.

Because this validation is used as an SSRF defense before outbound fetches, this appears to be an incomplete mitigation or bypass class for the previous SSRF issue.

I tested this against the current repository code at unreleased version 2.3.0. I used >=0.11.2, <=2.2.3 as the suspected affected range because 0.11.2 is listed as a patched version for GHSA-p9cg-vqcc-grcx, and this report concerns the post-fix validation logic. Maintainers may adjust the exact affected range.

Why this is not a duplicate of GHSA-p9cg-vqcc-grcx

GHSA-p9cg-vqcc-grcx covered the original behavior where Fedify fetched ActivityPub object, activity, document, and media URLs without first ensuring that the resolved destination was public.

This report is about the post-fix validation logic. The current mitigation now performs public URL/IP validation, but the IPv4 classification is incomplete and still treats several special-use ranges as public. Therefore, this is a potential incomplete fix/bypass of the previous SSRF mitigation rather than a re-report of the original issue.

The affected behavior appears to exist in the patched/current code path, not only in versions listed as vulnerable in the original advisory.

Affected Code

Affected file:

packages/vocab-runtime/src/url.ts

Current IPv4 validation logic:

export function isValidPublicIPv4Address(address: string): boolean {
  const parts = address.split(".");
  const first = parseInt(parts[0]);
  if (first === 0 || first === 10 || first === 127) return false;
  const second = parseInt(parts[1]);
  if (first === 169 && second === 254) return false;
  if (first === 172 && second >= 16 && second <= 31) return false;
  if (first === 192 && second === 168) return false;
  return true;
}

The important point is that the bypass exists in the mitigation logic itself: the function responsible for deciding whether a destination is public returns true for address ranges that are not globally routable public internet destinations.

Proof of Concept

I reproduced the IPv4 validation behavior using the same logic:

function isValidPublicIPv4Address(address) {
  const parts = address.split(".");
  const first = parseInt(parts[0], 10);
  if (first === 0 || first === 10 || first === 127) return false;

  const second = parseInt(parts[1], 10);
  if (first === 169 && second === 254) return false;
  if (first === 172 && second >= 16 && second <= 31) return false;
  if (first === 192 && second === 168) return false;

  return true;
}

const tests = [
  "8.8.8.8",
  "127.0.0.1",
  "10.0.0.1",
  "192.168.1.1",
  "169.254.169.254",
  "100.64.0.1",
  "198.18.0.1",
  "224.0.0.1",
  "240.0.0.1",
  "192.0.0.1",
  "192.0.2.1",
  "198.51.100.1",
  "203.0.113.1"
];

for (const ip of tests) {
  console.log(ip + " => " + isValidPublicIPv4Address(ip));
}

Observed output:

8.8.8.8 => true
127.0.0.1 => false
10.0.0.1 => false
192.168.1.1 => false
169.254.169.254 => false
100.64.0.1 => true
198.18.0.1 => true
224.0.0.1 => true
240.0.0.1 => true
192.0.0.1 => true
192.0.2.1 => true
198.51.100.1 => true
203.0.113.1 => true

The validator correctly blocks some common private and local ranges, but incorrectly allows multiple special-use ranges.

Examples of incorrectly allowed ranges

Important examples include:

100.64.0.0/10 Carrier-grade NAT
198.18.0.0/15 Benchmarking / internal testing networks
224.0.0.0/4 Multicast
240.0.0.0/4 Reserved
192.0.0.0/24 IETF protocol assignments

Additional correctness examples:

192.0.2.0/24 Documentation range
198.51.100.0/24 Documentation range
203.0.113.0/24 Documentation range

Security Impact

Any Fedify feature that accepts or processes remote ActivityPub object, activity, document, or media URLs and relies on validatePublicUrl() as an SSRF protection boundary may incorrectly allow outbound requests to special-use IPv4 destinations that should not be treated as public internet resources.

This may allow an attacker-controlled ActivityPub object or media URL to cause a Fedify server to initiate requests to non-public or special-use network ranges, depending on the deployment environment and network routing.

This is best understood as an incomplete fix/bypass class for the previous SSRF/internal-network-access advisory GHSA-p9cg-vqcc-grcx.

Suggested Fix

Avoid using a small manual denylist for public IP validation. Instead, validate that the resolved address is globally routable/public.

At minimum, IPv4 validation should reject all relevant special-use ranges, including:

0.0.0.0/8
10.0.0.0/8
100.64.0.0/10
127.0.0.0/8
169.254.0.0/16
172.16.0.0/12
192.0.0.0/24
192.0.2.0/24
192.168.0.0/16
198.18.0.0/15
198.51.100.0/24
203.0.113.0/24
224.0.0.0/4
240.0.0.0/4

A safer long-term fix would be to use a maintained IP address classification library that explicitly supports security-sensitive public/global IP validation.

Patch Idea

export function isValidPublicIPv4Address(address: string): boolean {
  const parts = address.split(".").map((part) => parseInt(part, 10));

  if (
    parts.length !== 4 ||
    parts.some((part) => Number.isNaN(part) || part < 0 || part > 255)
  ) {
    return false;
  }

  const [a, b] = parts;

  if (a === 0) return false;
  if (a === 10) return false;
  if (a === 100 && b >= 64 && b <= 127) return false;
  if (a === 127) return false;
  if (a === 169 && b === 254) return false;
  if (a === 172 && b >= 16 && b <= 31) return false;
  if (a === 192 && b === 0) return false;
  if (a === 192 && b === 168) return false;
  if (a === 198 && (b === 18 || b === 19)) return false;
  if (a === 198 && b === 51) return false;
  if (a === 203 && b === 0) return false;
  if (a >= 224) return false;

  return true;
}

Advisory Classification Note

I understand this may be classified either as a new advisory or as an update/incomplete fix for GHSA-p9cg-vqcc-grcx. Since the issue appears to affect the validation logic added after the original SSRF fix, and because the affected code is part of the current security boundary for outbound URL fetching, I wanted to report it privately for maintainer review.

Disclosure Note

This report does not attempt to access any real internal network service. The proof focuses on the validation decision itself: multiple non-public or special-use IPv4 ranges are accepted as public by the current SSRF protection logic.

Researcher

Reported by Chaitanya Garware.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.11.2"
            },
            {
              "fixed": "1.9.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.10.0"
            },
            {
              "fixed": "1.10.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/vocab-runtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/vocab-runtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/vocab-runtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50131"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918",
      "CWE-1286",
      "CWE-1389"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T18:15:25Z",
    "nvd_published_at": "2026-06-10T22:17:01Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nFedify previously addressed SSRF/internal network access in GHSA-p9cg-vqcc-grcx by adding public URL validation before runtime document and media fetching. However, the current IPv4 validation logic appears incomplete.\n\nThe `validatePublicUrl()` protection relies on `isValidPublicIPv4Address()` to reject non-public IPv4 destinations. The function blocks common private and local ranges such as `10.0.0.0/8`, `127.0.0.0/8`, `169.254.0.0/16`, `172.16.0.0/12`, and `192.168.0.0/16`, but it still treats several special-use, reserved, multicast, benchmarking, and carrier-grade NAT IPv4 ranges as valid public destinations.\n\nBecause this validation is used as an SSRF defense before outbound fetches, this appears to be an incomplete mitigation or bypass class for the previous SSRF issue.\n\nI tested this against the current repository code at unreleased version 2.3.0. I used `\u003e=0.11.2, \u003c=2.2.3` as the suspected affected range because 0.11.2 is listed as a patched version for GHSA-p9cg-vqcc-grcx, and this report concerns the post-fix validation logic. Maintainers may adjust the exact affected range.\n\n### Why this is not a duplicate of GHSA-p9cg-vqcc-grcx\n\nGHSA-p9cg-vqcc-grcx covered the original behavior where Fedify fetched ActivityPub object, activity, document, and media URLs without first ensuring that the resolved destination was public.\n\nThis report is about the post-fix validation logic. The current mitigation now performs public URL/IP validation, but the IPv4 classification is incomplete and still treats several special-use ranges as public. Therefore, this is a potential incomplete fix/bypass of the previous SSRF mitigation rather than a re-report of the original issue.\n\nThe affected behavior appears to exist in the patched/current code path, not only in versions listed as vulnerable in the original advisory.\n\n### Affected Code\n\nAffected file:\n\n`packages/vocab-runtime/src/url.ts`\n\nCurrent IPv4 validation logic:\n\n```ts\nexport function isValidPublicIPv4Address(address: string): boolean {\n  const parts = address.split(\".\");\n  const first = parseInt(parts[0]);\n  if (first === 0 || first === 10 || first === 127) return false;\n  const second = parseInt(parts[1]);\n  if (first === 169 \u0026\u0026 second === 254) return false;\n  if (first === 172 \u0026\u0026 second \u003e= 16 \u0026\u0026 second \u003c= 31) return false;\n  if (first === 192 \u0026\u0026 second === 168) return false;\n  return true;\n}\n```\n\nThe important point is that the bypass exists in the mitigation logic itself: the function responsible for deciding whether a destination is public returns true for address ranges that are not globally routable public internet destinations.\n\n### Proof of Concept\n\nI reproduced the IPv4 validation behavior using the same logic:\n\n```ts\nfunction isValidPublicIPv4Address(address) {\n  const parts = address.split(\".\");\n  const first = parseInt(parts[0], 10);\n  if (first === 0 || first === 10 || first === 127) return false;\n\n  const second = parseInt(parts[1], 10);\n  if (first === 169 \u0026\u0026 second === 254) return false;\n  if (first === 172 \u0026\u0026 second \u003e= 16 \u0026\u0026 second \u003c= 31) return false;\n  if (first === 192 \u0026\u0026 second === 168) return false;\n\n  return true;\n}\n\nconst tests = [\n  \"8.8.8.8\",\n  \"127.0.0.1\",\n  \"10.0.0.1\",\n  \"192.168.1.1\",\n  \"169.254.169.254\",\n  \"100.64.0.1\",\n  \"198.18.0.1\",\n  \"224.0.0.1\",\n  \"240.0.0.1\",\n  \"192.0.0.1\",\n  \"192.0.2.1\",\n  \"198.51.100.1\",\n  \"203.0.113.1\"\n];\n\nfor (const ip of tests) {\n  console.log(ip + \" =\u003e \" + isValidPublicIPv4Address(ip));\n}\n```\n\nObserved output:\n\n```\n8.8.8.8 =\u003e true\n127.0.0.1 =\u003e false\n10.0.0.1 =\u003e false\n192.168.1.1 =\u003e false\n169.254.169.254 =\u003e false\n100.64.0.1 =\u003e true\n198.18.0.1 =\u003e true\n224.0.0.1 =\u003e true\n240.0.0.1 =\u003e true\n192.0.0.1 =\u003e true\n192.0.2.1 =\u003e true\n198.51.100.1 =\u003e true\n203.0.113.1 =\u003e true\n```\n\nThe validator correctly blocks some common private and local ranges, but incorrectly allows multiple special-use ranges.\n\n### Examples of incorrectly allowed ranges\n\nImportant examples include:\n\n```\n100.64.0.0/10 Carrier-grade NAT\n198.18.0.0/15 Benchmarking / internal testing networks\n224.0.0.0/4 Multicast\n240.0.0.0/4 Reserved\n192.0.0.0/24 IETF protocol assignments\n```\n\nAdditional correctness examples:\n\n```\n192.0.2.0/24 Documentation range\n198.51.100.0/24 Documentation range\n203.0.113.0/24 Documentation range\n```\n\n## Security Impact\n\nAny Fedify feature that accepts or processes remote ActivityPub object, activity, document, or media URLs and relies on validatePublicUrl() as an SSRF protection boundary may incorrectly allow outbound requests to special-use IPv4 destinations that should not be treated as public internet resources.\n\nThis may allow an attacker-controlled ActivityPub object or media URL to cause a Fedify server to initiate requests to non-public or special-use network ranges, depending on the deployment environment and network routing.\n\nThis is best understood as an incomplete fix/bypass class for the previous SSRF/internal-network-access advisory GHSA-p9cg-vqcc-grcx.\n\n## Suggested Fix\n\nAvoid using a small manual denylist for public IP validation. Instead, validate that the resolved address is globally routable/public.\n\nAt minimum, IPv4 validation should reject all relevant special-use ranges, including:\n\n```\n0.0.0.0/8\n10.0.0.0/8\n100.64.0.0/10\n127.0.0.0/8\n169.254.0.0/16\n172.16.0.0/12\n192.0.0.0/24\n192.0.2.0/24\n192.168.0.0/16\n198.18.0.0/15\n198.51.100.0/24\n203.0.113.0/24\n224.0.0.0/4\n240.0.0.0/4\n```\n\nA safer long-term fix would be to use a maintained IP address classification library that explicitly supports security-sensitive public/global IP validation.\n\nPatch Idea\n\n```ts\nexport function isValidPublicIPv4Address(address: string): boolean {\n  const parts = address.split(\".\").map((part) =\u003e parseInt(part, 10));\n\n  if (\n    parts.length !== 4 ||\n    parts.some((part) =\u003e Number.isNaN(part) || part \u003c 0 || part \u003e 255)\n  ) {\n    return false;\n  }\n\n  const [a, b] = parts;\n\n  if (a === 0) return false;\n  if (a === 10) return false;\n  if (a === 100 \u0026\u0026 b \u003e= 64 \u0026\u0026 b \u003c= 127) return false;\n  if (a === 127) return false;\n  if (a === 169 \u0026\u0026 b === 254) return false;\n  if (a === 172 \u0026\u0026 b \u003e= 16 \u0026\u0026 b \u003c= 31) return false;\n  if (a === 192 \u0026\u0026 b === 0) return false;\n  if (a === 192 \u0026\u0026 b === 168) return false;\n  if (a === 198 \u0026\u0026 (b === 18 || b === 19)) return false;\n  if (a === 198 \u0026\u0026 b === 51) return false;\n  if (a === 203 \u0026\u0026 b === 0) return false;\n  if (a \u003e= 224) return false;\n\n  return true;\n}\n```\n\n\n## Advisory Classification Note\n\nI understand this may be classified either as a new advisory or as an update/incomplete fix for GHSA-p9cg-vqcc-grcx. Since the issue appears to affect the validation logic added after the original SSRF fix, and because the affected code is part of the current security boundary for outbound URL fetching, I wanted to report it privately for maintainer review.\n\n## Disclosure Note\n\nThis report does not attempt to access any real internal network service. The proof focuses on the validation decision itself: multiple non-public or special-use IPv4 ranges are accepted as public by the current SSRF protection logic.\n\n\n\n## Researcher\n\nReported by Chaitanya Garware.",
  "id": "GHSA-xw9q-2mv6-9fr8",
  "modified": "2026-07-14T18:15:25Z",
  "published": "2026-07-14T18:15:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fedify-dev/fedify/security/advisories/GHSA-xw9q-2mv6-9fr8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50131"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fedify-dev/fedify"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fedify has an incomplete SSRF mitigation after GHSA-p9cg-vqcc-grcx: validatePublicUrl allows special-use IPv4 ranges"
}

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