ghsa

It has been discovered that cookies created in the Install Tool are not hardened to be submitted only via HTTP. In combination with other vulnerabilities such as cross-site scripting it can lead to hijacking an active and valid session in the Install Tool.

Failing to properly encode user input, login status display is vulnerable to cross-site scripting in the website frontend. A valid user account is needed in order to exploit this vulnerability - either a backend user or a frontend user having the possibility to modify their user profile. Template patterns that are affected are - ###FEUSER_[fieldName]### using system extension felogin - <!--###USERNAME###--> for regular frontend rendering (pattern can be defined individually using TypoScript setting config.USERNAME_substToken)

Failing to properly encode user input, notifications shown in modal windows in the TYPO3 backend are vulnerable to cross-site scripting. A valid backend user account is needed in order to exploit this vulnerability.

Failing to properly encode user input, online media asset rendering (`*.youtube` and `*.vimeo` files) is vulnerable to cross-site scripting. A valid backend user account or write access on the server system (e.g. SFTP) is needed in order to exploit this vulnerability.

### Summary If the preopened directory has a symlink pointing outside, WASI programs can traverse the symlink and access host filesystem if the caller sets both `oflags::creat` and `rights::fd_write`. Programs can also crash the runtime by creating a symlink pointing outside with `path_symlink` and `path_open`ing the link. ### Details ### PoC Setup a filesystem as follows. ``` . ├── outside.file └── preopen └── dir └── file -> ../../outside.file ``` Compile this Rust snippet with `wasi` v0.11 (for the preview1 API). ```rust fn main() { unsafe { let filefd = wasi::path_open( 5, wasi::LOOKUPFLAGS_SYMLINK_FOLLOW, "app/dir/file", wasi::OFLAGS_CREAT, wasi::RIGHTS_FD_READ | wasi::RIGHTS_FD_WRITE, 0, 0, ) .unwrap(); eprintln!("filefd: {filefd}"); let mut buf = [0u8; 10]; let iovs = [wasi::Iovec { buf: buf.as_mut_ptr(), ...

### Summary Regardless of the role or privileges, no user should be able to inject malicious JavaScript (JS) scripts into the body HTML. an XSS (Cross-Site Scripting) vulnerability, specifically a Stored XSS, which affects all pages of the website. Once the JS script is embedded in the body HTML, the XSS will trigger on any page a victim visits, such as the about, blog, contact, or any other pages, except for the panel. ### Impact This vulnerability allows attackers to inject malicious JS or HTML through a crafted payload into the vulnerable spot, achieving persistence and attacking numerous visitors or anyone accessing the website. The attack can be widespread and affect many users because the malicious JS will execute on every page, unlike an injection on a specific page (e.g., injecting on the About page would only affect that page). In this case, a single injection point leads to the execution of the malicious JS on all pages. ### Patches - [**Formwork 1.13.1**](https://github.co...

Due to missing file extensions in $GLOBALS['TYPO3_CONF_VARS']['BE'][‘fileDenyPattern’], backend users are allowed to upload *.phar, *.shtml, *.pl or *.cgi files which can be executed in certain web server setups. A valid backend user account is needed in order to exploit this vulnerability. Derivatives of Debian GNU Linux are handling *.phar files as PHP applications since PHP 7.1 (for unofficial packages) and PHP 7.2 (for official packages). The file extension *.shtml is bound to server side includes which are not enabled per default in most common Linux based distributions. File extension *.pl and *.cgi require additional handlers to be configured which is also not the case in most common distributions (except for /cgi-bin/ location).

TYPO3’s built-in record registration functionality (aka `basic shopping cart`) using recs URL parameters is vulnerable to denial of service. Failing to properly ensure that anonymous user sessions are valid, attackers can use this vulnerability in order to create an arbitrary amount of individual session-data records in the database.

It has been discovered that mechanisms used for configuration of RequireJS package loading are susceptible to information disclosure. This way a potential attack can retrieve additional information about installed system and third party extensions.

It has been discovered that the output of field validation errors in the Form Framework is vulnerable to cross-site scripting.