Stored Cross-Site Scripting (XSS) Vulnerability Report

---

Vulnerability ID: ZBX-CONTACT-STORED-XSS-001
Severity: Critical (CVSS 8.9 - AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:L)
Component: /contact - Contact Us Form
Application: www.zabbix.com
Date Discovered: 2026-07-26
Reporter: Authorized Penetration Tester

---

1. Summary

The contact form on Zabbix's publicly accessible /contact page is vulnerable to Stored Cross-Site Scripting (XSS). User-supplied input fields — specifically Company name, First name, Last name, Job title, and Request — are not sanitized or encoded server-side before being persisted and subsequently rendered. When the Zabbix team views the submitted data (e.g., via an internal admin panel, email notification, or ticketing system), the injected payload executes in the context of the viewer's browser session.

Both JavaScript-based XSS and generic HTML injection were confirmed as working against the form.

---

2. Steps to Reproduce

2.1. XSS via <img> onerror (JavaScript Execution)

1. Navigate to https://www.zabbix.com/contact.

1. Locate the Contact Us form.

1. Inject the following payload into the Company name field (or any other text input field):
    
    
    <img src=0 onerror=alert(1)>
2. Fill remaining required fields with benign data.

1. Complete the Captcha challenge.

1. Submit the form.

1. (Simulated server-side) When a Zabbix administrator or support agent views the stored submission (email preview, admin dashboard, or CRM system), the script executes, producing an alert(1) dialog.

2.2. HTML Injection via <a> Tag

1. Repeat the process, injecting the following into the Request textarea:
    
    
    <a href=https://google.com>google.com</a>
2. On submission and subsequent rendering by the reviewing party, the raw HTML anchor tag is rendered in the browser, confirming that no HTML encoding is applied on the backend.

---

3. Technical Impact

 

---

4. Root Cause

The backend endpoint (/contact or its associated form handler) does not perform:

• Output encoding / contextual escaping before storing or rendering user-supplied values.
• Server-side input validation to strip or neutralize HTML/JavaScript.
• Content-Security-Policy (CSP) headers strict enough to block inline event handlers like onerror.

The form is rendered server-side (or forwarded via email in HTML format), and the raw input is included without sanitization.

---

5. Proof-of-Concept Payloads

 

---

6. Affected Fields

• Company name
• First name
• Last name
• Job title
• Business email address (partial — less likely to be rendered as raw HTML, but should still be validated)
• Request (textarea)
• Country / Territory

---

7. Remediation Recommendations

Critical (Immediate)

1. Server-side Output Encoding - Encode all user-supplied values using context-appropriate escaping (HTML entity encoding) before storage and before rendering in any email, admin panel, or web page:

• • & → &
  • < → <
  • > → >
  • " → "
  • ' → '

1. Input Validation - Reject or strip any HTML tags from text fields where plain text is expected. Use a server-side allowlist approach.

1. Implement Content-Security-Policy (CSP) - Deploy a strict CSP header on the contact page and any admin-facing interfaces that render submitted data:
    
    
    Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';
   Avoid 'unsafe-inline' and 'unsafe-eval' in production.

Recommended (Defense-in-Depth)

1. Use a Template Engine with Auto-Escaping - If the backend uses email templates (e.g., PHP, Node.js, Python), ensure auto-escaping is enabled by default and explicitly mark only trusted variables as safe.

1. Sanitize with an Allowlist Library - Use a well-maintained library such as OWASP Java HTML Sanitizer, DOMPurify (server-side), or Bleach (Python) on any field that legitimately requires limited HTML.

1. Audit Admin/Email Pipeline - Review how submitted form data flows from the web server to internal dashboards, email inboxes, and ticketing systems. Every point where raw input is rendered is an attack surface.