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.

5412 vulnerabilities reference this CWE, most recent first.

GHSA-JH75-99HH-QVX9

Vulnerability from github – Published: 2024-08-07 15:30 – Updated: 2025-11-04 19:50
VLAI
Summary
Django memory consumption vulnerability
Details

An issue was discovered in Django 5.0 before 5.0.8 and 4.2 before 4.2.15. The floatformat template filter is subject to significant memory consumption when given a string representation of a number in scientific notation with a large exponent.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0"
            },
            {
              "fixed": "5.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2"
            },
            {
              "fixed": "4.2.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-41989"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-07T19:01:44Z",
    "nvd_published_at": "2024-08-07T15:15:56Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Django 5.0 before 5.0.8 and 4.2 before 4.2.15. The floatformat template filter is subject to significant memory consumption when given a string representation of a number in scientific notation with a large exponent.",
  "id": "GHSA-jh75-99hh-qvx9",
  "modified": "2025-11-04T19:50:26Z",
  "published": "2024-08-07T15:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41989"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/27900fe56f3d3cabb4aeb6ccb82f92bab29073a8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/fc76660f589ac07e45e9cd34ccb8087aeb11904b"
    },
    {
      "type": "WEB",
      "url": "https://docs.djangoproject.com/en/dev/releases/security"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/django/django"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2024-67.yaml"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#%21forum/django-announce"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240905-0007"
    },
    {
      "type": "WEB",
      "url": "https://www.djangoproject.com/weblog/2024/aug/06/security-releases"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Django memory consumption vulnerability"
}

GHSA-JH82-C5JW-PXPC

Vulnerability from github – Published: 2022-01-21 23:20 – Updated: 2024-10-08 12:36
VLAI
Summary
Denial of Service in Onionshare
Details

Between September 26, 2021 and October 8, 2021, Radically Open Security conducted a penetration test of OnionShare 2.4, funded by the Open Technology Fund's Red Team lab.

  • Vulnerability ID: OTF-012
  • Vulnerability type: Denial of Service
  • Threat level: Moderate

Description:

The receive mode limits concurrent uploads to 100 per second and blocks other uploads in the same second, which can be triggered by a simple script.

Technical description:

The following script uses GNU parallel and curl with around 6000 requests in parallel to send 10000 requests. A change in the ulimit -n configuration is required for it to work. This is sufficient to block file upload on a (public) receive instance.

seq 10000 | parallel --max-args 0 --jobs 6000 "curl -i -s -x socks5h://localhost:9150 -k -X $'POST' -H $'Host: csqrp3qciewvj5axph4o62jnr6aevhmpxfkydmi3256bprhbusr2ltid.onion' -H $'Accept-Encoding: gzip, deflate' -H $'Content-Type: multipart/form-data; boundary=---------------------------19182376703918074873375387042' -H $'Content-Length: 329' -H $'Connection: close' --data-binary $'-----------------------------19182376703918074873375387042\x0d\x0aContent-Disposition: form-data; name=\"file[]\"; filename=\"poc.txt\"\x0d\x0aContent-Type: text/plain\x0d\x0a\x0d\x0aA\x0d\x0a-----------------------------19182376703918074873375387042\x0d\x0aContent-Disposition: form-data; name=\"text\"\x0d\x0a\x0d\x0a\x0d\x0a-----------------------------19182376703918074873375387042--\x0d\x0a' $'http://csqrp3qciewvj5axph4o62jnr6aevhmpxfkydmi3256bprhbusr2ltid.onion/upload-ajax'"

Attack duration was around 80 seconds.

Cases where over 99 requests were sent per second:

Every 0.1s: ls | grep...   onionvm: Tue Oct 5 12:17:00 2021
78

Cases where files were successfully written to disk:

Every 0.1s: ls | wc -w   onionvm: Tue Oct 5 12:17:00 2021
8399

This means that during the attack time 1601 requests of 10000 were dropped. We tried to upload multiple files in the web interface during the attack and were not successful.

The failsafe is used to prevent creating more than 100 directories per second:

https://github.com/onionshare/onionshare/blob/d08d5f0f32f755f504494d80794886f346fbafdb/cli/onionshare_cli/web/receive_mode.py#L386-L427

The limit of 100 requests/second is significantly lower than the possible network bandwidth and greatly reduces the attack complexity for denial of service. Our test was conducted over the tor network, which showed no limitation for the required bandwidth.

Impact:

An adversary with access to the receive mode can block file upload for others. There is no way to block this attack in public mode due to the anonymity properties of the tor network.

Recommendation:

  • Remove this limitation, or
  • Derive directory name from milliseconds
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "onionshare-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-21689"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-01-19T18:48:07Z",
    "nvd_published_at": "2022-01-18T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "Between September 26, 2021 and October 8, 2021, [Radically Open Security](https://www.radicallyopensecurity.com/) conducted a penetration test of OnionShare 2.4, funded by the Open Technology Fund\u0027s [Red Team lab](https://www.opentech.fund/labs/red-team-lab/).\n\n- Vulnerability ID: OTF-012\n- Vulnerability type: Denial of Service\n- Threat level: Moderate\n\n## Description:\n\nThe receive mode limits concurrent uploads to 100 per second and blocks other uploads in the same second, which can be triggered by a simple script.\n\n## Technical description:\n\nThe following script uses GNU parallel and curl with around 6000 requests in parallel to send 10000 requests. A change in the `ulimit -n` configuration is required for it to work. This is sufficient to block file upload on a (public) receive instance.\n\n```\nseq 10000 | parallel --max-args 0 --jobs 6000 \"curl -i -s -x socks5h://localhost:9150 -k -X $\u0027POST\u0027 -H $\u0027Host: csqrp3qciewvj5axph4o62jnr6aevhmpxfkydmi3256bprhbusr2ltid.onion\u0027 -H $\u0027Accept-Encoding: gzip, deflate\u0027 -H $\u0027Content-Type: multipart/form-data; boundary=---------------------------19182376703918074873375387042\u0027 -H $\u0027Content-Length: 329\u0027 -H $\u0027Connection: close\u0027 --data-binary $\u0027-----------------------------19182376703918074873375387042\\x0d\\x0aContent-Disposition: form-data; name=\\\"file[]\\\"; filename=\\\"poc.txt\\\"\\x0d\\x0aContent-Type: text/plain\\x0d\\x0a\\x0d\\x0aA\\x0d\\x0a-----------------------------19182376703918074873375387042\\x0d\\x0aContent-Disposition: form-data; name=\\\"text\\\"\\x0d\\x0a\\x0d\\x0a\\x0d\\x0a-----------------------------19182376703918074873375387042--\\x0d\\x0a\u0027 $\u0027http://csqrp3qciewvj5axph4o62jnr6aevhmpxfkydmi3256bprhbusr2ltid.onion/upload-ajax\u0027\"\n```\n\nAttack duration was around 80 seconds.\n\nCases where over 99 requests were sent per second:\n\n```\nEvery 0.1s: ls | grep...   onionvm: Tue Oct 5 12:17:00 2021\n78\n```\n\nCases where files were successfully written to disk:\n\n```\nEvery 0.1s: ls | wc -w   onionvm: Tue Oct 5 12:17:00 2021\n8399\n```\n\nThis means that during the attack time 1601 requests of 10000 were dropped. We tried to upload multiple files in the web interface during the attack and were not successful.\n\nThe failsafe is used to prevent creating more than 100 directories per second:\n\nhttps://github.com/onionshare/onionshare/blob/d08d5f0f32f755f504494d80794886f346fbafdb/cli/onionshare_cli/web/receive_mode.py#L386-L427\n\nThe limit of 100 requests/second is significantly lower than the possible network bandwidth and greatly reduces the attack complexity for denial of service. Our test was conducted over the tor network, which showed no limitation for the required bandwidth.\n\n## Impact:\n\nAn adversary with access to the receive mode can block file upload for others. There is no way to block this attack in public mode due to the anonymity properties of the tor network.\n\n## Recommendation:\n\n- Remove this limitation, or\n- Derive directory name from milliseconds\n",
  "id": "GHSA-jh82-c5jw-pxpc",
  "modified": "2024-10-08T12:36:56Z",
  "published": "2022-01-21T23:20:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/onionshare/onionshare/security/advisories/GHSA-jh82-c5jw-pxpc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21689"
    },
    {
      "type": "WEB",
      "url": "https://github.com/onionshare/onionshare"
    },
    {
      "type": "WEB",
      "url": "https://github.com/onionshare/onionshare/releases/tag/v2.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/onionshare-cli/PYSEC-2022-40.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Denial of Service in Onionshare"
}

GHSA-JH93-VVQF-MFQC

Vulnerability from github – Published: 2025-01-21 21:30 – Updated: 2025-01-21 21:30
VLAI
Details

Vulnerability in the PeopleSoft Enterprise PeopleTools product of Oracle PeopleSoft (component: OpenSearch). Supported versions that are affected are 8.60 and 8.61. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise PeopleSoft Enterprise PeopleTools. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of PeopleSoft Enterprise PeopleTools. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-21545"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-21T21:15:20Z",
    "severity": "HIGH"
  },
  "details": "Vulnerability in the PeopleSoft Enterprise PeopleTools product of Oracle PeopleSoft (component: OpenSearch).  Supported versions that are affected are 8.60 and  8.61. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise PeopleSoft Enterprise PeopleTools.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of PeopleSoft Enterprise PeopleTools. CVSS 3.1 Base Score 7.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).",
  "id": "GHSA-jh93-vvqf-mfqc",
  "modified": "2025-01-21T21:30:56Z",
  "published": "2025-01-21T21:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21545"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2025.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JH99-8QR7-CF7M

Vulnerability from github – Published: 2022-07-02 00:00 – Updated: 2022-07-14 00:00
VLAI
Details

The simplepush server iterates through the application installations and pushes a notification to the server provided by deviceToken. But this is user controlled. If a bogus applications is registered with bad deviceTokens, one can generate endless exceptions when those endpoints can't be reached or can slow the server down by purposefully wasting it's time with slow endpoints. Similarly, one can provide whatever HTTP end point they want. This turns the server into a DDOS vector or an anonymizer for the posting of malware and so on.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2014-3648"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-01T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "The simplepush server iterates through the application installations and pushes a notification to the server provided by deviceToken. But this is user controlled. If a bogus applications is registered with bad deviceTokens, one can generate endless exceptions when those endpoints can\u0027t be reached or can slow the server down by purposefully wasting it\u0027s time with slow endpoints. Similarly, one can provide whatever HTTP end point they want. This turns the server into a DDOS vector or an anonymizer for the posting of malware and so on.",
  "id": "GHSA-jh99-8qr7-cf7m",
  "modified": "2022-07-14T00:00:17Z",
  "published": "2022-07-02T00:00:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-3648"
    },
    {
      "type": "WEB",
      "url": "https://issues.redhat.com/browse/AEROGEAR-6091"
    }
  ],
  "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-JHG6-6FPM-5P2R

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

A denial of service vulnerability in GitLab CE/EE affecting all versions since 11.8 allows an attacker to create a recursive pipeline relationship and exhaust resources.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-22181"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-11T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A denial of service vulnerability in GitLab CE/EE affecting all versions since 11.8 allows an attacker to create a recursive pipeline relationship and exhaust resources.",
  "id": "GHSA-jhg6-6fpm-5p2r",
  "modified": "2022-05-24T19:05:05Z",
  "published": "2022-05-24T19:05:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22181"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22181.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/249100"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-JHJG-W2CP-5J44

Vulnerability from github – Published: 2022-05-17 03:20 – Updated: 2024-09-18 19:53
VLAI
Summary
Django DoS in django.views.static.serve
Details

