User Access Manager: CVE-2026-18352 Exposes wp-config.php

Published on 2 August 2026

Imagine someone could read your WordPress website's wp-config.php file from the outside – without a password, without a login, using just a single crafted web address. That very file contains the access credentials to your database: database name, user, password and the secret security keys. Anyone who gets hold of it effectively holds a master key to your entire website – and to all customer data stored within it. This is exactly what the security vulnerability CVE-2026-18352, published on 1 August 2026, enables in the widely used WordPress plugin User Access Manager.

Affected are all versions up to and including 2.3.15. According to wordpress.org, the plugin is in use on more than 10,000 active WordPress installations. If you use this plugin, you should read this article to the end – and then act.

What happened?

On 1 August 2026, the security firm Wordfence (Defiant Inc.) disclosed the vulnerability CVE-2026-18352. It received a CVSS score of 7.5 out of 10, classifying it as "High". The flaw was discovered by security researcher Supakiad S. (m3ez) of E-CQURITY in Thailand, who has already reported 43 documented vulnerabilities in the Wordfence Bug Bounty Program.

It is a so-called unauthenticated arbitrary file read – the unauthorised reading of arbitrary files without any login whatsoever. Technically, the vulnerability belongs to the Path Traversal category (CWE-22), i.e. "breaking out" of the actually permitted directory to reach files that should really be protected.

Wordfence describes the vulnerability as follows:

„The User Access Manager plugin for WordPress is vulnerable to Directory Traversal in all versions up to, and including, 2.3.15 via the 'uamgetfile' parameter. This makes it possible for unauthenticated attackers to read the contents of arbitrary files on the server, which can contain sensitive information.“
(Wordfence Intelligence, primary source)

The technical background – explained clearly

The plugin User Access Manager actually serves a sensible purpose: it controls who is allowed to see which content and file attachments on a WordPress website. Protected files are delivered via a special internal route that evaluates the uamgetfile parameter (i.e. part of the web address).

And this is precisely where the flaw lies. The attack proceeds in three steps:

1. The attacker picks a perfectly ordinary, publicly accessible file attachment on the website and notes its attachment_id (an internal ID number).
2. They assemble a URL that looks something like this: https://[target]/index.php?attachment_id=[legitimate_id]&uamgetfile=../../../../wp-config.php. The sequence ../ means "one directory level up" – this way you feel your way through the file system to the desired file.
3. The plugin now tries to resolve the path behind uamgetfile into a valid post ID. Because the traversal path is not a real attachment address, the WordPress function attachment_url_to_postid() returns the value 0.

And now comes the actual logical error in the programming: instead of aborting at this point, the plugin falls back to the global post context – i.e. to the legitimate public attachment whose ID the attacker sent along in the first step. The access check is performed against this harmless, public file and passes without a hitch. But the file that is then delivered is the one stated in the traversal path – for example wp-config.php.

Put differently: the lock checks the wrong key. It inspects a door that is allowed to be open, but then opens an entirely different, actually locked door.

In this way, highly sensitive files can be read, including:

• wp-config.php – database access credentials and secret keys
• /etc/passwd – system users of the server
• .htaccess and PHP configuration files
• in principle all files that the web server process can read

Anyone who reads out wp-config.php gains full database access – and can thereby take over the entire WordPress installation.

Who is affected?

Affected are all WordPress websites that have the plugin User Access Manager (slug: user-access-manager, author: gm_alex) installed in version 2.3.15 or older. Particularly sensitive: the plugin is deliberately used where content is access-restricted – i.e. in membership areas, customer portals and protected downloads. These are exactly the places where personal data typically resides.

How to check whether you are affected

1. Check the version: In the WordPress admin area go to Plugins > Installed Plugins, look for "User Access Manager" and note the version number.
2. Vulnerable? If the version is 2.3.15 or older, your installation is exploitable and must be updated immediately.
3. Alternatively via FTP/SSH: Navigate to the directory wp-content/plugins/user-access-manager/ and open the file readme.txt or user-access-manager.php – the version number is there.
4. Check the logs: Search your web server access logs (access.log) for requests containing the parameter uamgetfile in combination with traversal patterns such as ../ or the URL-encoded variant %2e%2e%2f.
5. Inspect wp-config.php: Check whether this file was unexpectedly modified (modification date, file hash), and watch out for unknown administrator accounts in the backend.
6. Security scan: Run a scan with a WordPress security plugin such as Wordfence or Patchstack.

What you need to do now

The good news first: a patch already exists. Version 2.3.16 was released on 27 July 2026 and fixes the vulnerability – according to the plugin changelog:

„Fix an unauthenticated arbitrary file read through path traversal in the file delivery.“
(Plugin changelog, version 2.3.16)

The most recent version is 2.3.17 (released on 31 July 2026). It contains the same security patch and additionally fixes a fatal type error in the multisite database update. Recommendation: update at least to 2.3.16, preferably straight to 2.3.17.

