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.

4628 vulnerabilities reference this CWE, most recent first.

GHSA-VGQ5-3255-V292

Vulnerability from github – Published: 2025-06-10 09:30 – Updated: 2025-06-10 20:41
VLAI
Summary
Apache Kafka Client Arbitrary File Read and Server Side Request Forgery Vulnerability
Details

A possible arbitrary file read and SSRF vulnerability has been identified in Apache Kafka Client. Apache Kafka Clients accept configuration data for setting the SASL/OAUTHBEARER connection with the brokers, including "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url". Apache Kafka allows clients to read an arbitrary file and return the content in the error log, or sending requests to an unintended location. In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use the "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url" configuratin to read arbitrary contents of the disk and environment variables or make requests to an unintended location. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment/URL access, which may be undesirable in certain environments, including SaaS products.

Since Apache Kafka 3.9.1/4.0.0, we have added a system property ("-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls") to set the allowed urls in SASL JAAS configuration. In 3.9.1, it accepts all urls by default for backward compatibility. However in 4.0.0 and newer, the default value is empty list and users have to set the allowed urls explicitly.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.kafka:kafka-clients"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.0"
            },
            {
              "fixed": "3.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27817"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-10T20:41:34Z",
    "nvd_published_at": "2025-06-10T08:15:22Z",
    "severity": "MODERATE"
  },
  "details": "A possible arbitrary file read and SSRF vulnerability has been identified in Apache Kafka Client. Apache Kafka Clients accept configuration data for setting the SASL/OAUTHBEARER connection with the brokers, including \"sasl.oauthbearer.token.endpoint.url\" and \"sasl.oauthbearer.jwks.endpoint.url\". Apache Kafka allows clients to read an arbitrary file and return the content in the error log, or sending requests to an unintended location. In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use the \"sasl.oauthbearer.token.endpoint.url\" and \"sasl.oauthbearer.jwks.endpoint.url\" configuratin to read arbitrary contents of the disk and environment variables or make requests to an unintended location. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment/URL access, which may be undesirable in certain environments, including SaaS products. \n\nSince Apache Kafka 3.9.1/4.0.0, we have added a system property (\"-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls\") to set the allowed urls in SASL JAAS configuration. In 3.9.1, it accepts all urls by default for backward compatibility. However in 4.0.0 and newer, the default value is empty list and users have to set the allowed urls explicitly.",
  "id": "GHSA-vgq5-3255-v292",
  "modified": "2025-06-10T20:41:35Z",
  "published": "2025-06-10T09:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27817"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/kafka"
    },
    {
      "type": "WEB",
      "url": "https://kafka.apache.org/cve-list"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/06/09/1"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Kafka Client Arbitrary File Read and Server Side Request Forgery Vulnerability"
}

GHSA-VGRC-HQ28-P3XP

Vulnerability from github – Published: 2026-06-26 19:48 – Updated: 2026-06-26 19:48
VLAI
Summary
Hysteria has an authenticated UDP ACL bypass that enables localhost and private-network UDP SSRF
Details

Summary

Hysteria's UDP relay treats the destination address as packet-scoped, but ACL and outbound policy are applied only once when a new UDP session is created. After an authenticated client opens a UDP session using an allowed first destination, later packets in the same Session ID can be sent to different destinations without re-running ACL evaluation.

This allows an authenticated user to bypass server-side UDP ACL rules and reach localhost or RFC1918/private-network UDP services from the server's network perspective, even when those destinations are explicitly rejected by ACL.

Verified on current HEAD at commit 64c396385631579598cc29d5561bff98c439772f.

Why this is a security issue

This report is not based on the assumption that one UDP session must be bound to one destination. The protocol and official client both support per-packet destinations:

  • PROTOCOL.md:93-107 defines each UDPMessage as carrying its own Addr field.
  • core/client/udp.go:52-62 exposes Send(data, addr), allowing the same UDP session to send to arbitrary addresses.

The problem is that the security-relevant destination is packet-scoped, while ACL and outbound authorization are cached at session scope.

This is also not a RequestHook-bypass claim. I understand RequestHook is first-packet-oriented. The broader issue is that operator-configured ACL policy intended to block UDP destinations is not enforced on later packets within the same session.

