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.

4601 vulnerabilities reference this CWE, most recent first.

GHSA-XW9Q-2MV6-9FR8

Vulnerability from github – Published: 2026-07-14 18:15 – Updated: 2026-07-14 18:15
VLAI
Summary
Fedify has an incomplete SSRF mitigation after GHSA-p9cg-vqcc-grcx: validatePublicUrl allows special-use IPv4 ranges
Details

Summary

Fedify previously addressed SSRF/internal network access in GHSA-p9cg-vqcc-grcx by adding public URL validation before runtime document and media fetching. However, the current IPv4 validation logic appears incomplete.

The validatePublicUrl() protection relies on isValidPublicIPv4Address() to reject non-public IPv4 destinations. The function blocks common private and local ranges such as 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, and 192.168.0.0/16, but it still treats several special-use, reserved, multicast, benchmarking, and carrier-grade NAT IPv4 ranges as valid public destinations.

Because this validation is used as an SSRF defense before outbound fetches, this appears to be an incomplete mitigation or bypass class for the previous SSRF issue.

I tested this against the current repository code at unreleased version 2.3.0. I used >=0.11.2, <=2.2.3 as the suspected affected range because 0.11.2 is listed as a patched version for GHSA-p9cg-vqcc-grcx, and this report concerns the post-fix validation logic. Maintainers may adjust the exact affected range.

Why this is not a duplicate of GHSA-p9cg-vqcc-grcx

GHSA-p9cg-vqcc-grcx covered the original behavior where Fedify fetched ActivityPub object, activity, document, and media URLs without first ensuring that the resolved destination was public.

This report is about the post-fix validation logic. The current mitigation now performs public URL/IP validation, but the IPv4 classification is incomplete and still treats several special-use ranges as public. Therefore, this is a potential incomplete fix/bypass of the previous SSRF mitigation rather than a re-report of the original issue.

The affected behavior appears to exist in the patched/current code path, not only in versions listed as vulnerable in the original advisory.

Affected Code

Affected file:

packages/vocab-runtime/src/url.ts

Current IPv4 validation logic:

export function isValidPublicIPv4Address(address: string): boolean {
  const parts = address.split(".");
  const first = parseInt(parts[0]);
  if (first === 0 || first === 10 || first === 127) return false;
  const second = parseInt(parts[1]);
  if (first === 169 && second === 254) return false;
  if (first === 172 && second >= 16 && second <= 31) return false;
  if (first === 192 && second === 168) return false;
  return true;
}

The important point is that the bypass exists in the mitigation logic itself: the function responsible for deciding whether a destination is public returns true for address ranges that are not globally routable public internet destinations.

Proof of Concept

I reproduced the IPv4 validation behavior using the same logic:

function isValidPublicIPv4Address(address) {
  const parts = address.split(".");
  const first = parseInt(parts[0], 10);
  if (first === 0 || first === 10 || first === 127) return false;

  const second = parseInt(parts[1], 10);
  if (first === 169 && second === 254) return false;
  if (first === 172 && second >= 16 && second <= 31) return false;
  if (first === 192 && second === 168) return false;

  return true;
}

const tests = [
  "8.8.8.8",
  "127.0.0.1",
  "10.0.0.1",
  "192.168.1.1",
  "169.254.169.254",
  "100.64.0.1",
  "198.18.0.1",
  "224.0.0.1",
  "240.0.0.1",
  "192.0.0.1",
  "192.0.2.1",
  "198.51.100.1",
  "203.0.113.1"
];

for (const ip of tests) {
  console.log(ip + " => " + isValidPublicIPv4Address(ip));
}

Observed output:

8.8.8.8 => true
127.0.0.1 => false
10.0.0.1 => false
192.168.1.1 => false
169.254.169.254 => false
100.64.0.1 => true
198.18.0.1 => true
224.0.0.1 => true
240.0.0.1 => true
192.0.0.1 => true
192.0.2.1 => true
198.51.100.1 => true
203.0.113.1 => true

The validator correctly blocks some common private and local ranges, but incorrectly allows multiple special-use ranges.

Examples of incorrectly allowed ranges

Important examples include:

100.64.0.0/10 Carrier-grade NAT
198.18.0.0/15 Benchmarking / internal testing networks
224.0.0.0/4 Multicast
240.0.0.0/4 Reserved
192.0.0.0/24 IETF protocol assignments

Additional correctness examples:

