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-GF2H-5QX6-V9FR

Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2025-10-22 00:31
VLAI
Details

Zimbra Collaboration Suite before 8.6 patch 13, 8.7.x before 8.7.11 patch 10, and 8.8.x before 8.8.10 patch 7 or 8.8.x before 8.8.11 patch 3 allows SSRF via the ProxyServlet component.

Severity
7.5 (High)
CVSS:3.0/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-2019-9621"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-04-30T18:29:00Z",
    "severity": "HIGH"
  },
  "details": "Zimbra Collaboration Suite before 8.6 patch 13, 8.7.x before 8.7.11 patch 10, and 8.8.x before 8.8.10 patch 7 or 8.8.x before 8.8.11 patch 3 allows SSRF via the ProxyServlet component.",
  "id": "GHSA-gf2h-5qx6-v9fr",
  "modified": "2025-10-22T00:31:39Z",
  "published": "2022-05-24T16:45:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9621"
    },
    {
      "type": "WEB",
      "url": "https://blog.tint0.com/2019/03/a-saga-of-code-executions-on-zimbra.html"
    },
    {
      "type": "WEB",
      "url": "https://blog.zimbra.com/2019/03/9826"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.zimbra.com/show_bug.cgi?id=109127"
    },
    {
      "type": "WEB",
      "url": "https://wiki.zimbra.com/wiki/Security_Center"
    },
    {
      "type": "WEB",
      "url": "https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2019-9621"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/46693"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/152487/Zimbra-Collaboration-Autodiscover-Servlet-XXE-ProxyServlet-SSRF.html"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/153190/Zimbra-XML-Injection-Server-Side-Request-Forgery.html"
    },
    {
      "type": "WEB",
      "url": "http://www.rapid7.com/db/modules/exploit/linux/http/zimbra_xxe_rce"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GF3V-FWQG-4VH7

Vulnerability from github – Published: 2026-02-11 15:13 – Updated: 2026-02-12 14:19
VLAI
Summary
@langchain/community affected by SSRF Bypass in RecursiveUrlLoader via insufficient URL origin validation
Details

Description

The RecursiveUrlLoader class in @langchain/community is a web crawler that recursively follows links from a starting URL. Its preventOutside option (enabled by default) is intended to restrict crawling to the same site as the base URL.

The implementation used String.startsWith() to compare URLs, which does not perform semantic URL validation. An attacker who controls content on a crawled page could include links to domains that share a string prefix with the target (e.g., https://example.com.attacker.com passes a startsWith check against https://example.com), causing the crawler to follow links to attacker-controlled or internal infrastructure.

Additionally, the crawler performed no validation against private or reserved IP addresses. A crawled page could include links targeting cloud metadata services (169.254.169.254), localhost, or RFC 1918 addresses, and the crawler would fetch them without restriction.

Impact

An attacker who can influence the content of a page being crawled (e.g., by placing a link on a public-facing page, forum, or user-generated content) could cause the crawler to:

  • Fetch cloud instance metadata (AWS, GCP, Azure), potentially exposing IAM credentials and session tokens
  • Access internal services on private networks (10.x, 172.16.x, 192.168.x)
  • Connect to localhost services
  • Exfiltrate response data via attacker-controlled redirect chains

This is exploitable in any environment where RecursiveUrlLoader runs on infrastructure with access to cloud metadata or internal services — which includes most cloud-hosted deployments.

Resolution

Two changes were made:

  1. Origin comparison replaced. The startsWith check was replaced with a strict origin comparison using the URL API (new URL(link).origin === new URL(baseUrl).origin). This correctly validates scheme, hostname, and port as a unit, preventing subdomain-based bypasses.

  2. SSRF validation added to all fetch operations. A new URL validation module (@langchain/core/utils/ssrf) was introduced and applied before every outbound fetch in the crawler. This blocks requests to:

  3. Cloud metadata endpoints: 169.254.169.254, 169.254.170.2, 100.100.100.200, metadata.google.internal, and related hostnames
  4. Private IP ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16
  5. IPv6 equivalents: ::1, fc00::/7, fe80::/10
  6. Non-HTTP/HTTPS schemes (file:, ftp:, javascript:, etc.)

Cloud metadata endpoints are unconditionally blocked and cannot be overridden.

Workarounds

Users who cannot upgrade immediately should avoid using RecursiveUrlLoader on untrusted or user-influenced content, or should run the crawler in a network environment without access to cloud metadata or internal services.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.1.13"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@langchain/community"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-26019"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-11T15:13:20Z",
    "nvd_published_at": "2026-02-11T22:15:51Z",
    "severity": "MODERATE"
  },
  "details": "## Description\n\nThe `RecursiveUrlLoader` class in `@langchain/community` is a web crawler that recursively follows links from a starting URL. Its `preventOutside` option (enabled by default) is intended to restrict crawling to the same site as the base URL.\n\nThe implementation used `String.startsWith()` to compare URLs, which does not perform semantic URL validation. An attacker who controls content on a crawled page could include links to domains that share a string prefix with the target (e.g., `https://example.com.attacker.com` passes a `startsWith` check against `https://example.com`), causing the crawler to follow links to attacker-controlled or internal infrastructure.\n\nAdditionally, the crawler performed no validation against private or reserved IP addresses. A crawled page could include links targeting cloud metadata services (`169.254.169.254`), localhost, or RFC 1918 addresses, and the crawler would fetch them without restriction.\n\n## Impact\n\nAn attacker who can influence the content of a page being crawled (e.g., by placing a link on a public-facing page, forum, or user-generated content) could cause the crawler to:\n\n- Fetch cloud instance metadata (AWS, GCP, Azure), potentially exposing IAM credentials and session tokens\n- Access internal services on private networks (`10.x`, `172.16.x`, `192.168.x`)\n- Connect to localhost services\n- Exfiltrate response data via attacker-controlled redirect chains\n\nThis is exploitable in any environment where `RecursiveUrlLoader` runs on infrastructure with access to cloud metadata or internal services \u2014 which includes most cloud-hosted deployments.\n\n## Resolution\n\nTwo changes were made:\n\n1. **Origin comparison replaced.** The `startsWith` check was replaced with a strict origin comparison using the URL API (`new URL(link).origin === new URL(baseUrl).origin`). This correctly validates scheme, hostname, and port as a unit, preventing subdomain-based bypasses.\n\n2. **SSRF validation added to all fetch operations.** A new URL validation module (`@langchain/core/utils/ssrf`) was introduced and applied before every outbound fetch in the crawler. This blocks requests to:\n   - **Cloud metadata endpoints:** `169.254.169.254`, `169.254.170.2`, `100.100.100.200`, `metadata.google.internal`, and related hostnames\n   - **Private IP ranges:** `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `127.0.0.0/8`, `169.254.0.0/16`\n   - **IPv6 equivalents:** `::1`, `fc00::/7`, `fe80::/10`\n   - **Non-HTTP/HTTPS schemes** (`file:`, `ftp:`, `javascript:`, etc.)\n\nCloud metadata endpoints are unconditionally blocked and cannot be overridden.\n\n## Workarounds\n\nUsers who cannot upgrade immediately should avoid using `RecursiveUrlLoader` on untrusted or user-influenced content, or should run the crawler in a network environment without access to cloud metadata or internal services.",
  "id": "GHSA-gf3v-fwqg-4vh7",
  "modified": "2026-02-12T14:19:06Z",
  "published": "2026-02-11T15:13:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/langchain-ai/langchainjs/security/advisories/GHSA-gf3v-fwqg-4vh7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26019"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langchain-ai/langchainjs/pull/9990"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langchain-ai/langchainjs/commit/d5e3db0d01ab321ec70a875805b2f74aefdadf9d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/langchain-ai/langchainjs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langchain-ai/langchainjs/releases/tag/%40langchain%2Fcommunity%401.1.14"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@langchain/community affected by SSRF Bypass in RecursiveUrlLoader via insufficient URL origin validation"
}

