Vulnerabilidades

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…

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…

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…

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…

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…

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…

It was possible to call filesystem and network references using the local LibreOffice instance using manipulated ODT documents. Attackers could discover restricted network topology and services as well as including local files with read permissions of the open-xchange system user. This was limited to specific…

When adding an external mail account, processing of POP3 "capabilities" responses are not limited to plausible sizes. Attacker with access to a rogue POP3 service could trigger requests that lead to excessive resource usage and eventually service unavailability. We now limit accepted POP3 server response to reasonable…

When adding an external mail account, processing of IMAP "capabilities" responses are not limited to plausible sizes. Attacker with access to a rogue IMAP service could trigger requests that lead to excessive resource usage and eventually service unavailability. We now limit accepted IMAP server response to reasonable…

When adding an external mail account, processing of SMTP "capabilities" responses are not limited to plausible sizes. Attacker with access to a rogue SMTP service could trigger requests that lead to excessive resource usage and eventually service unavailability. We now limit accepted SMTP server response to reasonable…

IPv4-mapped IPv6 addresses did not get recognized as "local" by the code and a connection attempt is made. Attackers with access to user accounts could use this to bypass existing deny-list functionality and trigger requests to restricted network infrastructure to gain insight about topology and running services. We…

Control characters were not removed when exporting user feedback content. This allowed attackers to include unexpected content via user feedback and potentially break the exported data structure. We now drop all control characters that are not whitespace character during the export. No publicly available exploits are…

Attackers can successfully request arbitrary snippet IDs, including E-Mail signatures of other users within the same context. Signatures of other users could be read even though they are not explicitly shared. We improved permission handling when requesting snippets that are not explicitly shared with other users. No…

Default permissions for a properties file were too permissive. Local system users could read potentially sensitive information. We updated the default permissions for noreply.properties set during package installation. No publicly available exploits are known.

OX App Suite through 7.10.6 allows XSS via a malicious capability to the metrics or help module, as demonstrated by a /#!!&app=io.ox/files&cap= URI.

OX App Suite through 7.10.6 allows XSS via script code within a contact that has an e-mail address but lacks a name.

OX App Suite through 8.2 allows XSS via a certain complex hierarchy that forces use of Show Entire Message for a huge HTML e-mail message.

OX App Suite through 8.2 allows XSS because BMFreehand10 and image/x-freehand are not blocked.

OX App Suite through 7.10.6 allows XSS via HTML in text/plain e-mail messages.

OX App Suite through 7.10.6 allows SSRF because the anti-SSRF protection mechanism only checks the first DNS AA or AAAA record.

OX App Suite through 7.10.6 has Uncontrolled Resource Consumption via a large request body containing a redirect URL to the deferrer servlet.

OX App Suite through 7.10.6 has Uncontrolled Resource Consumption via a large location request parameter to the redirect servlet.

OX App Suite through 7.10.6 allows XSS via XHTML CDATA for a snippet, as demonstrated by the onerror attribute of an IMG element within an e-mail signature.

OX App Suite through 7.10.6 allows XSS via a deep link, as demonstrated by class="deep-link-app" for a /#!!&app=%2e./ URI.

OX App Suite before 7.10.3-rev32 and 7.10.4 before 7.10.4-rev18 allows XSS via a code snippet (user-generated content) when a sharing link is created and an App Loader relative URL is used.