CVE-2026-77294 in TREK
Summary
by MITRE • 09/24/2026
TREK is a collaborative travel planner. Prior to 3.3.0, TREK allows an authenticated user to store an attacker-controlled llm_base_url through the settings API when the LLM_PARSING feature is enabled. Write permission to the target trip instance is required to trigger the vulnerable AI-assisted import path. The value is consumed by the clients in server/src/nest/llm-parse/clients/openai-compatible.client.ts, server/src/nest/llm-parse/clients/anthropic.client.ts, and server/src/nest/llm-parse/router/ollama-format.client.ts without applying the server-side request forgery guard. Triggering AI-assisted trip parsing causes the server to request the supplied destination, and upstream error response text can be returned in parsing warnings. This permits internal service discovery and access to link-local cloud metadata, with possible disclosure of infrastructure credentials and subsequent modification of protected cloud resources. This issue is fixed in version 3.3.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in TREK prior to version 3.3.0 represents a critical server-side request forgery flaw within the application's AI-assisted trip parsing functionality. The core technical deficiency lies in the handling of user-supplied configuration data, specifically the llm_base_url parameter accessible through the settings API when the LLM_PARSING feature is enabled. An authenticated attacker with write permissions to a target trip instance can inject arbitrary URLs into this field. This value is subsequently consumed by multiple backend client modules responsible for interacting with large language model services, including implementations compatible with OpenAI, Anthropic, and Ollama formats. The critical failure occurs because the server-side logic does not implement any form of request validation or allowlisting before initiating HTTP requests to the specified destination. Consequently, when an AI-assisted trip parsing operation is triggered, the application blindly follows the attacker-controlled URL without verifying its legitimacy or origin.
This lack of input sanitization and domain verification allows for a classic Server-Side Request Forgery attack vector. By directing internal service discovery mechanisms toward local endpoints, an attacker can probe the internal network topology from within the trusted server environment. More critically, this capability enables access to link-local cloud metadata services, such as those found in AWS EC2 or Google Cloud Platform instances. These metadata endpoints often contain sensitive infrastructure credentials, including temporary security tokens and API keys required for accessing other protected cloud resources. The vulnerability is exacerbated by the fact that upstream error response text from these internal requests can be returned within parsing warnings to the client interface. This side-channel information leakage provides the attacker with confirmation of successful access and potentially reveals details about the underlying infrastructure architecture, facilitating further exploitation attempts against connected systems.
From a classification perspective, this issue aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically involving the lack of validation for user-controlled URLs that are used to make server-side requests. The attack pattern corresponds to ATT&CK technique T1557, Adversary-in-the-Middle, as it allows an attacker to position themselves between the application and internal services to intercept or manipulate communications. Furthermore, the potential disclosure of infrastructure credentials falls under CWE-200 Exposure of Sensitive Information to an Unauthorized Actor. The operational impact is severe, as compromise of cloud metadata can lead to full account takeover within the affected cloud environment, allowing for data exfiltration, resource manipulation, and lateral movement across the organization's network perimeter.
Mitigation strategies must focus on implementing strict allowlisting mechanisms for outbound requests initiated by the LLM parsing components. The application should validate that any llm_base_url provided by users resolves only to known, trusted external domains or IP ranges designated for legitimate AI service providers. Additionally, deploying a web application firewall with SSRF detection rules can provide an additional layer of defense by blocking requests directed at private IP address spaces and cloud metadata endpoints. For existing deployments running versions prior to 3.3.0, immediate upgrading is required as the issue has been resolved in version 3.3.0. Until patching occurs, administrators should consider disabling the LLM_PARSING feature entirely if it is not essential for business operations, thereby removing the attack surface associated with this specific code path.