GHSA-GFGJ-8F63-3RWQ

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

Subscriber Server Side Request Forgery (SSRF) in [Aotuman] Grab WeChat Articles <= 2.0.1 versions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-32467"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-18T14:17:04Z",
    "severity": "MODERATE"
  },
  "details": "Subscriber Server Side Request Forgery (SSRF) in [Aotuman] Grab WeChat Articles \u003c= 2.0.1 versions.",
  "id": "GHSA-gfgj-8f63-3rwq",
  "modified": "2026-08-18T15:31:46Z",
  "published": "2026-08-18T15:31:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32467"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/apoyl-grabweixin/vulnerability/wordpress-aotuman-grab-wechat-articles-plugin-2-0-1-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GFHV-5RQH-7QX3

Vulnerability from github – Published: 2025-03-29 00:31 – Updated: 2025-04-01 14:20
VLAI
Summary
ShopXO Vulnerable to Server-Side Request Forgery (SSRF) via Email Settings
Details

ShopXO v6.4.0 is vulnerable to Server-Side Request Forgery (SSRF) in Email Settings.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopxo/shopxo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "6.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-28093"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-01T14:20:17Z",
    "nvd_published_at": "2025-03-28T22:15:18Z",
    "severity": "MODERATE"
  },
  "details": "ShopXO v6.4.0 is vulnerable to Server-Side Request Forgery (SSRF) in Email Settings.",
  "id": "GHSA-gfhv-5rqh-7qx3",
  "modified": "2025-04-01T14:20:17Z",
  "published": "2025-03-29T00:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-28093"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gongfuxiang/shopxo"
    },
    {
      "type": "WEB",
      "url": "https://www.yuque.com/morysummer/vx41bz/he2hb8ic8an8h07f"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ShopXO Vulnerable to Server-Side Request Forgery (SSRF) via Email Settings"
}

