Security Advisory

CVE-2026-79363Stored XSS in the branding footer

Cloudron · Cloudron UG (haftungsbeschränkt)

Advisory published 6 Oct 2026 · discovered 2 Jul 2026

Jump to proof of concept

Overview

Cloudron’s branding footer allowed HTML to be stored persistently. In the versions I tested (9.1.7 and 9.2), the value was rendered as HTML on the public login / OpenID interaction page and in the event log without sufficient sanitization. This allowed stored JavaScript to execute within the Cloudron origin.

Technical findings

The entry point was Appearance → Branding → Footer. An administrator or superadmin could store HTML there. The value was then used not only as branding on the public sign-in page but also rendered in other views, including the system event log.

After saving the value, simply opening the public Cloudron login or OpenID interaction page was enough to trigger the event handler. The same stored value was also rendered as HTML in the event log. Historical log entries could continue to contain the injected content even after the footer had been cleaned up.

An important qualification: inserting the payload requires high privileges on the Cloudron instance. This is not an unauthenticated injection. Once stored, however, the code can reach other users through a public authentication interface.

Proof of Concept (PoC)

The Branding Footer value is stored and later rendered as HTML without sufficient sanitization. The payload executes when the public Cloudron login / OpenID interaction page is loaded. The same stored value is also rendered in the Event Log.

PoC payload

cloud><img src=x onerror=prompt(1)>

Steps to reproduce

  1. Log in to Cloudron as an administrator or superadministrator.
  2. Go to Appearance → Branding.
  3. Set the Footer value to the payload shown above.
  4. Save the change.
  5. Open the public Cloudron login / OpenID interaction page.
  6. The stored JavaScript executes and opens the prompt(1) dialog.
  7. Go to System → Event Log.
  8. The same injected HTML is rendered there.
  9. Even after removing the payload from the Footer, the injected value may remain in the Event Log history.

Reproduce these steps only on a Cloudron instance you own or are explicitly authorized to test.

Why it matters

Stored XSS matters here because configuration data from a privileged admin area is passed to a public login / OIDC interface. The browser executing the payload does not have to be the one that supplied the manipulated value.

The JavaScript runs in the web origin of the Cloudron interface. Depending on the session, browser protections and exposed functionality, a payload may manipulate the visible login screen, read browser-accessible data or issue same-origin requests in the affected user’s context.

Potential impact

  • Persistent JavaScript execution for users who visit the affected login / OpenID page.
  • Manipulation of the sign-in interface, including deceptive content or redirects.
  • Execution in the Cloudron web origin with the privileges and browser capabilities of the affected session.
  • Repeated rendering of injected HTML in the event log; historical entries may retain the value for longer.

Remediation

  • Upgrade to Cloudron 10.0.0 or later.
  • Cloudron publicly described the fix as using DOMPurify; the Cloudron 10 release notes also mention sanitizing HTML and Markdown.
  • Allow arbitrary HTML only where functionally necessary, and sanitize it with a maintained library before it reaches any DOM sink.
  • Render event-log values as text, or use context-appropriate output encoding.
  • Maintain a restrictive Content Security Policy as defense in depth.

Affected and fixed versions

Confirmed affected / tested9.1.7 and 9.2
Fixed / vendor-confirmed10.0.0
Version scope

Cloudron confirmed that 10.0.0 was the first release containing the fix. The vendor also publicly described the issue as having existed for some time. Since I personally tested 9.1.7 and 9.2, I list only those releases as confirmed affected rather than claiming an introduction point I did not verify.

Disclosure timeline

  1. Responsible Disclosure

    Submitted the full report, including reproduction steps, PoC, impact and recommendations, to security@cloudron.io.

  2. Vendor confirmation

    Cloudron acknowledged the finding and said DOMPurify would be used for HTML sanitization in the next release.

  3. Cloudron 10 announced

    The public Cloudron 10 announcement lists “sanitize HTML and markdown in the dashboard” among its security changes.

  4. Final version clarification

    Asked the vendor again which release first included the fix before publication.

  5. Fixed version confirmed

    Cloudron confirmed 10.0.0 as the fixed release. The email cited 16 August 2026 as its release date, whereas the public Cloudron 10 announcement is dated 17 September 2026. For this advisory, the vendor-confirmed fixed version is therefore the relevant reference point.

  6. 90-day window elapsed

    The announced coordinated disclosure window following the original report had elapsed.

  7. Public Disclosure

    Published the technical advisory for CVE-2026-79363 on faydin.blog.

References

More security research

My other published vulnerability findings and coordinated disclosure advisories are collected in the CVE overview.