The vulnerability description explicitly points out an SSRF flaw in trestle/core/remote/cache.py, specifically mentioning the HTTPSFetcher._do_fetch() method. Analysis of the provided patches confirms this. Both commits, 53de5e75332888ea54f5da41d4c7859bb1d608e1 and 5c65c5926fe7ca908b9c1d281f904e7d97ba8310, introduce a new URLSecurityValidator class and apply it within the remote fetcher classes.
The core of the vulnerability lies in the _do_fetch methods of HTTPSFetcher and SFTPFetcher. These methods are responsible for making the actual network connections based on a user-supplied URI. Before the patch, these methods were called without any validation of the target URL, allowing an attacker to specify internal IP addresses or cloud metadata endpoints.
The patch introduces two layers of protection:
- Initial Validation: In the
__init__ method of both HTTPSFetcher and SFTPFetcher, the validate_url method of the new URLSecurityValidator is called. This performs an initial check on the URL.
- Time-of-Check to Time-of-Use (TOCTOU) Mitigation: A second call to
validate_url is added at the very beginning of the _do_fetch methods. The comment Re-validate URL before fetch to prevent DNS rebinding attacks makes it clear that this is to prevent attacks where the DNS record for a hostname is changed between the initial validation and the actual connection.
The presence of these added validation calls in the patches is direct evidence that the _do_fetch functions were the points where the unvalidated, user-supplied data was used, making them the vulnerable functions. The advisory focuses on HTTPSFetcher, but the patch correctly identifies and fixes the same flaw in SFTPFetcher. Therefore, both HTTPSFetcher._do_fetch and SFTPFetcher._do_fetch would appear in a runtime profile during exploitation.