Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-mw3h-qjxj-6xg9
No affected components available
HMAC validation bypass via multiple .replace() calls when removing URL signature
Summary
Thumbor’s HMAC validation can be bypassed due to the use of Python’s .replace() when removing the signature from the URL before validation. Since .replace() removes all occurrences of the substring, an attacker can insert the same signature multiple times in the URL and manipulate the final URL used for validation.
This allows crafting URLs where the validated string differs from the actual requested resource, enabling loading images from unintended domains or paths.
Details
Thumbor signs URLs using HMAC-SHA1 to prevent abuse such as loading arbitrary external images or invoking filters without authorization.
During request validation, Thumbor removes the signature from the request URL before recalculating the HMAC. The relevant code:
url_signature = self.context.request.hash
if url_signature:
signer = self.context.modules.url_signer(
self.context.server.security_key
)
try:
quoted_hash = quote(self.context.request.hash)
except KeyError:
self._error(400, f"Invalid hash: {self.context.request.hash}")
return
url_to_validate = url.replace(
f"/{self.context.request.hash}/", ""
).replace(f"/{quoted_hash}/", "")
valid = signer.validate(
unquote(url_signature).encode(), url_to_validate
)
The issue is that .replace() removes every occurrence of the substring in the URL, not just the first one.
Because the signature itself appears in the URL, an attacker can inject additional copies of the signature elsewhere in the path. When Thumbor performs .replace(), these extra occurrences are also removed, resulting in a different url_to_validate than the original request.
Example
Valid request:
/ddoyYVYUbDf6Po_dzOrBhCDrXLc=/300x200/s3.glbimg.com/v1/.../image.jpg
By injecting the same hash inside the URL:
/ddoyYVYUbDf6Po_dzOrBhCDrXLc=/300x200/s3.glbimg.co/ddoyYVYUbDf6Po_dzOrBhCDrXLc=/m/v1/.../image.jpg
After .replace() removes all occurrences of the hash, the URL used for validation differs from the effective request path. This allows manipulation of the upstream host or path.
Further manipulation is possible due to the second .replace() for the URL-encoded hash (%3D), enabling more precise path manipulation.
Example:
/ddoyYVYUbDf6Po_dzOrBhCDrXLc=/300x200/s3.glbimg.com/ddoyYVYUbDf6Po/ddoyYVYUbDf6Po_dzOrBhCDrXLc%3D/ddoyYVYUbDf6Po/v1/...
Impact
This behavior may allow attackers to:
- Bypass HMAC URL validation
- Load images from arbitrary domains
- Abuse Thumbor deployments as an open proxy / image fetcher
- Circumvent domain restrictions intended by the signed URL mechanism
Root Cause
Use of .replace() without limiting the number of replacements when removing the signature from the URL.
Since the signature is part of the request path, using a global replacement allows attackers to place additional occurrences of the same substring to influence the validated string.
Suggested Fix
Remove only the first occurrence of the signature or explicitly parse the URL components instead of performing global string replacement.
Example:
url.replace(f"/{self.context.request.hash}/", "", 1)
Alternatively, reconstruct the unsigned URL deterministically from the parsed request components.
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a high impact on the integrity of the data. There is a low impact on the availability of the system.
Exploitation activity has been observed. Apply available patches or mitigations urgently.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard