Veeam PHP2Shell: Veeam is not affected, but the PHP apps around your backup server may be

Veeam is not affected by PHP2Shell. Veeam KB4953, published on 22 October 2026, says Veeam products and Veeam SaaS solutions are not affected by CVE-2026-109618 or CVE-2026-109619, and that no Veeam product uses PHP. The Veeam PHP2Shell question still matters for backup admins, because PHP apps often run on the same network as the backup server.

Searches for "veeam php2shell" and "veeam php vulnerability" jumped this week, according to Google Trends. This post gives Veeam's answer, then covers the PHP apps around a backup stack and what to do about them.

What Veeam said

Veeam KB4953 says that Veeam products and Veeam SaaS solutions are not affected, and that PHP is not in use by any Veeam product or Veeam SaaS solution. It lists no affected products and no fix to install. The KB links to the NVD entries for both CVEs and to the list of external packages the Veeam Software Appliance requires.

Proxmox gave the same answer. In the PHP2Shell and Proxmox post from 25 October I covered why Proxmox VE and Proxmox Backup Server are not affected (they are written in Perl and Rust, per Proxmox staff) and how to patch PHP inside Proxmox guests.

What PHP2Shell is, briefly

PHP2Shell is the name for two PHP flaws that can allow unauthenticated remote code execution. The PHP project describes CVE-2026-109618 as remote code execution through out-of-memory corruption and CVE-2026-109619 as remote code execution through stale global state. Unit 42 rates both at 9.2 on CVSS 4.0.

PHP released the fixes on 21 October 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The watchTowr FAQ says watchTowr has seen exploitation since 21 October. Unit 42 reports that Cortex Xpanse found over 22.6 million exposed instances that may be vulnerable.

CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 26 October 2026. The catalog sets 29 October 2026 as the due date for US federal agencies.

Why a backup admin should still care

The machines around a Veeam server often run PHP. Check what else lives on the backup network or can reach it:

• Monitoring frontends. The Zabbix 7.4 frontend requires PHP 8.0 to 8.5, and LibreNMS needs PHP 8.4 or newer and runs it through PHP-FPM. Both usually have network access to everything they watch, the backup server included.
• NAS web interfaces and the apps installed on a NAS that also holds backup copies.
• Self-hosted dashboards, wikis and ticket systems where admins store notes, runbooks or passwords.

A web app that falls to PHP2Shell gives the attacker a shell on that machine. From there, the attacker can look for saved credentials and reach anything that machine can reach. If the monitoring server can log in to the backup server, or an admin reuses the same password on both, the attacker can get to the backup server too.

CISA's PHP alert warns that PHP is often a component of other software and may not be directly visible. An appliance or vendor product can carry its own PHP without telling you.

What to do

1. Inventory every PHP install that can reach the backup server or repository. CISA asks for the same inventory and suggests starting with internet-facing systems.
2. Patch to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's fixed package, and restart every PHP worker. watchTowr notes the fix only takes effect after the restart. For Debian package names and a check loop for Proxmox guests, see the Proxmox PHP2Shell post.
3. If you run PHP 8.1 or older, php.net says those branches get no updates from the PHP project. Get a backported package from your vendor or upgrade. CISA advises taking PHP systems offline until they can be patched.
4. Keep the backup server and repository off the general network. Allow only the ports Veeam needs, from the hosts that need them, and do not let monitoring or dashboard servers hold admin logins to the backup server.
5. Use different credentials for the backup server and everything else. Check that no PHP app, wiki or ticket system stores the backup admin password.
6. Make the repository immutable. The Veeam Backup & Replication 13 User Guide says a hardened repository on Linux keeps backup files from being moved, modified or deleted during the immutability period you set. With single-use credentials, the guide says, an attacker who compromises the backup server cannot get the credentials to connect to the repository.
7. Watch for signs of compromise. CISA suggests looking for PHP worker processes that launch shells or download tools.

For Veeam's own past CVEs and how exposed backup servers get hit, see Veeam security CVEs and exposed backup servers. For the limits of immutability, see Veeam immutable backups and trust.