CVE-2026-34210: mppx Auth Bypass Vulnerability

CVE-2026-34210 Overview

A payment replay attack vulnerability has been identified in mppx, a TypeScript interface for the machine payments protocol. Prior to version 0.4.11, the stripe/charge payment method failed to validate Stripe's Idempotent-Replayed response header when creating PaymentIntents. This oversight allowed attackers to replay valid credentials containing the same spt token against new challenges, enabling unauthorized resource consumption without additional charges.

Critical Impact
Attackers can pay once and consume unlimited resources by replaying payment credentials, resulting in significant financial losses for service providers and potential service abuse.

Affected Products

mppx versions prior to 0.4.11
Applications using the stripe/charge payment method in mppx
Services implementing machine payments protocol via mppx

Discovery Timeline

2026-03-31 - CVE CVE-2026-34210 published to NVD
2026-04-01 - Last updated in NVD database

Technical Details for CVE-2026-34210

Vulnerability Analysis

This vulnerability (CWE-697: Incorrect Comparison) stems from insufficient validation of payment processing responses. The mppx library's Stripe integration creates PaymentIntents to process transactions but failed to check whether Stripe was responding with a replayed payment rather than a newly processed one. Stripe's API includes an Idempotent-Replayed header specifically designed to indicate when a response is being replayed from a previous identical request.

Without checking this header, the server cannot distinguish between a legitimate new payment and a replayed one. An attacker who captures a valid payment credential with an spt token can resubmit that credential against subsequent challenges. The server would process each replay as a successful payment, granting access to resources without actually charging the customer again.

Root Cause

The root cause is the absence of idempotency verification in the payment flow. The Stripe client type definition in src/stripe/internal/types.ts did not include the lastResponse object containing response headers, making it impossible for downstream code to access the Idempotent-Replayed header. Consequently, the Charge.ts payment handler had no mechanism to detect and reject replayed PaymentIntents.

Attack Vector

The attack exploits the network-accessible payment processing endpoint. An attacker with low privileges (a valid payment credential) can:

Complete a legitimate payment transaction and capture the spt token
Monitor for new resource challenges from the server
Replay the captured credential against new challenges
Gain unlimited resource access since the server accepts replayed payments as valid

The following patch from the security fix commit shows the type definition update to expose response headers:

typescript

  */
 export type StripeClient = {
   paymentIntents: {
-    create(...args: any[]): Promise<{ id: string; status: string }>
+    create(...args: any[]): Promise<{
+      id: string
+      status: string
+      lastResponse?: { headers?: Record<string, string> }
+    }>
   }
 }

Source: GitHub Commit Update

The following patch shows the replay detection logic added to src/stripe/server/Charge.ts:

typescript

             metadata: resolvedMetadata,
           })
 
+      if (pi.replayed)
+        throw new VerificationFailedError({ reason: 'Payment has already been processed.' })
+
       if (pi.status === 'requires_action') {
         throw new PaymentActionRequiredError({ reason: 'Stripe PaymentIntent requires action' })
       }

Source: GitHub Commit Update

Detection Methods for CVE-2026-34210

Indicators of Compromise

Multiple successful payment authorizations using identical spt tokens across different challenge sessions
Unusual patterns of resource consumption that exceed paid amounts
Repeated PaymentIntent IDs appearing in logs for distinct transactions
Discrepancies between Stripe transaction counts and actual resources consumed

Detection Strategies

Implement logging that tracks spt tokens and correlates them with unique PaymentIntent IDs
Monitor Stripe webhook events for duplicate PaymentIntent completions
Compare server-side resource grants against actual Stripe charges in reconciliation reports
Alert on single payment credentials being used to satisfy multiple independent challenges

Monitoring Recommendations

Enable detailed logging for all payment verification attempts including full request and response metadata
Set up anomaly detection for disproportionate resource consumption relative to payment history
Periodically audit the ratio of Stripe charges to resources consumed per user or API key
Monitor for any VerificationFailedError exceptions after upgrading to identify potential attack attempts

How to Mitigate CVE-2026-34210

Immediate Actions Required

Upgrade mppx to version 0.4.11 or later immediately
Audit existing payment logs for potential replay attack indicators
Reconcile Stripe transaction records with resources granted to identify any exploitation
Consider temporarily restricting high-value resource requests until the patch is deployed

Patch Information

The vulnerability has been patched in mppx version 0.4.11. The fix adds replay detection by checking the replayed property on PaymentIntent responses and throwing a VerificationFailedError when a replayed payment is detected. The patch is available through the following resources:

Workarounds

Implement server-side tracking of used spt tokens and reject any token that has been previously accepted
Add custom middleware to validate Stripe response headers for Idempotent-Replayed before accepting payments
Rate-limit payment verification requests per token to reduce the impact of replay attempts
Deploy additional server-side validation that cross-references PaymentIntent IDs against a persistent store

bash

# Upgrade mppx to patched version
npm update mppx@0.4.11

# Verify installed version
npm list mppx