PHP runs a huge share of the websites you visit, including WordPress, Drupal, Magento, Laravel apps, and countless small business sites. That popularity makes it a favourite target. Attackers don’t need to hunt for a rare bug. They scan the internet for the same common mistakes, over and over.
On 21st October, the individuals who maintain PHP called for an emergency resolution for two key security vulnerabilities. Security teams call them PHP2Shell (also called php2shell), tracked as CVE-2026-109618 and CVE-2026-109619. Simply put, these PHP vulnerabilities allow unauthenticated remote code execution and memory corruption across web servers running PHP. Hence, staying updated is important.
PHP itself is not “bad.” Most problems come from how code is written, how old the software is and how carelessly a server is set up. Here are the common PHP vulnerabilities with simple fixes.
Common PHP Vulnerabilities and Their Fixes
SQL Injection (SQLi)
What it is: Your website talks to a database. If you paste user input straight into a database query, an attacker can type special text that changes what the query does. They could log in without a password, read private data or delete tables.
Dangerous code:
Php $result= $db->query("SELECT * FROM users WHERE email= $email");
Prepared statements (safe code) :
PHP"
$stmt = $pdo->prepare('SELECT * FROM users WHERE email=?');
$stmt->execute(array($email))
As a rule of thumb, you should never build queries by concatenating user input. Use prepared statements always.
Cross Site Scripting (XSS)
On the subject of: The site displays user supplied text including a comment or search term without cleaning. Attacker types in JavaScript rather than normal text. When other visitors load the page, the script runs in their browser and can steal sessions, redirect them or show fake login forms.
Risky code:
Php
Echo “Hello,”. $_GET[‘name’]
Safe code:
Php
Echo "hello". htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8');
Rule of thumb: Escape every output that you write to a screen. Blade and Twig do this by default.
(LFI and RFI) Including Files
What it is: PHP can include or require files. If the user supplies the filename, the attacker might be able to trick your site into including files it should not include, such as server config files (Local File Inclusion). It can even import code from another website (Remote File Inclusion) in some configurations.
High risk code:
Php
Include $_GET[‘page’] “.php”;
Safer approach:
Php
$allowed = [‘home,’ ‘about,’ ‘contact’];
$page= in_array($_GET[‘page’], $allowed, true)? $_GET[‘pahe’] : ‘home’;
include_DIR_ . “/pages/$page.php”;
Rule of thumb: Use an allow-list of permitted pages. Never trust a filename from the user.
Insecure File Uploads
What it is: Many sites let users upload profile pictures or documents. If the site doesn’t check the file properly, an attacker can upload a PHP script disguised as an image. Once uploaded, they visit its URL and take control of your server. This is one of the most common ways websites get fully hacked.
How to protect yourself:
Check the real file type on the server, not just the extension.
Rename uploaded files to random names
Store uploads outside the web root, or block PHP execution in the upload folder.
Limit file types and file size.
RCE (Remote Code Execution) & Unsafe Methods
eval(), system(), exec(), shell_exec(), passthru() – running code or system commands. If they can be reached by user input, an attacker can run his own commands on your server.
Rule of thumb: steer clear of these functions. If you truly need one, strictly validate input and use escapeshellarg(). Many hosts disable them in php.ini using disable_functions.
Real world example 2024: PHP CGI mode on Windows critical vulnerability (CVE-2024-4577) It enabled attackers to run commands on servers via a specially crafted request. It was exploited at scale within days of disclosure, which shows how fast attackers move once a bug becomes public.
Insecure Deserialization (Object Injection)
What it is: PHP’s unserialize () converts stored text back into objects. If an attacker controls that text, they can create objects that cause malicious actions in your code or in popular libraries. Often this leads to code execution and is found in legacy plugins and frameworks.
Rule of thumb: Don't ever call unserialize() on data that a user can touch (cookies, form fields or URL parameters). Use json_encode() and json_decode() instead.
Cross Site Request Forgery (CSRF)
What it is: An attacker tricks your browser into making a request on your behalf (like changing your password or transferring money) while you’re logged into a site, just by getting you to open a malicious page.
Protect yourself: Add a unique CSRF token to each form, verify it server-side. Also set the SameSite attribute on cookies. This is generally built-in feature of most frameworks so make sure it is on.
Weak Authentication and Session Management
What it is: Plaintext or old hash passwords (like MD5), unlimited login attempts, not regenerating session IDs after login, no two-factor authentication.
Secure password management:
Php $hash = password_hash ( $password , PASSWORD_DEFAULT ) ;
//subsequently:
If (password_verify($input, $hash)) /*login OK*/
Also session_regenerate_id(true) after login and make cookies secure and HttpOnly.
Juggling of Types and Loose Comparisons
What it is: PHP is a loosely typed language, and that looseness can come back to bite. This is especially true for the loose == operator, which in PHP (older versions) equates different values. Strings like “0e123” can be seen as the number zero, which has led to login and hash-check bypasses.
Rule of thumb: Use == instead of ==. For comparing hashes or tokens, use hash_equals().
Outdated PHP, Plugins and Themes
This is the biggest problem of all. A large number of real-world hacks aren’t clever. They simply use known bugs in software that was never updated.
Old PHP versions stop getting security fixes once they reach end of life, so any new bug stays open forever. Check php.net’s supported versions page to see where your version stands. WordPress, Joomla and Drupal plugins and themes are a leading source of breaches, especially abandoned ones. Leftover test files, backup files like config.php.bak and exposed env files leak passwords and API keys.
Rule of thumb: Update regularly, delete what you don’t use, and never leave backups or debug files on a live server.
Misconfiguration and Information Leaks
Small server settings cause big problems:
Display_errors = On in production shows attackers file paths and database details. Turn if off and log errors privately.
Expose_php = On advertises your PHP version. Turn it off.
Directory listing enabled lets anyone browse your folders.
Weak file permissions let one hacked site infect others on the same server.
A Quick Security Checklist
Use a currently supported PHP version and update often
Use prepared statements for every database query
Escape all output with htmlspecialchars()
Validate and sanitize every piece of user input.
Lock down file uploads
Hash passwords with password_hash() and offer two-factor login.
Add CSRF protection to all forms
Keep display_errors off in production
Remove unused plugins, themes, backups and test files.
Use HTTPS everywhere and add security headers
Use a Web Application Firewall (WAF) and take regular backups
Scan your code and dependencies with tools like Composer’s composer audit, PHPStan or Psalm.
Final Thoughts
Most PHP attacks are not sophisticated. They work because of the same handful of mistakes: trusting user input, skipping updates and leaving defaults in place. The good news is that the fixes are well known and mostly simple. Treat all user input as untrusted, keep everything updated and use a modern framework that handles the basics for you. Do that, and you’ll be safer than the majority of the sites on the internet.
Sources:
https://www.bbc.com/news/articles/c3qjnwye0ep5o
https://onclickinnovations.com/blog/php-vulnerability-hackers-website-fix/