October CMS: Incomplete Scheme Validation in Image Resizer

The image resizer can accept non-HTTP(S) PHP stream sources and pass them to the image library, potentially triggering metadata deserialisation. This requires existing template-authoring or backend-configuration functionality that passes untrusted input into |resize or ResizeImages::resize(). Default templates and uses limited to trusted values are not exposed; an unauthenticated visitor cannot exploit the resize route alone.

Check composer.lock for october/october at >= 4.3.0, < 4.3.4. If matched, inspect template code and backend widget configuration for |resize or direct ResizeImages::resize() calls that accept untrusted strings without scheme validation. Uses limited to uploaded file models, theme assets or trusted static URLs are not exposed. The advisory identifies 4.3.5 as the patched version.

Audit template code and backend widget configuration for |resize or direct ResizeImages::resize() calls that accept untrusted string input, and validate that the scheme is http or https before passing it in.

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