Because the ACL documentation is presented as the mechanism for handling or blocking client requests, and includes examples of denying udp/443 and private network CIDRs, operators can reasonably rely on ACL as a UDP egress security boundary. This boundary can currently be bypassed by reusing a previously authorized UDP session.

Root cause

The relevant flow appears to be:

  • core/server/udp.go:280-299: when a new session is created, the first destination is passed through m.io.Hook(...), logged, and then m.io.UDP(addr) is called once to create the outbound UDP connection.
  • core/server/server.go:397-398: m.io.UDP(addr) delegates to io.Outbound.UDP(reqAddr).
  • app/cmd/server.go:1187-1190: resolver, ACL, and actual outbounds are intentionally chained through the Outbound interface.
  • core/server/udp.go:125: the initial outbound connection is created only from the first packet via DialFunc(firstMsg.Addr, firstMsg.Data).
  • core/server/udp.go:92-111: later packets in the same session take the current packet address and directly call e.conn.WriteTo(dfMsg.Data, addr) without re-running ACL or outbound policy evaluation.

In other words, destination selection is packet-scoped, but authorization is session-scoped.

Impact

Any authenticated client that is allowed to use UDP relay can:

  • open one UDP session using an allowed first destination;
  • reuse the same session to send packets to destinations that ACL should reject;
  • reach UDP services on 127.0.0.1 or on RFC1918/private-network addresses from the server's network perspective.

In real deployments, this can expose internal-only UDP services such as:

  • internal DNS resolvers;
  • service discovery endpoints;
  • telemetry or metrics listeners;
  • local administrative daemons;
  • application-specific UDP services intended to be reachable only from localhost or the internal network.

This breaks the server's documented ACL-based UDP egress restrictions.

Reproduction

Two cases were reproduced with integration tests.

Case 1: localhost bypass

ACL:

direct(127.0.0.1, udp/<allowedPort>)
reject(127.0.0.1/32)

Steps:

  1. Start one UDP echo service on 127.0.0.1:<allowedPort>.
  2. Start another UDP echo service on 127.0.0.1:<blockedPort>.
  3. Connect an authenticated Hysteria client and create one UDP session.
  4. Send a packet to the allowed loopback destination to establish the session.
  5. Reuse the same UDP session and send a packet to the blocked loopback destination.

Observed result:

  • The second packet is relayed successfully and the blocked loopback service replies.

Expected result:

  • The second packet should be rejected because 127.0.0.1/32 is denied by ACL.

Case 2: private-network bypass

ACL:

direct(127.0.0.1, udp/<allowedPort>)
reject(10.0.0.0/8)

or the corresponding local RFC1918 range, such as 192.168.0.0/16 or 172.16.0.0/12.

Steps:

  1. Start one UDP echo service on 127.0.0.1:<allowedPort>.
  2. Start another UDP echo service on a real RFC1918 address of the server host.
  3. Connect an authenticated Hysteria client and create one UDP session.
  4. Send a packet to the allowed loopback destination first.
  5. Reuse the same UDP session and send a packet to the RFC1918 destination.

Observed result:

  • The private-address packet is relayed successfully and receives a reply.

Expected result:

  • The packet should be rejected by ACL.

PoC and local evidence

A local integration test file was added during verification:

  • core/internal/integration_tests/udp_private_acl_bypass_test.go

The two tests are:

  • TestClientServerUDPACLBYPASSLoopback
  • TestClientServerUDPACLBYPASSPrivateIPv4

They can be executed with:

go test ./core/internal/integration_tests -run 'TestClientServerUDPACLBYPASS(Loopback|PrivateIPv4)' -count=1

The tests pass locally and demonstrate that a destination blocked by ACL becomes reachable after the session is established with an allowed first destination.

Suggested fixes

Any of the following would address the issue:

  1. Re-evaluate ACL and outbound policy for every defragmented UDP packet before forwarding it with WriteTo.
  2. Alternatively, enforce a single immutable destination per UDP session and reject destination changes after the first packet.
  3. Ensure logging and policy hooks are aligned with the chosen model so that policy enforcement and observability reflect the real per-packet destination.

Severity assessment

Suggested CVSS v3.1 vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L

