E-Health Issues (1/3) - Severe Vulnerabilities in SimplifyU

During the last year (2025), we conducted a variety of penetration tests on E-Health applications. Shockingly, they all had severe vulnerabilities. This is particularly concerning given the highly sensitive information stored and processed by these applications. This is the first of three blog posts in which we will disclose some of the vulnerabilities we identified.

Intro

One of our clients wanted to begin using the E-Health web application SimplifyU – a quality management software for the health sector – in production. However, they wanted to assess its security before doing so. Hence, we conducted a web application penetration test. The results revealed multiple severe vulnerabilities, such as stored XSS across the entire application and anonymous users being able to easily brute-force access to sensitive reports.

Fortunately, the vendor, SimplifyU GmbH, responded quickly and professionally. The vulnerabilities were fixed shortly after they were disclosed.

Overview of the CVEs

A total of 8 CVEs were assigned to the most severe vulnerabilities identified. The affected versions are “02.06.2025 09:10” and earlier for the back-end as well as “02.06.2025 09:16” and earlier for the front-end.

Remediation

It is recommended to update SimplifyU to the latest version. All vulnerabilities have been fixed in the following release:

• Frontend: 23.02.2026 – 13:11:08
• Backend: 23.02.2026 – 13:13:12

CVEs in Detail

Stored Cross-Site Scripting

A total of 31 stored cross-site scripting (XSS) instances were identified. 14 of these could be exploited by users with the lowest permissions, i.e. “Leser” (German for “Reader”). Most of these could also be exploited by unauthenticated users if anonymous access was configured as allowed. A further 17 instances of stored XSS could only be exploited by users with higher permissions, i.e. “Verantwortlicher” (German for “Person in Charge”).

All instances were trivial XSS vulnerabilities because there was no user input validation. Unvalidated user input was embedded directly into HTML documents, so simple payloads such as <img src onerror=alert()> were sufficient. Therefore, there is nothing more to go into.

To keep track of the numerous XSS vulnerabilities, we created alert boxes containing an identifier for the affected functionality. The following figure illustrates one of these.

CSV Injection

A total of 7 tables contained unvalidated user input that could be exported as an Excel (.xlsx) file. By embedding CSV injection payloads, such as =cmd|' /C calc'!xxx, into specific places, it was possible to execute any command on the system of a user who opened an Excel file containing them. This is especially dangerous because users are likely to trust files exported from the SimplifyU application.

Insufficient Brute-Force Protection

This was the most interesting vulnerability from a technical perspective. SimplifyU allows both anonymous and authenticated users to open any report via the “TAN-Suche” (“TAN-Search”). Two pieces of information are needed for this: First, a “Meldungsnummer” (report number) and a TAN. The report number can easily be guessed because it has a fixed format. The first report has the number “M00001”, the 12th “M00012”, and so on. Therefore, all that is needed to access any report is to guess (or brute-force :)) the TAN, and there was no brute-force protection in place.

It doesn’t sound that difficult to exploit, right? You just throw it in Burp Intruder or FFUF and let it brute force the TAN in a matter of seconds or minutes. However, that wasn’t possible in this case because of the framework that SimplifyU is built with.

SimplifyU uses the ASP.NET Core Blazor framework, which uses a custom binary serialisation format called ‘BlazorPack’. Furthermore, Blazor communicates via WebSockets by default.

Fortunately, both issues can be resolved by using the Burp extension BlazorTrafficProcessor. It forces traffic to fall back to HTTP and supports conversion from binary to JSON format for easy modification. However, it cannot be used for automated brute force attacks. Therefore, we created a simple PoC Python script that can brute-force the TAN for any report.

Due to the way Blazor works, two requests are required for each brute-force attempt. The first request updates the TAN on the front- and back-end, while the second request triggers the TAN check on the back-end. As a side effect, the brute-force process looks pretty cool because one can see the TAN number increase visually until the correct one is found and the report is displayed.

The following figure shows the script iterating through every possible TAN, with the TAN on the web application being visually updated each time to reflect the next TAN to be tried.

Leak of EntraID Secret Key

The EntraID Secret Key was displayed in the EntraID settings of the web application. Although this was only accessible to privileged users, there were several (unauthenticated) stored XSS vulnerabilities that could be exploited to exfiltrate the EntraID Secret Key. This secret key can be used to request an access token for the Microsoft Graph API. The consequences depend on the app’s configuration. In our customer’s case, we could “only” retrieve various information about EntraID users, such as names, phone numbers, and email addresses.

This was the only vulnerability that was still present during the retest. However, it was eventually fixed in February 2026.

Timeline