Why Upgrading PHP Matters for WordPress Security

Milan Petrović has been working with WordPress since 2007—building plugins (many for bbPress), running Dev4Press, and more recently joining Freemius as a full‑stack developer. At WordCamp Europe he presented “Secure by design: hardening plugins with PHP 8.x,” a practical call to modernize PHP usage across the WordPress ecosystem. The core message: running legacy PHP is a security and performance liability, and moving to modern versions like PHP 8.x gives you native protections, speed gains, and lower memory use.

Why PHP version matters

Many site owners see a PHP version number once in a hosting control panel and wonder why it matters. In truth, the PHP version determines the language features available, the security patches you receive, and the runtime behavior of your code. Newer PHP versions include both defensive language changes and performance optimizations that reduce attack surface and resource consumption.

Two points Milan emphasized:

• Security: Old PHP branches have thousands of open bug reports (Milan cited 3–4k open, confirmed bugs on older branches). Once a branch reaches end‑of‑life, those bugs won’t be fixed and details are public—making automated exploitation far easier. Some vulnerabilities operate below the application layer and affect any PHP site, not just WordPress.
• Performance and resources: Every PHP version brings performance improvements. Milan pointed out that recent PHP releases cut memory usage and increase throughput; for example, newer PHP versions can be 5–10% faster with each update and later releases (like 8.5) show much larger improvements—he noted up to a 50% performance gain compared with 7.4 in his tests. For hosts this translates to cost savings and capacity gains.

Why WordPress still supports old PHP

WordPress has a long history of prioritizing backward compatibility. That has driven adoption by keeping WordPress usable on inexpensive hosting and older server stacks. But it also means WordPress Core and many plugins continue to support PHP versions that are past their prime. While compatibility helped the ecosystem grow, it has slowed adoption of safer, more efficient PHP patterns.

What to watch out for with legacy PHP

• Public, unpatched bugs: End‑of‑life branches leave thousands of issues unaddressed and readable by attackers. This increases the likelihood of automated exploitation.
• Inconsistent server builds: Some hosts patch or custom‑build PHP for stability or performance. That can temporarily reduce risk, but it also introduces divergence from the official PHP implementation and unpredictability for developers.
• Library pressure: Third‑party PHP libraries often move faster than the WordPress ecosystem and may require newer PHP versions. Relying on modern libraries can effectively force plugin authors to upgrade their PHP requirements.

Who should act—and how

Milan’s message is aimed at everyone: hosting companies, plugin and theme developers, agencies, and site owners.

• Hosting companies: They can accelerate upgrades across many sites and collect big performance and cost benefits. Adoption is costly, and they must handle support when changes break sites, but the upside is large: fewer resources per site and improved security posture.
• Developers and agencies: Use PHP 8 features to harden code (strict typing, modern patterns, attributes, and other mitigations). Update plugins gradually—declare a reasonable minimal PHP version (Milan uses 8.0 for his plugins) and refactor incrementally.
• Site owners: Treat your site like maintained equipment. Regular updates, testing, and staged upgrades reduce risk. If you’re running an old plugin or theme that is no longer maintained, replace or rebuild it rather than keep it on an unsafe platform.

A practical demonstration: Vulnerability Lab

To make the differences visible, Milan created the Vulnerability Lab plugin (available on GitHub). It demonstrates how the same vulnerable code behaves differently on older vs newer PHP versions—showing practical examples like authentication bypasses and server‑side request forgery that succeed on legacy PHP but are neutralized by modern PHP protections. The plugin also shows memory and performance differences, making it useful for developers and agencies to illustrate risk and justify upgrade work to clients.

Recommendations and next steps

• Gradual modernization: You don’t have to convert everything at once. Start with safer defaults, stricter typing, and small refactors. Over time you can take advantage of newer language features.
• Community leadership: Milan suggests WordPress could help by moving faster to modern minimums (for example declaring PHP 8.x as the new baseline), which would nudge plugin authors and hosts to follow.
• Use reliable sources: Follow php.net for upcoming features and changes; it’s the best place to learn what each new PHP release brings. Also watch third‑party library requirements—those often force changes quicker than Core.
• Test and communicate: Hosts and agencies should provide testing environments across PHP versions so site owners and developers can validate changes before production upgrades.

Final thoughts

Upgrading PHP is both a security imperative and a performance opportunity. The path forward is collaborative: WordPress Core, plugin authors, hosts, and site owners all share responsibility. Milan’s Vulnerability Lab and talk aim to make the risks tangible and provide concrete patterns for hardening. Start small, test often, and use the native features of modern PHP to build more secure, efficient WordPress sites.

If you want to explore Milan’s examples, find the Vulnerability Lab plugin on GitHub and watch his WordCamp Europe presentation via the WP Tavern show notes. He’s open to questions and contributions and encourages everyone to work together to move the ecosystem forward.