Nom du plugin	Learnify
Type de vulnérabilité	Inclusion de fichiers locaux
Numéro CVE	CVE-2025-60085
Urgence	Haut
Date de publication du CVE	2026-04-25
URL source	CVE-2025-60085

Critical Local File Inclusion in Learnify Theme (≤ 1.15.0) — Immediate Steps for WordPress Site Owners

2026-04-25 | WP‑Firewall Security Team

Résumé

A critical Local File Inclusion (LFI) vulnerability has been disclosed in the Learnify WordPress theme affecting versions ≤ 1.15.0 (CVE-2025-60085). The issue allows unauthenticated attackers to include and display local files from the webserver. The reported vulnerability has a high severity (CVSS 8.1) and can be exploited at scale — allowing attackers to leak sensitive files such as wp-config.php, environment files, or any readable server-side file. This can lead to credential disclosure, database compromise, and full site takeover depending on the environment.

If you run Learnify or sites that use it, read this post carefully. We explain what the vulnerability means, how attackers abuse it, how to detect signs of exploitation, and the step-by-step mitigation and incident-response process we recommend. We also show practical WAF rules and server hardening guidance to reduce the attack surface immediately.

---

Qu'est-ce que l'inclusion de fichiers locaux (LFI) ?

Local File Inclusion (LFI) is a class of vulnerability in web applications that occurs when user-controlled input is used to select and include files on the server without proper validation. In a PHP-based site, for example, this might look like:

• include($_GET['template']);
• require_once($_REQUEST['page']);

If an attacker can control the input that determines which file is included, they can point the application at arbitrary local files and force the server to read and output their contents. Common consequences:

