GHSA-phj3-59pf-cp83

### Summary Thumbor's `filters:proportion(<value>)` filter does not enforce an upper bound on `<value>` 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://<host>:<port>/<url-sign>/100x100/filters:proportion(10000)/example.jpg`

#### Example request 2 (/unsafe/) If `/unsafe/` is enabled:

`http://<host>:<port>/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.