The users clientID at "application passwords" was not sanitized or escaped before being added to DOM. Malicious script code can be executed within the victims context. This can lead to session hijacking or triggering unwanted actions via the web interface and API. To exploit this an attacker would require temporary access to the users account or lure a user to a compromised account. We now sanitize the user-controllable clientID parameter. No publicly available exploits are known.

Frontend themes are defined by user-controllable jslob settings and could point to a malicious resource which gets processed during login. Malicious script code can be executed within the victims context. This can lead to session hijacking or triggering unwanted actions via the web interface and API. To exploit this an attacker would require temporary access to the users account or lure a user to a compromised account. We now sanitize the theme value and use a default fallback if no theme matches. No publicly available exploits are known.

Full-text autocomplete search allows user-provided SQL syntax to be injected to SQL statements. With existing sanitization in place, this can be abused to trigger benign SQL Exceptions but could potentially be escalated to a malicious SQL injection vulnerability. We now properly encode single quotes for SQL FULLTEXT queries. No publicly available exploits are known.

In case Cacheservice was configured to use a sproxyd object-storage backend, it would follow HTTP redirects issued by that backend. An attacker with access to a local or restricted network with the capability to intercept and replay HTTP requests to sproxyd (or who is in control of the sproxyd service) could perform a server-side request-forgery attack and make Cacheservice connect to unexpected resources. We have disabled the ability to follow HTTP redirects when connecting to sproxyd resources. No publicly available exploits are known.

Cacheservice did not correctly check if relative cache object were pointing to the defined absolute location when accessing resources. An attacker with access to the database and a local or restricted network would be able to read arbitrary local file system resources that are accessible by the services system user account. We have improved path validation and make sure that any access is contained to the defined root directory. No publicly available exploits are known.

The cacheservice API could be abused to indirectly inject parameters with SQL syntax which was insufficiently sanitized and would later be executed when creating new cache groups. Attackers with access to a local or restricted network could perform arbitrary SQL queries. We have improved the input check for API calls and filter for potentially malicious content. No publicly available exploits are known.

The cacheservice API could be abused to inject parameters with SQL syntax which was insufficiently sanitized before getting executed as SQL statement. Attackers with access to a local or restricted network were able to perform arbitrary SQL queries, discovering other users cached data. We have improved the input check for API calls and filter for potentially malicious content. No publicly available exploits are known.

External service lookups for a number of protocols were vulnerable to a time-of-check/time-of-use (TOCTOU) weakness, involving the JDK DNS cache. Attackers that were timing DNS cache expiry correctly were able to inject configuration that would bypass existing network deny-lists. Attackers could exploit this weakness to discover the existence of restricted network infrastructure and service availability. Improvements were made to include deny-lists not only during the check of the provided connection data, but also during use. No publicly available exploits are known.

Attackers with access to user accounts can inject arbitrary control characters to SIEVE mail-filter rules. This could be abused to access SIEVE extension that are not allowed by App Suite or to inject rules which would break per-user filter processing, requiring manual cleanup of such rules. We have added sanitization to all mail-filter APIs to avoid forwardning control characters to subsystems. No publicly available exploits are known.

Attackers with access to the "documentconverterws" API were able to inject serialized Java objects, that were not properly checked during deserialization. Access to this API endpoint is restricted to local networks by default. Arbitrary code could be injected that is being executed when processing the request. A check has been introduced to restrict processing of legal and expected classes for this API. We now log a warning in case there are attempts to inject illegal classes. No publicly available exploits are known.