PHP Vulnerabilities: Assessment, Prevention, and Mitigation

PHP, like any other programming technology, is not exempt from having vulnerabilities. Due to PHP's popularity, PHP apps are a frequently probed attack surface for malicious parties who want to find and exploit vulnerabilities. This makes being able to assess and mitigate PHP vulnerabilities a crucial part of developing and managing PHP applications.

In this blog, we explore PHP vulnerabilities, including what PHP vulnerabilities are, how to assess them, and steps teams can take to keep their critical PHP applications patched and secure. 

PHP Vulnerabilities: Overview

Assessing, preventing, and mitigating PHP security vulnerabilities is critical for the safety and security of your web application. But before we get into strategies and tactics, let’s take a look at what PHP vulnerabilities are and answer a few frequently asked questions.

What Are PHP Vulnerabilities?

PHP vulnerabilities are exploitable flaws in a PHP application that can be used to gain unauthorized access to systems.

Common PHP vulnerabilities can include code injection, broken access control, security misconfiguration, and cryptographic failures, which we will discuss further later in this post.

What Is the Latest PHP Vulnerability?

New PHP Common Vulnerabilities and Exposures (CVEs) are identified daily. The most up-to-date list can be found in the Zend Security Center.

CVE entries include details about the CVE and its impact, which PHP versions and/or extensions were affected, and information on how to mitigate the CVE – whether that’s upgrading the PHP version, or using workarounds (e.g., configuration settings) that prevent exposure to PHP vulnerabilities.

How Is Exposure to PHP Vulnerabilities Prevented?

To prevent exposure to PHP vulnerabilities and other risks, teams should follow application security best practices, including:

• Threat modeling via the STRIDE method to find potential PHP vulnerabilities that could be exploited
• Risk assessment with the DREAD framework to understand the likelihood of specific kinds of attacks

Because so many web applications use PHP as their server-side language of choice, implementing these methodologies and keeping PHP versions up to date is one of many PHP security best practices that teams need to consider as they develop and maintain their web applications.

How Are PHP Vulnerabilities Disclosed?

Zend and the PHP community work daily to discover PHP vulnerabilities residing in the PHP engine and in all the prominent extensions that comprise the PHP ecosystem. The results of this continuous process are published in the form of CVEs by the community and in our PHP Security Center. These CVE entries serve to help teams assess and mitigate PHP vulnerabilities in their applications. 

How PHP Vulnerabilities Are Reported and Acted Upon Within the Community

If someone working within the PHP ecosystem finds any PHP vulnerabilities, they can securely report that PHP vulnerability to the PHP security team. Once a report is received, the team works to verify the issue, then collaborates on a patch with the reporting party.  

Once the fix is verified, it’s merged into the appropriate tree – but with the information obfuscated so that an observer cannot directly ascertain it is security related. This step is important, as it helps to keep nefarious parties from crawling for undisclosed PHP vulnerabilities and exploiting them before the CVE (or a patch) is disclosed to the public.

In the run up to the actual announcement of a CVE, a CVE identifier is associated with the patch, but the CVE is generally not given any details until after release.  

The PHP security team works with package maintainers from a number of operating system distributions (E.g., RHEL, Debian, Arch, etc.), so that binaries can be released either simultaneously with the source release, or within 1-2 days.

This process is well established across development ecosystems to help ensure teams are able to patch faster than nefarious parties are able to exploit the PHP vulnerability.  

It’s also important to note there are rare cases where PHP vulnerabilities may be found by a nefarious party, and are only made public due to the successful exploitation of a system. However, this is rare due to the continued proactive actions of reporters within the PHP community and the PHP security team. 

Stay Up to Date on the Latest CVEs

The Zend Security Center is designed to help developers identify and mitigate PHP vulnerabilities before they are exploited, keeping your PHP application secure and compliant.

Zend PHP Security Center   Security Solutions

PHP Vulnerabilities: Severity Levels

