Improper Access Control vulnerability in Mesalvo MEONA (MEONA Client and MEONA Server) allows an authenticated MEONA user to access administrative functions of the MEONA Client (admin panel). The MEONA Server does not independently verify the role asserted by the MEONA Client. A user who holds a valid MEONA user account and is able to execute a modified copy of the MEONA Client on a device within the operating hospitals network can assert an administrator role and access administrative functions with regular user credentials. Exploitation requires: (1) a valid MEONA user account issued by the operating hospital; (2) network access to the MEONA Server, which is operated exclusively within closed hospital networks without exposure to the public Internet (where a hospital permits remote access to that network at all, it is only through the hospitals own remote-access infrastructure (e.g. VPN) under the hospitals control); (3) the ability to modify MEONA Client binaries and to execute the modified copy on a device in that network. On managed devices with application control, as recommended in Mesalvos hardening guidance (MSA-2026-001), this requires local administrator privileges on the device. Mesalvo is not aware of any exploitation outside the reported security test. This issue affects MEONA Client and MEONA Server in versions 2024.10, 2025.04 and 2026.03. Mitigations are available with MEONA 2025.04.24 and 2026.03.02 (planned Q4 2026); see Mesalvo Security Advisory MSA-2026-001.
Weakness
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
Extended Description
Access control involves the use of several protection mechanisms such as:
When any mechanism is not applied or otherwise fails, attackers can compromise the security of the product by gaining privileges, reading sensitive information, executing commands, evading detection, etc. There are two distinct behaviors that can introduce access control weaknesses:
Potential Mitigations
- Compartmentalize the system to have “safe” areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
Related Attack Patterns
- https://cwe.mitre.org/data/definitions/19.html
- https://cwe.mitre.org/data/definitions/441.html
- https://cwe.mitre.org/data/definitions/478.html
- https://cwe.mitre.org/data/definitions/479.html
- https://cwe.mitre.org/data/definitions/502.html
- https://cwe.mitre.org/data/definitions/503.html
- https://cwe.mitre.org/data/definitions/536.html
- https://cwe.mitre.org/data/definitions/546.html
- https://cwe.mitre.org/data/definitions/550.html
- https://cwe.mitre.org/data/definitions/551.html
- https://cwe.mitre.org/data/definitions/552.html
- https://cwe.mitre.org/data/definitions/556.html
- https://cwe.mitre.org/data/definitions/558.html
- https://cwe.mitre.org/data/definitions/562.html
- https://cwe.mitre.org/data/definitions/563.html
- https://cwe.mitre.org/data/definitions/564.html
- https://cwe.mitre.org/data/definitions/578.html