192.0.2.0/24 Documentation range
198.51.100.0/24 Documentation range
203.0.113.0/24 Documentation range

Security Impact

Any Fedify feature that accepts or processes remote ActivityPub object, activity, document, or media URLs and relies on validatePublicUrl() as an SSRF protection boundary may incorrectly allow outbound requests to special-use IPv4 destinations that should not be treated as public internet resources.

This may allow an attacker-controlled ActivityPub object or media URL to cause a Fedify server to initiate requests to non-public or special-use network ranges, depending on the deployment environment and network routing.

This is best understood as an incomplete fix/bypass class for the previous SSRF/internal-network-access advisory GHSA-p9cg-vqcc-grcx.

Suggested Fix

Avoid using a small manual denylist for public IP validation. Instead, validate that the resolved address is globally routable/public.

At minimum, IPv4 validation should reject all relevant special-use ranges, including:

0.0.0.0/8
10.0.0.0/8
100.64.0.0/10
127.0.0.0/8
169.254.0.0/16
172.16.0.0/12
192.0.0.0/24
192.0.2.0/24
192.168.0.0/16
198.18.0.0/15
198.51.100.0/24
203.0.113.0/24
224.0.0.0/4
240.0.0.0/4

A safer long-term fix would be to use a maintained IP address classification library that explicitly supports security-sensitive public/global IP validation.

Patch Idea

export function isValidPublicIPv4Address(address: string): boolean {
  const parts = address.split(".").map((part) => parseInt(part, 10));

  if (
    parts.length !== 4 ||
    parts.some((part) => Number.isNaN(part) || part < 0 || part > 255)
  ) {
    return false;
  }

  const [a, b] = parts;

  if (a === 0) return false;
  if (a === 10) return false;
  if (a === 100 && b >= 64 && b <= 127) return false;
  if (a === 127) return false;
  if (a === 169 && b === 254) return false;
  if (a === 172 && b >= 16 && b <= 31) return false;
  if (a === 192 && b === 0) return false;
  if (a === 192 && b === 168) return false;
  if (a === 198 && (b === 18 || b === 19)) return false;
  if (a === 198 && b === 51) return false;
  if (a === 203 && b === 0) return false;
  if (a >= 224) return false;

  return true;
}

Advisory Classification Note

I understand this may be classified either as a new advisory or as an update/incomplete fix for GHSA-p9cg-vqcc-grcx. Since the issue appears to affect the validation logic added after the original SSRF fix, and because the affected code is part of the current security boundary for outbound URL fetching, I wanted to report it privately for maintainer review.

Disclosure Note

This report does not attempt to access any real internal network service. The proof focuses on the validation decision itself: multiple non-public or special-use IPv4 ranges are accepted as public by the current SSRF protection logic.

Researcher

