Executive summary

On 27 February 2026 a reflected Cross-Site Scripting (XSS) vulnerability affecting the Porto WordPress theme (versions ≤ 7.6.2) was published and tracked as CVE-2026-28075. The vulnerability is reflected XSS with a medium severity (CVSS 7.1). It can be triggered without authentication and may be exploited by tricking a victim — including administrators — into visiting a crafted URL or clicking a malicious link. Successful exploitation can lead to session theft, content manipulation, credential harvesting, or forced actions performed as the victim.

If your site runs the Porto theme (or includes Porto-derived code), treat this as urgent: prioritise detection, temporary mitigations, and a permanent code fix. This advisory explains the vulnerability, why it matters, how to detect exposure or indicators of targeting, and practical mitigations including WAF-style virtual patches and secure developer fixes.

What is reflected XSS (brief primer)

Reflected XSS occurs when a web application accepts user-supplied input (GET/POST parameters, headers, or other request data) and reflects it in the server response without proper encoding or sanitization. An attacker crafts a URL containing script content in a parameter; when a victim opens that URL, the payload runs in the victim’s browser under the site’s origin.

Key attributes:

• Attacker crafts a URL containing payload.
• Victim must open the URL (social engineering).
• Attack is executed immediately (reflected) — payload is not stored on the server.
• Impact depends on victim role and what the page context exposes (cookies, tokens, DOM).

Why this Porto vulnerability is important

• Affected versions: Porto theme ≤ 7.6.2.
• CVE: CVE-2026-28075.
• CVSS: 7.1 (medium).
• Required privilege: unauthenticated (anyone).
• User interaction: required (victim must click or visit crafted link).

Although user interaction is required, the fact that an unauthenticated attacker can craft these URLs and target administrators elevates the risk. If an administrator or editor is tricked into visiting a malicious link, consequences can include complete site compromise.

Real-world impact scenarios

Examples of how an attacker can leverage a reflected XSS:

• Session theft: Exfiltrate cookies or tokens accessible to JavaScript and impersonate users.
• Administrative takeover: If an admin visits a crafted URL while logged in, the attacker can execute privileged actions via DOM-driven requests.
• Content injection / defacement: Insert banners, ads, or malicious content visible to other visitors.
• Phishing / credential harvesting: Present fake login dialogs to capture credentials.
• Drive-by malware: Redirect visitors to malicious sites or attempt to exploit browser flaws.

Because Porto is a widely used commercial theme, targeted campaigns (e.g., phishing aimed at site staff) can scale quickly.

How to know if you are vulnerable or were targeted

1. Inventory: Confirm whether Porto is installed and check the active version. If ≤ 7.6.2 or using child themes that inherit vulnerable templates, assume exposure.
2. Logs: Inspect server logs for suspicious URLs with long query strings or parameters containing HTML/JavaScript fragments. Search for
3. Web server responses: In a safe test environment, supply a benign test string in query parameters and observe whether it is reflected without encoding.
4. WAF / security logs: Look for XSS-related alerts or increased 200 responses to requests that include suspicious parameters.
5. Content changes: Investigate unexpected content edits, new admin accounts, or file changes that could be an indicator of successful exploitation.

Note: Avoid using malicious payloads on production. Use sanitized, harmless probes or test in staging systems.

Immediate action plan for site owners

If you use Porto (≤ 7.6.2) or cannot confirm your site is patched, follow these steps in priority order:

1. Backup: Full site backup (files + database) before making changes.
2. Apply temporary mitigations:
   • Update Porto to a vendor-published fixed version if available.
   • If no patch is available, consider switching to a default WordPress theme (Twenty series) until a fix is released.
   • Remove or disable unused themes and plugins that could expose the vulnerable code.
3. Harden admin access:
   • Force administrators and editors to change passwords.
   • Enforce strong passwords and enable two-factor authentication (2FA).
   • Ensure cookies use HTTPOnly and Secure flags; set SameSite attributes where applicable.
4. Deploy a virtual patch (WAF rule): Use an application-layer firewall rule to block request patterns that attempt to reflect script-like content. See the examples below.
5. Audit and scan: Run malware scans and file-integrity checks; review logs for suspicious query strings and scanning activity.
6. Monitor: Increase monitoring and alerting for unusual admin logins, new admin accounts, or file changes.

Concrete WAF rules and virtual patches (examples)

Virtual patching with a WAF is useful when an official theme patch is not yet available. The examples below are for ModSecurity-style engines; adapt patterns for other WAFs or host/CDN rules. Test thoroughly on staging to avoid blocking legitimate traffic.

SecRule REQUEST_URI|ARGS|ARGS_NAMES|REQUEST_HEADERS "@rx (<|%3C)\s*(script|img|svg|iframe|object|embed|video|audio)" \
    "id:1000001,phase:2,deny,log,status:403,msg:'Reflected XSS - probable script tag in request',severity:2,t:none,t:urlDecodeUni"

SecRule ARGS|ARGS_NAMES "@rx (?i)(onerror|onload|onclick|onmouseover|onfocus)\s*=" \
    "id:1000002,phase:2,deny,log,status:403,msg:'Reflected XSS - event handler attribute in request',severity:2,t:none"

SecRule REQUEST_URI|ARGS "@rx (?i)(javascript:|data:text/html|document\.cookie|window\.location|eval\()" \
    "id:1000003,phase:2,deny,log,status:403,msg:'Reflected XSS - JS protocol or sensitive JS code in request',severity:2,t:urlDecodeUni"

SecRule ARGS|REQUEST_HEADERS|REQUEST_URI "@rx ((%3C)|(<))\s*([sS][cC][rR][iI][pP][tT])" \
    "id:1000004,phase:2,deny,log,status:403,msg:'Reflected XSS - encoded script tag',severity:2,t:urlDecodeUni"

Tips:

• Add exclusions for known legitimate endpoints that expect HTML fragments.
• Tune thresholds to avoid false positives (some legitimate inputs may include allowed HTML).
• Consider blocking overly long parameter values (> 2,000 characters) for endpoints that do not expect large inputs.

WordPress-specific adjustments:

• Block requests containing
  Review My Order

  0

  Subtotal

  Taxes & shipping calculated at checkout

  Checkout