WP with Spritz: Unauthenticated LFI Flaw (CVE-2018-25329) Threatens Servers

A single click is all it takes. That's all an attacker needs to read out the secret credentials of your database on a vulnerable WordPress website – with no password, no login, no special skills. This is precisely what a security flaw in the WordPress plugin WP with Spritz makes possible, a vulnerability the security platform Patchstack officially warned about on 3 August 2026. The flaw carries the identifier CVE-2018-25329 and is rated with a CVSS score of 8.1 (high). What makes it both remarkable and alarming: working attack code has been circulating publicly on the internet since April 2018 – and no patch exists, nor will one ever be released.

If you run this plugin on your website, you should read this article to the end and then act immediately. We'll explain in plain terms what exactly happens, whether you're affected, how to check in just a few minutes, and what you need to do right now.

What happened?

The WordPress plugin WP with Spritz in version 1.0 contains what's known as a Local File Inclusion vulnerability (LFI) – meaning the unauthorised inclusion of local files. Put simply: through a simple browser request, an attacker can make the server display arbitrary files that ought to be strictly protected.

The vulnerability is by no means new. Security researcher Wadeek discovered it back on 25 April 2018 and published a working proof-of-concept exploit on the well-known platform Exploit-DB (entry no. 44544). Despite this early discovery, the flaw only received an official CVE identifier on 17 May 2026, assigned by the company VulnCheck in the National Vulnerability Database (NVD) – the central, state-run US database for vulnerabilities. Patchstack, a provider specialising in WordPress security, followed on 3 August 2026 with its own warning, classifying the flaw as "High".

The plugin itself was already removed from the official WordPress.org plugin directory on 23 July 2020 – with the terse justification "Security Issue". Since then it has no longer been available for download there and is no longer maintained by the developer. Anyone still running it today is operating a digital wreck that no one is going to repair.

The technical background – explained clearly

The actual cause is a programming error in the file wp.spritz.content.filter.php. This file accepts a value called url, which can be passed directly in the browser, and forwards it completely unchecked to a PHP function that reads files. The problematic code reads:

if(isset($_GET['url'])){ $content = file_get_contents($_GET['url']); }

In plain terms: there is no validation, no filtering and no authentication. Whoever calls the address gets served whatever they ask for. An attacker exploits so-called path traversal sequences – character strings like ../ that allow them to move "upwards" through the server's file system. This gives them access, for example, to:

• /etc/passwd – a system file listing all user accounts on the server
• wp-config.php – the central WordPress configuration file, which stores database name, database user, database password and the secret WordPress security keys in plain text

Access to wp-config.php is the real worst-case scenario. Anyone who reads out this file holds the keys to your entire database – and thereby potentially to all customer data, orders, email addresses and password hashes stored there.

And it can get even worse: if the PHP setting allow_url_include is enabled on the server, the flaw can be escalated from a Local File Inclusion to a Remote File Inclusion (RFI). In that case the attacker can not only read local files but also load and execute their own malicious code from an external server – complete remote takeover of the server (Remote Code Execution, RCE).

Experts disagree on the exact severity but concur on the fundamental danger: Patchstack and Wordfence rate the flaw at 8.1 under CVSS 3.1, VulnCheck and the NVD at 8.7 under the newer CVSS 4.0, and WPScan even classifies it as critical at 9.1. Technically, the flaw falls under category CWE-98 (improper control of filename in PHP include statements) and is among the OWASP Top 10 risks – the official ranking of the most common and dangerous web vulnerabilities.

Who is affected?

Affected are exclusively WordPress websites on which the plugin WP with Spritz in version 1.0 is installed – regardless of whether it is active or deactivated. This is because the vulnerable file remains accessible via the web server even when the plugin is deactivated, and is therefore exploitable.

Exact installation figures are no longer available since the plugin was thrown out of the directory in 2020. The number is likely to be a manageable but by no means negligible one of legacy installations – typically on websites that have not been maintained for years. And that's precisely what makes it tricky: such neglected sites often harbour further security flaws as well.

Why is this particularly relevant for German SMEs? With a market share of roughly 41 to 43 percent of all websites worldwide (as of 2026, source: W3Techs), WordPress is by far the most widely used content management system – in Germany too. And many small and medium-sized enterprises run their website on the principle of "it works, doesn't it". That's exactly where such time bombs lie dormant.

How to check whether you're affected

The check takes just a few minutes. It's best to go through all the steps:

