GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly control the allocation and maintenance of a limited resource.

6175 vulnerabilities reference this CWE, most recent first.

GHSA-W825-MC9P-6WP6

Vulnerability from github – Published: 2025-01-14 18:32 – Updated: 2025-01-14 18:32
VLAI
Details

Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability

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-2025-21290"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-14T18:15:50Z",
    "severity": "HIGH"
  },
  "details": "Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability",
  "id": "GHSA-w825-mc9p-6wp6",
  "modified": "2025-01-14T18:32:04Z",
  "published": "2025-01-14T18:32:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21290"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21290"
    }
  ],
  "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-W878-PJ84-3J5V

Vulnerability from github – Published: 2026-09-02 23:42 – Updated: 2026-09-02 23:42
VLAI
Summary
Mailpit: SMTP command parser buffers unbounded command lines before syntax rejection
Details

Summary

Mailpit's SMTP server reads each command line with an unbounded bufio.Reader.ReadString('\n') before parsing the command or enforcing any protocol length limit. A remote SMTP client can send an oversized single command line and force Mailpit to allocate attacker-controlled memory before the server returns a syntax error or times out, even though RFC 5321 limits SMTP command lines to 512 octets including CRLF.

Technical Details

Mailpit enables SMTP by default. config/config.go sets SMTPListen = "[::]:1025", and cmd/root.go calls smtpd.Listen() during normal startup. The SMTP server configures recipient and message DATA size limits in internal/smtpd/main.go, including the default 50 MiB MaxMessageSize, but those limits do not apply to command lines.

The vulnerable path is in the SMTP command loop. internal/smtpd/smtpd.go calls s.readLine() for every command before parsing the verb or arguments:

line, err := s.readLine()
if err != nil {
    if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
        s.writef("421 4.4.2 %s %s ESMTP Service closing transmission channel after timeout exceeded", s.srv.Hostname, s.srv.AppName)
    }
    break
}

verb, args := s.parseLine(line)

readLine() then buffers until newline without a maximum length:

func (s *session) readLine() (string, error) {
    if s.srv.Timeout > 0 {
        _ = s.conn.SetReadDeadline(time.Now().Add(s.srv.Timeout))
    }

    line, err := s.br.ReadString('\n')
    if err != nil {
        return "", err
    }
    line = strings.TrimSpace(line)
    return line, err
}

This violates the SMTP command-line invariant before later validation can help. Address length validation in extractAndValidateAddress() runs only after the entire command line has already been buffered and parsed. The DATA reader has a separate srv.MaxSize check, but the issue is pre-DATA command input.

PoV

The following bounded test exercises the same command reader with a normal NOOP control and an 8 MiB oversized command line:

package smtpd

import (
    "bufio"
    "bytes"
    "strings"
    "testing"
)

func TestUnboundedSMTPCommandLinePoV(t *testing.T) {
    short := "NOOP\r\n"
    shortSession := session{srv: &Server{}, br: bufio.NewReader(strings.NewReader(short))}
    shortLine, err := shortSession.readLine()
    if err != nil {
        t.Fatalf("short control readLine failed: %v", err)
    }
    t.Logf("short control: accepted len=%d command=%q", len(shortLine), shortLine)

    oversizedLen := 8 * 1024 * 1024
    oversized := strings.Repeat("X", oversizedLen) + "\r\n"
    oversizedSession := session{srv: &Server{}, br: bufio.NewReader(bytes.NewBufferString(oversized))}
    oversizedLine, err := oversizedSession.readLine()
    if err != nil {
        t.Fatalf("oversized readLine failed: %v", err)
    }
    t.Logf("oversized command: accepted len=%d; RFC 5321 command-line limit is 512 octets including CRLF", len(oversizedLine))

    if len(oversizedLine) != oversizedLen {
        t.Fatalf("readLine length = %d, want %d", len(oversizedLine), oversizedLen)
    }
    if len(oversizedLine) <= 512 {
        t.Fatalf("oversized command did not exceed SMTP command-line limit")
    }
}

PoC

From a Mailpit checkout, save the PoV above as internal/smtpd/smtp_command_line_pov_test.go and run:

docker run --rm -v "$PWD:/src" -w /src golang:1.25 go test ./internal/smtpd -run TestUnboundedSMTPCommandLinePoV -v

On current develop commit cd7661fd5b23cce1e218b583b21e157cfa612051, the test prints:

=== RUN   TestUnboundedSMTPCommandLinePoV
    smtp_command_line_pov_test.go:17: short control: accepted len=4 command="NOOP"
    smtp_command_line_pov_test.go:26: oversized command: accepted len=8388608; RFC 5321 command-line limit is 512 octets including CRLF
--- PASS: TestUnboundedSMTPCommandLinePoV (0.01s)
PASS
ok      github.com/axllent/mailpit/internal/smtpd   0.017s

The same test against release v1.30.3 commit 6acf5b8f942ab0e007b1227d31dfb3c3303e8d13 prints:

=== RUN   TestUnboundedSMTPCommandLinePoV
    smtp_command_line_pov_test.go:17: short control: accepted len=4 command="NOOP"
    smtp_command_line_pov_test.go:26: oversized command: accepted len=8388608; RFC 5321 command-line limit is 512 octets including CRLF
--- PASS: TestUnboundedSMTPCommandLinePoV (0.02s)
PASS
ok      github.com/axllent/mailpit/internal/smtpd   0.020s

The NOOP control shows the normal reader path. The oversized case shows the parser accepting an 8 MiB command line into memory instead of rejecting at the SMTP command-line limit.

Impact

An unauthenticated remote client that can reach Mailpit's SMTP listener can force heap allocation proportional to a single command line before any SMTP command is parsed. Repeating the input across concurrent connections can consume process memory and degrade or deny Mailpit service availability. This is distinct from message DATA size handling: the default MaxMessageSize cap is enforced after DATA, while the command-line reader is reached before DATA and before MAIL FROM SIZE= handling.

