Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐘
🐘 Packagist
Not in CISA KEV
LOW severity

October CMS: Incomplete Scheme Validation in Image ResizerGHSA-2xmm-m4wv-3fjh

LOW

GHSA-2xmm-m4wv-3fjh is a low-severity (CVSS 3.9) Server-Side Request Forgery (SSRF) vulnerability in october/october. A fix is available for october/october — see the affected versions and patch details below.

Also known asCVE-2026-100909
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 26, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for GHSA-2xmm-m4wv-3fjh.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs22th percentile — riskier than 22% of all scored CVEsHighest risk
0.00%0.27%0.53%0.80%0.3%0.3%Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-2xmm-m4wv-3fjh by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 397,508 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐘october/october

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

Description

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

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistoctober/october≥ 4.3.0&&< 4.3.54.3.5composer require october/october:^4.3.5

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for october/october, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update october/october to 4.3.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2xmm-m4wv-3fjh is resolved across your whole dependency graph.

  3. Workarounds

    Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.

Frequently Asked Questions

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
O3 Security · Impact-Aware SCA

Is GHSA-2xmm-m4wv-3fjh in your dependencies?

Find it across Packagist, including transitive dependencies.

Scan my dependencies How O3 SCA works
October CMS: Incomplete Scheme Validation in Image…