FOSSBilling CVE-2026-43918

Requires the attacker to already hold a valid, authenticated FOSSBilling session (client, staff, or admin) established before an administrator suspends or marks the account inactive - the vulnerability manifests specifically in the loggedin_client and loggedin_admin loaders in src/di.php, which validate only account existence, not status. The triggering event is an administrative suspension/deactivation while the user's session is still live. Limiting factors: exploitation is impossible without a pre-existing authenticated session (PR:L), the attacker cannot create new access after suspension (login is blocked; only the old session works), and the window is bounded - access ends automatically when the session naturally expires or when server-side session data is cleared. Affects only FOSSBilling deployments prior to 0.8.0.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, VC:H/VI:H/VA:H, score 8.7) reflects that an already-authenticated actor with low privileges retains high confidentiality, integrity, and availability impact over their own accessible scope - but the PR:L requirement is the critical limiter: this is not an unauthenticated network compromise. It cannot be triggered by an outsider; it only matters once an administrator has decided a user should lose access. There is no EPSS score, no CISA KEV entry, and no POC in the provided data, so real-world exploitation pressure is low and opportunistic rather than mass-scannable. The 8.7 score is arguably high relative to the practical threat model, since exploitation depends entirely on an offboarding/suspension event and the window closes at natural session expiry; treat this as a meaningful account-lifecycle and offboarding-hygiene issue rather than an emergency internet-facing RCE. Note the reference tag says 'Information Disclosure' while the vector asserts high integrity and availability impact - that tag understates the flaw; the retained session grants whatever actions the role normally permits, not just data reads.

A hosting reseller with a staff or client login is caught abusing the platform and an administrator suspends their account, assuming access is revoked. Because the pre-0.8.0 session loader only checks that the account row exists, the suspended user simply keeps using their still-open browser session to view customer data, place orders, or change settings until the session times out. No exploit tooling is required - the attacker merely avoids logging out; no public POC is documented.