I have been blocked - recovery methods
A SecurityCheck Pro configuration change, a few accidental failed logins, or a firewall false positive can end up with your own IP blocked by the dynamic blacklist. This page lists every recovery method available, from easiest to most drastic — try them in this order.
JOOMLA
1. Rescue link (email)
Available since version 5.2.0, replacing the old OTP unlock. Requires an active Super User account and a working email delivery.
- From the blocked device, visit the following URL, replacing
YOUR_EMAILwith the email address of an active Super User of the site:
https://www.example.com/administrator/index.php?scpro_rescue=YOUR_EMAILThe 403 page shown to IPs blocked by the dynamic blacklist also includes these instructions.
-
If the email belongs to an active Super User, that user receives an email containing a single-use unblock link, valid for 15 minutes. The response in the browser is always the same, so the URL cannot be used to guess which email addresses exist.
-
Open the link from the email. A confirmation page shows the blocked IP, the date and the reason of the block. Press the confirmation button to execute the unblock (the unblock only happens on confirmation, so email link scanners cannot consume the link).
Once unblocked, the IP is removed from the dynamic blacklist and enters a grace period (30 minutes by default) during which it cannot re-enter the dynamic blacklist. The firewall filters keep inspecting and blocking individual malicious requests during the grace period, and the manual blacklist is never modified by this feature.
You do not always have to request the link yourself. If Proactive Rescue Email is enabled (Global Configuration > Tuning), a privileged user with an active session who gets blocked — by session protection, a hijack detection, or a firewall false positive — automatically receives a recovery link by email, without needing to visit the ?scpro_rescue= URL. By default this applies to any user who can log into the backend; additional groups can be added via Extra Groups Eligible for Rescue.
Modes
| Mode | Behaviour |
|---|---|
| Strict (default) | The unblock link only works when opened from the same blocked IP that requested it (self-rescue for Super Users). |
| Approval | The Super User receiving the email can confirm the unblock from any device, which also allows unblocking other blocked administrators. |
The mode, the grace period duration, the base URL used to build the link, and whether proactive emails are sent are configured in Configuration > Global Configuration > Tuning. Active grace periods are listed in the Firewall Configuration, in the dynamic blacklist section, where they can be revoked at any time.
2. Rescue file (FTP recovery)
Available since version 5.2.0. Use this when the rescue email cannot be delivered, or the backend is hidden or password-protected — it needs no email delivery and no working login page, only FTP or hosting File Manager access.
- In the Control Panel, look for the Rescue file secret card. It shows two values, both unique to your site: the exact file name you must use, and the file content (the secret).
- Using FTP or your hosting File Manager, create a plain text file inside
administrator/components/com_securitycheckpro/rescue/, using exactly the file name shown in the card, whose only content is the secret shown there (no extra spaces or lines). - Load your site once (front-end or
/administrator). The firewall detects the file, removes your current IP from the dynamic blacklist, grants it a grace period, and deletes the file automatically (single use). - Log in again.
The file is consumed (deleted) on the first request from a blocked IP, whether the secret was right or wrong. If it was wrong, create it again with the correct secret. A request from a non-blocked visitor does not consume it. Every use is written to the firewall log (tag RESCUE_MAGIC).
- The file name is derived from a per-site secret, so it cannot be guessed from the outside. If you rotate Joomla's secret (
configuration.php), the required name changes — always use the name currently shown in the card, not a previously noted one. - Press Regenerate Secret in the card if you suspect the current secret has been exposed. Any rescue file already created with the previous secret stops working.
- The
rescue/folder denies all web access via.htaccess. nginx does not read.htaccess, so if you run nginx add an explicit deny rule for that path in your server block, although the exposure is limited anyway (single-use, IP-scoped, logged):
location ^~ /administrator/components/com_securitycheckpro/rescue/ {
deny all;
return 403;
}- This method can be disabled entirely with the Rescue File (FTP Recovery) toggle in Global Configuration > Tuning.
3. Last resort: manual database edit
If the rescue link and rescue file are both disabled or unavailable and you remain locked out, you can temporarily disable the firewall plugin directly in the database (#__extensions table, set enabled to 0 for the securitycheckpro system plugin), log in, fix the configuration and re-enable it.
WORDPRESS
If you have been blocked by the firewall, use phpMyAdmin (or a similar tool) and open the wp_options table (adjust the prefix if needed). Search for the option_name equal to scp_firewallstatus and change the option_value from 1 to 0:
