Lago EUVD-2026-113813

Exploitation requires the attacker to be an authenticated Lago user who controls their own organization's Stripe integration, enabling them to sign a valid payment_intent.succeeded webhook event with their own Stripe signing secret. It further requires knowledge of the target's specific invoice UUID, which is a random identifier that is not enumerable and must be obtained or leaked separately - this is the primary limiting factor (reflected as AC:H/AT:P). The core defect is that Invoices::Payments::StripeService resolves the invoice without scoping the lookup to the requesting organization, so a cross-organization UUID is accepted. Impact is limited to integrity: marking another organization's invoice as paid to unlock wallet top-ups or payment-gated subscriptions; there is no confidentiality or availability impact. No fixed version is listed in the available sources.

All decision signals point to a low real-world priority. The input CVSS 4.0 base score is 2.3 (Low), and my independent assessment agrees: AV:N but AC:H, AT:P, and PR:L mean exploitation is network-reachable yet gated behind meaningful prerequisites. The attacker must be a legitimate authenticated Lago user who controls their own organization's Stripe integration (PR:L) and must supply a specific victim invoice UUID (AT:P / AC:H) - invoice UUIDs are random and not enumerable, which is the dominant limiting factor. Impact is confined to integrity (VI:L): an invoice is fraudulently marked paid, unlocking wallet top-ups or payment-gated subscriptions, with no confidentiality or availability loss. The vuln.today Decision label is 'monitor', consistent with this low-severity, high-prerequisite profile. No EPSS score and no KEV status are provided in the input, and no fixed version is listed in the available sources; absence of EPSS/KEV is not evidence either way. Reporting comes from VulnCheck with a VulnCheck advisory plus an abraxaslabs research write-up and direct source-code line references, so the mechanism is well-documented. This is a genuine but low-urgency authorization flaw, not a mass-exploitation threat - the UUID requirement and the need for a configured attacker-side Stripe integration keep it targeted rather than widespread.

An authenticated attacker operating their own Lago organization configures their organization's Stripe integration and then crafts a payment_intent.succeeded webhook event signed with their own Stripe signing secret, embedding a victim organization's invoice UUID. Because Invoices::Payments::StripeService looks up the invoice without scoping it to the attacker's organization, Lago marks the victim's invoice as paid, unlocking wallet top-ups or payment-gated subscriptions without any real payment. A public technical write-up (abraxaslabs) and a VulnCheck advisory describe the flaw, and the vulnerable code lines are referenced directly; however, no verified working exploit code is confirmed in the input.