XSS Vulnerability in the “Get a Quote” form while bypassing WordFence and CloudFlare

Reading Time: 5 Minutes

Introduction

While automated tools are useful for maintaining baseline security, they often miss sophisticated, multi-layered vulnerabilities that require a manual, strategic approach to uncover. At Black Hat Ethical Hacking (BHEH), our Red Team employs advanced manual testing, real-world attack simulations, and in-depth system analysis to uncover vulnerabilities that automated methods often overlook. This process highlights the importance of human expertise and creativity in identifying and exploiting complex weaknesses that could compromise even well-protected systems.

Executive Summary

During an external penetration testing, we uncovered a Cross-Site Scripting (XSS) vulnerability in the newly introduced “Get a Quote” form on the client’s website. This weakness allows malicious script injection via user input, which was not caught by existing defenses (including Wordfence and Cloudflare Web Application Firewall). As a result, an attacker could execute arbitrary JavaScript in the context of the website, potentially leading to session theft or site defacement. The finding underscores a significant security gap in a recent feature, warranting immediate remediation and improved defensive measures.

Security Lesson Learned: Even with multiple security layers like Wordfence and Cloudflare in place, only proper input validation and output encoding at the application level can effectively prevent XSS vulnerabilities.

The following report details each stage of the attack, the associated risks, and concrete remediation strategies.

Overview of the Issue Discovered

Weakness Type

CWE Reference: CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) – occurs when an application includes untrusted input in web pages without proper validation or escaping, allowing execution of attacker-supplied scripts in the victim’s browser.

• Weakness Type: Client-Side Code Injection
• Primary Risks:
  • Unauthorized execution of JavaScript in users’ browsers
  • Theft of session cookies and authentication tokens
  • Account hijacking, including admin takeover if targeted
  • Injection of malicious content (e.g. phishing forms, malware links)
  • Bypass of client-side/business logic (e.g. hidden form field manipulation)
  • Exposure of sensitive data via DOM-based access
  • Persistence through stored XSS in application logs or databases

Severity

High: XSS vulnerability in a publicly accessible form allows unauthenticated attackers to inject and execute JavaScript, bypassing Wordfence and Cloudflare protections, potentially leading to session hijacking, data exfiltration, and full account compromise (including admin access if targeted).

Base Score: 8.3 (High)

This vulnerability carries a CVSS v3 base score of 8.3 (High). The weakness type is improper input handling (CWE-79) that permits malicious client-side code injection via unsanitized parameters in an AJAX request, enabling attacker-controlled scripts to execute in user sessions and evade existing WAF defenses.

Affected Assets

• IPv4 Address: 192.x.x.x
• Hostname: Redacted
• System Type: Main Website with Contact Form

This discovery represents a high-severity security flaw due to the ability of unauthenticated attackers to inject and execute arbitrary scripts in the context of legitimate users, potentially compromising user sessions, stealing credentials, and undermining trust in the website’s integrity.

The vulnerability was identified in a recently deployed “Get a Quote” form that had not undergone prior security testing. During a manual examination, it was observed that this form processes user-supplied data (such as contact details or query parameters) without sufficient sanitization. The feature’s novelty meant it fell outside previous test coverage, and its implementation introduced an XSS flaw. In practical terms, an attacker is able to inject crafted JavaScript payloads through this form. The application then includes this unneutralized input in a web page response, enabling the code to execute in users’ browsers. The discovery highlights how new functionalities, if not rigorously tested, can inadvertently open severe security holes.

Impact and Risks

This issue is classified as a Cross-Site Scripting (XSS) vulnerability, specifically CWE-79: Improper Neutralization of Input During Web Page Generation. In this scenario, unsanitized user input submitted via the public “Get a Quote” form is reflected back into the application’s response without appropriate encoding, allowing client-side script execution within a victim’s browser. This flaw enables attackers to inject malicious JavaScript payloads, effectively altering the behavior of the page and performing actions on behalf of unsuspecting users.

