Description

Ghostfolio is an open source wealth management software. Prior to version 3.4.0, Ghostfolio's Stripe checkout success-URL handler at `GET /api/v1/subscription/stripe/callback?checkoutSessionId=<id>` retrieves the Stripe Checkout Session by ID and unconditionally grants a Premium subscription to the session's `client_reference_id` — without ever checking `session.payment_status` or `session.status`. There is no separate Stripe webhook endpoint with `stripe-signature` verification; this callback is the sole code path that creates Stripe-driven subscriptions. Any authenticated user can self-grant a 1-year Premium subscription without ever paying. Version 3.4.0 rejects sessions unless `session.payment_status === 'paid'` AND `session.status === 'complete'` (fails closed). Additionally, new unique `stripeCheckoutSessionId` column → a session can't be redeemed twice (race-safe via DB unique constraint).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-07T23:17:03.400Z",
  "pubdate": "2026-08-07T23:17:03.400Z",
  "executiveSummary": "Ghostfolio prior to version 3.4.0 suffers from an improper authorization and payment verification vulnerability within its Stripe checkout success-handler mechanism located at GET /api/v1/subscription/stripe/callback?checkoutSessionId=<id>.\nThe vulnerability allows any authenticated user to self-grant an unauthorized 1-year Premium subscription without executing a valid financial transaction.\nThe root cause stems from the application retrieving the Stripe Checkout Session by its identifier and unconditionally granting the subscription to the client_reference_id without validating essential session state properties such as session.payment_status or session.status.\nBecause the application lacks a secondary Stripe webhook endpoint utilizing cryptographic stripe-signature verification, this callback serves as the sole code path responsible for provisioning Stripe-driven subscriptions.\nThe business impact involves financial loss and unauthorized access to premium feature sets.\nExploitation requires active authentication within the affected system and the ability to interact with the specified API endpoint using arbitrary or manipulated checkout session identifiers, with no prior payment required.",
  "technicalDetails": "The vulnerability resides in the Ghostfolio subscription provisioning logic exposed via the GET /api/v1/subscription/stripe/callback?checkoutSessionId=<id> URL handler.\nAffected software versions comprise all Ghostfolio installations prior to version 3.4.0.\nThe vulnerable component is responsible for processing the return redirection from Stripe after an attempted checkout process.\nFrom a root cause perspective, the application logic queries the Stripe API to retrieve a Checkout Session object using the supplied checkoutSessionId query parameter but fails to evaluate the payment and completion states of that session.\nSpecifically, the code omits checks for session.payment_status (such as ensuring it equals 'paid') and session.status (such as ensuring it equals 'complete').\nConsequently, an attacker with standard authenticated user privileges can supply any valid or constructed session identifier from Stripe—even one associated with an unpaid, abandoned, or canceled checkout session—and the application will unconditionally assign a 1-year Premium subscription to the client_reference_id associated with that session.\nThe attack flow proceeds as follows: First, the attacker initiates or identifies a Stripe Checkout Session. Second, the attacker invokes the GET /api/v1/subscription/stripe/callback endpoint, passing the target checkoutSessionId. Third, the backend queries Stripe, retrieves the session metadata without validating payment parameters, and immediately provisions the subscription to the user account tied to the client_reference_id. Furthermore, the absence of a database-enforced unique constraint prior to version 3.4.0 allowed previously used session identifiers to be repeatedly redeemed or abused across accounts.\nThe vulnerability is exposed over the network via standard HTTP protocols, requires standard user authentication to invoke the API route, and demands no elevated administrative privileges."
}