Description

SolidInvoice is an open-source invoicing platform. Prior to version 3.0.1, the REST API authenticator accepts bearer tokens via a `?token=` URL query parameter as a fallback to the `X-API-TOKEN` header. This causes long-lived API credentials to be recorded in server access logs, proxy logs, browser history, and HTTP Referer headers sent to third-party origins. Version 3.0.1 fixes the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-09-04T18:17:55.290Z",
  "pubdate": "2026-09-04T18:17:55.290Z",
  "executiveSummary": "SolidInvoice, an open-source invoicing platform, contains a critical security vulnerability in its REST API authentication mechanism that facilitates the unauthorized exposure of sensitive credential material.\nThe vulnerability arises from the application's design choice to accept API bearer tokens via a 'token' URL query parameter as a functional fallback for the standard 'X-API-TOKEN' request header.\nThis behavior introduces significant risk, as API tokens—intended to be ephemeral or secured within request headers—are treated as part of the URI, leading to their persistence in plaintext across various logging and reporting layers.\nThe primary impact involves the inadvertent leakage of long-lived authentication credentials into server access logs, intermediary proxy logs, browser history, and HTTP Referer headers transmitted to third-party domains.\nAn attacker with access to any of these secondary storage locations can capture valid bearer tokens, effectively bypassing authentication controls to gain unauthorized access to the invoicing platform's REST API.\nThe vulnerability affects all versions of SolidInvoice prior to 3.0.1. Exploitation is passive from the perspective of the attacker, requiring only that legitimate users interact with the API via the vulnerable query parameter method to trigger the credential leakage.\nRemediation requires upgrading to version 3.0.1, which deprecates the insecure URL-based parameter handling in favor of secure header-only authentication.",
  "technicalDetails": "The root cause of this vulnerability is an insecure implementation of the REST API authentication handler within the SolidInvoice codebase. While the application supports the standard 'X-API-TOKEN' header for authentication, the developers implemented a secondary authentication logic that checks the 'token' parameter in the URI query string.\nThis design pattern, often used for legacy support or ease of integration, violates the principle of least privilege regarding data exposure. According to the HTTP specification and common security best practices, sensitive authentication tokens should be transmitted exclusively via request headers, as these are typically not cached by intermediary proxies or recorded in full-path access logs by standard web servers (e.g., Nginx, Apache).\nWhen a user or client application interacts with the SolidInvoice REST API using the 'token=' query parameter, the authentication token is transmitted as part of the request URI. This triggers a cascading effect of information leakage. Firstly, the web server processes the request and generates an access log entry that includes the full path of the requested URL, thereby persisting the API token in plaintext on the filesystem. Secondly, any forward or reverse proxies deployed in the infrastructure will capture the full request URI, extending the credential exposure across the infrastructure stack.\nFurthermore, if the application is accessed via a browser-based client that subsequently triggers requests to third-party resources, the 'Referer' header—which often includes the full current URL—may be transmitted to these external services, potentially exposing the sensitive token to logs and analytics engines managed by third parties. Browser history mechanisms also record the full URL, leaving credentials stored on the end-user's local workstation.\nThe attack flow for exploitation is highly opportunistic and requires no specific malicious payload. An attacker who gains read access to server logs, proxy infrastructure, or end-user browser environments can extract these tokens through pattern matching (e.g., regex searching for the token format). Once a token is harvested, the attacker can present this credential to the API endpoint, impersonating the legitimate user without requiring further authentication. Given the 'long-lived' nature of these tokens as described, the window of opportunity for an attacker to misuse the stolen credential is broad, potentially allowing for persistent unauthorized data access, modification, or destruction of invoicing records until the token is manually revoked or rotated."
}