Snipe-IT EUVD-2026-109456

Requires a valid authenticated Snipe-IT API token for a user who has permission to create assets but does NOT hold assets.view.encrypted_custom_fields, plus at least one custom field configured with the encrypted flag; the attacker must submit a value for that field via the asset-creation API call. Exploitation is limited to the Api\AssetsController::store path only - the API update path, non-API web paths, and BulkAssetsController correctly skip the write on gate denial - and only to versions <= 8.6.3. The resulting plaintext is not readable back through the API (the transformer redacts it to "ENCRYPTED"), so realized exposure additionally depends on an actor having database-layer access through backups, replicas, or direct DB/DBA access.

Signals point to a genuine but modest-priority issue. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N) scores 5.3 (medium) and is internally consistent with the mechanism: network-reachable API, low attack complexity, but PR:L meaning an authenticated caller is required, and the only impact set is VI:L (integrity) with VC:N confidentiality - the advisory confirms this is not a read bypass because the API transformer redacts the field back to the literal string "ENCRYPTED" for anyone lacking the permission. No EPSS score, no CISA KEV entry, and no proof-of-concept exploit reference are present in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The vuln.today decision label is this_month, not act_now or emergency, consistent with the medium severity and absence of exploitation signals. The real-world risk is that of a latent encryption-at-rest failure: sensitive custom-field values that operators believed were encrypted are stored as plaintext and are exposed to DB backups, read replicas, and direct/DBA database access - the harm materializes only for actors with database-layer access, not through the API itself, which is why this is a lower practical priority than the 'network/unauthenticated' surface of the vector might first suggest. No key signals conflict; the main gap is the absence of EPSS/KEV data, which is expected rather than an error for a freshly disclosed medium-severity flaw.

An authenticated Snipe-IT API user who can create assets but was not granted assets.view.encrypted_custom_fields submits a POST to the asset-creation endpoint including a value for a custom field flagged as encrypted. The faulty gate in Api\AssetsController::store skips the Crypt::encrypt() call but still writes the value, so the sensitive data lands in the database as plaintext in a column documented as encrypted, where it is later exposed via backups, replicas, or DBA access. No public exploit identified at time of analysis.