CVE-2026-119036 in Business::GoCardless
Summary
by MITRE • 10/30/2026
Business::GoCardless versions before 1.01 for Perl allow memory exhaustion by flattening legacy webhook payloads before checking their signature.
A webhook body with a top-level "payload" key is verified as a legacy webhook. To rebuild the signed string, the payload is flattened into one key and value pair per leaf, each key carrying the full path to that leaf, and the pairs are then encoded, sorted and joined. A long key holding a long array costs memory proportional to the key length times the array length.
A remote attacker can exhaust memory in the process receiving webhooks with a single request that carries no valid signature.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in GoCardless Perl library versions prior to 1.01 represents a significant resource exhaustion risk stemming from improper handling of legacy webhook payloads during cryptographic verification processes. This flaw is categorized under CWE-787, which denotes out-of-bounds write or access, although the primary manifestation here is memory consumption leading to denial of service rather than arbitrary code execution via buffer overflow. The attack vector aligns with ATT&CK technique T1496, Resource Hijacking, specifically through environmental exploitation where an attacker consumes system resources to degrade availability. In modern API architectures, webhooks are critical for asynchronous communication between services, and the integrity verification step is a standard security control intended to ensure that incoming requests originate from trusted sources. However, in this specific implementation, the order of operations creates a fatal flaw by performing expensive data transformation before validating the authenticity of the request.
The technical root cause lies in the sequence of operations executed when processing webhook bodies containing a top-level payload key, which identifies them as legacy webhooks requiring special handling. To verify the signature, the system must reconstruct the signed string from the original JSON structure. The library achieves this by flattening the nested JSON object into a flat list of key-value pairs, where each key represents the full path to its corresponding leaf node in the hierarchy. These keys are then encoded, sorted alphabetically, and joined together with delimiters before being hashed against the provided signature. While this approach ensures deterministic ordering for consistent hashing, it fails to account for the computational cost associated with deeply nested or large data structures. Specifically, when a payload contains an array of significant length at any depth within the JSON structure, the flattening process generates one key-value pair per element in that array. Each generated key includes the full path string from the root down to that specific leaf node.
This design leads to quadratic memory growth relative to both the depth of nesting and the size of arrays contained within the payload. For instance, if a webhook contains an array with thousands or millions of elements located deep within the JSON structure, the system must allocate memory for each individual key string in addition to the value itself. Since every element inherits the full path length as its key prefix, the total memory footprint becomes proportional to the product of the number of items and the length of their respective paths. A remote attacker can exploit this by crafting a single webhook request that includes a large array nested within the payload structure but deliberately omits or provides an invalid signature. Because the library processes the entire payload into its flattened representation before checking whether the signature matches, it consumes substantial amounts of RAM during the transformation phase regardless of the eventual verification outcome.
The operational impact of this vulnerability is severe for any service relying on GoCardless webhooks to process financial data updates. An attacker can trigger a denial-of-service condition by sending multiple such malformed requests concurrently or sequentially. This results in memory exhaustion, which may cause the application server to crash, become unresponsive, or be terminated by operating system resource limits such as OOM killers. In cloud environments, this could lead to increased costs due to auto-scaling triggers responding to perceived high load caused by CPU spikes during serialization and sorting operations, even though no legitimate business logic is being executed. The lack of signature validation prior to processing means that the service expends resources on malicious traffic without any gatekeeping mechanism to filter out unauthorized requests early in the request lifecycle.
Mitigation strategies must address both the immediate code flaw and broader architectural resilience practices. The primary remediation involves upgrading to GoCardless library version 1.01 or later, where this ordering issue has been resolved by validating signatures before performing expensive data transformations such as flattening. If an upgrade is not immediately feasible, developers should implement a pre-validation layer that checks the signature using a lightweight method if possible, or restricts webhook payload sizes through strict schema validation and size limits at the reverse proxy or API gateway level. Additionally, implementing rate limiting on webhook endpoints can mitigate the impact of volumetric attacks designed to exhaust resources. It is also advisable to review other parts of the application for similar patterns where data processing occurs before authentication checks, ensuring that computational costs are not incurred for unverified requests across all integrations.