Decloak is an AI-powered web security intelligence platform that scans a site's HTTP/TLS posture, JavaScript, and third-party scripts to produce a report anyone can read. This guide is part of Decloak's library of practical, source-backed security guidance.
In this guide
- Key takeaways
- Is PHP still a secure language?
- Which PHP versions are considered secure today?
- How often does PHP release security patches?
- What does "secure" actually mean for a PHP deployment?
- How can I verify that my site is running a secure PHP version?
- What steps should I take to keep my PHP installation secure?
- How does PHP’s security posture compare to other popular languages?
- What are the risks of running an outdated PHP version?
- How can I prove my PHP security posture to auditors?
- Summary
Key takeaways
- Use only PHP branches listed in the official Supported Versions page (e.g., 8.2, 8.3, 8.4, 8.5).
- Update to the latest point release immediately after it is published.
- Harden your configuration: disable unused extensions, turn off allow_url_fopen, and apply server - level hardening.
- Retire old branches (7.4, 8.0, 8.1) because they receive no security patches.
Is PHP still a secure language?
Yes, PHP is still secure as long as you run a currently supported version and apply every security - only point release. The PHP project publishes regular security updates and guarantees at least four years of maintenance for each branch - two years of active bug fixing followed by two years of critical - only fixes.
Which PHP versions are considered secure today?
Supported branches are those listed on the official Supported Versions page: 8.2, 8.3, 8.4, and 8.5. Anything older than the four - year window, such as 8.0, 8.1, or 7.4, is end - of - life and receives no further patches, making it insecure.
How often does PHP release security patches?
In June 2024 the PHP team released security - only point releases 8.3.8, 8.2.20 and 8.1.29. Those updates fixed critical issues like argument - injection in php - cgi, a filter - var URL bypass, a Windows proc_open workaround, and the Marvin attack on openssl_private_decrypt. Each fix is tracked by a CVE (e.g., CVE - 2024 - 4577, CVE - 2024 - 5458, CVE - 2024 - 5585). The pattern of monthly or quarterly security releases has been consistent for several years.
What does "secure" actually mean for a PHP deployment?
- Supported branch - The major version appears in the Supported Versions table. Using an unsupported branch means you are exposed to unpatched vulnerabilities.
- Up - to - date point release - Install the latest minor release as soon as it appears. Security - only releases contain only fixes for critical bugs, so missing them leaves a known attack surface.
- Configuration hygiene - Modern PHP defaults disable many risky settings (e.g., allow_url_fopen is off). Disable extensions you do not need, set
expose_php=Off, and run PHP under a hardened web server configuration.
How can I verify that my site is running a secure PHP version?
- Run
php -von the server and note the major version and point release. - Compare the version against the Supported Versions list on php.net.
- Check the PHP changelog for the latest security - only release for that branch.
- If the installed point release is older than the latest security - only release, schedule an immediate upgrade.
- Use a passive web security scanner (such as Decloak's free scan) to confirm the server header does not expose an outdated version.
What steps should I take to keep my PHP installation secure?
| Step | Action |
|---|---|
| 1 | Identify the current PHP major version on each server. |
| 2 | Verify that the version is listed in the Supported Versions table. |
| 3 | Download and apply the latest point release for that branch. |
| 4 | Review php.ini and disable unused extensions and risky directives (allow_url_fopen, expose_php). |
| 5 | Enable server - level hardening: run PHP under a dedicated user, limit file permissions, and use a modern TLS configuration. |
| 6 | Subscribe to the PHP security mailing list to receive alerts about new CVEs. |
| 7 | Schedule regular scans (e.g., daily free scans) to detect accidental version rollbacks. |
How does PHP’s security posture compare to other popular languages?
| Language | Supported version policy | Last security - only release (2024) |
|---|---|---|
| PHP | 2 - year active + 2 - year security - only | 8.3.8 (June 2024) |
| Node.js | 12 - month active LTS + 12 - month maintenance | 20.11.1 (June 2024) |
| Python | 5 - year security - only after end - of - life | 3.12.4 (June 2024) |
| Ruby | 2 - year security - only after active support | 3.3.2 (June 2024) |
| Both PHP and the other languages provide a clear lifecycle and regular security patches; the key is to stay within the supported window. |
What are the risks of running an outdated PHP version?
Running an end - of - life branch leaves you exposed to all previously disclosed CVEs that have not been patched. Attackers can exploit known bugs such as remote code execution via crafted HTTP requests or deserialization flaws in legacy extensions. Because no new patches are issued, any newly discovered vulnerability will remain open forever, increasing the likelihood of a successful breach.
How can I prove my PHP security posture to auditors?
When you run a scan with Decloak’s free tier, the report includes a static HTML analysis that shows the server header (if exposed) and the detected PHP version. If the version is supported and up - to - date, the scanner grades the HTTP/TLS posture positively and notes the lack of known vulnerable libraries. Export the report or an evidence package (available on paid plans) to provide auditors with a timestamped proof of the version and its security status.
Summary
PHP remains a secure platform when you follow three simple rules: run a supported major branch, apply every security - only point release, and harden the configuration. Neglecting any of these steps turns a generally safe language into a liability. Regular scanning and subscription to the official security mailing list help you stay ahead of new CVEs and keep your deployment compliant.
Related guides
What are the most common PHP security vulnerabilities and how to fix them?
Learn the top PHP security flaws - XSS, SQL injection, CSRF, RCE, file inclusion, session hijacking, IDOR, unsafe uploads, weak cryptography, and code injection - and get concrete steps to mitigate each one.
Is the recent PHP vulnerability fixed?
The critical remote - code - execution flaws CVE - 2026 - 109618 and CVE - 2026 - 109619 have been patched in the latest PHP releases 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
What is PHP and Why Should Developers Care About Its Security?
PHP is a widely used server - side scripting language that powers many web applications, but its popularity also makes it a frequent target for attackers.