GHSA-2xmm-m4wv-3fjh

The image resizer classified external sources by testing whether the source string began with the substring `http`, and the string-source branch in `ResizeImageItem::fromObject()` accepted any value containing `://` as a URL. As a result, non-http(s) PHP stream wrappers such as `phar://`, `file://` and `ftp://` could be stored in the resizer cache and later passed to the underlying image library. On a `phar://` path this can lead to metadata deserialization during subsequent file operations. **Exploitation requires an existing template-authoring or backend-configuration primitive that passes untrusted input into the `|resize` Twig filter (or the `ResizeImages::resize()` API).** The `/resize/{file}` route itself is a lookup against a cache entry that was previously written by trusted server-side code, and an unauthenticated visitor cannot cause an arbitrary source path to be written into that cache. In October's trust model the Publisher and Developer backend roles that can author templates are already trusted with template code execution, so this is a defense-in-depth hardening rather than an unauthenticated network-to-RCE path. ### Impact - On installations where a template author has piped untrusted input into `|resize` without validation, a `phar://` source could reach the resizer and trigger metadata deserialization - No exposure on default templates or on installations where `|resize` is only applied to trusted values (uploaded file models, theme assets, static URLs) - Hardening; not exploitable from the network without a pre-existing injection primitive on the calling code ### Patches The vulnerability has been patched in v4.3.5. ### Workarounds If upgrading immediately is not possible: - Audit template code and backend widget configuration for uses of the `|resize` filter (or direct `ResizeImages::resize()` calls) that accept untrusted string input, and validate the scheme is `http`/`https` before passing it in ### References - Reported by 0xGenesi