FOSSBilling vulnerabilities

FOSSBilling versions 0.6.0 through 0.7.2 have an unauthenticated payment bypass vulnerability. An attacker can mark any unpaid invoice as paid and credit the client account by sending a single crafted HTTP request to the IPN callback endpoint.

FOSSBilling versions 0.7.2 and prior have a vulnerability in the guest API that allows the creation of new administrator accounts even when one already exists. A flaw in the admin existence check enables an attacker to bypass protections.

FOSSBilling prior to version 0.8.0 has a Server-Side Template Injection (SSTI) vulnerability in the template rendering system. Administrators can inject arbitrary Twig expressions, leading to information disclosure and remote code execution.

FOSSBilling versions 0.5.4 to 0.8.0 have an authorization bypass in API role handling, allowing unauthenticated access to privileged `/api/system/*` endpoints. Attackers can invoke admin API methods without valid credentials.

In FOSSBilling prior to version 0.8.1, downloadable product files are stored using a deterministic filename-derived path (MD5 hash). Two different products or order files with the same original filename overwrite each other, causing customers or administrators to receive the wrong file.

In FOSSBilling versions 0.5.3 through 0.7.2, the Guest `serviceapikey/get_info` API endpoint is accessible without authentication. Any caller with a valid API key can retrieve all custom configuration parameters (`custom_*` fields) stored in the key's database record.

In FOSSBilling versions 0.5.6 through 0.7.2, when a client requests a password reset multiple times, the system reuses the existing token instead of generating a new one, with the 15-minute validity anchored to the first request. An attacker who obtained the original reset link can still use it even after the victim requests a new reset, as the original token is never invalidated.

FOSSBilling prior to version 0.8.0 contains a vulnerability that allows a low-privileged staff account to escalate privileges via the admin API. A user with the `staff.create_and_edit_staff` permission can call `/api/admin/staff/permissions_update` for their own account and set any permissions, bypassing role-based access control.

FOSSBilling versions 0.5.3 through 0.7.2 allow authenticated clients to read and reset API key secrets for orders that are no longer active (e.g., suspended, canceled). The root cause is missing order-state validation in two client API endpoints, despite an `isActive()` helper existing in the `Serviceapikey` module and the frontend UI correctly gating access on active orders.

FOSSBilling versions prior to 0.8.0 allow low-privileged staff accounts to perform unauthorized actions via admin API endpoints. The root cause is a combination of the `can_always_access` module flag and insufficient permission checks or unsafe parameter handling on individual endpoints.

In FOSSBilling versions 0.5.6 through 0.7.2, when the 'Require Email Confirmation' setting is enabled, a logged-in client with an unverified email address can access all client-area pages, such as wallet balance and transaction history. The API-side enforcement works correctly, but the page-side enforcement is overly permissive, allowing any request starting with '/client'.

FOSSBilling versions 0.6.0 through 0.7.2 have a stored cross-site scripting (XSS) vulnerability in client-facing email history views. Email HTML content is rendered into a JavaScript template literal without proper escaping, allowing an attacker with admin access to inject malicious JavaScript payloads.

FOSSBilling prior to version 0.8.0 contains a vulnerability where low-privileged staff accounts can read sensitive data via admin API endpoints lacking permission checks. Write endpoints correctly enforce fine-grained permissions, but the corresponding read endpoints have no authorization guards.

In FOSSBilling versions prior to 0.8.0, the PayPalEmail payment adapter accepts PayPal IPN callbacks and credits the IPN-supplied amount (`mc_gross`) to the client's balance without validating it against the invoice total. Combined with a $0.05 floating-point epsilon tolerance in the invoice credit-payment logic, this allows a client to underpay an invoice by up to $0.04 and still have it marked as fully paid.

In FOSSBilling prior to version 0.8.0, a race condition in the cart checkout flow allows an authenticated client to apply a promo code beyond its configured maximum uses. By sending concurrent checkout requests, a client can obtain unlimited discounted or free orders from a single-use or limited-use promo code.

In FOSSBilling prior to version 0.8.0, an unauthenticated mass assignment vulnerability in the client self-registration endpoint allows any visitor to assign themselves to an arbitrary client group during sign-up. This enables attackers to apply group-restricted promo codes and receive unauthorized discounts.

FOSSBilling versions 0.6.10 through 0.7.2 contain a PHP code injection vulnerability in the Config::prettyPrintArrayToPHP() method. An attacker with admin privileges can inject arbitrary PHP code into config.php, which is executed on every HTTP request.

In FOSSBilling prior to version 0.8.0, suspending or deactivating an account does not invalidate existing authenticated sessions. The session loader does not check the account status, allowing a suspended user to retain full access until session expiry.

In FOSSBilling prior to version 0.8.0, the Guest API invoice/update endpoint lacks an authorization check, allowing an unauthenticated user with knowledge of an invoice hash to modify the payment gateway for an unpaid invoice. An attacker who obtains the hash (e.g., via shared URLs, referrer headers, or email links) can change the `gateway_id` to any configured payment gateway.

FOSSBilling versions 0.6.0 through 0.7.2 have a SQL injection vulnerability in the Massmailer module filter functionality. An authenticated administrator can supply crafted filter values when updating a mass email message, causing untrusted input to be interpolated directly into SQL in the recipient selection query.

FOSSBilling versions 0.7.2 and prior have a vulnerability in the API that allows authenticated clients to access other clients' data by guessing order IDs. The __call method in the API does not verify if the client owns the order, potentially leading to data exposure.

FOSSBilling, a billing and client management system, has an IDOR vulnerability in versions 0.6.21 through 0.7.2, allowing authenticated clients to create support tickets referencing other clients' orders. The ticketCreateForClient() method did not verify order ownership, enabling manipulation of rel_id.

FOSSBilling prior to version 0.8.0 does not apply rate limiting to the password reset confirmation endpoint `/client/reset-password-confirm/:hash` because the rate limiter only applies to `/api/*` routes. This allows an attacker to probe the endpoint for valid reset tokens without any per-IP request limiting, attempt counting, or lockout mechanism. The endpoint acts as an oracle, returning a distinguishable response for valid versus invalid tokens (HTTP 200 vs HTTP 302 redirect). However, practical exploitability is significantly mitigated by the current token generation, which uses `hash('sha256', random_bytes(32))`, providing 256 bits of entropy. Tokens also expire after 15 minutes and are deleted after successful use. The same architectural gap applies to other controller-served auth routes, including `/staff/email/:hash` and `/client/confirm-email/:hash`. Version 0.8.0 fixes the issue.

FOSSBilling before 0.8.0 has an open redirect vulnerability in the Redirect module. The module does not validate the URL scheme of administrator-configured destination URLs, allowing arbitrary external URLs as redirect targets.

FOSSBilling prior to version 0.8.0 leaks the exact system version through asset cache buster parameters in HTML output, bypassing the hide_version_public security setting.