Description

The Stripe Payment Forms by WP Full Pay WordPress plugin before 8.5.5 does not verify that a subscription belongs to the customer bound to the requesting customer-portal session before cancelling it, allowing a user with a confirmed portal session to cancel subscriptions belonging to other customers. Exploitation requires the attacker to know the target subscription's identifier, which is high-entropy and not enumerable through the Stripe Payment Forms by WP Full Pay WordPress plugin before 8.5.5.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-29T06:17:49.560Z",
  "pubdate": "2026-08-29T06:17:49.560Z",
  "executiveSummary": "The Stripe Payment Forms by WP Full Pay plugin, specifically versions prior to 8.5.5, contains an Insecure Direct Object Reference (IDOR) vulnerability within its customer-portal subscription management functionality.\nThis flaw permits an authenticated user with an active, confirmed session to perform unauthorized cancellation of subscription resources owned by third-party customers.\nThe root cause of this vulnerability is the absence of server-side ownership verification, where the application fails to validate that the requested subscription ID is cryptographically or logically bound to the currently authenticated session.\nThe risk implication is a significant impact on service integrity and business logic, as it enables malicious actors to terminate services for arbitrary customers without authorization.\nExploitation is contingent upon the attacker obtaining a target's subscription identifier. While the plugin does not provide an enumeration vector due to the high-entropy nature of Stripe's identifiers, the vulnerability remains a critical flaw in access control mechanisms that could be exploited if an identifier is leaked via other means or via targeted reconnaissance.",
  "technicalDetails": "The vulnerability manifests as an improper authorization check during the subscription cancellation workflow in the Stripe Payment Forms by WP Full Pay plugin. When a user interacts with the customer-portal, the application triggers a backend process to terminate a subscription based on an identifier provided in the request.\nThe vulnerable component fails to perform an Access Control List (ACL) or ownership verification check to confirm that the `subscription_id` parameter matches the account holder of the authenticated session. Consequently, the application assumes that any user with an active portal session is authorized to modify any subscription ID passed to the request parameters.\nThe attack flow proceeds as follows: First, an attacker establishes a legitimate, confirmed session via the Stripe Payment Forms plugin to gain access to the portal environment. Second, the attacker captures the request intended to cancel their own subscription, typically using an interception proxy. Third, the attacker modifies the payload to inject a target's high-entropy subscription identifier. Finally, the server processes the request and executes the cancellation command through the Stripe API, effectively terminating the subscription for the victim without requiring ownership verification.\nWhile the high-entropy nature of Stripe identifiers effectively prevents brute-force enumeration, this does not mitigate the fundamental breakdown in secure authorization logic. The system lacks a server-side cross-reference between the session user's identity and the Stripe customer object associated with the target subscription ID.\nThe impact of this post-exploitation behavior is direct service disruption, potential loss of revenue, and administrative overhead for the plugin users. Because the cancellation request originates from a trusted, authenticated portal session, the underlying API call is treated as authorized, bypassing standard security measures.\nThe affected versions include all releases of the Stripe Payment Forms by WP Full Pay plugin prior to 8.5.5. The vulnerability requires the attacker to be authenticated as a valid portal user; however, it does not require administrative privileges, as it exploits the logic governing standard customer-side operations."
}