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

CVE-2026-38533 Overview

An improper authorization vulnerability exists in the /api/v1/users/{id} endpoint of Snipe-IT v8.4.0. This flaw allows authenticated attackers who possess the users.edit permission to modify sensitive authentication and account-state fields of other non-admin users by supplying a crafted PUT request. The vulnerability represents a Broken Access Control issue (CWE-285: Improper Authorization) that could enable horizontal privilege escalation within the application.

Critical Impact

Authenticated attackers can manipulate user account fields beyond their intended authorization scope, potentially compromising account integrity and security controls for non-admin users.

Affected Products

• Snipe-IT v8.4.0
• Snipe-IT Asset Management Platform (API v1)
• Deployments utilizing the /api/v1/users/{id} REST endpoint

Discovery Timeline

• 2026-04-14 - CVE CVE-2026-38533 published to NVD
• 2026-04-16 - Last updated in NVD database

Technical Details for CVE-2026-38533

Vulnerability Analysis

This vulnerability stems from insufficient authorization checks within the Snipe-IT REST API user management endpoint. The /api/v1/users/{id} endpoint accepts PUT requests for user modifications but fails to properly validate whether the requesting user should have access to modify specific sensitive fields belonging to other users.

When an authenticated user with the users.edit permission submits a crafted PUT request targeting another non-admin user's account, the API processes modifications to sensitive authentication and account-state fields without adequate field-level authorization verification. This allows attackers to alter critical user account attributes that should be restricted, even when they have legitimate edit permissions for other user fields.

The vulnerability is classified under CWE-285 (Improper Authorization), indicating a failure to properly restrict access to resources based on user privileges at a granular field level.

Root Cause

The root cause lies in the inadequate implementation of field-level authorization controls within the user update API handler. While the application enforces permission checks at the endpoint level (requiring users.edit permission), it does not implement sufficient validation to restrict which specific user fields can be modified based on the relationship between the requester and target user. The authorization logic fails to differentiate between benign user profile updates and sensitive authentication or account-state modifications that require elevated privileges.

Attack Vector

The attack is network-based and requires the attacker to have valid authentication credentials with the users.edit permission. The attacker identifies target non-admin user accounts and constructs malicious PUT requests to the /api/v1/users/{id} endpoint. By including sensitive authentication and account-state parameters in the request payload, the attacker can modify fields that should be protected from lateral access.

The attack does not require user interaction and can be executed with low complexity. An attacker with a lower-privileged account that has user editing capabilities can exploit this vulnerability to manipulate other user accounts, potentially disabling accounts, altering authentication credentials, or changing account states in unauthorized ways.

For technical exploitation details, refer to the GitHub CVE-2026-38533 PoC.

Detection Methods for CVE-2026-38533

Indicators of Compromise

• Unusual PUT requests to /api/v1/users/{id} endpoints modifying authentication-related fields
• API logs showing user account modifications performed by users other than administrators or account owners
• Multiple user account state changes originating from a single non-admin authenticated session
• Anomalous patterns of user record updates targeting sensitive fields like password hashes or account status

Detection Strategies

• Monitor API access logs for PUT requests to /api/v1/users/ endpoints that modify sensitive fields
• Implement alerting for user account modifications where the requesting user ID differs from the target user ID and the requester is not an administrator
• Deploy Web Application Firewall (WAF) rules to flag or block PUT requests containing sensitive authentication field parameters from non-admin users
• Utilize SentinelOne Singularity XDR to correlate API activity patterns and detect unauthorized access attempts

Monitoring Recommendations

• Enable detailed audit logging for all user management API endpoints
• Configure alerts for bulk or rapid user account modifications from single sessions
• Review API gateway logs for anomalous authorization patterns
• Implement real-time monitoring of user account state changes

How to Mitigate CVE-2026-38533

Immediate Actions Required

• Restrict the users.edit permission to only trusted administrators until a patch is available
• Review and audit recent user account modifications for unauthorized changes
• Implement additional authorization checks at the application or API gateway level
• Consider temporarily disabling API access to user management endpoints for non-admin users

Patch Information

Refer to the Snipe-IT Application official website and release notes for updated versions that address this vulnerability. Organizations should upgrade to a patched version of Snipe-IT as soon as one becomes available. Monitor the GitHub Security Advisory for additional remediation guidance.

Workarounds

• Implement API gateway rules to strip or block sensitive authentication fields from PUT requests made by non-admin users
• Deploy middleware that validates field-level permissions before processing user update requests
• Use network segmentation to limit API access to trusted internal networks only
• Temporarily revoke users.edit permissions from all non-administrator accounts

# Example: Restrict API access via nginx configuration
location /api/v1/users/ {
    # Require admin role for PUT requests
    if ($request_method = PUT) {
        # Implement additional authentication check
        # or restrict to admin IP ranges only
        allow 10.0.0.0/8;  # Internal admin network
        deny all;
    }
}