Reported by Chaitanya Garware.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.11.2"
            },
            {
              "fixed": "1.9.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.10.0"
            },
            {
              "fixed": "1.10.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/vocab-runtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/vocab-runtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/vocab-runtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50131"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918",
      "CWE-1286",
      "CWE-1389"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T18:15:25Z",
    "nvd_published_at": "2026-06-10T22:17:01Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nFedify previously addressed SSRF/internal network access in GHSA-p9cg-vqcc-grcx by adding public URL validation before runtime document and media fetching. However, the current IPv4 validation logic appears incomplete.\n\nThe `validatePublicUrl()` protection relies on `isValidPublicIPv4Address()` to reject non-public IPv4 destinations. The function blocks common private and local ranges such as `10.0.0.0/8`, `127.0.0.0/8`, `169.254.0.0/16`, `172.16.0.0/12`, and `192.168.0.0/16`, but it still treats several special-use, reserved, multicast, benchmarking, and carrier-grade NAT IPv4 ranges as valid public destinations.\n\nBecause this validation is used as an SSRF defense before outbound fetches, this appears to be an incomplete mitigation or bypass class for the previous SSRF issue.\n\nI tested this against the current repository code at unreleased version 2.3.0. I used `\u003e=0.11.2, \u003c=2.2.3` as the suspected affected range because 0.11.2 is listed as a patched version for GHSA-p9cg-vqcc-grcx, and this report concerns the post-fix validation logic. Maintainers may adjust the exact affected range.\n\n### Why this is not a duplicate of GHSA-p9cg-vqcc-grcx\n\nGHSA-p9cg-vqcc-grcx covered the original behavior where Fedify fetched ActivityPub object, activity, document, and media URLs without first ensuring that the resolved destination was public.\n\nThis report is about the post-fix validation logic. The current mitigation now performs public URL/IP validation, but the IPv4 classification is incomplete and still treats several special-use ranges as public. Therefore, this is a potential incomplete fix/bypass of the previous SSRF mitigation rather than a re-report of the original issue.\n\nThe affected behavior appears to exist in the patched/current code path, not only in versions listed as vulnerable in the original advisory.\n\n### Affected Code\n\nAffected file:\n\n`packages/vocab-runtime/src/url.ts`\n\nCurrent IPv4 validation logic:\n\n```ts\nexport function isValidPublicIPv4Address(address: string): boolean {\n  const parts = address.split(\".\");\n  const first = parseInt(parts[0]);\n  if (first === 0 || first === 10 || first === 127) return false;\n  const second = parseInt(parts[1]);\n  if (first === 169 \u0026\u0026 second === 254) return false;\n  if (first === 172 \u0026\u0026 second \u003e= 16 \u0026\u0026 second \u003c= 31) return false;\n  if (first === 192 \u0026\u0026 second === 168) return false;\n  return true;\n}\n```\n\nThe important point is that the bypass exists in the mitigation logic itself: the function responsible for deciding whether a destination is public returns true for address ranges that are not globally routable public internet destinations.\n\n### Proof of Concept\n\nI reproduced the IPv4 validation behavior using the same logic:\n\n```ts\nfunction isValidPublicIPv4Address(address) {\n  const parts = address.split(\".\");\n  const first = parseInt(parts[0], 10);\n  if (first === 0 || first === 10 || first === 127) return false;\n\n  const second = parseInt(parts[1], 10);\n  if (first === 169 \u0026\u0026 second === 254) return false;\n  if (first === 172 \u0026\u0026 second \u003e= 16 \u0026\u0026 second \u003c= 31) return false;\n  if (first === 192 \u0026\u0026 second === 168) return false;\n\n  return true;\n}\n\nconst tests = [\n  \"8.8.8.8\",\n  \"127.0.0.1\",\n  \"10.0.0.1\",\n  \"192.168.1.1\",\n  \"169.254.169.254\",\n  \"100.64.0.1\",\n  \"198.18.0.1\",\n  \"224.0.0.1\",\n  \"240.0.0.1\",\n  \"192.0.0.1\",\n  \"192.0.2.1\",\n  \"198.51.100.1\",\n  \"203.0.113.1\"\n];\n\nfor (const ip of tests) {\n  console.log(ip + \" =\u003e \" + isValidPublicIPv4Address(ip));\n}\n```\n\nObserved output:\n\n```\n8.8.8.8 =\u003e true\n127.0.0.1 =\u003e false\n10.0.0.1 =\u003e false\n192.168.1.1 =\u003e false\n169.254.169.254 =\u003e false\n100.64.0.1 =\u003e true\n198.18.0.1 =\u003e true\n224.0.0.1 =\u003e true\n240.0.0.1 =\u003e true\n192.0.0.1 =\u003e true\n192.0.2.1 =\u003e true\n198.51.100.1 =\u003e true\n203.0.113.1 =\u003e true\n```\n\nThe validator correctly blocks some common private and local ranges, but incorrectly allows multiple special-use ranges.\n\n### Examples of incorrectly allowed ranges\n\nImportant examples include:\n\n```\n100.64.0.0/10 Carrier-grade NAT\n198.18.0.0/15 Benchmarking / internal testing networks\n224.0.0.0/4 Multicast\n240.0.0.0/4 Reserved\n192.0.0.0/24 IETF protocol assignments\n```\n\nAdditional correctness examples:\n\n```\n192.0.2.0/24 Documentation range\n198.51.100.0/24 Documentation range\n203.0.113.0/24 Documentation range\n```\n\n## Security Impact\n\nAny Fedify feature that accepts or processes remote ActivityPub object, activity, document, or media URLs and relies on validatePublicUrl() as an SSRF protection boundary may incorrectly allow outbound requests to special-use IPv4 destinations that should not be treated as public internet resources.\n\nThis may allow an attacker-controlled ActivityPub object or media URL to cause a Fedify server to initiate requests to non-public or special-use network ranges, depending on the deployment environment and network routing.\n\nThis is best understood as an incomplete fix/bypass class for the previous SSRF/internal-network-access advisory GHSA-p9cg-vqcc-grcx.\n\n## Suggested Fix\n\nAvoid using a small manual denylist for public IP validation. Instead, validate that the resolved address is globally routable/public.\n\nAt minimum, IPv4 validation should reject all relevant special-use ranges, including:\n\n```\n0.0.0.0/8\n10.0.0.0/8\n100.64.0.0/10\n127.0.0.0/8\n169.254.0.0/16\n172.16.0.0/12\n192.0.0.0/24\n192.0.2.0/24\n192.168.0.0/16\n198.18.0.0/15\n198.51.100.0/24\n203.0.113.0/24\n224.0.0.0/4\n240.0.0.0/4\n```\n\nA safer long-term fix would be to use a maintained IP address classification library that explicitly supports security-sensitive public/global IP validation.\n\nPatch Idea\n\n```ts\nexport function isValidPublicIPv4Address(address: string): boolean {\n  const parts = address.split(\".\").map((part) =\u003e parseInt(part, 10));\n\n  if (\n    parts.length !== 4 ||\n    parts.some((part) =\u003e Number.isNaN(part) || part \u003c 0 || part \u003e 255)\n  ) {\n    return false;\n  }\n\n  const [a, b] = parts;\n\n  if (a === 0) return false;\n  if (a === 10) return false;\n  if (a === 100 \u0026\u0026 b \u003e= 64 \u0026\u0026 b \u003c= 127) return false;\n  if (a === 127) return false;\n  if (a === 169 \u0026\u0026 b === 254) return false;\n  if (a === 172 \u0026\u0026 b \u003e= 16 \u0026\u0026 b \u003c= 31) return false;\n  if (a === 192 \u0026\u0026 b === 0) return false;\n  if (a === 192 \u0026\u0026 b === 168) return false;\n  if (a === 198 \u0026\u0026 (b === 18 || b === 19)) return false;\n  if (a === 198 \u0026\u0026 b === 51) return false;\n  if (a === 203 \u0026\u0026 b === 0) return false;\n  if (a \u003e= 224) return false;\n\n  return true;\n}\n```\n\n\n## Advisory Classification Note\n\nI understand this may be classified either as a new advisory or as an update/incomplete fix for GHSA-p9cg-vqcc-grcx. Since the issue appears to affect the validation logic added after the original SSRF fix, and because the affected code is part of the current security boundary for outbound URL fetching, I wanted to report it privately for maintainer review.\n\n## Disclosure Note\n\nThis report does not attempt to access any real internal network service. The proof focuses on the validation decision itself: multiple non-public or special-use IPv4 ranges are accepted as public by the current SSRF protection logic.\n\n\n\n## Researcher\n\nReported by Chaitanya Garware.",
  "id": "GHSA-xw9q-2mv6-9fr8",
  "modified": "2026-07-14T18:15:25Z",
  "published": "2026-07-14T18:15:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fedify-dev/fedify/security/advisories/GHSA-xw9q-2mv6-9fr8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50131"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fedify-dev/fedify"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fedify has an incomplete SSRF mitigation after GHSA-p9cg-vqcc-grcx: validatePublicUrl allows special-use IPv4 ranges"
}

