CVE-2026-113811
Algorithm::UrataniTakeda versions from 0.1.5 before 0.1.7 for Perl allow memory exhaustion via a never-cleared failure shift cache in search
CVSS
—
Sin CVSS
EPSS
—
KEV
—
Exploit Today
—
0-100
Publicado: 21 oct 2026 · Última mod.: 22 oct 2026 · CWE-770
Sin historial EPSS suficiente todavía.
Algorithm::UrataniTakeda versions from 0.1.5 before 0.1.7 for Perl allow memory exhaustion via a never-cleared failure shift cache in search. The failure shift is cached for each pair of trie state and text character in a field of the matcher object, and nothing clears it. A character not seen before at a given state adds an entry that lasts for the life of the matcher. An attacker who can submit text with many distinct characters to a long-lived matcher can grow its memory with each search.
- github.comhttps://github.com/robrwo/perl-Algorithm-UrataniTakeda/commit/79897ef86a5a9bb6bc381718fe977c8150bc3d5b.patch
- github.comhttps://github.com/robrwo/perl-Algorithm-UrataniTakeda/security/advisories/GHSA-9vcx-647w-pr3h
- metacpan.orghttps://metacpan.org/release/RRWO/Algorithm-UrataniTakeda-v0.1.7/changes
- www.openwall.comhttp://www.openwall.com/lists/oss-security/2026/10/21/27
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-86696——
———Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.
esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.
This issue affects esaml: from 0.1.0 onward.13hCVE-2026-105270——
———Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.
esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.
This issue affects esaml: from 0.1.0 onward.15hCVE-2026-1147315.3 MED—
———Roundcube Webmail before 1.6.20 and 1.7.x before 1.7.5 is affected by an uncontrolled resource consumption vulnerability in the CSS proxy (the utils/modcss action). The fetched stylesheet was read into memory in full, with no size limit and no read timeout, so a stylesheet URL referencing an attacker-controlled host could be used to exhaust server memory. Upstream fixed this in the commit “Add a size limit to the CSS proxy content processing”, which caps the response at 5 MB, reads it as a stream and applies a read timeout.19hCVE-2026-963775.3 MED—
———Allocation of Resources Without Limits or Throttling vulnerability in Drupal Combined image style allows Excessive Allocation. This issue affects Combined image style versions: from 0.0.0 to 1.0.7.7hCVE-2026-963657.5 ALT—
———Allocation of Resources Without Limits or Throttling vulnerability in Drupal Webform allows Excessive Allocation. This issue affects Webform versions: from 0.0.0 to 6.2.12, from 6.3.0 to 6.3.1.7hCVE-2026-1147233.7 BAJ—
———Roundcube Webmail before 1.6.20 and 1.7.x before 1.7.5 allows the ImageMagick resource limits to be bypassed during thumbnail generation. When rcube_image falls back to GD, the available-memory check was applied only on Windows, so on other platforms a crafted image with large dimensions was processed by GD without any resource limit and could exhaust server memory. Upstream fixed this in the commit “Fix ImageMagick resource limits bypass by GD fallback during thumbnail generation”, which applies the memory check on all platforms.20h