CVE-2026-55542: 
PHP Analyse et atténuation des vulnérabilités

CVE-2026-55542 is a missing authorization vulnerability in Snipe-IT's S3 signature image retrieval functionality. On S3-backed deployments, authenticated users who know a signature filename can bypass authorization checks and obtain a 5-minute signed S3 URL for any signature image. The vulnerability affects Snipe-IT versions up to and including 8.5.0, with a patch available in version 8.5.1. It was disclosed by Ikaro tiagonas, published to the GitHub Advisory Database on June 23, 2026, and carries a CVSS v4 base score of 1.3 (Low) (GitHub Advisory).

The root cause is a missing authorization check (CWE-862) in app/Http/Controllers/ActionlogController.php. In the displaySig() method, when the storage backend is S3, the code generates and returns a temporary signed URL before reaching the authorize() call that is present in the local-file branch — meaning the authorization gate is never evaluated for S3 deployments. The fix (commit ded6515) moves the authorization check to the top of the method, first looking up the Actionlog record by filename and then calling $this->authorize('view', $actionlog->item) before any URL generation occurs, ensuring consistent enforcement regardless of storage backend (GitHub Commit, GitHub Advisory).

Successful exploitation allows an authenticated but unauthorized user to access signature images (e.g., asset acceptance signatures) stored in S3 that they should not be permitted to view. The impact is limited to a low-severity confidentiality breach — no integrity or availability impact is present, and the exposure is scoped to a temporary 5-minute signed URL. This could expose sensitive user signature data tied to asset or license acceptance records in organizations using Snipe-IT with S3 storage (GitHub Advisory).

1. Authenticate: Log in to a Snipe-IT instance (version ≤ 8.5.0) that uses S3 as its storage backend with any valid user account, regardless of permission level.
2. Identify a signature filename: Obtain a valid signature filename through indirect means — for example, by observing filenames exposed in action log API responses (app/Http/Transformers/ActionlogsTransformer.php:188) or by guessing predictable naming patterns used during asset acceptance workflows.
3. Request the signature endpoint: Send an authenticated HTTP GET request to the signature retrieval route (defined in routes/web.php:135-143), e.g., GET /account/accept/signature/<filename>.
4. Receive the signed S3 URL: Because the S3 branch in ActionlogController::displaySig() returns a temporary URL before the authorize() call, the server responds with a 5-minute signed S3 URL granting direct access to the signature image.
5. Access the signature image: Use the returned signed URL to download the signature image from S3 within the 5-minute validity window (GitHub Advisory, GitHub Commit).

• Logs: Snipe-IT application logs showing repeated or anomalous authenticated requests to the signature retrieval route (e.g., /account/accept/signature/<filename>) from users who do not have asset or license view permissions.
• Network: Outbound redirects from the Snipe-IT server to S3 temporary signed URLs (https://<bucket>.s3.<region>.amazonaws.com/...?X-Amz-Signature=...) initiated by low-privilege user sessions.
• Application Logs: Laravel access logs showing HTTP 302 redirect responses to S3 for the log.signature.view route from accounts that should not have view access to the associated assets or licenses.

Upgrade Snipe-IT to version 8.5.1 or later, which includes the patch in commit ded6515 that moves the authorize() check to execute before any S3 URL generation. No configuration-based workaround is available for S3-backed deployments on vulnerable versions; upgrading is the only reliable remediation. Organizations unable to upgrade immediately should consider restricting Snipe-IT access to trusted internal users only and auditing action log access patterns (GitHub Advisory, GitHub Commit).