Common Weakness Enumeration

CWE-835

Allowed

Loop with Unreachable Exit Condition ('Infinite Loop')

Abstraction: Base · Status: Incomplete

The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.

1052 vulnerabilities reference this CWE, most recent first.

GHSA-649X-HXFX-57J2

Vulnerability from github – Published: 2024-05-08 14:32 – Updated: 2024-05-10 21:33
VLAI
Summary
Vitess vulnerable to infinite memory consumption and vtgate crash
Details

Summary

When executing the following simple query, the vtgate will go into an endless loop that also keeps consuming memory and eventually will OOM.

Details

When running the following query, the evalengine will try evaluate it and runs forever.

select _utf16 0xFF

The source of the bug lies in the collation logic that we have. The bug applies to all utf16, utf32 and ucs2 encodings. In general, the bug is there for any encoding where the minimal byte length for a single character is more than 1 byte.

The decoding functions for these collations all implement logic like the following to enforce the minimal character length:

https://github.com/vitessio/vitess/blob/8f6cfaaa643a08dc111395a75a2d250ee746cfa8/go/mysql/collations/charset/unicode/utf16.go#L69-L71

The problem is that all the callers of DecodeRune expect progress by returning the number of bytes consumed. This means that if there's only 1 byte left in an input, it will here return still 0 and the caller(s) don't consume the character.

One example of such a caller is the following:

https://github.com/vitessio/vitess/blob/8f6cfaaa643a08dc111395a75a2d250ee746cfa8/go/mysql/collations/charset/convert.go#L73-L79

The logic here moves forward the pointer in the input []byte but if DecodeRune returns 0 in case of error, it will keep running forever. The OOM happens since it keeps adding the ? as the invalid character to the destination buffer infinitely, growing forever until it runs out of memory.

The fix here would be to always return forward progress also on invalid strings.

There's also a separate bug here that even if progress is guaranteed, select _utf16 0xFF will return the wrong result currently. MySQL will pad here the input when the _utf16 introducer is used with leading 0x00 bytes and then decode to UTF-16, resulting in the output of ÿ here.

PoC

select _utf16 0xFF

Impact

Denial of service attack by triggering unbounded memory usage.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/vitessio/vitess"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.0.0"
            },
            {
              "fixed": "19.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/vitessio/vitess"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "18.0.0"
            },
            {
              "fixed": "18.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/vitessio/vitess"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "17.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "vitess.io/vitess"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.17.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "vitess.io/vitess"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.18.0"
            },
            {
              "fixed": "0.18.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "vitess.io/vitess"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.19.0"
            },
            {
              "fixed": "0.19.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-32886"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-08T14:32:32Z",
    "nvd_published_at": "2024-05-08T14:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nWhen executing the following simple query, the `vtgate` will go into an endless loop that also keeps consuming memory and eventually will OOM.\n\n### Details\n\nWhen running the following query, the `evalengine` will try evaluate it and runs forever.\n\n```\nselect _utf16 0xFF\n```\n\nThe source of the bug lies in the collation logic that we have. The bug applies to all `utf16`,  `utf32` and `ucs2` encodings.  In general, the bug is there for any encoding where the minimal byte length for a single character is more than 1 byte.\n\nThe decoding functions for these collations all implement logic like the following to enforce the minimal character length:\n\nhttps://github.com/vitessio/vitess/blob/8f6cfaaa643a08dc111395a75a2d250ee746cfa8/go/mysql/collations/charset/unicode/utf16.go#L69-L71\n\nThe problem is that all the callers of `DecodeRune` expect progress by returning the number of bytes consumed. This means that if there\u0027s only 1 byte left in an input, it will here return still `0` and the caller(s) don\u0027t consume the character. \n\nOne example of such a caller is the following:\n\nhttps://github.com/vitessio/vitess/blob/8f6cfaaa643a08dc111395a75a2d250ee746cfa8/go/mysql/collations/charset/convert.go#L73-L79\n\nThe logic here moves forward the pointer in the input `[]byte` but if `DecodeRune` returns `0` in case of error, it will keep running forever. The OOM happens since it keeps adding the `?` as the invalid character to the destination buffer infinitely, growing forever until it runs out of memory.\n\nThe fix here would be to always return forward progress also on invalid strings. \n\nThere\u0027s also a separate bug here that even if progress is guaranteed, `select _utf16 0xFF` will return the wrong result currently. MySQL will pad here the input when the `_utf16` introducer is used with leading `0x00` bytes and then decode to UTF-16, resulting in the output of `\u00ff` here. \n\n### PoC\n\n```\nselect _utf16 0xFF\n```\n\n### Impact\n\nDenial of service attack by triggering unbounded memory usage.",
  "id": "GHSA-649x-hxfx-57j2",
  "modified": "2024-05-10T21:33:14Z",
  "published": "2024-05-08T14:32:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vitessio/vitess/security/advisories/GHSA-649x-hxfx-57j2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32886"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitessio/vitess/commit/2fd5ba1dbf6e9b32fdfdaf869d130066b1b5c0df"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitessio/vitess/commit/9df4b66550e46b5d7079e21ed0e1b0f49f92b055"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitessio/vitess/commit/c46dc5b6a4329a10589ca928392218d96031ac8d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitessio/vitess/commit/d438adf7e34a6cf00fe441db80842ec669a99202"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vitessio/vitess"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitessio/vitess/blob/8f6cfaaa643a08dc111395a75a2d250ee746cfa8/go/mysql/collations/charset/convert.go#L73-L79"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vitessio/vitess/blob/8f6cfaaa643a08dc111395a75a2d250ee746cfa8/go/mysql/collations/charset/unicode/utf16.go#L69-L71"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vitess vulnerable to infinite memory consumption and vtgate crash"
}

GHSA-65XW-VW82-R86X

Vulnerability from github – Published: 2026-03-29 15:19 – Updated: 2026-03-30 21:19
VLAI
Summary
XPath: Boolean expression infinite loop leads to denial of service via CPU exhaustion
Details

Boolean expressions that evaluate to true can cause an infinite loop in logicalQuery.Select, leading to 100% CPU usage. This can be triggered by top-level selectors such as "1=1" or "true()".

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/antchfx/xpath"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32287"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-29T15:19:45Z",
    "nvd_published_at": "2026-03-26T20:16:12Z",
    "severity": "HIGH"
  },
  "details": "Boolean expressions that evaluate to true can cause an infinite loop in logicalQuery.Select, leading to 100% CPU usage. This can be triggered by top-level selectors such as \"1=1\" or \"true()\".",
  "id": "GHSA-65xw-vw82-r86x",
  "modified": "2026-03-30T21:19:36Z",
  "published": "2026-03-29T15:19:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32287"
    },
    {
      "type": "WEB",
      "url": "https://github.com/antchfx/xpath/issues/121"
    },
    {
      "type": "WEB",
      "url": "https://github.com/golang/vulndb/issues/4526"
    },
    {
      "type": "WEB",
      "url": "https://github.com/antchfx/xpath/commit/afd4762cc342af56345a3fb4002a59281fcab494"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/antchfx/xpath"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-4526"
    },
    {
      "type": "WEB",
      "url": "https://securityinfinity.com/research/infinite-loop-dos-in-antchfx-xpath-logicalquery-select"
    }
  ],
  "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": "XPath: Boolean expression infinite loop leads to denial of service via CPU exhaustion"
}

GHSA-6729-2HP6-XXX8

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

