Unauthenticated local file inclusion in October CMS by octobercms

October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.421 and before version 1.0.469, an attacker can read local files on an October CMS server via a specially crafted request. Issue has been patched in Build 469 (v1.0.469) and v1.1.0.

• Vendor: octobercms.
• Product and package: October CMS, Composer package october/cms.
• Affected range: >= 1.0.421, < 1.0.469.
• The advisory identifies Build 469, also written as v1.0.469, as patched and states that the issue is also patched in v1.1.0.
• The status of parallel branches or other releases is not established by the available affected facts and must not be inferred as safe.

October CMS processes a specially crafted request in a way that allows an unauthenticated user to read local files on the server. The normalized record maps the issue to CWE-863, consistent with an authorization or path-validation failure in file handling. Patch evidence identifies related changes in FileDatasource and Halcyon Builder; file selection now calls validateFileName(...), and deletion also validates the file name. The exact endpoint, request parameter, and path-normalization behavior used by the vulnerable request are not disclosed in the available evidence. The specific files that can be read and the complete path scope therefore remain unknown.

The vulnerability is remotely reachable through a specially crafted request. The record and advisory state that authentication is not required and that no user interaction is required; exploitation complexity is characterized as low. The available evidence does not identify a specific endpoint or request parameter, so it does not support a safe description of an exploit sequence. Public exploitation or observed abuse is not established by the supplied record or the reviewed advisory; this is an evidence limitation, not a claim that exploitation has not occurred.

An attacker can read data from local files accessible to the October CMS process. The practical scope is likely constrained by the operating system permissions of the application account, but exposed configuration files or secrets could create secondary risk if disclosed. The record establishes information disclosure only; it does not establish data modification, code execution, or denial of service. Because authentication is not required, a publicly reachable instance may be probed and exploited without an application account.

The flaw can expose files readable by the October CMS web process. Depending on deployment permissions, those files could contain application source code, configuration data, connection details, or secrets used by other systems, although the record does not confirm which file types were exposed. The confirmed consequence is local file disclosure; the record does not establish file modification or service disruption. Internet-exposed October CMS instances and deployments containing sensitive configuration should receive priority review.

1. Upgrade the affected branch to Build 469, corresponding to v1.0.469. The advisory also identifies v1.1.0 as patched.
2. If an upgrade is not possible, manually apply the vendor-provided library patch to the installation. The vendor source provides the required code changes, but manual application should be tested before deployment.
3. After remediation, recheck the deployed october/cms package, effective version, and any local overrides or custom patches.
4. Do not rewrite the confirmed fixed releases as an open-ended statement covering every newer or parallel branch unless authoritative evidence confirms those branches.

1. Inventory October CMS deployments and identify the Composer package october/cms and its deployed version.
2. Flag systems in the >= 1.0.421, < 1.0.469 range for immediate remediation.
3. For systems that cannot be upgraded, verify whether the vendor's library patch has been applied manually.
4. Review October CMS access and application logs for unusual requests involving file-handling functionality. Treat this as precautionary monitoring because the available evidence provides no confirmed endpoint, request pattern, or IOC.
5. Do not treat the absence of suspicious log entries as proof that a system is safe.