GHSA-XWH2-742G-W3WP

Vulnerability from github – Published: 2026-01-07 19:22 – Updated: 2026-01-08 21:19
VLAI
Summary
Miniflux Media Proxy SSRF via /proxy endpoint allows access to internal network resources
Details

Summary

Miniflux's media proxy endpoint (GET /proxy/{encodedDigest}/{encodedURL}) can be abused to perform Server-Side Request Forgery (SSRF). An authenticated user can cause Miniflux to generate a signed proxy URL for attacker-chosen media URLs embedded in feed entry content, including internal addresses (e.g., localhost, private RFC1918 ranges, or link-local metadata endpoints). Requesting the resulting /proxy/... URL makes Miniflux fetch and return the internal response.

Details

  • Vulnerable route: GET /proxy/{encodedDigest}/{encodedURL} (accessible without authentication, but requires a server-generated HMAC-signed URL)
  • Handler: internal/ui/proxy.go ((*handler).mediaProxy)
  • Trigger: entry content is rewritten to proxy media URLs (e.g., mediaproxy.RewriteDocumentWithAbsoluteProxyURL(...)), producing signed /proxy/... URLs.
  • Root cause: the proxy validates the URL scheme and HMAC signature, but does not restrict target hosts/IPs. As a result, requests to loopback/private/link-local addresses are allowed and fetched by the server.