In tinysvcmdns through 2018-01-16, a maliciously crafted mDNS (Multicast DNS) packet triggers an infinite loop while parsing an mDNS query. When mDNS compressed labels point to each other, the function uncompress_nlabel goes into an infinite loop trying to analyze the packet with an mDNS query. As a result, the mDNS server hangs after receiving the malicious mDNS packet. NOTE: the product's web site states "This project is un-maintained, and has been since 2013. ... There are known vulnerabilities ... You are advised to NOT use this library for any new projects / products."

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-9747"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-13T19:29:00Z",
    "severity": "HIGH"
  },
  "details": "In tinysvcmdns through 2018-01-16, a maliciously crafted mDNS (Multicast DNS) packet triggers an infinite loop while parsing an mDNS query. When mDNS compressed labels point to each other, the function uncompress_nlabel goes into an infinite loop trying to analyze the packet with an mDNS query. As a result, the mDNS server hangs after receiving the malicious mDNS packet. NOTE: the product\u0027s web site states \"This project is un-maintained, and has been since 2013. ... There are known vulnerabilities ... You are advised to NOT use this library for any new projects / products.\"",
  "id": "GHSA-6729-2hp6-xxx8",
  "modified": "2022-05-13T01:23:05Z",
  "published": "2022-05-13T01:23:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9747"
    },
    {
      "type": "WEB",
      "url": "https://bitbucket.org/geekman/tinysvcmdns/issues/11/denial-of-service-vulnerability-infinite"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-67RX-HJ63-9H2V

Vulnerability from github – Published: 2023-01-13 03:30 – Updated: 2023-01-23 18:30
VLAI
Details

Technitium DNS Server before 10.0 allows a self-CNAME denial-of-service attack in which a CNAME loop causes an answer to contain hundreds of records.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-48256"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-13T01:15:00Z",
    "severity": "HIGH"
  },
  "details": "Technitium DNS Server before 10.0 allows a self-CNAME denial-of-service attack in which a CNAME loop causes an answer to contain hundreds of records.",
  "id": "GHSA-67rx-hj63-9h2v",
  "modified": "2023-01-23T18:30:19Z",
  "published": "2023-01-13T03:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48256"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TechnitiumSoftware/DnsServer/blob/master/CHANGELOG.md#version-100"
    }
  ],
  "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-6976-M887-R48H

Vulnerability from github – Published: 2022-10-14 12:00 – Updated: 2025-05-15 21:31
VLAI
Details

A list management bug in BSS handling in the mac80211 stack in the Linux kernel 5.1 through 5.19.14 could be used by local attackers (able to inject WLAN frames) to corrupt a linked list and, in turn, potentially execute code.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-42721"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-14T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A list management bug in BSS handling in the mac80211 stack in the Linux kernel 5.1 through 5.19.14 could be used by local attackers (able to inject WLAN frames) to corrupt a linked list and, in turn, potentially execute code.",
  "id": "GHSA-6976-m887-r48h",
  "modified": "2025-05-15T21:31:14Z",
  "published": "2022-10-14T12:00:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42721"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=1204060"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=bcca852027e5878aec911a347407ecc88d6fff7f"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20230203-0008"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2022/dsa-5257"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/10/13/5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-698C-2X4J-G9GQ

Vulnerability from github – Published: 2022-05-14 01:10 – Updated: 2024-10-15 23:33
VLAI
Summary
Improper Restriction of Operations within the Bounds of a Memory Buffer in Apache Tomcat
Details

The HTTP/2 header parser in Apache Tomcat 9.0.0.M1 to 9.0.0.M11 and 8.5.0 to 8.5.6 entered an infinite loop if a header was received that was larger than the available buffer. This made a denial of service attack possible.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.0.0.M11"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0.M1"
            },
            {
              "fixed": "9.0.0.M12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.5.0"
            },
            {
              "fixed": "8.5.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2016-6817"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-119",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-06T19:47:31Z",
    "nvd_published_at": "2017-08-10T22:29:00Z",
    "severity": "HIGH"
  },
  "details": "The HTTP/2 header parser in Apache Tomcat 9.0.0.M1 to 9.0.0.M11 and 8.5.0 to 8.5.6 entered an infinite loop if a header was received that was larger than the available buffer. This made a denial of service attack possible.",
  "id": "GHSA-698c-2x4j-g9gq",
  "modified": "2024-10-15T23:33:07Z",
  "published": "2022-05-14T01:10:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-6817"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/079372fc7bac8e2e378942715c9ce26a4a72c07a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/85c63227edabbfb4f2f500fc557480a190135d21"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20200227174145/http://www.securityfocus.com/bid/94462"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20180115024458/http://www.securitytracker.com/id/1037330"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20180607-0001"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/b5e3f51d28cd5d9b1809f56594f2cf63dcd6a90429e16ea9f83bbedc@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/b5e3f51d28cd5d9b1809f56594f2cf63dcd6a90429e16ea9f83bbedc%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/a9f24571460af003071475b75f18cad81ebcc36fa7c876965a75e32a@%3Cannounce.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/a9f24571460af003071475b75f18cad81ebcc36fa7c876965a75e32a%40%3Cannounce.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/88855876c33f2f9c532ffb75bfee570ccf0b17ffa77493745af9a17a@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/88855876c33f2f9c532ffb75bfee570ccf0b17ffa77493745af9a17a%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/6af47120905aa7d8fe12f42e8ff2284fb338ba141d3b77b8c7cb61b3@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/6af47120905aa7d8fe12f42e8ff2284fb338ba141d3b77b8c7cb61b3%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/343558d982879bf88ec20dbf707f8c11255f8e219e81d45c4f8d0551@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/343558d982879bf88ec20dbf707f8c11255f8e219e81d45c4f8d0551%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/tomcat"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/94462"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1037330"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Restriction of Operations within the Bounds of a Memory Buffer in Apache Tomcat"
}

