CtrlPanel-gg Stored XSS Session Hijacking Vulnerability

A severe Stored Cross-Site Scripting (XSS) vulnerability in CtrlPanel-gg/panel, a widely utilized Composer package for server and web application management.

Tracked under the GitHub Security Advisory GHSA-cmrr-q3hw-3vqh, this flaw allows unauthenticated or low-privileged attackers to inject malicious JavaScript into the application’s database. When triggered, this payload can facilitate complete session hijacking, credential harvesting, and unauthorized privilege escalation.

For organizations and administrators relying on CtrlPanel-gg for their infrastructure management, understanding the mechanics of this exploit is paramount.

At its core, Stored XSS (also known as Persistent XSS) occurs when a web application gathers input from a user, fails to properly sanitize or validate that input, and then stores it directly into a database or file system.

Later, when the application retrieves and renders that stored data in a victim’s browser, the malicious script executes within the context of the user’s session.

In the case of CtrlPanel-gg/panel (versions 1.1.1 and prior), this exact scenario plays out within the platform’s support ticket reply notification system. The vulnerability is deeply rooted in how the application handles the $newmessage variable when a user or administrator submits a response to a support ticket.

CtrlPanel-gg Stored XSS Vulnerability

Modern PHP frameworks like Laravel utilize templating engines in this case, Blade to render HTML views dynamically. Blade offers two primary syntaxes for outputting variables:

{{ $variable }}: This syntax automatically runs the data through PHP’s htmlspecialchars() function, effectively neutralizing any HTML or JavaScript by converting special characters into benign HTML entities.
{!! $variable !!}: This syntax explicitly tells the engine to output the raw, unescaped data directly into the Document Object Model (DOM).

The developers of CtrlPanel-gg mistakenly utilized the unescaped {!! !!} syntax within the notification view files. When a ticket reply is submitted, the application stores the raw message content in the database payload.

When the recipient later opens their notification panel, the raw HTML and JavaScript embedded in the reply are rendered directly by the browser.

The vulnerability manifests in two specific notification directions:

App\Notifications\Ticket\Admin\AdminReplyNotification: Triggered when a standard user replies to a ticket, injecting the payload into the administrator’s notification feed.
App\Notifications\Ticket\User\ReplyNotification: Triggered when an administrator replies, targeting the standard user’s notification feed.

To fully grasp the severity of this flaw, we must examine the primary attack path: User to Administrator. This vector is particularly dangerous because it allows a low-privileged user to execute code in the context of a highly privileged account.

Initial Access: An attacker registers or logs in as a standard, unprivileged user within the CtrlPanel-gg environment.
Payload Injection: The attacker navigates to the support ticket module and opens a new or existing ticket. They then submit a reply containing a malicious JavaScript payload. A simplified Proof of Concept (PoC) looks like this:HTML<script>alert('XSS_POC_Executed')</script> In a real-world attack, this script would be designed to silently exfiltrate session cookies or perform background administrative actions.
Storage: The application accepts this input without filtering, routing it to the database as an AdminReplyNotification.
Execution: When a targeted administrator logs into the system and clicks the notification bell icon in the top navigation bar, the drop-down renders the unsanitized payload. The JavaScript executes immediately in the admin’s browser context.

The reverse path Administrator to User is equally viable. A compromised or rogue administrator could systematically infect standard user accounts by replying to their support tickets with malicious payloads, effectively turning the notification system into a watering-hole attack mechanism.

While PoCs often use simple alert() boxes to demonstrate execution, the real-world impact of a Stored XSS vulnerability in an administrative panel is catastrophic. Because the script executes within the victim’s browser, it inherits the victim’s session authority, network placement, and access rights.

The most immediate threat is session hijacking. The injected JavaScript can access the document.cookie object (provided the cookies lack the HttpOnly flag) and transmit the administrator’s session token to a remote server controlled by the attacker. With this token, the attacker can hijack the active session, bypassing login screens and multi-factor authentication (MFA).

Once an attacker forces an administrator’s browser to execute arbitrary code, they can programmatically force the browser to issue authenticated HTTP requests. Without the victim’s knowledge, the malicious script could create new rogue administrator accounts, alter system configurations, or modify the passwords of existing users.

Attackers can use JavaScript to dynamically rewrite the DOM, injecting highly convincing, fake login prompts over the legitimate interface. When the startled administrator attempts to re-authenticate, their credentials are sent directly to the attacker.

Remediation and Patch

The developers of CtrlPanel-gg/panel have acknowledged the severity of this flaw and released a comprehensive patch in version 1.2.0. All administrators utilizing this package are strongly urged to update their instances immediately.

The remediation strategy is straightforward but highly effective. Since the notification panel is only designed to display a plain-text summary of the ticket reply, the developers implemented PHP’s native strip_tags() function.

This function aggressively strips all HTML and PHP tags from a given string, neutralizing any <script>, <iframe>, or <img> based injection attempts before they are embedded into the notification payload.

Vulnerable Code Snippet:

PHP

'content' => "
    <p>Ticket With ID : {$this->ticket->ticket_id} has had a new reply posted by <strong>{$this->user->name}</strong></p>
    <br>
    <p><strong>Message:</strong></p>
    <p>{$this->newmessage}</p>
",

Patched Code Snippet:

PHP

'content' => "
    <p>Ticket With ID : {$this->ticket->ticket_id} has had a new reply posted by <strong>{$this->user->name}</strong></p>
    <br>
    <p><strong>Message:</strong></p>
    <p>" . strip_tags($this->newmessage) . "</p>
",

This fix was correctly applied to both app/Notifications/Ticket/Admin/AdminReplyNotification.php and app/Notifications/Ticket/User/ReplyNotification.php.