PHP Security: What to Check First in an Older PHP App

You have a PHP app that was built years ago. It still takes orders, or bookings, or leads, and nobody wants to touch it because the last person who knew the code left. Then a security headline about PHP shows up in your feed, and the question is simple: is my app exposed, and what do I fix first?

This is how I would check an app like that, in the order I would do it. The first step happens on the server.

Is my PHP version already the problem?

On 21 Oct 2026, the PHP project shipped a critical security release for two flaws that allow unauthenticated remote code execution. The ids are CVE-2026-109618 and CVE-2026-109619. The flaws are in PHP itself, so they affect PHP installs that serve web requests, and the PHP project says the risk is highest for mod_php.

The ratings depend on who you ask. The PHP project scores both 9.2 CRITICAL (CVSS 4.0). NVD scores CVE-2026-109618 at 9.8 CRITICAL and CVE-2026-109619 at 8.1 HIGH. Either way, I would put it on this week.

The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Within each branch, older releases are vulnerable. PHP 8.1 and older get no project updates, except minimal source backports for 7.4, 8.0 and 8.1. The release notes list temporary mitigations, and they also say those mitigations do not make an installation safe. I read that as “update, do not tune”.

The first thing I would run on the server is this:

php -v
php -i | grep -i "session.cookie"

The first line gives the version. The second shows the session cookie settings, which you will need later. If the site runs WordPress, there is no WordPress update for this. WordPress shows the PHP version in Tools > Site Health > Info > Server, and the fix is a PHP update on the host.

Which PHP versions still get fixes?

This is the php.net support table on 27 Oct 2026.

Version	Active support until	Security fixes until
8.2	ended	31 Dec 2026
8.3	ended	31 Dec 2027
8.4	31 Dec 2026	31 Dec 2028
8.5	31 Dec 2027	31 Dec 2029

The latest stable release is 8.5.12. PHP 8.2 stops getting security fixes in about two months, so an app on 8.2 is fine today and on borrowed time in January.

Old versions are common. The wordpress.org stats API shows about 34% of WordPress sites on PHP older than 8.2. That number covers WordPress sites only, and it is the total of the API values for those versions. It still tells you that “we never upgraded” is a normal state for many sites.

Is PHP itself insecure?

The language gets security fixes on a public schedule. Old versions do not. Once the version is current, the rest of the work is in your own code, and the OWASP Top 10 is a good map. The current edition is 2025. Injection is A05, Cryptographic Failures is A04, and Software Supply Chain Failures is A03. Those three are where I would start reading an old PHP codebase, so they get their own sections below.

How do I stop SQL injection?

Do not build a query string out of user input. Use prepared statements with PDO, so the database treats the input as data and never as SQL.

$stmt = $pdo->prepare("SELECT id, email FROM users WHERE email = :email");
$stmt->execute(["email" => $_POST["email"]]);
$user = $stmt->fetch();

When I read an old app, I search for queries glued together with a dot and a request variable. Every hit is a candidate.

How do I stop XSS?

Escape every value at output time, for the context it lands in, such as HTML body or an attribute. htmlspecialchars is the basic tool for HTML. A Content-Security-Policy header is a good second layer. The OWASP XSS cheat sheet covers the contexts.

echo htmlspecialchars($comment, ENT_QUOTES, "UTF-8");

How should I store passwords?

Use password_hash and password_verify, and nothing you wrote yourself. PASSWORD_DEFAULT uses bcrypt today, and the php.net manual says this default can change over time. So store the full hash string and give the column room to grow.

$hash = password_hash($password, PASSWORD_DEFAULT);
if (password_verify($input, $hash)) {
    // log the user in
}

If the old app stores md5 hashes, that is the moment to plan a rehash on next login.

What about file uploads?

Treat every upload as hostile. Check the type on the server, store files outside the web root, and never let an uploaded file run as code. The OWASP file upload cheat sheet lists the full set of checks. The question I would ask is short: if someone uploads a file named shell.php, can the web server run it?

Are the session defaults safe?

Not for a production site. The php.ini defaults are session.cookie_httponly “0”, session.cookie_secure “0”, an empty session.cookie_samesite, and session.use_strict_mode “0”. That is four settings left for you to decide.

session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = "Lax"
session.use_strict_mode = 1

Add a CSRF token to every form that changes data, too.

Are my dependencies safe?

composer audit checks your installed packages for known security vulnerabilities. Composer added it in version 2.4.0, and you can also run install or update with the –audit flag.

composer audit
composer update --audit

What would my own check list look like?

1. Run php -v and compare it with the fixed versions above.
2. Search the code for queries that join strings with user input.
3. Search for echo or print of request data without escaping.
4. Check how passwords are stored.
5. Check where uploads go, and whether that folder can run PHP.
6. Read the session settings in php.ini.
7. Run composer audit.

When is a patch not enough?

A patch fixes one flaw. It does not fix an app that cannot move to a supported PHP version. Some apps break on each upgrade, and some have no tests, so nobody trusts a change. If your app runs PHP 8.1 or older, a version bump is a project that needs its own plan and tests.

Verdict

Update PHP first, because the October flaws sit in PHP itself and no code review fixes them. Then read your queries, your output, your passwords, your uploads and your session settings, in that order. If the upgrade itself is the wall you keep hitting, that is a modernization job, and this is how I approach PHP modernization.