GHSA-6CP8-V795-JR2J

Vulnerability from github – Published: 2026-06-26 21:53 – Updated: 2026-06-26 21:53
VLAI
Summary
Hackney has an infinite loop on non-token byte at start of an Alt-Svc entry
Details

Summary

CVE-2026-47066 is an infinite loop (CWE-835) in hackney's Alt-Svc response header parser (src/hackney_altsvc.erl). When an HTTP server returns an Alt-Svc header whose value begins with a non-token byte (e.g. !, @, =, ;), the parser enters a tight tail-recursive loop that pins an Erlang scheduler at 100% CPU and permanently hangs the calling connection process. Because the parser is invoked synchronously on every HTTP response, any attacker-controlled origin can trigger the hang with a single-byte header value.

Details

1. Parser dispatch

parse_and_cache/3 is called inside the hackney connection process on each HTTP response. It collects all Alt-Svc header values via collect_altsvc_headers/1, concatenates them, and passes the result to parse/1, which calls parse_entries(Header, []).

2. Failed token consumption

parse_entries/2parse_entry/1parse_protocol/1parse_token(Data, <<>>). The function parse_token/2 pattern-matches leading bytes: alphanumeric, -, _, whitespace, and comma all have explicit clauses. Any other byte (e.g. !) falls through to the catch-all:

parse_token(Rest, <<>>) -> {undefined, Rest}.

This returns the input unchanged — no byte is consumed.

3. No-progress loop

parse_entry propagates {undefined, Rest} back to parse_entries/2, which calls skip_comma(Rest). Because the first byte is not ,, skip_comma also returns Rest unchanged. parse_entries then recurses with the identical buffer:

parse_entries(Data, Acc)  % Data identical to previous iteration

Erlang tail recursion never preempts on a pure CPU loop, so the scheduler is pinned and the process never yields or returns.

4. Root cause

parse_entries/2 has no guard that detects zero-byte progress after a failed parse_entry call and no fallback to advance past the offending byte.

PoC

  1. Start an HTTP server that responds with the header Alt-Svc: ! (any single non-token byte suffices).
  2. Issue any HTTP GET request via hackney to that server: erlang hackney:request(get, "http://attacker.example/", [], <<>>, [])
  3. Observe that the call never returns; the Erlang scheduler hosting the connection process is pinned at 100% CPU indefinitely.

Alternatively, call the parser directly: hackney_altsvc:parse(<<"!">>) — the process hangs immediately.

Impact

Denial of service via unbounded CPU consumption. Any application using hackney 2.0.0-beta.1 through 4.0.0 that connects to attacker-controlled HTTP endpoints is affected. No authentication is required; a single response header byte is sufficient to hang the connection process. Fixed in hackney 4.0.1. CVSS v4.0 score: 8.7 (HIGH).

