Business::GoCardless versions before 1.01 for Perl accept forged webhooks when a configured webhook secret is undef or empty
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 1.01
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Business::GoCardless, a Perl module for the GoCardless payments API, can be affected by this vulnerability. When its webhook secret is unset or empty, it accepts forged webhook messages that an attacker has signed with an empty key, treating them as genuine notifications from GoCardless.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
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.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- Business-GoCardless
fixed in 1.01