CVE-2024-46508: Yeti-platform Yeti Auth Bypass Vulnerability

CVE-2024-46508 Overview

CVE-2024-46508 affects the Yeti threat intelligence platform in versions prior to 2.1.12. The vulnerability stems from a hardcoded default JSON Web Token (JWT) signing secret. When operators fail to change the YETI_AUTH_SECRET_KEY environment variable from its default value of SECRET, attackers can forge valid JWT tokens. This allows unauthenticated remote attackers to impersonate any user and access protected threat intelligence data. The flaw is classified under [CWE-798] Use of Hardcoded Credentials.

Critical Impact

Remote attackers can forge authentication tokens against any Yeti instance running the default secret, gaining full access to threat intelligence data without credentials.

Affected Products

• yeti-platform yeti versions prior to 2.1.12
• Deployments using the default YETI_AUTH_SECRET_KEY value of SECRET
• Self-hosted Yeti threat intelligence repositories exposed to untrusted networks

Discovery Timeline

• 2026-05-08 - CVE-2024-46508 published to the National Vulnerability Database (NVD)
• 2026-05-08 - Last updated in the NVD database

Technical Details for CVE-2024-46508

Vulnerability Analysis

Yeti is an open-source threat intelligence platform used to aggregate observables, indicators, and tactics, techniques, and procedures (TTPs). The platform uses JWT tokens for authenticating API requests and user sessions. Token signatures rely on a server-side secret loaded from the YETI_AUTH_SECRET_KEY environment variable.

In versions before 2.1.12, the platform ships with the placeholder value SECRET as the default signing key. Administrators who deploy Yeti without overriding this variable leave token validation vulnerable to forgery. An attacker who knows the default value can craft a signed JWT for any account, including administrative users.

The vulnerability requires no prior authentication, no user interaction, and is exploitable over the network. Successful exploitation breaks the confidentiality of threat intelligence stored in Yeti, including indicators, investigations, and integrated feed credentials.

Root Cause

The root cause is the use of a static, publicly known default value for a cryptographic signing key, mapped to [CWE-798] Use of Hardcoded Credentials. The application does not enforce rotation of YETI_AUTH_SECRET_KEY at startup and does not warn operators when the default value remains in place. JWT signatures generated with the default secret are indistinguishable from legitimate tokens.

Attack Vector

An attacker reaches the Yeti web interface or API over the network. The attacker constructs a JWT payload claiming an arbitrary username, then signs it with HMAC-SHA256 using the string SECRET. The forged token is submitted in the Authorization: Bearer header. The server validates the signature against its configured secret, accepts the token, and grants the impersonated user's permissions. The attacker can then read, modify, or exfiltrate threat intelligence artifacts.

For technical context on related Yeti vulnerabilities, see the Rhino Security Labs Analysis and the GitHub CVE-2024-46507 Repository.

Detection Methods for CVE-2024-46508

Indicators of Compromise

• Authentication events for privileged accounts originating from unfamiliar IP addresses or geographies
• JWT tokens in HTTP request logs with alg: HS256 and unusually long lifetimes or non-standard iat and exp claims
• Unexpected API calls to /api/v2/users or administrative endpoints from sessions without a preceding login event
• Configuration files or container environments where YETI_AUTH_SECRET_KEY is unset or equal to SECRET

Detection Strategies

• Audit running Yeti deployments for the presence and value of the YETI_AUTH_SECRET_KEY environment variable
• Decode JWT tokens captured in reverse proxy logs and verify whether they were signed with the default secret
• Correlate API access logs against the user login table to identify sessions established without authentication events
• Flag deployments running container images tagged below 2.1.12

Monitoring Recommendations

• Forward Yeti application and web server logs to a centralized analytics platform for retention and correlation
• Alert on access to sensitive endpoints from IP addresses not previously associated with the user account
• Monitor for token reuse across multiple source addresses within short time windows

How to Mitigate CVE-2024-46508

Immediate Actions Required

• Upgrade Yeti to version 2.1.12 or later
• Set YETI_AUTH_SECRET_KEY to a cryptographically random value of at least 32 bytes and restart the service
• Invalidate all existing JWT sessions and require users to re-authenticate after rotating the secret
• Restrict network access to the Yeti web interface and API using firewall rules or a VPN

Patch Information

The yeti-platform maintainers addressed the issue in version 2.1.12. The fix prevents deployments from running with the default placeholder secret. Operators should pull the updated container image or upgrade the Python package, then verify the configured secret has been changed from SECRET before exposing the service.

Workarounds

• Place Yeti behind a reverse proxy that enforces an additional authentication layer such as mutual TLS or single sign-on
• Rotate YETI_AUTH_SECRET_KEY to a high-entropy value as a temporary measure if upgrading is not immediately possible
• Remove the Yeti instance from public network exposure until the upgrade is applied

# Generate a strong secret and configure Yeti
export YETI_AUTH_SECRET_KEY="$(openssl rand -hex 32)"
# Persist the value in your deployment configuration (docker-compose, systemd, k8s secret)
# Then restart the Yeti service to invalidate previously issued tokens