GHSA-2xmm-m4wv-3fjh: Input Validation

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