CVE-2026-119548 in Lago
Summary
by MITRE • 10/30/2026
Lago through 1.55.0 contains an authorization bypass vulnerability in Invoices::Payments::StripeService that allows users of one organization to mark another organization's invoice as paid due to an unscoped invoice lookup. Attackers controlling their organization's Stripe integration can sign a payment_intent.succeeded event carrying a victim invoice UUID to unlock wallet top-ups or payment-gated subscriptions.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in Lago versions through 1.55.0 represents a critical authorization bypass within the Invoices::Payments::StripeService component, specifically affecting how Stripe webhook events are processed and validated against organizational boundaries. This flaw stems from an unscoped invoice lookup mechanism that fails to enforce strict ownership checks when handling payment intent success notifications. In a multi-tenant SaaS architecture like Lago, where distinct organizations maintain isolated data sets including invoices, subscriptions, and wallet balances, the integrity of these boundaries is paramount for both security and financial accuracy. The absence of proper scoping allows an attacker who controls their own organization's Stripe integration to manipulate this service by injecting malicious webhook payloads that reference invoice identifiers belonging to a victim organization rather than their own.
From a technical perspective, the core issue lies in the retrieval logic used when processing stripe.payment_intent.succeeded events. When such an event is received, the system attempts to locate the corresponding invoice record using only the UUID provided in the payload without verifying that this invoice belongs to the tenant associated with the Stripe account triggering the webhook. This lack of cross-referencing between the authenticated context of the incoming request and the ownership attribute of the target resource creates a classic Insecure Direct Object Reference (IDOR) scenario, which is formally categorized under CWE-639 in industry standards for vulnerability classification. By exploiting this gap, an attacker can effectively impersonate legitimate payment processing actions on behalf of other tenants within the same Lago instance.
The operational impact of this vulnerability is severe and directly affects financial integrity and service availability. An attacker with control over their organization's Stripe credentials can sign a forged or manipulated payment_intent.succeeded event containing the UUID of an invoice belonging to another organization. Upon successful processing by the vulnerable service, the system will mark that external invoice as paid, even though no actual funds were transferred from the victim organization. This unauthorized state change unlocks wallet top-ups for the attacker's account if those credits are tied to payment completion or allows access to subscription tiers and features that require active billing status. Consequently, this leads to direct financial loss through unearned service usage by the attacker while potentially causing revenue leakage for the affected victims who may not realize their invoices have been incorrectly settled until audit time.
This attack vector aligns with MITRE ATT&CK techniques related to privilege escalation and resource hijacking, specifically leveraging valid API endpoints or webhook handlers to perform unauthorized actions within a trusted context. The exploitation requires only that the attacker has access to configure Stripe webhooks for their own organization, which is often a standard administrative capability granted to account owners or developers in SaaS platforms. This lowers the barrier to entry significantly compared to vulnerabilities requiring remote code execution or complex injection attacks, making it a high-risk issue for any multi-tenant deployment of Lago prior to version 1.56.0 where this logic was presumably corrected by implementing strict tenant-scoped queries during invoice retrieval.
To mitigate this vulnerability and prevent similar issues in the future, immediate patching to version 1.56.0 or later is required if available. For organizations unable to upgrade immediately, manual code review of the Invoices::Payments::StripeService class should be conducted to ensure that all database queries for invoice records include a condition verifying that the record's organization_id matches the tenant context derived from the authenticated Stripe account or webhook signature verification process. Additionally, implementing strict input validation on incoming webhook payloads is essential; systems must never trust client-supplied identifiers without server-side authorization checks. Security teams should also monitor logs for unusual patterns of invoice status changes originating from unexpected IP addresses or associated with organizations that have not initiated corresponding payment intents in their own Stripe dashboards, as this may indicate active exploitation attempts.