GHSA-phj3-59pf-cp83 Thumbor proportion filter allows unbounded post-transform resize leading to remote DoS

• PyPI thumbor: < 7.8.0 → fixed in 7.8.0

Summary Thumbor's `filters:proportion()` filter does not enforce an upper bound on `` and runs in the post-transform phase. An attacker can trigger extremely large resizes (CPU/memory exhaustion) and cause denial of service. Details • Filter implementation: `thumbor/filters/proportion.py` • `value` is parsed as a float (`BaseFilter.DecimalNumber`) with no maximum. • The filter computes `new_width = source_width * value` and `new_height = source_height * value` and then calls `engine.resize(new_width, new_height)`. • Execution phase: `proportion` runs in the default POST_TRANSFORM phase (after the main transform pipeline). This means it can effectively bypass request-level size clamping that happens earlier in the request lifecycle (e.g., `MAX_WIDTH`/`MAX_HEIGHT` applied to `req.width/req.height`). Documentation states the `percentage` argument should be `0.0 to 1.0` (`docs/proportion.rst`), but the implementation does not enforce this constraint. PoC Preconditions • The `proportion` filter is enabled (it is enabled by default via `BUILTIN_FILTERS`). • Either: • `/unsafe/` URLs are allowed (`ALLOW_UNSAFE_URL=True`, common default in some deployments), OR • `/unsafe/` is disabled, and the attacker has a valid signed URL (i.e., the attacker is an authorized user/partner, or otherwise can obtain signed URLs issued by a trusted signing service). Example request 1 (signed URL) The following request was used to reproduce the issue and causes severe resource exhaustion: `http://://100x100/filters:proportion(10000)/example.jpg` Example request 2 (/unsafe/) If `/unsafe/` is enabled: `http://:/unsafe/100x100/filters:proportion(10000)/example.jpg` Impact • Remote Denial of Service via CPU and/or memory exhaustion (and potentially process crash / OOM kill). • Exploitability depends on deployment: • If `/unsafe/` is enabled: unauthenticated remote DoS. • If `/unsafe/` is disabled: the attacker needs a valid signed URL (i.e., the attacker can legitimately request signed URLs, or has access to signed URLs issued for other users/partners). If signed URLs are not exposed to untrusted parties, exploitability is reduced but the risk still applies to any party who can generate/use signed URLs. Suggested remediation • Enforce a strict bound on the `proportion` parameter (e.g., `0.0 < value <= 1.0` as documented), or define a safe maximum based on intended semantics.