How to Fix Duplicator Security Block or Firewall Issue

A Duplicator security block or firewall issue usually shows up in one of two ways: the scan fails with a vague error before a package is built, or a security scanner flags a Duplicator installer/archive file as suspicious. Start by finding the exact failure point, cleaning up old package files, and checking the firewall or scanner that blocked the request before loosening any security rule.

Check the exact Duplicator error first

Open the Duplicator screen where the failure happens and note the step, message, and time:

• Scan fails before a package is built: check Duplicator’s scan details and any visible status text before changing settings.
• Package build starts but stalls or is blocked: look for blocked admin AJAX, backup, archive, or storage requests in your host or firewall logs.
• A malware or YARA scan flags an installer/archive file: identify the exact file path and scanner rule before assuming the active site is infected.
• Download or installer access is blocked: check file permissions, hotlink protection, host WAF rules, and security-plugin logs.

Public WordPress.org support reports show this pattern in real sites, including a Duplicator scan that fails with error 0 and a separate YARA false positive report involving Duplicator files. Those threads are useful signals, but the fix still depends on the exact file, request, or rule being blocked on your site.

Update Duplicator from Plugins > Installed Plugins before deeper troubleshooting. The official WordPress plugin page for Duplicator describes it as a backup/migration tool that packages site files and the database into a backup, so old packages and installer files are the first place to check when a scanner complains about Duplicator-related files.

Remove old Duplicator package files

Before changing firewall rules, remove package files you no longer need.

In WordPress admin, open Duplicator > Packages and delete old packages from there when possible. Download any backup you still need before deleting it.

If a scanner flags an old installer.php, archive, or Duplicator storage file, treat it as a cleanup problem first:

1. Download any package you still need.
2. Delete old packages from Duplicator > Packages.
3. Re-run the security scan.
4. If the same file is still flagged, ask the scanner vendor or host for the exact file path and rule name.

Do not manually delete random files from wp-content unless you have a current backup and know they belong to an old Duplicator package.

Test for a security plugin conflict

If Duplicator’s scan or package step fails with a vague status error, temporarily narrow the conflict.

1. Make a fresh backup using your host panel if available.
2. In Plugins, temporarily disable Wordfence, Solid Security, Sucuri, All-In-One Security, or another firewall/security plugin.
3. Try the Duplicator scan again.
4. Re-enable the security plugin immediately after the test.

If Duplicator works only while the security plugin is disabled, do not leave protection off. Open that plugin’s firewall or activity log and look for the blocked Duplicator URL, action, or rule ID. Add a narrow allow rule for that Duplicator request, or send the blocked URL and rule ID to the security-plugin vendor.

If disabling the WordPress security plugin changes nothing, check Cloudflare, Sucuri Firewall, your hosting WAF, ModSecurity, or server malware scanning logs next.

Check host firewall and ModSecurity rules

Many shared hosts run ModSecurity or another web application firewall. These can block long-running backup requests, archive downloads, or installer-like PHP files even when WordPress itself is working.

Ask your host for the blocked request details, not just a general “firewall” answer. A useful support request is:

Duplicator is being blocked while scanning or building a package. Please check WAF/ModSecurity logs for my account at the time of the failure and tell me the rule ID, blocked URL, and whether the rule can be safely allowlisted for Duplicator.

If the host gives you a rule ID, keep it. You may need it again after a firewall ruleset update.

Do not ask the host to disable the entire firewall permanently. A narrow allowlist for the affected request is safer.

Rule out file permission and storage problems

Duplicator needs to read site files and write package files. WordPress’ file permissions guidance explains that WordPress may need write access in wp-content, while overly loose permissions such as 777 can create security risk.

Check these areas in your host file manager or SFTP client:

• wp-content exists and is writable by WordPress.
• Duplicator’s package or storage directory is not blocked by ownership problems.
• Disk space is not full.
• Backup archives are not being quarantined by a server malware scanner.
• A .htaccess rule is not blocking Duplicator storage paths.

If you recently restored the site, changed PHP handlers, or moved hosts, file ownership is a common culprit. Ask the host to repair ownership for your WordPress account instead of recursively setting everything to 777.

When WP-CLI is worth using

Use WP-CLI only when wp-admin is unavailable, you are already working over SSH, or you need a quick plugin status check before asking the host to investigate. It will not fix a WAF, ModSecurity, malware scanner, or CDN firewall block by itself.

To confirm Duplicator is installed and active, run:

wp plugin status duplicator

The official wp plugin status command documentation covers the status check. If Duplicator is inactive and you are in an SSH-only recovery situation, activate it with:

wp plugin activate duplicator

If wp-admin is working, activate or update the plugin there instead.

Safest fix order

Use this order to avoid weakening security more than necessary:

1. Update Duplicator and WordPress.
2. Check Duplicator’s scan/package screen for the exact step and message.
3. Delete old Duplicator packages you no longer need.
4. Re-run the scan or package step.
5. Temporarily test with WordPress security plugins disabled, then re-enable them.
6. Check CDN, host WAF, ModSecurity, and malware scanner logs.
7. Ask the host or firewall vendor to allowlist the specific blocked request.
8. Contact Duplicator support with the scan log, blocked URL, firewall rule ID, and package step where it fails.

How to confirm the fix worked

A working fix should let Duplicator complete the scan and move to package creation without the same security or firewall message. If the issue was a scanner false positive, the same exact file path should no longer be flagged after old package files are deleted.

Do one final cleanup pass after a successful package build. Keep only the backup files you actually need, then remove temporary installer/archive files from Duplicator’s package screen.

Rollback and escalation notes

Re-enable any security plugin, CDN firewall rule, or host protection you disabled for testing. If you added an allowlist rule, keep it narrow and record the reason.

Contact your host when the block appears in server security logs, ModSecurity, malware scanning, file ownership, disk quota, or archive download restrictions.

Contact Duplicator support when the host sees no block and the failure happens inside Duplicator’s scan/package flow. Include the Duplicator version, the exact error text, whether old packages were removed, and any firewall rule ID your host found.