This reflects a network-reachable issue with low attack complexity, requiring only an authenticated client, no victim interaction, and allowing impact beyond the proxy process by exposing localhost and internal-network UDP resources from the server's trust boundary.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.9.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/apernet/hysteria/core/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.9.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T19:48:50Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nHysteria\u0027s UDP relay treats the destination address as packet-scoped, but ACL and outbound policy are applied only once when a new UDP session is created. After an authenticated client opens a UDP session using an allowed first destination, later packets in the same `Session ID` can be sent to different destinations without re-running ACL evaluation.\n\nThis allows an authenticated user to bypass server-side UDP ACL rules and reach localhost or RFC1918/private-network UDP services from the server\u0027s network perspective, even when those destinations are explicitly rejected by ACL.\n\nVerified on current HEAD at commit `64c396385631579598cc29d5561bff98c439772f`.\n\n## Why this is a security issue\n\nThis report is not based on the assumption that one UDP session must be bound to one destination. The protocol and official client both support per-packet destinations:\n\n- `PROTOCOL.md:93-107` defines each `UDPMessage` as carrying its own `Addr` field.\n- `core/client/udp.go:52-62` exposes `Send(data, addr)`, allowing the same UDP session to send to arbitrary addresses.\n\nThe problem is that the security-relevant destination is packet-scoped, while ACL and outbound authorization are cached at session scope.\n\nThis is also not a `RequestHook`-bypass claim. I understand `RequestHook` is first-packet-oriented. The broader issue is that operator-configured ACL policy intended to block UDP destinations is not enforced on later packets within the same session.\n\nBecause the ACL documentation is presented as the mechanism for handling or blocking client requests, and includes examples of denying `udp/443` and private network CIDRs, operators can reasonably rely on ACL as a UDP egress security boundary. This boundary can currently be bypassed by reusing a previously authorized UDP session.\n\n## Root cause\n\nThe relevant flow appears to be:\n\n- `core/server/udp.go:280-299`: when a new session is created, the first destination is passed through `m.io.Hook(...)`, logged, and then `m.io.UDP(addr)` is called once to create the outbound UDP connection.\n- `core/server/server.go:397-398`: `m.io.UDP(addr)` delegates to `io.Outbound.UDP(reqAddr)`.\n- `app/cmd/server.go:1187-1190`: resolver, ACL, and actual outbounds are intentionally chained through the `Outbound` interface.\n- `core/server/udp.go:125`: the initial outbound connection is created only from the first packet via `DialFunc(firstMsg.Addr, firstMsg.Data)`.\n- `core/server/udp.go:92-111`: later packets in the same session take the current packet address and directly call `e.conn.WriteTo(dfMsg.Data, addr)` without re-running ACL or outbound policy evaluation.\n\nIn other words, destination selection is packet-scoped, but authorization is session-scoped.\n\n## Impact\n\nAny authenticated client that is allowed to use UDP relay can:\n\n- open one UDP session using an allowed first destination;\n- reuse the same session to send packets to destinations that ACL should reject;\n- reach UDP services on `127.0.0.1` or on RFC1918/private-network addresses from the server\u0027s network perspective.\n\nIn real deployments, this can expose internal-only UDP services such as:\n\n- internal DNS resolvers;\n- service discovery endpoints;\n- telemetry or metrics listeners;\n- local administrative daemons;\n- application-specific UDP services intended to be reachable only from localhost or the internal network.\n\nThis breaks the server\u0027s documented ACL-based UDP egress restrictions.\n\n## Reproduction\n\nTwo cases were reproduced with integration tests.\n\n### Case 1: localhost bypass\n\nACL:\n\n```text\ndirect(127.0.0.1, udp/\u003callowedPort\u003e)\nreject(127.0.0.1/32)\n```\n\nSteps:\n\n1. Start one UDP echo service on `127.0.0.1:\u003callowedPort\u003e`.\n2. Start another UDP echo service on `127.0.0.1:\u003cblockedPort\u003e`.\n3. Connect an authenticated Hysteria client and create one UDP session.\n4. Send a packet to the allowed loopback destination to establish the session.\n5. Reuse the same UDP session and send a packet to the blocked loopback destination.\n\nObserved result:\n\n- The second packet is relayed successfully and the blocked loopback service replies.\n\nExpected result:\n\n- The second packet should be rejected because `127.0.0.1/32` is denied by ACL.\n\n### Case 2: private-network bypass\n\nACL:\n\n```text\ndirect(127.0.0.1, udp/\u003callowedPort\u003e)\nreject(10.0.0.0/8)\n```\n\nor the corresponding local RFC1918 range, such as `192.168.0.0/16` or `172.16.0.0/12`.\n\nSteps:\n\n1. Start one UDP echo service on `127.0.0.1:\u003callowedPort\u003e`.\n2. Start another UDP echo service on a real RFC1918 address of the server host.\n3. Connect an authenticated Hysteria client and create one UDP session.\n4. Send a packet to the allowed loopback destination first.\n5. Reuse the same UDP session and send a packet to the RFC1918 destination.\n\nObserved result:\n\n- The private-address packet is relayed successfully and receives a reply.\n\nExpected result:\n\n- The packet should be rejected by ACL.\n\n## PoC and local evidence\n\nA local integration test file was added during verification:\n\n- `core/internal/integration_tests/udp_private_acl_bypass_test.go`\n\nThe two tests are:\n\n- `TestClientServerUDPACLBYPASSLoopback`\n- `TestClientServerUDPACLBYPASSPrivateIPv4`\n\nThey can be executed with:\n\n```bash\ngo test ./core/internal/integration_tests -run \u0027TestClientServerUDPACLBYPASS(Loopback|PrivateIPv4)\u0027 -count=1\n```\n\nThe tests pass locally and demonstrate that a destination blocked by ACL becomes reachable after the session is established with an allowed first destination.\n\n## Suggested fixes\n\nAny of the following would address the issue:\n\n1. Re-evaluate ACL and outbound policy for every defragmented UDP packet before forwarding it with `WriteTo`.\n2. Alternatively, enforce a single immutable destination per UDP session and reject destination changes after the first packet.\n3. Ensure logging and policy hooks are aligned with the chosen model so that policy enforcement and observability reflect the real per-packet destination.\n\n## Severity assessment\n\nSuggested CVSS v3.1 vector: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L`\n\nThis reflects a network-reachable issue with low attack complexity, requiring only an authenticated client, no victim interaction, and allowing impact beyond the proxy process by exposing localhost and internal-network UDP resources from the server\u0027s trust boundary.",
  "id": "GHSA-vgrc-hq28-p3xp",
  "modified": "2026-06-26T19:48:50Z",
  "published": "2026-06-26T19:48:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apernet/hysteria/security/advisories/GHSA-vgrc-hq28-p3xp"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apernet/hysteria"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Hysteria has an authenticated UDP ACL bypass that enables localhost and private-network UDP SSRF"
}

