Ravindra BagaleCourses & study guides मराठी Track your progress

21. Web Application Testing Tools

21.7 WPScan: Scanning WordPress

In short: WPScan checks the WordPress version, themes, plugins and users for known vulnerabilities.

A large share of the world's websites run WordPress, so it has its own scanner. WPScan checks the WordPress version, themes, plugins and users for known vulnerabilities.

wpscan --url http://192.168.56.30                       # basic scan (a WordPress VM you set up)
wpscan --url http://192.168.56.30 --enumerate u         # list usernames
wpscan --url http://192.168.56.30 --enumerate vp        # vulnerable plugins
wpscan --url http://192.168.56.30 -U users.txt -P /usr/share/wordlists/rockyou.txt   # password test (lab only)

WPScan uses a vulnerability database; a free API token from wpscan.com raises the daily limit. Most WordPress breaches come from outdated plugins, not WordPress core.

Ravindra Bagale's Tip

Don't just tell the client "your WordPress is old". Check the plugins – 90% of WordPress hacks happen through an old plugin. And if --enumerate u finds a username, tell the admin: don't show usernames publicly, and set a strong password + 2FA.

Lab

(Optional, if you set up a WordPress VM.) Run wpscan --url <your wp lab> --enumerate u,vp and list the version, any vulnerable plugin and the usernames found. Write one hardening step for each finding.

Hardening WordPress after a WPScan

WordPress powers a huge share of the web, including many Indian small-business and news sites. WPScan tells you what to update.

  1. Update WordPress core, themes and plugins.
  2. Remove unused plugins.
  3. Turn off user enumeration where possible.
  4. Use strong admin passwords and 2FA plugins.
  5. Put WordPress behind HTTPS and keep PHP / MySQL patched.

Real examples

Global: automated bots constantly try default admin URLs and old plugin exploits. Indian company (sample): a Pune agency that manages 40 WordPress sites runs WPScan weekly and applies updates every Monday morning.

Recap

  • Scan → update → remove unused plugins → 2FA.
  • Only sites you own or manage.

Defender's worksheet (do this today)

  1. Write the lesson title and date in your notebook.
  2. List three systems you own (VMs, personal projects, or lab apps) where this lesson applies.
  3. Run one safe command or checklist item from the lesson on a lab system only.
  4. Paste the command and its output under an Evidence heading.
  5. Write one fix you would give a teammate in two sentences.
  6. Write one mistake students make with this topic and how to avoid it.

More real-world pictures

Indian workplace (sample data)

Suppose we are a junior analyst at Tech Mahindra supporting a client SOC. After reading this lesson you add one detection or one hardening item to the team weekly checklist, with the owner name and a due date. That is how learning becomes operations.

Global practice

Public bodies such as CERT-In (India), CISA (US) and NCSC (UK) publish advisories that map to the same ideas: patch, least privilege, logging and user awareness. Bookmark one advisory feed and read it every Monday.

Home and family

Explain this lesson to a family member in four sentences without jargon. If they can repeat the main warning back to you, you understand it well enough to teach.

Connect to earlier chapters

Parts 1 to 9 built Linux, web servers, databases and cloud pieces. This lesson only makes sense when you can point to a concrete config file, package name or architecture box from those parts. If you cannot, revisit the matching earlier chapter before you practise any tool command.

Common mistakes

  • Skipping written permission just for a quick scan.
  • Practising on hostel or office Wi-Fi targets without authorisation.
  • Collecting tool output without writing the fix.
  • Copying exploit commands onto production to verify. Verification for defenders means checking versions and patches, not firing modules.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.
  • Teach one other person the warning from this lesson.