Skip to main content

Threats Tagged 'cve-2026-53505'

View all threats tagged with 'cve-2026-53505'. Filter and sort to focus on specific types of threats.

Pro Console Lifetime

Stop chasing alerts. Route them.

Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.

Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)

View Plans & Pricing

API access activates after upgrading in Console -> Billing.

Breach by OffSeqOFFSEQFRIENDS — 25% OFF

Check if your credentials are on the dark web

Instant breach scanning across billions of leaked records. Free tier available.

Scan now

Filter Threats

Narrow down the results by type, severity, or affected countries

Search threats by title, CVE ID, or description. Maximum 100 characters.
Active filters (1):Tag: cve-2026-53505

Threats Tagged 'cve-2026-53505'

Click on any threat for detailed analysis and mitigation recommendations

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

Join the discussion

Showing 1 to 1 of 1 result

Filters:Tag: cve-2026-53505
Page 1 of 1
OffSeq TrainingCredly Certified

Lead Pen Test Professional

Technical5-day eLearningPECB Accredited
View courses