Source
ghsa
Failing to properly validate the HTTP host-header TYPO3 CMS is susceptible to host spoofing. TYPO3 uses the HTTP host-header to generate absolute URLs in several places like 404 handling, http(s) enforcement, password reset links and many more. Since the host header itself is provided by the client it can be forged to any value, even in a name based virtual hosts environment. A blog post describes this problem in great detail.
Two Cross-Site Scripting vulnerabilities have been discovered in Alkacon's OpenCMS affecting version 16, which could allow a user: with sufficient privileges to create and modify web pages through the admin panel, can execute malicious JavaScript code, after inserting code in the `title` field. Another could having the roles of gallery editor or VFS resource manager will have the permission to upload images in the .svg format containing JavaScript code. The code will be executed the moment another user accesses the image.
The swiftmailer library in use allows to execute arbitrary shell commands if the "From" header comes from a non-trusted source and no "Return-Path" is configured. Affected are only TYPO3 installation the configuration option ``` $GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport'] ``` is set to "sendmail". Installations with the default configuration are not affected.
It has been discovered that request handling in Extbase can be vulnerable to insecure deserialization. User submitted payload has to be signed with a corresponding HMAC-SHA1 using the sensitive TYPO3 encryptionKey as secret - invalid or unsigned payload is not deserialized. However, since sensitive information could have been leaked by accident (e.g. in repositories or in commonly known and unprotected backup files), there is the possibility that attackers know the private encryptionKey and are able to calculate the required HMAC-SHA1 to allow a malicious payload to be deserialized. Requirements for successfully exploiting this vulnerability (all of the following): - rendering at least one Extbase plugin in the frontend - encryptionKey has been leaked (from LocalConfiguration.php or corresponding .env file)
It has been discovered that the output table listing in the “Files” backend module is vulnerable to cross-site scripting when a file extension contains malicious sequences. Access to the file system of the server - either directly or through synchronization - is required to exploit the vulnerability.
Versions of the package mysql2 before 3.9.8 are vulnerable to Prototype Pollution due to improper user input sanitization passed to fields and tables when using nestTables.
It has been discovered that t3:// URL handling and typolink functionality are vulnerable to cross-site scripting. Not only regular backend forms are affected but also frontend extensions which use the rendering with typolink.
It has been discovered that the output of field validation errors in the Form Framework is vulnerable to cross-site scripting.
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.
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...