Suggested advisory metadata: CWE-400 (Uncontrolled Resource Consumption). Conservative CVSS 3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base score 7.5 (High). If a deployment explicitly binds SMTP to trusted loopback-only clients, environmental severity may be lower; the project default is a network SMTP listener on [::]:1025.

Suggested Fix

Bound SMTP command-line reads before buffering the full line. For ordinary SMTP commands, reject input exceeding RFC 5321's 512-octet command-line limit including CRLF, returning a 500 5.5.2-style command-line-too-long response before allocating the entire attacker-controlled line. Apply the same pre-parse bound to AUTH continuation lines because handleAuthLogin(), handleAuthPlain(), and handleAuthCramMD5() also call readLine(). Consider adding a similar POP3 command-line cap in internal/pop3/server.go, where the optional POP3 server also uses ReadString('\n') for commands.

Regression tests should cover a normal short command, an over-limit command line, and over-limit AUTH continuation input. They should assert that the over-limit cases fail without returning the oversized string to command parsing.

Affected Package/Versions

Confirmed affected:

  • Current develop: cd7661fd5b23cce1e218b583b21e157cfa612051
  • Latest release: v1.30.3, tag commit 6acf5b8f942ab0e007b1227d31dfb3c3303e8d13, published 2026-06-27

No fixed version was identified during this review.

Advisory History

The closest published Mailpit advisory is GHSA-fpxj-m5q8-fphw, which covers unauthenticated memory exhaustion through unlimited SMTP DATA and /api/v1/send body sizes. This report is different: it targets the pre-DATA SMTP command-line reader before srv.MaxSize, MAIL FROM SIZE=, or DATA handling applies.

Other published Mailpit advisories checked were GHSA-28pq-6qxg-wg5r for HTTP JSON body limits, GHSA-54wq-72mp-cq7c for SMTP header injection, GHSA-w4vj-r5pg-3722 for proxy CSS map concurrency, GHSA-qx5x-85p8-vg4j for dump path traversal, the SSRF/link-check/proxy advisories GHSA-8v65-47jx-7mfr, GHSA-mpf7-p9x7-96r3, GHSA-6jxm-fv7w-rw5j, GHSA-j3fj-qppj-fmmc, GHSA-w4mc-hhc6-xp28, and GHSA-524m-q5m7-79mm for CSWSH. None of these describe unbounded SMTP command-line buffering.

Public Mailpit issue searches for SMTP command line too long ReadString, SMTP 512 octets command line, SMTP memory DoS command line, and ReadString smtpd found no matching issue. Public commit searches for ReadString smtpd, command line too long, and MaxMessageSize smtp found no matching fix. No prior submitted, ready-for-review, or completed-but-unsubmitted Mailpit report available in the review materials matched this root cause.