1. WordPress dashboard: Log in at yourdomain.de/wp-admin and open "Plugins" → "Installed Plugins". Search for "WP with Spritz". If it appears – active or inactive – you are affected.
2. File check via FTP/SFTP: Connect to your web server (or use your host's file manager) and check whether the directory /wp-content/plugins/wp-with-spritz/ exists.
3. Search directly for the vulnerable file: Check whether the file /wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php is present. It is the actual point of attack – even when the plugin is deactivated.
4. Review server logs: Search your Apache or Nginx access logs for calls to wp.spritz.content.filter.php, especially with the parameter url= and values like ../, etc/passwd, wp-config or external addresses (http://, https://). Such entries point to attack attempts that have already occurred.
5. Deploy a security plugin: Install a security plugin such as Wordfence Security (free version available) and run a full scan. Wordfence detects the flaw and explicitly reports CVE-2018-25329.
6. WPScan (for the technically savvy): Run wpscan --url https://yourdomain.de --enumerate p. WPScan reports the vulnerability under the database ID cdd8b32a-b424-4548-a801-bbacbaad23f8.

What you must do now

Since there is no patch and never will be one, there is only one truly effective measure: Remove the plugin completely. Don't weigh up whether you "still need it" – there is no such thing as secure operation of this version.

1. Deactivate and delete the plugin (urgent): Under "Plugins" → "Installed Plugins", deactivate "WP with Spritz" and then click "Delete".
2. Remove the directory manually: Connect via FTP/SFTP and delete the entire directory /wp-content/plugins/wp-with-spritz/ by hand. This ensures no remnants are left behind even if the uninstallation is faulty.
3. Rotate credentials (if compromise is suspected): If your logs show suspicious access, assume that wp-config.php has been read out. In that case, immediately change: (a) the database password in the hosting control panel, (b) the database credentials in wp-config.php, (c) all WordPress secret keys via the official generator at api.wordpress.org/secret-key/1.1/salt/ and (d) the administrator password.
4. Block the file immediately (stopgap if uninstallation isn't immediately possible): On Apache, add to your .htaccess: <Files 'wp.spritz.content.filter.php'> Require all denied </Files>. On Nginx: location ~* /wp-content/plugins/wp-with-spritz/wp\.spritz\.content\.filter\.php$ { deny all; return 403; }
5. Harden PHP: Make sure that in php.ini the values allow_url_include = Off and allow_url_fopen = Off are set. This prevents escalation to a remote takeover. If in doubt, ask your host.
6. Activate Patchstack or Wordfence: Patchstack has provided a virtual mitigation rule (RapidMitigate) that blocks attacks on protected websites. This complements the uninstallation but does not replace it.
7. Clean up: Take the opportunity to update all plugins and themes and remove extensions that are no longer maintained.
8. Regular audits: Run an automated vulnerability scan at least quarterly and subscribe to security newsletters such as the Patchstack Weekly.

Wordfence phrases the recommendation unambiguously:

"No known patch available. […] It may be best to uninstall the affected software and find a replacement." – Wordfence Intelligence (Defiant Inc.)

Context: why this needs to be taken seriously

One might object: but the flaw is from 2018, why the fuss now? Patchstack provides the answer in its current warning:

"This vulnerability is highly dangerous and expected to become exploited. Vulnerabilities like this one are used in mass-exploit campaigns. Attackers use these to attack thousands of websites at a time, regardless of traffic size or popularity." – Patchstack

In plain terms: attackers scan the entire web automatically and indiscriminately for vulnerable installations – the size or fame of your website plays no role. And the figures are alarming: according to Patchstack's "State of WordPress Security in 2026", a total of 11,334 new vulnerabilities were discovered in the WordPress ecosystem in 2025 – an increase of 42 percent over the previous year. 91 percent of them were in plugins. And the median time from the disclosure of a highly dangerous flaw to its first active exploitation is just five hours.

Whether CVE-2018-25329 is already being actively exploited on a large scale is unclear – according to SentinelOne, the EPSS probability is a low 0.03 percent. But with a trivially exploitable flaw, publicly available exploit and no authentication barrier, that could change at any time.

GDPR: this can get seriously expensive

For German website operators, the flaw has tangible legal dimensions. If an attacker uses the vulnerability to read out personal data – such as customer data from the database – this constitutes a personal data breach within the meaning of the GDPR. Several obligations follow from this:

• Notification obligation (Art. 33 GDPR): You must report the data breach to the competent state data protection authority within 72 hours.
• Communication obligation (Art. 34 GDPR): If there is a high risk to the data subjects (for instance in the case of exposed passwords or payment data), they too must be informed.
• Technical protection measures (Art. 32 GDPR): Anyone running a website with a plugin that has been known to be vulnerable since 2018 and is no longer maintained is in breach of the obligation to implement appropriate security measures. Supervisory authorities may deem this negligence.

The fines can be substantial: up to 10 million euros or 2 percent of worldwide annual turnover for inadequate security measures (Art. 83(4) GDPR), and in more serious cases even up to 20 million euros or 4 percent. In practice, fines for SMEs are usually considerably lower – yet even four- to five-figure sums can pose an existential threat to a small business. How seriously the authorities take the matter is shown by the highest German GDPR fine to date: in June 2025, Vodafone was fined 45 million euros for inadequate security measures. In addition, data subjects can claim compensation under Art. 82 GDPR – the ECJ has repeatedly ruled that the mere loss of control over one's own data can already constitute compensable non-material damage.

Conclusion

CVE-2018-25329 is a case study in why neglected software becomes a hazard. The WP with Spritz plugin has not been maintained for years, has been banned from the WordPress directory since 2020, and working attack code has been freely available since 2018. There is no patch – and there never will be one. The only correct response is the immediate and complete removal of the plugin.

Check today whether the plugin is present on your website. If so: delete it, review your server logs and, if in doubt, rotate your credentials. The effort involved is a matter of minutes. The damage from inaction can cost you your customer data, your reputation and – in a GDPR emergency – your budget. In IT security the rule holds: the cheapest vulnerability is the one you closed in time.