• Disclosure of secrets (database credentials, API keys).
• Information gathering to prepare further attacks.
• In environments that allow dangerous wrappers (php://input, php://filter) or where remote file include is enabled, remote code execution (RCE) may be possible.

LFI can be exploited using simple traversal strings (../../../../) and wrapper techniques (php://filter) to read files safely in contexts where direct inclusion won’t print the file content.

---

Why this Learnify LFI is dangerous

Key facts about this incident:

• Affects Learnify theme versions ≤ 1.15.0.
• CVE: CVE-2025-60085.
• Privilège requis : aucun (non authentifié).
• CVSS: 8.1 (High).
• No official vendor patch is available at the moment (site owners must apply mitigations).

Why this particular LFI is a high-priority issue:

1. Unauthenticated: An attacker does not need credentials to attempt exploitation.
2. Easy to automate: LFI checks can be run by automated scanners across thousands of sites.
3. Sensitive target files: WordPress stores database credentials and salts in wp-config.php, making this file a prime target.
4. Chainability: LFI can be chained with other misconfigurations (weak file permissions, writable plugin/theme directories, dangerous PHP wrappers) to escalate to RCE or persistent backdoor installation.

Because of these factors, sites running the vulnerable Learnify versions should act immediately.

---

Technical details (how attackers typically exploit LFI)

While the exact vulnerable parameter name may vary between theme versions, the exploitation pattern for LFI follows common steps. Below we explain the general method an attacker would use — so you can recognize and defend against it.

1. Finding the entry point
   – The attacker looks for theme files that call inclure, exiger, fichier_get_contents, or similar functions with variables influenced by GET/POST/cookie values.
   – Example risky pattern: include( $theme_dir . '/' . $_GET['tpl'] );
2. Path traversal
   – The attacker submits payloads containing traversal sequences:
       – ../../../../etc/passwd
       – ../../../../wp-config.php
   – Many servers prevent reading files by returning errors when including binary files. Attackers then use wrappers.
3. Using wrappers to read files (common technique)
   – php://filter/convert.base64-encode/resource=path/to/file — applies a filter to base64-encode a file when included, making it printable in responses.
   – Example payload:
       – ?tpl=php://filter/convert.base64-encode/resource=../../../../wp-config.php
4. Null byte and encoding tricks
   – On older PHP and server setups attackers may use null byte (%00) truncation to bypass suffix checks. Many modern versions mitigate this, but it’s still a common payload in automated scans:
       – ?tpl=../../../../wp-config.php%00
5. Post-exploitation steps
   – If wp-config credentials are found, attacker uses them to access database or to create an admin user, upload backdoors, or exfiltrate additional secrets.
   – If file uploads are accessible and not sanitized, attacker may upload PHP shells and gain RCE.

A responsible disclosure noted that the Learnify theme’s inclusion logic failed to properly sanitize user-provided paths, enabling the above techniques.

---

Example indicators and malicious request patterns to look for

Check your web server logs and WAF logs for requests containing these patterns:

• php://filter/convert.base64-encode/resource=
• ..%2F..%2F ou ../ repeated (path traversal)
• %00 or null byte encoded attempts
• Requests to theme PHP files with unusual query strings like ?tpl=... ou ?page=... (check any parameter that looks like it selects a template)
• Long base64 strings in responses (indicates file contents encoded and returned)

Sample suspicious request line:

GET /wp-content/themes/learnify/somefile.php?template=php://filter/convert.base64-encode/resource=../../../../wp-config.php HTTP/1.1

If you see this pattern, treat it as high-priority — immediately isolate and investigate.

---

Immediate action checklist (what to do in the first hours)

If you operate a site using Learnify ≤1.15.0, perform the following actions right away:

1. Take the site into maintenance mode (if feasible) or apply temporary access controls (IP allowlists) to reduce exposure.
2. Switch to a clean theme (WordPress default) or remove the vulnerable theme from public-facing directories. Do not leave the vulnerable theme active.
3. If a patched theme version is published, apply the update immediately. If no official patch exists yet, proceed with the mitigations below.
4. Put a WAF rule in place (virtual patching) to block requests that contain traversal sequences or wrapper uses (see example rules in the “WAF rules” section).
5. Change WordPress database password and any service credentials that may be stored in wp-config.php and other configuration files — but only after you have ensured backups and integrity checks, since compromise may persist.
6. Rotate secret keys and salts in wp-config.php after remediation.
7. Scan the site for webshells, suspicious files and modified timestamps.
8. Restore from a verified clean backup if you detect compromise.
9. Increase monitoring: enable file integrity monitoring, audit logs, and alerting.

If you do not have the technical capability to perform all steps, contact your hosting provider or a security team and provide them with the indicators you’ve found.

---

How to detect whether your site has been exploited

Even if you close the vulnerability, you must verify whether it was exploited earlier.

Vérifiez pour :

• Nouveaux fichiers ou fichiers modifiés dans wp-content/uploads, wp-content/thèmes, Contenu wp/plugins, ou d'autres emplacements inattendus.
• New admin users in WordPress (check utilisateurs_wp la table).
• Suspicious scheduled tasks (cron jobs) or unauthorized cron entries in the database.
• Outbound connections from the server to unknown IPs (check firewall/host logs).
• Unexpected high CPU/IO usage or spikes in traffic.
• Unusual database queries in slow query logs or queries using previously unseen accounts.
• Unknown PHP files or encoded scripts containing évaluer, base64_decode, ou gzinflate.

Recommended tools:

• Server-level file integrity checks (tripwire-style).
• WordPress security scanners (prefer ones that provide code-level scanning and heuristics).
• Full malware scan of files and database content.
• Manual review of critical files (wp-config, .htaccess, index.php in plugin/theme folders).

If you find evidence of compromise, follow the incident response steps in the next section.

---

Réponse aux incidents : manuel étape par étape

If you confirm exploitation, proceed as follows:

1. Contenir
   – Take the site offline or block traffic to prevent further damage.
   – Revoke compromised credentials and API keys.
   – Isolate the server from the network if possible.
2. Préserver les preuves
   – Backup logs (web server, database, application logs) and disk images.
   – Do not overwrite logs — preserve timestamps for forensic analysis.
3. Éradiquer
   – Remove all discovered backdoors, shells, and malicious scripts.
   – Reinstall WordPress core, plugins, and themes from clean sources.
   – Rebuild servers from images if server-level persistence is suspected.
4. Récupérer
   – Restore from a clean backup (taken before the compromise).
   – Apply all available security patches and hardening measures.
   – Change all passwords and rotate keys and salts.
5. Post‑Recovery
   – Strengthen monitoring and logging.
   – Conduct a post-mortem: how did the compromise occur? Which controls failed?
   – Educate the team and update your incident response plan.
6. Notifier
   – Notify stakeholders, hosting provider, and, if required in your jurisdiction, customers or regulators.

---

Hardening recommendations to reduce LFI risk

Even after immediate mitigation, adopt these long-term defenses:

1. Principe du moindre privilège
   – Ensure file and directory permissions are minimal. Most WordPress files should be readable by the web server but not writable, except wp-content/uploads which needs write access only for uploads.
   – Database accounts used by WordPress should only have necessary privileges.
2. PHP configuration
   – Disable autoriser_inclusion_url.
   – Disable unused wrappers if possible.
   – Utilisez open_basedir to restrict PHP’s access to directories.
   – Disable exécutif, shell_exec, passage, système if not required.
3. Disable the built-in plugin and theme editor
   – Add to wp-config.php:
   définir('DISALLOW_FILE_EDIT', vrai);
définir('DISALLOW_FILE_MODS', vrai); // restricts plugin/theme installations/updates from WP admin
4. Secure uploads
   – Prevent direct execution of PHP files in wp-content/uploads by adding server rules (see example .htaccess/nginx block below).
5. Use strong, unique salts and keys (rotate on remediation)
   – Changing keys will invalidate active authentication cookies — useful after an incident.
6. Sauvegardes régulières et tests de restauration
   – Keep frequent backups offsite and test restorations regularly.
7. Use staged upgrades and code review
   – For themes/plugins in active development, review third-party code or restrict usage until security posture is verified.

---

Règles WAF pratiques et atténuations au niveau du serveur

Virtual patching (WAF) can buy time when an official patch is not yet available. Below are example rules you can use in common WAF systems or as webserver-level controls. Adapt and test carefully — incorrect rules can block legitimate traffic.

Important pattern detection to block:

• Any parameter value containing php://filter
• Any parameter containing multiple ../ séquences
• Null byte attempts %00
• Attempts to include files with sensitive filenames (wp-config.php, .env, /etc/passwd)

Example ModSecurity/Core Rule Language (CRS) style rule:

# Block common LFI attack signatures
SecRule REQUEST_URI|ARGS|ARGS_NAMES|REQUEST_HEADERS "@rx (?i)((\.\./)|(\.\.\\)|php://filter|php%3A%2F%2Ffilter|%00|/etc/passwd|wp-config.php)" \
    "id:1009001,phase:1,deny,status:403,log,msg:'Potential LFI attempt blocked',severity:2,tag:'LFI',tag:'OWASP_TOP_10_A03'"

Nginx location-based rule to deny php://filter or traversal attempts:

if ($request_uri ~* "(php://filter|%00|\.\./){1,}") {
    return 403;
}

Apache .htaccess effective snippet to block PHP execution in uploads:

# Protect uploads - prevent PHP execution
<Directory "/path/to/your/wp-content/uploads">
    <FilesMatch "\.php$">
        Require all denied
    </FilesMatch>
</Directory>

# Alternatively for .htaccess in uploads directory
<FilesMatch "\.php$">
    Order Allow,Deny
    Deny from all
</FilesMatch>

A more nuanced approach: block only suspicious requests, allow safe ones. Test rules on staging before applying in production.

---

How we at WP‑Firewall help (managed firewall + mitigation)

At WP‑Firewall we operate with an assumption: vulnerabilities will be discovered in themes/plugins. The fastest, least disruptive protection is virtual patching via a managed WAF that blocks exploit attempts in real time while you plan and apply permanent fixes.

Core protections we deliver and recommend:

• Managed WAF rules updated automatically in response to new disclosures — block exploit payloads (php://filter, traversal sequences, attempts to fetch wp-config.php) before they hit PHP.
• Malware scanning and signature detection to detect webshells and suspicious modifications soon after an exploitation attempt.
• File integrity monitoring and daily scans to detect unexpected file changes.
• Incident alerting and support to help triage findings and implement mitigations.
• Virtual patching capability so that even if a theme has no official patch, you can continue operations while risk is reduced.

We recommend pairing immediate virtual patching with the server hardening steps outlined above, rotating credentials, and implementing continuous monitoring.

---

Sample detection regex and log analysis tips

Keep a watch on webserver logs and implement alerts on these patterns:

Regex (case-insensitive) to detect likely LFI probes:

(?i)(php%3A%2F%2Ffilter|php://filter|(\.\./){2,}|(\.\.\\){2,}|%00|wp-config\.php|/etc/passwd)

Log entries triggering alerts:

• GET /wp-content/themes/learnify/… ?…=php://filter/convert.base64-encode/resource=../../../../wp-config.php
• Any requests using php:// enveloppes
• Requests that return 200 with base64-encoded strings — base64 in HTML pages is often an indicator of file content readouts.

Set up an automated job to scan logs daily for these patterns and notify administrators.

---

Example safe test to check for vulnerability (only for owners of the site)

If you are the site owner and need to test whether your Learnify installation is vulnerable, follow this safe, read-only check procedure. Do not attempt to exploit other people’s sites.

1. Use a non-destructive php://filter request that simply attempts to base64-encode a recognized file (e.g., readme.html in the theme directory).
2. Construct a request similar to:

GET /wp-content/themes/learnify/index.php?tpl=php://filter/convert.base64-encode/resource=inc/readme.html

3. If the response contains a base64 string that decodes to the file content, the function in that theme is vulnerable to inclusion pattern misuse. Stop testing and proceed to mitigation.

Important: Only test on sites you own or operate. Do not perform tests on third-party sites.

---

Remediation decision tree: Update vs Temporary mitigation vs Remove

• If an official patched theme is available: update immediately, then follow the verification checklist (file integrity scan, password rotations).
• If no official patch exists:
  • Remove the theme from active use (switch to a default theme).
  • Apply WAF rules and server restrictions to block exploitation attempts.
  • Work with the theme vendor for timeline or consider replacing the theme with a maintained alternative.
• If you cannot remove the theme for business reasons:
  • Put the site behind strict access controls (IP whitelist) for admin access.
  • Apply strict WAF rules and allow only minimal functionality.
  • Schedule dedicated monitoring and frequent integrity scans.

---

After remediation: validate and monitor

After applying fixes, validate your environment:

1. Re-run automated scanners.
2. Verify no unexpected admin accounts or scheduled tasks are present.
3. Check for unexpected network connections or DNS changes.
4. Review backups for early indicators of compromise (ensure backups are clean).
5. Continue heightened monitoring for at least 30 days after remediation.

---

Foire aux questions (FAQ)

Q: Can LFI lead to Remote Code Execution?

A: LFI itself is a file inclusion/read vulnerability. RCE may be possible if the attacker can include a file they can control (e.g., an uploaded PHP file) or chain the LFI with other misconfigurations (writable directories, dangerous wrappers, or malicious plugins).

Q: My site uses a child theme of Learnify — am I impacted?

A: Possibly. Child themes inherit core code from parent themes. If the vulnerable logic exists in parent theme code and the parent theme is Learnify ≤1.15.0, you are likely affected. Check the parent theme version and apply mitigations.

Q: I patched the theme — do I still need to rotate credentials?

A: Yes. If there is any chance the site was exposed, rotate keys, database passwords, and API tokens used on the site. Patching prevents future exploitation but does not remove compromises that occurred earlier.

Q: How can I be notified of similar vulnerabilities in future?

A: Subscribe to a trusted security feed and keep your WAF signatures and malware scanners updated. Implement automated vulnerability monitoring for installed themes and plugins.

---

Commencez à protéger votre site aujourd'hui — Plan gratuit disponible

If you want a straightforward, immediate layer of protection while you perform the technical remediation steps above, our managed free tier provides essential defenses for WordPress sites. The free plan includes a managed firewall with virtual patching, a web application firewall (WAF), malware scanning, unlimited bandwidth protection and mitigation for the OWASP Top 10 risks. Signing up is simple and fast — you can start blocking exploit attempts within minutes.

Learn more or register for the free plan here

Upgrade options: we also offer affordable paid plans that add automatic malware removal, IP blacklisting/whitelisting, monthly security reports, and advanced managed services for businesses and agencies. If you’re running multiple sites or require active remediation support, our higher-tier plans provide a complete, managed security approach.

---

Final thoughts from WP‑Firewall Security Experts

This Learnify LFI disclosure is a reminder that any theme or plugin can introduce critical weaknesses. The most important aspects of responding to incidents like this are speed and completeness:

• Speed to apply mitigations (virtual patching and temporary removal).
• Completeness in investigation (did the attacker get anything? what was accessed?).
• Long-term improvements (hardening, monitoring, least privilege).

If you need a partner that can manage virtual patching and provide continuous detection and response for your WordPress fleet, WP‑Firewall’s managed services are designed to do exactly that — protect traffic in real time, scan for post-exploit indicators, and help you recover with minimal business disruption.

If you manage multiple WordPress sites, now is the time to review your theme inventory, confirm versions, and apply the steps above. If you need help triaging specific indicators, we publish detailed remediation guides and provide support to customers who require accelerated assistance. Stay vigilant and treat any LFI probe as potentially serious — attackers automate these checks, and an exploitable site is at real risk.

---

Appendix A: Quick checklist (copy/paste)

• Identify if Learnify ≤ 1.15.0 is installed.
• Switch to a different theme or deactivate Learnify.
• Apply WAF rule(s) to block php://filter and path traversal attempts.
• Scan for webshells and unauthorized file modifications.
• Rotate DB credentials and WP salts.
• Restore from clean backup if compromise is detected.
• Implement file permission hardening.
• Activez la surveillance et l'alerte de l'intégrité des fichiers.
• Monitor logs for 30 days after remediation.

---

Appendix B: Additional resources and references

• CVE-2025-60085 (public advisory reference)
• PHP hardening best practices
• WordPress security handbook (site admin guide)
• WAF tuning and rule testing guide

(If you want help implementing specific WAF rules or running a safe vulnerability scan on your environment, our security team at WP‑Firewall can assist. We offer both self-service and managed options tailored to sites of all sizes.)

---

Thank you for taking security seriously. If you have questions about the steps above or want guidance specific to your site, reach out to WP‑Firewall support or sign up for the free plan to get immediate, managed protection: https://my.wp-firewall.com/buy/wp-firewall-free-plan/