Summary
Sakai Conversations stores topic and post content without HTML sanitization and renders it with an unsafe HTML directive, enabling stored cross-site scripting.
An authenticated user with access to an enabled Conversations tool may inject content that executes JavaScript in the browsers of other users who view the affected topic or post.
Affected context
The vulnerability occurs in Sakai Conversations deployments using affected 23.x or 25.x releases. It requires a site where the Conversations tool is enabled and where an authenticated user can create or modify topics or posts. Risk arises when stored message content is later rendered in other users' browsers without effective HTML and script sanitization.
Exploit preconditions
- Attack surface: Sakai Conversations topic and post rendering
- Required access: An authenticated account with permission to access a site and submit or modify Conversation content
- Trigger point: Another user views the topic or post containing the stored content
- Why exploitation is possible: Submitted content is stored without adequate sanitization and is rendered through a frontend path that permits unsafe HTML
Why this happens
The underlying bug is a mismatch between untrusted user-generated content and a rendering mechanism designed to interpret HTML. Sakai stores topic and post messages without applying an appropriate sanitization policy, while the frontend uses LitElement's unsafeHTML() directive to render the content. This insecure pattern maps to CWE-79: Improper Neutralization of Input During Web Page Generation, because attacker-controlled data can become active markup or script in another user's browser.
Potential impact
- Execution of attacker-controlled script in the context of a Sakai session
- Theft of accessible user data or session-related information
- Unauthorized actions performed through a victim's browser
- Defacement or manipulation of Conversation content
- Phishing, malware delivery, or broader compromise of users who view affected posts
General mitigation guidance
Mitigation generally focuses on treating all user-generated message content as untrusted and preventing unsafe interpretation in the browser.
Common defensive patterns include:
- Applying context-aware, allowlist-based HTML sanitization before storage or rendering
- Rendering plain text by default when rich content is not required
- Avoiding unsafe HTML rendering directives for untrusted content
- Enforcing output encoding appropriate to the rendering context
- Applying defense-in-depth browser policies, such as a restrictive Content Security Policy
- Limiting authoring and editing permissions according to least privilege
- Preserving sanitized-content guarantees consistently across API, storage, and frontend layers
How teams detect issues like this
Organizations can look for stored XSS risks through:
- Static analysis rules identifying unsafe HTML rendering APIs and directives
- Code review checks for user-controlled data flowing into HTML-capable sinks
- Tests that submit markup and script-like content through topic and post fields, then verify safe rendering
- Review of sanitization and encoding policies across storage, API, and frontend boundaries
- Content-security and web-application monitoring for unexpected script execution or suspicious markup
- CI policy enforcement requiring approved sanitization libraries and rejecting unsafe rendering patterns
