A stored cross-site scripting (XSS) vulnerability in October CMS Bloghub Plugin v1.3.8 and lower allows attackers to execute arbitrary web scripts or HTML via a crafted payload into the Comments section.
Impact
This advisory affects authenticated administrators who may be redirected to an untrusted URL using the PageFinder schema. The resolver for the page finder link schema (october://) allowed external links, therefore allowing an open redirect outside the scope of the active host.
This vulnerability assumes a trusted user will attack another trusted user and cannot be actively exploited without access to the administration panel and interaction from the other user.
Patches
This issue has been patched in v3.5.15.
References
Credits to: - Benzetaa
For more information If you have any questions or comments about this advisory: Email us at hello@octobercms.com
Cross Site Scripting vulnerability found in October CMS v.3.2.0 allows local attacker to execute arbitrary code via the file type .mp3
Impact
An authenticated backend user with the editor.cmspages, editor.cmslayouts, or editor.cmspartials permissions who would normally not be permitted to provide PHP code to be executed by the CMS due to cms.safemode being enabled can write specific Twig code to escape the Twig sandbox and execute arbitrary PHP.
This is not a problem for anyone who trusts their users with those permissions to usually write and manage PHP within the CMS by not having cms.safemode enabled. Still, it would be a problem for anyone relying on cms.safemode to ensure that users with those permissions in production do not have access to write and execute arbitrary PHP.
Patches
This issue has been patched in v3.4.15.
Workarounds
As a workaround, remove the specified permissions from untrusted users.
References
Credits to: - Vasiliy Bodrov
For more information If you have any questions or comments about this advisory: Email us at hello@octobercms.com
Impact
An authenticated backend user with the editor.cmspages, editor.cmslayouts, or editor.cmspartials permissions who would normally not be permitted to provide PHP code to be executed by the CMS due to cms.safemode being enabled can craft a special request to include PHP code in the CMS template.
This is not a problem for anyone who trusts their users with those permissions to usually write & manage PHP within the CMS by not having cms.safemode enabled. Still, it would be a problem for anyone relying on cms.safemode to ensure that users with those permissions in production do not have access to write and execute arbitrary PHP.
Patches
This issue has been patched in v3.4.15.
Workarounds
As a workaround, remove the specified permissions from untrusted users.
References
Credits to: - Vasiliy Bodrov
For more information If you have any questions or comments about this advisory: Email us at hello@octobercms.com
Impact
A user with access to the media manager that stores SVG files could create a stored XSS attack against themselves and any other user with access to the media manager when SVG files are supported.
SVG files are supported by default in v3 for convenience; however, this has resulted in multiple mistaken vulnerability reports from security researchers. As per the documentation, if a backend user is not trusted, the advice is to remove the svg extension from the list of supported file types.
Patches
The issue has been patched in v3.5.2 by including an SVG sanister. It is enabled by default for new installations but must be enabled for existing sites in the config/media.php file.
'cleanvectors' => true,
Workarounds
If you cannot upgrade for this patch, follow the pervious advice and remove svg from the supported file types.
References
- https://github.com/octobercms/october/blob/3.x/config/media.php
Credits to: - Faris Krivic - Okan Kurtulus - Aldin Visnjic - Bug Shankar
For more information If you have any questions or comments about this advisory: Email us at hello@octobercms.com
Withdrawn Advisory This advisory has been withdrawn because the vulnerability affects October CMS's installer, not October CMS. The installer deletes all folders and files upon completion of installation. The vulnerability is valid, but because October's installer is not part of one of the GitHub Advisory Database's supported ecosystems, alerts cannot be sent out for the correct package.
Corrected Description A Cross-Site Scripting (XSS) vulnerability in the installer of October CMS allows an attacker to execute arbitrary web scripts via a crafted payload injected into the dbhost field.
An arbitrary file upload vulnerability in October CMS v3.4.4 allows attackers to execute arbitrary code via a crafted file.
October is a self-hosted Content Management System (CMS) platform based on the Laravel PHP Framework. This vulnerability only affects installations that rely on the safe mode restriction, commonly used when providing public access to the admin panel. Assuming an attacker has access to the admin panel and permission to open the "Editor" section, they can bypass the Safe Mode (cms.safemode) restriction to introduce new PHP code in a CMS template using a specially crafted request. The issue has been patched in versions 2.2.34 and 3.0.66.
October/System is the system module for October CMS, a self-hosted CMS platform based on the Laravel PHP Framework. Prior to versions 1.0.476, 1.1.12, and 2.2.15, when the developer allows the user to specify their own filename in the fromData method, an unauthenticated user can perform remote code execution (RCE) by exploiting a race condition in the temporary storage directory. This vulnerability affects plugins that expose the October\Rain\Database\Attach\File::fromData as a public interface and does not affect vanilla installations of October CMS since this method is not exposed or used by the system internally or externally. The issue has been patched in Build 476 (v1.0.476), v1.1.12, and v2.2.15. Those who are unable to upgrade may apply with patch to their installation manually as a workaround.
Octobercms is a self-hosted CMS platform based on the Laravel PHP Framework. Affected versions of OctoberCMS did not validate gateway server signatures. As a result non-authoritative gateway servers may be used to exfiltrate user private keys. Users are advised to upgrade their installations to build 474 or v1.1.10. The only known workaround is to manually apply the patch (e3b455ad587282f0fbcb7763c6d9c3d000ca1e6a) which adds server signature validation.
Octobercms is a self-hosted CMS platform based on the Laravel PHP Framework. In affected versions user input was not properly sanitized before rendering. An authenticated user with the permissions to create, modify and delete website pages can exploit this vulnerability to bypass cms.safemode / cms.enableSafeMode in order to execute arbitrary code. This issue only affects admin panels that rely on safe mode and restricted permissions. To exploit this vulnerability, an attacker must first have access to the backend area. The issue has been patched in Build 474 (v1.0.474) and v1.1.10. Users unable to upgrade should apply https://github.com/octobercms/library/commit/c393c5ce9ca2c5acc3ed6c9bb0dab5ffd61965fe to your installation manually.
October CMS is a self-hosted content management system (CMS) platform based on the Laravel PHP Framework. Prior to versions 1.0.473 and 1.1.6, an attacker with "create, modify and delete website pages" privileges in the backend is able to execute PHP code by running specially crafted Twig code in the template markup. The issue has been patched in Build 473 (v1.0.473) and v1.1.6. Those unable to upgrade may apply the patch to their installation manually as a workaround.
October CMS is a self-hosted content management system (CMS) platform based on the Laravel PHP Framework. Prior to versions 1.0.473 and 1.1.6, an attacker with access to the backend is able to execute PHP code by using the theme import feature. This will bypass the safe mode feature that prevents PHP execution in the CMS templates.The issue has been patched in Build 473 (v1.0.473) and v1.1.6. Those unable to upgrade may apply the patch to their installation manually as a workaround.
October is a Content Management System (CMS) and web platform built on the the Laravel PHP Framework. In affected versions administrator accounts which had previously been deleted may still be able to sign in to the backend using October CMS v2.0. The issue has been patched in v2.1.12 of the october/october package. There are no workarounds for this issue and all users should update.
octobercms in a CMS platform based on the Laravel PHP Framework. In affected versions of the october/system package an attacker can exploit this vulnerability to bypass authentication and takeover of and user account on an October CMS server. The vulnerability is exploitable by unauthenticated users via a specially crafted request. This only affects frontend users and the attacker must obtain a Laravel secret key for cookie encryption and signing in order to exploit this vulnerability. The issue has been patched in Build 472 and v1.1.5.
October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. A bypass of CVE-2020-26231 (fixed in 1.0.470/471 and 1.1.1) was discovered that has the same impact as CVE-2020-26231 & CVE-2020-15247. An authenticated backend user with the cms.managepages, cms.managelayouts, or cms.managepartials permissions who would normally not be permitted to provide PHP code to be executed by the CMS due to cms.enableSafeMode being enabled is able to write specific Twig code to escape the Twig sandbox and execute arbitrary PHP. This is not a problem for anyone that trusts their users with those permissions to normally write & manage PHP within the CMS by not having cms.enableSafeMode enabled, but would be a problem for anyone relying on cms.enableSafeMode to ensure that users with those permissions in production do not have access to write & execute arbitrary PHP. Issue has been patched in Build 472 (v1.0.472) and v1.1.2. As a workaround, apply https://github.com/octobercms/october/commit/f63519ff1e8d375df30deba63156a2fc97aa9ee7 to your installation manually if unable to upgrade to Build 472 or v1.1.2.
Impact When running on servers that are configured to accept a wildcard as a hostname (i.e. the server routes any request, regardless of the HOST header to an October CMS instance) the potential exists for Host Header Poisoning attacks to succeed. See the following resources for more information on Host Header Poisoning: - https://portswigger.net/web-security/host-header - https://dzone.com/articles/what-is-a-host-header-attack
Patches
A feature has been added in v1.1.2 to allow a set of trusted hosts to be specified in the application.
Workarounds
- Apply https://github.com/octobercms/library/commit/f86fcbcd066d6f8b939e8fe897409d152b11c3c6 & https://github.com/octobercms/october/commit/f638d3f78cfe91d7f6658820f9d5e424306a3db0 to your installation manually if unable to upgrade to v1.1.2.
- Check that the configuration setting cms.linkPolicy is set to force.
Alternative Workaround
Check to make sure that your web server does not accept any hostname when serving your web application.
1. Add an entry called testing.tld to your computer's host file and direct it to your server's IP address 2. Open the address testing.tld in your web browser 3. Make sure an October CMS website is not available at this address
If an October CMS website is returned, configure your webserver to only allow known hostnames. If you require assistance with this, please contact your server administrator.
References
Reported by Abdullah Hussam
For More Information
If you have any questions or comments about this advisory: Email us at hello@octobercms.com
Threat Assessment <img width="1108" alt="Screen Shot 2021-01-15 at 4 12 57 PM" src="https://user-images.githubusercontent.com/7253840/104783859-92fb3600-574c-11eb-9e21-c0dc05d230a9.png">
Impact When logging out, the session ID was not invalidated. This is not a problem while the user is logged out, but as soon as the user logs back in the old session ID would be valid again; which means that anyone that gained access to the old session cookie would be able to act as the logged in user. This is not a major concern for the majority of cases, since it requires a malicious party gaining access to the session cookie in the first place, but nevertheless has been fixed.
Patches Issue has been patched in Build 472 (v1.0.472) and v1.1.2.
Workarounds Apply https://github.com/octobercms/library/commit/642f597489e6f644d4bd9a0c267e864cabead024 to your installation manually if unable to upgrade to Build 472 or v1.1.2.
References - Reported by Anisio (Brazilian Information Security Analyst) - http://cve.circl.lu/cve/CVE-2021-3311
For more information If you have any questions or comments about this advisory: Email us at hello@octobercms.com
Threat assessment: <img width="699" alt="Screen Shot 2021-02-07 at 11 50 35 PM" src="https://user-images.githubusercontent.com/7253840/107180881-51eaf000-699f-11eb-8828-333128faf2a6.png">
October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. A bypass of CVE-2020-15247 (fixed in 1.0.469 and 1.1.0) was discovered that has the same impact as CVE-2020-15247. An authenticated backend user with the cms.managepages, cms.managelayouts, or cms.managepartials permissions who would normally not be permitted to provide PHP code to be executed by the CMS due to cms.enableSafeMode being enabled is able to write specific Twig code to escape the Twig sandbox and execute arbitrary PHP. This is not a problem for anyone that trusts their users with those permissions to normally write & manage PHP within the CMS by not having cms.enableSafeMode enabled, but would be a problem for anyone relying on cms.enableSafeMode to ensure that users with those permissions in production do not have access to write & execute arbitrary PHP. Issue has been patched in Build 470 (v1.0.470) and v1.1.1.
October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.319 and before version 1.0.469, backend users with access to upload files were permitted to upload SVG files without any sanitization applied to the uploaded files. Since SVG files support being parsed as HTML by browsers, this means that they could theoretically upload Javascript that would be executed on a path under the website's domain (i.e. /storage/app/media/evil.svg), but they would have to convince their target to visit that location directly in the target's browser as the backend does not display SVGs inline anywhere, SVGs are only displayed as image resources in the backend and are thus unable to be executed. Issue has been patched in Build 469 (v1.0.469) & v1.1.0.
October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.319 and before version 1.0.470, backend users with the default "Publisher" system role have access to create & manage users where they can choose which role the new user has. This means that a user with "Publisher" access has the ability to escalate their access to "Developer" access. Issue has been patched in Build 470 (v1.0.470) & v1.1.1.
October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.319 and before version 1.0.469, an authenticated backend user with the cms.managepages, cms.managelayouts, or cms.managepartials permissions who would normally not be permitted to provide PHP code to be executed by the CMS due to cms.enableSafeMode being enabled is able to write specific Twig code to escape the Twig sandbox and execute arbitrary PHP. This is not a problem for anyone that trusts their users with those permissions to normally write & manage PHP within the CMS by not having cms.enableSafeMode enabled, but would be a problem for anyone relying on cms.enableSafeMode to ensure that users with those permissions in production do not have access to write & execute arbitrary PHP. Issue has been patched in Build 469 (v1.0.469) and v1.1.0.
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.
In OctoberCMS before version 1.0.468, encrypted cookie values were not tied to the name of the cookie the value belonged to. This meant that certain classes of attacks that took advantage of other theoretical vulnerabilities in user facing code (nothing exploitable in the core project itself) had a higher chance of succeeding. Specifically, if your usage exposed a way for users to provide unfiltered user input and have it returned to them as an encrypted cookie (ex. storing a user provided search query in a cookie) they could then use the generated cookie in place of other more tightly controlled cookies; or if your usage exposed the plaintext version of an encrypted cookie at any point to the user they could theoretically provide encrypted content from your application back to it as an encrypted cookie and force the framework to decrypt it for them. Issue has been fixed in build 468 (v1.0.468).
In October from version 1.0.319 and before version 1.0.466, a user with access to a markdown FormWidget that stores data persistently could create a stored XSS attack against themselves and any other users with access to the generated HTML from the field. This has been fixed in 1.0.466. For users of the RainLab.Blog plugin, this has also been fixed in 1.4.1.
In October from version 1.0.319 and before version 1.0.467, pasting content copied from malicious websites into the Froala richeditor could result in a successful self-XSS attack. This has been fixed in 1.0.467.
The October CMS debugbar plugin before version 3.1.0 contains a feature where it will log all requests (and all information pertaining to each request including session data) whenever it is enabled. This presents a problem if the plugin is ever enabled on a system that is open to untrusted users as the potential exists for them to use this feature to view all requests being made to the application and obtain sensitive information from those requests. There even exists the potential for account takeovers of authenticated users by non-authenticated public users, which would then lead to a number of other potential issues as an attacker could theoretically get full access to the system if the required conditions existed. Issue has been patched in v3.1.0 by locking down access to the debugbar to all users; it now requires an authenticated backend user with a specifically enabled permission before it is even usable, and the feature that allows access to stored request information is restricted behind a different permission that's more restrictive.
In OctoberCMS (october/october composer package) versions from 1.0.319 and before 1.0.466, any users with the ability to modify any data that could eventually be exported as a CSV file from the ImportExportController could potentially introduce a CSV injection into the data to cause the generated CSV export file to be malicious. This requires attackers to achieve the following before a successful attack can be completed: 1. Have found a vulnerability in the victims spreadsheet software of choice. 2. Control data that would potentially be exported through the ImportExportController by a theoretical victim. 3. Convince the victim to export above data as a CSV and run it in vulnerable spreadsheet software while also bypassing any sanity checks by said software. Issue has been patched in Build 466 (v1.0.466).
In OctoberCMS (october/october composer package) versions from 1.0.319 and before 1.0.466, an attacker can exploit this vulnerability to delete arbitrary local files of an October CMS server. The vulnerability is only exploitable by an authenticated backend user with the cms.manageassets permission. Issue has been patched in Build 466 (v1.0.466).