CWE-918
AllowedServer-Side Request Forgery (SSRF)
Abstraction: Base · Status: Incomplete
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
6271 vulnerabilities reference this CWE, most recent first.
GHSA-4PFF-25FV-CM83
Vulnerability from github – Published: 2024-02-14 18:30 – Updated: 2024-05-03 15:30Grafana is an open-source platform for monitoring and observability. The CSV datasource plugin is a Grafana Labs maintained plugin for Grafana that allows for retrieving and processing CSV data from a remote endpoint configured by an administrator. If this plugin was configured to send requests to a bare host with no path (e.g. https://www.example.com/ https://www.example.com/` ), requests to an endpoint other than the one configured by the administrator could be triggered by a specially crafted request from any user, resulting in an SSRF vector. AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
{
"affected": [],
"aliases": [
"CVE-2023-5122"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-14T15:15:08Z",
"severity": "MODERATE"
},
"details": "Grafana is an open-source platform for monitoring and observability. The CSV datasource plugin is a Grafana Labs maintained plugin for Grafana that allows for retrieving and processing CSV data from a remote endpoint configured by an administrator. If this plugin was configured to send requests to a bare host with no path (e.g. https://www.example.com/ https://www.example.com/` ), requests to an endpoint other than the one configured by the administrator could be triggered by a specially crafted request from any user, resulting in an SSRF vector. AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator \n",
"id": "GHSA-4pff-25fv-cm83",
"modified": "2024-05-03T15:30:36Z",
"published": "2024-02-14T18:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5122"
},
{
"type": "WEB",
"url": "https://grafana.com/security/security-advisories/cve-2023-5122"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240503-0002"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4PG5-GW5Q-8554
Vulnerability from github – Published: 2026-08-11 18:31 – Updated: 2026-08-11 18:31Server-side request forgery (ssrf) in Microsoft Office SharePoint allows an authorized attacker to elevate privileges over a network.
{
"affected": [],
"aliases": [
"CVE-2026-70326"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-11T17:19:10Z",
"severity": "HIGH"
},
"details": "Server-side request forgery (ssrf) in Microsoft Office SharePoint allows an authorized attacker to elevate privileges over a network.",
"id": "GHSA-4pg5-gw5q-8554",
"modified": "2026-08-11T18:31:49Z",
"published": "2026-08-11T18:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-70326"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-70326"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-4PM6-4PWH-F3GG
Vulnerability from github – Published: 2026-06-22 18:34 – Updated: 2026-07-23 15:30IBM Watson Speech Services Cartridge is vulnerable to Server-Side Request Forgery (SSRF) in Sterling File Gateway, due to a flaw which may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks [GHSA-rr7j-v2q5-chgv] [CVE-2026-7253]. IBM Sterling File Gateway is used in our speech runtimes. This vulnerabilitiy has been addressed. Please read the details for remediation below.
{
"affected": [],
"aliases": [
"CVE-2026-7253"
],
"database_specific": {
"cwe_ids": [
"CWE-89",
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-22T16:16:41Z",
"severity": "MODERATE"
},
"details": "IBM Watson Speech Services Cartridge is vulnerable to Server-Side Request Forgery (SSRF) in Sterling File Gateway, due to a flaw which may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks [GHSA-rr7j-v2q5-chgv] [CVE-2026-7253]. IBM Sterling File Gateway is used in our speech runtimes. This vulnerabilitiy has been addressed. Please read the details for remediation below.",
"id": "GHSA-4pm6-4pwh-f3gg",
"modified": "2026-07-23T15:30:34Z",
"published": "2026-06-22T18:34:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7253"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7276994"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7280923"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4PMF-QQVH-JVQV
Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-05-24 19:12YzmCMS v5.5 contains a server-side request forgery (SSRF) in the grab_image() function.
{
"affected": [],
"aliases": [
"CVE-2020-20341"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-01T20:15:00Z",
"severity": "HIGH"
},
"details": "YzmCMS v5.5 contains a server-side request forgery (SSRF) in the grab_image() function.",
"id": "GHSA-4pmf-qqvh-jvqv",
"modified": "2022-05-24T19:12:40Z",
"published": "2022-05-24T19:12:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-20341"
},
{
"type": "WEB",
"url": "https://github.com/yzmcms/yzmcms/issues/44"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4Q2M-7CH2-98QJ
Vulnerability from github – Published: 2026-04-19 15:30 – Updated: 2026-04-19 15:30A vulnerability was detected in PHPEMS 11.0. This affects the function temppage of the file /app/exam/controller/exams.master.php of the component Instant Exam Creation Handler. The manipulation of the argument uploadfile results in server-side request forgery. The attack can be executed remotely. The exploit is now public and may be used.
{
"affected": [],
"aliases": [
"CVE-2026-6573"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-19T13:16:46Z",
"severity": "MODERATE"
},
"details": "A vulnerability was detected in PHPEMS 11.0. This affects the function temppage of the file /app/exam/controller/exams.master.php of the component Instant Exam Creation Handler. The manipulation of the argument uploadfile results in server-side request forgery. The attack can be executed remotely. The exploit is now public and may be used.",
"id": "GHSA-4q2m-7ch2-98qj",
"modified": "2026-04-19T15:30:18Z",
"published": "2026-04-19T15:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6573"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/789990"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/358207"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/358207/cti"
},
{
"type": "WEB",
"url": "https://vulnplus-note.wetolink.com/share/1QZ4NE0oTRIc"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-4Q39-2JHR-7QX8
Vulnerability from github – Published: 2026-09-02 22:14 – Updated: 2026-09-02 22:14Summary
@platejs/docx-io can fetch remote image URLs while converting HTML to DOCX. When an application converts attacker-controlled HTML in a server-side or privileged environment, this can cause the application environment to make unintended outbound requests and include fetched image data in the generated DOCX.
Impact
Applications are affected when they use @platejs/docx-io to convert untrusted HTML that may contain remote image references, especially in server-side conversion workflows or environments with access to internal network resources.
Affected package:
@platejs/docx-ioversions< 53.3.2
Patched versions
Upgrade to @platejs/docx-io version 53.3.2 or later.
Workarounds
If you cannot upgrade immediately, do not pass untrusted HTML with remote image URLs to DOCX export. Sanitize untrusted HTML to remove remote image references, convert trusted images to data URIs before conversion, or run conversion in an environment with restricted outbound network access.
Credits
Thanks to EQSTLab for reporting this issue.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@platejs/docx-io"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "53.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-65842"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-02T22:14:54Z",
"nvd_published_at": "2026-08-20T17:19:23Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`@platejs/docx-io` can fetch remote image URLs while converting HTML to DOCX. When an application converts attacker-controlled HTML in a server-side or privileged environment, this can cause the application environment to make unintended outbound requests and include fetched image data in the generated DOCX.\n\n## Impact\n\nApplications are affected when they use `@platejs/docx-io` to convert untrusted HTML that may contain remote image references, especially in server-side conversion workflows or environments with access to internal network resources.\n\nAffected package:\n\n- `@platejs/docx-io` versions `\u003c 53.3.2`\n\n## Patched versions\n\nUpgrade to `@platejs/docx-io` version `53.3.2` or later.\n\n## Workarounds\n\nIf you cannot upgrade immediately, do not pass untrusted HTML with remote image URLs to DOCX export. Sanitize untrusted HTML to remove remote image references, convert trusted images to data URIs before conversion, or run conversion in an environment with restricted outbound network access.\n\n## Credits\n\nThanks to EQSTLab for reporting this issue.",
"id": "GHSA-4q39-2jhr-7qx8",
"modified": "2026-09-02T22:14:54Z",
"published": "2026-09-02T22:14:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/udecode/plate/security/advisories/GHSA-4q39-2jhr-7qx8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65842"
},
{
"type": "WEB",
"url": "https://github.com/udecode/plate/pull/5053"
},
{
"type": "WEB",
"url": "https://github.com/udecode/plate/commit/21aa59926f4bbd421027354823cca09c6700ed73"
},
{
"type": "PACKAGE",
"url": "https://github.com/udecode/plate"
},
{
"type": "WEB",
"url": "https://github.com/udecode/plate/releases/tag/v53.3.2"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Plate: SSRF with response disclosure in DOCX image embedding"
}
GHSA-4Q6H-8P4V-67VQ
Vulnerability from github – Published: 2026-06-22 22:45 – Updated: 2026-06-22 22:45Summary
fetchToken in the OAuth2 SDK makes a POST to a builder-supplied URL with plain node-fetch, skipping the blacklist.isBlacklisted check that every other outbound fetch path in the codebase uses. The Joi schema for the OAuth2 URL has no scheme or host restriction. Alice, a builder, points an OAuth2 config at http://169.254.169.254/... or http://127.0.0.1:5984/; the server connects and returns response-body fragments in the validation result.
Details
packages/server/src/sdk/workspace/oauth2/utils.ts:17-65 defines fetchToken. Near the end:
const resp = await fetch(config.url, fetchConfig)
config.url is whatever the builder stored. fetchConfig has redirect: "follow" (the default), so a public URL that returns 302 to an internal target is also reachable.
The route validation at packages/server/src/api/routes/oauth2.ts:9 accepts any string:
url: Joi.string().required(),
The controller passes the URL into fetchToken through crud.ts. The /api/oauth2/validate endpoint (builder role) is the most direct attack path: it lives on builderRoutes, takes the URL from the body, fires the fetch, and returns a validation envelope that includes the upstream error string.
Compare with every other outbound fetch in the codebase:
packages/server/src/integrations/rest.ts:754callsblacklist.isBlacklisted(url)before its fetch (though it does not re-check redirects; see companion advisory for REST-redirect SSRF).packages/backend-core/src/utils/outboundFetch.ts:98-100setsredirect: "manual"and re-validates each hop.packages/server/src/automations/steps/outgoingWebhook.tsroutes throughfetchWithBlacklist.
The default blacklist blocks 127.0.0.0/8, 169.254.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (packages/backend-core/src/blacklist/blacklist.ts:6-16). The OAuth2 path never consults it.
Proof of Concept
Tested against Budibase 3.35.8 (built from master at f960e361).
Step 1: Alice, a builder, POSTs an OAuth2 config pointed at CouchDB on the same host as Budibase:
curl -sS -b "$BUILDER_COOKIE" -X POST "$BASE/api/oauth2/validate" \
-H "Content-Type: application/json" \
-d '{"url":"http://127.0.0.1:5984/","clientId":"t","clientSecret":"t",
"method":"BODY","grantType":"client_credentials"}'
Server response:
{"valid":false,"message":"Method Not Allowed"}
Budibase reached CouchDB (which rejects POST at / with 405). Without the blacklist bypass this request would be blocked at the IP check.
Step 2: Probe the cloud metadata range:
curl -sS -b "$BUILDER_COOKIE" -X POST "$BASE/api/oauth2/validate" \
-H "Content-Type: application/json" \
-d '{"url":"http://169.254.169.254/latest/meta-data/","clientId":"t","clientSecret":"t","method":"BODY","grantType":"client_credentials"}'
Server response:
{"valid":false,"message":"invalid json response body at http://169.254.169.254/latest/meta-data/ reason: Unexpected token 'N', \"Not Found\" is not valid JSON"}
The "Not Found" substring is the upstream body; the server reached the link-local metadata endpoint and leaked the first bytes of the response into the validation error.
Impact
Two concrete paths, both reachable from any builder account (free-tier signup on Budibase Cloud is enough):
- Cross-tenant data read on Cloud. Budibase Cloud multi-tenants on a shared CouchDB; each tenant gets its own
<tenantId>_global-dbandapp_<id>databases on the same port 5984. The blacklist is what keeps a builder from talking to CouchDB directly. With that bypassed, Alice canGET http://127.0.0.1:5984/_all_dbsvia a 302 redirector and enumerate every other tenant's databases, then read their_users, app definitions, and datasource configs (which include third-party credentials). None of this traffic goes through Budibase's tenant isolation layer, so standard app-level access controls do not apply. - IAM credential exfiltration. Alice points the URL at
http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>/and receives the instance role credentials in the validation error path. Those credentials carry whatever AWS permissions the Budibase instance role holds.
Self-hosted deployments face the same CouchDB/Redis/MinIO access plus any other service reachable on the host or pod network. The blacklist was explicitly added to prevent exactly this, and every other outbound fetch path uses it.
Recommended Fix
Call blacklist.isBlacklisted before the fetch and set redirect: "manual" on fetchConfig, matching the pattern in outboundFetch.ts:
import { blacklist } from "@budibase/backend-core"
async function fetchToken(config: { url: string; /* ... */ }) {
config = await processEnvironmentVariable(config)
if (await blacklist.isBlacklisted(config.url)) {
throw new Error("OAuth2 token URL is blocked.")
}
const fetchConfig: RequestInit = {
method: "POST",
headers: { "Content-Type": "application/x-www-form-urlencoded" },
body: new URLSearchParams({ grant_type: "client_credentials" }),
redirect: "manual",
}
// ...
}
Alternatively, replace the fetch call with fetchWithBlacklist, which handles both checks and re-validates redirect targets.
Found by aisafe.io
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@budibase/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.39.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48153"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-22T22:45:35Z",
"nvd_published_at": "2026-05-27T18:16:27Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`fetchToken` in the OAuth2 SDK makes a POST to a builder-supplied URL with plain node-fetch, skipping the `blacklist.isBlacklisted` check that every other outbound fetch path in the codebase uses. The Joi schema for the OAuth2 URL has no scheme or host restriction. Alice, a builder, points an OAuth2 config at `http://169.254.169.254/...` or `http://127.0.0.1:5984/`; the server connects and returns response-body fragments in the validation result.\n\n## Details\n\n`packages/server/src/sdk/workspace/oauth2/utils.ts:17-65` defines `fetchToken`. Near the end:\n\n```typescript\nconst resp = await fetch(config.url, fetchConfig)\n```\n\n`config.url` is whatever the builder stored. `fetchConfig` has `redirect: \"follow\"` (the default), so a public URL that returns 302 to an internal target is also reachable.\n\nThe route validation at `packages/server/src/api/routes/oauth2.ts:9` accepts any string:\n\n```typescript\nurl: Joi.string().required(),\n```\n\nThe controller passes the URL into `fetchToken` through `crud.ts`. The `/api/oauth2/validate` endpoint (builder role) is the most direct attack path: it lives on `builderRoutes`, takes the URL from the body, fires the fetch, and returns a validation envelope that includes the upstream error string.\n\nCompare with every other outbound fetch in the codebase:\n\n- `packages/server/src/integrations/rest.ts:754` calls `blacklist.isBlacklisted(url)` before its fetch (though it does not re-check redirects; see companion advisory for REST-redirect SSRF).\n- `packages/backend-core/src/utils/outboundFetch.ts:98-100` sets `redirect: \"manual\"` and re-validates each hop.\n- `packages/server/src/automations/steps/outgoingWebhook.ts` routes through `fetchWithBlacklist`.\n\nThe default blacklist blocks `127.0.0.0/8`, `169.254.0.0/16`, `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` (`packages/backend-core/src/blacklist/blacklist.ts:6-16`). The OAuth2 path never consults it.\n\n## Proof of Concept\n\nTested against Budibase 3.35.8 (built from master at f960e361).\n\nStep 1: Alice, a builder, POSTs an OAuth2 config pointed at CouchDB on the same host as Budibase:\n\n```bash\ncurl -sS -b \"$BUILDER_COOKIE\" -X POST \"$BASE/api/oauth2/validate\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"url\":\"http://127.0.0.1:5984/\",\"clientId\":\"t\",\"clientSecret\":\"t\",\n \"method\":\"BODY\",\"grantType\":\"client_credentials\"}\u0027\n```\n\nServer response:\n\n```json\n{\"valid\":false,\"message\":\"Method Not Allowed\"}\n```\n\nBudibase reached CouchDB (which rejects POST at `/` with 405). Without the blacklist bypass this request would be blocked at the IP check.\n\nStep 2: Probe the cloud metadata range:\n\n```bash\ncurl -sS -b \"$BUILDER_COOKIE\" -X POST \"$BASE/api/oauth2/validate\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"url\":\"http://169.254.169.254/latest/meta-data/\",\"clientId\":\"t\",\"clientSecret\":\"t\",\"method\":\"BODY\",\"grantType\":\"client_credentials\"}\u0027\n```\n\nServer response:\n\n```json\n{\"valid\":false,\"message\":\"invalid json response body at http://169.254.169.254/latest/meta-data/ reason: Unexpected token \u0027N\u0027, \\\"Not Found\\\" is not valid JSON\"}\n```\n\nThe `\"Not Found\"` substring is the upstream body; the server reached the link-local metadata endpoint and leaked the first bytes of the response into the validation error.\n\n## Impact\n\nTwo concrete paths, both reachable from any builder account (free-tier signup on Budibase Cloud is enough):\n\n1. **Cross-tenant data read on Cloud.** Budibase Cloud multi-tenants on a shared CouchDB; each tenant gets its own `\u003ctenantId\u003e_global-db` and `app_\u003cid\u003e` databases on the same port 5984. The blacklist is what keeps a builder from talking to CouchDB directly. With that bypassed, Alice can `GET http://127.0.0.1:5984/_all_dbs` via a 302 redirector and enumerate every other tenant\u0027s databases, then read their `_users`, app definitions, and datasource configs (which include third-party credentials). None of this traffic goes through Budibase\u0027s tenant isolation layer, so standard app-level access controls do not apply.\n2. **IAM credential exfiltration.** Alice points the URL at `http://169.254.169.254/latest/meta-data/iam/security-credentials/\u003crole\u003e/` and receives the instance role credentials in the validation error path. Those credentials carry whatever AWS permissions the Budibase instance role holds.\n\nSelf-hosted deployments face the same CouchDB/Redis/MinIO access plus any other service reachable on the host or pod network. The blacklist was explicitly added to prevent exactly this, and every other outbound fetch path uses it.\n\n## Recommended Fix\n\nCall `blacklist.isBlacklisted` before the fetch and set `redirect: \"manual\"` on `fetchConfig`, matching the pattern in `outboundFetch.ts`:\n\n```typescript\nimport { blacklist } from \"@budibase/backend-core\"\n\nasync function fetchToken(config: { url: string; /* ... */ }) {\n config = await processEnvironmentVariable(config)\n if (await blacklist.isBlacklisted(config.url)) {\n throw new Error(\"OAuth2 token URL is blocked.\")\n }\n const fetchConfig: RequestInit = {\n method: \"POST\",\n headers: { \"Content-Type\": \"application/x-www-form-urlencoded\" },\n body: new URLSearchParams({ grant_type: \"client_credentials\" }),\n redirect: \"manual\",\n }\n // ...\n}\n```\n\nAlternatively, replace the `fetch` call with `fetchWithBlacklist`, which handles both checks and re-validates redirect targets.\n\n---\n*Found by [aisafe.io](https://aisafe.io)*",
"id": "GHSA-4q6h-8p4v-67vq",
"modified": "2026-06-22T22:45:35Z",
"published": "2026-06-22T22:45:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Budibase/budibase/security/advisories/GHSA-4q6h-8p4v-67vq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48153"
},
{
"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: SSRF via OAuth2 token endpoint URL reaches internal hosts and cloud metadata"
}
GHSA-4QQR-VV2Q-CMR5
Vulnerability from github – Published: 2026-06-16 21:00 – Updated: 2026-07-20 21:12Summary
The Docker API server's SSRF protection (validate_webhook_url / validate_url_destination in deploy/docker/utils.py) used an explicit IPv4/IPv6 CIDR blocklist that missed several address families. An attacker could reach internal services and cloud metadata endpoints (e.g. 169.254.169.254) despite the filter by encoding an internal IPv4 address inside an IPv6 transition form, or by using the IPv6 unspecified address.
Because the Docker API is unauthenticated by default (jwt_enabled: false), no credentials are required.
Affected paths
The blocklist was applied to crawl URLs (POST /crawl, /md, /html, /screenshot, /pdf, /execute_js) and webhook URLs (/crawl/job, /llm/job). All shared the same incomplete check.
Bypasses
The following all resolve to (or route to) blocked internal addresses but were NOT caught:
- IPv6 unspecified ::
- NAT64 64:ff9b::a9fe:a9fe (embeds 169.254.169.254)
- 6to4 2002:a9fe:a9fe:: (embeds 169.254.169.254)
- IPv4-mapped ::ffff:169.254.169.254
- IPv4-compatible ::a9fe:a9fe
The error message also echoed the resolved internal IP, acting as a minor DNS/oracle leak.
Impact
Server-Side Request Forgery: an unauthenticated attacker can make the server fetch internal-network URLs and cloud instance-metadata endpoints, potentially exposing internal services and cloud credentials.
Fix
The blocklist is replaced by a single rule: reject any resolved IP where not ip.is_global, evaluated on the address AND every embedded IPv4 transition form (v4-mapped, NAT64 64:ff9b::/96, 6to4 2002::/16, v4-compat ::/96). Error messages are now opaque and no longer echo the resolved IP.
Workarounds
- Upgrade to the patched version.
- Enable authentication (
CRAWL4AI_API_TOKEN). - Restrict the container's outbound network access (egress firewall / no metadata route).
Credits
Internal security audit (Crawl4AI maintainers).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.8.7"
},
"package": {
"ecosystem": "PyPI",
"name": "crawl4ai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53754"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-16T21:00:04Z",
"nvd_published_at": "2026-06-23T19:17:07Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe Docker API server\u0027s SSRF protection (`validate_webhook_url` / `validate_url_destination` in `deploy/docker/utils.py`) used an explicit IPv4/IPv6 CIDR blocklist that missed several address families. An attacker could reach internal services and cloud metadata endpoints (e.g. `169.254.169.254`) despite the filter by encoding an internal IPv4 address inside an IPv6 transition form, or by using the IPv6 unspecified address.\n\nBecause the Docker API is unauthenticated by default (`jwt_enabled: false`), no credentials are required.\n\n### Affected paths\n\nThe blocklist was applied to crawl URLs (`POST /crawl`, `/md`, `/html`, `/screenshot`, `/pdf`, `/execute_js`) and webhook URLs (`/crawl/job`, `/llm/job`). All shared the same incomplete check.\n\n### Bypasses\n\nThe following all resolve to (or route to) blocked internal addresses but were NOT caught:\n- IPv6 unspecified `::`\n- NAT64 `64:ff9b::a9fe:a9fe` (embeds `169.254.169.254`)\n- 6to4 `2002:a9fe:a9fe::` (embeds `169.254.169.254`)\n- IPv4-mapped `::ffff:169.254.169.254`\n- IPv4-compatible `::a9fe:a9fe`\n\nThe error message also echoed the resolved internal IP, acting as a minor DNS/oracle leak.\n\n### Impact\n\nServer-Side Request Forgery: an unauthenticated attacker can make the server fetch internal-network URLs and cloud instance-metadata endpoints, potentially exposing internal services and cloud credentials.\n\n### Fix\n\nThe blocklist is replaced by a single rule: reject any resolved IP where `not ip.is_global`, evaluated on the address AND every embedded IPv4 transition form (v4-mapped, NAT64 `64:ff9b::/96`, 6to4 `2002::/16`, v4-compat `::/96`). Error messages are now opaque and no longer echo the resolved IP.\n\n### Workarounds\n\n- Upgrade to the patched version.\n- Enable authentication (`CRAWL4AI_API_TOKEN`).\n- Restrict the container\u0027s outbound network access (egress firewall / no metadata route).\n\n### Credits\n\nInternal security audit (Crawl4AI maintainers).",
"id": "GHSA-4qqr-vv2q-cmr5",
"modified": "2026-07-20T21:12:00Z",
"published": "2026-06-16T21:00:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/unclecode/crawl4ai/security/advisories/GHSA-4qqr-vv2q-cmr5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53754"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/crawl4ai/PYSEC-2026-587.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/unclecode/crawl4ai"
}
],
"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": "Crawl4AI: SSRF filter bypass in Docker server via IPv6 transition forms (NAT64 / 6to4 / unspecified / v4-mapped)"
}
GHSA-4R5R-P2HF-QWWW
Vulnerability from github – Published: 2026-01-22 18:30 – Updated: 2026-01-27 00:31Server-Side Request Forgery (SSRF) vulnerability in SmartDataSoft Pool Services pool-services allows Server Side Request Forgery.This issue affects Pool Services: from n/a through <= 3.3.
{
"affected": [],
"aliases": [
"CVE-2025-62741"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-22T17:15:59Z",
"severity": "CRITICAL"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in SmartDataSoft Pool Services pool-services allows Server Side Request Forgery.This issue affects Pool Services: from n/a through \u003c= 3.3.",
"id": "GHSA-4r5r-p2hf-qwww",
"modified": "2026-01-27T00:31:10Z",
"published": "2026-01-22T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62741"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Theme/pool-services/vulnerability/wordpress-pool-services-theme-3-3-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4R8V-7F5Q-9MR7
Vulnerability from github – Published: 2026-09-15 21:31 – Updated: 2026-09-15 21:31Vulnerabilities in the API of EdgeConnect SD-WAN Orchestrator could allow a remote attacker authenticated with low privileges to conduct server-side request forgery (SSRF) attacks. A successful exploit allows an attacker to enumerate information about the internal structure of the EdgeConnect SD-WAN Orchestrator host leading to potential disclosure of sensitive information beyond what is authorized by the user's existing privilege level.
{
"affected": [],
"aliases": [
"CVE-2026-76680"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-15T20:17:49Z",
"severity": "HIGH"
},
"details": "Vulnerabilities in the API of EdgeConnect SD-WAN Orchestrator could allow a remote attacker authenticated with low privileges to conduct server-side request forgery (SSRF) attacks. A successful exploit allows an attacker to enumerate information about the internal structure of the EdgeConnect SD-WAN Orchestrator host leading to potential disclosure of sensitive information beyond what is authorized by the user\u0027s existing privilege level.",
"id": "GHSA-4r8v-7f5q-9mr7",
"modified": "2026-09-15T21:31:35Z",
"published": "2026-09-15T21:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76680"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw05135en_us\u0026docLocale=en_US"
}
],
"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"
}
]
}
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.