PHP 7: Maintaining and Upgrading Legacy Apps · Security Hardening for PHP 7 Apps
End-of-Life PHP and Vulnerable Dependencies
Assess and reduce risk when you can't upgrade immediately.
Running EOL PHP means unpatched vulnerabilities in PHP itself; old Composer packages add more. Assess exposure (composer audit, local-php-security-checker), update dependencies within the constraints of your PHP version, and choose a mitigation path: upgrade (preferred), use distribution-backported packages (e.g., RHEL/Ubuntu ESM) or commercial extended support (e.g., Zend, TuxCare, Freexian) while you upgrade, and isolate the app (WAF, minimal exposure, least privilege).
composer audit # advisories for installed packages
composer outdated --direct --minor-only
php -v # confirm the exact runtime version in production
Common pitfalls
- Assuming 'no known exploits' means safe.
- Freezing dependencies forever because upgrades are hard.
- Running the app with broad database and filesystem permissions.
Key points
- EOL PHP gets no official security fixes
- Audit dependencies regularly
- Extended support buys time — upgrading is the fix
Further reading: PHP supported versions
Practice questions
What options exist if you can't upgrade off PHP 7.4 this quarter?
Answer
Use vendor/distribution extended-support builds, minimize exposure (WAF, network isolation, least privilege), keep dependencies patched within constraints, and schedule the upgrade with a clear plan.
What does composer audit check?
Answer
It compares installed package versions against security advisory databases and reports known vulnerabilities.
Open in the app to mark lessons complete, take notes and track your progress.