Short answer
- Protect a WordPress site by keeping core, themes and plugins updated and deleting everything you do not use.
- Turn on two-factor authentication for wp-admin and limit login attempts on wp-login.php and xmlrpc.php.
- Set permissions to 755 for directories and 644 for files, never 777, and never install nulled themes or plugins.
- Take a backup before every update and put a WAF at hosting level in front of the site.
- Recommended permissions
- directories 755, files 644, wp-config.php 600
- Endpoints hit by brute force
- wp-login.php and xmlrpc.php
- Constant that blocks the dashboard file editor
- DISALLOW_FILE_EDIT
- Before any update
- full backup, files and database
Where attackers get into a WordPress site
Automated scanners look for plugin versions with published vulnerabilities and exploit them within hours of the announcement, however small the site is. The second route is wp-login.php, where bots try lists of leaked passwords, while xmlrpc.php lets them test hundreds in a single request. The third is the pirated theme, which ships hidden code that opens a shell or injects spam links. Permissions set to 777 complete the picture: any other account on the same server can then write to your files.
What to do, in order of impact
Start with updates, because they close known vulnerabilities. Next comes access: long passwords, 2FA, login limiting and, unless you use the mobile app, xmlrpc.php switched off. Then harden the files: correct permissions, DISALLOW_FILE_EDIT in wp-config.php and no PHP execution inside wp-content/uploads. Finally put a hosting-level WAF in front, which filters malicious requests before PHP starts, and check that the daily backup really restores.
- Delete deactivated plugins and themes instead of just switching them off
- Use a username other than “admin” and a supported PHP version
- Check for security updates every week
What Romanian law says
If the site has forms, customer accounts or a shop, you process personal data and fall under Article 32 GDPR, which asks for technical measures proportionate to the risk. ANSPDCP has fined missing measures in Romania, so an outdated WordPress that leaks customer data is more than a technical problem. A shop that issues invoices through e-Factura must also keep the XML files sent to ANAF, which turns backups into a legal requirement.
WordPress protection measures and what each one blocks| Measure | Attack it stops | Where to configure it |
|---|
| Updates for core, themes and plugins | Exploitation of published vulnerabilities | WordPress dashboard or WP-CLI |
|---|
| 2FA + login limiting | Brute force on wp-login.php | Authentication plugin |
|---|
| Disable xmlrpc.php | Mass password guessing in a single request | .htaccess or the web server |
|---|
| Permissions 755/644, DISALLOW_FILE_EDIT | Writing and editing files from the dashboard | File system, wp-config.php |
|---|
| Block PHP in uploads | Execution of uploaded files | .htaccess or the web server |
|---|
| Hosting-level WAF | SQL injection, XSS, bots | Hosting panel |
|---|
Commands and configuration
Correct permissions for a WordPress installfind /var/www/example.ro -type d -exec chmod 755 {} \;
find /var/www/example.ro -type f -exec chmod 644 {} \;
chmod 600 /var/www/example.ro/wp-config.php
wp-config.php: no file editor in the dashboarddefine('DISALLOW_FILE_EDIT', true);
define('FORCE_SSL_ADMIN', true);
.htaccess in wp-content/uploads: no PHP execution<FilesMatch "\.php$">
Require all denied
</FilesMatch>
Practical examples
WooCommerce shop in Cluj-Napoca
A slider plugin left unpatched for a year let an attacker upload a PHP file into uploads, and the shop began redirecting visitors to gambling pages. Restoring the daily backup, updating and blocking PHP execution in uploads fixed it the same day.
Law firm in Bucharest
The default admin user, with an eight-character password, was guessed through xmlrpc.php. The attacker created a hidden administrator and planted spam links in old posts. Two-factor login and disabling xmlrpc.php stopped it from happening again.
Common mistakes
- Assuming an SSL certificate secures the site, when HTTPS only encrypts transport and does nothing about a vulnerable plugin.
- Installing nulled themes and scanning them with a desktop antivirus, which cannot see obfuscated PHP.
- Setting 777 on wp-content because “that is how uploads work”.
- Updating without a backup and discovering you cannot roll back when a theme breaks.
How 4hosting helps
- cPanel plans include a Let's Encrypt certificate and a daily backup, so recovery after an incident starts from yesterday's copy.
- From the cPanel Advanced plan upwards you have 1 hour of CyberSecurity per month; you request it from the client panel, in the “DevOps Services” section, for example for a permissions audit.
- WAF & DDoS Protection puts OWASP rules in front of the site and filters the bots that hammer wp-login.php.
Related questions
What do I do if my WordPress site has already been hacked?
Take it offline for now, change every password, including the database and FTP ones, restore a backup from before the compromise and update everything before going live again. Check the administrator accounts and the cron entries in wp_options. Without a clean backup, look for recently modified files.
Do I need a security plugin?
One good plugin for 2FA and login limiting is enough if the rest is in place: updates, permissions and a hosting-level WAF. Several overlapping security plugins slow the site down and add no real protection.
How often should I update?
Apply security updates the day they appear, after a backup. Everything else can be batched weekly. Enable automatic minor core updates and check from time to time that the plugins you rely on are still maintained by their authors.