1,089 IPs exploited one PHP flaw in January 2025. Learn the 5 critical security mistakes that leave applications vulnerable and how to fix them.
PHP powers 76% of websites with server-side programming. No wonder, custom php development is still on the rise. In January 2025, attackers from 1,089 unique IP addresses exploited a single PHP vulnerability.
We will explore five security mistakes and find out how to address them.
Overlooking Parameterized Queries
SQL injection has topped OWASP’s vulnerability list since 2003. Teams still build database queries by gluing user input directly into SQL strings. The application treats that input as executable commands instead of plain text.
Here’s what happens in practice:
- Attacker types admin’ OR ‘1’=’1 into a login form,
- Database interprets this as a command returning every user record,
- Attacker gains access to the entire user table without any password.
Parameterized queries solve this by separating query structure from user data. PDO and MySQLi both support this through prepared statements. Laravel’s query builder handles it automatically.
The difference comes down to how the database processes input:
| Approach | Database Treatment | Security Result |
| String concatenation | Input becomes part of SQL command | Exploitable – attackers control query logic |
| Parameterized queries | Input stays as separate data values | Secure – database never executes user input |
Some developers try sanitizing input with escape functions. Attackers bypass these filters through character encoding tricks. The problem keeps coming back because filtering requires perfect execution every single time.
Not Escaping Output
Cross-site scripting happens when you display user input without converting special characters into safe HTML entities. Someone posts a comment containing script tags.
Your application saves it and displays it on the page:
- Every visitor’s browser executes that script;
- Browser sees angle brackets and treats them as HTML tags;
- Tags contain JavaScript with full access to cookies, session tokens, and page content.
The htmlspecialchars() function converts dangerous characters into safe equivalents:
- Angle brackets become HTML entities that display as text;
- ENT_QUOTES flag handles both single and double quotes;
- UTF-8 encoding prevents attacks using alternate character representations.
Context determines the escaping method needed. HTML body content needs basic HTML escaping. HTML attributes require additional quote handling. JavaScript contexts need JavaScript-specific encoding.
Symfony’s Twig template engine examines where each variable appears and applies the correct encoding automatically. Teams using Twig get protection by default.
The timing matters too:
- Escape when displaying data, not when receiving it;
- Input filtering guesses how data will be used later;
- Output escaping knows the exact context at display time.
Accepting Unvalidated File Uploads
File upload forms let attackers deploy webshells when apps ignore content validation. The attacker uploads a PHP file disguised as an image.
Teams check file extensions, thinking it provides protection:
- Attacker uploads shell.php.jpg;
- Apache server processes it as PHP despite the .jpg ending;
- Certain configurations trigger PHP execution for any filename containing .php.
MIME type validation fails because Content-Type headers come from the client:
- Attacker controls the header,
- Sets it to whatever the application expects,
- Server accepts the “image,” but .php extension causes code execution.
Proper validation requires multiple layers. Whitelist allowed extensions and verify the file content. Use getimagesize() to confirm files are valid images. Store uploads outside the web root directory.
Storage location matters as much as validation. Files in the web root become directly accessible through URLs. Moving uploads outside the web directory means attackers can’t reach them even if they bypass upload filters.
Running Outdated PHP Versions
CVE-2024-4577 affects every PHP installation on Windows with a CVSS score of 9.8. GreyNoise detected 1,089 unique IP addresses attempting exploitation in January 2025. Attackers started within 48 hours of disclosure in June 2024. The flaw exists in how PHP’s CGI mode processes command-line arguments on Windows.
GreyNoise observed sustained attacks across multiple regions:
- United States, United Kingdom, Singapore,
- Japan, Taiwan, Hong Kong,
- India, Spain, Malaysia.
Cisco reported threat actors deploying Cobalt Strike toolkits to gain system privileges, modify registry keys, and create malicious services. PHP versions 8.1.29, 8.2.20, and 8.3.8 contain the fix.
Configuration changes won’t help. Only updating closes the vulnerability.
The 2025 PHP Landscape Report found 60% of teams use containerization:
- Containers make updates predictable by defining PHP versions in base images,
- Rebuilding applies patches across all containers,
- Teams must update base images first or propagate vulnerabilities.
PHP’s semantic versioning addresses the breaking change fear. Patch releases contain only security fixes and bug corrections. Updating from 8.3.8 to 8.3.19 shouldn’t break functionality but patches 11 CVEs.
The window between disclosure and widespread exploitation keeps shrinking:
- CVE-2024-4577 saw attacks within two days,
- Monitor PHP’s changelog,
- Deploy patches within days of critical disclosures.
Using session_start() Without Security Measures
PHP’s session_start() function creates sessions but provides zero protection against fixation or hijacking. PHP defaults to accepting any session ID the client provides.
Session fixation follows a simple pattern:
- Attacker generates a session ID,
- Tricks victim into using it through a crafted URL,
- Victim logs in, authenticating the session,
- Attacker already knows that session ID and uses it to impersonate the victim.
Session hijacking intercepts valid session IDs through network sniffing, XSS exploits, or physical device access:
- Attacker obtains the session ID,
- Makes requests the server accepts as legitimate,
- Impersonates the victim completely.
Prevention requires multiple layers. Regenerate session IDs when privileges change. Use HttpOnly flag to prevent JavaScript access. Enable Secure flag for HTTPS-only transmission.
Cookie flags make interception harder:
- HttpOnly flag prevents JavaScript from accessing session cookies,
- Secure flag ensures cookies only travel over encrypted HTTPS connections,
- SameSite attribute prevents browsers from sending cookies with cross-site requests.
Additional validation catches hijacking after it occurs. Store the User-Agent header and IP address in the session during login. Check them on subsequent requests.
Session timeout limits the window attackers have to exploit stolen IDs:
- Force re-authentication after inactivity,
- Configure through application code and php.ini,
- Typical timeout: 3600 seconds (1 hour).
PHP’s session configuration affects security application-wide. The session.use_strict_mode setting makes PHP reject uninitialized session IDs. The session.use_only_cookies directive prevents session ID transmission through URL parameters.
Conclusion
These five mistakes cause breaches repeatedly. Parameterized queries, output escaping, validated uploads, updated versions, and configured sessions each prevent entire categories of attacks. Professionals overlook the fundamentals and pay for it.