GHSA-GFJH-WVFW-6J4F

Vulnerability from github – Published: 2024-03-28 06:30 – Updated: 2026-04-01 18:31
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Kadence WP Gutenberg Blocks by Kadence Blocks.This issue affects Gutenberg Blocks by Kadence Blocks: from n/a through 3.2.19.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-23500"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-28T06:15:10Z",
    "severity": "HIGH"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Kadence WP Gutenberg Blocks by Kadence Blocks.This issue affects Gutenberg Blocks by Kadence Blocks: from n/a through 3.2.19.",
  "id": "GHSA-gfjh-wvfw-6j4f",
  "modified": "2026-04-01T18:31:43Z",
  "published": "2024-03-28T06:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23500"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/kadence-blocks/vulnerability/wordpress-kadence-blocks-plugin-3-2-19-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/kadence-blocks/wordpress-kadence-blocks-plugin-3-2-19-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GFPR-2VCF-JMXJ

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

Server-Side Request Forgery (SSRF) vulnerability in Brecht Visual Link Preview visual-link-preview allows Server Side Request Forgery.This issue affects Visual Link Preview: from n/a through <= 2.3.0.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-39670"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-08T09:16:38Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Brecht Visual Link Preview visual-link-preview allows Server Side Request Forgery.This issue affects Visual Link Preview: from n/a through \u003c= 2.3.0.",
  "id": "GHSA-gfpr-2vcf-jmxj",
  "modified": "2026-04-09T18:31:25Z",
  "published": "2026-04-08T09:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39670"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/visual-link-preview/vulnerability/wordpress-visual-link-preview-plugin-2-3-0-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GFQ7-5X4G-3XHF

Vulnerability from github – Published: 2026-06-22 23:39 – Updated: 2026-08-12 18:57
VLAI
Summary
@budibase/backend-core has potential SSRF DNS rebinding bypass in outbound fetch validation
Details

Summary

Authenticated users with automation permissions can bypass Budibase's SSRF blacklist through DNS rebinding.

The outbound fetch flow validates a hostname against the blacklist before the request is sent, but the actual socket connection later performs a separate DNS lookup through node-fetch. Since the validated IPs are never pinned to the connection, an attacker-controlled hostname can return a public IP during validation and a private/internal IP during the real connection.

This results in a non-blind SSRF primitive against internal services reachable from the Budibase host, including loopback, RFC1918 ranges, and cloud metadata endpoints.

Details

The issue comes from the outbound fetch validation flow resolving DNS twice:

During blacklist validation Again during the real socket connection

The first lookup result is discarded after validation, so the second lookup is free to resolve to a different IP.

This creates a classic TOCTOU DNS rebinding issue.

Affected flow in:

packages/backend-core/src/utils/outboundFetch.ts