PoC

1) Run Miniflux 2.2.15 with default configuration (media proxy enabled by default: MEDIA_PROXY_MODE=http-only).

2) Log in with any normal user account.

3) Subscribe to a feed you control that contains an entry with an image URL pointing to an internal address reachable from the Miniflux server, e.g.: - <img src="http://<internal-target>/secret"> (Note: <internal-target> must be reachable from the Miniflux process/network; in containerized setups, 127.0.0.1 may not refer to the host.)

4) Open the entry and locate the rewritten media proxy URL (/proxy/<encodedDigest>/<encodedURL>) in the rendered HTML/page source.

5) Request the /proxy/... URL. Expected (vulnerable): Miniflux fetches the internal URL and returns the internal response (SSRF).

Impact

Type: SSRF (Server-Side Request Forgery) via media proxy
Who is impacted: Miniflux instances with media proxy enabled (default configuration typically enables it for HTTP/mixed content handling).
Impact: attackers with a valid Miniflux account can fetch internal resources reachable from the Miniflux server (e.g., localhost services, private network services, and link-local endpoints such as 169.254.169.254), potentially exposing sensitive data.

Suggested CVSS (v3.1)

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (Base 6.5)

If there any questions or issues reproducing this, please contact: jeongwoolee340@gmail.com

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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.2.15"
      },
      "package": {
        "ecosystem": "Go",
        "name": "miniflux.app/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-21885"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-07T19:22:14Z",
    "nvd_published_at": "2026-01-08T14:15:57Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nMiniflux\u0027s media proxy endpoint (`GET /proxy/{encodedDigest}/{encodedURL}`) can be abused to perform Server-Side Request Forgery (SSRF). An authenticated user can cause Miniflux to generate a signed proxy URL for attacker-chosen media URLs embedded in feed entry content, including internal addresses (e.g., localhost, private RFC1918 ranges, or link-local metadata endpoints). Requesting the resulting `/proxy/...` URL makes Miniflux fetch and return the internal response.\n\n### Details\n- **Vulnerable route**: `GET /proxy/{encodedDigest}/{encodedURL}` (accessible without authentication, but requires a server-generated HMAC-signed URL)\n- **Handler**: `internal/ui/proxy.go` (`(*handler).mediaProxy`)\n- **Trigger**: entry content is rewritten to proxy media URLs (e.g., `mediaproxy.RewriteDocumentWithAbsoluteProxyURL(...)`), producing signed `/proxy/...` URLs.\n- **Root cause**: the proxy validates the URL scheme and HMAC signature, but does not restrict target hosts/IPs. As a result, requests to loopback/private/link-local addresses are allowed and fetched by the server.\n\n### PoC\n1) Run Miniflux 2.2.15 with default configuration (media proxy enabled by default: `MEDIA_PROXY_MODE=http-only`).\n\n2) Log in with any normal user account.\n\n3) Subscribe to a feed you control that contains an entry with an image URL pointing to an internal address reachable from the Miniflux server, e.g.:\n   - `\u003cimg src=\"http://\u003cinternal-target\u003e/secret\"\u003e`\n   (Note: `\u003cinternal-target\u003e` must be reachable *from the Miniflux process/network*; in containerized setups, `127.0.0.1` may not refer to the host.)\n\n4) Open the entry and locate the rewritten media proxy URL (`/proxy/\u003cencodedDigest\u003e/\u003cencodedURL\u003e`) in the rendered HTML/page source.\n\n5) Request the `/proxy/...` URL.\nExpected (vulnerable): Miniflux fetches the internal URL and returns the internal response (SSRF).\n\n### Impact\n**Type**: SSRF (Server-Side Request Forgery) via media proxy  \n**Who is impacted**: Miniflux instances with media proxy enabled (default configuration typically enables it for HTTP/mixed content handling).  \n**Impact**: attackers with a valid Miniflux account can fetch internal resources reachable from the Miniflux server (e.g., localhost services, private network services, and link-local endpoints such as 169.254.169.254), potentially exposing sensitive data.\n\n### Suggested CVSS (v3.1)\n`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N` (Base 6.5)\n\n\n\n\nIf there any questions or issues reproducing this, please contact: jeongwoolee340@gmail.com",
  "id": "GHSA-xwh2-742g-w3wp",
  "modified": "2026-01-08T21:19:09Z",
  "published": "2026-01-07T19:22:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/miniflux/v2/security/advisories/GHSA-xwh2-742g-w3wp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21885"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/miniflux/v2"
    }
  ],
  "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"
    }
  ],
  "summary": "Miniflux Media Proxy SSRF via /proxy endpoint allows access to internal network resources"
}

