Quieting GuardPress Security Alert Email Flood

Is This Your Issue?

Pattern A: Same alert every day for days or weeks

A single GuardPress security alert — same subject line, same finding, same body — arrives in your inbox every morning. Could be an “Outdated Software Check” alert about a debug log, a file integrity change about a file that no longer exists, or a malware finding you’ve already triaged. The alert never stops — one customer reported receiving the same “Debug Log Exposed” alert every morning for 15+ days.

What the flood looks like in your inbox

Two threads, each grouping 31 identical copies of the same alert (62 total emails). Pre-1.6.21 the scanners had no “already notified” state, so every daily scan re-sent every unresolved finding. Fixed in 1.6.21.

If either pattern (or both) describes what you’re seeing, this article is for you. If you’re getting emails for events you didn’t expect to be alerted on at all (e.g. routine logins by your own admin account), see Sign-in Notifications instead.

The Fix — Update GuardPress to 1.6.24 or Later

Both bugs are fully resolved at 1.6.24. The update is the entire fix — no settings to change, no caches to clear, no config to edit.

Verify the Fix

Confirm both bugs are fixed:

If You Want to Dial Notifications Down Further

The 1.6.24 fix stops the excessive emails. If you still want fewer emails overall — or want to route alerts to a different inbox — the controls live under GuardPress → Settings → Notifications:

• Enable email alerts — master toggle for all GuardPress email notifications. Turning this off stops every alert (brute-force attacks, malware detection, file changes, outdated software, uptime monitoring). Not recommended — you lose visibility into real incidents — but it’s the nuclear option when you need email silence for a brief maintenance window.
• Alert Email — the destination address. Defaults to the WordPress admin email. Set a separate ops inbox, shared team alias, or pager address if you don’t want alerts mixed in with general admin mail.
• Send Test Email — verifies the configured address actually receives mail. If you’ve never received any GuardPress emails (even after triggering events), test here first — the answer is usually mail delivery, not GuardPress.

Why Did This Happen?

The email flood came from two distinct bugs in different modules that shipped at different times. Both modules wrote dashboard alerts correctly — only the email channel was misbehaving.

Pattern A — Pre-1.6.21: scanners had no “already notified” state

Three modules — file integrity monitor, vulnerability scanner (“Outdated Software Check”), and malware scanner — ran on a daily cron schedule. Each scan that found a critical issue would call wp_mail() to send the alert. Neither scanner remembered what it had already sent. So if you had an unresolved finding (a debug log left exposed, a deleted file flagged as “missing”, a malware signature hit that turned out to be a false positive you hadn’t triaged yet), every single subsequent daily scan re-sent the exact same email — for days, then weeks. The 1.6.21 fix added hashed-deduplication state to all three modules:

• File monitor tracks guardpress_file_monitor_last_notified_at (a timestamp) and only includes changes recorded since that timestamp in the next notification
• Vulnerability scanner hashes the sorted critical-issue set into guardpress_vulnerability_last_notified_hash and only emails when the hash changes
• Malware scanner hashes file_path|threat_type per detected threat into guardpress_malware_last_notified_hash with the same change-detection logic

All three dedup hashes auto-clear when the underlying issue set goes empty — so the next new finding alerts on the very next scan with no manual reset needed. State updates only happen on a successful wp_mail() send, so a transient SMTP failure retries on the next scan instead of silently swallowing the alert.

Pattern B — Pre-1.6.24: file monitor sent one email per changed file

The file integrity monitor had two separate notification paths firing at the same time during every scan. The first was the per-file Critical File Change Detected alert, queued individually via the alert subsystem so each changed file produced its own email. The second was the batched end-of-scan summary email that already listed every change with paths and hashes.

Both were intentional in isolation. Stacked, they meant a normal WooCommerce or Elementor update — which legitimately modifies 100+ PHP files in one go — produced 100+ individual “Critical File Change Detected” emails plus the one summary email, for 101+ emails from a single update. The 1.6.24 fix suppressed the per-file email entirely. Dashboard alert rows still record every change (the data is preserved for forensic review), but the email channel only sends the consolidated summary.

Still Stuck? Email Priority Support

If you’re on GuardPress 1.6.24 or later and emails are still flooding (or you’re receiving zero emails when you should be getting some), the cause is almost certainly outside GuardPress — usually mail delivery or a custom integration.

Email support@royalplugins.com with the diagnostic info below. Priority email support is included with your GuardPress Pro license — typical response time is within 24 hours.