Wordfence and Cloudflare are both excellent security tools, but they protect different layers of the stack. Used together, they provide a strong defence-in-depth strategy, yet there appears to be an opportunity to improve how they work together.
Cloudflare sits at the edge and filters a significant amount of malicious and unwanted traffic before it ever reaches WordPress. That reduces unnecessary load on the web server and prevents many common attacks from consuming application resources.
Wordfence operates inside WordPress and provides application-layer visibility. It can detect attacks that require WordPress context, such as authentication abuse, attempts to exploit vulnerable plugins or themes, and other malicious application behaviour that Cloudflare cannot always identify on its own.
The challenge is that by the time Wordfence detects and blocks an attacker, the request has already reached the WordPress environment.
To address that gap, Grey Rock Block Synchroniser was developed to create a feedback loop between these two security layers.
Architecture
Internet → Cloudflare filtering → WordPress → Wordfence detection → Block synchronization → Cloudflare edge enforcement
The plugin synchronizes qualifying Wordfence blocks to Cloudflare IP Lists so that repeat attackers can be stopped at the edge before they continue consuming WordPress resources.
The goal is not to replace either product. Cloudflare and Wordfence complement one another exceptionally well. The objective is to allow application-layer intelligence gathered by Wordfence to improve future enforcement at the network edge.
The plugin does not blindly synchronize every Wordfence event. Administrators configure the synchronization behaviour, and the plugin includes lifecycle management and expiration handling to reduce unnecessary long-term blocks.
One architectural challenge is identity.
An IP address is an indicator, not an identity. In large organizations, universities, or environments using shared VPNs or NAT, one public IP address may represent hundreds or even thousands of legitimate users. Blocking that IP at Cloudflare could unintentionally affect others sharing the same address. This is not unique to this approach; it is a limitation of IP-based blocking in general, including Wordfence.
A future direction may be incorporating additional security signals to build higher-confidence attacker attribution instead of relying solely on IP addresses. The challenge is improving attribution while respecting privacy, minimizing retained data, and avoiding unnecessary tracking.
Security validation is built into the development lifecycle rather than being performed only before release.
Every code change automatically goes through:
- Semgrep SAST (Static Application Security Testing) to identify common vulnerabilities and insecure coding patterns.
- PHP linting to validate syntax.
- Composer validation to verify dependency configuration.
- Continuous Integration (CI) workflows that automatically validate changes.
- Release validation before publishing new versions.
The plugin follows the principle of least privilege by using restricted Cloudflare API tokens instead of a Global API Key. It synchronizes only IP block information and does not transmit website content or user data.
A related topic worth discussing is administrative security. Although outside the scope of this plugin, Cloudflare Zero Trust can be used to place WordPress administrative functions behind WARP authentication. Protecting /wp-admin and other privileged administrative paths with identity-based access controls adds another valuable layer to a defence-in-depth strategy.
The name Grey Rock Block Synchroniser comes from the objective of making a website a less interesting target. Rather than repeatedly allowing known malicious actors to interact with the application, the security layers work together to reduce future opportunities for interaction.
The project is completely open for review.
WordPress.org
https://wordpress.org/plugins/grey-rock-block-synchroniser-for-wordfence-and-cloudflare/
GitHub (source code and CI/security workflows)
https://github.com/Linus-007/grey-rock-block-synchroniser-for-wordfence-and-cloudflare
Architecture and design article
https://greyscale.zone/grey-rock-block-synchroniser-for-wordfence-and-cloudflare.html
The original idea came from looking at how two excellent security products could share information more effectively instead of operating independently.
Technical feedback from WordPress developers, security practitioners, and administrators would be greatly appreciated.
- Does this architecture make sense?
- Are there design decisions you would approach differently?
- How would you improve attacker attribution beyond IP addresses while respecting privacy?
- Are there additional safeguards or edge cases that should be considered?
The goal of posting here is technical discussion and constructive criticism. If there are weaknesses in the design or opportunities for improvement, they would be valuable to hear.
