#git

Failing to properly encode user input, frontend forms handled by the form framework (system extension “form”) are vulnerable to cross-site scripting.

When using the TYPO3 backend in order to create new backend user accounts, database records containing insecure or empty credentials might be persisted. When the type of user account is changed - which might be entity type or the admin flag for backend users - the backend form is reloaded in order to reflect changed configuration possibilities. However, this leads to persisting the current state as well, which can result into some of the following: - account contains empty login credentials (username and/or password) - account is incomplete and contains weak credentials (username and/or password) Albeit the functionality provided by the TYPO3 core cannot be used either with empty usernames or empty passwords, it still can be a severe vulnerability to custom authentication service implementations. This weakness cannot be directly exploited and requires interaction on purpose by some backend user having according privileges.

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 backend users having limited access to specific languages are capable of modifying and creating pages in the default language which actually should be disallowed. A valid backend user account is needed in order to exploit this vulnerability.

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.

Failing to properly encode user input, templates using built-in Fluid ViewHelpers are vulnerable to cross-site scripting.

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)

After weeks of withering criticism and exposed security flaws, Microsoft has vastly scaled back its ambitions for Recall, its AI-enabled silent recording feature, and added new privacy features.

Online Pizza Ordering System version 1.0 suffers from a remote SQL injection vulnerability.

The encrypt() function of Ninja Core v7.0.0 was discovered to use a weak cryptographic algorithm, leading to a possible leakage of sensitive information.