Disclaimer: This post is for educational and defensive security purposes only. Never use the information and techniques shown here for anything illegal or on systems where you don’t have explicit permission. Doing so could break the law and get you into serious trouble.

Note: This is not the final version of this blog post. Some technical details are being withheld until the final patches for all vulnerabilities have been released.

Before diving into the found vulnerabilities, we want to give a huge shoutout to the Austrian CERT1. The CERT supported us throughout the whole coordinated vulnerability process (CVD), handled the communication with the ENISA for us and gave us regular insights and information about the current status. If anybody thinks about going through a CVD process, we would highly recommend doing it with the CERT.

The found vulnerabilities in this blog post affect the application Meona from Mesalvo2, which we found during a recent red team engagement. The affected version of Meona was 2025.04 5+323020 and the version of the launcher was 19.06.2020 15:11:49 (yes, just a timestamp). The application is used in the healthcare sector to manage patients, and is built on a client and server architecture. The client communicates through HTTP with the backend server. During our red team engagement, we abused the application for lateral movement, mail spoofing and password leakage. Below you can find each CVE and how we abused it.

Client-Side Authorization (CVE-2026-0856)

To start off, we first needed to find a way into the application, since we only had regular credentials without admin access to Meona. Examining the architecture of the .NET application and tinkering with it, we found out that the backend server did not verify the permissions of the given credentials. Because of that, we were able to access the admin panel with normal user credentials: Access to admin panel This access provides full control over all the data and functions inside the admin portal: Data inside admin panel

Plain Text Storage of Passwords (CVE-2026-0857)

After getting access to the admin panel, the users of the application could be examined: List of users Browsing through the users, several super admin accounts were found, with their respective passwords hashed using the MD5 algorithm: Showcase of a user with MD5 password hash Even more critical was the fact that some passwords were also stored in plaintext: Showcase of a user with a plaintext password These hashes were cracked in a short amount of time and were used in password spraying attacks together with the found plaintext passwords. We used this for lateral movement through the network through additional compromised accounts.

Code Execution (CVE-2026-22314)

Within the application, we found another way to laterally move through the network by abusing different administrative features. Scripts could be added in different programming languages or XML-based configurations could be changed to execute arbitrary code on each client Meona is running on: XML configuration option

Accessible SQL Interface (CVE-2026-22315)

Another feature of the application allowed NTLM relay attacks through an accessible SQL interface, since common SQL stored procedures were active: Menu of the SQL interface Among other things, also the (cleartext) passwords of all users could be read out through the same SQL interface, bypassing any logging mechanisms.

Recipient Email Address Manipulation (CVE-2026-25602)

The last thing we abused within our red team engagement was the feedback report functionality. As it can be seen in the screenshot, the mail address was hardcoded into the client: Sending feedback interface To change this, either the string within the client could be manipulated, or (the funnier part) the traffic could be analyzed: Request of the client As it can be seen, the application uses serialized Hessian3 objects for communication. Once the protocol was understood, the mail could simply be swapped out to an arbitrary address, together with the content. Since the server component does not verify the recipient address, it accepts the change and the message arrived at the new destination, sent from a legitimate mail server: Spoofed Mail Since the mail was sent from an internal address (noreply-meona-prod@customer.at), this feature was abused for internal social engineering.

Timetable

During the CVD we had the following timeline of relevant events:

DateDescription
2026-01-08Requested CVE identifiers and notified manufacturer
2026-01-12Received CVE identifiers
2026-01-26Manufacturer contacted SecCore
2026-01-27Explained vulnerabilities to manufacturer
2026-02-19Asked manufacturer for an update
2026-02-25Asked manufacturer for an update
2026-04-15Meeting with manufacturer, re-explained the vulnerabilities
2026-05-04Manufacturer wants to apply patches in May / June
2026-05-04Manufacturer requested publication of the CVEs
2026-05-13Initial blog post release