GHSA-VH2W-9GGJ-CCRM

Vulnerability from github – Published: 2023-03-14 06:30 – Updated: 2023-03-21 18:30
VLAI
Details

In SAP BusinessObjects Business Intelligence Platform (Web Services) - versions 420, 430, an attacker can control a malicious BOE server, forcing the application server to connect to its own admintools, leading to a high impact on availability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-27271"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-14T06:15:00Z",
    "severity": "HIGH"
  },
  "details": "In SAP BusinessObjects Business Intelligence Platform (Web Services) - versions 420, 430, an attacker can control a malicious BOE server, forcing the application server to connect to its own admintools, leading to a high impact on availability.",
  "id": "GHSA-vh2w-9ggj-ccrm",
  "modified": "2023-03-21T18:30:20Z",
  "published": "2023-03-14T06:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27271"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/3287120"
    },
    {
      "type": "WEB",
      "url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VH6P-P447-HRRR

Vulnerability from github – Published: 2022-05-18 00:00 – Updated: 2022-05-26 00:01
VLAI
Details

Server-Side Request Forgery (SSRF) in GitHub repository jgraph/drawio prior to 18.0.6.

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": [],
  "aliases": [
    "CVE-2022-1723"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-17T09:15:00Z",
    "severity": "HIGH"
  },
  "details": "Server-Side Request Forgery (SSRF) in GitHub repository jgraph/drawio prior to 18.0.6.",
  "id": "GHSA-vh6p-p447-hrrr",
  "modified": "2022-05-26T00:01:12Z",
  "published": "2022-05-18T00:00:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1723"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jgraph/drawio/commit/7a68ebe22a64fe722704e9c4527791209fee2034"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/619851a4-2a08-4196-80e9-ab41953491d8"
    }
  ],
  "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-VH75-FWV3-PQRH

