{"id":637,"date":"2026-10-21T17:24:25","date_gmt":"2026-10-21T17:24:25","guid":{"rendered":"https:\/\/server.ua\/en\/blog\/?p=637"},"modified":"2026-10-21T17:24:25","modified_gmt":"2026-10-21T17:24:25","slug":"new-php-vulnerabilities-open-the-door-to-servers-without-a-password","status":"publish","type":"post","link":"https:\/\/server.ua\/en\/blog\/new-php-vulnerabilities-open-the-door-to-servers-without-a-password","title":{"rendered":"New PHP Vulnerabilities Open the Door to Servers Without a Password"},"content":{"rendered":"\n
\"A
Hidden Threats to PHP Server Security<\/figcaption><\/figure>\n\n\n\n

A typical break-in usually needs some kind of entry ticket \u2013 a weak password, a stolen token, or remnants of an old admin panel. But what happens when all it takes to gain access is an ordinary, seemingly legitimate request to a website that makes PHP execute someone else’s code?<\/p>\n\n\n\n\n\n\n\n

That’s exactly the threat security researchers have been talking about in recent days, after two critical vulnerabilities were disclosed in PHP itself. Not in some popular WordPress plugin or an abandoned CMS, but in the programming language itself. Both tiny brochure websites on shared hosting and powerful VPS servers running custom projects are potentially in the line of fire.<\/p>\n\n\n\n

The situation is serious enough that the European Computer Emergency Response Team (CERT-EU) explicitly recommended isolating systems from the network if they can’t be secured quickly.<\/p>\n\n\n\n

What Happened to PHP and Why Is It So Serious<\/h2>\n\n\n\n

We’re talking about two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both caused by serious flaws. Each scored 9.2 out of 10 under CVSS 4.0 \u2013 the numbers speak for themselves.<\/p>\n\n\n\n

The root of the problem lies in how the interpreter handles memory. In one scenario, a failure occurs when resources run low and internal structures haven’t been fully initialized. In the other, PHP reuses a section of memory it has already freed.<\/p>\n\n\n\n

From the outside, it may look like an ordinary visitor request. But in the right hands, the flaw turns into a classic RCE (Remote Code Execution) attack. And here’s the worst part \u2013 no authentication is needed. Forget about guessing SSH passwords or trying to get into the admin panel.<\/p>\n\n\n\n

The attack can potentially work before the website’s own engine even starts processing the request. So even a well-written, properly secured application can be affected simply because it’s running on a vulnerable PHP version.<\/p>\n\n\n\n

How One Website Can Give Attackers Access to a Server<\/h2>\n\n\n\n

Take a typical VPS running a mid-sized online store. Traffic follows the usual route: the web server receives a request, passes it to PHP, PHP talks to the database and returns a result. Quick and routine.<\/p>\n\n\n\n

But if an exploit gets into that chain, malicious code may run with the same permissions as the website’s process. What happens next depends entirely on the configuration.<\/p>\n\n\n\n

If the attacker can read configuration files in the directory, they may suddenly have the credentials needed to connect to the database. If writing to the project’s root directory is allowed, a web shell may soon appear. After that, control over the website could end up in someone else’s hands.<\/p>\n\n\n\n

A common configuration mistake is running several projects under the same system user without proper isolation. With that setup, compromising a single online store may be enough to put neighboring websites at risk.<\/p>\n\n\n\n

Of course, being able to execute code doesn’t give an attacker full control of the entire server with one click. If isolation is properly configured and processes run with restricted permissions, the attacker’s options will be considerably limited. But even that is usually enough to cause a serious headache.<\/p>\n\n\n\n

Which Servers Are Most at Risk<\/h2>\n\n\n\n

The scale of the problem is striking: versions from PHP 5.4 through 8.5.11 are affected. The way PHP is run doesn’t guarantee protection \u2013 the list includes PHP-FPM, classic Apache mod_php, and php-cgi, along with FrankenPHP and LiteSpeed.<\/p>\n\n\n\n

The combination of Apache and the mod_php<\/code> module is a particular concern. An attack capable of bypassing the application’s own protection has already been demonstrated for this setup.<\/p>\n\n\n\n

Those who haven’t looked at their server settings in years may have the hardest time. An old PHP version is often left in place because of the familiar \u201cif it works, don’t touch it\u201d approach. Maybe it’s running legacy corporate software, an accounting system, or a custom online store. People are reluctant to upgrade because they’re afraid of disrupting something that still works.<\/p>\n\n\n\n

The trouble is, an absence of errors in the logs doesn’t mean the system is secure. A server can run for months without a single failure while remaining exposed to the next attack attempt.<\/p>\n\n\n\n

The same goes for Docker containers. The host system may be updated regularly, while an old image inside a container continues running a vulnerable PHP version.<\/p>\n\n\n\n

Can a Regular Firewall Protect You<\/h2>\n\n\n\n

A network firewall is useful when you need to close unnecessary ports or block password-guessing attempts. But not here. To network security tools, this traffic may look like just another ordinary request for a webpage. Changing your SSH password or blocking unused ports won’t fix the vulnerability itself.<\/p>\n\n\n\n

A WAF (Web Application Firewall) improves things somewhat by filtering out some malicious requests, but the developers behind the fixes are clear about it: this is only a temporary measure, not a complete solution.<\/p>\n\n\n\n

The key thing is access permissions. A separate system account for each website and as few unnecessary permissions as possible for PHP processes \u2013 these are basic safeguards that help limit the damage from an attack. They won’t remove the vulnerability from the interpreter itself, but they give you a chance to keep the attacker contained within an isolated environment.<\/p>\n\n\n\n

What to Check on Your VPS or Dedicated Server Right Now<\/h2>\n\n\n\n

Start by checking which PHP versions are actually installed. The console command php -v<\/code> only shows the version of the interpreter launched from the command line by default. Your website, however, may be running through a completely different PHP-FPM pool, so check the environment that’s actually handling incoming requests.<\/p>\n\n\n\n

Fixes are already available in the official PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 releases. If you install packages from your Linux distribution’s repositories, check for updates from the package maintainers. They often backport fixes to older releases while leaving the main version number unchanged.<\/p>\n\n\n\n

Things get more complicated with older branches like PHP 8.1. Official support has ended, so you’re left relying on repositories offering extended support. If patched packages aren’t available at all, you’ll need to plan a move to a supported version.<\/p>\n\n\n\n

Before making any changes, create backups and check software compatibility. Once the updates are installed, make sure to restart the relevant services. Otherwise, old processes may stay in memory for a while, still running the old code.<\/p>\n\n\n\n

And one final rule: a lack of warning signs doesn’t prove your system is secure. A vulnerability doesn’t necessarily cause noticeable problems with your server<\/a>. Sometimes you only find out something went wrong after an attacker has already managed to execute their code.<\/p>\n","protected":false},"excerpt":{"rendered":"

A typical break-in usually needs some kind of entry ticket \u2013 a weak password, a stolen token, or remnants of an old admin panel. But what happens when all it takes to gain access is an ordinary, seemingly legitimate request to a website that makes PHP execute someone else’s code?<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21],"tags":[155,68,114],"class_list":["post-637","post","type-post","status-publish","format-standard","hentry","category-security","tag-cybersecurity","tag-server-security","tag-website-protection"],"_links":{"self":[{"href":"https:\/\/server.ua\/en\/blog\/wp-json\/wp\/v2\/posts\/637","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/server.ua\/en\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/server.ua\/en\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/server.ua\/en\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/server.ua\/en\/blog\/wp-json\/wp\/v2\/comments?post=637"}],"version-history":[{"count":1,"href":"https:\/\/server.ua\/en\/blog\/wp-json\/wp\/v2\/posts\/637\/revisions"}],"predecessor-version":[{"id":639,"href":"https:\/\/server.ua\/en\/blog\/wp-json\/wp\/v2\/posts\/637\/revisions\/639"}],"wp:attachment":[{"href":"https:\/\/server.ua\/en\/blog\/wp-json\/wp\/v2\/media?parent=637"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/server.ua\/en\/blog\/wp-json\/wp\/v2\/categories?post=637"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/server.ua\/en\/blog\/wp-json\/wp\/v2\/tags?post=637"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}