PHP Vulnerabilities

A document summarizing the types, causes, and countermeasures of security flaws that repeatedly appear in PHP applications.

PHP Vulnerabilities

Overview

PHP is a server-side scripting language that powers a significant portion of websites worldwide, but its design flexibility—such as dynamic typing and automatic type conversion, include-based template processing, and long-maintained legacy functions—has contributed to various security flaws. “PHP vulnerabilities” is a concept encompassing the types of vulnerabilities that repeatedly appear in PHP applications, their root causes, and defense techniques.

Key points

Representative vulnerability types

SQL injection: Occurs when user input is inserted into queries through string concatenation. It is mostly prevented with prepared statements in PDO and mysqli.
XSS (Cross-Site Scripting): Occurs when user input is output as-is via echo; the basic countermeasure is output escaping with htmlspecialchars($s, ENT_QUOTES, 'UTF-8').
File inclusion (LFI/RFI): When user input enters include or require, it can lead to local or remote file execution. Whitelists and realpath() validation are required.
OS command injection: Occurs when input is passed to system, exec, shell_exec, passthru, popen, proc_open, etc.; using escapeshellarg() is recommended.
PHP object injection (deserialization): When unserialize() is applied to untrusted data, attacks can exploit magic methods (__wakeup, __destruct). The allowed_classes option or replacing it with json_decode() is necessary.
Type juggling: Loose type conversion in == comparisons can cause authentication bypass, so using === is recommended.
File upload vulnerabilities: A representative case is uploading a web shell due to insufficient extension and MIME validation.
Session fixation and hijacking: Regenerating the session ID (session_regenerate_id) and setting cookie attributes (HttpOnly, Secure, SameSite) are key.

Language and runtime-level causes

In the past, register_globals and magic_quotes_gpc distorted input validation and caused large-scale vulnerabilities, and each was removed in PHP 5.4. The /e modifier of preg_replace was removed in PHP 7.0, and create_function() was deprecated in 7.2 and removed in 8.0. Since 8.0, assert() does not evaluate strings as code. Nevertheless, features such as eval(), dynamic variables ($var), and extract() remain dangerous. Also frequently noted are deserialization via the phar:// stream wrapper and exposure of path and configuration information due to display_errors being enabled.

Security changes by version

PHP 5.4 removed global variables and magic quotes, and PHP 7.0 cleaned up execution operators and the /e modifier, improving safety along with performance. PHP 8.0 introduced JIT along with removal of create_function and strengthening of the type system; 8.1 added enums, 8.2 announced deprecation of dynamic properties, and 8.3 and 8.4 continued typing and security-related cleanup. Older 5.x and 7.x branches are at greater structural risk because patches are not provided after end-of-life (EOL).

Defense techniques

The principle is to separate input validation and output escaping. Use prepared statements for databases, context-specific escaping for HTML, and argument escaping for the shell. Normalize file paths with whitelists and basename()/realpath(), and replace deserialization with signed tokens or JSON whenever possible. Setting open_basedir, display_errors=Off, least-privilege execution accounts, PHP-FPM pool isolation, and container-based sandboxing are also effective. It is safer to check dependencies with composer audit and use the CSRF, ORM, and validation features provided by frameworks (Laravel, Symfony).

Real-world cases

Representative examples include file inclusion and SQL injection vulnerabilities repeatedly reported in WordPress plugins and themes, numerous CVEs in phpMyAdmin, remote code execution in PHPUnit's eval-stdin.php (CVE-2017-9841), and a deserialization vulnerability in Laravel Ignition (CVE-2021-3129). In 2024, CVE-2024-4577, which allowed arbitrary code execution via argument injection in PHP-CGI on Windows environments, became a major issue.

Latest trends

As of 2024–2025, with the end of support for PHP 8.1 approaching, migration to 8.2 or later has become a security recommendation, and PHP 8.4 was officially released in November 2024. After CVE-2024-4577, inspections of PHP-CGI and Windows distribution configurations are being emphasized, and supply chain attacks targeting the Composer ecosystem (malicious packages, typosquatting) are increasing. Adoption of static analysis (SAST), dependency scanning, and runtime application self-protection (RASP) tools is increasing, and automated vulnerability scanning and patch management for legacy CMSs and plugins have emerged as key practical tasks.