The django.views.static.serve view in Django before 1.4.18, 1.6.x before 1.6.10, and 1.7.x before 1.7.3 reads files an entire line at a time, which allows remote attackers to cause a denial of service (memory consumption) via a long line in a file.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6"
            },
            {
              "fixed": "1.6.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.7"
            },
            {
              "fixed": "1.7.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2015-0221"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-03T19:57:13Z",
    "nvd_published_at": "2015-01-16T16:59:00Z",
    "severity": "HIGH"
  },
  "details": "The `django.views.static.serve` view in Django before 1.4.18, 1.6.x before 1.6.10, and 1.7.x before 1.7.3 reads files an entire line at a time, which allows remote attackers to cause a denial of service (memory consumption) via a long line in a file.",
  "id": "GHSA-jhjg-w2cp-5j44",
  "modified": "2024-09-18T19:53:58Z",
  "published": "2022-05-17T03:20:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-0221"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/553779c4055e8742cc832ed525b9ee34b174934f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/818e59a3f0fbadf6c447754d202d88df025f8f2a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/d020da6646c5142bc092247d218a3d1ce3e993f7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/blob/9b9c805cedb08621bd5dc58a01a6478eb7cc49a9/docs/releases/1.4.18.txt#L48C1-L49C1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2015-6.yaml"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20150128111656/http://secunia.com/advisories/62285"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20150128111656/http://secunia.com/advisories/62309"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20150523054951/http://www.mandriva.com/en/support/security/advisories/advisory/MDVSA-2015:109/?name=MDVSA-2015:109"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20150523054953/http://www.mandriva.com/en/support/security/advisories/advisory/MDVSA-2015:036/?name=MDVSA-2015:036"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20151104201446/http://secunia.com/advisories/62718"
    },
    {
      "type": "WEB",
      "url": "https://www.djangoproject.com/weblog/2015/jan/13/security"
    },
    {
      "type": "WEB",
      "url": "http://advisories.mageia.org/MGASA-2015-0026.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2015-January/148485.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2015-January/148608.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2015-January/148696.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-updates/2015-04/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-updates/2015-09/msg00035.html"
    },
    {
      "type": "WEB",
      "url": "http://ubuntu.com/usn/usn-2469-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Django DoS in django.views.static.serve"
}

GHSA-JHP8-JFXV-5GGJ

Vulnerability from github – Published: 2026-02-12 00:31 – Updated: 2026-06-30 03:35
VLAI
Details

The issue was addressed with improved memory handling. This issue is fixed in macOS Tahoe 26.3, iOS 18.7.5 and iPadOS 18.7.5, visionOS 26.3, iOS 26.3 and iPadOS 26.3, Safari 26.3. A remote attacker may be able to cause a denial-of-service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-20652"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-120",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-11T23:16:08Z",
    "severity": "HIGH"
  },
  "details": "The issue was addressed with improved memory handling. This issue is fixed in macOS Tahoe 26.3, iOS 18.7.5 and iPadOS 18.7.5, visionOS 26.3, iOS 26.3 and iPadOS 26.3, Safari 26.3. A remote attacker may be able to cause a denial-of-service.",
  "id": "GHSA-jhp8-jfxv-5ggj",
  "modified": "2026-06-30T03:35:35Z",
  "published": "2026-02-12T00:31:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20652"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/126354"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/126353"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/126348"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/126347"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/126346"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-20652.json"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2448793"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-20652"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:9692"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:22136"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19535"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19206"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:16695"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:16056"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:14659"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:13845"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:11814"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:11329"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:10702"
    }
  ],
  "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-JHQP-VF4W-RPWQ

Vulnerability from github – Published: 2022-06-21 22:51 – Updated: 2022-06-21 22:51
VLAI
Summary
DoS through large manifest files in Argo CD
Details

Impact

All versions of Argo CD starting with v0.7.0 are vulnerable to an uncontrolled memory consumption bug, allowing an authorized malicious user to crash the repo-server service. The repo-server is a critical component of Argo CD, so crashing the repo-server effectively denies core Argo CD services (such as syncing Application updates).

To achieve denial of service, the attacker must be an authenticated Argo CD user authorized to deploy Applications from a repository which contains (or can be made to contain) a large file.

