Users were able to set an arbitrary "product name" for OX Guard. The chosen value was not sufficiently sanitized before processing it at the user interface, allowing for indirect cross-site scripting attacks. Accounts that were temporarily taken over could be configured to trigger persistent code execution, allowing an attacker to build a foothold. Sanitization is in place for product names now. No publicly available exploits are known.

OX Guard 2.10.4 and earlier allows a Denial of Service via a WKS server that responds slowly or with a large amount of data.

An issue was discovered in Open-Xchange OX Guard before 2.4.0-rev8. OX Guard uses an authentication token to identify and transfer guest users' credentials. The OX Guard API acts as a padding oracle by responding with different error codes depending on whether the provided token matches the encryption padding. In combination with AES-CBC, this allows attackers to guess the correct padding. Attackers may run brute-forcing attacks on the content of the guest authentication token and discover user credentials. For a practical attack vector, the guest users needs to have logged in, the content of the guest user's "OxReaderID" cookie and the value of the "auth" parameter needs to be known to the attacker.