WordPress Out of the Box: Why Your Site Is Exposed Before You Even Launch
You just installed WordPress. Fresh hosting account, clean database, default theme. Maybe you clicked a one-click installer on your shared hosting plan. You haven’t even picked a color scheme yet.
Within 90 seconds, bots have already found your login page. Within 10 minutes, automated scripts are hammering /wp-login.php with password lists. Within an hour, your site has been fingerprinted, cataloged, and added to a target database shared across criminal networks.
This isn’t hypothetical. If you run a business in Fort Lauderdale, Miami, or anywhere in South Florida and your site runs WordPress, this is happening to you right now. You just don’t see it because nobody configured logging.
Here’s everything WordPress leaves exposed the moment you install it — and why Automattic has no intention of fixing it.
What’s Exposed on a Default Install
A vanilla WordPress installation — no plugins, no customization, nothing but the core — ships with at least ten known security weaknesses. Not bugs. Design decisions.
The login page is at a predictable URL. Every WordPress site on the planet puts its admin login at /wp-admin/ or /wp-login.php. Attackers don’t need to search for it. It’s the same address on your Fort Lauderdale bakery’s website as it is on a Fortune 500 corporate blog. Automated scanners hit these paths first on every domain they probe.
There’s no login rate limiting. Out of the box, WordPress allows unlimited password attempts. No lockout after 5 tries. No CAPTCHA. No delay. An attacker can submit 10,000 passwords per minute against your admin account and WordPress will process every single one. The only thing slowing them down is your server’s CPU.
No two-factor authentication. WordPress has never shipped with 2FA built in. If your admin password is compromised — through phishing, credential stuffing, or brute force — there’s nothing else between the attacker and your entire site. You need a plugin for 2FA. We’ll get to the plugin problem.
xmlrpc.php is enabled by default. XML-RPC was designed for remote publishing back when people blogged from desktop apps. In 2026, it’s a brute-force amplification tool. A single XML-RPC request can test hundreds of username/password combinations at once using the system.multicall method. Most site owners don’t know this file exists. Every attacker does.
The REST API exposes your usernames. Visit /wp-json/wp/v2/users/ on any default WordPress site and you’ll get a JSON list of every user account, including their username (the slug field). That’s half of the login credentials handed to attackers for free. No authentication required.
The version number is broadcast publicly. WordPress injects its version into the HTML <meta> tag (<meta name="generator" content="WordPress 6.7" />), into RSS feeds, and into script query strings. When a new vulnerability is disclosed for a specific version, attackers don’t have to guess which sites are affected — WordPress tells them.
readme.html and license.txt confirm WordPress is present. Even if you remove the generator tag, these two files sit in the webroot and confirm the CMS. readme.html even displays the exact version number. They ship with every install and survive every update.
Directory listing on /wp-content/uploads/. On many default server configurations, browsing to /wp-content/uploads/ shows a file listing of every image, PDF, and document ever uploaded to the site. Internal documents, client files, draft content — all browsable, all indexable by Google.
The admin panel includes a code editor. WordPress ships with a built-in Theme Editor and Plugin Editor that lets anyone with admin access write and execute arbitrary PHP directly from the browser. One compromised admin account and the attacker doesn’t need SSH — they can write a backdoor through the WordPress dashboard.
wp-config.php sits in the webroot. Your database credentials, authentication keys, and salt values live in wp-config.php, which sits in the publicly accessible document root. A single misconfiguration in your web server — or a path traversal vulnerability in any plugin — and those credentials are exposed.
That’s ten attack surfaces. On a site with zero plugins, zero customization, and zero content. Before you’ve written a single word.
The Plugin Problem
If the default install is a house with unlocked doors, plugins are the windows you’re propping open yourself.
WordPress has over 60,000 plugins in its official directory. Thousands more are sold through third-party marketplaces. The quality ranges from enterprise-grade to a college student’s weekend project that hasn’t been updated since 2019.
Here’s the architectural problem: every WordPress plugin runs with full PHP execution privileges on your server. There’s no sandboxing, no permission system, no capability restrictions. A contact form plugin has the same server access as your operating system. A slider plugin can read your database credentials. An abandoned SEO tool can be hijacked to execute arbitrary code.
This isn’t theoretical. These are real vulnerabilities that hit millions of sites:
- Elementor (5M+ active installs): Authenticated remote code execution in 2023. Any user with contributor-level access could execute arbitrary code on the server.
- Contact Form 7 (5M+ active installs): Stored cross-site scripting (XSS) allowing attackers to inject malicious scripts into form submissions that execute when admins view them.
- WP File Manager (700K+ active installs): Unauthenticated arbitrary file upload in 2020. No login required. Attackers uploaded web shells to hundreds of thousands of sites within hours of disclosure.
These aren’t obscure plugins. They’re the most popular tools in the ecosystem. And for years, WordPress didn’t even auto-update plugins by default. Automatic plugin updates weren’t introduced until WordPress 5.5 in August 2020 — and even then, they’re opt-in per plugin, not enabled globally. Sites installed before that date are still running whatever version was current when the owner stopped paying attention.
The average WordPress site runs 20-50 plugins. Each one is a separate codebase, maintained by a separate developer, with a separate update cycle and a separate security track record. One bad plugin is all it takes for a full server compromise. Not a defacement — a compromise, meaning the attacker has the same access to your server that you do.
For a Miami law firm or a Fort Lauderdale medical practice, that means patient data, client records, and financial information accessible to anyone who exploited a slider plugin you installed three years ago and forgot about.
Why WordPress Doesn’t Fix This
You might assume these are oversights that Automattic will eventually address. They won’t. There are three structural reasons.
The plugin ecosystem is their competitive moat. WordPress’s market share exists because of plugins. Need a contact form? Plugin. Need SEO tools? Plugin. Need security? Plugin. Wordfence alone has over 4 million active installs — a security plugin that exists specifically because WordPress’s core is insecure. If WordPress shipped real security by default, Wordfence and dozens of competing security plugins become unnecessary. That’s a multi-million-dollar ecosystem Automattic doesn’t want to disrupt.
Backwards compatibility is sacred. WordPress still officially supports PHP 7.4, a version that reached end-of-life in November 2022 and receives no security patches. Why? Because shared hosting providers — WordPress’s core audience — are slow to upgrade PHP versions. Breaking backwards compatibility would break millions of sites, generate millions of support tickets, and risk losing market share to competitors. So WordPress maintains support for software that its own language maintainers have declared insecure.
The platform is designed for the cheapest hosting. WordPress was built to run on $3/month shared hosting. That means no background workers, no queue systems, no sophisticated rate limiting, no process isolation. The security architecture can’t exceed what a bottom-tier GoDaddy plan can support. Every security feature has to work within the constraints of a server shared with 500 other sites, which means meaningful security features simply can’t be implemented at the platform level.
This isn’t a technical problem. WordPress has talented engineers who could build rate limiting, 2FA, and plugin sandboxing. It’s a business problem. Fixing the defaults would disrupt the plugin economy, break backwards compatibility, and alienate the shared hosting market. All three are existential threats to WordPress’s business model.
What Modern Platforms Do Differently
If you’ve only ever worked with WordPress, you might assume every platform ships this way. They don’t.
Laravel (PHP) ships with CSRF protection on every form, bcrypt/Argon2 password hashing, rate limiting middleware, and an authentication scaffolding system that includes 2FA support. Out of the box.
Django (Python) enables CSRF protection, XSS escaping, SQL injection prevention, and clickjacking protection by default. The security middleware is on unless you explicitly turn it off. The philosophy is “secure by default, opt out if you know what you’re doing.”
Rails (Ruby) has shipped with CSRF tokens, parameterized queries, and encrypted credentials since version 5. Session management, cookie security, and content security policies are configured by default.
These aren’t premium features. They’re the baseline. They ship with the framework because the framework authors decided that security is not optional and shouldn’t require a third-party plugin.
WordPress could do this. It chooses not to.
What This Means for Your Business
If you’re running a business in South Florida on a WordPress site, here are four things you need to understand:
1. A default WordPress install is not a finished product. It’s a starting point that requires significant hardening before it’s safe to face the internet. If your developer installed WordPress, added a theme and some plugins, and called it done — your site is exposed. Most agencies never touch the security layer because the client won’t pay for work they can’t see.
2. Every plugin is a liability. Each plugin you install gives a third-party developer root-equivalent access to your server. You’re trusting their coding practices, their update schedule, and their commitment to maintaining the project. When a solo developer abandons a plugin with 100,000 active installs, those 100,000 sites become targets with no patch coming.
3. You’re paying for security either way. Either you pay upfront for a platform and team that builds security into the foundation, or you pay later in incident response, data breach notification, customer trust, and Google blacklist recovery. A security breach for a small business averages $120,000 in direct costs according to IBM’s Cost of a Data Breach Report. That doesn’t include reputation damage, lost customers, or the weeks of downtime while you rebuild.
4. Alternatives exist. Static site generators, modern frameworks, and custom-built solutions ship with the security WordPress refuses to include. A static HTML site has no login page to attack, no database to inject, no plugins to exploit, and no PHP to execute. It’s not the right fit for every project, but for the majority of South Florida businesses — restaurants, law firms, medical practices, service companies — a static site is faster, cheaper to maintain, and orders of magnitude more secure.
The Bottom Line
A default WordPress installation is a storefront with the doors unlocked, the alarm disabled, and a sign out front listing the brand of every lock you didn’t install. The bots already have the address. They’re already testing the handle.
You can spend the next five years installing security plugins, running updates, monitoring logs, and hoping your plugin developers don’t abandon their projects. Or you can build on a platform where the doors don’t exist in the first place.
That’s not a sales pitch. That’s architecture.