A critical security flaw has been identified in the popular Yeti Forensic Intelligence platform, exposing its users to unauthenticated remote code execution (RCE) attacks.
Two vulnerabilities designated CVE-2024-46507 and CVE-2024-46508, affect versions 2.0 to 2.1.11 of the Yeti platform, posing significant risks to cybersecurity and DFIR (Digital Forensics and Incident Response) teams.
Yeti, widely used by threat intelligence professionals, enables users to catalog, analyze, and link observables such as IP addresses, TTPs (Tactics, Techniques, and Procedures), and threat actors.
.png
)
With over 10,000 DockerHub pulls and nearly 2,000 GitHub stars, its popularity underscores the urgency of addressing these vulnerabilities, as per a report by Rhino Security Labs.
CVE-2024-46507: SSTI Leads to Remote Code Execution
The first vulnerability, CVE-2024-46507, involves a Server-Side Template Injection (SSTI) flaw that allows attackers to execute arbitrary code on targeted Yeti servers.
The issue arises from Yeti’s feature allows users to create custom templates for exporting observables like IP addresses, hashes, and domains.
These templates are processed on the backend without input sanitization, leaving the platform susceptible to malicious payloads embedded within the templates.
Steps to Exploit
- Create a Malicious Template: Attackers craft a template with embedded malicious commands.
- Create an Observable: Observables can be generated via “Observables -> New Observable -> Save.”
- Export Observable Using Malicious Template: Upon export, users download a .txt file, which executes the attacker’s command on the server backend.
The consequences can be severe, ranging from attackers gathering intelligence on monitored threat actors to altering or destroying critical observables.
CVE-2024-46508: Static Insecure JWT Secret
The second vulnerability, CVE-2024-46508, exposes Yeti deployments to authentication bypasses due to the use of a static, insecure JWT secret.
During installation, Yeti does not require users to modify the default .env file, where the JWT secret is hardcoded as “SECRET.”
Additionally, Yeti’s documentation does not urge users to configure the secret, increasing the likelihood of unmodified deployments in production environments.
With access to the static JWT secret, attackers can generate valid tokens, bypassing authentication altogether.
When combined with SSTI-driven RCE, this flaw enables attackers to escalate privileges, fully compromise the server, and infiltrate sensitive threat intelligence data.
The vulnerabilities have been patched in version 2.1.12 of Yeti. Users are strongly advised to upgrade immediately. The fixed version can be obtained from the Yeti GitHub repository.
- Update to Version 2.1.12: Apply the patch to address both SSTI and JWT vulnerabilities.
- Configure Unique Secrets: Ensure that JWT secrets are replaced during installation to prevent authentication bypasses.
- Sanitize User Inputs: Employ proper input validation across all modules.
Yeti users in the DFIR community should act promptly to secure their deployments and avoid potential breaches.
Collect Threat Intelligence with TI Lookup to improve your company’s security - Get 50 Free Request
 attacks.){kind=link}