#vulnerability

It has been discovered that Flow 3.0.0 allows arbitrary file uploads, inlcuding server-side scripts, posing the risk of attacks. If those scripts are executed by the server when accessed through their public URL, anything not blocked through other means is possible (information disclosure, placement of backdoors, data removal, …). Note: The upload of files is only possible if the application built on Flow provides means to do so, and whether or not the upload of files poses a risk is dependent on the system setup. If uploaded script files are not executed by the server, there is no risk. In versions prior to 3.0.0 the upload of files with the extension php was blocked. In Flow 2.3.0 to 2.3.6 a potential XML External Entity processing vulnerability has been discovered in the MediaTypeConverter.

TikTok accounts are being hacked! Celebrities and brands targeted in zero-click attack. Learn more about this major security…

Insecure deserialization is a vulnerability which occurs when untrusted data is used to abuse the logic of an application. In July 2018, the vulnerability of insecure deserialization when executing Phar archives was addressed by removing the known attack vector in the TYPO3 core. For more details read the corresponding TYPO3 advisory. In addition, a new interceptor was introduced to protect possible (but unknown) vulnerabilities in 3rd party components like TYPO3 extensions. Basically, the PharStreamWrapper intercepts direct invocations of Phar archives and allows or denies further processing based on individual rules. Recently, the PharStreamWrapper was extracted from the TYPO3 core and released as standalone package under the MIT license. It is now available for any PHP driven project. The stream wrapper overwrites the existing Phar handling of PHP, applies its own assertions and then restores the native PHP Phar handling for the corresponding commands (e.g. file_exists, include, ...

The PersistedUsernamePasswordProvider was prone to a information disclosure of account existance based on timing attacks as the hashing of passwords was only done in case an account was found. We changed the core so that the provider always does a password comparison in case credentials were submitted at all.

If you had used entity security and wanted to secure entities not just based on the user's role, but on some property of the user (like the company he belongs to), entity security did not work properly together with the doctrine query cache. This could lead to other users re-using SQL queries from the cache which were built for other users; and thus users could see entities which were not destined for them.

It has been discovered that Neos is vulnerable to several XSS attacks. Through these vulnerabilities, an attacker could tamper with page rendering, redirect victims to a fake login page, or capture user credentials (such as cookies). With the potential backdoor upload an attacker could gain access to the server itself, to an extent mainly limited by the server setup.

It has been discovered that the Import/Export module is susceptible to broken access control. Regular backend users have access to import functionality which usually only is available to admin users or users having User TSconfig setting options.impexp.enableImportForNonAdminUser explicitly enabled. Database content to be imported however was correctly checked against users’ permissions and not affected. However it was possible to upload files by-passing restrictions of the file abstraction layer (FAL) - however this did not affect executable files which have been correctly secured by fileDenyPattern. Currently the only known vulnerability is to directly inject *.form.yaml files which could be used to trigger the vulnerability of TYPO3-CORE-SA-2018-003 (privilege escalation & SQL injection) - which requires the Form Framework (ext:form) being available on an according website. CVSSv3 scoring is based on this scenario. A valid backend user account is needed in order to exploit this vu...

It has been discovered backend users not having read access to specific pages still could see them in the page tree which actually should be disallowed. A valid backend user account is needed in order to exploit this vulnerability.

Backend API configuration using Page TSconfig is vulnerable to arbitrary code execution and cross-site scripting. TSconfig fields of page properties in backend forms can be used to inject malicious sequences. Field tsconfig_includes is vulnerable to directory traversal leading to same scenarios as having direct access to TSconfig settings. A valid backend user account having access to modify values for fields pages.TSconfig and pages.tsconfig_includes is needed in order to exploit this vulnerability.

When users change their password existing sessions for that particular user account are not revoked. A valid backend or frontend user account is required in order to make use of this vulnerability.