CVE-2026-6879
`Element.findall()` and fully-consumed `Element.iterfind()` exhibit `O(n^2)` time complexity when using XPath index predicates (e.g. `[1]`,
CVSS
—
No CVSS
EPSS
0.4%
p31
KEV
—
Exploit Today
9
0-100
Published: Jul 28, 2026 · Last modified: Aug 13, 2026 · CWE-407
0.4%EPSS · 30 days0.4%
2026-08-202026-09-18
`Element.findall()` and fully-consumed `Element.iterfind()` exhibit `O(n^2)` time complexity when using XPath index predicates (e.g. `[1]`, `[last()]`, `[last()-N]`) on XML documents with many same-tag siblings. `Element.find()` is only affected when the first match is near the end of the sibling list, such as with `[last()]` or `[last()-N]`; `.//item[1]` short-circuits after the first match.
- github.comhttps://github.com/python/cpython/commit/02c08e6b747ac43d0d866a4ffa916bedf3423f81
- github.comhttps://github.com/python/cpython/commit/037965c00a427cba5c05447efadc67c51a492e85
- github.comhttps://github.com/python/cpython/commit/0583f24ae678993e3f7939f51ad5bcae5ad9dc70
- github.comhttps://github.com/python/cpython/commit/2ffab083782968a4d732738f4f1dff6bbd69d2b0
- github.comhttps://github.com/python/cpython/commit/390337b8ba1658833fdef379e1739c9f9533a8db
- github.comhttps://github.com/python/cpython/commit/96510a3758f4a075f43223afdee3b6ee1a7a7f02
- github.comhttps://github.com/python/cpython/commit/cb409342a19f25656f62e679f8bac265fe1442c3
- github.comhttps://github.com/python/cpython/issues/152674
- github.comhttps://github.com/python/cpython/pull/152676
- mail.python.orghttps://mail.python.org/archives/list/security-announce@python.org/thread/7YMZ6DDZVR26TJJBVO3RDNBAVGHNYAKR/
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-82760—43.5%
——13Inefficient Algorithmic Complexity vulnerability in team-alembic AshAuthentication allows an unauthenticated attacker to exhaust CPU and memory via an oversized base62 segment in a submitted API key.
AshAuthentication.Base.decode62/1 in lib/ash_authentication/base.ex splits its argument into one binary per character and folds it with charval62/2, which recomputes Integer.pow(62, index) at every position instead of accumulating by Horner's method, so cost grows roughly cubically in the input length. bindecode62/1 in the same module is quadratic through Integer.undigits/2 and Integer.digits/2. Neither function caps byte_size/1, and AshAuthentication.Strategy.ApiKey.SignInPreparation passes the underscore-separated segments of the submitted key straight into both, before any key lookup and without prior authentication. The surrounding rescue clauses catch exceptions, not CPU or memory exhaustion.
This issue affects ash_authentication: from 4.8.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.3hCVE-2026-196685.3 MED34.4%
——10A BIND recursive resolver may experience excessive resource consumption if it encounters large numbers of a particular kind of invalid DNSSEC record. Default limits on "max-records-per-type" and "max-types-per-name" help mitigate the exposure.
This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.2dCVE-2026-923654.3 MED32.6%
——10A vulnerability was found in vllm-project vllm up to 0.29.0. Affected by this issue is some unknown functionality of the file vllm/v1/sample/thinking_budget_state.py. The manipulation results in inefficient algorithmic complexity. It is possible to launch the attack remotely. The pull request to fix this issue awaits acceptance.2dCVE-2026-920915.9 MED41.6%
——12A flaw was found in jwcrypto. The JWK.import_key() function validates the key_ops JWK member for duplicate values using an algorithm with O(n^2) time complexity, and the length of key_ops is not bounded. A remote, unauthenticated attacker can supply a JWK with a large key_ops array to an application that passes attacker-controlled key material to a public key-import API (reachable via ECDH-ES key agreement, OIDC dynamic client registration, DPoP, or ACME account key registration, among others) to consume excessive CPU time, resulting in a denial of service.2dCVE-2026-49250—22.4%
——7Conform, a type-safe form validation library, allows the parsing of nested objects in the form of object.property. From 1.8.0 until 1.19.4, the parseSubmission future API in packages/conform-dom/formdata.ts repeatedly scans FormData or URLSearchParams entries by each unique field name. An unauthenticated attacker can submit a crafted form containing many unique names, causing excessive synchronous CPU work and denial of service in an application that passes the submission to parseSubmission. Applications should continue to enforce request parsing limits before invoking Conform. This issue is fixed in version 1.19.4.4dCVE-2026-863494.3 MED12.4%
——4Mattermost versions 11.9.x <= 11.9.0, 11.8.x <= 11.8.4, 11.7.x <= 11.7.8, 10.11.x <= 10.11.22 fail to limit the nesting depth in the server-side Markdown parser which allows an authenticated attacker to cause a denial of service (CPU resource exhaustion) via a crafted post containing deeply nested blockquotes or list items.. Mattermost Advisory ID: MMSA-2026-007072d