CVE-2026-42331 in FOSSBilling
Summary
by MITRE • 07/07/2026
FOSSBilling is a free, open-source billing and client management system. Prior to version 0.8.0, the Guest API invoice/update endpoint is missing an authorization check present in other invoice-related endpoints, allowing an unauthenticated user with knowledge of an invoice hash to modify the payment gateway associated with an unpaid invoice. An attacker who obtains an invoice hash, which may leak through shared URLs, referrer headers, or email links, can change the `gateway_id` on an unpaid invoice to any payment gateway configured in the system. This does not allow redirecting payments to an arbitrary external endpoint, as the gateway must already be installed and configured by an administrator. The practical impact is further limited by the `invoice_accessible_from_hash` system setting. Version 0.8.0 contains a patch. No known workarounds are available.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/07/2026
The FOSSBilling vulnerability represents a critical authorization flaw in the Guest API that undermines the integrity of invoice management processes. This security weakness exists specifically in versions prior to 080 where the invoice/update endpoint lacks proper authentication checks that are implemented in other invoice-related endpoints within the system. The absence of these authorization controls creates an exploitable pathway for unauthenticated attackers to manipulate payment gateway associations for unpaid invoices, fundamentally compromising the billing system's security posture.
The technical flaw stems from inconsistent implementation of access controls across different API endpoints within FOSSBilling's architecture. While other invoice-related functions properly validate user authentication and authorization before executing modifications, the guest API endpoint for invoice updates omits these crucial security checks. This inconsistency allows attackers to leverage knowledge of valid invoice hashes to perform unauthorized modifications through a predictable API interface. The vulnerability manifests when an attacker discovers an invoice hash through various leakage vectors including shared URLs, referrer headers, or email links that contain direct access points to specific invoices.
The operational impact of this vulnerability extends beyond simple unauthorized modifications as it creates potential for financial manipulation and system abuse. Although the attack vector is limited by the requirement that payment gateways must already be configured by administrators, the ability to change gateway associations provides attackers with significant control over how unpaid invoices are processed. The system's `invoice_accessible_from_hash` setting offers some mitigation but does not fully address the core authorization issue. Attackers can effectively redirect payments through legitimate payment channels that have been pre-configured in the system, potentially leading to unauthorized fund transfers or revenue loss for the organization.
This vulnerability aligns with CWE-639 (Authorization Bypass Through User-Controlled Key) and represents a classic case of insufficient authorization checks in API endpoints. From an ATT&CK framework perspective, this weakness maps to T1543.003 (Create or Modify System Process: Windows Service) and T1078.004 (Valid Accounts: Cloud Accounts) through the exploitation of legitimate system interfaces for unauthorized modifications. The attack requires minimal skill level and can be automated, making it particularly dangerous in environments where invoice hashes might be exposed through routine system operations.
The remediation approach required for this vulnerability involves implementing proper authorization checks on the guest API invoice/update endpoint to ensure that only authenticated users with appropriate permissions can modify invoice payment gateway associations. Version 080 contains the necessary patch that addresses this specific authorization bypass issue, closing the gap in access control implementation between different API endpoints. Organizations should immediately upgrade to version 080 or later and conduct thorough security assessments of their billing systems to identify any similar authorization inconsistencies. Given the nature of the vulnerability, no viable workarounds exist that would maintain system functionality while providing adequate security protection.
The broader implications of this vulnerability highlight the importance of consistent security implementation across all API endpoints in open source systems. FOSSBilling's case demonstrates how seemingly minor oversights in access control can create significant security risks, particularly when dealing with financial transactions and payment processing. This incident underscores the critical need for comprehensive security testing and code review processes in open source projects where multiple contributors may introduce inconsistencies in security controls across different components of the system architecture. Organizations relying on FOSSBilling should implement additional monitoring mechanisms to detect unauthorized invoice modifications and establish proper access control policies for all system interfaces handling financial data.