txtdot SSRF vulnerability in /get

The SSRF vulnerability in txtdot allows an attacker to bypass network segmentation and access internal resources that are not directly exposed to the internet. An attacker could use this to scan the internal network for open ports and services, potentially identifying other vulnerable systems. They could also retrieve sensitive data from internal web applications or APIs, such as configuration files, database credentials, or user data. The blast radius extends to any internal resource accessible via HTTP GET requests from the txtdot server. While version 1.7.0 prevents the display of the response, the underlying request forwarding functionality remains, meaning sensitive data can still be exfiltrated through other means.

Organizations running txtdot versions prior to 1.7.0, particularly those with sensitive internal resources accessible via HTTP, are at risk. Shared hosting environments where txtdot is deployed alongside other applications could also be vulnerable, as an attacker could potentially exploit the SSRF vulnerability to access resources belonging to other tenants.

• nodejs / server:

  ps aux | grep txtdot

• nodejs / server:

  journalctl -u txtdot --since "1 hour ago"

• generic web:

  curl -I http://<txtdot_server>/get?url=http://internal_resource

• generic web: Review access logs for unusual outbound requests originating from the txtdot server's IP address.

1. 2024-07-26Disclosure

   disclosure

1. Reserviert2024-07-22
2. Veröffentlicht2024-07-26
3. Geändert2024-08-02
4. EPSS aktualisiert2026-04-02

The primary mitigation for CVE-2024-41812 is to upgrade txtdot to version 1.7.0 or later. This version prevents the display of responses from forged requests, reducing the immediate risk of data exposure. However, it does not completely eliminate the SSRF vulnerability. For complete mitigation, a firewall should be implemented between the txtdot server and other internal network resources, restricting outbound connections to only necessary destinations. Consider using a Web Application Firewall (WAF) to filter outbound requests and block suspicious traffic. After upgrading, confirm the fix by attempting to send a request to an internal resource via the /get route and verifying that the response is not displayed.