All the vulnerabilities related to the version 1.0.2 of the package
sanitize-html is vulnerable to XSS through incomprehensive sanitization
sanitize-html
prior to version 2.0.0-beta is vulnerable to Cross-site Scripting (XSS). The sanitizeHtml()
function in index.js
does not sanitize content when using the custom transformTags
option, which is intended to convert attribute values into text. As a result, malicious input can be transformed into executable code.
Improper Input Validation in sanitize-html
Apostrophe Technologies sanitize-html before 2.3.1 does not properly handle internationalized domain name (IDN) which could allow an attacker to bypass hostname whitelist validation set by the "allowedIframeHostnames" option.
Improper Input Validation in sanitize-html
Apostrophe Technologies sanitize-html before 2.3.2 does not properly validate the hostnames set by the "allowedIframeHostnames" option when the "allowIframeRelativeUrls" is set to true, which allows attackers to bypass hostname whitelist for iframe element, related using an src value that starts with "/\example.com".
Sanitize-html Vulnerable To REDoS Attacks
The package sanitize-html before 2.7.1 are vulnerable to Regular Expression Denial of Service (ReDoS) due to insecure global regular expression replacement logic of HTML comment removal.
sanitize-html Information Exposure vulnerability
Versions of the package sanitize-html before 2.12.1 are vulnerable to Information Exposure when used on the backend and with the style attribute allowed, allowing enumeration of files in the system (including project dependencies). An attacker could exploit this vulnerability to gather details about the file system structure and dependencies of the targeted server.
PostCSS line return parsing error
An issue was discovered in PostCSS before 8.4.31. It affects linters using PostCSS to parse external Cascading Style Sheets (CSS). There may be \r
discrepancies, as demonstrated by @font-face{ font:(\r/*);}
in a rule.
This vulnerability affects linters using PostCSS to parse external untrusted CSS. An attacker can prepare CSS in such a way that it will contains parts parsed by PostCSS as a CSS comment. After processing by PostCSS, it will be included in the PostCSS output in CSS nodes (rules, properties) despite being originally included in a comment.