Innovate faster and cut risk with PHP experts from Zend Services.
Beginning to advanced PHP classes to learn and earn global certification.
Help me choose >
Submit support requests and browse self-service resources.
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.
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.
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.
To prevent these and other risks, teams should follow application security best practices, including:
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.
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.
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 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.
Base Score Range
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.
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.
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.
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 ZendZend provides PHP LTS for EOL PHP versions, all backed by guaranteed SLAs and support from our team of experts.See Our LTS Options
Zend provides PHP LTS for EOL PHP versions, all backed by guaranteed SLAs and support from our team of experts.
See Our LTS Options
Massimiliano Cavicchioli is a Software Architect at Zend. He has over 20 years of experience in the tech world, 16 of which he spent contributing to the PHP ecosystem at Zend. During his many years of providing consultation to enterprise corporations, Massi has developed a wealth of tangible knowledge — making him highly capable in helping companies achieve best practices in both PHP and OSS.