Search for packages
| purl | pkg:composer/typo3/cms@11.3.3 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-1fhb-2xe6-j7ag
Aliases: CVE-2022-36108 GHSA-fv2m-9249-qx85 |
TYPO3 CMS vulnerable to Cross-Site Scripting in <f:asset.css> view helper > ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (4.1) ### Problem It has been discovered that the `f:asset.css` view helper is vulnerable to cross-site scripting when user input is passed as variables to the CSS. ### Solution Update to TYPO3 version 10.4.32 or 11.5.16 that fix the problem described above. ### Credits Thanks to TYPO3 contributor member Frank Nägler who reported this issue and to TYPO3 core & security team member Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2022-010](https://typo3.org/security/advisory/typo3-core-sa-2022-010) |
Affected by 7 other vulnerabilities. |
|
VCID-2cs4-v238-qydz
Aliases: CVE-2022-31049 GHSA-h4mx-xv96-2jgm |
Cross-Site Scripting in TYPO3's Frontend Login Mailer > ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (4.9) ### Problem User submitted content was used without being properly encoded in HTML emails sent to users. The actually affected components were mail clients used to view those messages. ### Solution Update to TYPO3 versions 9.5.35 ELTS, 10.4.29, 11.5.11 that fix the problem described above. ### Credits Thanks to Christian Seifert who reported this issue and to TYPO3 framework merger Andreas Fernandez who fixed the issue. ### References * [TYPO3-CORE-SA-2022-004](https://typo3.org/security/advisory/typo3-core-sa-2022-004) |
Affected by 13 other vulnerabilities. |
|
VCID-3mg6-tjfx-fbe5
Aliases: CVE-2022-36106 GHSA-5959-4x58-r8c2 |
TYPO3 CMS missing check for expiration time of password reset token for backend users > ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N/E:F/RL:O/RC:C` (5.0) ### Problem It has been discovered that the expiration time of a password reset link for TYPO3 backend users has never been evaluated. As a result, a password reset link could be used to perform a password reset even if the default expiry time of two hours has been exceeded. ### Solution Update to TYPO3 version 10.4.32 or 11.5.16 that fix the problem described above. ### Credits Thanks to Ingo Fabbri who reported this issue and to TYPO3 security team member Torben Hansen who fixed the issue. ### References * [TYPO3-CORE-SA-2022-008](https://typo3.org/security/advisory/typo3-core-sa-2022-008) |
Affected by 7 other vulnerabilities. |
|
VCID-9vzf-4j4j-gyex
Aliases: CVE-2022-36020 GHSA-47m6-46mj-p235 |
TYPO3 HTML Sanitizer Bypasses Cross-Site Scripting Protection > ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (5.7) ### Problem Due to a parsing issue in upstream package [`masterminds/html5`](https://packagist.org/packages/masterminds/html5), malicious markup used in a sequence with special HTML comments cannot be filtered and sanitized. This allows to by-pass the cross-site scripting mechanism of `typo3/html-sanitizer`. ### Solution Update to `typo3/html-sanitizer` versions 1.0.7 or 2.0.16 that fix the problem described. ### Credits Thanks to David Klein who reported this issue, and to TYPO3 security team member Oliver Hader who fixed the issue. |
Affected by 7 other vulnerabilities. |
|
VCID-c4su-ykce-xkh3
Aliases: CVE-2022-23499 GHSA-hvwx-qh2h-xcfj |
TYPO3 HTML Sanitizer vulnerable to Cross-Site Scripting ### Problem Due to a parsing issue in the upstream package [`masterminds/html5`](https://packagist.org/packages/masterminds/html5), malicious markup used in a sequence with special HTML CDATA sections cannot be filtered and sanitized. This allows bypassing the cross-site scripting mechanism of [`typo3/html-sanitizer`](https://packagist.org/packages/typo3/html-sanitizer). Besides that, the upstream package `masterminds/html5` provides HTML raw text elements (`script`, `style`, `noframes`, `noembed` and `iframe`) as DOMText nodes, which were not processed and sanitized further. None of the mentioned elements were defined in the default builder configuration, that's why only custom behaviors, using one of those tag names, were vulnerable to cross-site scripting. ### Solution Update to `typo3/html-sanitizer` versions 1.5.0 or 2.1.1 that fix the problem described. |
Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-fbxf-4gpp-4ff9
Aliases: CVE-2022-31048 GHSA-3r95-23jp-mhvg |
Cross-Site Scripting in TYPO3's Form Framework > ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (4.9) ### Problem It has been discovered that the Form Designer backend module of the Form Framework is vulnerable to cross-site scripting. A valid backend user account with access to the form module is needed to exploit this vulnerability. ### Solution Update to TYPO3 versions 8.7.47 ELTS, 9.5.35 ELTS, 10.4.29, 11.5.11 that fix the problem described above. ### Credits Thanks to Gabe Troyan who reported and fixed the issue. ### References * [TYPO3-CORE-SA-2022-003](https://typo3.org/security/advisory/typo3-core-sa-2022-003) |
Affected by 13 other vulnerabilities. |
|
VCID-hn17-q49v-qffj
Aliases: CVE-2021-41114 GHSA-m2jh-fxw4-gphm |
HTTP Host Header Injection ### Meta * CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N/E:F/RL:O/RC:C` (3.5) ### Problem It has been discovered that TYPO3 CMS is susceptible to host spoofing due to improper validation of the HTTP _Host_ header. TYPO3 uses the HTTP _Host_ header, for example, to generate absolute URLs during the frontend rendering process. 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. This vulnerability is the same as described in [TYPO3-CORE-SA-2014-001 (CVE-2014-3941)](https://typo3.org/security/advisory/typo3-core-sa-2014-001/). A regression, introduced during TYPO3 v11 development, led to this situation. The already existing setting _$GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern']_ (used as an effective mitigation strategy in previous TYPO3 versions) was not evaluated anymore, and reintroduced the vulnerability. ### Solution Update your instance to TYPO3 version 11.5.0 which addresses the problem described. ### Credits Thanks to TYPO3 framework merger Benjamin Franzke who reported and fixed the issue. ### References * [TYPO3-CORE-SA-2021-015](https://typo3.org/security/advisory/typo3-core-sa-2021-015) * [CVE-2014-3941](https://nvd.nist.gov/vuln/detail/CVE-2014-3941) reintroduced in TYPO3 v11.0.0 |
Affected by 18 other vulnerabilities. |
|
VCID-kh9n-kuvd-pbat
Aliases: CVE-2022-23501 GHSA-jfp7-79g7-89rf |
TYPO3 CMS vulnerable to Weak Authentication in Frontend Login ### Problem Restricting frontend login to specific users, organized in different storage folders (partitions), can be bypassed. A potential attacker might use this ambiguity in usernames to get access to a different account - however, credentials must be known to the adversary. ### Solution Update to TYPO3 versions 8.7.49 ELTS, 9.5.38 ELTS, 10.4.33, 11.5.20, 12.1.1 that fix the problem described above. ### References * [TYPO3-CORE-SA-2022-013](https://typo3.org/security/advisory/typo3-core-sa-2022-013) |
Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-m3w6-67ux-h7d6
Aliases: CVE-2021-41113 GHSA-657m-v5vm-f6rw |
Cross-Site-Request-Forgery in Backend > ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H/E:F/RL:O/RC:C` (8.2) ### Problem It has been discovered that the new TYPO3 v11 feature that allows users to create and share [deep links in the backend user interface](https://typo3.org/article/typo3-version-112-escape-the-orbit#c12178) is vulnerable to cross-site-request-forgery. The impact is the same as described in [TYPO3-CORE-SA-2020-006 (CVE-2020-11069)](https://typo3.org/security/advisory/typo3-core-sa-2020-006). However, it is not limited to the same site context and does not require the attacker to be authenticated. In a worst case scenario, the attacker could create a new admin user account to compromise the system. To successfully carry out an attack, an attacker must trick his victim to access a compromised system. The victim must have an active session in the TYPO3 backend at that time. The following [Same-Site cookie settings](https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/8.7.x/Feature-90351-ConfigureTYPO3-shippedCookiesWithSameSiteFlag.html) in _$GLOBALS[TYPO3_CONF_VARS][BE][cookieSameSite]_ are required for an attack to be successful: * _SameSite=_***strict***: malicious evil.**example.org** invoking TYPO3 application at good.**example.org** * _SameSite=_***lax*** or ***none***: malicious **evil.com** invoking TYPO3 application at **example.org** ### Solution Update your instance to TYPO3 version 11.5.0 which addresses the problem described. ### Credits Thanks to Richie Lee who reported this issue and to TYPO3 core & security team members Benni Mack and Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2021-014](https://typo3.org/security/advisory/typo3-core-sa-2021-014) * [CVE-2020-11069](https://nvd.nist.gov/vuln/detail/CVE-2020-11069) reintroduced in TYPO3 v11.2.0 |
Affected by 18 other vulnerabilities. |
|
VCID-pn6v-bye1-33fu
Aliases: CVE-2022-23500 GHSA-8c28-5mp7-v24h |
TYPO3 CMS vulnerable to Denial of Service in Page Error Handling ### Problem Requesting invalid or non-existing resources via HTTP triggers the page error handler, which again could retrieve content to be shown as an error message from another page. This leads to a scenario in which the application is calling itself recursively - amplifying the impact of the initial attack until the limits of the web server are exceeded. This vulnerability is very similar, but not identical, to the one described in [TYPO3-CORE-SA-2021-005](https://typo3.org/security/advisory/typo3-core-sa-2021-005) (CVE-2021-21359). ### Solution Update to TYPO3 versions 9.5.38 ELTS, 10.4.33 or 11.5.20 that fix the problem described above. ### References * [TYPO3-CORE-SA-2022-012](https://typo3.org/security/advisory/typo3-core-sa-2022-012) |
Affected by 1 other vulnerability. |
|
VCID-q2ch-qd6x-vqeu
Aliases: CVE-2022-31047 GHSA-fh99-4pgr-8j99 |
Insertion of Sensitive Information into Log File in typo3/cms-core > ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N/E:F/RL:O/RC:C` (4.9) ### Problem It has been discovered that system internal credentials or keys (e.g. database credentials) have been logged as plaintext in exception handlers, when logging the complete exception stack trace. ### Solution Update to TYPO3 versions 7.6.57 ELTS, 8.7.47 ELTS, 9.5.35 ELTS, 10.4.29, 11.5.11 that fix the problem described above. ### Credits Thanks to Marco Huber who reported this issue and to TYPO3 security member Torben Hansen who fixed the issue. ### References * [TYPO3-CORE-SA-2022-002](https://typo3.org/security/advisory/typo3-core-sa-2022-002) |
Affected by 13 other vulnerabilities. |
|
VCID-swwb-fm9u-tucv
Aliases: CVE-2023-24814 GHSA-r4f8-f93x-5qh3 |
TYPO3 is vulnerable to Cross-Site Scripting via frontend rendering > ### CVSS: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:H/A:L/E:F/RL:O/RC:C` (8.2) ### Problem TYPO3 core component `GeneralUtility::getIndpEnv()` uses the unfiltered server environment variable `PATH_INFO`, which allows attackers to inject malicious content. In combination with the TypoScript setting [`config.absRefPrefix=auto`](https://github.com/TYPO3/typo3/blob/v11.5.22/typo3/sysext/frontend/Classes/Controller/TypoScriptFrontendController.php#L2547-L2549), attackers can inject malicious HTML code into pages that have not yet been rendered and cached. As a result, injected values would be cached and delivered to other website visitors (persisted cross-site scripting). Individual code which relies on the resolved value of [`GeneralUtility::getIndpEnv('SCRIPT_NAME')`](https://github.com/TYPO3/typo3/blob/v11.5.22/typo3/sysext/core/Classes/Utility/GeneralUtility.php#L2481-L2484) and corresponding usages (as shown below) are vulnerable as well. - `GeneralUtility::getIndpEnv('PATH_INFO') ` - `GeneralUtility::getIndpEnv('SCRIPT_NAME') ` - `GeneralUtility::getIndpEnv('TYPO3_REQUEST_DIR')` - `GeneralUtility::getIndpEnv('TYPO3_REQUEST_SCRIPT')` - `GeneralUtility::getIndpEnv('TYPO3_SITE_PATH')` - `GeneralUtility::getIndpEnv('TYPO3_SITE_SCRIPT')` - `GeneralUtility::getIndpEnv('TYPO3_SITE_URL')` Installations of TYPO3 versions 8.7 and 9.x are probably only affected when server environment variable [`TYPO3_PATH_ROOT`](https://docs.typo3.org/m/typo3/reference-coreapi/9.5/en-us/ApiOverview/Environment/Index.html#configuring-environment-paths) is defined - which is the case if they were installed via Composer. Additional investigations confirmed that Apache and Microsoft IIS web servers using PHP-CGI (FPM, FCGI/FastCGI, or similar) are affected. There might be the risk that nginx is vulnerable as well. It was not possible to exploit Apache/mod_php scenarios. ### Solution The usage of server environment variable `PATH_INFO` has been removed from corresponding processings in `GeneralUtility::getIndpEnv()`. Besides that, the public property `TypoScriptFrontendController::$absRefPrefix` is encoded for both being used as a URI component and for being used as a prefix in an HTML context. This mitigates the cross-site scripting vulnerability. Update to TYPO3 versions 8.7.51 ELTS, 9.5.40 ELTS, 10.4.36 LTS, 11.5.23 LTS and 12.2.0 that fix the problem described above. > ℹ️ **Strong security defaults - Manual actions required** > Any web server using PHP-CGI (FPM, FCGI/FastCGI, or similar) needs to ensure that the PHP setting [**`cgi.fix_pathinfo=1`**](https://www.php.net/manual/en/ini.core.php#ini.cgi.fix-pathinfo) is used, which is the default PHP setting. In case this setting is not enabled, an exception is thrown to avoid continuing with invalid path information. For websites that cannot be patched timely the TypoScript setting [`config.absRefPrefix`](https://docs.typo3.org/m/typo3/reference-typoscript/main/en-us/Setup/Config/Index.html#absrefprefix) at least should be set to a static path value, instead of using `auto` - e.g. `config.absRefPrefix=/` - this **does not fix all aspects of the vulnerability**, and is just considered to be an intermediate mitigation to the most prominent manifestation. ### References * [TYPO3-CORE-SA-2023-001](https://typo3.org/security/advisory/typo3-core-sa-2023-001) * [TYPO3-CORE-PSA-2023-001](https://typo3.org/security/advisory/typo3-psa-2023-001) *pre-announcement* |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-twj9-9jqv-vkcx
Aliases: CVE-2022-23502 GHSA-mgj2-q8wp-29rr |
TYPO3 CMS vulnerable to Insufficient Session Expiration after Password Reset ### Problem When users reset their password using the corresponding password recovery functionality, existing sessions for that particular user account were not revoked. This applied to both frontend user sessions and backend user sessions. ### Solution Update to TYPO3 versions 10.4.33, 11.5.20, 12.1.1 that fix the problem described above. ### References * [TYPO3-CORE-SA-2022-014](https://typo3.org/security/advisory/typo3-core-sa-2022-014) |
Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-u89a-9jv7-bkhu
Aliases: CVE-2022-31050 GHSA-wwjw-r3gj-39fq |
Insufficient Session Expiration in TYPO3's Admin Tool > ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L/E:F/RL:O/RC:C` (5.6) ### Problem Admin Tool sessions initiated via the TYPO3 backend user interface have not been revoked even if the corresponding user account was degraded to lower permissions or disabled completely. This way, sessions in the admin tool theoretically could have been prolonged without any limit. ### Solution Update to TYPO3 versions 9.5.35 ELTS, 10.4.29, 11.5.11 that fix the problem described above. ### Credits Thanks to Kien Hoang who reported this issue and to TYPO3 framework merger Ralf Zimmermann and TYPO3 security member Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2022-005](https://typo3.org/security/advisory/typo3-core-sa-2022-005) |
Affected by 13 other vulnerabilities. |
|
VCID-u8we-bkyu-83b8
Aliases: CVE-2022-23503 GHSA-c5wx-6c2c-f7rm |
TYPO3 CMS vulnerable to Arbitrary Code Execution via Form Framework ### Problem Due to the lack of separating user-submitted data from the internal configuration in the Form Designer backend module, it was possible to inject code instructions to be processed and executed via TypoScript as PHP code. The existence of individual TypoScript instructions for a particular form item (known as [`formDefinitionOverrides`](https://docs.typo3.org/c/typo3/cms-form/main/en-us/I/Concepts/FrontendRendering/Index.html#form-element-properties)) and a valid backend user account with access to the form module are needed to exploit this vulnerability. ### Solution Update to TYPO3 versions 8.7.49 ELTS, 9.5.38 ELTS, 10.4.33, 11.5.20, 12.1.1 that fix the problem described above. ### References * [TYPO3-CORE-SA-2022-015](https://typo3.org/security/advisory/typo3-core-sa-2022-015) |
Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-vecz-7yug-dbcx
Aliases: CVE-2022-23504 GHSA-8w3p-qh3x-6gjr |
TYPO3 CMS vulnerable to Sensitive Information Disclosure via YAML Placeholder Expressions in Site Configuration > ### CVSS: `CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:L/A:L/E:F/RL:O/RC:C` (5.3) ### Problem Due to the lack of handling user-submitted [YAML placeholder expressions](https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/Configuration/Yaml/YamlApi.html#custom-placeholder-processing) in the site configuration backend module, attackers could expose sensitive internal information, such as system configuration or HTTP request messages of other website visitors. A valid backend user account having administrator privileges is needed to exploit this vulnerability. ### Solution Update to TYPO3 versions 9.5.38 ELTS, 10.4.33, 11.5.20, 12.1.1 that fix the problem described above. ### Credits Thanks to TYPO3 core & security team member Oliver Hader who reported and fixed the issue. ### References * [TYPO3-CORE-SA-2022-016](https://typo3.org/security/advisory/typo3-core-sa-2022-016) |
Affected by 1 other vulnerability. Affected by 1 other vulnerability. |
|
VCID-w2hv-ftte-fyd1
Aliases: CVE-2022-36107 GHSA-9c6w-55cp-5w25 |
TYPO3 CMS Stored Cross-Site Scripting via FileDumpController > ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (5.0) ### Problem It has been discovered that the `FileDumpController` (backend and frontend context) is vulnerable to cross-site scripting when malicious files are displayed using this component. A valid backend user account is needed to exploit this vulnerability. ### Solution Update to TYPO3 version 7.6.58 ELTS, 8.7.48 ELTS, 9.5.37 ELTS, 10.4.32 or 11.5.16 that fix the problem described above. ### Credits Thanks to Vautia who reported this issue and to TYPO3 core & security team member Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2022-009](https://typo3.org/security/advisory/typo3-core-sa-2022-009) * [Vulnerability Report on huntr.dev](https://huntr.dev/bounties/51e9b709-193c-41fd-bd4a-833aaca0bd4e/) (embargoed +30 days) |
Affected by 7 other vulnerabilities. |
|
VCID-xww9-ktn9-e3ga
Aliases: CVE-2022-36105 GHSA-m392-235j-9r7r |
TYPO3 CMS vulnerable to User Enumeration via Response Timing > ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (4.9) ### Problem It has been discovered that observing response time during user authentication (backend and frontend) can be used to distinguish between existing and non-existing user accounts. Extension authors of 3rd party TYPO3 extensions providing a custom authentication service should check if the extension is affected by the described problem. Affected extensions must implement new `MimicServiceInterface::mimicAuthUser`, which simulates corresponding times regular processing would usually take. ### Solution Update to TYPO3 version 7.6.58 ELTS, 8.7.48 ELTS, 9.5.37 ELTS, 10.4.32 or 11.5.16 that fix the problem described above. ### Credits Thanks to Vautia who reported this issue and to TYPO3 core & security team members Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2022-007](https://typo3.org/security/advisory/typo3-core-sa-2022-007) * [Vulnerability Report on huntr.dev](https://huntr.dev/bounties/7d519735-2877-4fad-bd77-accde3e290a7/) (embargoed +30 days) |
Affected by 7 other vulnerabilities. |
|
VCID-xxf2-6qn3-x7f8
Aliases: CVE-2022-31046 GHSA-8gmv-9hwg-w89g |
Information Disclosure via Export Module > ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (4.0) ### Problem The export functionality fails to limit the result set to allowed columns of a particular database table. This allows authenticated users to export internal details of database tables to which they already have access. ### Solution Update to TYPO3 versions 7.6.57 ELTS, 8.7.47 ELTS, 9.5.35 ELTS, 10.4.29, 11.5.11 that fix the problem described above. In order to address this issue, access to mentioned export functionality is completely denied for regular backend users. ℹ️ **Strong security defaults - Manual actions required** Following User TSconfig setting would allow using the export functionality for particular users: ``` options.impexp.enableExportForNonAdminUser = 1 ``` ### Credits Thanks to TYPO3 core merger Lina Wolf who reported this issue and to TYPO3 security member Torben Hansen who fixed the issue. ### References * [TYPO3-CORE-SA-2022-001](https://typo3.org/security/advisory/typo3-core-sa-2022-001) |
Affected by 13 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||