Transformers URL Username Injection - Origin Impersonation Fetch
Older versions of the Transformers library checked if an image or model URL was 'trusted' by simply looking at whether the URL string starts with a known domain. Attackers can craft URLs that pass this check but actually connect somewhere else entirely, letting them redirect the fetch to a malicious server.
How the attack works
An attacker builds a URL like https://www.youtube.com@attacker.tld/x.png, putting the trusted domain in the username portion of the URL, or uses a hostname like www.youtube.com.attacker.tld where the trusted domain appears as a subdomain label. The library's origin check uses a simple 'starts with' string comparison, which is fooled by both tricks. The underlying HTTP client, however, connects to the real host — attacker.tld — not the trusted one. This lets the attacker serve phishing content, malware, or capture data sent to what the victim believes is a trusted origin.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 0f2a6c19-4c8b-4d7e-9a3f-1b5e8c274d63
- Severity
- High
Why it matters
An application using this library to fetch images or model assets can be tricked into pulling content from an attacker-controlled server instead of the intended trusted source, enabling phishing, malware delivery, or data exfiltration.
What you can do
- →Upgrade Hugging Face Transformers past version 4.49.0 where this URL validation flaw was present.
- →Do not rely on startswith()-style string checks for URL origin validation anywhere in your own code; parse the URL and compare the actual hostname.
- →Restrict outbound network access from services that process untrusted URLs to an allowlist of known hosts.
- →Review logs for HTTP requests where the connected host differs from the domain that appears in a URL's username or as a non-final hostname label.
Known benign look-alikes
- HTTP basic-auth URLs whose username is an e-mail address or a dotted service account (alice%40corp.com:token@registry / first.last@host). Mitigated - the rule discards any userinfo whose user component contains '@' or '%40', and requires the embedded domain to differ from the host actually connected to.
- Vendor or CDN hostnames that legitimately embed a common TLD label mid-name (customer.com.cdn.provider.net) and split-horizon internal suffixes appended to a public name. Mitigated - this variant is only reported when corroborated by a Python/Jupyter interpreter in the caller's own lineage or by an image / model-asset path, and never on hostnames with fewer than four labels (so example.com.au, foo.co.uk and similar ccTLD forms are never matched).
- Security research, dependency-scanning or CI harnesses that deliberately replay the CVE payload against a local sink. Expect these to report; they are genuinely the pattern and should be triaged by lineage.
- Internal proxies or crawlers that stuff an origin hint into the userinfo field of a rewritten URL. Reported, not blocked - this rule only reports.