Podcast Brief: The HTML Sanitiser Flaws Your Web Tools Are Hiding From You
Four critical vulnerabilities in a single HTML sanitisation library. A prototype pollution flaw in a spreadsheet utility. All published within 24 hours, all scoring 9.4 or above on the CVSS scale. That is the data for this week’s brief.
No vendor is selling you a product to fix these. No consultancy is writing a white paper about them yet. They are just sitting in the NVD, waiting for someone to check.
Let us look at what the intelligence actually says.
The justhtml Cluster: Four CVEs, One Library
CVE-2026-5388, CVE-2026-7808, CVE-2026-8445, and a related disclosure affecting versions up to 1.16.0 all concern the same Python HTML sanitisation library: justhtml. Each scores CVSS 9.8. They were published by NIST on 23 August 2026.
The nature of the flaws is worth understanding. These are not abstract bugs. They describe specific, known attacker techniques.
CVE-2026-5388 covers sanitisation bypasses in URL helpers and Markdown passthrough. Encoded javascript: URLs, backslash-based relative URLs that resolve as remote hosts, raw </textarea> tags surviving through Markdown rendering. These are classic cross-site scripting evasion techniques. They survive sanitisation not because the library is careless, but because edge cases in parsing and serialisation are genuinely hard to close.
CVE-2026-7808 covers a different attack surface: mutating or reusing policy objects, and mixed-case tag names. A sanitiser that rejects <script> may pass <ScRiPt> if the tag name comparison is case-sensitive. This is a decades-old bypass. Its presence in a library at CVSS 9.8 in 2026 is not surprising. It is depressing.
CVE-2026-8445 is arguably the most instructive. The to_markdown() conversion function fails to escape angle brackets in text nodes. Content that is safe in HTML output, including entity-decoded text and content from <title> or <textarea> elements, can be emitted as raw HTML in Markdown output. The sanitiser bypass is not in the sanitiser. It is in the downstream conversion.
The pattern across all three: complexity creates surface area. Every additional feature, every conversion path, every configuration option is a potential bypass route. The default usage path is safer. Advanced usage is where the vulnerabilities cluster.
For a small business, the immediate question is not “do I understand these CVEs.” It is: does any software I run, or any software my suppliers run on my behalf, use justhtml? If the answer is yes, and the installed version is below 1.16.0, the library needs updating.
exceljs-hardened: Prototype Pollution in a Spreadsheet Tool
CVE-2026-78207 concerns exceljs-hardened before version 5.0.0. CVSS 9.4. Published 24 August 2026.
The vulnerability is in the deepMerge helper function. When the library processes cell notes in spreadsheet files, it merges JSON objects. The deepMerge function fails to reject __proto__, constructor, or prototype keys. An attacker who can supply a crafted spreadsheet file with a malicious __proto__ property in a cell note can modify Object.prototype, affecting every plain object created in that Node.js process.
Prototype pollution is not a new class of vulnerability. It has been documented in JavaScript environments for years. Its presence here at CVSS 9.4 reflects the severity of what it enables: arbitrary property injection into all objects in the process, with potential paths to remote code execution depending on how the application uses those objects downstream.
The practical attack scenario for a small business: a malicious Excel file uploaded to a web form, processed by a Node.js application using exceljs-hardened below 5.0.0. The uploader does not need credentials. They need access to a file upload field.
The fix is version 5.0.0 or above.
What the Data Does Not Say
The NVD entries do not confirm active exploitation of any of these CVEs. They are not on the CISA Known Exploited Vulnerabilities catalogue at time of publication.
That matters. High CVSS scores are a measure of theoretical severity, not of observed attacker behaviour. A CVSS 9.8 vulnerability that nobody is exploiting is a different operational priority from a CVSS 6.0 vulnerability that ransomware groups are actively using.
The absence from the KEV catalogue does not mean ignore these. It means calibrate. Patch the affected libraries. Do not panic-buy monitoring tools because a vendor cited these CVEs in a campaign email.
How to Turn This Into a Competitive Advantage
Most small businesses have no visibility into their software supply chain below the application layer. They know they use a CRM. They do not know what libraries that CRM’s web interface uses for HTML rendering or spreadsheet export.
That gap is a risk. It is also, if closed, a differentiator.
Businesses that can answer “we audit our third-party software dependencies and have a process for responding to CVE disclosures” are increasingly attractive to larger clients and procurement teams. Supply chain security questions are appearing in tender documents that did not include them two years ago. Having a credible answer, backed by evidence, is a commercial advantage.
It does not require a security operations centre. It requires a software inventory and a process for checking it against NVD disclosures.
How to Sell This to Your Board
Three arguments that will hold up.
First: the attack surface is not what the board thinks it is. The perimeter is not the firewall. It is every library in every application the business runs, including applications managed by third parties. These CVEs demonstrate that a widely used HTML sanitiser can carry four critical flaws simultaneously. The board needs to understand that software supply chain risk is not theoretical.
Second: the remediation cost here is almost zero. Version upgrades for open-source libraries cost engineering time, not licence fees. The cost of not doing it is a potential XSS compromise or prototype pollution leading to process-level code execution. Present that comparison plainly.
Third: regulatory exposure is real. A cross-site scripting vulnerability that results in a data breach involving personal data is a reportable incident under UK GDPR. The ICO does not distinguish between “we were hacked via a sophisticated attack” and “we were hacked via a known vulnerability that had a patch available.” The latter tends to generate more uncomfortable questions.
What This Means for Your Business
1. Audit your software stack for justhtml and exceljs-hardened this week. Ask your developer, your MSP, or your web hosting provider which libraries your applications use. If you receive a blank look, that is itself a finding worth acting on.
2. If justhtml is present, update to 1.16.0 or above immediately. Versions below this are affected by at least three of the four CVEs. Do not wait for a maintenance window.
3. If exceljs-hardened is present, update to 5.0.0 or above. If your application processes user-supplied spreadsheet files, treat this as urgent. An unauthenticated file upload path is a realistic attack vector.
4. Review your file upload controls. Any web form that accepts Excel or spreadsheet files should validate file type, restrict file size, and process uploads in an isolated environment where possible. This is good practice regardless of CVE status.
5. Subscribe to NVD notifications for libraries in your stack. NIST provides email and RSS feeds. This is free. It will tell you within hours when a library you use receives a critical CVE. There is no credible reason not to have this in place.
If you want to go further: a software bill of materials (SBOM) is a structured inventory of every component in your applications. It is not a complex undertaking for most small business stacks, and it is the foundation of any serious supply chain risk programme.
Before you go: if this brief was useful, follow the show wherever you listen. A rating or review genuinely helps others find it. Drop a comment with your thoughts, and if you know someone running a small business who should be across this kind of intelligence, send it to them. They will probably thank you for it.