CVE-2025-64180: Manager-io Auth Bypass Vulnerability

CVE-2025-64180 Overview

A critical Server-Side Request Forgery (SSRF) vulnerability has been identified in Manager-io/Manager accounting software. This vulnerability exists in Manager Desktop and Server versions 25.11.1.3085 and below, permitting unauthorized access to internal network resources through a Time-of-Check Time-of-Use (TOCTOU) race condition in the DNS validation mechanism.

The flaw lies in the fundamental design of the DNS validation mechanism, where attackers can exploit the TOCTOU condition to bypass network isolation controls. This enables access to internal services, cloud metadata endpoints (such as AWS IMDSv1 at 169.254.169.254), and other protected network segments. Notably, the Desktop edition requires no authentication whatsoever, while the Server edition requires only standard user authentication, significantly lowering the barrier to exploitation.

Critical Impact

This vulnerability allows complete bypass of network isolation controls, enabling attackers to access internal services, cloud infrastructure metadata, and protected network segments. The lack of authentication requirement in the Desktop edition makes this particularly dangerous for organizations running Manager on internal networks.

Affected Products

• Manager Desktop versions 25.11.1.3085 and below
• Manager Server versions 25.11.1.3085 and below

Discovery Timeline

• 2025-11-07 - CVE-2025-64180 published to NVD
• 2025-11-12 - Last updated in NVD database

Technical Details for CVE-2025-64180

Vulnerability Analysis

This vulnerability is classified under CWE-367 (Time-of-Check Time-of-Use Race Condition). The flaw exists in how the application validates DNS resolutions before making network requests. The DNS validation check and the subsequent network request occur as separate operations, creating a window of opportunity for attackers.

When the application checks whether a requested URL resolves to a permitted host, an attacker can initially provide a hostname that resolves to an allowed IP address. However, by the time the actual network request is made, the DNS resolution can return a different IP address—one pointing to internal resources. This technique, often called DNS rebinding, allows bypassing network access controls that would otherwise prevent access to internal infrastructure.

The vulnerability is particularly severe in cloud environments where metadata endpoints like http://169.254.169.254/latest/meta-data/ can be accessed to retrieve sensitive instance credentials, IAM role tokens, and configuration data.

Root Cause

The root cause is a TOCTOU race condition in the DNS validation mechanism. The application performs DNS validation as a security check before executing network requests, but fails to ensure atomicity between the validation step and the actual request execution. This design flaw allows the DNS resolution to change between the check and the use, bypassing the intended security controls.

Attack Vector

The attack exploits the network-accessible interface of Manager software. An attacker can craft requests that initially pass DNS validation but ultimately resolve to internal network addresses during the actual request phase. The attack flow involves:

1. Attacker controls a malicious DNS server or uses a DNS rebinding service
2. Initial DNS query during validation returns an allowed external IP
3. Subsequent DNS query during actual request returns an internal IP (e.g., 10.0.0.1, 192.168.1.1, or cloud metadata endpoint 169.254.169.254)
4. Application makes request to internal resource, bypassing network isolation

For technical implementation details and proof-of-concept information, refer to the GitHub Security Advisory.

Detection Methods for CVE-2025-64180

Indicators of Compromise

• Outbound DNS requests with unusually short TTL values from Manager application hosts
• Network traffic from Manager servers to internal IP ranges that should not be accessed
• Connections to cloud metadata endpoints (e.g., 169.254.169.254) from application servers
• Multiple rapid DNS resolutions for the same hostname returning different IP addresses

Detection Strategies

• Monitor network flows from Manager application hosts for connections to RFC 1918 private IP ranges and link-local addresses
• Implement DNS query logging and alert on suspicious patterns including rapid re-resolution of hostnames
• Deploy network segmentation monitoring to detect unauthorized internal network access
• Use cloud provider security tools to monitor for metadata endpoint access from application workloads

Monitoring Recommendations

• Configure firewall rules to log and alert on outbound connections from Manager hosts to internal network segments
• Enable cloud metadata service logging (e.g., AWS CloudTrail for IMDSv2 enforcement monitoring)
• Implement application-level logging to track all external URL requests processed by Manager software
• Deploy network detection rules for DNS rebinding attack patterns

How to Mitigate CVE-2025-64180

Immediate Actions Required

• Upgrade Manager Desktop and Server to version 25.11.1.3086 or later immediately
• Restrict network access from Manager application hosts to only required external services
• Enable authentication on Manager Server instances if not already configured
• Block access to cloud metadata endpoints from application workloads at the network level

Patch Information

The vulnerability has been addressed in Manager version 25.11.1.3086. Organizations should update all affected Manager Desktop and Server installations to this version or later. The patch addresses the TOCTOU vulnerability in the DNS validation mechanism, ensuring proper validation persists through the request execution.

For complete details on the security fix, see the GitHub Security Advisory.

Workarounds

• Implement network-level controls to prevent Manager hosts from accessing internal network ranges
• Deploy a web proxy that performs proper DNS pinning for all outbound requests from Manager
• Use cloud provider metadata service protections such as IMDSv2 on AWS which requires session tokens
• Isolate Manager instances in a dedicated network segment with strict egress filtering

# Example: Block access to cloud metadata endpoint from Manager hosts (iptables)
iptables -A OUTPUT -d 169.254.169.254 -j DROP

# Example: Block access to common internal 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