CVE-2026-112293 in saas-starter-kit
Summary
by MITRE • 10/19/2026
BoxyHQ Enterprise SaaS Starter Kit through 1.6.0 contains a missing authorization vulnerability that allows non-owner team members to manage billing because payment routes skip the team_payments permission check. Authenticated MEMBER or ADMIN users can call create-portal-link, create-checkout-session, and products to open Stripe billing portals, view invoices, change payment methods, or alter subscriptions.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in BoxyHQ Enterprise SaaS Starter Kit versions through 1.6.0 represents a critical failure in access control mechanisms within the application's billing subsystem. This flaw is classified as an Insecure Direct Object Reference combined with Broken Access Control, specifically falling under CWE-285: Improper Authorization and CWE-639: Injection of Critical Data into a Command or Context via Indirect Reference if data manipulation occurs during checkout processes. The core issue stems from the application's backend logic where specific payment-related API endpoints fail to verify whether the authenticated user possesses the necessary permissions relative to the team context they are attempting to modify. In a properly secured multi-tenant SaaS environment, actions affecting billing infrastructure must be strictly limited to users holding explicit administrative or owner roles within that specific tenant organization. However, in this implementation, the authorization middleware responsible for checking the team_payments permission is bypassed or entirely absent for these routes.
This architectural deficiency allows any authenticated user with a MEMBER or ADMIN role on a team to perform sensitive financial operations intended exclusively for team owners. By exploiting this gap, an attacker can invoke endpoints such as create-portal-link, create-checkout-session, and products without triggering the expected authorization checks. The operational impact of this vulnerability is severe because it grants unauthorized actors direct control over the financial lifecycle of the organization's subscription model. Attackers can open Stripe billing portals for other team members, potentially exposing sensitive invoice details including credit card numbers, billing addresses, and historical payment data to individuals who should not have access to such information. This constitutes a significant breach of confidentiality regarding personally identifiable information and financial records protected under regulations like GDPR or PCI-DSS depending on the jurisdiction and data sensitivity.
Furthermore, the ability to alter subscriptions and create checkout sessions introduces risks related to integrity and availability. Malicious actors could downgrade premium plans for other users, disrupt service continuity by canceling active subscriptions, or inadvertently trigger billing cycles that result in unexpected charges if payment methods are compromised during the process. The manipulation of products endpoint allows attackers to potentially inject malicious configurations into the pricing structure, although the primary risk remains the unauthorized access to financial data and control over subscription states. From a threat modeling perspective using MITRE ATT&CK frameworks, this vulnerability aligns with T1078: Valid Accounts, as it relies on legitimate credentials, and T1530: Data from Cloud Storage or T1567: Exfiltration Over Web Service if the invoice data is exfiltrated. It also reflects aspects of T1499: Endpoint Denial of Service if subscription cancellations are used to disrupt business operations for competitors or disgruntled employees.
Mitigation strategies must prioritize immediate remediation of the authorization logic within the affected API routes. Developers should enforce strict role-based access control checks at the beginning of each billing-related endpoint handler, ensuring that only users with the owner or specific admin privileges can execute these functions. Implementing middleware that validates team membership and permission levels before processing any request to Stripe APIs is essential. Additionally, applying the principle of least privilege ensures that MEMBER roles are explicitly denied access to financial management features regardless of their general administrative rights within other non-financial modules. Security testing should include automated penetration tests focusing on horizontal privilege escalation scenarios where a lower-privileged user attempts actions reserved for higher-privileged users in different teams or contexts. Regular code audits and static application security testing tools configured with rulesets detecting missing authorization checks can help prevent similar regressions in future releases.