PHP vulnerabilities are not created equally, which is why organizations like the National Institute of Standards and Technology (NIST) have created standardized criteria for assessing PHP vulnerabilities. The National Vulnerability Database (NVD) provides a scoring system called the common vulnerability scoring system, or CVSS, that helps teams working with software to quickly understand the severity of a given PHP vulnerability.

This scoring system has went through several iterations, with CVSS v3.0 breaking down severities into five categories ranging from critical, to no severity.

CVSS v3.0 Severity by Base Score Range

Calculating Security Levels for PHP Vulnerabilities

NIST provides a calculator for determining the score / severity of PHP vulnerabilities. These scores are determined based on a number of vectors, including attack vector, attack complexity, privileges required, user interaction, scope, confidentiality impact, integrity impact, and availability impact. There are other defined characteristics for temporal and environmental scores as well.

To use an example, let's look at CVE-2022-3160's results on the NIST calculator. Here, you can see two separate base scores listed, with the associated vectors selected during the calculation phase differing between the two scores. 

This means that both the NVD group and PHP Group evaluated the CVE, with the NVD group finding it more severe (per their vector selections) than the PHP group.

Common Types of PHP Vulnerabilities

PHP powers approximately 75% of web applications, so it is no surprise that it is a frequent target for malicious attacks. To keep your applications secure and user data protected, understanding and addressing the following common PHP vulnerabilities is an essential step in building a comprehensive security strategy.

Code Injection

Code injection is the general term for attack types which consist of injecting code that is then interpreted and executed by the application. This type of attack exploits poor handling of untrusted data, and it is made possible due to improper input/output data validation. This can include:

• Allowed characters (standard regular expressions classes or custom)
• Data format
• Amount of expected data

These types of PHP vulnerabilities can range from very hard to very easy to find. Once found, they are usually hard to exploit, though this can depend on the scenario. However, if successfully exploited, the impact on your application could include loss of confidentiality, integrity, availability, and/or accountability.

Broken Access Control

Access control prevents users from acting outside of their intended permissions. Broken or failed access control typically leads to unauthorized information disclosure, modification, data destruction, or performing a business function outside a user's limits. Common access control vulnerabilities include:

• Violation of the principle of least privilege or deny by default, where access should only be granted for specific capabilities, roles, or users, but is available to anyone.
• Bypassing access control checks by modifying the URL (parameter tampering or force browsing), internal application state, or the HTML page, or by using an attack tool modifying API requests.
• Permitting viewing or editing of someone else's account, by providing its unique identifier (insecure direct object references).
• Accessing API with missing access controls for POST, PUT and DELETE.
• Elevation of privilege, where someone acts as a user without being logged in, or acts as an admin when logged in as a user.
• Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token, or a cookie or hidden field manipulated to elevate privileges and abusing JWT invalidation.
• CORS misconfiguration, which allows API access from unauthorized or untrusted origins.
• Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user.

Access control is only effective in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata. Always deny by default, except for public resources. Implement access control mechanisms once, and re-use them throughout the application, including minimizing Cross-Origin Resource Sharing (CORS) usage. Other best practices and mitigation strategies include the following:

• Model access controls should enforce record ownership rather than accepting that the user can create, read, update, or delete any record.
• Use domain models to enforce unique application business limit requirements.
• Disable web server directory listing and ensure file metadata (e.g., .git) and backup files are not present within web roots.
• Log access control failures and alert admins when appropriate (e.g., repeated failures).
• Rate limit API and controller access to minimize the harm from automated attack tooling.
• Invalidate stateful session identifiers on the server after logout. Stateless JWT tokens should rather be short-lived to minimize the window of opportunity for an attacker. For longer lived JWTs, it's highly recommended to follow the OAuth standards to revoke access.

Security Misconfiguration

Security misconfiguration vulnerabilities occur when systems, applications, or cloud infrastructure are not properly configured, leaving them vulnerable to cyberattacks and data breaches. These PHP vulnerabilities arise from insecure default settings, improper access controls, and neglecting regular patching and updates. Some of the common causes include:

