Summary
A server-side request forgery vulnerability in OctoberCMS affects image-resizing logic that processes the realSourcePath argument. A remote attacker may be able to influence the requested source location, causing the server to make requests to unintended internal or external resources.
Affected context
The vulnerability occurs in OctoberCMS versions where the getSourcePathForResize function in modules/system/classes/ResizeImages.php accepts an attacker-influenced realSourcePath. Deployments are at risk when this value can reach image-resizing functionality without sufficiently restricting the permitted schemes, hosts, ports, or network destinations.
Exploit preconditions
- Attack surface: Remotely reachable OctoberCMS image-resizing functionality
- Required access: The ability to submit or influence a request that controls, directly or indirectly, the
realSourcePathvalue - Trigger point: Processing of the source path by
getSourcePathForResize - Why exploitation is possible: The server may resolve or retrieve an attacker-selected resource without adequately constraining destinations
Why this happens
The underlying bug is insufficient validation and destination control for a server-side resource path used during image processing. When application-controlled network requests accept attacker-influenced locations without enforcing an allowlist or blocking unsafe destinations, the server can be induced to access resources on behalf of the requester. This behavior maps to CWE-918: Server-Side Request Forgery.
Potential impact
- An attacker may access services that are reachable from the OctoberCMS server but not from the public internet
- Sensitive internal endpoints or cloud metadata services could be exposed
- The server could send requests to unintended external systems
- Internal network reconnaissance may be possible
- Requests could consume server resources or interact with trusted network services
General mitigation guidance
Mitigation generally focuses on reducing trust in user-controlled resource locations and enforcing explicit network destination policies.
Common defensive patterns include:
- Restricting resource retrieval to approved schemes, hosts, ports, and paths
- Preferencing local, application-managed files over arbitrary network locations
- Blocking loopback, private, link-local, multicast, and metadata-service address ranges
- Resolving hostnames and validating the final destination before connecting
- Disabling redirects or validating every redirect target
- Applying network egress controls and least-privilege service permissions
- Separating image-processing workers from sensitive internal networks where practical
How teams detect issues like this
Organizations can detect SSRF risks through:
- Static analysis rules for HTTP clients or file-fetching APIs receiving request-derived values
- Code review checks for unrestricted URL, path, host, scheme, redirect, and DNS handling
- Tests covering loopback, private-network, link-local, metadata, alternate-encoding, and redirect destinations
- Web application firewall or gateway policies that flag suspicious resource URLs
- Network monitoring for unexpected outbound requests from application workers
- Automated security review tools that identify missing destination allowlists and weak URL validation
