This is a demonstration. “aurora-co.com” is a fictional site used to show the report format. The findings below are representative of the issues Lockora most commonly detects on real WordPress sites. To produce this report for your own site, install the plugin and run your first scan.
78
3critical
7warnings
24passed
A firewall would not have caught most of these — they are configuration and account problems, not attack traffic. How an audit differs from a firewall →
Critical — act today
Critical Outdated “Contact Form 7” matches a known vulnerability (CVE-2023-6449) /wp-content/plugins/contact-form-7 · installed 5.8.2, patched in 5.8.4
- What
- The installed Contact Form 7 version allows an unrestricted file upload via the
[file]form tag: a crafted filename likecv.pdf.phtmlcan bypass sanitization and land in the uploads directory with an executable extension. - Why it matters
- On hosts that execute
.phtmlas PHP, this is unauthenticated remote code execution from a public contact form. Automated scanners actively probe for this version. - What to do
- Update the plugin from Plugins → Updates, then block PHP execution inside
wp-content/uploadsat the web server so the same class of bug cannot execute in future. Full background: Contact Form 7 security vulnerabilities. Vulnerability matching uses your optional Wordfence Intelligence API key; without one, Lockora still flags the plugin as behind the current release.
Critical WordPress authentication keys still contain placeholder values wp-config.php · 3 of 8 keys = "put your unique phrase here"
- What
- Three of the eight authentication keys and salts in
wp-config.phpwere never replaced with unique values — a common leftover from one-click installers. - Why it matters
- These keys sign session cookies. Predictable keys make forged authentication cookies feasible, undermining every login protection on the site.
- What to do
- Use the plugin’s Rotate keys action to generate eight fresh high-entropy values, or paste new ones yourself. Rotation logs out all active sessions, so pick a quiet moment. Details in the wp-config.php security guide.
Critical Unknown Administrator account, inactive for 26 months user "webtemp7" · created 2023-02-11 · 4 Administrators on a 3-person team
- What
- An Administrator account exists that matches no current staff, vendor, or service pattern, and has been dormant for over two years. The site also has more Administrators than its team size suggests.
- Why it matters
- Dormant privileged accounts are a favourite persistence mechanism after a compromise — and even when benign, they widen the attack surface for credential stuffing.
- What to do
- Lockora lists the account with its role, creation date and last activity, and never deletes users itself. Downgrade it, delete it (reassigning its content), or confirm it is known. See user roles and permissions security.
Warnings — act this week
Warning xmlrpc.php enabled and publicly reachable POST /xmlrpc.php → 200 OK · system.multicall enabled
- What
- The legacy XML-RPC endpoint is publicly reachable and accepts batched authentication attempts via
system.multicall. - Why it matters
- One HTTP request can carry hundreds of password guesses, bypassing login throttles that only watch
wp-login.php. The endpoint can also be abused for pingback reflection DDoS. - What to do
- If nothing on the site uses XML-RPC (Jetpack and some mobile-app setups still do), switch on Lockora’s Disable XML-RPC toggle. It applies the WordPress filter and can be switched back off at any time. Full walkthrough: what is xmlrpc.php and how to disable it.
Warning Usernames exposed through author archives; no login-protection plugin detected /?author=1 → /author/aurora-admin/ · /wp-json/wp/v2/users → 200
- What
- Two Administrator usernames are discoverable from public author archives and the REST users route, and no login-protection or two-factor plugin was detected.
- Why it matters
- Known usernames plus an unthrottled login form is a complete brute-force path. Removing the username leak and adding lockouts or 2FA breaks it.
- What to do
- Switch on the REST user routes toggle to close
/wp-json/wp/v2/users, set display names that differ from login names, and add lockouts and two-factor authentication. Guide: how to secure the WordPress login page.
Warning debug.log is publicly reachable GET /wp-content/debug.log → 200 OK · 1.2 MB
- What
- Debug logging writes to the default location inside
wp-content, and the web server serves the file to anyone who asks for it. - Why it matters
- Information disclosure: the log contains absolute file paths, plugin internals and sometimes database queries, which attackers use to pick working exploits faster.
- What to do
- Set
WP_DEBUG_LOGto a path outside the web root (or turn debug logging off in production), delete the exposed file, and deny direct access to*.logat the web server. The wp-config.php guide has the exact constants.
Warning readme.html and generator tag reveal the WordPress version GET /readme.html → 200 · <meta name="generator" content="WordPress 6.4.2">
- What
- The stock
readme.htmlis reachable and every page carries a generator meta tag naming the exact WordPress version. - Why it matters
- Version information lets mass scanners skip straight to the exploits that apply. It is low severity on its own, but it is free to remove.
- What to do
- Switch on the Remove generator tag toggle and delete or block
readme.htmlat the web server.
Passed — a sample of the 24 clean checks
Passed Core files match WordPress.org checksums 1,412 core files verified against official hashes · 0 modified · export CSV / TXT
- What this check covers
- Every WordPress core file is compared against the checksums WordPress.org publishes for this exact version. Injected backdoors in core files — a common malware pattern — would surface here, with paths you can export.
Passed No executables or backup archives found in wp-content uploads, cache and custom directories scanned · 0 anomalies
- What this check covers
- The bounded anomaly scan looks for PHP or other executables in uploads, unexpected PHP outside the standard code directories, runtime executables, and exposed backup or secret-like files. Plugin and theme directories are checked separately through update and vulnerability posture.
Passed HTTPS enforced and security headers present HSTS · X-Content-Type-Options · X-Frame-Options · Referrer-Policy
- What this check covers
- The site redirects to HTTPS and sends the basic browser-hardening headers. Sites that fail this check can switch on Lockora’s Basic security headers toggle.
Passed SSL certificate valid for 61 more days; PHP 8.2 is supported expires 2026-11-01 · PHP status from WordPress.org Serve Happy
- What this check covers
- Certificate expiry is checked so renewals do not slip, and the PHP version is compared with the support status WordPress.org publishes.
Passed Automatic core updates enabled; no must-use plugins present minor releases auto-update · /wp-content/mu-plugins absent
- What this check covers
- Security releases arrive without waiting for a person, and there is no must-use plugin directory where code would load silently on every request.
Download this sample report
The same findings in the formats you would hand to a client, a developer or a host. The PDF is a printable version of this page; the CSV and TXT files mirror the export formats the plugin produces for core-integrity and anomaly results.
PDF Sample audit report
Score, all findings with what / why / what-to-do, and the passed checks. Ready to print or forward.
A4 · 5 pages
CSV Findings as a spreadsheet
One row per finding: severity, category, check, location, evidence, recommendation, remediation type.
Opens in Excel, Numbers, Sheets
TXT Plain-text summary
The same report as plain text, for tickets, email, or pasting into a runbook.
UTF-8 · no formatting
What the score means
Lockora weights each check by how often it is involved in real compromises, then scores the site out of 100 and compares the result with the previous scan. As a rule of thumb:
0 – 49At least one critical finding, usually a known vulnerability, placeholder keys or a suspicious file. Fix the criticals before anything else.
50 – 79No open door, but several windows: exposure, account hygiene or hardening gaps. The demo site above sits here.
80 – 100Well-maintained. Re-scan after updates and staff changes to stay here; the previous-scan comparison shows drift.
The score is a prioritisation aid, not a guarantee. A site can score 95 and still have a vulnerable custom theme that no automated check can see — which is why every finding is explained rather than just counted.
How to read this report
If you are a site owner receiving this from a developer or agency, three things to know:
- CriticalSomething an attacker can use today — a known vulnerability, weak secrets, a suspicious file or account. Fix within the day; these are also the items most worth a phone call.
- WarningSomething that makes an attack easier or louder: exposed endpoints, leaked usernames, missing headers. Fix this week; most are one toggle or one edit.
- PassedChecks that came back clean. They are listed so you can see what was covered, not just what went wrong.
Each finding follows the same shape — what was found, why it matters, and what to do — and says whether the fix is a reversible toggle inside Lockora, an action such as rotating keys, or a manual change for your developer or host. The report maps closely to the WordPress security checklist, so you can use the two together.
Every check the scan runs
The full list as of Lockora Security Audit v0.4.2. Each row is a finding you could see in the report above.
| Check | What it looks for | Fix type |
|---|---|---|
| Integrity | ||
| Core file checksums | Every core file compared with WordPress.org hashes for the installed version; modified or extra files listed, exportable as CSV/TXT | manual |
| Executable uploads | PHP and other executable files inside wp-content/uploads | manual |
| PHP outside code directories | Unexpected PHP files outside plugin, theme, mu-plugin and language directories | manual |
| Runtime executables | Binaries and scripts that should not exist under wp-content | manual |
| Backup and secret-like files | Archives, dumps, .env-style and key-like files reachable under the web root | manual |
| Must-use plugin directory | Presence and contents of wp-content/mu-plugins | review |
| Configuration and secrets | ||
| Authentication keys and salts | Missing or placeholder values among the eight keys | action in Lockora |
| Database table prefix | Default wp_ prefix | manual |
| HTTPS | Site served over HTTPS with redirect from HTTP | manual |
| Security headers | Basic browser-hardening headers present | toggle |
| Generator tag | WordPress version in the page <meta> | toggle |
| Public exposure | ||
| debug.log reachability | wp-content/debug.log served publicly | manual |
| readme.html reachability | Stock readme exposing the version | manual |
| Uploads directory listing | Directory index enabled on wp-content/uploads | manual |
| PHP execution in uploads | Whether the server executes PHP placed in uploads | manual |
| XML-RPC | xmlrpc.php enabled and reachable | toggle |
| REST user routes | /wp-json/wp/v2/users listing users publicly | toggle |
| Author archive enumeration | Usernames discoverable via ?author=N | manual |
| Accounts | ||
| Default usernames | Administrators named admin, the domain, or similar | review |
| Excess Administrators | More Administrator accounts than a site of this kind needs | review |
| Inactive Administrators | Privileged accounts with no recent activity | review |
| User ID 1 exposure | Whether the first account is an easily-targeted Administrator | review |
| Login protection / 2FA | Presence of a login-protection or two-factor plugin | manual |
| Updates and platform | ||
| Core, plugin, theme updates | Anything behind its current release | manual |
| Automatic update posture | Whether security releases install on their own | manual |
| Known vulnerabilities | Installed versions matched locally against the Wordfence Intelligence feed (optional API key) | manual |
| PHP version | Support status from WordPress.org Serve Happy data | manual |
| SSL certificate expiry | Days until the certificate expires | manual |
“Toggle” means a reversible switch inside the plugin. “Action in Lockora” means a button in the plugin that makes one explicit change when you click it. “Review” means Lockora shows the evidence and you decide. Everything else is guidance for you, your developer or your host. A scan summary also appears under Tools → Site Health → Status.
Run this report on your own site
Install the free plugin, open Tools → Lockora Security Audit, click Run Scan, and you will have this report for your site in a few minutes. Agencies can run the same scan from the command line with wp lockora scan --format=json and, on WordPress 7, generate a client-facing summary from the findings.
Built by G. Schad, from several hundred manual audits. Found the plugin on a site you did not set up? Start here.