A high-severity authorization vulnerability in FOSSBilling, the open-source billing and client management platform, allowed any staff account with basic edit permissions to escalate itself to full administrative control, and the escalation would persist indefinitely.
Tracked as CVE-2026-53645 and rated High severity under CVSS v4 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:L), the flaw affects all FOSSBilling versions from 0.1.0 through 0.7.2.
It was patched in version 0.8.0. Security researcher admdly published the advisory (GHSA-4hf7-xxxw-64rm) last month, crediting Mitchell45 for the responsible disclosure.
The vulnerability lives in the admin API’s permission-update pathway. The endpoint /api/admin/staff/permissions_update, defined in src/modules/Staff/Api/Admin.php, accepts an arbitrary target staff ID and an arbitrary permissions payload, then passes both directly to setPermissions() in src/modules/Staff/Service.php:
public function setPermissions($member_id, $array): bool
{
$this->checkPermissionsAndThrowException('staff', 'create_and_edit_staff');
$array = array_filter($array);
// writes $array as JSON to admin.permissions
}The only gate is a check confirming the caller holds staff.create_and_edit_staff a relatively low-tier permission intended for routine staff account management, not privilege assignment. Once that single check passes, the function writes whatever permission structure the caller submits, with no validation of scope.
Three critical safeguards are missing:
- No self-edit prevention, so a staff member can target their own account ID
- No module restriction, allowing any backend module (billing, invoicing, email, system settings) to be added
- No privilege-ceiling enforcement, meaning a caller can grant itself permissions exceeding its own current access
Notably, sibling methods like update(), delete(), and changePassword() in the same service correctly distinguish between admin and staff targets. setPermissions() skips that distinction entirely, meaning the same logic flaw could theoretically be abused to modify admin-tier accounts as well.
Because the new permissions are written directly to the database, the escalation survives logouts, session expiry, and password changes. A staff account with nothing more than staff-editing rights can silently grant itself access to client records, order management, invoicing, and system configuration, effectively becoming a full administrator without anyone approving the change.
The CVSS vector reflects this clearly: no privileges are needed beyond low-level access, no user interaction is required, and the “subsequent system impact” jumps to high confidentiality and integrity risk once escalation occurs.
“This bug is a textbook reminder that permission systems fail not from missing checks, but from checks that ask the wrong question. Verifying ‘can this user edit permissions’ is meaningless if you never ask ‘whose permissions, and how far can they reach.'”
Until organizations upgrade, GitHub’s advisory recommends two interim controls:
- Restrict
staff.create_and_edit_staffto only the most trusted personnel - Use a reverse proxy or WAF rule to block unauthorized access to
/api/admin/staff/permissions_update
FOSSBilling administrators running any version at or below 0.7.2 should prioritize upgrading to 0.8.0, which introduces proper admin/staff target distinction and privilege-ceiling checks. Given the low complexity and network-based attack vector, this vulnerability offers an easy path to full backend compromise for any organization running an unpatched instance.
About the Author
