Description

SolidInvoice is an open-source invoicing platform. Prior to version 3.0.1, an authenticated user can view the API request history of any other user's API tokens within the same company by manipulating two writable Symfony UX LiveComponent props on the `DataGrid` component. Version 3.0.1 fixes the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-04T18:17:55.580Z",
  "pubdate": "2026-09-04T18:17:55.580Z",
  "executiveSummary": "SolidInvoice versions prior to 3.0.1 contain an Insecure Direct Object Reference (IDOR) vulnerability within the DataGrid component.\nThis flaw allows an authenticated user to perform unauthorized data exposure by accessing the API request history of other users within the same company.\nThe vulnerability arises from improper validation of writable Symfony UX LiveComponent properties, enabling an attacker to manipulate internal state to retrieve sensitive logs they are not authorized to view.\nSuccessful exploitation requires the attacker to be an authenticated user within the target company environment.\nThe risk implication is significant as it facilitates the exfiltration of sensitive API usage telemetry, which could potentially expose secret tokens or private metadata associated with other accounts.\nThe attack is mitigated by upgrading to version 3.0.1, which implements stricter access controls on the LiveComponent properties.",
  "technicalDetails": "The vulnerability resides within the DataGrid component implemented using Symfony UX LiveComponents. In SolidInvoice, the LiveComponent architecture exposes public properties that can be modified by the client to update the component state dynamically.\nThe root cause is an insufficient authorization check on the writable properties of the DataGrid component, which governs the retrieval of API request history.\nAn authenticated user can exploit this by intercepting and modifying the request payload sent to the LiveComponent endpoint. By manipulating specific props, the attacker can force the component to change its data context, switching from the scope of their own user account to the scope of any other API token ID present within the same company.\nThe attack flow follows these steps: 1. The attacker authenticates as a legitimate user within a company. 2. The attacker triggers a DataGrid interaction, such as a filter change or page update, while capturing the network traffic. 3. The attacker identifies the writable properties responsible for filtering the API history records. 4. By injecting or modifying these property values to reference an arbitrary API token ID belonging to a different user, the attacker submits the modified request to the server. 5. The server-side component fails to re-validate that the requester owns or is explicitly authorized to view the requested resource, process the request, and returns the full API request history of the victim. 6. The attacker receives the sensitive information in the response, which may include interaction patterns or other metadata associated with the target's API usage.\nThis vulnerability is classified as an IDOR because the application relies on client-supplied identifiers without verifying ownership or cross-referencing permissions during the update or fetch lifecycle of the LiveComponent. Because the platform uses Symfony UX, these properties are often exposed via public methods, making them attractive vectors for state manipulation if developers do not explicitly restrict which properties are mutable via #[LiveProp] attributes or manual validation logic in the `mount` or `updated` hooks.\nThe impact includes unauthorized information disclosure and loss of confidentiality regarding user-specific system interactions. As the API history may contain sensitive parameters, headers, or timestamps, an attacker could use this information to map out the infrastructure or compromise other integrations used by the victim."
}