1. Immediate action – update: Update the plugin via the WordPress dashboard under Plugins > Updates or download it manually from wordpress.org.
2. If an immediate update is not possible: Deactivate the plugin until you can update. Alternatively, block access to the uamgetfile parameter via a web application firewall (WAF – an upstream protective layer) or an .htaccess rule.
3. Check logs for exploitation: Search for uamgetfile in combination with ../ or URL-encoded traversal sequences.
4. If compromise is suspected: Immediately change all access credentials from wp-config.php – the database password as well as the secret keys and salts – and check the database for unauthorised changes.
5. Establish a patching process: Enable automatic plugin updates or monitor sources such as Wordfence, Patchstack and BSI warnings in a structured way.
6. Contact your service provider: If your website is managed by an agency, request written confirmation that the update has been carried out. The data protection responsibility remains with you as the company.

Assessment: how dangerous is the vulnerability really?

The attack is network-based, requires no authentication and no user interaction, and has low complexity. It is precisely this combination that makes such vulnerabilities attractive targets for automated mass attacks. The vulnerability database VulDB rates the exploitability as "easy":

„The exploitation appears to be easy. The attack can be launched remotely. The exploitation doesn't need any form of authentication. [...] The pricing for an exploit might be around USD $0-$5k at the moment.“
(VulDB, VDB-385315)

At the time of publication, no publicly available exploits are known and there are no reports of active exploitation. But that is no reason to sound the all-clear. The security service provider Patchstack writes in its report "State of WordPress Security in 2026":

„The weighted median time to first exploit is 5 hours. This suggests that the most heavily targeted vulnerabilities are typically attacked within hours, not days.“
(Patchstack, State of WordPress Security in 2026)

Five hours – that is how short the median time span is between publication and first mass exploitation of heavily attacked vulnerabilities. Since the technical details of CVE-2026-18352 are already public, a swift "weaponisation" (the conversion of the vulnerability into a ready-to-use attack tool) is realistic.

For context, some figures: in 2025, 11,334 new vulnerabilities were discovered in the WordPress ecosystem – a 42% increase over 2024. Of these, 91% concerned plugins. And sobering: in pentests, traditional defensive measures such as WAFs blocked only 26% of all WordPress-specific attacks. So there is no substitute for an update.

GDPR: why this is also a legal matter

Because the plugin is deployed precisely where access-restricted and thus often personal content resides, CVE-2026-18352 is especially delicate from a data protection perspective. With the database access credentials read out from wp-config.php, an attacker can access the entire WordPress database – typically with usernames, email addresses, hashed passwords and, in the case of WooCommerce, order data too.

This can give rise to concrete obligations. Mario Elsen of ELSEN GRC puts it in a nutshell:

„Eine erfolgreiche [Ausnutzung] bedeutet, dass ein Angreifer den Server kontrolliert – und damit potenziell auf personenbezogene Daten zugreifen kann. [...] DSGVO-Meldepflicht (Art. 33): Bei einer Verletzung des Schutzes personenbezogener Daten ist die Aufsichtsbehörde in der Regel binnen 72 Stunden zu informieren. Die Uhr läuft ab Kenntnis – nicht ab Behebung.“
(Mario Elsen, ELSEN GRC)

Specifically, you should keep an eye on the following points:

• Notification obligation under Art. 33 GDPR: Where there is reasonable suspicion of exploitation and personal data is affected, the supervisory authority must be informed without undue delay, ideally within 72 hours of becoming aware.
• Notification obligation under Art. 34 GDPR: Where a high risk to the data subjects is likely, they too must be informed directly.
• Liability risk under Art. 83 GDPR: Anyone who fails to patch known vulnerabilities promptly risks fines of up to EUR 10 million or 2% of annual global turnover (violation of Art. 32 – security of processing).
• Processing on behalf of a controller: If an agency manages your website, you remain the controller under data protection law. A valid data processing agreement (DPA) with clear security and notification obligations is mandatory.

That this is not a theoretical danger is shown by the figures: in Germany, a total of 10,259 data breaches were reported to the supervisory authorities in 2025 (up from 8,623 the previous year). The authorities imposed 249 fines with a total value of around EUR 46.9 million.

Conclusion

CVE-2026-18352 is no footnote. An unauthenticated, easily exploitable vulnerability that enables the reading of wp-config.php and thus the takeover of the entire website is among the more serious security problems that SME website operators have to contend with. At least: unlike almost half of all WordPress vulnerabilities in 2025, here the patch was already available before the public CVE disclosure – version 2.3.16 of 27 July 2026.

Make use of this head start. Check now whether the plugin User Access Manager is running on your website, and update it immediately to at least version 2.3.16 – better still straight to 2.3.17. If an update is not immediately possible, deactivate the plugin temporarily. Given a median time to first exploitation of just five hours, the rule is: every hour that a vulnerable version stays online is an hour too many.