How to secure WordPress on a VPS

Quick answer: Keep core, themes and plugins updated; use strong unique passwords + 2FA; set correct file permissions (dirs 755, files 644, wp-config.php 640); disable the built-in file editor; add a security plugin (Wordfence or similar) — and harden the server underneath, because on a VPS WordPress is only as safe as the box it runs on.

Overview

WordPress compromises come overwhelmingly from four doors: outdated plugins, weak/reused passwords, hosting-level weaknesses and nulled themes. On a VPS you control every layer, so a modest checklist covers all four. This article is the practical walkthrough; the condensed version lives in the security checklist.

Before you start

• Server basics done: SSH keys, firewall, no root password logins — see securing your VPS.
• A working backup — security without backups is half a plan.

Step-by-step guide

1. Update everything, automatically where sensible: minor core updates are on by default; consider auto-updates for trusted plugins: wp plugin auto-updates enable --all (review what you run first).
2. Accounts: unique admin usernames (not “admin”), strong passwords, 2FA plugin for all administrators, delete unused accounts.
3. Permissions and file safety:

   sudo find /var/www/example.com -type d -exec chmod 755 {} \;
   sudo find /var/www/example.com -type f -exec chmod 644 {} \;
   sudo chmod 640 /var/www/example.com/wp-config.php

   Add to wp-config.php: define('DISALLOW_FILE_EDIT', true);
4. Reduce attack surface: block xmlrpc.php at the web server if unused, limit login attempts (see brute-force protection), remove inactive themes/plugins entirely.
5. Detect: install Wordfence or WPScan-based scanning, and watch auth logs server-side; a weekly wp core verify-checksums catches modified core files.

Common issues

• “Secure” site on an unpatched server: the OS needs updates too — unattended-upgrades handles security patches on Ubuntu/Debian.
• Nulled/pirated themes: the single most common malware source — never install them.
• Over-tight permissions break updates: if WordPress can’t write to wp-content, updates and uploads fail — the web server user must own the tree.

When to contact support

If you suspect an active compromise (defacement, spam pages, traffic anomalies), take a backup snapshot of the current state for forensics and open a ticket — the team can help at the platform level (e.g. network isolation) while you clean the application.

Frequently asked questions

What is the most common way WordPress sites get hacked?

Outdated plugins and themes with known vulnerabilities, followed by weak or reused passwords. Keeping everything updated and enabling 2FA removes the two biggest attack vectors.

Do I still need a security plugin on a hardened VPS?

Yes — server hardening protects the box, while a security plugin watches the application layer: login abuse, file changes and known-vulnerable components inside WordPress itself.

Which file permissions should WordPress use?

Directories 755, files 644, wp-config.php 640, everything owned by the web-server user (www-data). Never use 777 — it lets any process on the server write your code.

Related articles

• How to protect WordPress from brute-force attacks
• WordPress security checklist
• How to secure your VPS after deployment
• How to configure WordPress backups

Need a hand? Contact Cloud2Y support →