CVE-2026-33500
Stored XSS in WWBN AVideo Comments via Markdown Links
Publication date: 2026-03-23
Last updated on: 2026-03-24
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| wwbn | avideo | to 26.0 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-79 | The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'This vulnerability exists in the WWBN AVideo platform where an incomplete fix for a previous stored Cross-Site Scripting (XSS) issue allows attackers to inject malicious JavaScript via markdown links in comments.'}, {'type': 'paragraph', 'content': "The problem arises because the custom sanitization only handles raw HTML <a> and <img> tags but disables Parsedown's safeMode, which normally filters unsafe URLs like those starting with 'javascript:'. Markdown links using the syntax [text](url) are processed without this sanitization, allowing an attacker to craft links such as [Click here](javascript:alert(document.cookie)) that execute arbitrary JavaScript when clicked."}, {'type': 'paragraph', 'content': 'This stored XSS payload is saved in the database unchanged and executes in the context of any user viewing the comment, potentially leading to session hijacking and account takeover.'}] [1]
How can this vulnerability impact me? :
This vulnerability can impact users by allowing attackers to execute arbitrary JavaScript in the context of users viewing affected comments.
- Attackers can steal session cookies, leading to session hijacking.
- It can result in full account takeover if the attacker uses the stolen session.
- The vulnerability crosses trust boundaries and persists in the database, affecting all users who view the malicious comment.
- User interaction is required (the victim must click the malicious link), which limits the severity compared to auto-executing XSS.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by inspecting user comments for markdown links that contain unsafe URL schemes such as "javascript:". Specifically, look for markdown link syntax like `[text](javascript:alert(1))` in comments stored in the database or rendered on the platform.'}, {'type': 'paragraph', 'content': 'Since the vulnerability involves stored XSS via markdown links, detection involves searching for markdown links with potentially dangerous schemes in comment content.'}, {'type': 'list_item', 'content': 'Use database queries to find comments containing markdown links with `javascript:` URIs, for example, searching for the pattern `(javascript:` in comment text fields.'}, {'type': 'list_item', 'content': 'On the system or application logs, monitor for unusual or suspicious user input containing markdown links with unsafe schemes.'}, {'type': 'list_item', 'content': "No specific commands are provided in the resources, but a sample SQL query to detect potentially malicious markdown links could be: `SELECT * FROM comments WHERE comment_text LIKE '%(javascript:%';`"}] [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves applying the patch that overrides the `inlineLink()` method to whitelist safe URL schemes and strip unsafe ones from markdown links.
Specifically, update the platform to include the fix that enforces a whitelist on the `href` attribute of inline links, allowing only URLs starting with `http://`, `https://`, `mailto:`, `/`, or `#`. Unsafe schemes like `javascript:` are sanitized by setting the `href` to an empty string.
If patching immediately is not possible, consider disabling markdown link rendering or sanitizing user input to block or escape markdown links containing unsafe URL schemes.
Also, educate users to avoid clicking suspicious links in comments until the fix is applied.