PHP Exposed: Two Major Vulnerabilities Threaten 70% of Websites, Including WordPress and Other Platforms

PHP, the backend language powering nearly 70% of the internet's websites, is once again under the spotlight due to security issues. Security researchers have discovered two high-severity vulnerabilities in the PHP core, and the scope of impact is broad enough to keep administrators of half the internet up at night.

Vulnerability Overview: Two Flaws, One Storm

According to security media reports, the vulnerabilities discovered this time exist in the PHP language itself, not in a specific framework or plugin. This means any server running an affected PHP version may be exposed to the attack surface. PHP's ubiquity determines the severity of the problem—WordPress, Drupal, Wikipedia, and even high-traffic communities like DeviantArt and 4Chan all rely on PHP at their core. The report mentions that DeviantArt and 4Chan were forced to temporarily go offline after the vulnerability disclosure to assess and patch the risk.

The specific technical details of the two vulnerabilities are not extensively covered in the original source, but given the characterization of "putting a large swath of the internet at risk," both the exploitation threshold and potential impact should not be underestimated. For businesses built on PHP, this is not a warning that can be ignored.

What Is a "PHP Core Vulnerability"

As an interpreted language, PHP's execution environment consists of the Zend engine, standard library, and various built-in extensions—this runtime as a whole is referred to as the PHP core. Core-level vulnerabilities are fundamentally different from WordPress plugin vulnerabilities: the latter only affect sites with a specific plugin installed, while the former, once triggered, can affect any PHP application that calls the relevant functions—attackers may not even need to touch business code.

Common high-severity types include memory out-of-bounds, use-after-free, and integer overflow. These are mostly caused by C language implementation details and can lead to remote code execution or information disclosure. Since PHP is embedded in different runtime modes such as Apache and Nginx+FPM as a module, the exploitability of the same vulnerability varies across deployments. This is why assessing the impact surface requires considering the actual hosting environment.

Why PHP Vulnerabilities Always Have a "Ripple Effect"

PHP's ecological niche determines that its security incidents have an amplifying effect. It is not a niche tech stack but the default choice for shared hosting, CMS systems, and established web applications. A flaw at the PHP runtime level propagates down the dependency chain, ultimately affecting millions of unrelated websites.

This structural risk has two implications. The first is patching speed: PHP version upgrades often require coordination among hosting providers, operations teams, and application developers—the chain is long, inertia is strong, and the vulnerability window can be lengthy. The second is visibility: many small and medium-sized sites are maintained by non-professional teams who may not even know which PHP minor version they are running, making it impossible to determine their exposure.

PHP Version Fragmentation and Lifecycle

The PHP community follows a branch-based maintenance strategy: each major version (e.g., 8.1, 8.2, 8.3) receives about two years of active support, then enters a security-fix-only phase, and eventually reaches end-of-life (EOL). Once a branch is EOL, no official patches are released, and sites continuing to use that version will have no official fix available when new vulnerabilities emerge.

The problem is that shared hosting providers and distribution repositories often stay on older branches for compatibility, resulting in many sites running unsupported PHP. When vulnerabilities are disclosed, these sites can neither get patches nor complete cross-version migrations in a short time, because legacy code may depend on removed functions or behaviors. This version fragmentation is the structural reason why patching windows are prolonged. The reason "confirming the minor version number" is important is precisely that security fixes are typically backported only to still-supported branches.

Practical Reminders for Developers and Site Operators

Several actionable defense lines can be drawn from this incident. First, promptly confirm the PHP version used in production environments and check official security advisories to determine if you are affected. Second, prioritize upgrades through package managers or official channels, avoiding branches that have reached end-of-life. Third, for sites using CMS platforms like WordPress and Drupal, monitor upstream security notices, as CMS vendors typically follow up with compatibility guidance.

Another often-overlooked path is runtime isolation. Even if you cannot immediately upgrade PHP, you can reduce the attack surface through web application firewalls, least-privilege configurations, and input validation layers. Security is never a single action but a combination of defense-in-depth measures.

Why WAF and Least Privilege Can "Buy Time"

A Web Application Firewall (WAF) performs rule matching before requests reach the PHP runtime, intercepting known attack signatures such as malicious request parameters or anomalous serialized payloads. It cannot fix underlying flaws but can reduce the probability of exploitation before official patches are deployed.

Least-privilege configurations work similarly: running PHP-FPM as a non-root user, restricting file access scope via open_basedir, and disabling unnecessary dangerous functions (such as eval and system) can significantly reduce the blast radius after a successful exploit. The input validation layer reduces opportunities for untrusted data to enter sensitive functions from the application side. Together, these three form defense in depth: the WAF blocks at the entrance, privilege restrictions contain the consequences, and input validation reduces the trigger surface. It must be emphasized that these are mitigation measures; upgrading to a supported version remains the fundamental solution.

The Security Paradox of Open Source Infrastructure

PHP's situation reflects a common dilemma of open source infrastructure: the more widely used it is, the more likely it is to attract attackers, yet maintenance resources may not match the scale of users. PHP supports a significant portion of the internet's backbone, and the returns on its security investment are public goods—individual companies lack the incentive to pay for the entire industry.

These two vulnerabilities will not be the last. For technology decision-makers, incorporating PHP version management into routine security hygiene processes is more valuable than emergency response during each crisis. The three letters PHP actually test the entire ecosystem's response speed and willingness to collaborate.

One-line Summary

Two high-severity vulnerabilities in the PHP core affect about 70% of websites, testing the ecosystem's response speed.

Paragraph Summary

Security researchers have discovered two high-severity vulnerabilities in the PHP language core, affecting approximately 70% of websites using PHP. Because the flaws are at the runtime level rather than in a specific framework or plugin, platforms relying on PHP—including WordPress, Drupal, Wikipedia, DeviantArt, and 4Chan—are all exposed to risk, with some sites forced to temporarily go offline. The article analyzes the amplifying effect of PHP vulnerabilities: patching requires coordination among hosting providers, operations teams, and developers—the chain is long and inertia is strong—while many small and medium-sized sites do not even know the specific version they are running. The article recommends promptly checking PHP versions and upgrading to supported branches, while building defense in depth with WAF, least-privilege configurations, and input validation, and incorporating PHP version management into routine security processes.