Is NewNet Lithium affected by the PHP2Shell vulnerabilities (CVE-2026-109618 / CVE-2026-109619)?

Overview

Is NewNet Lithium (TextPass) affected by the PHP2Shell remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619? Does the related PHP advisory CVE-2026-115560 apply to Lithium?

Information

No. NewNet Lithium Release 24.03 and Release 22.x are not affected by CVE-2026-109618 or CVE-2026-109619. This applies to all Lithium components, including MGR, CCI, RTR, AMS, HUB, FAF, LGP, STV and LGR. CVE-2026-115560 is a PHP advisory. Lithium does not include PHP, so it does not apply.

These vulnerabilities are defects in the PHP engine itself. An attacker can exploit them only on a server where a PHP engine (Apache mod_php, PHP-FPM, php-cgi or similar) handles incoming web requests. Lithium does not contain PHP, does not install PHP, and its web interfaces cannot load a PHP module. You do not need a Lithium patch, upgrade, configuration change or interim mitigation for these CVEs.

Why Lithium is not exposed:

1. Application software. Lithium components are written in C, Perl and Java. No component contains PHP code.
2. Web interfaces. The Manager (MGR) and CCI web interfaces are Perl applications. Apache HTTP Server serves them through mod_perl, not mod_php. Each interface runs as its own Apache instance from its own configuration file (for MGR: /var/TextPass/MGR/conf/MGR.conf), with a fixed list of modules (mod_perl, mod_apreq2, mod_ssl and standard Apache modules). These files do not include the system-wide Apache configuration, so a PHP module cannot load unless someone edits the file by hand. Apache itself is not vulnerable to these CVEs: the defect is in the PHP engine.
3. Bundled third-party software. The open-source packages that ship with Lithium (Apache Tomcat for the LGR reports application, MySQL, OpenJDK, Perl modules, HPE support tools) do not contain PHP and do not depend on it.
4. Operating system. The Lithium OS installation for Release 24.03 (RHEL 8.10) installs the Red Hat "core" and "base" package groups plus a fixed list of extra packages. PHP is not in that selection. On Release 22.x (RHEL 7.9), use the checks below to confirm the same result on each node.

Testing

To confirm this on your own servers, run these commands on each Lithium server (MGR, traffic nodes such as RTR, HUB and AMS, LGP nodes, and every other node). They are read-only, they change nothing, and they work as the textpass user.

cat /usr/local/etc/NMM-OS-release
rpm -qa | grep -i php
command -v php php-cgi php-fpm
ps -eo pid,user,args | grep -i '[p]hp'

1. The first command shows the Lithium OS image installed on that node.
2. The second command lists every installed package with "php" in its name. The third looks for a PHP engine on the system path, including copies that were not installed as packages. The fourth lists every running PHP process.
3. On a standard Lithium installation, the second, third and fourth commands print nothing. No output means that no PHP engine is present, so there is nothing to patch, mitigate or check for exploitation.
4. If any of these three commands prints output, PHP was installed outside the standard Lithium installation (for example, by a local tool or a monitoring agent). Do not change anything yet. Open a support ticket first, so that Support can review it with you.

On RHEL 8 nodes, a security scanner that inspects files on disk, not installed packages, can report PHP .rpm files in the local package repository folder /var/Packages/OS. This is expected: the Lithium OS installation copies the Red Hat package set into that folder. These files are not installed and do not run, so they do not cause an exposure.

Open a support ticket if:

• One of the PHP checks prints output. Send, for each affected server: the server name and its site, the node role (MGR, RTR, AMS and so on), the exact command, and its full output.
• Your security scanner reports PHP on a Lithium node and the finding is not one of the /var/Packages/OS files described above. Attach the full scan report, so that Support can match each finding to the file it refers to.
• Your organisation needs a formal written vendor statement for a security questionnaire. Name the CVEs in the ticket.
• Your question is about a Java or Tomcat advisory, not PHP. That is a different assessment: name the CVE in the ticket.