CVE-2026-116198 in Snipe-IT
Summary
by MITRE • 10/25/2026
Snipe-IT before 8.7.0 contains a missing encryption vulnerability in Api\AssetsController::store that writes plaintext into encrypted-flagged custom-field columns when callers lack assets.view.encrypted_custom_fields. Authenticated API users without that permission can create assets whose sensitive custom-field values persist unencrypted in the database, exposing them through backups, replicas, or direct database access.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified in Snipe-IT versions prior to 8.7.0 represents a critical failure in data protection mechanisms within the application's API layer, specifically located in the Api\AssetsController::store method. This flaw stems from an improper implementation of encryption controls that governs how sensitive information is persisted to the database. In secure systems, custom fields designated as encrypted should undergo cryptographic transformation before storage to ensure confidentiality even if the underlying data store is compromised. However, due to this missing encryption logic, the application fails to apply necessary ciphering operations when processing asset creation requests under specific permission conditions. This architectural oversight allows sensitive data intended for protection to be written in plaintext directly into columns that are flagged as encrypted, fundamentally undermining the security model designed to safeguard proprietary or personal information stored within these fields.
The operational impact of this vulnerability is severe because it relies on a nuanced permissions check rather than a complete absence of encryption logic across all user roles. Specifically, authenticated API users who lack the assets.view.encrypted_custom_fields permission are inadvertently granted the ability to create new asset records with sensitive custom-field values stored in an unencrypted state. This creates a significant discrepancy where data intended for restricted viewing is exposed through multiple vectors including database backups, read replicas used for reporting or disaster recovery, and direct access by database administrators who may not have application-level permissions but possess infrastructure-level access. The exposure of plaintext sensitive data such as serial numbers, license keys, hardware specifications, or other proprietary details poses a substantial risk to organizational security posture, potentially leading to intellectual property theft, regulatory non-compliance with standards like GDPR or HIPAA if applicable personal data is involved, and increased attack surface for further exploitation through information disclosure.
From a classification perspective, this vulnerability aligns closely with CWE-319 which describes the use of cleartext transmission without cryptographic protection in contexts where confidentiality is required, although it manifests here as storage rather than transit encryption failure. It also relates to CWE-200 regarding exposure of sensitive information to an unauthorized actor due to improper access control or implementation errors. In terms of adversary tactics, this flaw facilitates the ATT&CK technique T1537 which involves data exfiltration over a different network channel, as attackers could potentially extract unencrypted data from backups rather than attempting to bypass application-level authentication controls directly. The vulnerability highlights the importance of ensuring that encryption logic is applied consistently regardless of user permissions and that permission checks do not inadvertently disable security features meant for data protection at rest.
Mitigation strategies must focus on immediate patching and architectural review. Organizations running Snipe-IT versions earlier than 8.7.0 should upgrade to the latest stable release where this issue has been resolved by correcting the encryption logic in the AssetsController store method. Until upgrading is possible, administrators can implement compensating controls such as restricting API access to only trusted IP addresses and ensuring that database backups are encrypted at rest using strong cryptographic standards like AES-256. Additionally, it is advisable to review custom field configurations to identify any fields containing highly sensitive data and consider migrating them to external secret management solutions or implementing application-level encryption checks that do not depend solely on user permission flags. Regular security audits of API endpoints should be conducted to verify that all write operations involving sensitive data adhere strictly to encryption standards regardless of the calling context, ensuring that no plaintext leakage occurs through any code path within the asset creation workflow.