Summary: A high-severity Local File Inclusion (LFI) vulnerability (CVE-2026-22344) was publicly reported affecting the FiveStar WordPress theme (versions ≤ 1.7). The vulnerability is exploitable by unauthenticated attackers and has a CVSS score in the high range. If your site uses this theme, act now: follow the detection and mitigation steps below to reduce risk while you await a vendor patch or switch themes.

Why this matters (short explanation)

Local File Inclusion (LFI) lets attackers instruct PHP to include local filesystem files and return their contents. When combined with weak permissions or other flaws, LFI may expose wp-config.php, API keys, and other secrets — and can lead to remote code execution (RCE) or full site takeover. The reported issue affects FiveStar (≤ 1.7) and is exploitable without authentication, so immediate mitigations are required for any affected site.

What we know (technical summary)

• Type de vulnérabilité : Inclusion de Fichiers Locaux (LFI)
• Affected software: FiveStar WordPress theme
• Affected versions: ≤ 1.7
• CVE: CVE-2026-22344
• Privilèges requis : Aucun (non authentifié)
• CVSS (reported): 8.1 (High)
• Reported disclosure date: February 2026

The root cause for LFI is usually insecure inclusion of files (include/require) using unsanitised input. Attackers may use directory traversal (e.g., ../../../../wp-config.php) or wrappers like php://filter to read or modify files.

Note: At public disclosure some distributions of the theme may not have an official patch available yet. That makes quick mitigation via configuration changes, theme removal, or virtual patching necessary.

Immediate risk to site owners

• Unauthenticated attackers can read sensitive files (e.g., wp-config.php) and steal database credentials or salts.
• LFI can be chained with file upload or write functionality to achieve code execution.
• Backups or other sensitive files exposed via LFI may leak secrets.
• Automated scanning and exploitation can begin rapidly after public disclosure.

Treat any site using FiveStar (≤ 1.7) as at risk until mitigations are applied.

Quick checklist — do this now (ordered)

1. Identifiez les sites affectés :
   • Dashboard: Appearance → Themes — check for “FiveStar” and version.
   • If you cannot log in, inspect the filesystem: wp-content/themes/fivestar/style.css or run:

     grep -R "Theme Name: FiveStar" -n wp-content/themes || true

2. Put the site into maintenance/read-only mode if possible, especially for sites handling sensitive transactions.
3. Take a complete backup (files + database) now and store it offline/offsite.
4. If FiveStar is active:
   • Deactivate the theme immediately and switch to a trusted theme (for example a WordPress default) until the issue is resolved.
   • Preserve any customisations offline before removing the theme folder.
5. If you cannot deactivate/remove the theme immediately:
   • Use a Web Application Firewall (WAF) or host firewall to block requests with LFI patterns (see defensive rules below).
   • Harden file permissions and remove world-writable files.
6. Rotate all sensitive credentials: WordPress admin passwords, database user passwords, and any API keys stored on the server. If wp-config.php may be exposed, rotate DB credentials immediately.
7. Scan for indicators of compromise (IOCs) — see detection section below.
8. If you detect active exploitation, put the site into containment and engage an incident response provider.

How to detect attempts and compromise (symptoms & logs)

Search webserver logs for LFI indicators:

• Requests containing traversal sequences like ../ ou des équivalents encodés (%2e%2e%2f).
• Paramètres contenant php://filter, données :, expect :, zip://, octet nul %00, or filenames such as /etc/passwd, wp-config.php.
• Repeated varied-path requests from the same IP.

Exemples de requêtes de journal :

grep -E "(%2e%2e|(\.\./)|php://|wp-config.php|/etc/passwd|%00|php%3A//)" /var/log/apache2/access.log*

grep -E "(%2e%2e|(\.\./)|php://|wp-config.php|/etc/passwd|%00|php%3A//)" /var/log/nginx/access.log*

Other signs:

• New/modified files you did not create (web shells often have short/random names).
• Utilisateurs administrateurs inattendus dans wp_users.
• Large data exports, DB dumps, or unusual DB queries.
• Modifié wp-config.php or new files in wp-content/uploads.
• CPU or network spikes at odd hours.

Defensive measures you can apply immediately (virtual patch / WAF rules)

