User Registration Stripe CVE-2026-49081

The target WordPress site must have the ThemeGrill User Registration Stripe plugin installed and activated at version 1.3.12 or earlier, with the affected endpoint reachable over HTTP/HTTPS - the standard deployment for a public WordPress signup page. No authentication, user interaction, or non-default configuration is required (PR:N, UI:N, AC:L), and exploitation works against default installations. Limiting factors are narrow: the plugin must actually be present (it is an add-on, not part of WordPress core or the base User Registration plugin), and the attacker must know or discover the specific vulnerable action name, which Patchstack's advisory may disclose post-embargo.

The CVSS vector AV:N/AC:L/PR:N/UI:N indicates fully remote, low-complexity, unauthenticated exploitation with no user interaction, which is the worst-case pre-conditions profile and aligns with the 'Unauthenticated' qualifier in the Patchstack report. The C:L/I:H/A:N impact pattern is consistent with a broken access control flaw that lets attackers modify or create data (e.g., users, subscriptions, payment state) with only limited read exposure and no denial-of-service. No EPSS score, KEV listing, or SSVC decision is provided, and no POC is referenced, so real-world exploitation pressure is currently unknown - for a niche commerce plugin this typically means opportunistic mass scanning of WordPress sites rather than targeted attacks. The lack of an explicit fixed version in the input is a notable gap: Patchstack lists 1.3.12 as the highest vulnerable version, but the patched release must be verified directly from the linked advisory before deployment.

An attacker scanning the internet for WordPress sites fingerprints the User Registration Stripe plugin via its static assets or REST namespace, then sends a crafted HTTP request directly to the vulnerable AJAX or REST endpoint without any session cookie or nonce. Because the handler skips capability checks, the request succeeds and the attacker modifies registration or payment-related state - for example creating users, altering subscription records, or manipulating plan assignments. No public exploit is identified at time of analysis, but the low-complexity unauthenticated profile makes development of a working PoC straightforward once the specific endpoint is identified.