• Insecure Default Settings — Using default passwords, leaving services open to the internet, or not disabling unnecessary features.
• Improper Access Controls — Granting users excessive permissions, neglecting least privilege principle, or failing to implement strong authentication methods.
• Neglecting Updates and Patches — Failing to keep software and systems up-to-date with the latest security patches, leaving known vulnerabilities unaddressed.
• Misconfigured firewalls — Incorrectly configured firewalls can allow unauthorized traffic to enter or exit a network.
• Lack of monitoring and logging — Not having proper logging and monitoring in place can make it difficult to detect and respond to security incidents.

Crytographic Failures

Cryptographic failures are where attackers target sensitive data that has been improperly protected, such as passwords, credit card numbers, and personal information. Cryptographic failures are the root cause of sensitive data exposure. 

Software updates, critical data, and Continuous Integration/Continuous Delivery (CI/CD) pipelines play a crucial role in maintaining the security and functionality of software systems. However, if the integrity of these components is not verified, it can lead to severe vulnerabilities and potential exploitation by malicious actors.

One of the key concerns in this category is the lack of proper verification of software updates. When updates to software are not thoroughly tested and verified, they can introduce vulnerabilities that can be exploited by attackers. This could result in unauthorized access, data breaches, or disruption of critical systems. If sensitive information is not adequately protected, it can be accessed or tampered with, leading to significant consequences such as financial loss or reputational damage.

Furthermore, compromised CI/CD pipelines can pose a significant threat. These pipelines are responsible for automating the build, testing, and deployment of software systems. If the integrity of the CI/CD pipeline is compromised, it can lead to the deployment of malicious code, giving attackers unauthorized access to systems.

Session Hijacking

Session hijacking refers to the malicious act of taking control of a user’s web session. A session, in the context of web browsing, is a series of interactions between two communication endpoints, sharing a unique session token to ensure continuity and security.

This attack involves a bad actor stealing or manipulating the session token to gain unauthorized access to information or services. The hijacking process typically begins when an attacker intercepts this token, which can be likened to a secret handshake between the user and the website. The attacker then gains the ability to masquerade as the legitimate user.

The methods of interception can vary, ranging from network eavesdropping to sophisticated phishing attacks. In most applications, after successfully hijacking a session, the attacker gains complete access to all of the user’s data, and is permitted to perform operations. While hijackers have many techniques at their disposal, certain methods stand out due to their prevalence and effectiveness:

• Session sniffing — This technique involves monitoring network traffic to capture valid session tokens.
• Cross-site scripting (XSS) — Attackers inject malicious scripts into web pages, which then allow them to steal session cookies from unsuspecting users.
• Session fixation — An attacker forces a user to use a specific session ID, which the attacker has already obtained, to compromise the session.

Each technique requires a tailored approach to mitigation, highlighting the need for a multi-layered security strategy.

Mitigation Tactics for Identified PHP Security Vulnerabilities

Once a PHP vulnerability has been identified, it is important to take steps to guard your application against exploitation or exposure. While each type of PHP vulnerability will require different mitigation tactics, the following practices can be applied to keep your application secure.

Check CVE Entry for Specific Mitigation Steps

As mentioned previously, each CVE will have an entry detailing how teams can address the identified vulnerability. Depending on the CVE, this may include specific mitigation steps, such as adjusting configurations or disabling specific libraries. For example, consider a PHP vulnerability identified last year: CVE-2024-8926.

CVE-2024-8926 is a High severity remote code execution, which is a PHP vulnerability that allows attackers to remotely execute malicious code. While the most straightforward mitigation tactic is to update to a patched PHP version (details in the next section), a few vulnerability mitigation strategies can be implemented:

First, developer teams could apply a mod_rewrite rule to block attacks, like the following:

RewriteEngine On
RewriteCond %{QUERY_STRING} ^%ad [NC]
RewriteRule .? – [F,L]

However, if your team uses XAMPP and does not need the PHP CGI feature, you can find the 'ScriptAlias' directive in the Apache configuration file (typically at 'C:/xampp/apache/conf/extra/httpd-xampp.conf'), and comment it out.

