CVE-2026-61823: Stored Cross-Site Scripting (XSS) via iframe srcdoc Attribute in code16 Sharp

The administrative and content-management framework code16 Sharp for Laravel utilizes a rich-text editor allowing content creators to format and structure HTML. To prevent security issues, the framework employs an HTML sanitizer on incoming submissions before storing them in the persistent database layer.

However, in versions prior to 9.22.5, the backend sanitization rules explicitly allowed the 'srcdoc' attribute on 'iframe' elements. This configuration creates a critical parsing vector due to the structural differences between how server-side libraries sanitize raw HTML and how client-side user agents render the nested documents of iframes.

Because the input is persistently stored, any user with permission to edit a rich-text field can introduce malicious scripts. When another administrative user views the edited content within the Sharp interface, the script executes, creating a significant privilege escalation risk.

The root cause of this vulnerability lies in the improper neutralization of input within nested browser rendering contexts (CWE-79). When a server-side HTML sanitizer processes an iframe with a 'srcdoc' attribute, it attempts to protect the page by HTML-encoding active tag markers inside the attribute. For example, the string <script> becomes <script>.

While this sanitization is sufficient for typical attribute contexts, the 'srcdoc' attribute defines the content of an embedded HTML document. Web browsers natively process this attribute by applying a standard decoding pass. During this pass, the browser converts all HTML entities (such as < and >) back into their literal characters before executing the DOM parser inside the frame.

Consequently, the browser reverses the safety measures applied by the sanitizer. The safe, encoded string is normalized back into an active script block inside the document. The browser then executes the script in the context of the parent domain unless isolated by a strict sandbox configuration.

The configuration error was located within the backend formatting class at src/Utils/Sanitization/FormatsSanitizedValue.php. The sanitizer instances whitelisted several attributes on iframe elements, including the vulnerable 'srcdoc' attribute.

Below is the relevant code before the remediation was applied:

private function sanitizer(): HtmlSanitizer
{
    return (new HtmlSanitizer())
        // ...
        ->allowAttribute('srcdoc', 'iframe') // The vulnerable configuration
        // ...
}

The fix, implemented in commit ec509a22c808a5bd9dfad6a0a85c92ce6f411e21, removes 'srcdoc' from the allowed properties. Below is the patch details:

File: src/Utils/Sanitization/FormatsSanitizedValue.php
@@ -49,7 +49,6 @@ private function sanitizer(): HtmlSanitizer
                 'referrerpolicy',
                 'sandbox',
                 'src',
-                'srcdoc',
                 'width',
                 'height',
                 'id',

Additionally, the patch hardens data attributes (specifically 'data-html-content') to ensure they are only preserved if the RAW_HTML option is enabled in the rich-text field's toolbar. This prevents alternative bypass paths using unescaped data tags.

An attacker with authenticated access to edit rich-text fields within the admin panel constructs a payload targeting the nested parsing behavior of the iframe. This payload consists of an iframe tag whose 'srcdoc' attribute contains encoded scripting elements.

<iframe srcdoc="&lt;script&gt;alert('Stored XSS')&lt;/script&gt;"></iframe>

When the application processes this payload, the backend sanitizer evaluates the input. Because 'srcdoc' is whitelisted, the parser accepts the attribute without stripping it. The application saves the sanitized markup to the database.

Upon retrieval, the application renders the raw iframe within the DOM. The browser processes the 'srcdoc' attribute, decodes the HTML entities, and executes the payload inside the frame, bypassing standard sanitization filters.

A successful attack allows arbitrary JavaScript to execute in the security context of the victim's session. Since code16 Sharp is a Laravel-based administrative and content-management framework, the typical user of this interface holds elevated privileges (e.g., content managers, editors, and administrators).

The executing script can perform actions on behalf of the victim. This includes hijacking active sessions via cookie extraction (unless protected by HttpOnly flags), reading sensitive data exposed in the administrative console, or silently performing state-changing operations such as creating new administrative accounts, modifying application configurations, or deploying malicious templates.

The primary remediation strategy is upgrading the code16/sharp package to version 9.22.5 or higher. This permanently removes 'srcdoc' from the whitelist of the underlying sanitizer.

If upgrading immediately is not possible, a temporary workaround can be achieved via a global Laravel middleware or custom validation rules. This layer should analyze incoming editor fields and remove 'srcdoc' attributes using an XML/HTML DOM parser before storing the content.

public function sanitizeIncomingContent(string $content): string
{
    // Temporary regular expression to strip the srcdoc attribute if DOM parsing is unavailable
    return preg_replace('/<iframe\b[^>]*\bsrcdoc\s*=\s*(["\'])(.*?)\1/is', '<iframe>', $content);
}

For defense-in-depth, configure a Content Security Policy (CSP) header that restricts iframe generation (frame-src 'self') and limits script execution domains to trusted sources.