Critical Advisory: Reflected XSS in “Auto-Install Free SSL” WordPress Plugin (≤ 4.5.0) — What Site Owners Must Do Now

Published: 1 May, 2026
Severity: Low (CVSS: 6.1)
Affected plugin: Free SSL Certificate Plugin, HTTPS Redirect, Renewal Reminder – Auto‑Install Free SSL
Vulnerable versions: ≤ 4.5.0
Patched in: 4.5.1
CVE: CVE-2024-13362

As a Hong Kong-based security researcher, I review and triage WordPress plugin vulnerabilities frequently. This advisory summarises a reflected Cross‑Site Scripting (XSS) issue found in the Auto‑Install Free SSL plugin (versions ≤ 4.5.0). Although classified as low severity, the vulnerability is unauthenticated and can be abused if an administrative user or other privileged user is lured into clicking a crafted URL.

Executive summary

• What happened: A reflected XSS vulnerability allows attacker-controlled input to be reflected into an HTTP response without proper encoding, enabling script execution in the victim’s browser.
• Who is affected: Any WordPress site with the plugin installed and active on public-facing sites running vulnerable versions.
• Impact: Session token theft, redirects to malicious pages, display of malicious content, or social engineering targeting administrative users. Full takeover is uncommon for reflected XSS alone but possible when chained with other weaknesses.
• Immediate fix: Update the plugin to 4.5.1 (or later). If immediate updating is not possible, deactivate the plugin or apply temporary mitigations to block exploit attempts.

What is reflected XSS and why it matters

Reflected Cross‑Site Scripting occurs when user-supplied input (e.g., a query parameter) is included in an HTTP response without proper escaping or encoding. The browser executes that input as script in the context of the vulnerable site.

For WordPress sites this is important because:

• XSS can be used to hijack sessions, capture credentials, or perform privileged actions if an admin clicks a malicious link.
• Even low-severity reflected XSS is useful to attackers for phishing, redirecting visitors, or delivering malware.
• Many attacks rely on social engineering — a single clicked link by an administrator can escalate to a broader compromise.

Technical analysis (high level, non-exploitative)

• The vulnerability is reflected — not persisted to the site database, but returned in the immediate response.
• It is unauthenticated — no login is required to send the crafted input.
• Likely cause: user input (e.g., a GET parameter or part of the request path) is echoed into page output without proper output encoding or sanitisation.
• Exploit requires user interaction — the victim must click a crafted link or submit a crafted form.

This is a typical output-encoding failure. Whitelisting expected values, escaping output, or stripping unexpected characters would have prevented the issue.

Real-world threats and likely attack scenarios

1. Targeted admin phishing: An attacker crafts a URL and tricks an administrator into clicking it. The injected script may exfiltrate cookies, tokens, or perform privileged actions via the admin session.
2. Mass scanning and redirection campaigns: The vulnerability may be discovered by scanners; unsuspecting visitors can be redirected to malware or ad farms.
3. Reputation damage / content injection: Malicious HTML could be reflected that displays deceptive content, harming trust and SEO.
4. Chained attacks: Reflected XSS can be combined with other misconfigurations to increase impact.

Immediate actions for site owners (0–24 hours)

1. Update the plugin: Apply the plugin update to 4.5.1 or newer immediately. This is the fastest and most reliable fix.
2. If you cannot update immediately:
   • Deactivate the plugin until you can apply the update.
   • Apply temporary server-level restrictions to the plugin endpoints (e.g., block access via .htaccess or nginx rules) where feasible.
   • Use a WAF or equivalent server-side filtering to block typical reflected XSS payloads (see rule examples below).
3. Protect privileged users: Require multi-factor authentication for administrators, enforce strong passwords, and temporarily reduce administrative exposure where possible.
4. Rotate credentials: As a precaution, rotate API keys and admin passwords if you suspect anyone clicked a malicious link.
5. Scan for signs of exploitation: Run full site scans (file integrity & content), inspect for unexpected admin users, unauthorized scheduled tasks, modified files, or suspicious uploads.

Recommended WAF / virtual patch rules (generic examples)

Temporary server-side filters can reduce risk while you update. These rules are generic patterns to detect common reflected XSS payloads — they should be tested on staging to avoid blocking legitimate traffic.

• Block requests containing script tags or encoded equivalents in query strings, POST bodies, or Referer headers. Patterns: , %3Cscript%3E, javascript:, onerror=, onload=, document.cookie, window.location, eval(.
• Block requests containing suspicious event handler attributes or javascript: scheme in user-supplied inputs.
• Block requests that send raw HTML/JS into parameters known to be reflected by the plugin.

# Block simple reflected XSS patterns in query string or request body (example)
SecRule ARGS|ARGS_NAMES|REQUEST_URI|REQUEST_HEADERS "@rx (

# Find query strings that contain likely XSS tags
grep -Ei "%3Cscript|

# Pseudocode: count blocked events per URI in WAF logs
cat waf.log | grep "XSS" | awk '{print $7}' | sort | uniq -c | sort -nr | head