async function throwIfUnsafe(url: string): Promise<void> {
  const parsed = parseUrl(url)

  if (await isBlacklisted(parsed.hostname)) {
    throw new Error("URL is blocked or could not be resolved safely.")
  }
}

for (let redirects = 0; redirects <= MAX_REDIRECTS; redirects++) {
  await throwIfUnsafe(nextUrl)

  const response = await fetchFn(nextUrl, nextRequest)

  // ...
}

fetchFn uses plain node-fetch with no custom http.Agent / https.Agent, so the underlying socket performs its own independent dns.lookup after validation completes.

The same pattern also exists in:

packages/server/src/automations/steps/utils.ts

await throwIfBlacklisted(nextUrl)

const response = await fetch(nextUrl, nextRequest)

The blacklist implementation resolves hostnames but only returns a boolean:

packages/backend-core/src/blacklist/blacklist.ts

async function lookup(address: string): Promise<string[]> {
  address = parseAddress(address)

  const addresses = await performLookup(address, { all: true })

  return addresses.map(addr => addr.address)
}

export async function isBlacklisted(address: string): Promise<boolean> {
  // ...

  if (!net.isIP(address)) {
    try {
      ips = await lookup(address)
    } catch (e) {
      /* ... */
    }
  } else {
    ips = [address]
  }

  return ips.some(ip => blackList!.check(ip, getIpVersion(ip)))
}

The resolved IPs are discarded, so callers cannot pin the later socket connection to the validated addresses.

An attacker controlling authoritative DNS for a hostname can therefore return:

a public IP during validation a private/internal IP during the actual connection

Anything routing through these helpers inherits the issue, including:

outgoing webhook Slack Discord Make Zapier n8n AI extract object-store fetches

Several of these steps return upstream response content directly into automation output, which makes the SSRF non-blind.

PoC

Tested locally against a self-hosted build from master. No Budibase-operated infrastructure was touched.

Run Budibase locally.

Start a harmless local HTTP listener:

python3 -m http.server 8080 --bind 127.0.0.1

Use a rebinding hostname such as:

7f000001.cb007264.rbndr.us

which rotates between:

127.0.0.1 203.0.113.100

Steps to reproduce:

Log into Budibase with automation permissions. Create an automation using the Outgoing Webhook step. Set the URL to: http://:8080/ Trigger the automation.

Observed result:

The blacklist validation resolves the hostname to the public IP and allows the request. node-fetch performs a second DNS lookup during socket creation. The second lookup resolves to 127.0.0.1. The TCP connection lands on the local service. The local server response body appears directly in the automation output. Impact

This produces a non-blind read-SSRF primitive against anything reachable from the Budibase host process, including:

loopback services (127.0.0.1) RFC1918 ranges internal Kubernetes/VPC services cloud metadata endpoints (169.254.169.254)

On cloud deployments without IMDSv2 enforcement, this may expose temporary IAM credentials via:

/latest/meta-data/iam/security-credentials/