Resources

  • Introduction commit: https://github.com/benoitc/hackney/commit/408e5fe20302226ea8c74dde2bcbd452d712b5b2
  • Patch commit: https://github.com/benoitc/hackney/commit/e548aba1f97ffa3f4750da7b772998fb78c01894
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "hackney"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "4.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47066"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T21:53:07Z",
    "nvd_published_at": "2026-05-25T15:16:21Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\n[CVE-2026-47066](https://nvd.nist.gov/vuln/detail/CVE-2026-47066) is an infinite loop (CWE-835) in hackney\u0027s Alt-Svc response header parser (`src/hackney_altsvc.erl`). When an HTTP server returns an `Alt-Svc` header whose value begins with a non-token byte (e.g. `!`, `@`, `=`, `;`), the parser enters a tight tail-recursive loop that pins an Erlang scheduler at 100% CPU and permanently hangs the calling connection process. Because the parser is invoked synchronously on every HTTP response, any attacker-controlled origin can trigger the hang with a single-byte header value.\n\n### Details\n\n**1. Parser dispatch**\n\n`parse_and_cache/3` is called inside the hackney connection process on each HTTP response. It collects all `Alt-Svc` header values via `collect_altsvc_headers/1`, concatenates them, and passes the result to `parse/1`, which calls `parse_entries(Header, [])`.\n\n**2. Failed token consumption**\n\n`parse_entries/2` \u2192 `parse_entry/1` \u2192 `parse_protocol/1` \u2192 `parse_token(Data, \u003c\u003c\u003e\u003e)`. The function `parse_token/2` pattern-matches leading bytes: alphanumeric, `-`, `_`, whitespace, and comma all have explicit clauses. Any other byte (e.g. `!`) falls through to the catch-all:\n\n```erlang\nparse_token(Rest, \u003c\u003c\u003e\u003e) -\u003e {undefined, Rest}.\n```\n\nThis returns the *input unchanged* \u2014 no byte is consumed.\n\n**3. No-progress loop**\n\n`parse_entry` propagates `{undefined, Rest}` back to `parse_entries/2`, which calls `skip_comma(Rest)`. Because the first byte is not `,`, `skip_comma` also returns `Rest` unchanged. `parse_entries` then recurses with the identical buffer:\n\n```erlang\nparse_entries(Data, Acc)  % Data identical to previous iteration\n```\n\nErlang tail recursion never preempts on a pure CPU loop, so the scheduler is pinned and the process never yields or returns.\n\n**4. Root cause**\n\n`parse_entries/2` has no guard that detects zero-byte progress after a failed `parse_entry` call and no fallback to advance past the offending byte.\n\n### PoC\n\n1. Start an HTTP server that responds with the header `Alt-Svc: !` (any single non-token byte suffices).\n2. Issue any HTTP GET request via hackney to that server:\n   ```erlang\n   hackney:request(get, \"http://attacker.example/\", [], \u003c\u003c\u003e\u003e, [])\n   ```\n3. Observe that the call never returns; the Erlang scheduler hosting the connection process is pinned at 100% CPU indefinitely.\n\nAlternatively, call the parser directly: `hackney_altsvc:parse(\u003c\u003c\"!\"\u003e\u003e)` \u2014 the process hangs immediately.\n\n### Impact\n\nDenial of service via unbounded CPU consumption. Any application using hackney 2.0.0-beta.1 through 4.0.0 that connects to attacker-controlled HTTP endpoints is affected. No authentication is required; a single response header byte is sufficient to hang the connection process. Fixed in hackney 4.0.1. CVSS v4.0 score: **8.7 (HIGH)**.\n\n## Resources\n\n* Introduction commit: https://github.com/benoitc/hackney/commit/408e5fe20302226ea8c74dde2bcbd452d712b5b2\n* Patch commit: https://github.com/benoitc/hackney/commit/e548aba1f97ffa3f4750da7b772998fb78c01894",
  "id": "GHSA-6cp8-v795-jr2j",
  "modified": "2026-06-26T21:53:07Z",
  "published": "2026-06-26T21:53:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/benoitc/hackney/security/advisories/GHSA-6cp8-v795-jr2j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47066"
    },
    {
      "type": "WEB",
      "url": "https://github.com/benoitc/hackney/commit/e548aba1f97ffa3f4750da7b772998fb78c01894"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2026-47066.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/benoitc/hackney"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2026-47066"
    }
  ],
  "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": "Hackney has an infinite loop on non-token byte at start of an Alt-Svc entry"
}

GHSA-6CR8-QX2W-7743

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

Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in the mod_proxy_ftp module in Apache HTTP Server with an attacker controlled backend FTP server.

