N-day

You observe n-day risk by matching what you run to what is published. Check each plugin, theme, CMS core, and server package version against CVE entries and the CISA Known Exploited Vulnerabilities Catalog, which lists flaws seen exploited in the wild. Days since disclosure is a simple count from the advisory date.

Logs confirm attempts: requests to a known vulnerable path, a distinctive payload string, or a burst of scans for one plugin slug. A log hit is an attempt; a changed file or a new admin user is a success.

A plugin author publishes an advisory on a Tuesday for an unauthenticated file upload in a form plugin used on a church site. By Thursday the access log shows 40 POSTs from a rotating set of IPs to the plugin's upload.php. The church still runs the version from before the fix, and a file named x.php appears the next morning.

That is two days after disclosure. The attacker needed no secret, only the advisory and a list of unpatched sites. Updating the plugin on day three would not have removed x.php, so the cleanup includes checking the upload folder.

A zero-day has no fix when it is used, so defenders cannot patch their way out. An n-day has a fix, so the exposure is the delay between release and install. The zero-day is a vendor problem first; the n-day is an operations problem.

Thinking a small, unadvertised plugin is too obscure to be targeted. Updating the plugin but leaving the backdoor it was used to drop. Counting only core updates and skipping abandoned plugins. Waiting for a monthly maintenance window while a flaw is under active exploitation. Judging urgency by CVSS score alone.

Keep an inventory with versions and an alert source for each component. Patch anything on the CISA catalog first, within days. If a flaw was exploitable before you patched, check for dropped files and new users as well as updating.