CVE-2026-4964: letta-ai letta SSRF Vulnerability

CVE-2026-4964 Overview

A Server-Side Request Forgery (SSRF) vulnerability has been identified in letta-ai letta version 0.16.4. This vulnerability affects the function _convert_message_create_to_message within the file letta/helpers/message_helper.py of the component File URL Handler. Through manipulation of the ImageContent argument, an attacker can force the server to make unintended requests to internal or external resources. The attack can be launched remotely by an authenticated attacker with low privileges.

Critical Impact

Authenticated attackers can exploit this SSRF vulnerability to access internal network resources, potentially leading to data exfiltration, internal service enumeration, or further attacks against internal infrastructure.

Affected Products

• letta-ai letta version 0.16.4
• Potentially other versions prior to a patched release

Discovery Timeline

• 2026-03-27 - CVE-2026-4964 published to NVD
• 2026-03-30 - Last updated in NVD database

Technical Details for CVE-2026-4964

Vulnerability Analysis

The vulnerability resides in the _convert_message_create_to_message function within letta/helpers/message_helper.py. This function handles File URL processing as part of the File URL Handler component. When processing ImageContent arguments, the application fails to properly validate or sanitize user-supplied URL inputs before making server-side requests.

SSRF vulnerabilities (CWE-918) occur when an application fetches remote resources based on user-controlled input without proper validation. In this case, an attacker can craft malicious URLs pointing to internal network resources, localhost services, or cloud metadata endpoints that should not be accessible from external sources.

Root Cause

The root cause of this vulnerability is improper input validation in the File URL Handler component. The _convert_message_create_to_message function processes URLs from the ImageContent argument without implementing sufficient safeguards such as URL allowlisting, scheme validation, or network destination restrictions. This allows attackers to supply arbitrary URLs that the server will fetch on their behalf.

Attack Vector

The attack is conducted remotely over the network and requires the attacker to have low-level authenticated access to the application. The attacker provides a crafted URL through the ImageContent parameter, which the vulnerable function processes without adequate validation. The server then makes a request to the attacker-specified destination, potentially exposing internal services, cloud provider metadata endpoints (such as http://169.254.169.254/), or other sensitive resources.

The exploit has been publicly disclosed and proof-of-concept details are available. See the GitHub Code Snippet for technical details on the vulnerability mechanism.

Detection Methods for CVE-2026-4964

Indicators of Compromise

• Unusual outbound HTTP/HTTPS requests from the letta application server to internal IP ranges (e.g., 10.x.x.x, 172.16.x.x, 192.168.x.x)
• Server requests to cloud metadata endpoints such as 169.254.169.254 or metadata.google.internal
• Anomalous requests to localhost or loopback addresses (127.0.0.1, ::1) originating from the application
• Log entries showing URL fetch operations with unexpected or suspicious destination addresses

Detection Strategies

• Monitor network traffic from the letta application server for connections to internal IP ranges or cloud metadata services
• Implement web application firewall (WAF) rules to detect SSRF patterns in ImageContent parameters
• Review application logs for the _convert_message_create_to_message function processing unusual URLs
• Deploy behavioral analysis to detect deviation from normal application URL fetch patterns

Monitoring Recommendations

• Enable detailed logging for all URL fetch operations within the letta application
• Configure network monitoring to alert on outbound connections from the application tier to internal network segments
• Set up intrusion detection rules specifically targeting SSRF attack patterns
• Implement DNS query monitoring to detect resolution attempts for internal hostnames from the application server

How to Mitigate CVE-2026-4964

Immediate Actions Required

• Review and restrict the application's access to internal network resources using network segmentation
• Implement URL allowlisting for the ImageContent parameter to permit only trusted external domains
• Deploy a web application firewall with SSRF protection rules in front of the letta application
• Disable or restrict the File URL Handler functionality if not required for business operations
• Monitor for exploitation attempts using the detection strategies outlined above

Patch Information

The vendor was contacted early about this disclosure but did not respond. As of the last modification date (2026-03-30), no official patch has been released by letta-ai. Organizations should monitor the VulDB entry and the official letta-ai repository for security updates.

Workarounds

• Implement a proxy or gateway service that validates and sanitizes all URLs before they are processed by the letta application
• Configure network-level controls to block the application server from accessing internal IP ranges, localhost, and cloud metadata endpoints
• Apply input validation at the application level to restrict URL schemes to https:// only and block requests to private IP ranges
• Consider running the letta application in a network-isolated environment with restricted egress capabilities

# Example network mitigation using iptables to block internal network access
# Apply on the server running letta to prevent SSRF to internal resources

# Block access to common internal network ranges
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP

# Block cloud metadata endpoints
iptables -A OUTPUT -d 169.254.169.254 -j DROP

# Block localhost access from application (if applicable)
iptables -A OUTPUT -d 127.0.0.0/8 -j DROP