If you updated a plugin or your CMS after receiving one of my security notices, good. That was the important step, and for many sites it is the only step needed.

Updating closes the hole from now on. It cannot tell you whether anyone found the hole before you closed it. This page is a practical, roughly 30-minute self-check for answering that question yourself, written for site owners who do not have a security background or a security budget. It is generic guidance, not a finding about your site: from the outside I can see which software version a site reports, and nothing more.

Step 1: Check what the flaw could actually do

Not every vulnerability deserves the same response. Find your notice on the site notices page and check which class it falls into (each notice page states this near the top):

  • Account takeover or code execution (an attacker could gain administrator access or run their own code): work through the full checklist below.
  • Data reading (an attacker could read information from your database, but not change your site): focus on steps 2 and 5. The question is what data was stored, not whether your site was altered.
  • Narrower issues (flaws that require specific configuration, or that only reach an admin screen): the notice page for your component says what, if anything, is worth checking. Often the update alone is enough.

Step 2: Work out your exposure window

Two dates bound the period that matters:

  1. When the hole opened on your site. Usually the day you installed the affected version. If you don’t know it, the date in the notice’s CVE advisory (linked from each notice page) is a reasonable stand-in: from publication onward, attackers knew too.
  2. When you updated. The day you closed it.

Everything below is about that window. If it is short, say you updated within a day or two of the advisory, your risk is real but small. If the window is months long, take the checklist seriously.

Step 3: Review who can access your site

An attacker who got in almost always leaves themselves a way back in. Check, in order:

  • Administrator accounts. In WordPress: Users, then filter by Administrator. In Joomla: Users, then User Manager. Look for any account you did not create. Caveat: some flaws (the Simple Membership one, for example) let an attacker take over an existing account instead of creating a new one, so this check alone proves nothing. That is why the credential rotation in step 4 matters even when the user list looks clean.
  • Recently added plugins, themes, or extensions you did not install.
  • Scheduled tasks (WordPress: the WP Crontrol plugin shows them; many backdoors re-install themselves from a scheduled job).
  • Application passwords (WordPress: Users, Profile, Application Passwords), a quiet way to keep API access after a password reset.

Step 4: Rotate credentials

If your notice was in the account-takeover or code-execution class and your exposure window was more than a few days, rotate even if step 3 found nothing:

  • Passwords for all administrator accounts.
  • The secret keys and salts in wp-config.php (WordPress). This signs everyone out, including any attacker with a stolen session; the official generator gives fresh values. On Joomla, the equivalent is the $secret value in configuration.php.
  • Your hosting control panel and FTP/SFTP passwords if they are shared with anyone or old.

This costs ten minutes and closes the door on stolen sessions and cracked password hashes regardless of whether a break-in happened.

Step 5: Scan and check the files

  • Run your hosting provider’s malware scan if the control panel offers one (most shared hosts do), or a reputable free scanner. For WordPress, Wordfence’s free scan compares your files against the official copies.
  • Look at recently modified files around and after the start of your exposure window, especially PHP files in upload directories. Those should essentially never contain PHP.
  • If your host keeps access logs, skim the window for requests to the vulnerable component from addresses you don’t recognize. Absence of evidence here is weak, since logs rotate, but a hit is decisive.

If the self-check turns up something

Do not delete anything yet. Take a full backup first, files and database, so that whatever happened can still be examined. Then, in order of cost:

  1. Your hosting provider. Most have a malware-cleanup service or will at least confirm what their own scanners see. This is the right first call for most small sites.
  2. A professional. If the site handles customer data or payments, or the scan found a backdoor, it is worth paying someone to establish what was accessed; data-protection law in many places turns on that answer.
  3. The nuclear option that always works: restore from a backup that predates the exposure window, or reinstall the CMS and plugins from official sources, keeping only your content. Then update and rotate everything above.

If you are not sure what you are looking at, you can also simply reply to the notice email. I read every reply, and pointing someone in the right direction is part of why I send these notices in the first place. I am not selling a cleanup service and this page is not a pitch; see the disclosure policy.

If you had already updated before my email arrived

The same logic applies: the notice means your site recently reported an affected version, so a window existed even if it is closed now. Steps 2 to 4 still answer the question that matters.