CVE-2026-34210: 
JavaScript vulnerability analysis and mitigation

CVE-2026-34210 is a Stripe charge credential replay vulnerability in the mppx npm package (by wevm) caused by a missing idempotency check when creating Stripe PaymentIntents. The stripe/charge payment method failed to validate Stripe's Idempotent-Replayed response header, allowing an authenticated attacker to replay a previously used payment credential (containing the same spt token) against new challenges, with the server accepting the replayed PaymentIntent as a fresh successful payment without charging the customer again. All versions of mppx before 0.4.11 for Node.js are affected. The vulnerability was published on March 26, 2026, and has a CVSS v3.1 base score of 8.1 (High) and a CVSS v4.0 base score of 6.0 (Medium) (Github Advisory, wevm Advisory).

The root cause is classified as CWE-697 (Incorrect Comparison): the stripe/charge server-side handler in Charge.ts did not inspect the idempotent-replayed response header returned by Stripe's API when a PaymentIntent was created with a previously used idempotency key (mppx_{challenge.id}_{spt}). Because Stripe's idempotency mechanism returns a cached response (with the Idempotent-Replayed: true header) when the same key is reused, the server was unable to distinguish a genuine new payment from a replayed one. The fix, introduced in commit b2b1a0b, adds a check for result.lastResponse?.headers?.['idempotent-replayed'] === 'true' (for the client path) and response.headers.get('idempotent-replayed') === 'true' (for the secret-key path), and throws a VerificationFailedError if a replay is detected (Github Commit, wevm Advisory).

Successful exploitation allows a low-privileged attacker (any user who can complete one legitimate payment) to replay their payment credential an unlimited number of times, gaining access to paid resources or services without incurring additional charges. This results in direct financial losses for service operators and potential resource exhaustion (availability impact), as well as integrity violations through unauthorized transaction acceptance. There is no confidentiality impact, and the vulnerability does not enable lateral movement or data exfiltration (Github Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability requires low privileges (a valid account capable of making one legitimate payment) and has no user interaction requirement, making it straightforward to exploit for any authenticated user of an affected application. The EPSS score is approximately 0.04% (6th percentile), indicating a low near-term exploitation probability. The CVE is not listed in the CISA Known Exploited Vulnerabilities catalog. No threat actor attribution has been reported.

1. Obtain a valid account: Register or log in to a service running a vulnerable version of mppx (< 0.4.11) that uses the stripe/charge payment method.
2. Initiate a legitimate payment: Submit a payment request to trigger the server to issue a challenge. The server responds with a 402 status and a challenge object.
3. Complete one real payment: Provide a valid Stripe payment token (spt) to satisfy the challenge. The server creates a Stripe PaymentIntent using an idempotency key of the form mppx_{challenge.id}_{spt} and grants access upon success (HTTP 200).
4. Capture the credential: Record the serialized Authorization header credential (containing the spt token) used in the successful payment request.
5. Replay the credential: Submit the same Authorization credential in subsequent requests to the same or new challenges. Because the server does not check the Idempotent-Replayed header in the Stripe API response, it accepts the cached PaymentIntent as a new successful payment.
6. Consume unlimited resources: Repeat step 5 indefinitely to access paid resources or services without additional charges (wevm Advisory, Github Commit).

• Logs: Server-side payment logs showing the same spt token or Stripe PaymentIntent ID (pi_*) appearing in multiple successful payment records across different sessions or challenges.
• Logs: Application logs showing repeated HTTP 200 responses to payment endpoints from the same user account without corresponding new Stripe charges in the Stripe dashboard.
• Network: Stripe API calls with the same idempotency key (mppx_{challenge.id}_{spt}) being reused across multiple requests, observable in Stripe's API logs or webhook events.
• Application Behavior: A single user account accessing paid resources or services at a volume inconsistent with the number of confirmed Stripe charges on record.

Upgrade mppx to version 0.4.11 or later, which adds server-side validation of Stripe's Idempotent-Replayed response header and rejects replayed PaymentIntents with a VerificationFailedError. There are no workarounds available for unpatched versions — the fix requires a code change in the library itself. Additionally, operators should review Stripe dashboard logs for duplicate PaymentIntent IDs and audit payment transaction records for anomalous replay patterns (Github Advisory, mppx Release).

The vulnerability was discovered and reported by security researchers samczsun and veria-labs, credited in the GitHub Security Advisory. No significant public commentary, media coverage, or social media discussion beyond the advisory itself has been identified at this time (Github Advisory).