GHSA-XWH3-29C4-3Q7H

Vulnerability from github – Published: 2025-08-05 00:30 – Updated: 2025-08-05 00:30
VLAI
Details

A vulnerability was found in Exrick xboot up to 3.3.4. It has been rated as critical. This issue affects some unknown processing of the file xboot-fast/src/main/java/cn/exrick/xboot/modules/base/controller/common/SecurityController.java of the component Swagger. The manipulation of the argument loginUrl leads to server-side request forgery. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-8527"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-04T22:15:29Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in Exrick xboot up to 3.3.4. It has been rated as critical. This issue affects some unknown processing of the file xboot-fast/src/main/java/cn/exrick/xboot/modules/base/controller/common/SecurityController.java of the component Swagger. The manipulation of the argument loginUrl leads to server-side request forgery. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.",
  "id": "GHSA-xwh3-29c4-3q7h",
  "modified": "2025-08-05T00:30:26Z",
  "published": "2025-08-05T00:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8527"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Exrick/xboot/issues/70"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Exrick/xboot/issues/70#issue-3252425972"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.318653"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.318653"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.622174"
    }
  ],
  "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-XWHW-2Q44-QW48

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

OX App Suite through 7.10.4 allows SSRF via a URL with an @ character in an appsuite/api/oauth/proxy PUT request.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-23927"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-12T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "OX App Suite through 7.10.4 allows SSRF via a URL with an @ character in an appsuite/api/oauth/proxy PUT request.",
  "id": "GHSA-xwhw-2q44-qw48",
  "modified": "2022-05-24T17:38:56Z",
  "published": "2022-05-24T17:38:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23927"
    },
    {
      "type": "WEB",
      "url": "https://packetstormsecurity.com/files/160853/OX-App-Suite-OX-Documents-7.10.x-XSS-SSRF.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XWV8-8669-GWR6

Vulnerability from github – Published: 2022-05-14 02:19 – Updated: 2022-05-14 02:19
VLAI
Details

An issue was discovered in SeaCMS 6.61. adm1n/admin_reslib.php has SSRF via the url parameter.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-16444"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-09-04T04:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in SeaCMS 6.61. adm1n/admin_reslib.php has SSRF via the url parameter.",
  "id": "GHSA-xwv8-8669-gwr6",
  "modified": "2022-05-14T02:19:18Z",
  "published": "2022-05-14T02:19:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16444"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MichaelWayneLIU/seacms/blob/master/seacms3.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XX3M-2JCF-FRFQ

Vulnerability from github – Published: 2023-11-03 03:30 – Updated: 2023-11-03 03:30
VLAI
Details

IBM Content Navigator 3.0.13 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. IBM X-Force ID: 259247.

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-2023-35896"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-03T03:15:07Z",
    "severity": "MODERATE"
  },
  "details": "IBM Content Navigator 3.0.13 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.  IBM X-Force ID:  259247.",
  "id": "GHSA-xx3m-2jcf-frfq",
  "modified": "2023-11-03T03:30:24Z",
  "published": "2023-11-03T03:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35896"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/259247"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7065203"
    }
  ],
  "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-XX75-4FHF-JF2W

Vulnerability from github – Published: 2026-06-29 18:31 – Updated: 2026-06-29 18:31
VLAI
Details

Pinpoint through 3.1.0 contains a server-side request forgery vulnerability in the webhook registration endpoint that allows authenticated users to register internal URLs due to missing SSRF protection. Attackers can trigger alarm threshold breaches to force the server to issue POST requests to internal hosts and metadata endpoints, enabling unauthorized access to internal network resources.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-57947"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-29T18:16:39Z",
    "severity": "MODERATE"
  },
  "details": "Pinpoint through 3.1.0 contains a server-side request forgery vulnerability in the webhook registration endpoint that allows authenticated users to register internal URLs due to missing SSRF protection. Attackers can trigger alarm threshold breaches to force the server to issue POST requests to internal hosts and metadata endpoints, enabling unauthorized access to internal network resources.",
  "id": "GHSA-xx75-4fhf-jf2w",
  "modified": "2026-06-29T18:31:56Z",
  "published": "2026-06-29T18:31:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57947"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pinpoint-apm/pinpoint/issues/13857"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/pinpoint-server-side-request-forgery-via-alarm-webhook-registration"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:H/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-XXCQ-47CQ-JXJH

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

