High-severity findings.

Audited release

2.5.18

Findings

3

Worst severity

high

Content hash

b10f68e41650587080dc7593… Copy

Findings

• high stripePaymentIntent accepts an arbitrary Stripe customerId with no ownership check

  auth_bypass

  In the PAYMENT branch the resolver maps the authenticated WPGraphQL viewer to a Stripe customer via woonuxt_get_mapped_stripe_customer_id(), then immediately overwrites that mapping if args.customerId matches /^cus_[A-Za-z0-9]+$/. There is no check that the requested cus_ belongs to context->viewer (or to the current cart). create_payment_intent() then sends that customer id to Stripe, and saveForFuture can set setup_future_usage=off_session on it. Combined with User.savedPaymentMethods (which returns token=pm_xxx and customerId=cus_xxx for any publicly queryable User), an attacker who can put an item in a guest cart can mint a PaymentIntent bound to the victim's Stripe customer and confirm it with the leaked payment_method. Even without the leak, any cus_ learned from receipts, logs, or XSS can be targeted. customerId is ignored for SETUP; this is PAYMENT-only but still unauthenticated aside from the cart-total > 0 gate.

  includes/graphql/stripe.php:552-565

  Recommendation

  Ignore client-supplied customerId unless it equals the mapped ID for the authenticated viewer. For guest checkout, pass no Stripe customer (or a guest customer created for that session). Do not set setup_future_usage unless the viewer is authenticated. If a client must send a cus_ (Capacitor/native), verify it server-side against user meta / WC payment tokens for that user_id before calling Stripe.

• high User.savedPaymentMethods and User.stripeCustomerId leak other users' Stripe tokens

  information_disclosure

  Both fields are registered on GraphQL type User with custom resolvers and no auth/isPrivate. They resolve $source->databaseId (a WPGraphQL allowed_restricted_field, so it is populated even for public/restricted authors) and then call woonuxt_get_mapped_stripe_customer_id() / WC_Payment_Tokens::get_customer_tokens($user_id,'stripe') with no comparison to get_current_user_id() or context->viewer. WPGraphQL User objects are public for users with published posts of GraphQL-exposed types (WooCommerce products, blog posts). An unauthenticated query of product authors therefore returns Stripe customer IDs, payment_method IDs (pm_xxx), last4, expiry, and brand for the store owner or any shop_manager who published a product. That is PCI-adjacent data and the input to the customerId IDOR on stripePaymentIntent. Intended access is viewer { savedPaymentMethods }; the registration on User makes every reachable User node a dump of that user's wallet.

  includes/graphql/stripe.php:592-758

  Recommendation

  Resolve these fields only when intval($source->databaseId) === get_current_user_id() or the WPGraphQL viewer ID; otherwise return null/[]. Prefer registering them on Viewer only, or set auth.callback / isPrivate so unauthenticated and cross-user selections fail. Do not return raw Stripe pm_ / cus_ IDs to any caller that is not the cardholder.

• medium graphql_data_is_private forces PluginObject public, listing all installed plugins

  information_disclosure

  woonuxt_register_graphql_filters() (hooked from graphql_register_types when WooCommerce is active) adds graphql_data_is_private that returns false whenever $model_name is PluginObject. WPGraphQL\Model\Plugin::is_private() otherwise requires activate_plugins (and on multisite manage_network_plugins / the network plugins menu). After this filter, an unauthenticated { plugins { nodes { name version path author } } } query returns the full installed-plugin inventory, including filesystem paths and versions of WooCommerce, WPGraphQL, security plugins, etc. That is reconnaissance for known-vulnerable companions. The headless storefront does not need this; woonuxtSettings already exposes wooCommerceSettingsVersion for the WooNuxt plugin itself.

  includes/graphql/filters.php:21-23

  Recommendation

  Remove the PluginObject bypass. If the Nuxt app needs a capability flag, add an explicit boolean on woonuxtSettings (e.g. stripeEnabled) instead of opening the entire Plugin type. Keep graphql_data_is_private from forcing other models public.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.