This issue affects undefined: from 2.4.0 through 2.4.67.

Users are recommended to upgrade to version 2.4.68, which fixes the issue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-44186"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-08T16:16:40Z",
    "severity": "HIGH"
  },
  "details": "Loop with Unreachable Exit Condition (\u0027Infinite Loop\u0027) vulnerability in the mod_proxy_ftp module in Apache HTTP Server with an attacker controlled backend FTP server.\n\nThis issue affects undefined: from 2.4.0 through 2.4.67.\n\nUsers are recommended to upgrade to version 2.4.68, which fixes the issue.",
  "id": "GHSA-6cr8-qx2w-7743",
  "modified": "2026-06-09T15:32:08Z",
  "published": "2026-06-08T18:31:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44186"
    },
    {
      "type": "WEB",
      "url": "https://httpd.apache.org/security/vulnerabilities_24.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/06/08/13"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6CW3-G6WV-C2XV

Vulnerability from github – Published: 2022-02-04 00:00 – Updated: 2024-09-20 15:34
VLAI
Summary
Infinite Loop in Django
Details

An issue was discovered in MultiPartParser in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2. Passing certain inputs to multipart forms could result in an infinite loop when parsing files.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2"
            },
            {
              "fixed": "2.2.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2"
            },
            {
              "fixed": "3.2.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0"
            },
            {
              "fixed": "4.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-23833"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-02-04T16:30:27Z",
    "nvd_published_at": "2022-02-03T02:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in MultiPartParser in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2. Passing certain inputs to multipart forms could result in an infinite loop when parsing files.",
  "id": "GHSA-6cw3-g6wv-c2xv",
  "modified": "2024-09-20T15:34:07Z",
  "published": "2022-02-04T00:00:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23833"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/c477b761804984c932704554ad35f78a2e230c6a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/d16133568ef9c9b42cb7a08bdf9ff3feec2e5468"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/f9c7d48fdd6f198a6494a9202f90242f176e4fc9"
    },
    {
      "type": "WEB",
      "url": "https://docs.djangoproject.com/en/4.0/releases/security"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-6cw3-g6wv-c2xv"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/django/django"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2022-20.yaml"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#!forum/django-announce"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/B4SQG2EAF4WCI2SLRL6XRDJ3RPK3ZRDV"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220221-0003"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2022/dsa-5254"
    },
    {
      "type": "WEB",
      "url": "https://www.djangoproject.com/weblog/2022/feb/01/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: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": "Infinite Loop in Django"
}

GHSA-6CWX-5RQ4-6PX8

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

A vulnerability in the Simple Network Management Protocol (SNMP) subsystem of Cisco IOS XE Software could allow an authenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.

This vulnerability is due to improper error handling when parsing a specific SNMP request. An attacker could exploit this vulnerability by sending a specific SNMP request to an affected device. A successful exploit could allow the attacker to cause the device to reload unexpectedly, resulting in a DoS condition.

This vulnerability affects SNMP versions 1, 2c, and 3. To exploit this vulnerability through SNMPv2c or earlier, the attacker must know a valid read-write or read-only SNMP community string for the affected system. To exploit this vulnerability through SNMPv3, the attacker must have valid SNMP user credentials for the affected system.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-20312"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-24T18:15:34Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the Simple Network Management Protocol (SNMP) subsystem of Cisco IOS XE Software could allow an authenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.\n\n This vulnerability is due to improper error handling when parsing a specific SNMP request. An attacker could exploit this vulnerability by sending a specific SNMP request to an affected device. A successful exploit could allow the attacker to cause the device to reload unexpectedly, resulting in a DoS condition.\n\n This vulnerability affects SNMP versions 1, 2c, and 3. To exploit this vulnerability through SNMPv2c or earlier, the attacker must know a valid read-write or read-only SNMP community string for the affected system. To exploit this vulnerability through SNMPv3, the attacker must have valid SNMP user credentials for the affected system.",
  "id": "GHSA-6cwx-5rq4-6px8",
  "modified": "2025-09-24T18:30:31Z",
  "published": "2025-09-24T18:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20312"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snmpwred-x3MJyf5M"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.