Yeti JWT Flaw CVE-2024-46508 Lets Attackers Forge Auth Tokens

Executive Summary

A hard-coded default JWT signing secret in the Yeti threat intelligence platform (versions prior to 2.1.12) allows any attacker who knows the default key to forge valid authentication tokens, gaining unrestricted access to the platform's web interface and API. Tracked as CVE-2024-46508 with a CVSS score of 7.5 (High), the flaw stems from the application's failure to enforce a unique YETI_AUTH_SECRET_KEY environment variable at installation. The disclosure comes from Rhino Security Labs, who identified the issue during a security assessment of the open-source platform.

Technical Analysis

Yeti is an open-source threat intelligence platform used by security teams to aggregate, store, and analyze indicators of compromise (IOCs) from multiple sources. The vulnerability resides in the JWT authentication mechanism: if an administrator does not explicitly set the YETI_AUTH_SECRET_KEY environment variable to a non-default value, Yeti falls back to a hard-coded secret embedded in the source code. An unauthenticated remote attacker who knows this default secret can craft arbitrary JWT tokens with any user identity, including administrative accounts.

The JWT library used by Yeti signs tokens symmetrically with HMAC-SHA256. Without a unique secret, the signing key is effectively public knowledge — anyone who inspects the Yeti source code or documentation can derive it. Once a forged token is generated, the attacker can present it to the Yeti web server or API endpoints, which will accept it as legitimate. This bypasses all authentication checks, granting the attacker full read and write access to the platform's data, including stored threat intelligence feeds, user accounts, and configuration settings.

Rhino Security Labs notes that the issue is exacerbated by the fact that many Yeti deployments run in Docker containers or automated CI/CD pipelines where environment variables may not be configured explicitly. The default secret is clearly documented in the Yeti installation guide as a placeholder, but operators may overlook the step of changing it. The researchers demonstrated token forgery against a default Yeti installation in under 30 seconds using a simple Python script.

Mitigations & Recommendations

Administrators running Yeti versions prior to 2.1.12 should immediately upgrade to version 2.1.12 or later, which removes the hard-coded default and requires a unique secret to be set. For deployments that cannot upgrade immediately, operators must ensure the YETI_AUTH_SECRET_KEY environment variable is set to a cryptographically random, high-entropy string (at least 32 bytes) and that the variable is properly injected into the application's runtime environment. After changing the secret, all existing JWT tokens are invalidated, so all users and automated processes will need to re-authenticate.

Defenders should audit their Yeti installations for use of the default secret by checking application logs for unexpected authentication events or by attempting to validate a token signed with the known default key. Organizations using Yeti in multi-tenant or internet-facing configurations should treat this vulnerability as critical — a successful exploit leads to complete compromise of the threat intelligence platform, which can be leveraged to poison feeds or exfiltrate sensitive IOC data.