It is important to note that these steps are usually best used as a stop-gap solution until you can update the affected PHP version. Implementing these workarounds, particularly with a less experienced developer team, can have undesired impacts on your critical applications.

Update or Patch the Affected PHP Version

PHP versions have a lifecycle of four years, with the community offering two years of active support, followed by two years of security-only support. During active support, bugs and security issues that have been identified will be fixed and released regularly. During security-only support, releases will be made as required, with only critical security issues addressed. This could include multiple releases or none, depending on identified CVEs.

As a result of this release cycle, using the most up-to-date PHP version is critical to mitigating identified PHP vulnerabilities. With new CVEs identified daily, using outdated or un-patched PHP can leave applications defenseless against new threats. Updating regularly ensures that you have access to the latest security features, bug fixes, and mitigations available for newly identified CVEs.

For teams where upgrading quickly isn’t feasible, implementing security patches through third-party long-term support (LTS) services may be your best option. PHP LTS – such as the services provided by Perforce Zend – can extend the lifespan of your PHP version, allowing you to upgrade on your schedule. This, in turn, can help save money on refactoring, maintain compliance standards, and mitigate newly identified PHP vulnerabilities.

Learn more about PHP Upgrades >>

Utilize Container Technologies

According to the 2025 PHP Landscape Report, nearly 60% of surveyed teams are using container technologies in their applications. One aspect impacting the popularity of containers may be due to how they improve security and mitigate exposure to PHP vulnerabilities.

By isolating applications from one another and their underlying environment, containers ensure consistency and security across deployments. PHP teams can use containers to create reproducible environments with predefined configurations, making it easier to apply updates, implement patches, and mitigate identified PHP vulnerabilities.

However, it’s important to ensure the security of your base image, as it is used as the starting point for creating derivative images. Any security vulnerabilities or flaws found within that base container image will carry over to derivative images.

Learn more about How Containers Improve PHP Application Security >>

Secure Container Images From Zend

Make your container initiatives a success with container-ready PHP products and expert professional services from Zend. 

Explore Container Solutions  Container Registry

Refactor Your Code

Refactoring a PHP web application involves improving the structure and maintainability of existing code without altering its behavior. Refactoring can enhance code efficiency, reduce technical debt, and improve security against identified PHP vulnerabilities. 

However, refactoring does have some limitations, such as its inability to address foundational architectural issues. Refactoring also demands significant skill to be executed effectively and without introducing new bugs during large-scale changes. While it can enhance your code base, it does not introduce new security features the way that updating PHP versions does.

Learn more about When to Rewrite vs. Refactor Your Web App>>

Final Thoughts

Identifying and mitigating PHP vulnerabilities is a constant and necessary effort for PHP teams. By understanding common types of vulnerabilities, their severity levels, and approaches for mitigation, you can effectively safeguard your application from malicious attacks. Prioritizing regular updates, utilizing containers, and adopting secure coding practices are just a few ways to minimize risk and protect sensitive data.

Another solution is to partner with an experienced team of PHP experts, like Perforce Zend. We can assist you in identifying and mitigating PHP vulnerabilities, upgrading PHP versions, implementing best security practices, and more  – freeing your team to focus on developing new features that drive your business.

Stay Secure With ZendPHP + ZendHQ

Keep your PHP applications secure and supported with ZendPHP runtimes and the ZendHQ extension. Upgrade on your schedule, access 24/7/365 support, and simplify monitoring processes.

Discover ZendPHP  Try ZendPHP + ZendHQ Free

Additional Resources

• 101 Guide - PHP Security
• Solution - Zend PHP Consulting Services
• Solution - Zend PHP Security and Consulting Services
• Blog - Why Good PHP Monitoring Matters
• Blog - Mitigating CVE-2023-0662
• Blog - CVE-2023-3823 Overview
• Blog - 6 PHP Security Best Practices
• Blog - Understanding CVEs and CVSS Scores

Editor's Note: The blog was originally published in March, 2023. It has been updated and expanded to include new information.