What makes this vulnerability particularly dangerous is its stealthy nature and resistance to automated detection. Both Wordfence, a well-known WordPress security plugin, and Cloudflare’s WAF were in place and actively filtering malicious input — yet this XSS was not caught by either system. The payloads used in the attack were manually crafted and refined, encoded using Base64 obfuscation and alternate vectors (e.g., event attributes in HTML elements) to bypass standard WAF signatures. This type of targeted evasion is not typical of automated attacks and demonstrates a realistic, high-skill adversary scenario.

The vulnerability is unauthenticated, affecting a public-facing form and allowing external attackers to exploit users — including privileged sessions — without any prior access. If a user with administrative privileges interacts with a malicious submission (e.g., viewing quote requests from the backend or moderation panel), the attacker could potentially hijack the admin session and escalate privileges further within the application.

Given the context, the attack vector, the criticality of the impacted asset (a public production system), and the ineffectiveness of layered defenses in stopping the exploit, this vulnerability presents a high-severity business and technical risk.

Primary Risk Impacts

• Session Hijacking: Theft of user or admin session cookies can lead to unauthorized access to sensitive accounts.
• Privilege Escalation: If an administrator views a malicious payload, the attacker can gain elevated privileges and deeper access to the backend.
• Website Defacement or Content Injection: Scripts can alter visual elements, insert misleading information, or load external malicious resources.
• Data Exfiltration: User-submitted data (such as quote form content) can be harvested by attackers through injected JavaScript.
• Reputation Damage: Public compromise of a business-critical form can erode user trust and harm brand credibility.
• Security Control Evasion: Wordfence and Cloudflare WAFs were bypassed, demonstrating a breakdown in perimeter and application-layer defenses.
• Stealthy Persistence: Lack of alerts/logs due to WAF evasion increases dwell time and allows sustained exploitation without detection.

Key Considerations

• This was not a common or trivial XSS — the successful payload required manual analysis, payload tuning, and WAF bypass techniques.
• The attacker exploited parameters not previously evaluated in earlier assessments (e.g., country, action in AJAX POST).
• Traditional security tools and default configurations failed to identify or block the threat — indicating a gap in depth of protection.

Technical Description

Blue Team Perspective – Detection/Blocking Failures

From a defensive standpoint, the security controls in place did log and attempt to block some XSS injection attempts, but the malicious input ultimately slipped through. The site’s WordPress security plugin (Wordfence) and Cloudflare WAF were configured to filter common attack patterns. Initial test payloads – such as a simple <script>alert('XSS')</script> – triggered Wordfence’s rules and were blocked with HTTP 403 errors, indicating the WAF recognized the attack signature.

 

Blue Team Note: While baseline protections are active, the use of known XSS vectors was insufficient. WAF systems relying on static signatures often miss obfuscated or context-aware payloads. This block confirms Wordfence works on common strings but fails under evasion pressure.

However, the payload that was eventually used by BHEH’s Red Team was more complex and bypassed these filters. It appears the defensive systems were relying on signature-based detection, which was evaded by the obfuscation techniques employed (described below). Cloudflare’s cloud WAF also did not flag the payload, suggesting that its managed rules either were not aggressive enough or did not interpret the obfuscated script as a threat. The failure in detection highlights a gap in the Blue Team’s coverage: advanced or encoded XSS payloads were not accounted for in the current WAF rule sets, allowing the attack to proceed unhindered.

Despite Wordfence blocking the direct attack string, no alert or block was generated for the successful payload. The logs would show normal traffic for that request, meaning the attack flew under the radar. Cloudflare’s dashboard likewise did not register a WAF event for the bypass. In effect, the malicious request blended in with legitimate traffic.

Red Team Perspective – Exploitation via Obfuscated Payload

From the attacker (Red Team) perspective, exploiting this vulnerability required manual payload crafting and the use of Burp Suite for testing. Automated scanners did not flag the issue, likely because the injection point was an AJAX endpoint not covered by basic crawlers, and default payloads were getting blocked by the WAF. The tester used Burp Suite Intruder to systematically try different XSS payload variations, observing which requests were blocked and which got through.

 

