| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| User ID references at mentions in document comments were not correctly sanitized. Script code could be injected to a users session when working with a malicious document. Please deploy the provided updates and patch releases. User-defined content like comments and mentions are now filtered to avoid potentially malicious content. No publicly available exploits are known. |
| Connections to external data sources, like e-mail autoconfiguration, were not terminated in case they hit a timeout, instead those connections were logged. Some connections use user-controlled endpoints, which could be malicious and attempt to keep the connection open for an extended period of time. As a result users were able to trigger large amount of egress network connections, possibly exhausting network pool resources and lock up legitimate requests. A new mechanism has been introduced to cancel external connections that might access user-controlled endpoints. No publicly available exploits are known.
|
| Documents operations, in this case "drawing", could be manipulated to contain invalid data types, possibly script code. Script code could be injected to an operation that would be executed for users that are actively collaborating on the same document. Operation data exchanged between collaborating parties does now gets checked for validity to avoid code execution. No publicly available exploits are known.
|
| Documents operations could be manipulated to contain invalid data types, possibly script code. Script code could be injected to an operation that would be executed for users that are actively collaborating on the same document. Operation data exchanged between collaborating parties does now get escaped to avoid code execution. No publicly available exploits are known.
|
| RMI was not requiring authentication when calling ChronosRMIService:setEventOrganizer. Attackers with local or adjacent network access could abuse the RMI service to modify calendar items using RMI. RMI access is restricted to localhost by default. The interface has been updated to require authenticated requests. No publicly available exploits are known.
|
| Requests to fetch image metadata could be abused to include SQL queries that would be executed unchecked. Exploiting this vulnerability requires at least access to adjacent networks of the imageconverter service, which is not exposed to public networks by default. Arbitrary SQL statements could be executed in the context of the services database user account. API requests are now properly checked for valid content and attempts to circumvent this check are being logged as error. No publicly available exploits are known.
|
| Requests to cache an image could be abused to include SQL queries that would be executed unchecked. Exploiting this vulnerability requires at least access to adjacent networks of the imageconverter service, which is not exposed to public networks by default. Arbitrary SQL statements could be executed in the context of the services database user account. API requests are now properly checked for valid content and attempts to circumvent this check are being logged as error. No publicly available exploits are known.
|
| Requests to cache an image and return its metadata could be abused to include SQL queries that would be executed unchecked. Exploiting this vulnerability requires at least access to adjacent networks of the imageconverter service, which is not exposed to public networks by default. Arbitrary SQL statements could be executed in the context of the services database user account. API requests are now properly checked for valid content and attempts to circumvent this check are being logged as error. No publicly available exploits are known.
|
| Functions with insufficient randomness were used to generate authorization tokens of the integrated oAuth Authorization Service. Authorization codes were predictable for third parties and could be used to intercept and take over the client authorization process. As a result, other users accounts could be compromised. The oAuth Authorization Service is not enabled by default. We have updated the implementation to use sources with sufficient randomness to generate authorization tokens. No publicly available exploits are known.
|
| The "OX Count" web service did not specify a media-type when processing responses by external resources. 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 are now defining the accepted media-type to avoid code execution. No publicly available exploits are known.
|
| The "OX Chat" web service did not specify a media-type when processing responses by external resources. 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 are now defining the accepted media-type to avoid code execution. No publicly available exploits are known.
|
| Custom log-in and log-out locations are used-defined as jslob but were not checked to contain malicious protocol handlers. 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 jslob content for those locations to avoid redirects to malicious content. No publicly available exploits are known.
|
| The "upsell" widget for the portal allows to specify a product description. This description taken from a user-controllable jslob did not get 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 jslob content. No publicly available exploits are known.
|
| 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.
|
| 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.
|