References

  • RFC 5321 section 4.5.3.1.4, command-line length limit: https://www.rfc-editor.org/rfc/rfc5321#section-4.5.3.1.4
  • Mailpit security policy: https://github.com/axllent/mailpit/security/policy
  • GHSA-fpxj-m5q8-fphw: https://github.com/axllent/mailpit/security/advisories/GHSA-fpxj-m5q8-fphw
  • GHSA-28pq-6qxg-wg5r: https://github.com/axllent/mailpit/security/advisories/GHSA-28pq-6qxg-wg5r
  • GHSA-54wq-72mp-cq7c: https://github.com/axllent/mailpit/security/advisories/GHSA-54wq-72mp-cq7c
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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.30.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/axllent/mailpit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.30.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-67445"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-02T23:42:25Z",
    "nvd_published_at": "2026-08-20T21:17:07Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nMailpit\u0027s SMTP server reads each command line with an unbounded `bufio.Reader.ReadString(\u0027\\n\u0027)` before parsing the command or enforcing any protocol length limit. A remote SMTP client can send an oversized single command line and force Mailpit to allocate attacker-controlled memory before the server returns a syntax error or times out, even though RFC 5321 limits SMTP command lines to 512 octets including CRLF.\n\n## Technical Details\n\nMailpit enables SMTP by default. `config/config.go` sets `SMTPListen = \"[::]:1025\"`, and `cmd/root.go` calls `smtpd.Listen()` during normal startup. The SMTP server configures recipient and message DATA size limits in `internal/smtpd/main.go`, including the default 50 MiB `MaxMessageSize`, but those limits do not apply to command lines.\n\nThe vulnerable path is in the SMTP command loop. `internal/smtpd/smtpd.go` calls `s.readLine()` for every command before parsing the verb or arguments:\n\n```go\nline, err := s.readLine()\nif err != nil {\n    if netErr, ok := err.(net.Error); ok \u0026\u0026 netErr.Timeout() {\n        s.writef(\"421 4.4.2 %s %s ESMTP Service closing transmission channel after timeout exceeded\", s.srv.Hostname, s.srv.AppName)\n    }\n    break\n}\n\nverb, args := s.parseLine(line)\n```\n\n`readLine()` then buffers until newline without a maximum length:\n\n```go\nfunc (s *session) readLine() (string, error) {\n    if s.srv.Timeout \u003e 0 {\n        _ = s.conn.SetReadDeadline(time.Now().Add(s.srv.Timeout))\n    }\n\n    line, err := s.br.ReadString(\u0027\\n\u0027)\n    if err != nil {\n        return \"\", err\n    }\n    line = strings.TrimSpace(line)\n    return line, err\n}\n```\n\nThis violates the SMTP command-line invariant before later validation can help. Address length validation in `extractAndValidateAddress()` runs only after the entire command line has already been buffered and parsed. The DATA reader has a separate `srv.MaxSize` check, but the issue is pre-DATA command input.\n\n## PoV\n\nThe following bounded test exercises the same command reader with a normal `NOOP` control and an 8 MiB oversized command line:\n\n```go\npackage smtpd\n\nimport (\n    \"bufio\"\n    \"bytes\"\n    \"strings\"\n    \"testing\"\n)\n\nfunc TestUnboundedSMTPCommandLinePoV(t *testing.T) {\n    short := \"NOOP\\r\\n\"\n    shortSession := session{srv: \u0026Server{}, br: bufio.NewReader(strings.NewReader(short))}\n    shortLine, err := shortSession.readLine()\n    if err != nil {\n        t.Fatalf(\"short control readLine failed: %v\", err)\n    }\n    t.Logf(\"short control: accepted len=%d command=%q\", len(shortLine), shortLine)\n\n    oversizedLen := 8 * 1024 * 1024\n    oversized := strings.Repeat(\"X\", oversizedLen) + \"\\r\\n\"\n    oversizedSession := session{srv: \u0026Server{}, br: bufio.NewReader(bytes.NewBufferString(oversized))}\n    oversizedLine, err := oversizedSession.readLine()\n    if err != nil {\n        t.Fatalf(\"oversized readLine failed: %v\", err)\n    }\n    t.Logf(\"oversized command: accepted len=%d; RFC 5321 command-line limit is 512 octets including CRLF\", len(oversizedLine))\n\n    if len(oversizedLine) != oversizedLen {\n        t.Fatalf(\"readLine length = %d, want %d\", len(oversizedLine), oversizedLen)\n    }\n    if len(oversizedLine) \u003c= 512 {\n        t.Fatalf(\"oversized command did not exceed SMTP command-line limit\")\n    }\n}\n```\n\n## PoC\n\nFrom a Mailpit checkout, save the PoV above as `internal/smtpd/smtp_command_line_pov_test.go` and run:\n\n```fish\ndocker run --rm -v \"$PWD:/src\" -w /src golang:1.25 go test ./internal/smtpd -run TestUnboundedSMTPCommandLinePoV -v\n```\n\nOn current `develop` commit `cd7661fd5b23cce1e218b583b21e157cfa612051`, the test prints:\n\n```text\n=== RUN   TestUnboundedSMTPCommandLinePoV\n    smtp_command_line_pov_test.go:17: short control: accepted len=4 command=\"NOOP\"\n    smtp_command_line_pov_test.go:26: oversized command: accepted len=8388608; RFC 5321 command-line limit is 512 octets including CRLF\n--- PASS: TestUnboundedSMTPCommandLinePoV (0.01s)\nPASS\nok  \tgithub.com/axllent/mailpit/internal/smtpd\t0.017s\n```\n\nThe same test against release `v1.30.3` commit `6acf5b8f942ab0e007b1227d31dfb3c3303e8d13` prints:\n\n```text\n=== RUN   TestUnboundedSMTPCommandLinePoV\n    smtp_command_line_pov_test.go:17: short control: accepted len=4 command=\"NOOP\"\n    smtp_command_line_pov_test.go:26: oversized command: accepted len=8388608; RFC 5321 command-line limit is 512 octets including CRLF\n--- PASS: TestUnboundedSMTPCommandLinePoV (0.02s)\nPASS\nok  \tgithub.com/axllent/mailpit/internal/smtpd\t0.020s\n```\n\nThe `NOOP` control shows the normal reader path. The oversized case shows the parser accepting an 8 MiB command line into memory instead of rejecting at the SMTP command-line limit.\n\n## Impact\n\nAn unauthenticated remote client that can reach Mailpit\u0027s SMTP listener can force heap allocation proportional to a single command line before any SMTP command is parsed. Repeating the input across concurrent connections can consume process memory and degrade or deny Mailpit service availability. This is distinct from message DATA size handling: the default `MaxMessageSize` cap is enforced after `DATA`, while the command-line reader is reached before DATA and before `MAIL FROM SIZE=` handling.\n\nSuggested advisory metadata: CWE-400 (Uncontrolled Resource Consumption). Conservative CVSS 3.1 vector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`, base score 7.5 (High). If a deployment explicitly binds SMTP to trusted loopback-only clients, environmental severity may be lower; the project default is a network SMTP listener on `[::]:1025`.\n\n## Suggested Fix\n\nBound SMTP command-line reads before buffering the full line. For ordinary SMTP commands, reject input exceeding RFC 5321\u0027s 512-octet command-line limit including CRLF, returning a `500 5.5.2`-style command-line-too-long response before allocating the entire attacker-controlled line. Apply the same pre-parse bound to AUTH continuation lines because `handleAuthLogin()`, `handleAuthPlain()`, and `handleAuthCramMD5()` also call `readLine()`. Consider adding a similar POP3 command-line cap in `internal/pop3/server.go`, where the optional POP3 server also uses `ReadString(\u0027\\n\u0027)` for commands.\n\nRegression tests should cover a normal short command, an over-limit command line, and over-limit AUTH continuation input. They should assert that the over-limit cases fail without returning the oversized string to command parsing.\n\n## Affected Package/Versions\n\nConfirmed affected:\n\n- Current `develop`: `cd7661fd5b23cce1e218b583b21e157cfa612051`\n- Latest release: `v1.30.3`, tag commit `6acf5b8f942ab0e007b1227d31dfb3c3303e8d13`, published 2026-06-27\n\nNo fixed version was identified during this review.\n\n## Advisory History\n\nThe closest published Mailpit advisory is `GHSA-fpxj-m5q8-fphw`, which covers unauthenticated memory exhaustion through unlimited SMTP DATA and `/api/v1/send` body sizes. This report is different: it targets the pre-DATA SMTP command-line reader before `srv.MaxSize`, `MAIL FROM SIZE=`, or DATA handling applies.\n\nOther published Mailpit advisories checked were `GHSA-28pq-6qxg-wg5r` for HTTP JSON body limits, `GHSA-54wq-72mp-cq7c` for SMTP header injection, `GHSA-w4vj-r5pg-3722` for proxy CSS map concurrency, `GHSA-qx5x-85p8-vg4j` for dump path traversal, the SSRF/link-check/proxy advisories `GHSA-8v65-47jx-7mfr`, `GHSA-mpf7-p9x7-96r3`, `GHSA-6jxm-fv7w-rw5j`, `GHSA-j3fj-qppj-fmmc`, `GHSA-w4mc-hhc6-xp28`, and `GHSA-524m-q5m7-79mm` for CSWSH. None of these describe unbounded SMTP command-line buffering.\n\nPublic Mailpit issue searches for `SMTP command line too long ReadString`, `SMTP 512 octets command line`, `SMTP memory DoS command line`, and `ReadString smtpd` found no matching issue. Public commit searches for `ReadString smtpd`, `command line too long`, and `MaxMessageSize smtp` found no matching fix. No prior submitted, ready-for-review, or completed-but-unsubmitted Mailpit report available in the review materials matched this root cause.\n\n## References\n\n- RFC 5321 section 4.5.3.1.4, command-line length limit: https://www.rfc-editor.org/rfc/rfc5321#section-4.5.3.1.4\n- Mailpit security policy: https://github.com/axllent/mailpit/security/policy\n- `GHSA-fpxj-m5q8-fphw`: https://github.com/axllent/mailpit/security/advisories/GHSA-fpxj-m5q8-fphw\n- `GHSA-28pq-6qxg-wg5r`: https://github.com/axllent/mailpit/security/advisories/GHSA-28pq-6qxg-wg5r\n- `GHSA-54wq-72mp-cq7c`: https://github.com/axllent/mailpit/security/advisories/GHSA-54wq-72mp-cq7c",
  "id": "GHSA-w878-pj84-3j5v",
  "modified": "2026-09-02T23:42:25Z",
  "published": "2026-09-02T23:42:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axllent/mailpit/security/advisories/GHSA-w878-pj84-3j5v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67445"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axllent/mailpit/commit/993bed95b3c74d95231af93bd0e0d4c3d5b4db4d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axllent/mailpit"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axllent/mailpit/releases/tag/v1.30.4"
    }
  ],
  "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": "Mailpit: SMTP command parser buffers unbounded command lines before syntax rejection"
}

