Every CVESearch/Get API key

GHSA-7vfx-4246-jcfh

SolidInvoice: IDOR in LiveComponent allows same-company cross-user access to API tokens and notification transport settings

8.9 HighFix available

Summary

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.

Suggested Fix

Add user ownership verification in each LiveAction/LiveProp before performing operations:

if ($token->getUser() !== $this->security->getUser()) {
    throw $this->createAccessDeniedException();
}

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
High
Integrity
High
Availability
High

What each source reports

GitHub Advisories Score used8.9

SolidInvoice: IDOR in LiveComponent allows same-company cross-user access to API tokens and notification transport settings

Summary

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.

Suggested Fix

Add user ownership verification in each LiveAction/LiveProp before performing operations:

if ($token->getUser() !== $this->security->getUser()) {
    throw $this->createAccessDeniedException();
}
Record
GHSA-7vfx-4246-jcfh
CVSS 4.0
8.9 HighCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P
Weakness
CWE-639, CWE-862
Updated
2026-11-02
OSV8.9

SolidInvoice: IDOR in LiveComponent allows same-company cross-user access to API tokens and notification transport settings

Summary

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.

Suggested Fix

Add user ownership verification in each LiveAction/LiveProp before performing operations:

if ($token->getUser() !== $this->security->getUser()) {
    throw $this->createAccessDeniedException();
}
Record
GHSA-7vfx-4246-jcfh
CVSS 4.0
8.9 HighCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P
Weakness
CWE-639, CWE-862
Updated
2026-11-02

Affected packages

Affected packages
PackageAffectedFixed
solidinvoice/solidinvoice
Packagist
through 2.3.15
2.3.16
solidinvoice/solidinvoice
Packagist
before 2.3.16
2.3.16

History

History
RecordedChangedSources
first indexedGitHub Advisories, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

GHSA-7vfx-4246-jcfh is a high vulnerability (CVSS 8.9) in solidinvoice/solidinvoice, published June 26, 2026. No source lists public exploit code. Fixed in solidinvoice/solidinvoice 2.3.16.

References

MoveEnter Open