CVE-2026-110214 in Snowyinfo

Summary

by MITRE • 10/13/2026

Snowy 3.6.5 contains a hard-coded HMAC key vulnerability that allows unauthenticated attackers to forge download signatures for the /dev/file/download endpoint by using the published FILE_DOWNLOAD_SIGN_SECRET constant. Attackers can compute HMAC-SHA256 signatures of guessed file ids offline to download stored files such as avatars, editor images and attachments.

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 10/14/2026

The vulnerability identified in Snowy version 3.6.5 represents a critical failure in cryptographic key management, specifically categorized under CWE-798: Use of Hard-coded Credentials. The core technical flaw lies within the application's handling of digital signatures for file access control mechanisms. The system utilizes an HMAC-SHA256 algorithm to generate authentication tokens required for accessing sensitive resources via the /dev/file/download endpoint. However, instead of deriving this signing key from a secure, randomized source or storing it in a protected configuration store separate from the application codebase, the developers embedded the secret directly into the source code as a public constant named FILE_DOWNLOAD_SIGN_SECRET. This architectural decision fundamentally undermines the security model because HMAC signatures rely entirely on the secrecy of the shared key; once an attacker obtains this key, they can independently generate valid authentication tokens without any interaction with the server's session management or login systems.

From an operational perspective, this vulnerability allows unauthenticated attackers to bypass access controls and retrieve arbitrary files stored within the application environment. By leveraging the exposed constant, adversaries can perform offline computations of HMAC-SHA256 signatures for various file identifiers. Since many applications use predictable patterns for file IDs, such as sequential integers or hashes based on user data, an attacker can systematically guess these identifiers to construct valid download requests. This capability enables the exfiltration of sensitive assets including user avatars, which may reveal personal information about users; editor images that might contain proprietary content or metadata; and various attachments that could include confidential documents, configuration files, or other restricted resources. The ability to forge signatures offline means there is no need for brute-force attacks against login pages or exploitation of session hijacking vulnerabilities, making this attack vector highly efficient and difficult to detect through standard intrusion detection systems that monitor for failed authentication attempts rather than successful but unauthorized data access.

The impact extends beyond simple data leakage, as the ability to download arbitrary files can serve as a stepping stone for further attacks within the network infrastructure. If sensitive configuration files or database dumps are accessible via this endpoint, attackers could extract connection strings and credentials, facilitating lateral movement or direct compromise of backend systems. Furthermore, the exposure of user avatars and personal attachments contributes significantly to privacy violations and potential identity theft scenarios. This vulnerability aligns with ATT&CK technique T1005: Data from Local System, as it involves the unauthorized collection of data stored on local drives accessible through application endpoints. It also reflects poor adherence to OWASP guidelines regarding secure configuration and cryptographic practices, specifically failing to protect sensitive information in transit or at rest by ensuring that secrets are not embedded in client-side code or publicly accessible repositories.

To mitigate this vulnerability, immediate remediation is required to replace the hard-coded secret with a dynamically generated key stored securely outside of the application source code. Best practices dictate using environment variables, secure vaults such as HashiCorp Vault or AWS Secrets Manager, or hardware security modules to manage cryptographic keys. The current FILE_DOWNLOAD_SIGN_SECRET constant must be removed from the codebase and rotated immediately, assuming it has not been widely disseminated in public repositories like GitHub. Additionally, implementing rate limiting on the /dev/file/download endpoint can help mitigate bulk enumeration attacks where attackers guess file IDs systematically. Access controls should also be reinforced to ensure that even if a valid signature is presented, the user associated with that session or token actually owns or has permission to access the requested resource, adding a layer of authorization beyond mere cryptographic validity. Regular security audits and static application security testing (SAST) scans configured to detect hard-coded secrets are essential preventive measures against similar future occurrences.

Responsible

VulnCheck

Reservation

10/13/2026

Disclosure

10/13/2026

Moderation

accepted

EPSS

0.00456

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!