Full path disclosure (FPD) is a software bug that results in the full path to the webroot directory of the server being exposed. This is not necessarily a security risk, but can be used in combination with other vulnerabilities to create a real issue.

In this guide We will explain the importance of Full Path Disclosure in regards to WordPress vulnerabilities and cover various methods of triggering Full Path Disclosure.
Example: WordPress Path disclosure
You have probably already seen path disclosure errors without even noticing, they look something like this:
Fatal error: require() [function.require]: Failed opening required 'some-file.php' (include_path='.:/usr/local/php53/lib/php') in /home/stefan/public_html/index.php on line 17
Inside this example an attacker can find useful information:
stefan | user that owns the website and probably has SSH access |
public_html | folder on the server where the website is stored |
php53 | website uses PHP 5.3 an outdated version of PHP |
Another example of an Unauthenticated Full Path Disclosure vulnerability on a WordPress website is the ⚠️ CVE-2021-25118 that affects Yoast SEO plugin<= 17.2.1
The plugin discloses the full internal path of featured images in posts via the wp/v2/posts REST endpoints which could help an attacker identify other vulnerabilities or help during the exploitation of other identified vulnerabilities.
So on a website that has Yoast SEO plugin <= 17.2.1 when an attacker sends the following request:
curl -s 'https://example.com/wp-json/wp/v2/posts?per_page=1' | jq '.[0].yoast_head_json.og_image[0].path'
He will receive the full path to the image:
/home/stefan/public_html/wp-content/uploads/2022/03/Reset-WordPress-password-from-the-command-line.png
Why is full path disclosure important
The information revealed by a full path can disclose a lot more than simply the webroot directory’s path. It can provide the usernames of the server’s user accounts, whether it’s a shared server, which hosting provider it’s with, what operating system it’s running, etc.
In the example above We can see that the website is running on cPanel, the username is “stefan” and the website is running older version of PHP. Now how can this information be misused?
SSH Bruteforce
With this information an attacker can run an SSH bruteforce on the server because he already has the hostname (website name) and the username (disclosed in the full path error), now just needs port to run SSH Bruteforce.
The default SSH port is 22, but if a hosting provider is using custom port it can easily be found in their knowledge base.
An attacker can use this information to run a SSH bruteforce attack on the server, and the only thing that is keeping them out is how strong your password is.
From then the attacker can attempt to escalate privileges in order to gain root access to the server for a full compromise.
For SSH bruteforce protection on cPanel servers I recommend using CSF and cPHULK, and for protecting WordPress itself from brute force attacks make sure you follow these security recommendations.
File inclusion or disclosure vulnerabilities
Remote File Inclusion (RFI) and Local File Inclusion (LFI) are vulnerabilities that are often found in poorly-written WordPress plugins and themes that are not following WordPress coding standard. These plugins include nulled/cracked versions of premium plugins, as well as plugin forks on Github.
These vulnerabilities occur when the plugin allows users to submit input directly into files or upload files to the server.
With Local File Disclosure you can only gain access through information disclosure as a result of leaked files – so reading config files like wp-config.php is one of the most common ways to obtain access to the server.
SQL Injections
By using an SQL Injection attacks if a vulnerable WordPress plugin or theme uses into outfile or dumpfile to write files then an attacker can perform local file reads via load_file();
Both can be used to read configuration files such as wp-config.php or to insert a shell in order to gain access to the server.
We recently covered in depth SQLi attacks in this guide:
Malicious Symbolic Linking
From the example error above, we know the path to the website is /home/stefan/public_html/ but from this information an experienced attacker can also conclude that the user is using cPanel – because public_html is the default document root for the main domain on cpanel software.
On cPanel shared hosting hundreds of sites are running on the same server.
Aside from determining the version of cPanel a website is running and then searching for a cPanel exploit, an attacker can also exploit another website on the server to attack your website.
If they gain access to another website on the server they can create a Symbolic Link to the webspace of the site that they were originally attempting to compromise. Without having the full path to the website, this would not be possible.
How to block path disclosure
Use a WordPress security plugin such as iThemes Security that has an option to “Prevent PHP execution in folders” which will add .htaccess file to the folders and prevent direct access.
In PHP you can disable full path disclosure errors by adding the following inside the actual php file:
error_reporting(0);
Directly in PHP’s php.ini file or in Apache’s httpd.conf file:
php.ini
display_errors = 'off'
.htaccess
php_flag display_errors off