GHSA-W8CP-FRXC-55PJ

Vulnerability from github – Published: 2024-05-24 19:00 – Updated: 2024-05-24 19:00
VLAI
Summary
Kwik does not discard unused encryption keys
Details

Kwik commit 745fd4e2 does not discard unused encryption keys.

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": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "tech.kwik:kwik"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-22588"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-327",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-24T19:00:28Z",
    "nvd_published_at": "2024-05-24T15:15:23Z",
    "severity": "MODERATE"
  },
  "details": "Kwik commit 745fd4e2 does not discard unused encryption keys.",
  "id": "GHSA-w8cp-frxc-55pj",
  "modified": "2024-05-24T19:00:28Z",
  "published": "2024-05-24T19:00:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22588"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ptrd/kwik/issues/31"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ptrd/kwik/commit/040b0d1327bfb0a8e35c23c2bd612a4a39b721d4"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/QUICTester/29a1851c2b2a406411f688735526fe2e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ptrd/kwik"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/rfc/rfc9001#name-discarding-unused-keys"
    }
  ],
  "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"
    }
  ],
  "summary": "Kwik does not discard unused encryption keys"
}

GHSA-W8G4-H8CC-352M

Vulnerability from github – Published: 2022-05-02 03:36 – Updated: 2025-04-09 04:13
VLAI
Details

