WordPress vs Astro Security: Beyond the Plugin vs Package Meme

I saw a meme the other day that made me stop scrolling.

On one side: a WordPress site drowning under hundreds of plugins. On the other: an Astro site with a package.json that had somehow ballooned to a thousand npm packages. The caption was something like “which one is actually less secure?”

It was funny. It was also incomplete.

I’ve been thinking about this comparison a lot lately, mostly because the default framing (static vs server, or “plugins are bad / npm is bad”) misses the more interesting part: how each platform creates (or avoids) shared, exploitable surfaces. So I sat down and tried to map the real attack surfaces instead of just counting dependencies.

The meme is pointing at something real

WordPress and Astro do have different default shapes.

WordPress ships with a large, well-known set of endpoints and an extensibility model where plugins run with significant privileges inside the same process. A popular plugin that handles file uploads, form submissions, or authentication becomes a shared attack surface across thousands or millions of sites. When it breaks, a lot of people feel it at the same time.

Astro, by contrast, is more of a framework you assemble. You choose what runs on the server, what gets prerendered, which libraries you pull in, and how much custom code you write. A bug in your auth middleware or in a less-common dependency is far more likely to affect only the sites that contain that exact code.

That difference is real. It creates different failure modes.

Standardized surfaces vs idiosyncratic risk

With WordPress, a vulnerability in core or in a widely used plugin is immediately relevant to a large fraction of the installed base. Attackers can write one exploit and scan for it. The same property means a single good fix (or a forced core auto-update) can protect a huge number of sites at once.

With Astro, most of the dynamic behavior is code you (or your team) wrote, or a specific combination of libraries and adapters you chose. There is less mass-exploitation surface. The flip side is that a better auth library appearing in the ecosystem does not automatically fix the one you already integrated. You own more of the implementation, so you own more of the defects.

Neither is automatically “safer.” They fail differently.

Concrete attack surfaces

Let’s look at what an attacker can actually reach.

WordPress (typical dynamic install)

• Login and admin endpoints: /wp-login.php and /wp-admin are constant targets for credential stuffing and brute force. User enumeration via the REST API (/wp-json/wp/v2/users) is trivial.
• REST API and AJAX: The default REST API indexes registered routes (which reveals plugins). Plugins freely add more endpoints. Many historically lacked proper permission checks. XML-RPC is another long-standing vector.
• Plugin and theme code: This is the dominant surface. Plugins run in the same PHP process with access to the database, filesystem, and request lifecycle. Common results include SQL injection, remote code execution via file inclusion or unsafe evaluation, arbitrary file uploads that become webshells, and privilege escalation through missing capability checks.
• Supply chain on production: Plugins are typically installed and updated over HTTP on the live server. A compromised plugin update executes directly in production.

Astro (SSR or hybrid)

• Request header handling: Astro has had real issues with trusting or poorly validating Host, X-Forwarded-Host, X-Forwarded-Proto, and related headers. These have led to SSRF (especially when rendering error pages), middleware path-protection bypasses, and URL pollution that can cause cache poisoning or XSS.
• Rendering pipelines: Unescaped dynamic content inside <script> or <style> tags, unescaped slot names in client directives, and certain attribute handling in server islands have produced reflected XSS.
• Image optimization endpoint (/_image): Domain allowlist bypasses (protocol-relative URLs, data: URLs, path matching flaws) have enabled SSRF and XSS via malicious SVGs.
• Adapters and middleware: Specific bugs have appeared in how adapters or custom middleware process requests.

Pure-static Astro removes most of these live request-processing surfaces. The remaining risks shift elsewhere.

Supply chain timing is different

In the JavaScript world, many high-profile compromises hit the developer machine or CI. Malicious code runs during install or build. If you catch it before deployment, production can stay clean.

WordPress plugins are usually updated on the live server. A compromised release executes in the production PHP process with application privileges. The blast radius is the running site.

Astro projects still pull npm packages, so they inherit build-time risk. WordPress projects that use modern tooling inherit both.

When both go fully static

Both WordPress and Astro can be deployed as completely static sites.

Once you do that, the classic “dynamic application” attack surfaces shrink dramatically. There is no live PHP process evaluating plugin code, and no Node server rendering pages on each request. You are no longer primarily exposed to the framework’s request-handling bugs.

What remains is different:

• Third-party scripts and integrations. A pixel tracker, analytics snippet, chat widget, or A/B testing tool that you embed still runs in the browser. If that third party is compromised, your visitors are affected regardless of whether your HTML is static. This is a client-side supply-chain problem, not a server-side one.
• Your hosting provider. If you deploy the static files to Fly, Railway, Netlify, Cloudflare Pages, or similar, you are still dependent on the security of that platform. Origin compromises, misconfigurations, or platform-level vulnerabilities can still impact you. Static hosting reduces your application surface, but it does not eliminate infrastructure risk.
• Build pipeline and content sources. If your static site is generated from a CMS, a headless content API, or a build that pulls in untrusted data, problems can be baked into the output at generation time.

Static mode changes the shape of the risk; it does not make the site invulnerable.

Practical takeaways

WordPress optimizes for shared, standardized surfaces. This produces high-volume exploitation when something popular is vulnerable, and high-leverage remediation when it is fixed. The quality variance across the plugin ecosystem is large, so the shared surface is often the weak one.

Astro optimizes for smaller shared surfaces and more custom code. This reduces the chance that a single bug takes down thousands of unrelated sites, but it increases the chance that any given site contains unique implementation flaws. Security improvements do not propagate as automatically.

If you need a content management system with a large ecosystem of ready-made features, WordPress’s model (and its risks) may be the practical choice — provided you treat plugins as privileged code and minimize them aggressively. If you prefer to own more of the implementation and keep the live surface small, Astro (especially in static or carefully scoped hybrid mode) shifts the burden onto your code review and dependency practices.

The meme is a decent starting point. The real difference is not the raw count of plugins versus packages. It is how much of the attack surface is shared across the ecosystem, how that code executes, and where in the lifecycle a compromise lands.

Both platforms can be used securely. Both can be used carelessly. The architecture just makes certain kinds of mistakes more or less expensive.