On multi-tenant hosted deployments, this may also create potential cross-tenant access paths through shared internal infrastructure.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@budibase/backend-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.39.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54353"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-22T23:39:24Z",
    "nvd_published_at": "2026-06-26T21:16:35Z",
    "severity": "HIGH"
  },
  "details": "Summary\n\nAuthenticated users with automation permissions can bypass Budibase\u0027s SSRF blacklist through DNS rebinding.\n\nThe outbound fetch flow validates a hostname against the blacklist before the request is sent, but the actual socket connection later performs a separate DNS lookup through node-fetch. Since the validated IPs are never pinned to the connection, an attacker-controlled hostname can return a public IP during validation and a private/internal IP during the real connection.\n\nThis results in a non-blind SSRF primitive against internal services reachable from the Budibase host, including loopback, RFC1918 ranges, and cloud metadata endpoints.\n\nDetails\n\nThe issue comes from the outbound fetch validation flow resolving DNS twice:\n\nDuring blacklist validation\nAgain during the real socket connection\n\nThe first lookup result is discarded after validation, so the second lookup is free to resolve to a different IP.\n\nThis creates a classic TOCTOU DNS rebinding issue.\n\nAffected flow in:\n\npackages/backend-core/src/utils/outboundFetch.ts\n```\nasync function throwIfUnsafe(url: string): Promise\u003cvoid\u003e {\n  const parsed = parseUrl(url)\n\n  if (await isBlacklisted(parsed.hostname)) {\n    throw new Error(\"URL is blocked or could not be resolved safely.\")\n  }\n}\n\nfor (let redirects = 0; redirects \u003c= MAX_REDIRECTS; redirects++) {\n  await throwIfUnsafe(nextUrl)\n\n  const response = await fetchFn(nextUrl, nextRequest)\n\n  // ...\n}\n```\nfetchFn uses plain node-fetch with no custom http.Agent / https.Agent, so the underlying socket performs its own independent dns.lookup after validation completes.\n\nThe same pattern also exists in:\n\npackages/server/src/automations/steps/utils.ts\n```\nawait throwIfBlacklisted(nextUrl)\n\nconst response = await fetch(nextUrl, nextRequest)\n```\nThe blacklist implementation resolves hostnames but only returns a boolean:\n\npackages/backend-core/src/blacklist/blacklist.ts\n```\nasync function lookup(address: string): Promise\u003cstring[]\u003e {\n  address = parseAddress(address)\n\n  const addresses = await performLookup(address, { all: true })\n\n  return addresses.map(addr =\u003e addr.address)\n}\n\nexport async function isBlacklisted(address: string): Promise\u003cboolean\u003e {\n  // ...\n\n  if (!net.isIP(address)) {\n    try {\n      ips = await lookup(address)\n    } catch (e) {\n      /* ... */\n    }\n  } else {\n    ips = [address]\n  }\n\n  return ips.some(ip =\u003e blackList!.check(ip, getIpVersion(ip)))\n}\n```\nThe resolved IPs are discarded, so callers cannot pin the later socket connection to the validated addresses.\n\nAn attacker controlling authoritative DNS for a hostname can therefore return:\n\na public IP during validation\na private/internal IP during the actual connection\n\nAnything routing through these helpers inherits the issue, including:\n\noutgoing webhook\nSlack\nDiscord\nMake\nZapier\nn8n\nAI extract\nobject-store fetches\n\nSeveral of these steps return upstream response content directly into automation output, which makes the SSRF non-blind.\n\nPoC\n\nTested locally against a self-hosted build from master.\nNo Budibase-operated infrastructure was touched.\n\nRun Budibase locally.\n\nStart a harmless local HTTP listener:\n\npython3 -m http.server 8080 --bind 127.0.0.1\n\nUse a rebinding hostname such as:\n\n7f000001.cb007264.rbndr.us\n\nwhich rotates between:\n\n127.0.0.1\n203.0.113.100\n\nSteps to reproduce:\n\nLog into Budibase with automation permissions.\nCreate an automation using the Outgoing Webhook step.\nSet the URL to:\nhttp://\u003crebinding-host\u003e:8080/\nTrigger the automation.\n\nObserved result:\n\nThe blacklist validation resolves the hostname to the public IP and allows the request.\nnode-fetch performs a second DNS lookup during socket creation.\nThe second lookup resolves to 127.0.0.1.\nThe TCP connection lands on the local service.\nThe local server response body appears directly in the automation output.\nImpact\n\nThis produces a non-blind read-SSRF primitive against anything reachable from the Budibase host process, including:\n\nloopback services (127.0.0.1)\nRFC1918 ranges\ninternal Kubernetes/VPC services\ncloud metadata endpoints (169.254.169.254)\n\nOn cloud deployments without IMDSv2 enforcement, this may expose temporary IAM credentials via:\n\n/latest/meta-data/iam/security-credentials/\u003crole\u003e\n\nOn multi-tenant hosted deployments, this may also create potential cross-tenant access paths through shared internal infrastructure.",
  "id": "GHSA-gfq7-5x4g-3xhf",
  "modified": "2026-08-12T18:57:24Z",
  "published": "2026-06-22T23:39:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-gfq7-5x4g-3xhf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54353"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Budibase/budibase"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@budibase/backend-core has potential SSRF DNS rebinding bypass in outbound fetch validation"
}

GHSA-GFRJ-PXWG-9R69

Vulnerability from github – Published: 2026-08-11 12:30 – Updated: 2026-08-11 12:30
VLAI
Details