Stack consumption vulnerability in the FTP Service in Microsoft Internet Information Services (IIS) 5.0 through 7.0 allows remote authenticated users to cause a denial of service (daemon crash) via a list (ls) -R command containing a wildcard that references a subdirectory, followed by a .. (dot dot), aka "IIS FTP Service DoS Vulnerability."

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2009-2521"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-09-04T10:30:00Z",
    "severity": "MODERATE"
  },
  "details": "Stack consumption vulnerability in the FTP Service in Microsoft Internet Information Services (IIS) 5.0 through 7.0 allows remote authenticated users to cause a denial of service (daemon crash) via a list (ls) -R command containing a wildcard that references a subdirectory, followed by a .. (dot dot), aka \"IIS FTP Service DoS Vulnerability.\"",
  "id": "GHSA-w8g4-h8cc-352m",
  "modified": "2025-04-09T04:13:52Z",
  "published": "2022-05-02T03:36:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-2521"
    },
    {
      "type": "WEB",
      "url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2009/ms09-053"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A6508"
    },
    {
      "type": "WEB",
      "url": "http://archives.neohapsis.com/archives/fulldisclosure/2009-09/0040.html"
    },
    {
      "type": "WEB",
      "url": "http://support.microsoft.com/default.aspx?scid=kb%3B%5BLN%5D%3BQ975191"
    },
    {
      "type": "WEB",
      "url": "http://support.microsoft.com/default.aspx?scid=kb;[LN];Q975191"
    },
    {
      "type": "WEB",
      "url": "http://www.us-cert.gov/cas/techalerts/TA09-286A.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-W8G6-73FG-2X53

Vulnerability from github – Published: 2024-10-29 15:32 – Updated: 2024-10-29 15:32
VLAI
Details

A vulnerability in gaizhenbiao/chuanhuchatgpt version 20240628 allows for a Denial of Service (DOS) attack. When uploading a file, if an attacker appends a large number of characters to the end of a multipart boundary, the system will continuously process each character, rendering ChuanhuChatGPT inaccessible. This uncontrolled resource consumption can lead to prolonged unavailability of the service, disrupting operations and causing potential data inaccessibility and loss of productivity.

Severity
7.5 (High)
CVSS:3.0/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-2024-7807"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-29T13:15:10Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in gaizhenbiao/chuanhuchatgpt version 20240628 allows for a Denial of Service (DOS) attack. When uploading a file, if an attacker appends a large number of characters to the end of a multipart boundary, the system will continuously process each character, rendering ChuanhuChatGPT inaccessible. This uncontrolled resource consumption can lead to prolonged unavailability of the service, disrupting operations and causing potential data inaccessibility and loss of productivity.",
  "id": "GHSA-w8g6-73fg-2x53",
  "modified": "2024-10-29T15:32:05Z",
  "published": "2024-10-29T15:32:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7807"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gaizhenbiao/chuanhuchatgpt/commit/919222d285d73b9dcd71fb34de379eef8c90d175"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/db67276d-36ee-4487-9165-b621c67ef8a3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W8J3-PQ8G-8M7W

Vulnerability from github – Published: 2026-05-18 16:33 – Updated: 2026-06-09 10:32
VLAI
Summary
iskorotkov/avro: CPU Exhaustion in Decoder
Details

CPU Exhaustion in Avro Decoder via Unbounded Block-Count Iteration

Summary

The Avro array and map decoders looped over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 / arm64 targets — so a producer can declare a block of up to math.MaxInt64 (~9.2 × 10¹⁸) elements followed by EOF (or any truncated payload), and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is "indefinite until the worker is killed externally" — a single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated. Remote, unauthenticated denial-of-service.

The fix exits the loop on the first inner-decode error. It does not bound the loop length itself; for full coverage on untrusted inputs, also configure Config.MaxSliceAllocSize and Config.MaxMapAllocSize (the latter introduced in v2.33.0).

Description

Avro arrays and maps are encoded as one or more blocks; each block declares an element count followed by that many encoded elements. The decoder reads the block count as a zigzag-encoded long, then iterates that many times calling an inner decoder.

Three iteration sites trusted the block count without checking the reader's accumulated error state between iterations:

  • codec_skip.go sliceSkipDecoder.Decode — skip helper for arrays.
  • codec_skip.go mapSkipDecoder.Decode — skip helper for maps.
  • reader_generic.go Reader.ReadArrayCB and Reader.ReadMapCB — callback-based decoders used by generic and unmarshaling code paths.

Because the inner Decode(nil, r) call is a no-op when r has already errored (it returns immediately without consuming bytes), the loop would run to completion even after the first iteration's EOF. On amd64 / arm64, Reader.ReadBlockHeader returns the count as int (= int64), so the loop bound is whatever the wire payload specified, up to math.MaxInt64. A modest 200-million-count payload (well under 2³¹) already burns several seconds; a math.MaxInt − 2 payload (the value used in the regression test TestDecoder_ArrayMultiBlockExceedsMaxInt from PR #9) effectively pins the goroutine until external kill.

This overlaps with GHSA-mc57-h6j3-3hmv: the same large-block-count payload that drives the unbounded loop here also drives the cumulative-arithmetic overflow there (cross-platform), and on a 32-bit target additionally triggers the union-index / byte-slice narrowing.

Affected components

File Function PR Fix commit
codec_skip.go sliceSkipDecoder.Decode — b124caa
codec_skip.go mapSkipDecoder.Decode — b124caa
reader_generic.go Reader.ReadArrayCB #4 2ce4242
reader_generic.go Reader.ReadMapCB #4 2ce4242

These are the audited and patched sites. Any other code path that iterates over an attacker-controlled count while calling a Reader-style decoder is structurally susceptible to the same pattern; reviewers of consumer code should grep for for range l / for i := 0; i < int(l); i++ near Reader method calls and confirm an in-loop error check.

Technical details

Vulnerable pattern:

for range l {
    d.decoder.Decode(nil, r)
    // r.Error may have been set by Decode; loop continues regardless.
}

After r.Error != nil, subsequent Decode calls short-circuit and return without consuming bytes or doing useful work, but the loop control variable still runs to l. With l = math.MaxInt64, the loop body executes ~9.2 × 10¹⁸ times — effectively infinite for any realistic timeout.

Fixed pattern (b124caa, 2ce4242):

for range l {
    d.decoder.Decode(nil, r)
    if r.Error != nil {
        break
    }
}

The fix terminates the loop on the first inner error. It does not bound l itself — a well-formed payload that actually contains N encoded null elements still iterates N times. The MaxSliceAllocSize / MaxMapAllocSize caps are the policy-level bound on that case (see Mitigation).

Fixed behavior

The reader's accumulated error is checked after every inner Decode in the four affected loops. Decoder errors now surface in O(1) iterations instead of O(blockCount) when the underlying read fails mid-stream.

Affected versions

  • github.com/hamba/avro/v2 — all versions up to and including v2.31.0 (repository is read-only upstream).
  • github.com/iskorotkov/avro/v2 — all versions prior to v2.33.0.

Fixed versions

github.com/iskorotkov/avro/v2 v2.33.0 and later. There is no upstream fix for github.com/hamba/avro/v2 — module path is archived. Migrate to the fork as described under Mitigation.

Mitigation

Migrate from github.com/hamba/avro/v2 to github.com/iskorotkov/avro/v2 >= v2.33.0. Replace the import path and run go mod tidy:

go get github.com/iskorotkov/avro/v2@latest

Or, for consumers that prefer the original import path, a replace directive in go.mod:

replace github.com/hamba/avro/v2 => github.com/iskorotkov/avro/v2 v2.33.0

replace is honoured only for the main module of a build — transitive consumers must add their own replace, or migrate the import path directly.

The error-propagation fix runs on the existing decode path and requires no configuration.

For defense-in-depth against well-formed but oversized payloads (where the fix above does not help, because no error fires), set explicit allocation caps:

cfg := avro.Config{
    MaxByteSliceSize:  102_400,
    MaxSliceAllocSize: 10_000,
    MaxMapAllocSize:   10_000,
}.Freeze()

decoder := cfg.NewDecoder(schema, reader)

MaxMapAllocSize is new in v2.33.0 and opt-in (default zero, which leaves the previous unbounded behavior). Without setting it, a producer that ships a math.MaxInt64-count block still consumes the corresponding memory and CPU; see GHSA-mx64-mj3q-7prj for the cumulative-allocation enforcement details.

If you cannot upgrade immediately, the structural workarounds are application-level: per-request decode timeouts, isolated decoder workers under CPU quotas, and rejection of payloads whose advertised block count exceeds a known sane bound for your schema.

Proof-of-concept input

A minimal payload that triggers the bug for an array of int:

zigzag-encoded long: math.MaxInt64   (block element count)
EOF                                  (no further bytes)

The decoder reads the block-count header, enters the loop, fails to read the first element (EOF), records the error, and then iterates math.MaxInt64 − 1 further times calling the inner decoder as a no-op. Wall-clock cost on commodity hardware: indefinite — the goroutine pins one CPU core until the process is OOM-killed, deadline-cancelled, or terminated externally. The classic "a few seconds per request" characterisation applies only to small-but-still-pathological block counts in the 10⁸–10⁹ range (e.g. 200_999_000 in TestDecoder_SkipArrayEOF); the architectural ceiling is math.MaxInt64.

A negative block count (-N) is also legal in Avro (signals an N-element block with an explicit byte length); the same iteration pattern applies once the count is negated.

References

Credits

  • Discovery and fixes (commits b124caa skip helpers and 2ce4242 callback path, PR #4): Daniel Błażewicz (@klajok)
  • Release authorship: Ivan Korotkov (@iskorotkov)

Timeline

  • 2026-04-28 — Skip-decoder fix (b124caa) merged.
  • 2026-04-30 — Callback-decoder fix (PR #4, 2ce4242) merged.
  • 2026-05-06 — v2.33.0 tagged and released.
  • 2026-05-11 — Advisory published.
  • 2026-05-15 — Advisory revised.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
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
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/iskorotkov/avro/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.33.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46385"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-400",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T16:33:43Z",
    "nvd_published_at": "2026-05-29T20:16:27Z",
    "severity": "HIGH"
  },
  "details": "# CPU Exhaustion in Avro Decoder via Unbounded Block-Count Iteration\n\n## Summary\n\nThe Avro array and map decoders looped over an attacker-controlled block-count value without checking the underlying reader\u0027s error state inside the loop body. `Reader.ReadBlockHeader` returns the count as a Go `int`, which is 64-bit on `amd64` / `arm64` targets \u2014 so a producer can declare a block of up to `math.MaxInt64` (~9.2 \u00d7 10\u00b9\u2078) elements followed by EOF (or any truncated payload), and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is \"indefinite until the worker is killed externally\" \u2014 a single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated. Remote, unauthenticated denial-of-service.\n\nThe fix exits the loop on the first inner-decode error. It does not bound the loop length itself; for full coverage on untrusted inputs, also configure `Config.MaxSliceAllocSize` and `Config.MaxMapAllocSize` (the latter introduced in `v2.33.0`).\n\n## Description\n\nAvro arrays and maps are encoded as one or more blocks; each block declares an element count followed by that many encoded elements. The decoder reads the block count as a zigzag-encoded `long`, then iterates that many times calling an inner decoder.\n\nThree iteration sites trusted the block count without checking the reader\u0027s accumulated error state between iterations:\n\n- `codec_skip.go` `sliceSkipDecoder.Decode` \u2014 skip helper for arrays.\n- `codec_skip.go` `mapSkipDecoder.Decode` \u2014 skip helper for maps.\n- `reader_generic.go` `Reader.ReadArrayCB` and `Reader.ReadMapCB` \u2014 callback-based decoders used by generic and unmarshaling code paths.\n\nBecause the inner `Decode(nil, r)` call is a no-op when `r` has already errored (it returns immediately without consuming bytes), the loop would run to completion even after the first iteration\u0027s EOF. On `amd64` / `arm64`, `Reader.ReadBlockHeader` returns the count as `int` (= `int64`), so the loop bound is whatever the wire payload specified, up to `math.MaxInt64`. A modest 200-million-count payload (well under 2\u00b3\u00b9) already burns several seconds; a `math.MaxInt \u2212 2` payload (the value used in the regression test `TestDecoder_ArrayMultiBlockExceedsMaxInt` from PR #9) effectively pins the goroutine until external kill.\n\nThis overlaps with [`GHSA-mc57-h6j3-3hmv`](https://github.com/iskorotkov/avro/security/advisories/GHSA-mc57-h6j3-3hmv): the same large-block-count payload that drives the unbounded loop here also drives the cumulative-arithmetic overflow there (cross-platform), and on a 32-bit target additionally triggers the union-index / byte-slice narrowing.\n\n## Affected components\n\n| File | Function | PR | Fix commit |\n|------|----------|----|------------|\n| `codec_skip.go` | `sliceSkipDecoder.Decode` | \u2014 | [`b124caa`](https://github.com/iskorotkov/avro/commit/b124caa58a821f68f100d86f045f9753b88881e8) |\n| `codec_skip.go` | `mapSkipDecoder.Decode` | \u2014 | [`b124caa`](https://github.com/iskorotkov/avro/commit/b124caa58a821f68f100d86f045f9753b88881e8) |\n| `reader_generic.go` | `Reader.ReadArrayCB` | [#4](https://github.com/iskorotkov/avro/pull/4) | [`2ce4242`](https://github.com/iskorotkov/avro/commit/2ce4242e6095d93470ab3b37ed6082b0596f325c) |\n| `reader_generic.go` | `Reader.ReadMapCB` | [#4](https://github.com/iskorotkov/avro/pull/4) | [`2ce4242`](https://github.com/iskorotkov/avro/commit/2ce4242e6095d93470ab3b37ed6082b0596f325c) |\n\nThese are the audited and patched sites. Any other code path that iterates over an attacker-controlled count while calling a `Reader`-style decoder is structurally susceptible to the same pattern; reviewers of consumer code should grep for `for range l` / `for i := 0; i \u003c int(l); i++` near `Reader` method calls and confirm an in-loop error check.\n\n## Technical details\n\n**Vulnerable pattern:**\n\n```go\nfor range l {\n    d.decoder.Decode(nil, r)\n    // r.Error may have been set by Decode; loop continues regardless.\n}\n```\n\nAfter `r.Error != nil`, subsequent `Decode` calls short-circuit and return without consuming bytes or doing useful work, but the loop control variable still runs to `l`. With `l = math.MaxInt64`, the loop body executes ~9.2 \u00d7 10\u00b9\u2078 times \u2014 effectively infinite for any realistic timeout.\n\n**Fixed pattern** ([`b124caa`](https://github.com/iskorotkov/avro/commit/b124caa58a821f68f100d86f045f9753b88881e8), [`2ce4242`](https://github.com/iskorotkov/avro/commit/2ce4242e6095d93470ab3b37ed6082b0596f325c)):\n\n```go\nfor range l {\n    d.decoder.Decode(nil, r)\n    if r.Error != nil {\n        break\n    }\n}\n```\n\nThe fix terminates the loop on the first inner error. It does **not** bound `l` itself \u2014 a well-formed payload that actually contains `N` encoded `null` elements still iterates `N` times. The `MaxSliceAllocSize` / `MaxMapAllocSize` caps are the policy-level bound on that case (see Mitigation).\n\n## Fixed behavior\n\nThe reader\u0027s accumulated error is checked after every inner `Decode` in the four affected loops. Decoder errors now surface in O(1) iterations instead of O(blockCount) when the underlying read fails mid-stream.\n\n## Affected versions\n\n- `github.com/hamba/avro/v2` \u2014 all versions up to and including `v2.31.0` (repository is read-only upstream).\n- `github.com/iskorotkov/avro/v2` \u2014 all versions prior to `v2.33.0`.\n\n## Fixed versions\n\n`github.com/iskorotkov/avro/v2` `v2.33.0` and later. There is no upstream fix for `github.com/hamba/avro/v2` \u2014 module path is archived. Migrate to the fork as described under Mitigation.\n\n## Mitigation\n\nMigrate from `github.com/hamba/avro/v2` to `github.com/iskorotkov/avro/v2 \u003e= v2.33.0`. Replace the import path and run `go mod tidy`:\n\n```bash\ngo get github.com/iskorotkov/avro/v2@latest\n```\n\nOr, for consumers that prefer the original import path, a `replace` directive in `go.mod`:\n\n```\nreplace github.com/hamba/avro/v2 =\u003e github.com/iskorotkov/avro/v2 v2.33.0\n```\n\n`replace` is honoured only for the **main** module of a build \u2014 transitive consumers must add their own `replace`, or migrate the import path directly.\n\nThe error-propagation fix runs on the existing decode path and requires no configuration.\n\nFor defense-in-depth against well-formed but oversized payloads (where the fix above does not help, because no error fires), set explicit allocation caps:\n\n```go\ncfg := avro.Config{\n    MaxByteSliceSize:  102_400,\n    MaxSliceAllocSize: 10_000,\n    MaxMapAllocSize:   10_000,\n}.Freeze()\n\ndecoder := cfg.NewDecoder(schema, reader)\n```\n\n`MaxMapAllocSize` is new in `v2.33.0` and opt-in (default zero, which leaves the previous unbounded behavior). Without setting it, a producer that ships a `math.MaxInt64`-count block still consumes the corresponding memory and CPU; see [`GHSA-mx64-mj3q-7prj`](https://github.com/iskorotkov/avro/security/advisories/GHSA-mx64-mj3q-7prj) for the cumulative-allocation enforcement details.\n\nIf you cannot upgrade immediately, the structural workarounds are application-level: per-request decode timeouts, isolated decoder workers under CPU quotas, and rejection of payloads whose advertised block count exceeds a known sane bound for your schema.\n\n## Proof-of-concept input\n\nA minimal payload that triggers the bug for an array of `int`:\n\n```\nzigzag-encoded long: math.MaxInt64   (block element count)\nEOF                                  (no further bytes)\n```\n\nThe decoder reads the block-count header, enters the loop, fails to read the first element (EOF), records the error, and then iterates `math.MaxInt64 \u2212 1` further times calling the inner decoder as a no-op. Wall-clock cost on commodity hardware: indefinite \u2014 the goroutine pins one CPU core until the process is OOM-killed, deadline-cancelled, or terminated externally. The classic *\"a few seconds per request\"* characterisation applies only to small-but-still-pathological block counts in the 10\u2078\u201310\u2079 range (e.g. `200_999_000` in `TestDecoder_SkipArrayEOF`); the architectural ceiling is `math.MaxInt64`.\n\nA negative block count (`-N`) is also legal in Avro (signals an N-element block with an explicit byte length); the same iteration pattern applies once the count is negated.\n\n## References\n\n- Fix PR: [iskorotkov/avro#4](https://github.com/iskorotkov/avro/pull/4) (callback path)\n- Fix commits: [`b124caa`](https://github.com/iskorotkov/avro/commit/b124caa58a821f68f100d86f045f9753b88881e8) (skip helpers), [`2ce4242`](https://github.com/iskorotkov/avro/commit/2ce4242e6095d93470ab3b37ed6082b0596f325c) (callback path)\n- Release: [`v2.33.0`](https://github.com/iskorotkov/avro/releases/tag/v2.33.0)\n- Security policy: [`SECURITY.md`](https://github.com/iskorotkov/avro/blob/main/SECURITY.md)\n- Related advisories on this fork: [`GHSA-mc57-h6j3-3hmv`](https://github.com/iskorotkov/avro/security/advisories/GHSA-mc57-h6j3-3hmv) (integer overflow \u2014 same large-block-count payload also triggers cumulative-arithmetic overflow there), [`GHSA-mx64-mj3q-7prj`](https://github.com/iskorotkov/avro/security/advisories/GHSA-mx64-mj3q-7prj) (unbounded map allocation \u2014 the policy-level bound on well-formed huge inputs)\n- Cross-module precedent on `hamba/avro`: [`GO-2023-1930`](https://pkg.go.dev/vuln/GO-2023-1930) / `CVE-2023-37475` / `GHSA-9x44-9pgq-cf45`\n- Upstream (read-only): [`hamba/avro`](https://github.com/hamba/avro)\n\n## Credits\n\n- **Discovery and fixes** (commits `b124caa` skip helpers and `2ce4242` callback path, PR #4): Daniel B\u0142a\u017cewicz ([@klajok](https://github.com/klajok))\n- **Release authorship**: Ivan Korotkov ([@iskorotkov](https://github.com/iskorotkov))\n\n## Timeline\n\n- **2026-04-28** \u2014 Skip-decoder fix (`b124caa`) merged.\n- **2026-04-30** \u2014 Callback-decoder fix (PR #4, `2ce4242`) merged.\n- **2026-05-06** \u2014 `v2.33.0` tagged and released.\n- **2026-05-11** \u2014 Advisory published.\n- **2026-05-15** \u2014 Advisory revised.",
  "id": "GHSA-w8j3-pq8g-8m7w",
  "modified": "2026-06-09T10:32:33Z",
  "published": "2026-05-18T16:33:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/iskorotkov/avro/security/advisories/GHSA-w8j3-pq8g-8m7w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46385"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/iskorotkov/avro"
    }
  ],
  "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"
    },
    {
      "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": "iskorotkov/avro: CPU Exhaustion in Decoder"
}

