The vulnerability allows bypassing a workspace-only filesystem policy during the processing of Feishu docx uploads. This is identified as an incomplete fix for a previous SSRF vulnerability (GHSA-qf48-qfv4-jjm9). The provided patch commit d7c3210cd6f5fdfdc1beff4c9541673e814354d5 modifies the fetchWithSsrFGuard function in src/infra/net/fetch-guard.ts.
Analysis of the patch reveals a Time-of-check, time-of-use (TOCTOU) vulnerability in the fetchWithSsrFGuard function. In the vulnerable version, the code first resolves the requested hostname and validates it against a security policy (resolvePinnedHostnameWithPolicy). However, if the system is configured to use a trusted environment proxy, the result of this validation is discarded. The original, unvalidated hostname is passed to the proxy, which then performs its own DNS resolution.
An attacker could exploit this by providing a URL in a docx file that points to a domain they control. At the time of the initial check by fetchWithSsrFGuard, the domain resolves to a safe, public IP address. Immediately after the check, the attacker can change the DNS record to point to a local or internal IP address (e.g., 127.0.0.1). The proxy, resolving the hostname after the check, would then connect to the malicious local IP, bypassing the SSRF protection and allowing access to local files, thus violating the 'Workspace-Only Filesystem Policy'.
The vulnerable function is fetchWithSsrFGuard because it contains the flawed logic that allows the SSRF bypass. The fix addresses this by skipping the initial DNS pinning check when a trusted proxy is in use, correctly delegating the responsibility of safe resolution to the proxy.