CVE-2026-123660 in Vulnerability-Lookup
Summary
by MITRE • 11/06/2026
In Vulnerability-Lookup 5.5.1 up to but not including 6.4.1, a signed-in user could make the server allocate memory far out of proportion to their input through a webhook notification's payload template. Each placeholder's format specifier was passed unchanged to Python's string formatting, which builds the padded result before its size can be checked. A template of a few dozen bytes, such as {"text": "{title:>999999999}"}, therefore produced a string of about 1 GB when the notification form test-rendered it on save, and repeating such fields multiplied the cost. Templates that passed the save check could also repeat placeholders such as {text} thousands of times; the notification daemon rebuilt those on every webhook delivery. Deeply nested templates raised an unhandled recursion error (HTTP 500). An attacker needs only an account, which the default configuration lets anyone create after e-mail confirmation. They could exhaust the memory of web workers or the notification daemon, causing a denial of service. Version 6.4.1 caps every number in a format specifier at 256, limits a rendered template to 1,000,000 characters both on save and at delivery, and rejects templates nested deeper than 32 levels.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/06/2026
The vulnerability identified in Vulnerability-Lookup versions 5.5.1 through 6.4.1 represents a critical resource exhaustion flaw rooted in improper input validation within the webhook notification system. This issue allows authenticated users to trigger disproportionate memory allocation on the server side, leading to potential denial of service conditions. The core technical failure lies in how Python's string formatting engine processes format specifiers contained within template payloads. When a user submits a notification template containing specific padding directives, such as right-alignment with an excessive width value like {title:>999999999}, the underlying string construction mechanism attempts to build the padded result immediately before any size constraints can be applied or checked. This architectural oversight means that even a small input payload of merely a few dozen bytes can force the server to allocate approximately one gigabyte of memory during the test-render phase when saving the template.
The impact is further exacerbated by the ability to replicate these placeholders within a single template and by the operational behavior of the notification daemon. Attackers could construct templates that repeat placeholder fields thousands of times, which would then be rebuilt with every webhook delivery event rather than just once at save time. This multiplicative effect significantly increases the resource consumption per request. Additionally, deeply nested template structures trigger unhandled recursion errors resulting in HTTP 500 responses, indicating a lack of depth validation for recursive operations. The severity of this vulnerability is heightened by the default configuration settings which allow any individual to create an account after simple email confirmation. Consequently, no authentication bypass or privilege escalation is required; any registered user can exploit these flaws to exhaust the memory resources of web workers or the notification daemon, effectively disrupting service availability for all users.
From a classification perspective, this vulnerability aligns with CWE-789: Memory Allocation with Excessive Size Value and CWE-400: Uncontrolled Resource Consumption. The exploitation technique involves manipulating format specifiers to force excessive memory usage, which is characteristic of server-side request forgery patterns where the attacker controls input that dictates resource allocation magnitude. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1496: Resource Hijacking, specifically through CPU or Memory Exhaustion, as well as aspects of T1059: Command and Scripting Interpreter if considering the broader context of template injection mechanisms often associated with such flaws. The vulnerability demonstrates how improper handling of dynamic string formatting can lead to significant availability impacts when input validation is insufficiently robust against maliciously crafted payloads.
Mitigation strategies implemented in version 6.4.1 address these issues through strict quantitative limits and structural constraints. The update caps every number within a format specifier at a maximum value of two hundred fifty-six, preventing the creation of excessively large padded strings during initial rendering. Furthermore, it enforces a hard limit on rendered templates to one million characters both during the save operation and at delivery time, ensuring that even repeated placeholders cannot consume disproportionate memory resources. To address the recursion issue, the system now rejects templates with nesting depths exceeding thirty-two levels. These controls effectively neutralize the attack vectors by limiting the magnitude of resource allocation per request and preventing infinite or excessively deep recursive processing loops. Organizations running affected versions must upgrade to 6.4.1 or later to restore service stability and prevent unauthorized users from causing denial of service through memory exhaustion attacks.