Insufficient validation of user-supplied input for the Solstice Pod before 2.8.4 networking configuration enables authenticated attackers to execute arbitrary commands as root.

Solstice-Pod up to 5.0.2 WEBRTC server mishandles the format-string specifiers %x; %p; %c and %s in the screen_key, display_name, browser_name, and operation_system parameter during the authentication process. This may crash the server and force Solstice-Pod to reboot, which leads to a denial of service.

In Solstice Pod before 3.0.3, the web services allow users to connect to them over unencrypted channels via the Browser Look-in feature. An attacker suitably positioned to view a legitimate user's network traffic could record and monitor their interactions with the web services and obtain any information the user supplies, including Administrator passwords and screen keys.

In Solstice Pod before 3.3.0 (or Open4.3), the screen key can be enumerated using brute-force attacks via the /lookin/info Solstice Open Control API because there are only 1.7 million possibilities.

In Solstice Pod before 3.3.0 (or Open4.3), the Administrator password can be enumerated using brute-force attacks via the /Config/service/initModel?password= Solstice Open Control API because there is no complexity requirement (e.g., it might be all digits or all lowercase letters).

In Solstice Pod before 3.0.3, the firmware can easily be decompiled/disassembled. The decompiled/disassembled files contain non-obfuscated code. NOTE: it is unclear whether lack of obfuscation is directly associated with a negative impact, or instead only facilitates an attack technique

Solstice Pod API (version 5.5, 6.2) contains an unauthenticated API endpoint (`/api/config`) that exposes sensitive information such as the session key, server version, product details, and display name. Unauthorized users can extract live session information by accessing this endpoint without authentication.