CWE-1286
AllowedImproper Validation of Syntactic Correctness of Input
Abstraction: Base · Status: Incomplete
The product receives input that is expected to be well-formed - i.e., to comply with a certain syntax - but it does not validate or incorrectly validates that the input complies with the syntax.
150 vulnerabilities reference this CWE, most recent first.
GHSA-VP7P-3HC7-H72X
Vulnerability from github – Published: 2025-04-30 12:31 – Updated: 2025-04-30 12:31A vulnerability in the “Hosts” functionality of the web application of ctrlX OS allows a remote authenticated (low-privileged) attacker to manipulate the “hosts” file in an unintended manner via a crafted HTTP request.
{
"affected": [],
"aliases": [
"CVE-2025-24345"
],
"database_specific": {
"cwe_ids": [
"CWE-1286"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-30T12:15:18Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the \u201cHosts\u201d functionality of the web application of ctrlX OS allows a remote authenticated (low-privileged) attacker to manipulate the \u201chosts\u201d file in an unintended manner via a crafted HTTP request.",
"id": "GHSA-vp7p-3hc7-h72x",
"modified": "2025-04-30T12:31:24Z",
"published": "2025-04-30T12:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24345"
},
{
"type": "WEB",
"url": "https://psirt.bosch.com/security-advisories/BOSCH-SA-640452.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-WCRJ-9V56-HJQW
Vulnerability from github – Published: 2025-08-12 18:31 – Updated: 2025-08-12 18:31Improper validation of syntactic correctness of input in Microsoft Exchange Server allows an unauthorized attacker to perform spoofing over a network.
{
"affected": [],
"aliases": [
"CVE-2025-25007"
],
"database_specific": {
"cwe_ids": [
"CWE-1286"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-12T18:15:27Z",
"severity": "MODERATE"
},
"details": "Improper validation of syntactic correctness of input in Microsoft Exchange Server allows an unauthorized attacker to perform spoofing over a network.",
"id": "GHSA-wcrj-9v56-hjqw",
"modified": "2025-08-12T18:31:30Z",
"published": "2025-08-12T18:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25007"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-25007"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WX2X-F6C2-GQXF
Vulnerability from github – Published: 2025-04-24 03:31 – Updated: 2025-04-24 03:31Westermo WeOS 5 through 5.23.0 allows a reboot via a malformed ESP packet.
{
"affected": [],
"aliases": [
"CVE-2025-46419"
],
"database_specific": {
"cwe_ids": [
"CWE-1286"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-24T01:15:51Z",
"severity": "MODERATE"
},
"details": "Westermo WeOS 5 through 5.23.0 allows a reboot via a malformed ESP packet.",
"id": "GHSA-wx2x-f6c2-gqxf",
"modified": "2025-04-24T03:31:31Z",
"published": "2025-04-24T03:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46419"
},
{
"type": "WEB",
"url": "https://www.westermo.com/-/media/Files/Cyber-security/westermo_sa_25-02_malformed_esp_packet_could_cause_denial_vulnerability_in_weos.pdf?rev=9af5c93194f343a0b4fad2d24d032df2\u0026hash=87F4AD7F74C2BE69CA1B4C24F29B82EA"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-X4Q9-MG3C-99RC
Vulnerability from github – Published: 2024-04-02 12:30 – Updated: 2024-04-02 12:30** DISPUTED ** An Improper Input Validation vulnerability affecting the FTP service running on the DJI Mavic Mini 3 Pro could allow an attacker to craft a malicious packet containing a malformed path provided to the FTP SIZE command that leads to a denial-of-service attack of the FTP service itself.
{
"affected": [],
"aliases": [
"CVE-2023-6950"
],
"database_specific": {
"cwe_ids": [
"CWE-1286",
"CWE-20"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-02T11:15:51Z",
"severity": "LOW"
},
"details": "** DISPUTED ** An Improper Input Validation vulnerability affecting the FTP service running on the DJI Mavic Mini 3 Pro could allow an attacker to craft a malicious packet containing a malformed path provided to the FTP SIZE command that leads to a denial-of-service attack of the FTP service itself.",
"id": "GHSA-x4q9-mg3c-99rc",
"modified": "2024-04-02T12:30:32Z",
"published": "2024-04-02T12:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6950"
},
{
"type": "WEB",
"url": "https://www.nozominetworks.com/labs/vulnerability-advisories-cve-2023-6950"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-X6CG-7P5M-7WCC
Vulnerability from github – Published: 2026-05-18 12:31 – Updated: 2026-05-18 12:31Denial-of-service condition in M-Files Server versions before 26.5.16015.0, before 26.2 LTS, and before 25.8 LTS SR3 allows an authenticated user to cause the MFserver process to crash
{
"affected": [],
"aliases": [
"CVE-2026-0983"
],
"database_specific": {
"cwe_ids": [
"CWE-1286"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-18T12:16:16Z",
"severity": "HIGH"
},
"details": "Denial-of-service condition in M-Files Server versions before 26.5.16015.0, before 26.2 LTS, and before 25.8 LTS SR3 allows an authenticated user to cause the MFserver process to crash",
"id": "GHSA-x6cg-7p5m-7wcc",
"modified": "2026-05-18T12:31:47Z",
"published": "2026-05-18T12:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0983"
},
{
"type": "WEB",
"url": "https://empower.m-files.com/security-advisories/CVE-2026-0983"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-XFCP-H9VC-F632
Vulnerability from github – Published: 2023-08-09 12:30 – Updated: 2024-09-20 12:31A partial DoS vulnerability has been detected in the Reports section, exploitable by a malicious authenticated user forcing a report to be saved with its name set as null.
The reports section will be partially unavailable for all later attempts to use it, with the report list seemingly stuck on loading.
{
"affected": [],
"aliases": [
"CVE-2023-24015"
],
"database_specific": {
"cwe_ids": [
"CWE-1286",
"CWE-20"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-09T10:15:09Z",
"severity": "MODERATE"
},
"details": "A partial DoS vulnerability has been detected in the Reports section, exploitable by a malicious authenticated user forcing a report to be saved with its name set as null.\n\nThe reports section will be partially unavailable for all later attempts to use it, with the report list seemingly stuck on loading.\n\n",
"id": "GHSA-xfcp-h9vc-f632",
"modified": "2024-09-20T12:31:45Z",
"published": "2023-08-09T12:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24015"
},
{
"type": "WEB",
"url": "https://security.nozominetworks.com/NN-2023:6-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-XHPM-F58R-37PX
Vulnerability from github – Published: 2026-06-05 00:31 – Updated: 2026-06-05 00:31On affected platforms running Arista EOS with IPsec configured, a specially crafted packet can cause the dataplane to stop processing all IPsec traffic. The control plane may detect this condition, and attempt to reset the IPsec processing pipeline. After reset traffic may not resume being processed. There is no impact to non-IPsec traffic or to IPsec traffic not originating or terminating on the system. This issue was reported by an Arista customer.
{
"affected": [],
"aliases": [
"CVE-2025-8873"
],
"database_specific": {
"cwe_ids": [
"CWE-1286"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-04T23:16:48Z",
"severity": "HIGH"
},
"details": "On affected platforms running Arista EOS with IPsec configured, a specially crafted packet can cause the dataplane to stop processing all IPsec traffic. The control plane may detect this condition, and attempt to reset the IPsec processing pipeline. After reset traffic may not resume being processed. There is no impact to non-IPsec traffic or to IPsec traffic not originating or terminating on the system. This issue was reported by an Arista customer.",
"id": "GHSA-xhpm-f58r-37px",
"modified": "2026-06-05T00:31:36Z",
"published": "2026-06-05T00:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8873"
},
{
"type": "WEB",
"url": "https://www.arista.com/en/support/advisories-notices/security-advisory/22869-security-advisory-0127"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-XP8W-JXFC-XRQQ
Vulnerability from github – Published: 2024-06-10 18:31 – Updated: 2024-07-03 18:44An issue in FinalWire AIRDA Extreme, AIDA64 Engineer, AIDA64 Business, AIDA64 Network Audit v.7.00.6700 and before allows a local attacker to escalate privileges via the DeviceIoControl call associated with MmMapIoSpace, IoAllocateMdl, MmBuildMdlForNonPagedPool, or MmMapLockedPages components.
{
"affected": [],
"aliases": [
"CVE-2024-26507"
],
"database_specific": {
"cwe_ids": [
"CWE-1286"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-10T16:15:12Z",
"severity": "HIGH"
},
"details": "An issue in FinalWire AIRDA Extreme, AIDA64 Engineer, AIDA64 Business, AIDA64 Network Audit v.7.00.6700 and before allows a local attacker to escalate privileges via the DeviceIoControl call associated with MmMapIoSpace, IoAllocateMdl, MmBuildMdlForNonPagedPool, or MmMapLockedPages components.",
"id": "GHSA-xp8w-jxfc-xrqq",
"modified": "2024-07-03T18:44:22Z",
"published": "2024-06-10T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26507"
},
{
"type": "WEB",
"url": "https://belong2yourself.github.io/vulnerabilities/docs/AIDA/Elevation-of-Privileges/readme"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XPWH-C6WC-QG9F
Vulnerability from github – Published: 2022-05-24 19:16 – Updated: 2022-07-13 00:01A user controlled parameter related to SMTP test functionality is not correctly validated making it possible to bypass blocked network recipients.
{
"affected": [],
"aliases": [
"CVE-2021-31987"
],
"database_specific": {
"cwe_ids": [
"CWE-1286",
"CWE-20"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-05T22:15:00Z",
"severity": "HIGH"
},
"details": "A user controlled parameter related to SMTP test functionality is not correctly validated making it possible to bypass blocked network recipients.",
"id": "GHSA-xpwh-c6wc-qg9f",
"modified": "2022-07-13T00:01:25Z",
"published": "2022-05-24T19:16:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31987"
},
{
"type": "WEB",
"url": "https://www.axis.com/files/tech_notes/CVE-2021-31987.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XW9Q-2MV6-9FR8
Vulnerability from github – Published: 2026-07-14 18:15 – Updated: 2026-07-14 18:15Summary
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.
{
"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"
}
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
CAPEC-66: SQL Injection
This attack exploits target software that constructs SQL statements based on user input. An attacker crafts input strings so that when the target software constructs SQL statements based on the input, the resulting SQL statement performs actions other than those the application intended. SQL Injection results from failure of the application to appropriately validate input.
CAPEC-676: NoSQL Injection
An adversary targets software that constructs NoSQL statements based on user input or with parameters vulnerable to operator replacement in order to achieve a variety of technical impacts such as escalating privileges, bypassing authentication, and/or executing code.