CWE-918
AllowedServer-Side Request Forgery (SSRF)
Abstraction: Base · Status: Incomplete
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
6271 vulnerabilities reference this CWE, most recent first.
GHSA-MVVV-V22X-XQWP
Vulnerability from github – Published: 2026-04-15 19:43 – Updated: 2026-05-14 20:39Summary
NocoBase's workflow HTTP request plugin and custom request action plugin make server-side HTTP requests to user-provided URLs without any SSRF protection. An authenticated user can access internal network services, cloud metadata endpoints, and localhost.
Vulnerable Code
1. Workflow HTTP Request Plugin
packages/plugins/@nocobase/plugin-workflow-request/src/server/RequestInstruction.ts lines 117-128:
return axios.request({
url: trim(url), // User-controlled, no validation
method,
headers,
params,
timeout,
...(method.toLowerCase() !== 'get' && data != null
? { data: transformer ? await transformer(data) : data }
: {}),
});
The url at line 98 comes directly from user workflow configuration with only whitespace trimming.
2. Custom Request Action Plugin
packages/plugins/@nocobase/plugin-action-custom-request/src/server/actions/send.ts lines 172-198:
const axiosRequestConfig = {
baseURL: ctx.origin,
...options,
url: getParsedValue(url, variables), // User-controlled via template
headers: { ... },
params: getParsedValue(arrayToObject(params), variables),
data: getParsedValue(toJSON(data), variables),
};
const res = await axios(axiosRequestConfig); // No IP validation
Missing Protections
- No
request-filtering-agentor SSRF library (confirmed via grep across entire codebase) - No private IP range filtering
- No cloud metadata endpoint blocking
- No URL scheme validation
- No DNS rebinding protection
Attack Scenario
- Authenticated user creates a workflow with HTTP Request node
- Sets URL to
http://169.254.169.254/latest/meta-data/iam/security-credentials/ - Triggers the workflow
- Server fetches AWS metadata and returns IAM credentials in workflow execution logs
Alternatively via Custom Request action:
1. Create custom request with URL http://127.0.0.1:5432 or http://10.0.0.1:8080/admin
2. Execute the action
3. Server makes request to internal service
Impact
- Cloud metadata theft: AWS/GCP/Azure credentials via metadata endpoints
- Internal network access: Scan and interact with services on private IP ranges
- Database access: Connect to localhost databases (PostgreSQL, Redis, etc.)
- Authentication required: Yes (authenticated user), but any workspace member can create workflows
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@nocobase/plugin-workflow-request"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.37"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40346"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-15T19:43:50Z",
"nvd_published_at": "2026-04-18T00:16:38Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nNocoBase\u0027s workflow HTTP request plugin and custom request action plugin make server-side HTTP requests to user-provided URLs without any SSRF protection. An authenticated user can access internal network services, cloud metadata endpoints, and localhost.\n\n## Vulnerable Code\n\n### 1. Workflow HTTP Request Plugin\n\n**`packages/plugins/@nocobase/plugin-workflow-request/src/server/RequestInstruction.ts` lines 117-128:**\n```typescript\nreturn axios.request({\n url: trim(url), // User-controlled, no validation\n method,\n headers,\n params,\n timeout,\n ...(method.toLowerCase() !== \u0027get\u0027 \u0026\u0026 data != null\n ? { data: transformer ? await transformer(data) : data }\n : {}),\n});\n```\n\nThe `url` at line 98 comes directly from user workflow configuration with only whitespace trimming.\n\n### 2. Custom Request Action Plugin\n\n**`packages/plugins/@nocobase/plugin-action-custom-request/src/server/actions/send.ts` lines 172-198:**\n```typescript\nconst axiosRequestConfig = {\n baseURL: ctx.origin,\n ...options,\n url: getParsedValue(url, variables), // User-controlled via template\n headers: { ... },\n params: getParsedValue(arrayToObject(params), variables),\n data: getParsedValue(toJSON(data), variables),\n};\nconst res = await axios(axiosRequestConfig); // No IP validation\n```\n\n## Missing Protections\n\n- No `request-filtering-agent` or SSRF library (confirmed via grep across entire codebase)\n- No private IP range filtering\n- No cloud metadata endpoint blocking\n- No URL scheme validation\n- No DNS rebinding protection\n\n## Attack Scenario\n\n1. Authenticated user creates a workflow with HTTP Request node\n2. Sets URL to `http://169.254.169.254/latest/meta-data/iam/security-credentials/`\n3. Triggers the workflow\n4. Server fetches AWS metadata and returns IAM credentials in workflow execution logs\n\nAlternatively via Custom Request action:\n1. Create custom request with URL `http://127.0.0.1:5432` or `http://10.0.0.1:8080/admin`\n2. Execute the action\n3. Server makes request to internal service\n\n## Impact\n\n- **Cloud metadata theft**: AWS/GCP/Azure credentials via metadata endpoints\n- **Internal network access**: Scan and interact with services on private IP ranges\n- **Database access**: Connect to localhost databases (PostgreSQL, Redis, etc.)\n- **Authentication required**: Yes (authenticated user), but any workspace member can create workflows",
"id": "GHSA-mvvv-v22x-xqwp",
"modified": "2026-05-14T20:39:05Z",
"published": "2026-04-15T19:43:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nocobase/nocobase/security/advisories/GHSA-mvvv-v22x-xqwp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40346"
},
{
"type": "WEB",
"url": "https://github.com/nocobase/nocobase/pull/9079"
},
{
"type": "WEB",
"url": "https://github.com/nocobase/nocobase/commit/2853368243ed07339c62c548b7d475f4eeaada59"
},
{
"type": "PACKAGE",
"url": "https://github.com/nocobase/nocobase"
},
{
"type": "WEB",
"url": "https://github.com/nocobase/nocobase/releases/tag/v2.0.37"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "NocoBase has SSRF in Workflow HTTP Request and Custom Request Plugins"
}
GHSA-MVW2-JQ9P-J2H2
Vulnerability from github – Published: 2026-10-10 21:31 – Updated: 2026-10-10 21:31Server-Side Request Forgery (SSRF) vulnerability in Builderius.io Builderius allows Server Side Request Forgery.
This issue affects Builderius: from 1.4 through 1.4-beta.
{
"affected": [],
"aliases": [
"CVE-2026-27350"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-10T20:16:33Z",
"severity": "HIGH"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in Builderius.io Builderius allows Server Side Request Forgery.\n\nThis issue affects Builderius: from 1.4 through 1.4-beta.",
"id": "GHSA-mvw2-jq9p-j2h2",
"modified": "2026-10-10T21:31:16Z",
"published": "2026-10-10T21:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27350"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/builderius/vulnerability/wordpress-builderius-plugin-1-4-beta-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MVXJ-8QHJ-G2WR
Vulnerability from github – Published: 2026-08-31 21:32 – Updated: 2026-08-31 21:32Unauthenticated Server Side Request Forgery (SSRF) in MapSVG <= 8.15.0 versions.
{
"affected": [],
"aliases": [
"CVE-2026-82852"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-31T21:17:54Z",
"severity": "MODERATE"
},
"details": "Unauthenticated Server Side Request Forgery (SSRF) in MapSVG \u003c= 8.15.0 versions.",
"id": "GHSA-mvxj-8qhj-g2wr",
"modified": "2026-08-31T21:32:14Z",
"published": "2026-08-31T21:32:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82852"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/mapsvg-lite-interactive-vector-maps/vulnerability/wordpress-mapsvg-plugin-8-15-0-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MW2P-J3F6-XVPM
Vulnerability from github – Published: 2023-12-07 12:30 – Updated: 2026-04-28 21:33Server-Side Request Forgery (SSRF) vulnerability in Softaculous Team SpeedyCache – Cache, Optimization, Performance.This issue affects SpeedyCache – Cache, Optimization, Performance: from n/a through 1.1.2.
{
"affected": [],
"aliases": [
"CVE-2023-49746"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-07T11:15:08Z",
"severity": "MODERATE"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in Softaculous Team SpeedyCache \u2013 Cache, Optimization, Performance.This issue affects SpeedyCache \u2013 Cache, Optimization, Performance: from n/a through 1.1.2.",
"id": "GHSA-mw2p-j3f6-xvpm",
"modified": "2026-04-28T21:33:17Z",
"published": "2023-12-07T12:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49746"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/speedycache/wordpress-speedycache-plugin-1-1-2-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MW34-C6M6-G442
Vulnerability from github – Published: 2026-08-17 18:31 – Updated: 2026-08-17 18:31In JetBrains IntelliJ IDEA before 2026.2.1 sSRF was possible via the OpenAPI preview proxy in untrusted projects
{
"affected": [],
"aliases": [
"CVE-2026-75054"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-17T16:17:52Z",
"severity": "MODERATE"
},
"details": "In JetBrains IntelliJ IDEA before 2026.2.1 sSRF was possible via the OpenAPI preview proxy in untrusted projects",
"id": "GHSA-mw34-c6m6-g442",
"modified": "2026-08-17T18:31:20Z",
"published": "2026-08-17T18:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-75054"
},
{
"type": "WEB",
"url": "https://www.jetbrains.com/privacy-security/issues-fixed"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MW69-W5MV-7FC5
Vulnerability from github – Published: 2022-12-08 18:30 – Updated: 2022-12-12 18:30In JetBrains TeamCity between 2022.10 and 2022.10.1 a custom STS endpoint allowed internal port scanning.
{
"affected": [],
"aliases": [
"CVE-2022-46830"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-08T18:15:00Z",
"severity": "MODERATE"
},
"details": "In JetBrains TeamCity between 2022.10 and 2022.10.1 a custom STS endpoint allowed internal port scanning.",
"id": "GHSA-mw69-w5mv-7fc5",
"modified": "2022-12-12T18:30:30Z",
"published": "2022-12-08T18:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46830"
},
{
"type": "WEB",
"url": "https://www.jetbrains.com/privacy-security/issues-fixed"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MW9J-687W-WH97
Vulnerability from github – Published: 2026-09-19 09:32 – Updated: 2026-09-19 09:32The Wow Elements Addons for Elementor plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.11.2. This is due to the plugin passing user-controlled input from the 'Changelog File' setting directly to the wp_remote_get function without adequate validation or sanitization of the URL. This makes it possible for authenticated attackers, with Contributor-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.
{
"affected": [],
"aliases": [
"CVE-2026-1641"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-19T08:16:53Z",
"severity": "MODERATE"
},
"details": "The Wow Elements Addons for Elementor plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.11.2. This is due to the plugin passing user-controlled input from the \u0027Changelog File\u0027 setting directly to the wp_remote_get function without adequate validation or sanitization of the URL. This makes it possible for authenticated attackers, with Contributor-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
"id": "GHSA-mw9j-687w-wh97",
"modified": "2026-09-19T09:32:11Z",
"published": "2026-09-19T09:32:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1641"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wow-elements-addons-for-elementor/tags/1.5.6/includes/widgets/changelog.php#L786"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wow-elements-addons-for-elementor/trunk/includes/widgets/changelog.php#L786"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?reponame=\u0026old=3583568%40wow-elements-addons-for-elementor\u0026new=3583568%40wow-elements-addons-for-elementor"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/8ded7bd6-3dd8-4659-9704-f197e7c2f941?source=cve"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-MWP4-54F8-5FHR
Vulnerability from github – Published: 2026-08-03 19:59 – Updated: 2026-08-03 19:59Summary
Address4 accepts an octet written with a leading zero and decodes it as decimal, while the WHATWG URL host parser, inet_aton, and getaddrinfo all decode a leading zero as octal. The library and the network stack therefore disagree about which host a string names. new Address4('012.0.0.1') reports correctForm() of 12.0.0.1 and isPrivate() of false, but fetch('http://012.0.0.1/') connects to 10.0.0.1.
An application that builds a network trust-boundary decision on these checks (for example a filter intended to block Server-Side Request Forgery, or SSRF) will classify an internal target as external and allow the request. SSRF is an attack in which a user-supplied address coaxes the server into making a request to an internal destination the user could not otherwise reach, such as a loopback service or a cloud metadata endpoint.
Details
Address4.parse gates untrusted input on RE_ADDRESS (src/v4/constants.ts:5), whose per-octet alternative is:
(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)
The [01]?[0-9][0-9]? branch matches a leading zero, so 012 passes validation. Every downstream decode then reads the octet with parseInt(part, 10) (src/common.ts:87), yielding 12. A resolver reading the same string treats the leading 0 as base 8 and yields 10.
The defect is in the parse gate rather than in any one classifier, so every consumer of Address4 inherits it: isPrivate(), isLoopback(), isLinkLocal(), isCGNAT(), isInSubnet(), isHostInSubnet(), and correctForm() are all computed from the mis-decoded octets.
Address6 already rejects this notation on its IPv4-in-IPv6 path, throwing "IPv4 addresses can't have leading zeroes." (src/ipv6.ts:751-762), so Address4 is the outlier within the library.
Affected versions
<= 10.3.0. Unlike GHSA-22jq-vg5j-6vgg and GHSA-4xrf-jv44-h6hh, which were bounded below by the is* classification API introduced in 10.1.1, this defect is in parse and reaches every release: a guard built on isInSubnet() against the RFC 1918 ranges is affected in versions predating that API.
Impact
The disagreement runs in both directions. Under-blocking is the security-relevant case; over-blocking is a correctness and availability problem.
| Input | correctForm() |
Classified as | Resolver reaches | Effect |
|---|---|---|---|---|
012.0.0.1 |
12.0.0.1 |
public | 10.0.0.1 |
internal target allowed |
012.012.012.012 |
12.12.12.12 |
public | 10.10.10.10 |
internal target allowed |
010.0.0.1 |
10.0.0.1 |
private | 8.0.0.1 |
public target blocked |
Reachable targets are those whose leading octet is expressible as a three-character octal literal, which covers the whole of 10.0.0.0/8 and 0.0.0.0/8. A four-character octet such as 0177 for 127 is rejected by the regex, so loopback is not reachable through this path; see the note on rejection below for why rejection is not the same as safety.
Reachability
A leading-zero address is a legal URL host, so this is reachable through the ordinary URL path with no unusual application shape required:
new URL('http://012.0.0.1/').hostname // '10.0.0.1'
This distinguishes it from GHSA-4xrf-jv44-h6hh, where the /0 CIDR suffix could not survive URL parsing and exploitation therefore required an application that accepted a bare suffix-bearing string. Here the attack rides the same code path a normal user-supplied URL takes.
Proof of concept
npm i ip-address@10.3.0, then:
const { Address4 } = require('ip-address');
// A guard of the shape the library documents.
function isBlocked(host) {
return Address4.isValid(host) && new Address4(host).isPrivate();
}
for (const h of ['10.0.0.1', '012.0.0.1', '012.012.012.012']) {
console.log(isBlocked(h) ? 'BLOCK' : 'ALLOW', h,
'-> resolver reaches', new URL('http://' + h + '/').hostname);
}
On affected versions:
BLOCK 10.0.0.1 -> resolver reaches 10.0.0.1
ALLOW 012.0.0.1 -> resolver reaches 10.0.0.1
ALLOW 012.012.012.012 -> resolver reaches 10.10.10.10
The literal RFC 1918 address is blocked as expected; the octal-ambiguous spellings of the same destinations are allowed through.
Remediation
Upgrade to the patched release. In the fix, Address4.parse rejects any octet with a leading zero followed by further digits, mirroring the check Address6 already applies at src/ipv6.ts:751, and RE_ADDRESS is tightened so those forms no longer appear in the valid corpus. After upgrading, Address4.isValid('012.0.0.1') returns false and the constructor throws AddressError.
This rejects input that previous releases accepted. An application that deliberately feeds zero-padded addresses such as 010.010.010.010 from a legacy system must strip the padding before parsing.
If you cannot upgrade immediately, reject any host whose octets carry a leading zero before you parse it:
if (host.split('.').some((octet) => /^0\d/.test(octet))) throw new Error('ambiguous address');
A note on SSRF defense
These methods are address classifiers, not a complete SSRF defense. Regardless of this fix, a robust SSRF guard must resolve the hostname and validate the resolved IP against the socket it connects to, and account for DNS rebinding and redirects. Treat these checks as one layer, not the only one.
One specific pitfall is worth naming, because the fix above does not remove it. Address4.isValid() returning false means "this is not a dotted-quad IPv4 literal"; it does not mean "this is not an address that will reach an internal host". Every one of the following is rejected by isValid() and still resolves to loopback:
0177.0.0.1 0x7f.0.0.1 0x7f000001 2130706433
127.1 127.0.1 127.0.0.1. 127.0.0.1
A guard shaped if (Address4.isValid(h)) { check() } else { treatAsHostname() } therefore routes all of them past the IP check. Rejecting these is correct behavior for an IPv4 parser and is not changed by this advisory, but a guard must treat "not a valid literal" as a case to resolve and re-check, never as a case to allow.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.3.0"
},
"package": {
"ecosystem": "npm",
"name": "ip-address"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-69192"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-03T19:59:44Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\n`Address4` accepts an octet written with a leading zero and decodes it as decimal, while the WHATWG URL host parser, `inet_aton`, and `getaddrinfo` all decode a leading zero as octal. The library and the network stack therefore disagree about which host a string names. `new Address4(\u0027012.0.0.1\u0027)` reports `correctForm()` of `12.0.0.1` and `isPrivate()` of `false`, but `fetch(\u0027http://012.0.0.1/\u0027)` connects to `10.0.0.1`.\n\nAn application that builds a network trust-boundary decision on these checks (for example a filter intended to block Server-Side Request Forgery, or SSRF) will classify an internal target as external and allow the request. SSRF is an attack in which a user-supplied address coaxes the server into making a request to an internal destination the user could not otherwise reach, such as a loopback service or a cloud metadata endpoint.\n\n### Details\n\n`Address4.parse` gates untrusted input on `RE_ADDRESS` (`src/v4/constants.ts:5`), whose per-octet alternative is:\n\n```\n(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\n```\n\nThe `[01]?[0-9][0-9]?` branch matches a leading zero, so `012` passes validation. Every downstream decode then reads the octet with `parseInt(part, 10)` (`src/common.ts:87`), yielding 12. A resolver reading the same string treats the leading `0` as base 8 and yields 10.\n\nThe defect is in the parse gate rather than in any one classifier, so every consumer of `Address4` inherits it: `isPrivate()`, `isLoopback()`, `isLinkLocal()`, `isCGNAT()`, `isInSubnet()`, `isHostInSubnet()`, and `correctForm()` are all computed from the mis-decoded octets.\n\n`Address6` already rejects this notation on its IPv4-in-IPv6 path, throwing \"IPv4 addresses can\u0027t have leading zeroes.\" (`src/ipv6.ts:751-762`), so `Address4` is the outlier within the library.\n\n### Affected versions\n\n`\u003c= 10.3.0`. Unlike GHSA-22jq-vg5j-6vgg and GHSA-4xrf-jv44-h6hh, which were bounded below by the `is*` classification API introduced in 10.1.1, this defect is in `parse` and reaches every release: a guard built on `isInSubnet()` against the RFC 1918 ranges is affected in versions predating that API.\n\n### Impact\n\nThe disagreement runs in both directions. Under-blocking is the security-relevant case; over-blocking is a correctness and availability problem.\n\n| Input | `correctForm()` | Classified as | Resolver reaches | Effect |\n|---|---|---|---|---|\n| `012.0.0.1` | `12.0.0.1` | public | `10.0.0.1` | internal target allowed |\n| `012.012.012.012` | `12.12.12.12` | public | `10.10.10.10` | internal target allowed |\n| `010.0.0.1` | `10.0.0.1` | private | `8.0.0.1` | public target blocked |\n\nReachable targets are those whose leading octet is expressible as a three-character octal literal, which covers the whole of `10.0.0.0/8` and `0.0.0.0/8`. A four-character octet such as `0177` for 127 is rejected by the regex, so loopback is not reachable through this path; see the note on rejection below for why rejection is not the same as safety.\n\n### Reachability\n\nA leading-zero address is a legal URL host, so this is reachable through the ordinary URL path with no unusual application shape required:\n\n```js\nnew URL(\u0027http://012.0.0.1/\u0027).hostname // \u002710.0.0.1\u0027\n```\n\nThis distinguishes it from GHSA-4xrf-jv44-h6hh, where the `/0` CIDR suffix could not survive URL parsing and exploitation therefore required an application that accepted a bare suffix-bearing string. Here the attack rides the same code path a normal user-supplied URL takes.\n\n### Proof of concept\n\n`npm i ip-address@10.3.0`, then:\n\n```js\nconst { Address4 } = require(\u0027ip-address\u0027);\n\n// A guard of the shape the library documents.\nfunction isBlocked(host) {\n return Address4.isValid(host) \u0026\u0026 new Address4(host).isPrivate();\n}\n\nfor (const h of [\u002710.0.0.1\u0027, \u0027012.0.0.1\u0027, \u0027012.012.012.012\u0027]) {\n console.log(isBlocked(h) ? \u0027BLOCK\u0027 : \u0027ALLOW\u0027, h,\n \u0027-\u003e resolver reaches\u0027, new URL(\u0027http://\u0027 + h + \u0027/\u0027).hostname);\n}\n```\n\nOn affected versions:\n\n```\nBLOCK 10.0.0.1 -\u003e resolver reaches 10.0.0.1\nALLOW 012.0.0.1 -\u003e resolver reaches 10.0.0.1\nALLOW 012.012.012.012 -\u003e resolver reaches 10.10.10.10\n```\n\nThe literal RFC 1918 address is blocked as expected; the octal-ambiguous spellings of the same destinations are allowed through.\n\n### Remediation\n\nUpgrade to the patched release. In the fix, `Address4.parse` rejects any octet with a leading zero followed by further digits, mirroring the check `Address6` already applies at `src/ipv6.ts:751`, and `RE_ADDRESS` is tightened so those forms no longer appear in the valid corpus. After upgrading, `Address4.isValid(\u0027012.0.0.1\u0027)` returns `false` and the constructor throws `AddressError`.\n\nThis rejects input that previous releases accepted. An application that deliberately feeds zero-padded addresses such as `010.010.010.010` from a legacy system must strip the padding before parsing.\n\nIf you cannot upgrade immediately, reject any host whose octets carry a leading zero before you parse it:\n\n```js\nif (host.split(\u0027.\u0027).some((octet) =\u003e /^0\\d/.test(octet))) throw new Error(\u0027ambiguous address\u0027);\n```\n\n### A note on SSRF defense\n\nThese methods are address classifiers, not a complete SSRF defense. Regardless of this fix, a robust SSRF guard must resolve the hostname and validate the *resolved* IP against the socket it connects to, and account for DNS rebinding and redirects. Treat these checks as one layer, not the only one.\n\nOne specific pitfall is worth naming, because the fix above does not remove it. `Address4.isValid()` returning `false` means \"this is not a dotted-quad IPv4 literal\"; it does not mean \"this is not an address that will reach an internal host\". Every one of the following is rejected by `isValid()` and still resolves to loopback:\n\n```\n0177.0.0.1 0x7f.0.0.1 0x7f000001 2130706433\n127.1 127.0.1 127.0.0.1. \uff11\uff12\uff17.0.0.1\n```\n\nA guard shaped `if (Address4.isValid(h)) { check() } else { treatAsHostname() }` therefore routes all of them past the IP check. Rejecting these is correct behavior for an IPv4 parser and is not changed by this advisory, but a guard must treat \"not a valid literal\" as a case to resolve and re-check, never as a case to allow.",
"id": "GHSA-mwp4-54f8-5fhr",
"modified": "2026-08-03T19:59:44Z",
"published": "2026-08-03T19:59:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/beaugunderson/ip-address/security/advisories/GHSA-mwp4-54f8-5fhr"
},
{
"type": "WEB",
"url": "https://github.com/beaugunderson/ip-address/commit/56368cb3d66c73ba0ee9b6b834fd31b22c2fd71e"
},
{
"type": "PACKAGE",
"url": "https://github.com/beaugunderson/ip-address"
},
{
"type": "WEB",
"url": "https://github.com/beaugunderson/ip-address/releases/tag/v10.3.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "ip-address: Address4 decodes leading-zero octets as decimal while resolvers decode them as octal, allowing SSRF and trust-boundary bypass"
}
GHSA-MX52-G499-R9JM
Vulnerability from github – Published: 2022-05-21 00:01 – Updated: 2022-05-27 00:00Server-Side Request Forgery (SSRF) in GitHub repository jgraph/drawio prior to 18.0.8.
{
"affected": [],
"aliases": [
"CVE-2022-1784"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-20T13:15:00Z",
"severity": "HIGH"
},
"details": "Server-Side Request Forgery (SSRF) in GitHub repository jgraph/drawio prior to 18.0.8.",
"id": "GHSA-mx52-g499-r9jm",
"modified": "2022-05-27T00:00:38Z",
"published": "2022-05-21T00:01:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1784"
},
{
"type": "WEB",
"url": "https://github.com/jgraph/drawio/commit/c63f3a04450f30798df47f9badbc74eb8a69fbdf"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/d1330ce8-cccb-4bae-b9a9-a03b97f444a5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MX5P-8RH7-X52C
Vulnerability from github – Published: 2026-04-27 18:32 – Updated: 2026-04-27 18:32A security vulnerability has been detected in AlejandroArciniegas mcp-data-vis up to de5a51525a69822290eaee569a1ab447b490746d. Affected by this vulnerability is the function axios of the file src/servers/web-scraper/server.js of the component HTTP Request Handler. Such manipulation leads to server-side request forgery. The attack may be launched remotely. The exploit has been disclosed publicly and may be used. This product operates on a rolling release basis, ensuring continuous delivery. Consequently, there are no version details for either affected or updated releases. The project was informed of the problem early through an issue report but has not responded yet.
{
"affected": [],
"aliases": [
"CVE-2026-7146"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-27T18:16:56Z",
"severity": "MODERATE"
},
"details": "A security vulnerability has been detected in AlejandroArciniegas mcp-data-vis up to de5a51525a69822290eaee569a1ab447b490746d. Affected by this vulnerability is the function axios of the file src/servers/web-scraper/server.js of the component HTTP Request Handler. Such manipulation leads to server-side request forgery. The attack may be launched remotely. The exploit has been disclosed publicly and may be used. This product operates on a rolling release basis, ensuring continuous delivery. Consequently, there are no version details for either affected or updated releases. The project was informed of the problem early through an issue report but has not responded yet.",
"id": "GHSA-mx5p-8rh7-x52c",
"modified": "2026-04-27T18:32:09Z",
"published": "2026-04-27T18:32:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7146"
},
{
"type": "WEB",
"url": "https://github.com/AlejandroArciniegas/mcp-data-vis/issues/1"
},
{
"type": "WEB",
"url": "https://github.com/AlejandroArciniegas/mcp-data-vis"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/801895"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/359745"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/359745/cti"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
No mitigation information available for this CWE.
CAPEC-664: Server Side Request Forgery
An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.