CVE-2026-50550: Snipe-IT Auth Bypass Vulnerability

CVE-2026-50550 Overview

CVE-2026-50550 is an authorization flaw in Snipe-IT, an open-source IT asset and license management system. Versions prior to 8.5.0 fail to enforce the canEditAuthFields gate before clearing two-factor authentication (2FA) secrets on user accounts. A user with permission to edit other users can invoke the postTwoFactorReset() method in app/Http/Controllers/Api/UsersController.php to reset a superadmin's 2FA. This weakens account protections and enables account takeover paths against privileged users. The issue is fixed in Snipe-IT 8.5.0 and is tracked under [CWE-863: Incorrect Authorization].

Critical Impact
Authenticated user-editors can strip 2FA from superadmin accounts, removing a critical control against account compromise.

Affected Products

Snipe-IT versions prior to 8.5.0
Snipe-IT API endpoint postTwoFactorReset() in app/Http/Controllers/Api/UsersController.php
Self-hosted and containerized Snipe-IT deployments running vulnerable releases

Discovery Timeline

2026-08-19 - CVE-2026-50550 published to NVD
2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-50550

Vulnerability Analysis

Snipe-IT exposes an API route that resets a target user's 2FA state by nulling two_factor_secret and setting two_factor_enrolled to 0. In vulnerable versions, the controller calls $this->authorize('update', $user), which only verifies that the caller may edit the target user record. It does not verify the caller's authority over authentication-sensitive fields. Any account with users.edit privileges can therefore reach the 2FA reset code path against higher-privileged accounts, including superadmins. Combined with a known or reset password, this enables a full account takeover of a privileged user.

Root Cause

The root cause is a missing authorization check on a sensitive sub-operation. The update policy authorizes general profile edits but does not gate security-critical fields. Snipe-IT already defines a canEditAuthFields ability specifically for authentication attributes, but the postTwoFactorReset() handler never invoked it. This is a classic authorization boundary error where a coarse-grained policy is reused for a fine-grained, higher-impact action.

Attack Vector

Exploitation requires an authenticated session with edit permissions on other users. The attacker issues an API request to the 2FA reset endpoint, supplying the superadmin's user id. The server clears the target's 2FA enrollment without further checks. The attacker then leverages a password reset or previously obtained credentials to authenticate as the superadmin without a second factor.

php

// Patch: gate 2FA reset behind canEditAuthFields and editableOnDemo
// Source: https://github.com/grokability/snipe-it/commit/046ef82c6501be14df597f0bf5d0de2566c7d6bc
try {
    $user = User::find($request->input('id'));
    $this->authorize('update', $user);

    if (auth()->user()->can('canEditAuthFields', $user) && auth()->user()->can('editableOnDemo')) {

        $user->two_factor_secret = null;
        $user->two_factor_enrolled = 0;
        $user->saveQuietly();

        // Log the reset
        $logaction = new Actionlog;
        $logaction->target_type = User::class;
        $logaction->target_id = $user->id;
        $logaction->item_type = User::class;
        $logaction->item_id = $user->id;
        $logaction->created_at = date('Y-m-d H:i:s');

Detection Methods for CVE-2026-50550

Indicators of Compromise

Snipe-IT Actionlog entries with action type 2FA reset targeting superadmin or administrative user IDs from non-administrative accounts.
Unexpected two_factor_enrolled = 0 state changes on privileged accounts, followed by successful logins without a second-factor challenge.
API requests to the users controller postTwoFactorReset route originating from user-editor accounts rather than administrators.

Detection Strategies

Review application audit logs for 2FA reset events and correlate the acting user (created_by) against the target user's privilege level.
Compare the set of accounts historically permitted to reset 2FA against actual actors observed in logs to identify policy drift.
Alert on any 2FA reset event where the target account holds administrative roles and the actor does not.

Monitoring Recommendations

Ship Snipe-IT application logs and web server access logs to a centralized SIEM for correlation with authentication events.
Monitor for password reset requests immediately following a 2FA reset on the same account, which indicates an active takeover sequence.
Track privileged account logins that succeed without an MFA challenge and reconcile against expected enrollment state.

How to Mitigate CVE-2026-50550

Immediate Actions Required

Upgrade Snipe-IT to version 8.5.0 or later, which enforces canEditAuthFields on the 2FA reset endpoint.
Audit the Actionlog table for prior 2FA reset events and validate each against expected administrative activity.
Re-enroll 2FA for all administrative and superadmin accounts and rotate their passwords.

Patch Information

The fix ships in Snipe-IT v8.5.0 and is implemented in commit 046ef82. Additional context is available in the GHSA-6x4j-8954-5hxm advisory. The patch wraps the 2FA reset logic in auth()->user()->can('canEditAuthFields', $user) and auth()->user()->can('editableOnDemo') checks.

Workarounds

Restrict the users.edit permission to a minimal set of trusted administrators until the upgrade is applied.
Place the Snipe-IT API behind network access controls that limit reachability to trusted management networks, reflecting the adjacent-network attack requirement.
Temporarily disable API tokens for accounts that do not require API access to reduce the exploitation surface.

bash

# Upgrade Snipe-IT to the patched release
git fetch --tags
git checkout v8.5.0
php artisan down
composer install --no-dev --prefer-source
php artisan migrate --force
php artisan config:clear
php artisan cache:clear
php artisan up

# Verify version
php artisan --version
grep "'version'" config/version.php