GHSA-W8M9-7CW8-W84W

Vulnerability from github – Published: 2022-05-14 01:16 – Updated: 2022-05-14 01:16
VLAI
Details

The History implementation in WebKit in Apple iOS before 9.3, Safari before 9.1, and tvOS before 9.2 allows remote attackers to cause a denial of service (resource consumption and application crash) via a crafted web site.

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

{
  "affected": [],
  "aliases": [
    "CVE-2016-1784"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2016-03-24T01:59:00Z",
    "severity": "MODERATE"
  },
  "details": "The History implementation in WebKit in Apple iOS before 9.3, Safari before 9.1, and tvOS before 9.2 allows remote attackers to cause a denial of service (resource consumption and application crash) via a crafted web site.",
  "id": "GHSA-w8m9-7cw8-w84w",
  "modified": "2022-05-14T01:16:09Z",
  "published": "2022-05-14T01:16:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-1784"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/HT206166"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/HT206169"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/HT206171"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2016/Mar/msg00000.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2016/Mar/msg00002.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2016/Mar/msg00005.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1035353"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W8QV-6JWH-64R5

Vulnerability from github – Published: 2021-05-24 19:52 – Updated: 2021-05-20 22:03
VLAI
Summary
Regular Expression Denial of Service in browserslist
Details

The package browserslist from 4.0.0 and before 4.16.5 are vulnerable to Regular Expression Denial of Service (ReDoS) during parsing of queries.

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
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "browserslist"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.16.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-23364"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-20T22:03:36Z",
    "nvd_published_at": "2021-04-28T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The package browserslist from 4.0.0 and before 4.16.5 are vulnerable to Regular Expression Denial of Service (ReDoS) during parsing of queries.",
  "id": "GHSA-w8qv-6jwh-64r5",
  "modified": "2021-05-20T22:03:36Z",
  "published": "2021-05-24T19:52:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23364"
    },
    {
      "type": "WEB",
      "url": "https://github.com/browserslist/browserslist/pull/593"
    },
    {
      "type": "WEB",
      "url": "https://github.com/browserslist/browserslist/commit/c091916910dfe0b5fd61caad96083c6709b02d98"
    },
    {
      "type": "WEB",
      "url": "https://github.com/browserslist/browserslist/blob/e82f32d1d4100d6bc79ea0b6b6a2d281a561e33c/index.js%23L472-L474"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-1277182"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-BROWSERSLIST-1090194"
    }
  ],
  "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": "Regular Expression Denial of Service in browserslist"
}

