PHP Vulnerabilities: Assessment and Prevention

PHP, like any other programming technology, is not exempt from having vulnerabilities. In fact, web applications (most of which use PHP) are a frequently probed attack surface for malicious parties who want to find and exploit PHP vulnerabilities. This makes being able to assess and mitigate PHP vulnerabilities a crucial part of developing and managing PHP applications.

In this blog, we give an overview of PHP vulnerabilities, including what PHP vulnerabilities are, how to assess them, and steps teams can take to keep their EOL PHP patched and secure. 

What Is a PHP Vulnerability?

A PHP vulnerability is an exploitable flaw in a PHP application that can be used to gain unauthorized access to systems that comprise or underlie that PHP application. 

Common PHP vulnerabilities can include code injection, broken access control, security misconfiguration, and cryptographic failures.

Common Vulnerabilities and Exposures, or 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.

Examples of PHP Vulnerabilities

An example of a PHP vulnerability is the recent ‘OOB read due to insufficient input validation in imageloadfont()’ (CVE-2022-31630).

This flaw allows a remote attacker to pass specially crafted data to the web application, trigger an out-of-bounds read error, and read the contents of memory on the system.

Preventing Exposure to PHP Vulnerabilities

To prevent 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 most web applications use PHP as their server-side language of choice, implementing the above mentioned 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, as discussed above, serve to help teams assess and mitigate vulnerabilities in their PHP applications. 

How PHP Vulnerabilities Are Reported and Acted Upon Within the Community

If someone working within the PHP ecosystem finds a PHP vulnerability, they can securely report that  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 is only made public due to the successful exploitation of a system via that vulnerability. However, this is rare due to the continued proactive actions of reporters within the PHP community and the PHP security team.  

On-Demand Webinar: PHP Engine Security

Join global PHP security expert Stanislav Malyshev for an on-demand webinar exploring how security vulnerabilities are managed in the PHP engine.

PHP Vulnerabilities: Severity Levels

PHP vulnerabilities are not created equally, which is why organizations like the National Institute of Standards and Technology have created standardized criteria for assessing PHP vulnerabilities. The National Vulnerability Database 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 the Security Levels of 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.

Source: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator 

Returning back to our earlier PHP CVE example, CVE-2022-31630, you can see two separate base scores listed, with the associated vectors selected during the calculation phase differing between the two scores. 

Source: https://nvd.nist.gov/vuln/detail/CVE-2022-31630 

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.

Final Thoughts

While assessing and mitigating PHP vulnerabilities can be complicated and time-consuming, it’s a very important part of the PHP development and management process. If CVEs are left unpatched, it leaves teams at risk to potentially devastating exploits – exploits that can ultimately impact the success of their organizations.

If you haven’t yet, we highly encourage you to bookmark our PHP Security Center page, and to make sure you have full visibility into the PHP versions you’re deploying. And, if you have end of life PHP that needs patched, be sure to check out our PHP LTS offerings.

Keep Your EOL PHP Patched With LTS From Zend

Zend provides PHP LTS for EOL PHP versions, all backed by guaranteed SLAs and support from our team of experts.

See Our LTS Options

Additional Resources

• Solution - Zend PHP Consulting Services
• Solution - Zend PHP Security and Consulting Services
• White Paper - The Costs of Building PHP In-House
• White Paper - Planning Your Next PHP Migration
• Blog - Unpacking the Drupal PHP Support Lifecycle
• Blog - CVE-2023-3823 Overview
• Blog - Why Good PHP Monitoring Matters
• Blog - Mitigating CVE-2023-0662
• Blog - Using Containers to Improve PHP Application Security
• Blog - 6 PHP Security Best Practices
• Blog - PHP 7.4 EOL Is Here: Are Your Applications Secure?
• Blog - Understanding CVEs and CVSS Scores