A server-side request forgery vulnerability in Apioo Fusio 8.8.3 allows authenticated consumer-role users to make the server issue HTTP requests to internal network addresses by registering a webhook URL pointing to an internal host. The webhook registration endpoint validates URL syntax via FILTER_VALIDATE_URL but applies no IP or host denylist. When the registered event fires, the server issues an HTTP POST to the attacker-supplied internal URL.

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": [],
  "aliases": [
    "CVE-2026-72598"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-11T12:17:42Z",
    "severity": "MODERATE"
  },
  "details": "A server-side request forgery vulnerability in Apioo Fusio 8.8.3 allows authenticated consumer-role users to make the server issue HTTP requests to internal network addresses by registering a webhook URL pointing to an internal host. The webhook registration endpoint validates URL syntax via FILTER_VALIDATE_URL but applies no IP or host denylist. When the registered event fires, the server issues an HTTP POST to the attacker-supplied internal URL.",
  "id": "GHSA-gfrj-pxwg-9r69",
  "modified": "2026-08-11T12:30:27Z",
  "published": "2026-08-11T12:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72598"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apioo/fusio"
    }
  ],
  "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"
    }
  ]
}

GHSA-GFW7-F889-5P73

Vulnerability from github – Published: 2024-06-06 18:30 – Updated: 2024-06-06 18:30
VLAI
Details

A Server-Side Request Forgery (SSRF) vulnerability exists in the 'add_webpage' endpoint of the parisneo/lollms-webui application, affecting the latest version. The vulnerability arises because the application does not adequately validate URLs entered by users, allowing them to input arbitrary URLs, including those that target internal resources such as 'localhost' or '127.0.0.1'. This flaw enables attackers to make unauthorized requests to internal or external systems, potentially leading to access to sensitive data, service disruption, network integrity compromise, business logic manipulation, and abuse of third-party resources. The issue is critical and requires immediate attention to maintain the application's security and integrity.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-5482"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-06T18:15:21Z",
    "severity": "HIGH"
  },
  "details": "A Server-Side Request Forgery (SSRF) vulnerability exists in the \u0027add_webpage\u0027 endpoint of the parisneo/lollms-webui application, affecting the latest version. The vulnerability arises because the application does not adequately validate URLs entered by users, allowing them to input arbitrary URLs, including those that target internal resources such as \u0027localhost\u0027 or \u0027127.0.0.1\u0027. This flaw enables attackers to make unauthorized requests to internal or external systems, potentially leading to access to sensitive data, service disruption, network integrity compromise, business logic manipulation, and abuse of third-party resources. The issue is critical and requires immediate attention to maintain the application\u0027s security and integrity.",
  "id": "GHSA-gfw7-f889-5p73",
  "modified": "2024-06-06T18:30:58Z",
  "published": "2024-06-06T18:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5482"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/d97e23e7-172f-4862-a732-86bfc0b7860e"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GG29-529G-R9M2

Vulnerability from github – Published: 2025-09-09 18:31 – Updated: 2025-09-09 18:31
VLAI
Details

SSRF in Ivanti Connect Secure before 22.7R2.9 or 22.8R2, Ivanti Policy Secure before 22.7R1.6, Ivanti ZTA Gateway before 2.8R2.3-723 and Ivanti Neurons for Secure Access before 22.8R1.4 (Fix deployed on 02-Aug-2025) allows a remote authenticated attacker with admin privileges to enumerate internal services.

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-2025-55139"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-09T16:15:33Z",
    "severity": "MODERATE"
  },
  "details": "SSRF in Ivanti Connect Secure before 22.7R2.9 or 22.8R2, Ivanti Policy Secure before 22.7R1.6, Ivanti ZTA Gateway before 2.8R2.3-723 and Ivanti Neurons for Secure Access before 22.8R1.4 (Fix deployed on 02-Aug-2025) allows a remote authenticated attacker with admin privileges to enumerate internal services.",
  "id": "GHSA-gg29-529g-r9m2",
  "modified": "2025-09-09T18:31:18Z",
  "published": "2025-09-09T18:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55139"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/September-Security-Advisory-Ivanti-Connect-Secure-Policy-Secure-ZTA-Gateways-and-Neurons-for-Secure-Access-Multiple-CVEs?language=en_US"
    }
  ],
  "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"
    }
  ]
}

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