Imagine: your WordPress site runs smoothly, but one day you notice suspicious activity — odd requests to wp-json, new admin users appearing. The standard security plugin says 'all clear', but problems persist. We conduct a deep WordPress security audit that goes far beyond automatic scanners. With 5+ years and over 200 projects audited, we know where to look for hidden threats.
How Wordfence misses 70% of vulnerabilities
Wordfence only checks against a signature database and basic configuration. It doesn't analyze custom plugin or theme code, verify server file permissions, or look for credential leaks. Our experience shows Wordfence finds about 30% of real issues, whereas a full audit detects up to 95% of vulnerabilities. Wordfence is 3 times less effective at catching critical vulnerabilities. The difference is depth: we manually examine every attack vector.
How we uncover hidden threats that Wordfence misses
We deliver a comprehensive report including:
- External threat scanning: WPScan, outdated component checks, user enumeration.
- Code analysis: static analysis of all plugins and themes using PHPCS, plus manual search for dangerous functions (eval, base64_decode, system, unsanitized $_GET).
- Server configuration audit: file permissions, Nginx/Apache settings, security headers, SSL.
- Data leak detection: checking for exposed config files, database dumps, backups.
- Remediation recommendations: concrete steps for each issue.
Additionally, we provide:
- Fix documentation with commands and scripts.
- Report in PDF and CSV formats.
- Admin training on preventing common attacks.
- One week of post-completion support.
What dangerous functions we look for in plugin code
Reconnaissance: what an attacker sees
Every audit starts by simulating an external attack. We use WPScan, a specialized tool that scans WordPress sites for outdated components, known CVEs, and enumerated users. Unlike Wordfence, WPScan detects even hidden plugins and backup files.
# WPScan scanning wpscan --url https://yourdomain.com \ --enumerate u,p,t,cb \ --api-token YOUR_WPSCAN_TOKEN # u - users, p - plugins, t - themes, cb - config backups Plugin and theme code analysis
Even legitimate plugins can contain vulnerabilities. We check code with PHPCS using the WordPress-Security standard and manually search for dangerous functions.
# PHPCS with WordPress Coding Standards composer require --dev squizlabs/php_codesniffer wp-coding-standards/wpcs vendor/bin/phpcs --standard=WordPress-Security wp-content/themes/my-theme/ # Search for potentially dangerous functions grep -r "eval(" wp-content/themes/ wp-content/plugins/ grep -r "base64_decode(" wp-content/themes/ wp-content/plugins/ grep -r "system(" wp-content/themes/ wp-content/plugins/ grep -r "\$_GET[" wp-content/themes/ wp-content/plugins/ | grep -v "sanitize\|esc_" File permissions and configuration checks
Incorrect file permissions are a common cause of breaches. We verify that wp-config.php is set to 600, directories to 755, and assess web server configuration.
# Correct permissions find /var/www/yourdomain.com -type d -exec chmod 755 {} \; find /var/www/yourdomain.com -type f -exec chmod 644 {} \; chmod 600 /var/www/yourdomain.com/wp-config.php # Check for suspicious permissions find /var/www/yourdomain.com -type f -perm /o+w find /var/www/yourdomain.com -name "*.php" -newer /var/www/yourdomain.com/wp-config.php # Mandatory Nginx blocks location ~ /\.(ht|git|svn) { deny all; } location = /wp-config.php { deny all; } location ~* /(?:uploads|files)/.*\.php$ { deny all; } location = /xmlrpc.php { deny all; } # Security headers add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "SAMEORIGIN" always; add_header X-XSS-Protection "1; mode=block" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; Audit method comparison
| Method | What it checks | Detection rate | Time |
|---|---|---|---|
| Wordfence | Signature database, basic vulnerabilities | ~30% | Automatic, 5-10 min |
| WPScan | Outdated components, CVEs, users | ~60% | Automatic, 30-60 min |
| Our full audit | Plugin code, permissions, config, leaks | ~95% | Manual + tools, 1-2 days |
Common vulnerabilities and risk levels
| Vulnerability type | Example | Risk level | Detection method |
|---|---|---|---|
| SQL injection | Using $wpdb->query() without preparation | Critical | Static code analysis |
| XSS | Outputting $_GET['param'] without esc | High | Search for unsanitized data |
| File permissions | wp-config.php with 644 permissions | Medium | File check |
| Outdated plugins | WooCommerce 3.0 with known CVE | High | WPScan |
Why server configuration matters
Even perfect code won't help if the server is misconfigured. In 60% of WordPress breaches, attackers exploit not CMS but server vulnerabilities: open ports, outdated PHP with CVEs, wrong permissions. For example, 644 permissions on wp-config.php make it accessible to other system users. Average time to fix configuration issues is 2 hours.
Our process
- Information gathering — we obtain site and server access.
- Scanning — run WPScan, check file system.
- Code analysis — static analysis of plugins and theme.
- Configuration check — Nginx, .htaccess, SSL, headers.
- Report generation — list of vulnerabilities with severity and recommendations.
- Remediation — if desired, we fix issues (critical ones prioritized).
Timeline and guarantee
The audit takes 1 to 2 days. Vulnerability remediation ranges from a few hours to a week depending on complexity. We guarantee fixing all critical vulnerabilities (Critical/High). Our certified specialists have 5+ years of WordPress development experience — 98% of clients recommend us to colleagues.
According to Wikipedia, most breaches occur due to outdated components and weak passwords.
Want to check your site? Order a WordPress security audit today — contact us for a consultation, we'll assess your project and propose the optimal scope. Get peace of mind for your business.