Virtual patching at the edge is often the quickest mitigation when a vendor patch is not yet available. Below are defensive rules and examples to block common LFI exploitation patterns. These patterns must be tuned to avoid false positives — test on staging first where possible.

Generic blocking rules (conceptual)

• Deny requests containing path traversal indicators: ../, ..%2f, ..%5c, or double-encoded equivalents.
• Block references to sensitive filenames: wp-config.php, /etc/passwd, /proc/self/environ, .env, backup patterns (.sql, .zip, .tar.gz, .bak).
• Block protocol wrappers: php://, données :, zip://, expect://, fichier://.
• Block null byte sequences (%00).
• Block absolute path indicators (e.g., /var/www/, C:\).

Example ModSecurity rule snippets (defensive)

Use these as a starting point and adapt to your environment:

# Block typical path traversal with file names
SecRule ARGS|REQUEST_URI "@rx \.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c" \
    "id:1001001,phase:2,deny,status:403,msg:'Blocked path traversal attempt',log"

# Block access to wp-config.php, /etc/passwd, and other sensitive files via parameters
SecRule ARGS|REQUEST_URI "@rx (wp-config\.php|/etc/passwd|/proc/self/environ|\.env|\.sql|\.bak|\.tar\.gz|\.zip)" \
    "id:1001002,phase:2,deny,status:403,msg:'Blocked sensitive file access attempt',log"

# Block protocol wrappers in input
SecRule ARGS|REQUEST_URI "@rx (php://|data:|expect://|zip://|file://)" \
    "id:1001003,phase:2,deny,status:403,msg:'Blocked protocol wrapper in request',log"

# Block null byte injection
SecRule ARGS|REQUEST_URI "@contains %00" \
    "id:1001004,phase:2,deny,status:403,msg:'Blocked null byte in request',log"

Nginx location-based blocking (nginx.conf)

Simple Nginx snippet to reduce obvious exploit attempts — test carefully to avoid disrupting legitimate traffic:

# inside server block
if ($request_uri ~* "(?:\.\./|%2e%2e%2f|php://|/etc/passwd|wp-config\.php|%00)") {
    return 403;
}

WordPress-level workarounds

• Remove or disable publicly accessible theme files that include other files based on request input.
• If the theme exposes an include endpoint (for example inc/load.php?file=...), remove or harden it: enforce a strict whitelist of allowed files and never include user input directly.

Server hardening and file permission recommendations

• Assurez-vous wp-config.php is not world-readable (for example chmod 640 with correct ownership).
• Prevent execution of PHP from wp-content/uploads:

<!-- Apache: place inside wp-content/uploads/.htaccess -->
<FilesMatch "\.(php|php5|phtml)$">
  Deny from all
</FilesMatch>

# Nginx:
location ~* ^/wp-content/uploads/.*\.(php|php5|phtml)$ {
    deny all;
}

• Avoid overly permissive permissions (no 777 directories).
• Consider disabling dangerous PHP functions (e.g., exec, shell_exec, système) with caution — this can break legitimate code.

How to safely remove the theme and preserve customizations

1. Backup the theme folder:

   cp -a wp-content/themes/fivestar /root/offline-backups/fivestar-2026-02-12

2. Switch to a default theme (Dashboard or WP-CLI):

   wp theme activate twentytwentyone

3. Delete the vulnerable theme:

   rm -rf wp-content/themes/fivestar

4. Move any custom files to a safe location and review them for unsafe include() usage before reuse.

Evidence of exploitation — common IOCs