Vulnerability from github – Published: 2026-05-05 19:52 – Updated: 2026-05-13 16:26
VLAI
Summary
requests-hardened is Vulnerable to Server-Side Request Forgery
Details

The SSRF protection in requests-hardened prior to version 1.2.1 fails to block IP addresses within the RFC 6598 Shared Address Space (100.64.0.0/10). An attacker who can supply arbitrary URLs to requests-hardened could exploit this gap to access internal services hosted within 100.64.0.0/10. This is for example relevant in environments such as AWS EKS where 100.64.0.0/10 is commonly used as the default pod CIDR.

The impact is environment-dependent, deployments that utilize the affected CIDR range for internal networking are exposed to SSRF bypass, while others may not be affected.

The issue is resolved in version 1.2.1 by extending the IP filtering logic to explicitly block the RFC 6598 range in addition to standard private addresses, as well as blocking all other reserved addresses (such as multicast) to prevent the re-occurrence of similar issues.

Version 1.2.1 is now blocking the following CIDRs:

  • 192.88.99.0/24 - 6to4 relay anycast
  • 100.64.0.0/10 - CG-NAT
  • 5f00::/16 - IPv6 Segment Routing
  • 64:ff9b::/96 - used for IPv6 & IPv4 translation (NAT64)
  • 2001:20::/28 - ORCHIDv2 (overlay identifiers)
  • 224.0.0.0/4 - multicast
  • ff00::/8 - multicast

Resources

  • https://github.com/python/cpython/issues/119812
  • https://github.com/saleor/requests-hardened/commit/b7403f88d3b3689e57435b75b51691a160aaeef5 - the fix itself
  • https://github.com/saleor/requests-hardened/commit/a266b3958bb142bca515b3c230fdea19fbda327c - follow up, adding additional support for outdated Python versions (3.11.9 and 3.10.11 instead of only 3.11.15 and 3.10.20)
  • https://github.com/saleor/requests-hardened/releases/tag/v1.2.1
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "requests-hardened"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42175"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T19:52:45Z",
    "nvd_published_at": "2026-05-12T18:17:24Z",
    "severity": "MODERATE"
  },
  "details": "The SSRF protection in `requests-hardened` prior to version 1.2.1 fails to block IP addresses within the RFC 6598 Shared Address Space (`100.64.0.0/10`). An attacker who can supply arbitrary URLs to `requests-hardened` could exploit this gap to access internal services hosted within `100.64.0.0/10`. This is for example relevant in environments such as AWS EKS where `100.64.0.0/10` is commonly used as the default pod CIDR.\n\nThe impact is environment-dependent, deployments that utilize the affected CIDR range for internal networking are exposed to SSRF bypass, while others may not be affected.\n\nThe issue is resolved in version 1.2.1 by extending the IP filtering logic to explicitly block the RFC 6598 range in addition to standard private addresses, as well as blocking all other reserved addresses (such as multicast) to prevent the re-occurrence of similar issues.\n\nVersion 1.2.1 is now blocking the following CIDRs:\n\n- `192.88.99.0/24` - 6to4 relay anycast\n- `100.64.0.0/10` - CG-NAT\n- `5f00::/16` - IPv6 Segment Routing\n- `64:ff9b::/96` - used for IPv6 \u0026 IPv4 translation (NAT64)\n- `2001:20::/28` - ORCHIDv2 (overlay identifiers)\n- `224.0.0.0/4` - multicast\n- `ff00::/8` - multicast\n\n## Resources\n\n- https://github.com/python/cpython/issues/119812\n- https://github.com/saleor/requests-hardened/commit/b7403f88d3b3689e57435b75b51691a160aaeef5 - the fix itself\n- https://github.com/saleor/requests-hardened/commit/a266b3958bb142bca515b3c230fdea19fbda327c - follow up, adding additional support for outdated Python versions (`3.11.9` and `3.10.11` instead of only `3.11.15` and `3.10.20`)\n- https://github.com/saleor/requests-hardened/releases/tag/v1.2.1",
  "id": "GHSA-vh75-fwv3-pqrh",
  "modified": "2026-05-13T16:26:26Z",
  "published": "2026-05-05T19:52:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/saleor/requests-hardened/security/advisories/GHSA-vh75-fwv3-pqrh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42175"
    },
    {
      "type": "WEB",
      "url": "https://github.com/saleor/requests-hardened/commit/a266b3958bb142bca515b3c230fdea19fbda327c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/saleor/requests-hardened/commit/b7403f88d3b3689e57435b75b51691a160aaeef5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/saleor/requests-hardened"
    },
    {
      "type": "WEB",
      "url": "https://github.com/saleor/requests-hardened/releases/tag/v1.2.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "requests-hardened is Vulnerable to Server-Side Request Forgery"
}

