CVE-2026-105850: Race Condition and Order Double-Processing in @payloadcms/plugin-ecommerce

The vulnerability exists within the @payloadcms/plugin-ecommerce package, which is a key component of the Payload CMS e-commerce ecosystem. This plugin handles the direct integration between storefront checkout interfaces and external payment gateways, specifically focusing on the Stripe payment adapter. The order confirmation validation pipeline acts as the final gatekeeper that reconciles completed payments with database models.

Under normal operations, when a consumer completes a checkout flow, the payment gateway issues a webhook or a direct client-side callback to finalize the transaction. The backend must securely transition the transaction status, generate a corresponding order record, update associated inventories, and reset the active cart. This makes the confirmation endpoint a critical attack surface, handling complex state transitions and external data processing.

This vulnerability is classified under CWE-837 (Improper Enforcement of a Single, Unique Action) and has a CVSS v4.0 score of 8.8. The core issue lies in the reliance on sequential, non-atomic database operations to process order creation and transaction state transitions. An attacker or a high-concurrency event can exploit this behavior to force multiple orders to process against a single valid financial payment.

A visual overview of the vulnerable sequential flow versus the secured atomic check-and-set flow is outlined below:

The root cause of CVE-2026-105850 lies in a classic Time-of-Check to Time-of-Use (TOCTOU) race condition within the Stripe payment adapter. In the affected version of the plugin, the confirmOrder endpoint processed incoming state change requests using a sequence of standard, non-atomic database reads and updates. When a webhook or client API call occurred, the system evaluated the transaction's current status inside the application layer.

Once the status of a transaction was verified as pending, the execution thread sequentially performed distinct database writes. First, it executed payload.create to insert a new document into the orders collection. Second, it updated the associated cart to register the purchase. Finally, it modified the transaction document itself to bind the new order ID and set the status value to succeeded.

Because these operations were not wrapped in an isolated database transaction or bound by an atomic lock, concurrent threads could execute parallel reads before any single thread could complete the subsequent state write. When two requests executed the preliminary verification checks concurrently, both identified the transaction status as pending and both proceeded to create distinct order documents.

This design flaw exposed the platform to order duplication, incorrect stock levels, and mismatched financial balances. The database engine accepted multiple sequential updates to the same transaction entity, allowing multiple successfully created order identifiers to be associated with a single original transaction reference in rapid succession.

The core patch implemented in commit 6c0c4dc9b4ce1ac87b03fbb5dd7356b8559cbc4e eliminates the TOCTOU gap by introducing an atomic database-level state machine. Instead of using separate reads and writes, the patched code employs the database driver's native atomic update capabilities to claim the transaction status before performing any application-level business logic.

The primary remediation introduces the finalizeTransactionOrder function, which performs a structured compare-and-set operation. This query targets the database layer directly to set the transaction status to processing in an atomic fashion.

// Atomic transaction claim query introduced in the patch
const claimedTransaction = await req.payload.db.updateOne({
  collection: transactionsSlug,
  data: { status: 'processing' },
  options: { atomic: true },
  req,
  where: {
    and: [
      { id: { equals: transactionID } },
      { status: { equals: 'pending' } },
      { order: { exists: false } },
    ],
  },
});

If the update operation returns a null document, the application recognizes that another concurrent thread has already claimed the transaction. The thread then drops out of the creation flow and runs a retry polling loop (waitForCanonicalOrder) to wait for the winning thread to write the completed order. This fail-closed and polling architecture ensures only one canonical order is generated while preserving the API response for secondary parallel requests.

Below is the sequence flow of the newly implemented atomic settlement and wait loop mechanism:

Exploiting this race condition does not require authentication or specific system configurations. An attacker merely needs to target the checkout confirmation route with rapid, concurrent request streams. The main prerequisite is a valid Stripe paymentIntentID which is naturally obtained by completing a payment or initiating a valid checkout session.

To perform the attack, an adversary uses a multi-threaded HTTP client or a specialized intercepting proxy. After completing the Stripe checkout flow, the attacker intercepts the client-to-server call directed at the endpoint /api/payments/stripe/confirm-order. Instead of letting the single request pass, the attacker clones the payload containing the paymentIntentID and cartID.

Using a single-packet attack framework or a high-concurrency request generator, the attacker transmits these cloned requests simultaneously to the target server. Because of the sequential database write timing gap, multiple execution threads process the requests concurrently.

The target system responds by creating duplicate order documents in the database. For each successfully processed request, the system triggers subsequent downstream actions such as payment capture confirmations, order confirmation emails, and inventory decrement actions. This allows the attacker to purchase a limited item while triggering multiple shipments, or to completely drain the vendor's physical inventory allocations.

The impact of CVE-2026-105850 is highly critical for e-commerce platforms using Payload CMS. First, the vulnerability directly compromises the system's operational integrity. Duplicate order generation forces warehouse operations to receive contradictory processing tasks, leading to duplicate physical shipments, financial losses, and overhead costs associated with inventory recovery.

Second, the vulnerability causes critical inventory state inconsistencies. In standard configurations, each order document creation decrements physical stock counters. When multiple concurrent orders are validated against a single payment, stock counts are decremented multiple times. This can cause stock levels to drop below zero, blocking legitimate consumers from purchasing items that are incorrectly reported as out of stock.

Furthermore, the vulnerability breaks transactional audit logging. Financial auditing and standard compliance frameworks require a strict one-to-one mapping between financial transactions (e.g., Stripe Payment Intents) and fulfillment invoices. If multiple orders point to the same payment ID, automated accounting programs will fail to reconcile balances, requiring expensive and time-consuming manual intervention.

Remediating this vulnerability requires a combination of library upgrades, custom code refactoring, and database schema migrations. The primary fix is to upgrade the parent payload monorepo and the @payloadcms/plugin-ecommerce package to version 3.90.0 or higher. For teams running the 4.x canary branch, they must upgrade to 4.0.0-canary.34 or higher.

Because the patch introduces a new transaction state enum value (processing), PostgreSQL-backed deployments require a structured database migration. Developers must execute the payload migration CLI to generate and apply the required schema adjustments immediately after updating dependencies.

If your deployment uses a custom payment adapter, you must ensure that it does not call the database directly to write order documents. The custom adapter's confirmOrder function must be updated to invoke the newly introduced, core-provided finalizeOrder callback. This guarantees that any custom integration automatically gains the protection of the compare-and-set claim mechanism and the safe polling retry loops.

Additionally, organizations should implement application monitoring to detect potential exploitation attempts. Search application logs for database write conflicts on the transactions collection or look for transactions that remain stuck in the processing state indefinitely, which may occur if an application server crashed mid-execution of the winning thread.