Focus on mersive vulnerabilities and metrics.
Last updated: 16 Jan 2026, 23:25 UTC
This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with mersive. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.
For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.
Total mersive CVEs: 7
Earliest CVE date: 27 Nov 2019, 16:15 UTC
Latest CVE date: 04 Dec 2025, 21:16 UTC
Latest CVE reference: CVE-2025-66573
30-day Count (Rolling): 0
365-day Count (Rolling): 1
Calendar-based Variation
Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.
Month Variation (Calendar): -100.0%
Year Variation (Calendar): 0%
Month Growth Rate (30-day Rolling): -100.0%
Year Growth Rate (365-day Rolling): 0.0%
Average CVSS: 4.76
Max CVSS: 9.0
Critical CVEs (≥9): 1
| Range | Count |
|---|---|
| 0.0-3.9 | 1 |
| 4.0-6.9 | 5 |
| 7.0-8.9 | 0 |
| 9.0-10.0 | 1 |
These are the five CVEs with the highest CVSS scores for mersive, sorted by severity first and recency.
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.
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
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.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.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.
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.
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.