Summary
SolidInvoice: IDOR in LiveComponent allows same-company cross-user access to API tokens and notification transport settings
Four authorization bypass vulnerabilities in Symfony LiveComponent actions allow any authenticated user within a company to access, modify, or delete other users' API tokens and notification transport settings. The root cause is that LiveComponent actions accept entity IDs without verifying ownership, while the listing methods correctly filter by user.
Findings
1. Cross-User API Token Revocation (MEDIUM)
File: src/UserBundle/Twig/Components/ApiTokens.php, lines 50-55
The revoke() LiveAction accepts any ApiToken via #[LiveArg] without checking ownership. The apiTokens() method correctly filters by user (getApiTokensForUser($this->security->getUser())).
#[LiveAction]
public function revoke(#[LiveArg] ApiToken $token): void
{
$this->apiTokenRepository->revoke($token); // No ownership check
}
2. Cross-User API Token History Disclosure (MEDIUM)
File: src/UserBundle/Twig/Components/ApiTokenHistory.php, lines 30-55
The writable $token LiveProp performs $this->apiTokenRepository->find($this->token) without user verification. Exposes IP addresses, request methods, paths, and user agents from other users' API token usage.
3. Cross-User Notification Transport Settings Disclosure (HIGH)
File: src/NotificationBundle/Twig/Components/NotificationIntegrations.php, lines 48-55
The integration() method performs $this->repository->find($this->setting) using a writable LiveProp without user check. The enabledIntegrations() method correctly filters: $this->repository->findBy(['user' => $this->getUser()]).
The TransportSetting entity stores notification credentials in a JSON settings column, potentially exposing API keys for Slack, Discord, Telegram, or SMS services.
4. Cross-User Notification Transport Setting Takeover (HIGH)
File: src/NotificationBundle/Twig/Components/NotificationTransportConfiguration.php, lines 39-40, 84-101
The writable $setting LiveProp accepts any TransportSetting entity. The save() action overwrites the user field with the current user via $setting->setUser($user), effectively stealing the transport configuration and its stored credentials.
Root Cause
The application relies on Doctrine's CompanyFilter for tenant isolation but has no user-level access controls within a company. LiveComponent actions that resolve entities from client-provided IDs don't verify ownership.
Impact
The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Add user ownership verification in each LiveAction/LiveProp before performing operations:
if ($token->getUser() !== $this->security->getUser()) {
throw $this->createAccessDeniedException();
}
Frequently Asked Questions
- What is GHSA-7VFX-4246-JCFH? GHSA-7VFX-4246-JCFH is a high-severity missing authorization vulnerability in solidinvoice/solidinvoice (composer), affecting versions <= 2.3.15. It is fixed in 2.3.16. The application does not perform an authorization check before performing a sensitive operation.
- Which versions of solidinvoice/solidinvoice are affected by GHSA-7VFX-4246-JCFH? solidinvoice/solidinvoice (composer) versions <= 2.3.15 is affected.
- Is there a fix for GHSA-7VFX-4246-JCFH? Yes. GHSA-7VFX-4246-JCFH is fixed in 2.3.16. Upgrade to this version or later.
- Is GHSA-7VFX-4246-JCFH exploitable, and should I be worried? Whether GHSA-7VFX-4246-JCFH is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-7VFX-4246-JCFH is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-7VFX-4246-JCFH? Upgrade
solidinvoice/solidinvoiceto 2.3.16 or later.