Summary
The blog comment functionality improperly sanitizes user-supplied HTML, allowing certain HTML tags (such as images and media elements) to be rendered in comments. Although many dangerous tags are filtered, several HTML elements remain permitted, enabling users to embed arbitrary external content within comments.
Vulnerability Type
HTML Injection
Improper Input Sanitization
Stored Content Injection
Affected URL
https:
Description
The blog comment feature attempts to sanitize HTML input before rendering comments. While many HTML tags and potentially dangerous payloads are blocked, the sanitization is incomplete.
I discovered that several HTML elements are still accepted and rendered by the application. For example, image tags and certain media-related elements can be embedded within comments and are displayed to anyone viewing the blog post.
This allows attackers to inject arbitrary HTML content into comments. Although JavaScript execution appears to be prevented, the ability to embed external resources can still be abused to manipulate comment appearance, display misleading content, or load third-party resources.
Steps to Reproduce
Visit:
https:
Add a new comment.
Include HTML that uses an allowed element, for example:
<img src="https://example.com/image.png">
or another permitted media element.
Submit the comment.
Refresh the page.
Observe that the HTML is rendered instead of being escaped or removed.
Proof of Concept
Example payload:
<img src="https://example.com/image.png">
Observed Result
The image is rendered within the blog comment.
HTML is interpreted by the browser rather than displayed as plain text.
Expected Result
User-supplied comments should either:
Escape all HTML before rendering, or
Allow only a strictly defined whitelist of safe formatting tags that do not permit embedding external resources.
Impact
An attacker can inject rendered HTML into blog comments, which may be abused to:
Embed arbitrary external images.
Embed supported media elements.
Manipulate the appearance of comments.
Display misleading or deceptive content.
Cause users' browsers to make requests to third-party servers (potential privacy implications).
Reduce the effectiveness of the application's HTML sanitization controls.
While this does not appear to result in JavaScript execution, it still represents improper output sanitization and enables stored HTML injection.
Root Cause
The HTML sanitization policy removes many dangerous tags but does not completely restrict HTML capable of rendering external resources. The filtering logic relies on a partial allow/block list rather than ensuring only explicitly safe formatting elements are permitted.
Remediation
Escape HTML by default before rendering comments.
If HTML formatting is required, implement a strict whitelist allowing only safe formatting tags (e.g., <b>, <i>, <strong>, <em>, <code>).
Remove or sanitize tags capable of embedding external resources, including <img>, <video>, <audio>, <iframe>, <object>, <embed>, and similar elements.
Use a well-maintained HTML sanitization library with a restrictive allowlist configuration.
CWE
CWE-79 – Improper Neutralization of Input During Web Page Generation (HTML Injection / Stored HTML Injection)
Severity
medium
The issue does not appear to allow JavaScript execution or account compromise, but it enables stored HTML injection that can be used to embed external resources and manipulate the presentation of blog comments. Depending on the allowed elements, it may also facilitate social engineering or privacy-impacting resource loads.