CVE-2026-70589: Improper Status Validation in Ghost CMS Offer Redemption

The affected component is Ghost's subscription and membership offering subsystem. This component manages portal sign-ups, membership levels, pricing tiers, and promotional discounts. When a user requests to subscribe to a paid tier, the backend system dynamically generates a payment session and communicates the details to the external payment gateway (Stripe).

Prior to the patch, this subsystem allowed unauthenticated remote users to redeem promotional codes and offers that were deactivated or archived. By exposing an API endpoint that processes raw inputs directly, Ghost became vulnerable to business logic bypasses. The attack surface is completely public-facing, meaning anyone on the internet with access to the checkout page can trigger this logical oversight.

The vulnerability is classified under CWE-20 (Improper Input Validation) with a CVSS 3.1 base score of 4.8. The main impact is financial and operational, as it allows unauthorized users to sign up for membership tiers at discounted prices that administrators had intended to terminate. Although it does not expose sensitive operating system capabilities, it directly disrupts the economic integrity of CMS deployments utilizing Ghost's membership modules.

The core of the vulnerability lies in a logic gap within the backend database retrieval workflow. In Ghost CMS, promotional discounts are stored as 'Offers' with distinct states. When a site administrator chooses to disable or deprecate an offer, its database field status transitions from 'active' to 'archived' or another equivalent inactive value.

When a checkout process is initialized, the application controller handles the validation of parameters such as tierId and offerId. However, the server-side logic in unpatched versions only checked whether the database query successfully retrieved an offer record. It did not evaluate whether that record's status field permitted active redemptions.

Because deactivated or archived offers are preserved in the database to maintain relational integrity for historical billing and transaction logs, the query always successfully located the record. Lacking any status validation, the controller took the discount metadata from the archived offer and supplied it to the payment gateway session. This created an operational route where an obsolete promotion could be applied repeatedly to new subscriptions.

The vulnerability resides in the controller responsible for resolving payment checkout sessions, specifically located at ghost/core/core/server/services/members/members-api/controllers/router-controller.js. The vulnerable logical flow took the validated parameters from the input request and proceeded to apply them to the checkout data builder without validating state transition rules.

Below is the code diff of the patch implemented in version 6.54.1, illustrating the addition of explicit state verification:

@@ -467,6 +467,13 @@ module.exports = class RouterController {
                 });
             }
 
+            if (offer.status && offer.status !== 'active') {
+                throw new BadRequestError({
+                    message: tpl(messages.offerArchived),
+                    context: 'Offer with id "' + offerId + '" is no longer active'
+                });
+            }
+
             if (!offer.tier) {
                 throw new BadRequestError({
                     message: 'Offer does not have a tier'

The inserted verification block acts as a barrier directly after the record retrieval phase. The if conditional checks whether the offer.status field is present and strictly verifies if its value deviates from the 'active' string state. If the condition is met, the application invokes the localized translation layer and throws a standard HTTP 400 BadRequestError, terminating the execution flow prior to Stripe checkout generation.

While this fix successfully blocks basic programmatic redemption of inactive offers, developers must ensure that the returned offer object always includes the status field. If subsequent API variations or queries yield partial objects where status is omitted or undefined, the expression evaluates to falsy, bypassing the entire validation block.

To exploit this flaw on an unpatched Ghost instance, an attacker must first obtain a valid but inactive offerId. These identifiers can often be scraped from web search archives, historical social media advertisements, client-side caches, or prior subscription receipts. Alternatively, if predictable naming structures or sequence patterns are utilized for campaigns, an attacker can attempt brute-force enumeration.

Once an inactive ID is obtained, the attacker navigates to the registration interface and initiates the checkout process. Using a local interception proxy, the outbound payment initialization request is intercepted before hitting the Ghost API. The attacker then injects the inactive identifier into the HTTP POST request payload.

{
  "tierId": "prod_example123",
  "offerId": "archived_offer_id_abc"
}

Because the vulnerable server fails to validate the offer's current status, it resolves the archived promotional data and generates a valid Stripe checkout URL incorporating the discount. The server returns this URL in the HTTP response body. The attacker then follows the link to finalize the payment on Stripe's domain, successfully securing the discounted subscription terms.

The primary impact of CVE-2026-70589 is economic degradation and unauthorized access to premium subscription tiers. Attackers can bypass billing tier requirements, allowing them to purchase high-value membership plans at reduced prices or even for free, depending on the discount parameters of the archived offer.

The vulnerability is assigned a CVSS v3.1 base score of 4.8. The CVSS vector string is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N. The attack complexity is rated as High because it requires gathering or guessing a valid inactive identifier. Privileges required and user interaction are both rated as None since the checkout endpoints are accessible to unauthenticated public visitors.

There is a low confidentiality impact, as an attacker can confirm the existence of legacy promotions and pricing structures that were meant to remain hidden. Availability remains completely unaffected by this vulnerability, as it does not trigger memory corruption, deadlocks, or server resource exhaustion.

The primary remediation path is upgrading the Ghost installation to version 6.54.1 or newer. This upgrade introduces the required backend validation blocks to block checkout initialization when inactive promotional IDs are passed.

If an immediate upgrade is not feasible, administrators can implement a defense-in-depth mitigation strategy at the payment gateway level. Because Ghost's internal offers correspond directly to Coupon entities inside Stripe, administrators can navigate to their Stripe Dashboard, review their active and inactive coupons, and manually delete or archive any obsolete coupon codes. This ensures that even if a vulnerable Ghost server successfully generates a session payload with an old discount code, Stripe's payment API will reject the transaction.

Additionally, security teams can implement detection mechanisms. For instance, Web Application Firewalls (WAF) can be configured to monitor the rate of requests directed to /members/api/checkout/ to prevent automated brute-forcing or enumeration of potential offerId strings.