• Obfuscated PHP or base64 payloads in wp-content/uploads, wp-content/themes/*/, or site root.
• Web shells (small PHP files with eval/base64/etc.).
• Comptes administrateurs inattendus.
• Suspicious cron jobs or unexpected WP-Cron entries.
• Outbound connections to unknown IPs/domains from the webserver.

Incident response: if you suspect a compromise

1. Isolate: Take the site offline or block external traffic at the host/cloud level.
2. Preserve: Collect logs (access/error), database dump, and a filesystem snapshot for forensics.
3. Rotate credentials: DB credentials, API keys, admin passwords — generate new keys and revoke old ones.
4. Nettoyer ou restaurer :
   • Restore from a known-good backup if available.
   • If not possible, perform full malware cleanup: remove web shells, inspect PHP files, and rebuild from pristine sources.
5. Rebuild servers if attackers had shell access or if persistent backdoors are found.
6. Hunt for persistence: check mu-plugins, modified wp-config.php, altered .htaccess, or scheduled tasks.
7. Communicate with stakeholders and comply with any disclosure or breach notification obligations.
8. After cleanup, implement hardening and monitoring described in this guide.

Long-term remediation and prevention

• Replace or update the vulnerable theme. If the vendor issues a patch, test and apply it quickly.
• If you cannot rely on the vendor, remove the theme and migrate to a supported alternative.
• Gardez le cœur de WordPress, les thèmes et les plugins à jour.
• Adopt layered defenses: WAF/edge filtering, file integrity monitoring (FIM), regular malware scans, and offsite encrypted backups.
• Use least-privilege for DB users and enforce strict file permissions.
• Conduct periodic security audits and maintain an asset inventory of theme/plugin versions.

How teams can respond quickly (virtual patching and monitoring)

Security teams and hosts should deploy targeted blocking rules at the edge to reduce the attack surface while awaiting a vendor patch. Combine virtual patches with file-scanning and monitoring to detect attempts early. Always test rules to minimise false positives.

How to test if your WAF / rules are blocking exploit attempts

• Use a safe staging environment with the vulnerable theme and send non-destructive test requests containing traversal sequences to verify blocking.
• Do NOT execute exploit code against production systems — use isolated testing only.
• Check logs for blocked entries (HTTP 403) and review false positives to avoid breaking legitimate functionality.

Recommended scanning and monitoring cadence

• Daily: automated malware scan, WAF rule health check, and backups.
• Weekly: log review and integrity checks for critical files.
• Monthly: vulnerability scan of themes/plugins, review maintenance status of third-party code, and a permissions audit.
• After any security event: forensically review logs and add WAF signatures discovered during the incident.

Si vous observez ces motifs, escaladez immédiatement à la réponse aux incidents.

Q: Can a site be exploited if FiveStar is installed but not active?

A: Risk is reduced if the theme is inactive because many theme files are not executed. However, publicly accessible files in the theme may still be reachable. The safest action is to remove vulnerable theme files entirely if not in use.

Q: Will removing the theme break my site?

A: If the theme is active and removed without switching, WordPress will fall back to a default theme. Switch themes before removal and export customisations first.

Q : Un WAF est-il suffisant ?

A: A WAF is an important layer for virtual patching, but it is not a substitute for patching, secure configuration, and full remediation if a compromise has occurred.

Practical “how to” — commands and checks

# Check theme header for version
head -n 40 wp-content/themes/fivestar/style.css | sed -n '1,40p'

# Search logs for suspicious attempts
zgrep -iE "(\.\./|%2e%2e%2f|php://|wp-config\.php|/etc/passwd|%00)" /var/log/nginx/access.log* /var/log/apache2/access.log*

# Backup example
mysqldump -u wpuser -p wordpress_db > /root/backups/db-$(date +%F).sql
tar -czf /root/backups/wwwroot-$(date +%F).tgz /var/www/html

# Find recently changed PHP files (last 7 days)
find /var/www/html -type f -name '*.php' -mtime -7 -print

If you host multiple sites — scale your response

• Apply pattern-based blocking across your fleet to block known LFI patterns.
• Prioritise sites using the vulnerable theme for immediate review and backups.
• Maintain an asset inventory with theme/plugin versions to identify exposed sites rapidly.
• Automate alerts for anomalous request patterns matching LFI indicators.

A short note on responsible disclosure and updates

After public disclosure, attackers often scan quickly. If you are waiting for vendor patches, virtual patching and proactive hardening are the safest interim measures. If you are the theme developer or can contact the developer, provide reproduction details privately and insist on a timely patch.

Final words — prioritise and act now

This LFI is high-risk because it is unauthenticated and can expose files needed for full site control. If you run FiveStar (≤ 1.7), do not delay:

1. Sauvegardez immédiatement.
2. Deactivate or remove the vulnerable theme where possible.
3. Apply edge-level blocking rules and harden file permissions.
4. Scan for compromise and rotate credentials.
5. Replace or rework customisations if vendor patching is slow.

If you need a tailored checklist or example rules for your environment (Apache, Nginx, or cloud WAF), reply with your server type and access details and we will provide adapted, safe examples.