GHSA-W8QW-X88F-F35R

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

The Symantec Encryption Management Server (SEMS) product, prior to version 3.4.2 MP1, may be susceptible to a denial of service (DoS) exploit. A DoS attack is a type of attack whereby the perpetrator attempts to make a particular machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a specific host within a network.

Severity
7.5 (High)
CVSS:3.0/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-2018-5243"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-08-20T18:29:00Z",
    "severity": "HIGH"
  },
  "details": "The Symantec Encryption Management Server (SEMS) product, prior to version 3.4.2 MP1, may be susceptible to a denial of service (DoS) exploit. A DoS attack is a type of attack whereby the perpetrator attempts to make a particular machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a specific host within a network.",
  "id": "GHSA-w8qw-x88f-f35r",
  "modified": "2022-05-14T02:21:24Z",
  "published": "2022-05-14T02:21:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5243"
    },
    {
      "type": "WEB",
      "url": "https://support.symantec.com/en_US/article.SYMSA1458.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105062"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1041527"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W8WR-7345-JPP3

Vulnerability from github – Published: 2026-08-28 18:31 – Updated: 2026-08-29 00:30
VLAI
Details

An issue in the with_argv function (/unistd/mod.rs) of relibc commit 61f42d allows attackers to cause a Denial of Service (DoS) via a crafted input.

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-2026-38638"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-28T16:17:47Z",
    "severity": "HIGH"
  },
  "details": "An issue in the with_argv function (/unistd/mod.rs) of relibc commit 61f42d allows attackers to cause a Denial of Service (DoS) via a crafted input.",
  "id": "GHSA-w8wr-7345-jpp3",
  "modified": "2026-08-29T00:30:58Z",
  "published": "2026-08-28T18:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-38638"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Marsman1996/pocs/tree/master/redox/CVE-2026-38638"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.redox-os.org/redox-os/relibc/-/issues/261"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/989"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.redox-os.org/redox-os/relibc/-/work_items/261"
    }
  ],
  "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"
    }
  ]
}
Mitigation
Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Mitigation
Architecture and Design
  • Mitigation of resource exhaustion attacks requires that the target system either:
  • The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
  • The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • recognizes the attack and denies that user further access for a given amount of time, or
  • uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Mitigation
Implementation

Ensure that all failures in resource allocation place the system into a safe posture.

CAPEC-147: XML Ping of the Death

An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.

CAPEC-227: Sustained Client Engagement

An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.

CAPEC-492: Regular Expression Exponential Blowup

An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.

← Back to the CWE list