CVE-2026-116198: 
Snipe-IT vulnerability analysis and mitigation

CVE-2026-116198 is a missing encryption vulnerability in Snipe-IT's Api\AssetsController::store endpoint that causes sensitive custom-field values to be written as plaintext into database columns flagged for encryption. It affects Snipe-IT versions up to and including 8.6.3 (all versions before 8.7.0). The vulnerability was disclosed on October 25, 2026, with a patch released in version 8.7.0. It carries a CVSS v3.1 base score of 4.3 (Medium) and a CVSS v4.0 base score of 5.3 (Medium) (GitHub Advisory, Snipe-IT Advisory).

The root cause is a control flow implementation flaw (CWE-670) combined with missing encryption of sensitive data (CWE-311) in app/Http/Controllers/Api/AssetsController.php. The vulnerable store() method checked Gate::allows('assets.view.encrypted_custom_fields') before calling Crypt::encrypt(), but lacked an else continue; branch — meaning when the gate denied the caller, the unencrypted $field_val fell through to the unconditional $asset->{$field->db_column} = $field_val; write. The sibling update() method and non-API paths (including BulkAssetsController) handled this correctly with a continue; under the deny branch, making store() the sole outlier. Exploitation requires only a valid API authentication token; no elevated privileges beyond basic API access are needed (Snipe-IT Advisory).

The primary impact is a data-integrity and encryption-at-rest violation: sensitive custom-field values intended to be encrypted are instead stored as raw plaintext in the database. This exposes the data through database backups, read replicas, and direct DBA access — any party with database-level access can read values that were expected to be encrypted. Notably, the vulnerability does not grant the attacker direct read access to the plaintext via the API (the transformer still redacts the value to the literal string "ENCRYPTED" for callers without assets.view.encrypted_custom_fields), but privileged readers attempting to decrypt the stored value will encounter Error Decrypting: The payload is invalid. errors, and the plaintext persists in storage (Snipe-IT Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (GitHub Advisory). The EPSS score is 0.0, reflecting very low probability of near-term exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires authenticated API access, limiting the attack surface to users who already hold valid API credentials for the Snipe-IT instance.

1. Obtain API credentials: Acquire a valid Snipe-IT API token for an account that has asset creation permissions but lacks the assets.view.encrypted_custom_fields permission.
2. Identify encrypted custom fields: Query the Snipe-IT API or review the admin UI to enumerate custom fields that are flagged as encrypted (i.e., field_encrypted = 1).
3. Create an asset with sensitive custom-field values: Send a POST request to the /api/v1/hardware endpoint with an API token, including values for the encrypted custom fields in the request body.
4. Confirm plaintext storage: Because the store() method lacks the else continue; guard, the submitted value bypasses Crypt::encrypt() and is written directly to the database column as plaintext.
5. Access plaintext data: Retrieve the plaintext values via direct database access, database backups, or read replicas — the data is now stored unencrypted despite the column's encryption flag (Snipe-IT Advisory).

• Database: Encrypted custom-field columns containing non-Base64/non-Laravel-Crypt-formatted values (i.e., raw plaintext strings instead of the expected eyJpdiI6... Laravel encrypted payload format).
• Logs: Snipe-IT application logs showing Error Decrypting: The payload is invalid. errors when privileged users attempt to view encrypted custom fields — indicating a plaintext value was stored where ciphertext was expected.
• API Access Logs: POST requests to /api/v1/hardware from API tokens belonging to accounts without the assets.view.encrypted_custom_fields permission, particularly where encrypted custom fields were included in the payload.
• Database Backups/Replicas: Presence of human-readable sensitive values in columns documented or schema-flagged as encrypted (Snipe-IT Advisory).

Upgrade Snipe-IT to version 8.7.0 or later, which fixes the issue in commit 34dafe9eed by adding a continue; statement under the deny branch of the encryption gate in store(), mirroring the correct pattern already used in update(). As an interim workaround, restrict API access to trusted users only and avoid granting asset creation API permissions to accounts that lack assets.view.encrypted_custom_fields. After patching, review all assets created via the API by users without that permission and verify the encryption status of their custom fields — any plaintext values stored prior to the patch will need to be re-entered to be properly encrypted (Snipe-IT Advisory, GitHub Advisory).

The vulnerability was reported by researcher builtbybrayden and remediated by the Snipe-IT maintainer (snipe). The advisory was published at a Low severity level by the Snipe-IT project itself, with the CVE assigned at a Moderate/Medium level by NVD. No significant broader media coverage or notable community commentary beyond the standard advisory channels has been observed (Snipe-IT Advisory).