How to Assess and Prevent PHP Vulnerabilities

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 they 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 workarounds (e.g., configuration settings) that prevent exposure.

PHP Vulnerability Example

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 these and other risks, teams should follow application security best practices, including:

• Threat modeling via the STRIDE method to find potential 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 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 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 vulnerability.  

It’s also important to note there are rare cases where a PHP vulnerability 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.  

PHP Vulnerability 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 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 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 Vulnerability Severity Levels

NIST provides a calculator for determining the score / severity of 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
• Resource - Zend PHP Security Center
• Blog - Unpacking the Drupal PHP Support Lifecycle
• Blog - CVE-2023-3823 Overview
• Blog - Changes to Watch in PHP 8.3
• Blog - Why Good PHP Monitoring Matters
• Blog - Mitigating CVE-2023-0662
• Blog - The State of WordPress PHP Support
• Blog - Using Containers to Improve PHP Application Security
• Blog - 6 PHP Security Best Practices
• Blog - Setting Your PHP 7.4 Migration Strategy
• Blog - PHP 7.4 EOL Is Here: Are Your Applications Secure?
• Blog - Understanding CVEs and CVSS Scores
• Blog - Are You Ready for PHP 8.0 EOL?
• White Paper - The Costs of Building PHP In-House
• White Paper - Planning Your Next PHP Migration