Patches

A patch for this vulnerability has been released in the following Argo CD versions:

  • v2.4.1
  • v2.3.5
  • v2.2.10
  • v2.1.16

The patch introduces a new reposerver.max.combined.directory.manifests.size config parameter, which you should tune before upgrading in production. It caps the maximum total file size of .yaml/.yml/.json files in directory-type (raw manifest) Applications. The default max is 10M per Application. This max is designed to keep any single app from consuming more than 3G of memory in the repo-server (manifests consume more space in memory than on disk). The 300x ratio assumes a maliciously-crafted manifest file. If you only want to protect against accidental excessive memory use, it is probably safe to use a smaller ratio.

If your organization uses directory-type Applications with very many manifests or very large manifests then check the size of those manifests and tune the config parameter before deploying this change to production. When testing, make sure to do a "hard refresh" in either the CLI or UI to test your directory-type App. That will make sure you're using the new max logic instead of relying on cached manifest responses from Redis.

Workarounds

There is no workaround besides upgrading.

To mitigate the issue, carefully limit 1) who can configure repos (determined by RBAC), 2) which repos are allowed (determined by Project limitations), and 3) who has push access to those repos (determined by your SCM provider configuration).

Credits

Disclosed by ADA Logics in a security audit of the Argo project sponsored by CNCF and facilitated by OSTIF. Thanks to Adam Korczynski and David Korczynski for their work on the audit.

For more information

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.8.7"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.7.0"
            },
            {
              "fixed": "2.1.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.4.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2022-31016"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-21T22:51:05Z",
    "nvd_published_at": "2022-06-25T08:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAll versions of Argo CD starting with v0.7.0 are vulnerable to an uncontrolled memory consumption bug, allowing an authorized malicious user to crash the [repo-server](https://argo-cd.readthedocs.io/en/stable/operator-manual/architecture/#repository-server) service. The repo-server is a critical component of Argo CD, so crashing the repo-server effectively denies core Argo CD services (such as syncing Application updates).\n\nTo achieve denial of service, the attacker must be an authenticated Argo CD user authorized to deploy Applications from a repository which contains (or can be made to contain) a large file. \n\n### Patches\n\nA patch for this vulnerability has been released in the following Argo CD versions:\n\n* v2.4.1\n* v2.3.5\n* v2.2.10\n* v2.1.16\n\n**The patch introduces a new `reposerver.max.combined.directory.manifests.size` config parameter, which you should tune before upgrading in production.** It caps the maximum total file size of .yaml/.yml/.json files in directory-type (raw manifest) Applications. The default max is `10M` per Application. This max is designed to keep any single app from consuming more than 3G of memory in the repo-server (manifests consume more space in memory than on disk). The 300x ratio assumes a maliciously-crafted manifest file. If you only want to protect against accidental excessive memory use, it is probably safe to use a smaller ratio.\n\nIf your organization uses directory-type Applications with very many manifests or very large manifests then **check the size of those manifests and tune the config parameter before deploying this change to production**. When testing, make sure to do a \"hard refresh\" in either the CLI or UI to test your directory-type App. That will make sure you\u0027re using the new max logic instead of relying on cached manifest responses from Redis.\n\n### Workarounds\n\nThere is no workaround besides upgrading.\n\nTo mitigate the issue, carefully limit 1) who can configure repos (determined by [RBAC](https://argo-cd.readthedocs.io/en/stable/getting_started/)), 2) which repos are allowed (determined by [Project](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/) limitations), and 3) who has push access to those repos (determined by your SCM provider configuration).\n\n### Credits\n\nDisclosed by ADA Logics in a security audit of the Argo project sponsored by CNCF and facilitated by OSTIF. Thanks to Adam Korczynski and David Korczynski for their work on the audit.\n\n### For more information\n\n* Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)\n* Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd\n",
  "id": "GHSA-jhqp-vf4w-rpwq",
  "modified": "2022-06-21T22:51:05Z",
  "published": "2022-06-21T22:51:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-jhqp-vf4w-rpwq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31016"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/argoproj/argo-cd"
    }
  ],
  "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": "DoS through large manifest files in Argo CD"
}