GHSA-VHP6-HRQQ-RPQJ

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

Ada.cx's Sentry configuration allowed for blind server-side request forgeries (SSRF) through the use of a data scraping endpoint.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-9410"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-04T14:15:05Z",
    "severity": "MODERATE"
  },
  "details": "Ada.cx\u0027s Sentry configuration allowed for blind server-side request forgeries (SSRF) through the use of a data scraping endpoint.",
  "id": "GHSA-vhp6-hrqq-rpqj",
  "modified": "2024-10-04T15:31:22Z",
  "published": "2024-10-04T15:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9410"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/research/tra-2024-41"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VHV4-J9CM-5CJX

Vulnerability from github – Published: 2024-06-05 18:30 – Updated: 2024-06-05 18:30
VLAI
Details

A vulnerability in the web-based management interface of Cisco Finesse could allow an unauthenticated, remote attacker to conduct an SSRF attack on an affected system.

This vulnerability is due to insufficient validation of user-supplied input for specific HTTP requests that are sent to an affected system. An attacker could exploit this vulnerability by sending a crafted HTTP request to the affected device. A successful exploit could allow the attacker to obtain limited sensitive information for services that are associated to the affected device.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-20404"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-05T17:15:11Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the web-based management interface of Cisco Finesse could allow an unauthenticated, remote attacker to conduct an SSRF attack on an affected system.\n\n This vulnerability is due to insufficient validation of user-supplied input for specific HTTP requests that are sent to an affected system. An attacker could exploit this vulnerability by sending a crafted HTTP request to the affected device. A successful exploit could allow the attacker to obtain limited sensitive information for services that are associated to the affected device.",
  "id": "GHSA-vhv4-j9cm-5cjx",
  "modified": "2024-06-05T18:30:34Z",
  "published": "2024-06-05T18:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20404"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-finesse-ssrf-rfi-Um7wT8Ew"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VJ2P-7PGW-G2WF

Vulnerability from github – Published: 2026-03-27 15:46 – Updated: 2026-03-27 15:46
VLAI
Summary
Postiz App has a High-Severity SSRF Vulnerability via Next.js
Details

Impact

A successful SSRF attack allows an attacker to: - Bypass firewalls to scan and interact with internal network services/ports. - Access sensitive cloud metadata services (e.g., AWS IMDS 169.254.169.254) to potentially leak instance credentials. - Pivot into the internal network environment where Postiz is hosted.

Workarounds

There are no workarounds known to this, please upgrade to Postiz version v2.21.1.

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": "npm",
        "name": "postiz"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1395",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-27T15:46:53Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nA successful SSRF attack allows an attacker to:\n- Bypass firewalls to scan and interact with internal network services/ports.\n- Access sensitive cloud metadata services (e.g., AWS IMDS 169.254.169.254) to potentially leak instance credentials.\n- Pivot into the internal network environment where Postiz is hosted.\n\n### Workarounds\nThere are no workarounds known to this, please upgrade to Postiz version `v2.21.1`.",
  "id": "GHSA-vj2p-7pgw-g2wf",
  "modified": "2026-03-27T15:46:53Z",
  "published": "2026-03-27T15:46:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gitroomhq/postiz-app/security/advisories/GHSA-vj2p-7pgw-g2wf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/security/advisories/GHSA-fr5h-rqp8-mj6g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34351"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gitroomhq/postiz-app"
    }
  ],
  "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": "Postiz App has a High-Severity SSRF Vulnerability via Next.js"
}

GHSA-VJX8-8P7H-82GR

Vulnerability from github – Published: 2026-04-07 18:10 – Updated: 2026-04-24 21:04
VLAI
Summary
OpenClaw: Marketplace Plugin Download Follows Redirects Without SSRF Protection
Details

Summary

Marketplace Plugin Download Follows Redirects Without SSRF Protection

