CVE-2026-119038 in GoCardless
Summary
by MITRE • 10/30/2026
Business::GoCardless versions before 1.01 for Perl complete redirect flows without checking the session token, letting a leaked redirect flow ID create payments against another customer's mandate.
confirm_resource takes no session token from the caller. It reads the redirect flow back from the GoCardless API and completes it with the token from that response, so the check that the flow is completed by the session that started it always passes. It then creates the requested payment or subscription against the flow's mandate. Since version 1.00, a flow that already has a mandate is returned as confirmed without being completed again, so the same ID creates a new payment on every call.
A remote attacker who obtains another customer's redirect flow ID can create payments or subscriptions against that customer's mandate.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in GoCardless Perl library versions prior to 1.01 represents a critical failure in session management and object reference validation, specifically within the logic handling OAuth2 authorization code exchange flows. The core technical flaw resides in the confirm_resource method, which is responsible for finalizing the redirect flow initiated by a user's authentication process. In a secure implementation, this step must strictly bind the incoming request to the specific session that originated it, typically through the validation of a state parameter or session token stored server-side. However, the affected code does not accept or verify any session token from the caller. Instead, it retrieves the redirect flow details directly from the GoCardless API using only the flow ID provided in the request parameters and then proceeds to complete that flow using the token returned by the external service. This architectural oversight means there is no mechanism to ensure that the entity initiating the completion of the flow is the same entity that started it, effectively bypassing any intended session affinity checks.
This design flaw leads directly to a severe business logic vulnerability where an attacker can manipulate payment mandates belonging to other users. Once a redirect flow ID is generated during a legitimate user's authentication process with GoCardless, this identifier becomes available in various contexts such as URL parameters or logs if not properly sanitized or secured. If a remote attacker obtains another customer's active redirect flow ID, they can invoke the confirm_resource method with that specific ID. Because the library blindly trusts the API response and does not cross-reference it against an internal session state, the system accepts the request as valid. Consequently, the library completes the payment authorization process for the victim's mandate without any further verification of user identity or intent. This allows the attacker to create unauthorized payments or subscriptions charged directly to the victim's bank account via their established mandate.
The impact is exacerbated by a specific behavior introduced in version 1.00 where flows that already possess an associated mandate are returned as confirmed without requiring re-completion. In earlier versions, completing a flow might have been idempotent only once or required explicit state transitions. However, with this change, the same redirect flow ID can be used repeatedly to trigger new payment creation events against the victim's mandate every time it is called by an attacker. This transforms what could potentially be a one-time unauthorized transaction into a persistent and repeatable vector for financial fraud. The lack of rate limiting or unique nonce validation in conjunction with this flaw means that automated scripts can rapidly generate multiple fraudulent transactions, leading to significant financial loss for the victims and potential liability issues for the merchant integrating the library.
From a classification perspective, this vulnerability aligns closely with CWE-285 Improper Authorization, as the application fails to enforce proper access controls when granting permissions to complete a payment flow. It also relates to CWE-613 Insufficient Session Expiration, given that the session token or state validation is entirely absent rather than merely expired incorrectly. In terms of the MITRE ATT&CK framework, this behavior facilitates Account Manipulation and potentially Financial Theft through unauthorized transaction initiation. The attacker leverages a leaked identifier to impersonate the legitimate user's intent within the payment gateway ecosystem, exploiting the trust relationship between the merchant application and the banking API without valid proof of session continuity.
Mitigation for organizations using affected versions requires an immediate upgrade to version 1.01 or later where this logic has been corrected. For systems that cannot be immediately updated, a temporary workaround involves implementing strict server-side validation of redirect flow IDs before they are passed to any library methods responsible for completing payments. This includes verifying that the flow ID corresponds to a session currently active on the web server and ensuring that no other pending flows exist for the same user within a short time window. Additionally, merchants should implement robust logging and monitoring for unusual patterns in payment creation requests, particularly those originating from unexpected IP addresses or occurring at high frequencies against single mandates. Enforcing strict CORS policies and securing redirect URIs to prevent leakage of flow identifiers through referrer headers or browser history is also essential to reduce the attack surface available to remote adversaries seeking to exploit this session validation failure.