GHSA-7VFX-4246-JCFH
Vulnerability from github – Published: 2026-06-26 22:20 – Updated: 2026-06-26 22:20Summary
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();
}
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.3.15"
},
"package": {
"ecosystem": "Packagist",
"name": "solidinvoice/solidinvoice"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T22:20:50Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nFour authorization bypass vulnerabilities in Symfony LiveComponent actions allow any authenticated user within a company to access, modify, or delete other users\u0027 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.\n\n## Findings\n\n### 1. Cross-User API Token Revocation (MEDIUM)\n\n**File:** `src/UserBundle/Twig/Components/ApiTokens.php`, lines 50-55\n\nThe `revoke()` LiveAction accepts any `ApiToken` via `#[LiveArg]` without checking ownership. The `apiTokens()` method correctly filters by user (`getApiTokensForUser($this-\u003esecurity-\u003egetUser())`).\n\n```php\n#[LiveAction]\npublic function revoke(#[LiveArg] ApiToken $token): void\n{\n $this-\u003eapiTokenRepository-\u003erevoke($token); // No ownership check\n}\n```\n\n### 2. Cross-User API Token History Disclosure (MEDIUM)\n\n**File:** `src/UserBundle/Twig/Components/ApiTokenHistory.php`, lines 30-55\n\nThe writable `$token` LiveProp performs `$this-\u003eapiTokenRepository-\u003efind($this-\u003etoken)` without user verification. Exposes IP addresses, request methods, paths, and user agents from other users\u0027 API token usage.\n\n### 3. Cross-User Notification Transport Settings Disclosure (HIGH)\n\n**File:** `src/NotificationBundle/Twig/Components/NotificationIntegrations.php`, lines 48-55\n\nThe `integration()` method performs `$this-\u003erepository-\u003efind($this-\u003esetting)` using a writable LiveProp without user check. The `enabledIntegrations()` method correctly filters: `$this-\u003erepository-\u003efindBy([\u0027user\u0027 =\u003e $this-\u003egetUser()])`.\n\nThe `TransportSetting` entity stores notification credentials in a JSON `settings` column, potentially exposing API keys for Slack, Discord, Telegram, or SMS services.\n\n### 4. Cross-User Notification Transport Setting Takeover (HIGH)\n\n**File:** `src/NotificationBundle/Twig/Components/NotificationTransportConfiguration.php`, lines 39-40, 84-101\n\nThe writable `$setting` LiveProp accepts any `TransportSetting` entity. The `save()` action overwrites the user field with the current user via `$setting-\u003esetUser($user)`, effectively stealing the transport configuration and its stored credentials.\n\n## Root Cause\n\nThe application relies on Doctrine\u0027s `CompanyFilter` for tenant isolation but has no user-level access controls within a company. LiveComponent actions that resolve entities from client-provided IDs don\u0027t verify ownership.\n\n## Suggested Fix\n\nAdd user ownership verification in each LiveAction/LiveProp before performing operations:\n```php\nif ($token-\u003egetUser() !== $this-\u003esecurity-\u003egetUser()) {\n throw $this-\u003ecreateAccessDeniedException();\n}\n```",
"id": "GHSA-7vfx-4246-jcfh",
"modified": "2026-06-26T22:20:50Z",
"published": "2026-06-26T22:20:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/SolidInvoice/SolidInvoice/security/advisories/GHSA-7vfx-4246-jcfh"
},
{
"type": "PACKAGE",
"url": "https://github.com/SolidInvoice/SolidInvoice"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS: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",
"type": "CVSS_V4"
}
],
"summary": "SolidInvoice: IDOR in LiveComponent allows same-company cross-user access to API tokens and notification transport settings"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.