ghsa

### Summary BoringSSLAEADContext keeps track of how many OHTTP responses have been sent and uses this sequence number to calculate the appropriate nonce to use with the encryption algorithm. Unfortunately, two separate errors combine which would allow an attacker to cause the sequence number to overflow and thus the nonce to repeat. ### Details 1. There is no overflow detection or enforcement of the maximum sequence value. (This is a missed requirement from the draft Chunked Oblivious OHTTP RFC and so should be inherited from the HPKE RFC 9180, Section 5.2). 2. The sequence number (seq) is stored as 32-bit int which is relatively easy to overflow. https://github.com/netty/netty-incubator-codec-ohttp/blob/1ddadb6473cd3be5491d114431ed4c1a9f316001/codec-ohttp-hpke-classes-boringssl/src/main/java/io/netty/incubator/codec/hpke/boringssl/BoringSSLAEADContext.java#L112-L114 ### Impact If the BoringSSLAEADContext is used to encrypt more than 2^32 messages then the AES-GCM nonce will repeat...

It has been discovered that TYPO3’s Salted Password system extension (which is a mandatory system component) is vulnerable to Authentication Bypass when using hashing methods which are related by PHP class inheritance. In standard TYPO3 core distributions stored passwords using the blowfish hashing algorithm can be overridden when using MD5 as the default hashing algorithm by just knowing a valid username. Per default the Portable PHP hashing algorithm (PHPass) is used which is not vulnerable.

Failing to properly check user permission on file storages, editors could gain knowledge of protected storages and its folders as well as using them in a file collection being rendered in the frontend. A valid backend user account is needed to exploit this vulnerability.

Phar files (formerly known as "PHP archives") can act als self extracting archives which leads to the fact that source code is executed when Phar files are invoked. The Phar file format is not limited to be stored with a dedicated file extension - "bundle.phar" would be valid as well as "bundle.txt" would be. This way, Phar files can be obfuscated as image or text file which would not be denied from being uploaded and persisted to a TYPO3 installation. Due to a missing sanitization of user input, those Phar files can be invoked by manipulated URLs in TYPO3 backend forms. A valid backend user account is needed to exploit this vulnerability. In theory the attack vector would be possible in the TYPO3 frontend as well, however no functional exploit has been identified so far.

Versions of the package pymongo before 4.6.3 are vulnerable to Out-of-bounds Read in the bson module. Using the crafted payload the attacker could force the parser to deserialize unmanaged memory. The parser tries to interpret bytes next to buffer and throws an exception with string. If the following bytes are not printable UTF-8 the parser throws an exception with a single byte.

HTTP requests being performed using the TYPO3 API expose the specific TYPO3 version to the called endpoint.

Failing to properly dissociate system related configuration from user generated configuration, the Form Framework (system extension "form") is vulnerable to SQL injection and Privilege Escalation. Basically instructions can be persisted to a form definition file that were not configured to be modified - this applies to definitions managed using the form editor module as well as direct file upload using the regular file list module. A valid backend user account as well as having system extension form activated are needed in order to exploit this vulnerability.

TYPO3 uses the package swiftmailer/swiftmailer for mail actions. This package is known to be vulnerable to Remote Code Execution.

Due to a missing file extension in the fileDenyPattern, backend user are allowed to upload *.pht files which can be executed in certain web server setups. The new default fileDenyPattern is the following, which might have been overridden in the TYPO3 Install Tool. ``` \.(php[3-7]?|phpsh|phtml|pht)(\..*)?$|^\.htaccess$ ```

It has been discovered that the Form Framework (system extension "form") is vulnerable to Insecure Deserialization when being used with the additional PHP PECL package “yaml”, which is capable of unserializing YAML contents to PHP objects. A valid backend user account as well as having PHP setting "yaml.decode_php" enabled is needed to exploit this vulnerability (which is the default value according to PHP documentation).