How a Single Google Dork Exposed 17 WordPress Users — and What We Can Learn

🔍 The Discovery

While performing routine reconnaissance, I came across an interesting Google search result. The query was simple:

filetype:csv “username” “password”

filetype:csv “username” “password”

Among the usual test files and outdated dumps, one result caught my eye:

National Foundation for Australian Women — nfaw.org
/wp-content/uploads/2020/10/export-users-2–3.csv

National Foundation for Australian Women — nfaw.org
/wp-content/uploads/2020/10/export-users-2–3.csv

The file was publicly indexed, directly downloadable, and contained 174 columns of user data. It wasn't a test — it was a full export of the WordPress user table for a legitimate non‑profit organisation.

📂 What Was Exposed?

The CSV held everything an attacker could dream of:

| Category | Examples | | — — — — — | — — — — — | | Authentication | Usernames, MD5‑hashed passwords ($P$B…) | | PII | Full names, physical addresses (street, city, postcode), phone numbers (home & mobile) | | Membership & Financial | Membership level (Concession), renewal dates, WooCommerce transaction IDs | | Technical | WordPress session tokens, user capabilities (subscriber), internal user IDs |

17 individual records were leaked — one per member.

⚠️ The Impact

The combination of PII + hashed passwords + addresses opens the door to:

• Identity theft — fraudsters can piece together a complete profile.
• Account takeover — MD5 hashes can be cracked (especially weak ones) using rainbow tables or brute‑force. If users reuse passwords, other services are at risk too.
• Spear‑phishing — attackers can craft highly convincing emails using real membership details and renewal dates.

The file was located in the /wp‑content/uploads/ directory, which many admins wrongly assume is "safe" from direct access.

🛠️ Responsible Disclosure

I immediately reported the issue to the NFAW technical team via their contact form. Within 48 hours, I received a gracious acknowledgment:

"Thank you for identifying and reporting the vulnerability… The issue has now been fully addressed and resolved." NFAW Tech Support

The file was removed, and I later confirmed the directory was no longer listing sensitive files.

📋 Remediation Checklist (for any WordPress admin)

1. Delete the file — immediately remove any .csv, .sql, or .log exports from the server.
2. Harden uploads folder — add an .htaccess rule to deny access to CSV/JSON files:

<Files ~ "\.(csv|json|log)$">
Order allow,deny
Deny from all
</Files>

<Files ~ "\.(csv|json|log)$">
Order allow,deny
Deny from all
</Files>

3. Disable directory indexing — add Options -Indexes to your .htaccess.
4. Force password reset — invalidate all exposed hashes and require users to set new strong passwords.
5. Notify affected users — be transparent about what was exposed and offer support.
6. Consider OAIC notification — in Australia, this may qualify as a Notifiable Data Breach under the Privacy Act.

🧠 Lessons Learned

This bug wasn't caused by a zero‑day or complex attack — it was a simple misconfiguration. The CSV was probably generated during a site migration or backup and left in a web‑accessible location. Google's crawler found it within days.

For developers and site owners:

• Never store sensitive exports in wp‑content/uploads — use a private folder outside the web root.
• Always set proper file permissions.
• Regularly audit your public directories for unexpected files.
• Use strong, salted password hashing (WordPress already uses phpass, but the hash format can still be cracked if the password is weak).

This experience reminded me that security is often about the little things — and that responsible disclosure is a vital part of the ecosystem.

🙌 Acknowledgements

Thanks to the NFAW team for their swift and professional response. It's a pleasure working with organisations that take data protection seriously.