CVE-2026-48507: 
PHP vulnerability analysis and mitigation

CVE-2026-48507 is an incorrect authorization vulnerability in Snipe-IT, an open-source IT asset and license management system. It affects all versions prior to 8.6.0 and allows a non-admin user holding only the granular users.edit permission to lock every administrator out of the instance by manipulating the activated and ldap_import user flags via the bulk edit functionality. The vulnerability was published on June 8, 2026, with a patch released in version 8.6.0. It carries a CVSS v3.1 base score of 7.1 (High) (GitHub Advisory, Red Hat CVE).

The root cause is an incorrect authorization flaw (CWE-863) in the bulk user editing functionality within app/Http/Controllers/Users/BulkUsersController.php. Prior to the patch, the activated and ldap_import fields were included in the bulk update array without any per-user authorization check, meaning a user with only users.edit permission could submit a bulk edit request setting activated=0 (disabling login) and ldap_import=1 (blocking password reset via LDAP) for all admin accounts. The attack is network-based, requires low privileges (a valid account with users.edit), and no user interaction, making it straightforward to execute against any unpatched instance (GitHub Advisory, Patch Commit).

Successful exploitation results in a complete denial of service for all administrator accounts: admins are unable to log in (activated=0) and cannot request a password reset (ldap_import=1), effectively locking them out of the Snipe-IT instance entirely. There is no confidentiality impact, but integrity is partially affected as user account flags are modified without authorization. The availability impact is rated High, as the entire administrative control plane of the asset management system becomes inaccessible (GitHub Advisory).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at this time (Red Hat CVE). The EPSS score is approximately 0.036%, indicating a low current probability of exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the low attack complexity and minimal privilege requirement (any user with users.edit) make it a realistic insider threat or privilege abuse scenario.

1. Obtain access: Authenticate to the Snipe-IT instance with a non-admin account that has been granted the granular users.edit permission.
2. Navigate to bulk user edit: Access the Users section and select multiple admin accounts using the bulk selection interface.
3. Submit bulk edit request: Send a POST request to the users/bulkeditsave route with the selected admin user IDs and the parameters activated=0 and/or ldap_import=1.
4. Lock out admins: The application, lacking per-user authorization checks on these fields (in versions prior to 8.6.0), applies the changes to all selected admin accounts, setting their activated flag to 0 (preventing login) and ldap_import to 1 (blocking password reset).
5. Achieve denial of service: All targeted admin accounts are now unable to log in or recover access via password reset, leaving the attacker (or no one) in control of the instance (GitHub Advisory, Patch Commit).

• Logs: Application or web server logs showing POST requests to the users/bulkeditsave route from a non-admin user account, particularly with parameters activated=0 or ldap_import=1 targeting multiple user IDs.
• Database: Unexpected changes to the activated or ldap_import columns in the users table for admin or superuser accounts, especially if changed to 0 and 1 respectively in a short time window.
• Application Events: Snipe-IT audit log entries showing bulk user edits performed by a non-admin account affecting privileged users.
• Authentication: Sudden inability of all admin accounts to log in, combined with failed login attempts recorded in the application logs.

Upgrade Snipe-IT to version 8.6.0 or later, which contains the patch that enforces per-user canEditAuthFields authorization checks before applying activated and ldap_import changes in bulk edits (Patch Commit). As an interim workaround, restrict the users.edit permission to only fully trusted users, and audit which accounts currently hold this permission. Additionally, consider maintaining at least one superuser account that is managed separately and not subject to bulk edit operations.

The vulnerability was reported by security researchers louissanchez-vokecyber and whatisproblem, and was disclosed via GitHub's security advisory process (GitHub Advisory). No significant broader media coverage or notable social media commentary has been identified at this time.