CVE-2026-119037 in Business::GoCardless
Summary
by MITRE • 10/30/2026
Business::GoCardless versions before 1.01 for Perl accept forged webhooks when a configured webhook secret is undef or empty.
signature_valid uses each configured secret as the HMAC key, and nothing rejects undef or an empty string, both of which Digest::SHA treats as an empty key. A secret read from an unset environment variable, or an empty entry in a list of rotated secrets, is used as is.
A remote attacker can sign a forged webhook with an empty key and have it accepted as sent by GoCardless.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in the Business::GoCardless Perl module prior to version 1.01 represents a critical authentication bypass stemming from improper handling of cryptographic keys during webhook signature verification. Webhooks are commonly used to allow third-party services, such as payment processors like GoCardless, to push real-time data updates to an application's API endpoint. To ensure the integrity and authenticity of these incoming requests, developers typically employ HMAC-based signatures where a shared secret key is used to generate a hash that must match the one provided in the request headers. In this specific implementation, the signature validation logic relies on the Digest::SHA library to compute the expected HMAC value. However, the code fails to enforce strict input validation regarding the configured webhook secrets before they are passed as keys for hashing operations.
The core technical flaw lies within the signature_valid function which iterates through a list of potentially rotated or multiple configured secrets. The implementation does not check whether these secret values are defined or non-empty prior to their use in cryptographic calculations. When an environment variable is unset, it results in an undef value in Perl, and if a developer explicitly configures an empty string as one of the allowed secrets for rotation purposes, that empty string is also retained. The Digest::SHA module treats both undefined values and empty strings identically by using them as an empty key for HMAC generation. Consequently, any request signed with an empty key will produce a hash that matches the expected value calculated from an empty key, effectively allowing the signature verification to pass without requiring knowledge of the actual intended secret.
This behavior creates a severe security gap where remote attackers can forge valid-looking webhook requests by signing them with an empty HMAC key. Since the application accepts these forged signatures as legitimate communications from GoCardless, the attacker gains the ability to inject arbitrary data into the system under the guise of authorized events. This undermines the fundamental purpose of using webhooks for secure asynchronous communication and exposes downstream business logic to manipulation. The impact is particularly acute in financial or transactional contexts where webhook payloads trigger critical actions such as payment processing, account updates, or status changes based on unverified input data.
From a standards perspective, this vulnerability aligns with CWE-347 which describes Improper Verification of Cryptographic Signature. It also relates to CWE-287 regarding Improper Authentication because the system fails to properly verify the identity of the sender due to weak credential handling. In terms of MITRE ATT&CK techniques, this flaw facilitates Impair Defenses by allowing attackers to bypass security mechanisms that rely on signature verification and potentially supports Supply Chain Compromise if the forged webhooks trigger actions in connected systems or APIs. The lack of strict validation against empty credentials is a common pitfall in cryptographic implementations where developers assume configuration inputs are always valid and non-empty.
To mitigate this vulnerability, organizations must upgrade to Business::GoCardless version 1.01 or later which addresses the input validation logic. For environments unable to immediately patch, defensive coding practices should be implemented within custom wrapper functions that validate webhook secrets before passing them to the library. Developers must ensure that any secret used for HMAC verification is strictly checked for being defined and having a length greater than zero. Additionally, it is recommended to enforce strict configuration management policies where environment variables are validated at application startup to fail fast if required security credentials are missing or empty. Regular audits of cryptographic key handling should be conducted to prevent similar issues in other parts of the codebase that rely on shared secrets for integrity checks.