CVE-2026-33687: Sharp Laravel Auth Bypass Vulnerability

CVE-2026-33687 Overview

CVE-2026-33687 is an Unrestricted File Upload vulnerability (CWE-434) affecting Sharp, a content management framework built as a package for Laravel. This vulnerability allows authenticated users to completely bypass file type validation restrictions through a client-controlled validation parameter in the file upload endpoint.

The flaw exists in the ApiFormUploadController which accepts a validation_rule parameter directly from the client. By manipulating this parameter to contain only validation_rule[]=file, attackers can circumvent all MIME type and file extension restrictions, potentially uploading malicious files including PHP webshells.

Critical Impact

Authenticated attackers can bypass all file type restrictions to upload arbitrary files, potentially leading to remote code execution if the storage disk is configured as public.

Affected Products

• Sharp CMS for Laravel versions prior to 9.20.0
• Laravel applications using vulnerable Sharp package configurations
• Deployments with public storage disk configurations (highest risk)

Discovery Timeline

• 2026-03-26 - CVE-2026-33687 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-33687

Vulnerability Analysis

This vulnerability represents a classic insecure direct object reference combined with insufficient server-side validation. The ApiFormUploadController in Sharp CMS was designed to accept client-provided validation rules for flexibility, but this design decision introduced a significant security flaw.

When processing file uploads, the controller takes a validation_rule parameter from the HTTP request and passes it directly to Laravel's validator without server-side enforcement of security constraints. This allows authenticated users to downgrade the validation from strict MIME type and extension checks to a simple "file" validation rule, which only verifies that the upload is a valid file—not what type of file it is.

The vulnerability is particularly dangerous in environments where Sharp's storage disk is configured as public. In such configurations, an attacker who successfully uploads a PHP file could directly access and execute it via the web server, achieving remote code execution.

Root Cause

The root cause is the acceptance of client-controlled input (validation_rule) for security-critical validation logic. The ApiFormUploadController trusts the client to provide appropriate validation rules rather than enforcing them server-side. This violates the principle of never trusting client input for security decisions.

The fix implemented in version 9.20.0 removes this client-controlled parameter entirely and enforces upload validation rules strictly on the server side, eliminating the bypass vector.

Attack Vector

The attack is network-based and requires authentication to the Sharp CMS interface. An attacker with valid credentials can intercept the file upload request using a proxy tool and modify the validation_rule parameter. By changing this parameter to validation_rule[]=file, all MIME type and extension restrictions are bypassed.

The exploitation flow involves:

1. Authenticating to the Sharp CMS admin interface
2. Initiating a file upload through a normal upload field
3. Intercepting the upload request with a proxy
4. Modifying the validation_rule parameter to bypass restrictions
5. Uploading a malicious file (e.g., PHP webshell)
6. If storage is public, accessing the uploaded file directly for execution

For detailed technical information about this vulnerability, see the GitHub Security Advisory and the Pull Request #714 which contains the fix.

Detection Methods for CVE-2026-33687

Indicators of Compromise

• Unexpected file types appearing in Sharp's upload directories
• PHP files or executable scripts in storage directories
• Upload requests containing modified validation_rule parameters in web server logs
• Access attempts to unusual file paths within the storage directory

Detection Strategies

• Monitor web application firewall (WAF) logs for upload requests with validation_rule[]=file patterns
• Implement file integrity monitoring on Sharp storage directories
• Review HTTP request logs for parameter manipulation attempts on upload endpoints
• Deploy endpoint detection to identify webshell behaviors on the web server

Monitoring Recommendations

• Enable detailed logging for all file upload operations in Sharp CMS
• Configure alerts for new PHP or script files appearing in storage directories
• Monitor for unusual outbound connections from the web server that may indicate webshell activity
• Audit authentication logs for suspicious access patterns to the Sharp admin interface

How to Mitigate CVE-2026-33687

Immediate Actions Required

• Upgrade Sharp CMS to version 9.20.0 or later immediately
• Audit storage directories for any unauthorized or suspicious file uploads
• Review Sharp storage disk configuration and ensure private disk settings are enforced
• Rotate credentials for any accounts with Sharp CMS access as a precaution

Patch Information

The vulnerability has been addressed in Sharp version 9.20.0. The fix removes the client-controlled validation rules entirely and enforces upload validation strictly on the server side. Users should update their composer.json to require version 9.20.0 or higher.

For additional details, see the GitHub Release v9.20.0 and the associated Pull Request.

Workarounds

• Ensure the storage disk used for Sharp uploads is strictly private (not publicly accessible via web)
• Implement additional WAF rules to block requests containing manipulated validation_rule parameters
• Add server-side file type verification after upload as a secondary defense layer
• Restrict Sharp CMS access to trusted networks or implement additional authentication controls

# Configuration example - Ensure Sharp uses private disk in config/filesystems.php
# Verify your Sharp configuration uses a private disk:
# In config/sharp.php, ensure uploads are configured with:
# 'upload_disk' => 'local'  # Not 'public'

# Check your filesystems.php to confirm 'local' disk is not publicly accessible:
# 'local' => [
#     'driver' => 'local',
#     'root' => storage_path('app'),
#     'visibility' => 'private',
# ],