GHSA-JHV8-V22G-62JM

Vulnerability from github – Published: 2025-11-11 18:30 – Updated: 2025-11-11 18:30
VLAI
Details

Uncontrolled resource consumption for some Gaudi software before version 1.21.0 within Ring 3: User Applications may allow a denial of service. System software adversary with an authenticated user combined with a low complexity attack may enable denial of service. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (none) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-27249"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-11T17:15:45Z",
    "severity": "MODERATE"
  },
  "details": "Uncontrolled resource consumption for some Gaudi software before version 1.21.0 within Ring 3: User Applications may allow a denial of service. System software adversary with an authenticated user combined with a low complexity attack may enable denial of service. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (none) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.",
  "id": "GHSA-jhv8-v22g-62jm",
  "modified": "2025-11-11T18:30:18Z",
  "published": "2025-11-11T18:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27249"
    },
    {
      "type": "WEB",
      "url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01374.html"
    }
  ],
  "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:X/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"
    }
  ]
}

GHSA-JHWX-MHWW-RGC3

Vulnerability from github – Published: 2024-03-29 19:04 – Updated: 2024-03-29 19:04
VLAI
Summary
ArgoCD's repo server has Uncontrolled Resource Consumption vulnerability
Details

Impact

All versions of ArgoCD starting from v2.4 have a bug where the ArgoCD repo-server component is vulnerable to a Denial-of-Service attack vector. Specifically, it's possible to crash the repo server component through an out of memory error by pointing it to a malicious Helm registry. The loadRepoIndex() function in the ArgoCD's helm package, does not limit the size nor time while fetching the data. It fetches it and creates a byte slice from the retrieved data in one go. If the registry is implemented to push data continuously, the repo server will keep allocating memory until it runs out of it.

Patches

A patch for this vulnerability has been released in the following Argo CD versions:

v2.10.5 v2.9.10 v2.8.14

For more information

If you have any questions or comments about this advisory:

Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd

Credits

This vulnerability was found & reported by Jakub Ciolek

The Argo team would like to thank these contributors for their responsible disclosure and constructive communications during the resolve of this issue

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.8.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.9.0"
            },
            {
              "fixed": "2.9.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.10.0"
            },
            {
              "fixed": "2.10.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-29893"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-29T19:04:27Z",
    "nvd_published_at": "2024-03-29T15:15:12Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nAll versions of ArgoCD starting from v2.4 have a bug where the ArgoCD repo-server component is vulnerable to a Denial-of-Service attack vector. Specifically,  it\u0027s possible to crash the repo server component through an out of memory error by pointing it to a malicious Helm registry.\nThe loadRepoIndex() function in the ArgoCD\u0027s helm package, does not limit the size nor time while fetching the data. It fetches it and creates a byte slice from the retrieved data in one go. If the registry is implemented to push data continuously, the repo server will keep allocating memory until it runs out of it.\n\n### Patches\nA patch for this vulnerability has been released in the following Argo CD versions:\n\nv2.10.5\nv2.9.10\nv2.8.14\n\n### For more information\nIf you have any questions or comments about this advisory:\n\nOpen an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)\nJoin us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd\n\n\n### Credits\nThis vulnerability was found \u0026 reported by Jakub Ciolek\n\nThe Argo team would like to thank these contributors for their responsible disclosure and constructive communications during the resolve of this issue",
  "id": "GHSA-jhwx-mhww-rgc3",
  "modified": "2024-03-29T19:04:27Z",
  "published": "2024-03-29T19:04:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-jhwx-mhww-rgc3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29893"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/commit/14f681e3ee7c38731943b98f92277e88a3db109d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/commit/36b8a12a38f8d92d55bffc81deed44389bf6eb59"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/commit/3e5a878f6e30d935fa149723ea2a2e93748fcddd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/argoproj/argo-cd"
    }
  ],
  "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": "ArgoCD\u0027s repo server has Uncontrolled Resource Consumption vulnerability"
}

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.