Current Maintainer Triage

  • Status: open
  • Normalized severity: medium
  • Assessment: v2026.3.28 still uses bare redirect-following fetch in src/plugins/marketplace.ts for marketplace archives, and fixed-on-main only does not change that shipped SSRF exposure.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published npm version: 2026.3.31
  • Vulnerable version range: <=2026.3.28
  • Patched versions: >= 2026.3.31
  • First stable tag containing the fix: v2026.3.31

Fix Commit(s)

  • 2ce44ca6a1302b166a128abbd78f72114f2f4f52 — 2026-03-31T12:59:42+01:00

Release Process Note

  • The fix is already present in released version 2026.3.31.
  • This draft looks ready for final maintainer disposition or publication, not additional code-fix work.

Thanks @AntAISecurityLab for reporting.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.28"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.31"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41297"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-07T18:10:45Z",
    "nvd_published_at": "2026-04-21T00:16:30Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\nMarketplace Plugin Download Follows Redirects Without SSRF Protection\n\n## Current Maintainer Triage\n- Status: open\n- Normalized severity: medium\n- Assessment: v2026.3.28 still uses bare redirect-following fetch in src/plugins/marketplace.ts for marketplace archives, and fixed-on-main only does not change that shipped SSRF exposure.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version: `2026.3.31`\n- Vulnerable version range: `\u003c=2026.3.28`\n- Patched versions: `\u003e= 2026.3.31`\n- First stable tag containing the fix: `v2026.3.31`\n\n## Fix Commit(s)\n- `2ce44ca6a1302b166a128abbd78f72114f2f4f52` \u2014 2026-03-31T12:59:42+01:00\n\n## Release Process Note\n- The fix is already present in released version `2026.3.31`.\n- This draft looks ready for final maintainer disposition or publication, not additional code-fix work.\n\nThanks @AntAISecurityLab for reporting.",
  "id": "GHSA-vjx8-8p7h-82gr",
  "modified": "2026-04-24T21:04:32Z",
  "published": "2026-04-07T18:10:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-vjx8-8p7h-82gr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41297"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/2ce44ca6a1302b166a128abbd78f72114f2f4f52"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-server-side-request-forgery-via-marketplace-plugin-download-redirect"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Marketplace Plugin Download Follows Redirects Without SSRF Protection"
}

GHSA-VJXX-54VW-Q59F

Vulnerability from github – Published: 2022-05-14 01:17 – Updated: 2025-05-30 19:54
VLAI
Summary
Moodle SSRF Vulnerability
Details

The edit_blog.php script allows a registered user to add external RSS feed resources. It was identified that this feature could be abused to be used as a SSRF attack vector by adding a malicious URL/TCP PORT in order to target internal network or an internet hosted server, bypassing firewall rules, IP filtering and more.

This kind of vulnerability is then called “blind” because of no response available on Moodle web site, enforcing attacker to exploit it using a “time based” approach.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.5.0"
            },
            {
              "fixed": "3.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-6970"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-19T20:37:25Z",
    "nvd_published_at": "2019-03-21T16:01:00Z",
    "severity": "HIGH"
  },
  "details": "The `edit_blog.php` script allows a registered user to add external RSS feed resources. It was identified that this feature could be abused to be used as a SSRF attack vector by adding a malicious URL/TCP PORT in order to target internal network or an internet hosted server, bypassing firewall rules, IP filtering and more.\n\nThis kind of vulnerability is then called \u201cblind\u201d because of no response available on Moodle web site, enforcing attacker to exploit it using a \u201ctime based\u201d approach.",
  "id": "GHSA-vjxx-54vw-q59f",
  "modified": "2025-05-30T19:54:40Z",
  "published": "2022-05-14T01:17:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6970"
    },
    {
      "type": "WEB",
      "url": "https://cds.thalesgroup.com/en/tcs-cert/CVE-2019-6970"
    },
    {
      "type": "WEB",
      "url": "https://excellium-services.com/cert-xlm-advisory/cve-2019-6970"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moodle/moodle"
    },
    {
      "type": "WEB",
      "url": "https://www.excellium-services.com/cert-xlm-advisory"
    },
    {
      "type": "WEB",
      "url": "https://www.excellium-services.com/cert-xlm-advisory/cve-2019-6970"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Moodle SSRF Vulnerability"
}

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