A restriction bypass vulnerability in is-localhost-ip could allow attackers to perform Server-Side Request Forgery (SSRF). This issue affects is-localhost-ip: 2.0.0.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-9960"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-22T19:16:28Z",
    "severity": "MODERATE"
  },
  "details": "A restriction bypass vulnerability in is-localhost-ip could allow attackers to perform Server-Side Request Forgery (SSRF).\nThis issue affects is-localhost-ip: 2.0.0.",
  "id": "GHSA-xxcq-47cq-jxjh",
  "modified": "2025-09-22T21:30:29Z",
  "published": "2025-09-22T21:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9960"
    },
    {
      "type": "WEB",
      "url": "https://fluidattacks.com/advisories/registrada"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinovyatkin/is-localhost-ip"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-XXMG-WVH2-Q23Q

Vulnerability from github – Published: 2024-08-13 06:30 – Updated: 2024-08-13 06:30
VLAI
Details

SAP CRM ABAP (Insights Management) allows an authenticated attacker to enumerate HTTP endpoints in the internal network by specially crafting HTTP requests. On successful exploitation this can result in information disclosure. It has no impact on integrity and availability of the application.

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": [],
  "aliases": [
    "CVE-2024-41737"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-13T04:15:10Z",
    "severity": "MODERATE"
  },
  "details": "SAP CRM ABAP (Insights\nManagement) allows an authenticated attacker to enumerate HTTP endpoints in the\ninternal network by specially crafting HTTP requests. On successful\nexploitation this can result in information disclosure. It has no impact on\nintegrity and availability of the application.",
  "id": "GHSA-xxmg-wvh2-q23q",
  "modified": "2024-08-13T06:30:47Z",
  "published": "2024-08-13T06:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41737"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3487537"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "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"
    }
  ]
}

GHSA-XXP4-MF4H-6CWM

Vulnerability from github – Published: 2023-06-22 21:30 – Updated: 2024-04-19 16:22
VLAI
Summary
Moodle vulnerable to Server Side Request Forgery
Details

An issue in the logic used to check 0.0.0.0 against the cURL blocked hosts lists resulted in an SSRF risk. This flaw affects Moodle versions 4.2, 4.1 to 4.1.3, 4.0 to 4.0.8, 3.11 to 3.11.14, 3.9 to 3.9.21 and earlier unsupported versions.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0"
            },
            {
              "fixed": "4.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "4.2.0"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.0"
            },
            {
              "fixed": "4.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.10.0"
            },
            {
              "fixed": "3.11.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.9.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-35133"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-06-23T21:38:44Z",
    "nvd_published_at": "2023-06-22T21:15:09Z",
    "severity": "HIGH"
  },
  "details": "An issue in the logic used to check 0.0.0.0 against the cURL blocked hosts lists resulted in an SSRF risk. This flaw affects Moodle versions 4.2, 4.1 to 4.1.3, 4.0 to 4.0.8, 3.11 to 3.11.14, 3.9 to 3.9.21 and earlier unsupported versions.",
  "id": "GHSA-xxp4-mf4h-6cwm",
  "modified": "2024-04-19T16:22:21Z",
  "published": "2023-06-22T21:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35133"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2214373"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moodle/moodle"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/7A72KX4WU6GK2CX4TKYFGFASPKOEOJFC"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5QAEAGJ44NVXLAJFJXKARKC45OGEDXT"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7A72KX4WU6GK2CX4TKYFGFASPKOEOJFC"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/I5QAEAGJ44NVXLAJFJXKARKC45OGEDXT"
    },
    {
      "type": "WEB",
      "url": "https://moodle.org/mod/forum/discuss.php?d=447831"
    },
    {
      "type": "WEB",
      "url": "http://git.moodle.org/gw?p=moodle.git\u0026a=search\u0026h=HEAD\u0026st=commit\u0026s=MDL-78215"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Moodle vulnerable to Server Side Request Forgery"
}

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