It is not because Bricks Builder is fundamentally unsafe. We see sites get compromised because too many designers still prioritise the visual canvas over real server-level optimisation and treat security like a plugin you add at the end of a build rather than the foundation you engineer from the start.
In early 2024 a critical remote code execution vulnerability was discovered in versions of Bricks Builder up to and including 1.9.6. This allowed unauthenticated attackers to execute arbitrary code on vulnerable sites. That was a real and actively exploited flaw that needed to be patched.
In mid-2025 another Bricks Builder vulnerability, a blind SQL injection in versions up to and including 1.12.4, meant attackers could manipulate database queries and extract data if the site was not updated.
One of the things I appreciate about Bricks is the way the team handles these situations. They disclose vulnerabilities publicly and move quickly to resolve them, which shows a strong commitment to transparency and security. That responsiveness is a big reason why their team has such a solid reputation.
We Still Treat Security as an Option
You hit the nail on the head when you wrote that most freelancers bring their old, lazy security habits from tools like Elementor into Bricks. But here is the reality: Bricks gives you more direct access to database queries, loops, and dynamic data generation, and that power increases risk if you do not harden the environment.
Firewall plugins and “security suites” are useful for detecting attacks, but they do not prevent exploitation of underlying flaws in the builder itself. A firewall can only block known attack patterns. It cannot fix a REST endpoint or unsanitised query before it is exploited.
Most checklists still say “change your login URL and you’re secure.” That is like putting a prettier lock on the front door while leaving the back window wide open.
The Execution Gap Is Still Huge
Hardening only matters when you build for it from the start. That means:
Server-Level Hardening Comes First
If you are hosting client sites on ultra-cheap shared hosts with poor isolation, you have already lost before you started. These environments allow one compromised site to affect its neighbours through weak protections.
Real hardening begins with how WordPress talks to the server:
- Disable file editing from the dashboard so an attacker with admin access cannot rewrite theme or plugin files.
- Move your
wp-config.phpoutside the public HTML root. - Enforce strict file permissions to reduce write access for unauthorized scripts.
- Disable PHP execution in the uploads folder using server configuration.
These simple steps stop a huge percentage of post-compromise persistence techniques.
Bricks-Specific Considerations
Bricks makes it easy to build advanced features, but there are specific risks if you leave dangerous tools open:
- Code execution features must be tightly controlled and limited to trusted administrators only.
- Older versions of Bricks exposed endpoints and input paths that were abused to achieve remote code execution.
- Even after security patches are released, many sites sit on outdated versions and remain vulnerable.
Most developers update once at launch and never return to check for new patches or server requirements. Attackers on the internet do the opposite. They constantly scan for known versions with documented CVEs.
The True Foundation of Security
You cannot outsource security to a plugin or a cloud firewall. You need to build it into your workflow from the ground up:
Authentication and Access Control
- Enforce strict lockout policies for repeated login failures.
- Require two-factor authentication for all users with publishing or admin access.
- Use passkeys where possible to reduce the risk of credential theft.
Complaints about “clients not wanting 2FA” do not matter when you are cleaning up a hacked site at 2 a.m.
Maintenance Discipline
- Keep PHP and all WordPress core components up to date with supported versions.
- Audit and prune plugins and themes regularly.
- Remove unused plugins promptly.
A large proportion of WordPress compromises happen through outdated or unmaintained extensions, and the volume of disclosed vulnerabilities continues to grow rapidly.
Database Hygiene
- Change the default
wp_table prefix early in the install. - Export your database regularly to an off-site location like Amazon S3, Google Drive or just locally.
- Limit post revisions and clean out overhead.
A bloated database is a larger attack surface and makes recovery harder when a breach occurs.
What You Do After a Breach Matters
If a site is compromised, do not try to delete infected files one by one. The only reliable way to clean a hacked WordPress install is:
- Wipe the entire directory except the uploads folder.
- Reinstall WordPress core from a fresh download.
- Reinstall plugins and themes from official sources.
- Manually audit uploads for any rogue PHP files.
- Rotate all database, FTP, and admin passwords.
This “scorched earth” method ensures you do not leave backdoors behind that will allow the attacker to return.
Build a Fortress, Not a Facade
Security is not a product you buy. It is a process you maintain continuously. If you design a site that is fast but insecure, any scanner or bot can compromise it within minutes whenever a known CVE exists for a component you forgot to update.
Stop thinking of security as optional or superficial. Do the boring work early so you do not spend countless unpaid hours recovering client sites later.
Your clients are not paying for just for pretty designs. They are also paying for a secure and reliable web presence. Build accordingly.