Blue Team Note: Intruder output clearly highlights discrepancies in response status and size. This visual evidence shows the WAF did not normalize or decode payloads before inspection, allowing attacker-crafted inputs to slip through undetected.

Dozens of known XSS vectors (with varying encodings and syntaxes) were tested in the vulnerable field. Eventually, a payload was identified that slipped past Wordfence and Cloudflare filters. The winning payload involved base64 encoding parts of the script and leveraging a browser decoding function. For example, an <img> tag’s onerror attribute was used to execute eval(atob('YWxlcnQoJ1hTUycp')). In this construct, the actual attack code (such as alert('XSS')) is hidden in Base64 form. The browser’s built-in atob() function decodes the string at runtime, and eval() executes it. This two-step indirection meant that the literal text alert( or <script> never appeared in the request — bypassing signature-based filters.

Another variant used a <div style="background-image:url(javascript:…)"> CSS injection, exploiting how CSS url() can execute JavaScript in some contexts. The final working exploit combined these ideas to ensure the payload looked innocuous to defensive eyes but still executed in the browser.

 

Blue Team Note: This bypass is critical — not only did the WAFs fail to flag it, but the server logic also rendered the injected string back to the client without escaping. This means the application’s output encoding is not context-aware.

Client-Side Execution and Validation

Once the payload reached the server, the vulnerability in the application’s code took effect: the malicious input was included unsanitized in the response. The response for the AJAX request contained the injected snippet, which the browser then executed when rendering the update. In testing, this was confirmed by observing the expected proof-of-concept behavior (in this case, a JavaScript alert firing). The XSS fired successfully, proving that an attacker’s code can run on the site by exploiting this flaw.

 

Blue Team Note: This confirms both reflection and execution in the browser. Even if persistence is not achieved, this type of injection is highly useful for phishing, session hijacking, or pivoting to stored XSS depending on backend storage behavior.

Observed Behavior in Production UI

The final verification step was to observe how the injection behaved in the production web interface. The injected payload was passed through the backend and rendered as part of the dynamic dropdown for selecting ZIP codes based on country. No errors were logged or surfaced to the user. The response appeared normal (with the placeholder “Select zipcode”), while the XSS script executed silently.

Blue Team Note: Even UI elements like dropdowns are viable XSS attack surfaces if inputs are reflected directly. Defensive coding should never assume dropdowns, tables, or modals are “safe zones.” Validate and escape everywhere.

Key Technical Summary

• Target: Public “Get a Quote” form (AJAX backend: admin-ajax.php)
• Vulnerable Parameters: country, action
• Successful Payload: Obfuscated Base64 JavaScript within <img onerror=eval(atob(...))> or CSS-based url()
• Defense Bypassed: Wordfence (403 block on standard payloads only), Cloudflare (no alert or mitigation on obfuscated payloads)
• Execution Point: Response body of AJAX call rendered client-side by UI component
• Impact: Full execution of arbitrary JS in browser, exploitable for session theft, impersonation, or further lateral movement

Blue Team Final Takeaway: Manual testing exposed a significant gap in layered defenses. WAFs alone are not reliable barriers. Input validation, output encoding, CSP headers, and developer awareness are all essential components in preventing XSS — especially in new or rapidly developed features.

Steps to Reproduce

The following steps outline how to reproduce the XSS vulnerability using Burp Suite and a web browser. All sensitive details (e.g., domain names, cookies) have been redacted or replaced with placeholders for security. Only authorized testers should attempt this on a staging environment.

1. Navigate to the “Get a Quote” form page.
Open the target website’s Get a Quote page (e.g., https://[ClientSite]/get-quote/) in a browser. Prepare Burp Suite and configure your browser to use it as a proxy for intercepting requests.

2. Submit the form with interception enabled.
Fill in the form fields with test data. For the quote request to proceed, valid-looking values may be needed (e.g., a sample name, email, etc.). If the form dynamically loads data (for example, selecting a country triggers an AJAX request to load zip codes), ensure those actions are performed while interception is on.

3. Identify the vulnerable request.
In Burp’s Proxy > HTTP history, find the request associated with the form submission or dynamic loading. The vulnerable endpoint is an AJAX call to /wp-admin/admin-ajax.php with a parameter such as action=get_zipcodes.

POST /wp-admin/admin-ajax.php HTTP/2
Host: [ClientSite]
Content-Type: application/x-www-form-urlencoded

country=US&action=get_zipcodes
    

In this case, the country field is user-controllable. The server’s response is an HTML snippet (e.g., a list of <option> tags for zip codes), which makes it suitable for injection.

4. Attempt a simple XSS payload (for baseline).
Send the request to Burp Repeater and modify the country value to a basic XSS string, for example:

country="><script>alert('XSS')</script>&action=get_zipcodes

Then send the request.Expected result: The response is blocked by the server. Wordfence should return a 403 Forbidden and display a security warning. This confirms that the WAF is functioning as expected for obvious payloads.

5. Craft an obfuscated payload to evade the WAF.
Next, encode or obfuscate the payload. One proven method is to use a Base64-encoded JavaScript string decoded by atob():

<img src="x" onerror="eval(atob('YWxlcnQoJ1hTUycp'))">

When URL-encoded for transport, the payload becomes:

country=%3Cimg%20src%3Dx%20onerror%3D%22eval(atob('YWxlcnQoJ1hTUycp'))%22%3E&action=get_zipcodes

This hides the actual alert('XSS') within the Base64 string YWxlcnQoJ1hTUycp. The browser decodes and executes it, but to Wordfence/Cloudflare it does not resemble typical <script> or alert keywords.

6. Send the obfuscated payload.
Using Burp Repeater (or Intruder for automation), send the modified request with the encoded payload.Expected result: The response should return HTTP 200 OK and include normal form content (e.g., <option>Select zipcode</option>). No WAF error or block page should be present. In a real browser, this AJAX response will be rendered, and the malicious tag will execute silently, triggering the JavaScript.Note: For validation, copy the raw HTML response into a test page or use Burp’s embedded browser to observe execution.

7. Verify XSS execution in browser.
In a safe environment, simulate the front-end’s behavior after the payload is sent. If the form relies on client-side rendering of the dropdown, ensure the injected content appears and triggers.Expected behavior: The browser will process the payload, and a JavaScript alert should pop up (or any benign visible output confirming execution).

8. Redact and document evidence.
Capture screenshots of:

• The Burp request/response showing successful delivery
• Browser output showing the script execution

Ensure all sensitive information — such as cookies, IPs, or hostnames — is redacted before including them in any report.

By following these steps, the XSS vulnerability can be reliably reproduced, confirming that the “Get a Quote” form’s backend logic is susceptible to obfuscated input that bypasses existing WAF mechanisms. This also demonstrates the impact of allowing user-supplied content to be reflected unfiltered into the DOM.

Remediation

To fix this vulnerability and prevent similar issues, the development and security teams should implement multiple layers of defense. Key remediation actions are detailed below:

• Input Validation & Sanitization:
  Implement strict server-side validation for all input fields in the “Get a Quote” form (and across the site). The country parameter should only accept expected formats (e.g., country names or ISO codes). Enforce allow-lists and reject any input that deviates. For output in templates, use WordPress escaping functions such as esc_html(), esc_attr(), or wp_kses() to neutralize any injected script content.

• Output Encoding:
  Ensure all server responses, especially those returned via AJAX, are properly encoded according to context. If HTML is being returned, encode any dynamic values before insertion. As a safer alternative, consider switching to JSON-based responses and rendering elements with client-side JavaScript to reduce the risk of injection.

• WAF Rule Updates:
  Harden Wordfence and Cloudflare configurations. Enable Cloudflare’s Managed Rules for XSS with heightened sensitivity. Create custom WAF rules to detect evasion methods (e.g., javascript: in CSS or atob() in event handlers). Ensure Wordfence is fully updated and that any custom bypass rules are accounted for. Consider blocking common vectors like <img onerror> when not required.

• Content Security Policy (CSP):
  Deploy a strict CSP to prevent inline scripts, eval(), and javascript: URIs from executing. For example, use headers like:

  Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'none';

  This reduces the risk of successful exploitation even if injection occurs, by instructing the browser to ignore or block script execution.

• Server-Side Framework Protections:
  If the “Get a Quote” form is part of a plugin or theme, verify the component is up to date. If it’s custom-developed, audit the code for improper rendering of user input. Use WordPress best practices (e.g., wp_verify_nonce()) to enforce request origin and prevent CSRF. Avoid rendering any user input directly into markup unless it’s properly sanitized.

By implementing these remediation steps, the vulnerability can be fully mitigated and the application hardened against future XSS attacks. The objective is to treat all user input as untrusted and to apply defense-in-depth principles — ensuring that if one layer (e.g., WAF) fails, others (application logic, browser policies, framework-level protections) provide sufficient safeguards.

Lessons for the Defense Team

This incident provides several important lessons and takeaways for the defensive team:

• Don’t Rely Solely on WAFs:
  Web Application Firewalls like Wordfence and Cloudflare are helpful, but they are not foolproof. Skilled attackers can craft inputs that evade signature-based detection. It’s crucial to build security into the application itself (via secure coding practices), rather than assuming external tools will catch all malicious input.

• Security Testing for New Features:
  Any new feature — such as the “Get a Quote” form — should undergo a rigorous security assessment before and after deployment. In this case, the feature was introduced without prior penetration testing, which allowed a critical bug to reach production. Going forward, ensure all new code is reviewed for common vulnerabilities (e.g., XSS, SQLi), and integrate automated scans or dedicated security QA checks into the deployment pipeline.

• Regular Updates and Monitoring:
  Keep all security tools and components up to date. For example, Wordfence has had public bypasses (e.g., CVE-2019-9669), highlighting the need for ongoing patching and rule refinement. Monitor WAF logs proactively — a pattern of blocked requests followed by a successful similar request may signal a bypass attempt. Timely log reviews can help catch exploitation early.

• Defense in Depth:
  Use multiple, overlapping layers of security. If one layer fails, others should still protect the application. For XSS, this means combining input validation, output encoding, CSP headers, and behavioral monitoring. In this case, even though the WAF missed the attack, proper output escaping would have neutralized the exploit. Similarly, a strict Content Security Policy would have prevented script execution, even if injection succeeded.

• Blue Team and Red Team Collaboration:
  This outcome illustrates the importance of thinking like an attacker. Regularly perform adversarial simulations — either via internal red teams or external engagements — particularly for high-impact application functionality. The blue team can use findings from these tests to tune existing defenses (e.g., refining Wordfence or Cloudflare rule sets). Include training on modern obfuscation and bypass techniques so defenders recognize advanced attack signatures.

• Incident Response Preparedness:
  Although this was a simulated attack, a real adversary exploiting the same vector could have caused damage before detection. Ensure that your incident response plan includes coverage for web injection attacks. Implement monitoring for unusual admin actions, page or plugin changes, and session anomalies. Be prepared to revoke tokens or invalidate sessions quickly if a privileged user account is suspected of being compromised.

By learning from these lessons, the defense team can significantly improve the organization’s security posture. The goal is to minimize attackers’ windows of opportunity by catching vulnerabilities early, responding quickly, and layering defenses to mitigate both basic and advanced threats. The discovery in the “Get a Quote” feature should serve as a catalyst for tighter security practices across the board.

📍Enjoying this free Write-up?
If you’d like access to all future write-ups with new ones delivered every month, you can subscribe here to unlock full access.

All content is crafted and delivered by BHEH’s Red Team, straight from real-world Pentesting engagements.

Disclaimer: All actions described in this report were performed under strict ethical guidelines and with explicit written authorization from the client. Black Hat Ethical Hacking does not condone or take any responsibility for the misuse of the information contained herein. This write-up is intended solely for educational and professional reporting purposes. No details revealing the identity of the client, their infrastructure, or specific assets have been disclosed, ensuring full confidentiality and protection of client data.