Why a Default WordPress Install Is a Security Liability

Imagine a business owner in Lynchburg gets a new WordPress website built. The developer picks a theme, installs a handful of plugins, hands over the login credentials, and sends the final invoice. The site looks great. The owner is happy. But what neither of them may realize is that within minutes of going live, automated scanning tools have already cataloged the site, tested its login page, and filed it into a database of potential targets shared across networks of bad actors around the world.

This is the reality for every WordPress site on the internet, including those belonging to small businesses across Virginia. The platform that powers roughly 40% of the web comes with a set of default configurations that leave sites vulnerable from the moment they are installed. Not because of bugs or oversights, but because of deliberate architectural choices that have never been revisited.

Ten Things WordPress Leaves Wide Open

A brand-new WordPress installation, with no plugins added and no content published, already presents a significant number of entry points for attackers. These are not edge cases or obscure settings. They are fundamental parts of how the platform operates.

Predictable admin URLs. The administrative dashboard on every WordPress site in existence lives at /wp-admin/ and the login form sits at /wp-login.php. Whether it belongs to a dental practice in Richmond or a Fortune 500 company, the address is identical. Attackers do not need to guess where the front door is located. WordPress tells them.

Unlimited login attempts. There is no built-in mechanism to slow down or block repeated failed login attempts. An automated script can submit thousands of username and password combinations per minute, and WordPress will faithfully process each one. The only bottleneck is the server's processing power.

No built-in two-factor authentication. If someone obtains your admin password through phishing, a data breach on another service, or brute force, nothing else stands between them and full control of your website. Adding 2FA requires installing a separate plugin, which introduces its own set of concerns.

xmlrpc.php ships enabled. This legacy file was originally meant for posting to your blog from desktop applications. In practice, it serves as a brute-force multiplier. A single request to this endpoint can test hundreds of credential pairs simultaneously through its system.multicall method. Most site owners have never heard of it. Every automated attack tool knows exactly where to find it.

The REST API reveals usernames. Anyone can visit /wp-json/wp/v2/users/ on a standard WordPress site and receive a structured list of every user account, complete with usernames. That means half of the information needed to breach an account is freely available without any authentication.

Version numbers are advertised. WordPress inserts its version into the HTML source code through a generator meta tag, into RSS feeds, and into the query strings of its JavaScript and CSS files. When a vulnerability is disclosed for a specific release, attackers can immediately identify which sites are running the affected version without lifting a finger.

Fingerprinting files sit in the webroot. Two files, readme.html and license.txt, are included in every installation. Even if someone removes the version meta tag, these files confirm that WordPress is running and often reveal the exact version number. They are refreshed with every core update.

Upload directories may be browsable. Depending on the server configuration, navigating to /wp-content/uploads/ in a browser can display a full directory listing of every file that has been uploaded to the site. Invoices, internal documents, draft media, client files. All visible, all potentially indexed by search engines.

A code editor is built into the dashboard. WordPress includes a Theme Editor and Plugin Editor that allows anyone with admin access to write and execute PHP code directly through the browser. If an attacker gains admin credentials, they do not need server access to plant a backdoor. The CMS provides a built-in text editor for exactly that purpose.

Database credentials sit in the public directory. The file wp-config.php, which contains your database hostname, username, password, and authentication salts, lives in the web-accessible document root. A misconfigured server or a path traversal flaw in any installed component could expose the contents of this file to the outside world.

Plugins Are the Primary Attack Surface

The default installation vulnerabilities are concerning on their own, but the real risk multiplier is the plugin ecosystem. WordPress hosts more than 60,000 plugins in its official directory, with thousands more sold through third-party marketplaces. Quality ranges from professionally maintained enterprise tools to abandoned side projects that have not seen an update in years.

The fundamental architectural problem is that every WordPress plugin executes with unrestricted PHP access on the server. There is no permission model, no sandboxing, and no capability boundary. A simple contact form plugin operates with the same level of system access as the operating system itself. A photo gallery plugin can read your database credentials. A deactivated-but-not-deleted SEO tool can be exploited to run arbitrary commands.

This is not a theoretical concern. Major plugins with millions of active installations have been compromised repeatedly:

• Elementor (5 million+ installs): A remote code execution vulnerability in 2023 allowed anyone with basic contributor access to execute arbitrary code on the hosting server.
• Contact Form 7 (5 million+ installs): Cross-site scripting flaws enabled attackers to inject malicious code into form submissions that would execute when administrators reviewed them.
• WP File Manager (700,000+ installs): An unauthenticated file upload vulnerability in 2020 required no login at all. Attackers uploaded web shells to hundreds of thousands of sites within hours of the disclosure.

These are not fringe tools maintained by anonymous developers. They are among the most widely used plugins in the entire ecosystem. And for most of WordPress's history, automatic plugin updates were not even available. That feature did not arrive until WordPress 5.5 in August 2020, and even then it remains opt-in on a per-plugin basis rather than a global default. Sites installed before that date, or sites where the owner never toggled the setting, are running whatever plugin versions were current the last time someone manually clicked "Update."

For a Virginia small business, whether it is a law firm in Roanoke, a restaurant in Charlottesville, or a contracting company in Lynchburg, that level of exposure means customer data, financial records, and internal communications could be accessible to anyone who exploits a gallery plugin that was installed three years ago and forgotten.

Why Automattic Will Not Address This

It would be reasonable to expect that a platform used by hundreds of millions of websites would eventually ship meaningful security defaults. But there are structural reasons why that is unlikely to happen.

The plugin marketplace is the core business advantage. WordPress dominates market share specifically because of the plugin ecosystem. Need a booking system? Plugin. Need SEO optimization? Plugin. Need security hardening? Also a plugin. Wordfence, one of the most popular security plugins, has over four million active installs. It exists entirely because WordPress core does not provide adequate protection. If the platform shipped robust security out of the box, an entire category of commercial plugins would become redundant, and Automattic has no incentive to undermine that revenue stream.

Backwards compatibility takes priority over security. WordPress still maintains support for PHP 7.4, a version whose official security support ended in November 2022. The reason is straightforward: shared hosting providers, which represent a huge portion of the WordPress market, are slow to upgrade their PHP versions. Dropping support for outdated PHP would break millions of existing sites. So WordPress continues to support software that its own language maintainers have declared unsafe to run in production.

The platform was engineered for the cheapest hosting tier. WordPress was designed from the beginning to operate on budget shared hosting plans. That architectural constraint rules out background workers, process isolation, sophisticated rate limiting, and many other security mechanisms that require dedicated server resources. Every security feature must work within the limitations of a server shared with hundreds of other accounts, and that reality caps what can meaningfully be built into the platform.

This is not a gap in engineering talent. The WordPress team has capable developers who could implement rate limiting, two-factor authentication, and plugin isolation. The barrier is commercial, not technical. Hardening the defaults would disrupt the plugin economy, fracture backwards compatibility, and alienate the shared hosting providers that distribute WordPress to millions of new users each year.

How Modern Frameworks Approach Security

If your only experience with web platforms is WordPress, it might seem normal for security to be an afterthought that requires third-party tools. Other frameworks take a fundamentally different approach.

Laravel, the most widely used PHP framework, includes cross-site request forgery protection on every form, rate limiting as configurable middleware, Argon2 password hashing, and a complete authentication system with multi-factor support. These protections are active from the first line of code.

Django, the leading Python web framework, enables CSRF validation, automatic HTML escaping to prevent cross-site scripting, parameterized database queries to block SQL injection, and clickjacking protection as part of its default middleware stack. The design philosophy is that security should be on unless you explicitly choose to disable it.

Rails has provided CSRF tokens, parameterized queries, encrypted credentials, and secure session management since version 5. Content security policies and cookie security are configured by default.

None of these are paid add-ons or premium tiers. They are baseline features included in the framework because the developers who built them decided that security should not be optional and should never depend on a third-party extension. WordPress could adopt the same approach. It has chosen a different path.

What This Means for Virginia Business Owners

If your company operates a WordPress website, there are four things worth understanding clearly.

1. An out-of-the-box WordPress site is not production-ready. Installing WordPress, activating a theme, and adding content does not produce a secure website. It produces a starting point that requires deliberate hardening work. If your web developer or agency delivered a WordPress site without addressing the items listed above, your business is exposed right now. The majority of agencies skip the security layer because clients are not willing to pay for work that is invisible to them.

2. Every plugin represents a trust decision. Installing a plugin means granting a third-party developer unrestricted access to your server. You are relying on their coding standards, their commitment to releasing timely patches, and their willingness to keep maintaining the project. When a solo developer walks away from a plugin that has a hundred thousand active installations, those hundred thousand sites become targets with no fix on the horizon.

3. The cost of a breach is not theoretical. IBM's annual Cost of a Data Breach Report puts the average impact for a small business at approximately $120,000 in direct costs. That figure does not account for reputational damage, lost client relationships, or the operational disruption of rebuilding from scratch. For a small or mid-sized Virginia business, that kind of expense can be existential. Investing in the right platform upfront is substantially cheaper than recovering from an incident after the fact.

4. Secure alternatives are available and practical. Static site generators, custom-built applications, and modern frameworks provide the security that WordPress does not include. We cover this transition in detail in our posts on why we ditched WordPress for Astro and why static sites are back. A static HTML website has no login page to target, no database to inject into, no plugins executing server-side code, and no PHP processing requests. That architecture is not suitable for every project, but for the vast majority of business websites, including those belonging to service companies, professional practices, and local retailers across Virginia, it delivers better web design performance, lower maintenance costs, and a dramatically smaller attack surface. For more on what goes into protecting a business site, see our website security checklist for Virginia businesses.