WordPress powers massive amounts of corporate infrastructure in Nigeria. Banks use it for their corporate facing portals. Fintechs use it for marketing funnels. Logistics companies use it to track shipments. Because it is ubiquitous, it is a primary target. Because it is often deployed poorly on cheap local hosting, it is an easy target. We exploit these misconfigurations constantly during penetration testing engagements.
The shared hosting threat model
Many businesses choose local hosting companies in Lagos to satisfy regulatory preferences or keep latency low. However, shared hosting packages often suffer from poor user isolation. If another site on the same physical server is hacked, the attacker can traverse the file system and access your WordPress configuration file (wp-config.php). This represents a catastrophic failure of multi-tenant security.
We check file permission settings during our reviews. If your directories use permission flags like 777, any user on the server can read and write files inside your application workspace. An attacker compromises a weak blog on the same server, drops a PHP web shell, navigates up the directory tree, and reads your corporate database credentials.
You cannot trust the host to isolate your application. You must assume the host OS is compromised by adjacent tenants. We test this exact scenario. We upload our own shells to a test account and attempt to traverse into the client's production directory. We map the kernel limitations. We check if the hosting provider implements strict `open_basedir` restrictions in PHP. They rarely do.
Cross-site file traversal exposes database password
Weak directory permissions let one site account read another site's wp-config.php. That file contains database credentials and authentication salts. Separate site users, block cross-account reads, and rotate every exposed value. If you deploy on shared hosting, assume your database credentials will leak eventually. You must implement IP restriction on the database listener itself.
Exposed backup files and database folders
Developers occasionally create database backups and store them directly in the WordPress root directory using predictable filenames like backup.sql, site.zip, or db_dump.tar.gz. They do this because it is convenient for server migrations. They forget to delete them.
We use web scanners, dictionary lists, and Google Dorks to locate these hidden files. If they are publicly accessible, we download the entire database structure. We extract customer lists. We extract administrator password hashes. We crack those hashes offline using hashcat and massive dictionary rulesets. Once we crack an administrator password, we own the WordPress installation. We install a malicious plugin. We turn your corporate site into a phishing host.
We test directory indexing. If a developer leaves a directory without an `index.php` or `index.html` file, Apache or Nginx often lists the contents of the directory. We find sensitive plugin logs, debug files containing API keys for Nigerian payment gateways like Paystack or Flutterwave, and uploaded KYC documents in the `/wp-content/uploads/` directory. Directory indexing must be disabled globally at the web server level.
Hardening your WordPress configuration
To secure your WordPress deployment on local hosting providers, you must implement strict access controls at the `.htaccess` level before traffic ever hits the PHP application logic.
# Add to .htaccess to prevent directory indexing
Options -Indexes
# Block access to the configuration file
<Files wp-config.php>
order allow,deny
deny from all
</Files>
# Block access to sensitive log files
<FilesMatch "\.(log|sql|zip|tar\.gz)$">
order allow,deny
deny from all
</FilesMatch>This configuration provides a baseline defense against automated scraping and directory enumeration. However, `.htaccess` only works on Apache. If you use Nginx, you must port these rules directly into the server block configuration.
- Enforce strict file permissions: Set directories to
755and files to644. Thewp-config.phpfile should be set to600or400. Only the web server process should have permission to read the configuration file. - Disable XML-RPC: Block access to
xmlrpc.php. Attackers use this endpoint to execute massive brute-force amplification attacks against your login form. They submit hundreds of password guesses in a single HTTP request. If you do not actively use the WordPress mobile app or Jetpack, delete this file or block it via the web server. - Keep plugins updated: Automate updates for security plugins and form components. Outdated plugins account for over 90% of WordPress compromises. A vulnerable form plugin allows unauthenticated arbitrary file uploads, granting the attacker a direct web shell.
- Move the login URL: Do not leave the login page at `/wp-admin` or `/wp-login.php`. Automated botnets constantly scan these endpoints. Change the login path to a custom string. Implement strict rate limiting. Enforce Two-Factor Authentication (2FA) for all administrator accounts.
Check the whole hosting account
List every site, subdomain, database, FTP account, mailbox, cron job, and control-panel user in the hosting account. Remove old sites and unused users. A forgotten staging site running WordPress 5.2 on a subdomain (`staging.yourcompany.com.ng`) provides the exact same access to the server as your fully patched production site. Attackers compromise the forgotten staging site, escalate privileges locally, and pivot to production.
Give each site a separate system user when the host supports it. One damaged site must not expose another site's files. Isolate PHP execution pools. Enforce strict chroot environments.
Request a backup restore into a clean location. Confirm who can download backups, how long they remain available, and whether backup links expire. Search the public web root for .zip, .sql, .env, log, and old configuration files. Test direct access instead of trusting a directory listing. Do not assume your backup plugin secures the archives it generates. Many popular backup plugins store the `.zip` files in a predictable folder inside `wp-content`. We find them. We download them.
Evidence and pass conditions
During an audit, we document the attack chain explicitly. We keep the affected URL, response status, redacted file sample, file owner, directory permissions, plugin version, and hosting account boundary. A pass means the file cannot be fetched, the weak account is removed, the exposed secret is rotated, and access logs show no remaining route to the data.
WooCommerce sites need the payment tests in our WooCommerce security audit guide. Review the wider service scope on web application penetration testing. A compromised WooCommerce installation allows attackers to skim credit card details or manipulate order pricing directly in the database.
Get your WordPress site audited
A compromised company website damages your business reputation and spreads malware to your customers. Simpa Labs will audit your server configuration, scan for exposed backups, test your plugin vulnerabilities, and secure your database configurations against local privilege escalation attacks.