# Transformers URL Username Injection - Origin Impersonation Fetch

- **Severity:** High
- **Signature ID:** `0f2a6c19-4c8b-4d7e-9a3f-1b5e8c274d63`
- **OWASP:** LLM03 (Supply Chain)

## Summary

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.

## 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.

## References

- https://github.com/huggingface/transformers/blob/main/src/transformers/image_utils.py
- https://cwe.mitre.org/data/definitions/20.html
- https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/
- https://url.spec.whatwg.org/#url-parsing

---
Source: https://www.netzilo.com/threats/transformers-url-username-injection