Invia #1028117: InvoiceShelf up to 2.4.3/3.0.0-alpha.1/3.0.0-alpha.2/3.0.0-alpha.3 Cross-Tenant Privilege Escalation / Incorrect Authorization

Summary:
InvoiceShelf does not validate the companies[].id and companies[].role values supplied when an authorized company owner creates or edits a staff member. An owner of any company on a shared installation can attach a newly created, attacker-controlled account, or an account already controlled by the attacker, to an arbitrary victim company with an attacker-selected role such as owner. This results in full cross-tenant privilege escalation.

Affected versions:
InvoiceShelf <= 2.4.3 and 3.0.0-alpha.1 through 3.0.0-alpha.3.

Fixed versions:
InvoiceShelf 2.4.4 and 3.0.0-alpha.4.

Affected components:
- app/Domains/Accounts/Http/Requests/MemberRequest.php
- app/Domains/Accounts/Application/MemberService.php, create() and update()
- app/Domains/Accounts/Http/Controllers/Company/MembersController.php, store() and update()
- User-controlled parameters: companies[].id and companies[].role

Technical details:
MemberRequest validates only that each companies array entry contains an id and role. It does not verify that the acting user owns or administers the referenced company or that the selected role is authorized. MemberService::create() and MemberService::update() pass these values to companies()->sync(). grantRoles() then changes the Bouncer scope to the attacker-supplied company ID and assigns the attacker-supplied role. MembersController::store() checks only UserPolicy::create(), which establishes that the caller owns the currently active company, but does not authorize the companies listed in the request body.

Proof of concept logic:
1. Authenticate as an owner of Company A on a multi-company InvoiceShelf installation.
2. Submit a normal staff-member creation request, but modify companies[].id to the identifier of Company B and companies[].role to the owner role.
3. Supply an attacker-controlled email address and password for the new account.
4. The server creates the account and attaches it to Company B with the selected role, without an invitation or authorization from Company B.
5. Log in with the newly created account and access Company B's invoices, customers, payments and administrative functions.

The same primitive exists in the member update path, allowing an existing account administered by the attacker to be associated with another tenant.

Impact:
An authenticated owner of one company can obtain full administrative control over any other company hosted on the same InvoiceShelf installation. This can expose and permit modification or deletion of financial records, invoices, customer information and payment data. The issue breaks the tenant security boundary.

Weaknesses:
CWE-284 Improper Access Control; CWE-863 Incorrect Authorization.

Suggested CVSS v3.1:
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H (9.1 Critical). The high privilege requirement represents the need to own one legitimate company; the affected authorization scope is a different tenant.

Remediation:
Restrict companies[].id to companies the acting user owns or administers, validate that every requested role exists and is assignable in that company, and reject unauthorized company/role pairs before calling sync() or grantRoles().

Vendor coordination and fix:
The vendor coordinated the disclosure and fixed the issue in 2.4.4 (pull request #826) and 3.0.0-alpha.4 (pull request #822). The public GitHub Security Advisory was published on 2026-09-23. It currently states that there is no known CVE.

Public references:
- Full bilingual technical write-up and safe laboratory PoC: https://github.com/capivara-research/GHSA-c9cx-7r7m-264v
- Vendor advisory: https://github.com/InvoiceShelf/InvoiceShelf/security/advisories/GHSA-c9cx-7r7m-264v
- Fix for 2.x: https://github.com/InvoiceShelf/InvoiceShelf/pull/826
- Fix for 3.x: https://github.com/InvoiceShelf/InvoiceShelf/pull/822

Audited commit:
0076ab9c5b1840d53690e721a1a4e7a91a068795 (2026-09-16).

Public advisory attribution:
The GitHub advisory currently identifies capivara-research as Reporter and gdarko as Coordinator.

Requested VulDB researcher credits:
- Alysson Dutra
- Lucas Diniz
- Fernando Viana

Please credit all three researchers above in the VulDB entry and any CVE record created from this submission. Please associate Fernando Viana's credit with the GitHub profile https://github.com/capivara-research.

• Utente: fernando viana (UID 101484)
• Sottomissione: 13/10/2026 16:43 (23 giorni fa)
• Moderazione: 04/11/2026 19:40 (22 days later)
• Stato: Accettato
• Voce VulDB: 431158 [InvoiceShelf fino a 2.4.3/3.0.0-alpha.3 MemberService.php MemberService::create companies[].id/companies[].role escalationi di privilegi]
• Punti: 20