On 21 October 2026 the PHP project published fixes for two critical remote-code-execution flaws, named PHP2Shell. PHP sits inside more products than most buyers realise, and digital signage is one of them: some players and some content management systems run PHP, and some do not. This article sets out what the flaws are, what SpinetiX did about them and how fast, which signage stacks we could verify as exposed or not, and what to ask a vendor this week. Where we could not verify something, we say so.
What PHP2Shell is
PHP2Shell is the name given to two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, disclosed with the PHP security advisory of 21 October 2026. The first lets an attacker reach remote code execution by pushing PHP into an out-of-memory condition. The second involves request state that survives after its memory has been freed. Both are scored 9.2 on CVSS 4.0 by the PHP project, and NVD adds a CVSS 3.1 score of 9.8. The PHP project says unauthenticated remote code execution is possible and that every PHP installation serving web requests is at risk, with the highest risk for Apache running mod_php.
| Item | Detail |
|---|---|
| Affected PHP | CVE-2026-109619 from 5.4.0, CVE-2026-109618 from 7.3.0 (NVD configuration data) |
| Fixed upstream | PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 |
| End-of-life branches | No official release; minimal source backports for 7.4, 8.0 and 8.1 |
| Exploitation | Attempts reported; no confirmed successful exploitation per CISA's alert |
| CISA KEV | Not listed as of 23 October 2026 |
On exploitation we keep to what the sources say. Amazon reported an attempt on 17 October, before disclosure. CISA, in its alert of 21 October, revised on 23 October, says it has not observed successful exploitation of these vulnerabilities in the wild. Neither CVE is in the Known Exploited Vulnerabilities catalogue; we explain what that listing means in what a CISA KEV listing means for your signage CMS. Estimates of exposed hosts vary from about 1.3 million to over 5.1 million, which tells you the count is not settled.
The SpinetiX timeline, in UTC
SpinetiX documents its position on a single PHP2Shell page on its support wiki. The times below come from the PHP project's published advisories and that page's edit history.
| When (UTC) | Event |
|---|---|
| 21 Oct, 13:34 | PHP advisories published (clock starts) |
| 22 Oct, 05:42 | Hosting provider finishes patching the SpinetiX websites |
| 22 Oct, 07:55 | SpinetiX advisory page created, about 18 hours after disclosure |
| 22 Oct, 17:15 | DSOS 5.0.0 released, about 28 hours after disclosure |
The advisory came the morning after disclosure and fixed firmware the same evening. One point of wording matters: DSOS 5.0.0 "Zinalrothorn" is a planned major release that also carries feature work (a new SNMP MIB, crash-dump collection, a change to the update mechanism), and the PHP fix is one entry in its security section alongside updates for ten curl CVEs. It is not a single-purpose emergency patch, and we would not describe it as one.
What the advisory says, in short. Affected: DSOS 4.0.0 through 4.10.0, through the Control Center, RPC and DiVA CMS functions. Fixed: DSOS 5.0.0 and later. Not affected: Elementi and the SpinetiX cloud. Until a player is updated, SpinetiX's workaround is that DSOS devices are not reachable from the internet and are accessible only from trusted networks. If you have not segmented your signage network yet, network segmentation and zero trust is the practical starting point, and the secure update strategy covers staging a firmware rollout.
An honest limit on the DSOS fix
DSOS 5.0.0 still reports PHP 8.1.34. PHP 8.1 reached upstream end of life on 31 December 2025, so the PHP project no longer ships updates for it. SpinetiX states that its 8.1.34 build includes backported fixes for both CVEs, and the 5.0.0 release notes list the php fix, but a backport on an end-of-life branch is the vendor maintaining a branch the upstream has dropped. We cannot independently verify the backport and have not tested it. A buyer should take it as a vendor statement backed by a released fix, keep the network restriction in place regardless, and expect the PHP version to move on in a later release. We would rather say this here than have you find it in the version string.
Which signage stacks are exposed
The table below covers only what we could confirm from public sources on 24 October 2026: vendor documentation, open-source repositories and release notes. Vendors other than SpinetiX are not named. "No PHP found" means we found none, not that none exists.
| Stack | PHP2Shell position | Basis |
|---|---|---|
| SpinetiX DSOS 4.0.0 to 4.10.0 | Affected; fixed in DSOS 5.0.0 | SpinetiX advisory, release notes |
| SpinetiX Elementi and cloud | Not affected | SpinetiX advisory (no PHP components) |
| One British open-source CMS | PHP product; a security release followed about 2.5 hours after the PHP advisories | Its development branch requires PHP 8.4 and its official Docker image runs it under Apache mod_php; release notes name both CVEs |
| One American player brand | No PHP in its OS image | Build recipes in its published open-source source bundles for two OS releases |
| One Korean display maker's CMS server | Not affected | Java and Tomcat, per vendor documentation |
| One Greek cloud CMS | No PHP found | Python backend, per the vendor's own job posting; the player image was not checked |
| Open-source players built on Node, Python or Ruby | Not affected | Source repositories contain no PHP |
| One Swiss software brand | No PHP found | Public documentation describes Windows Server, IIS and SQL Server; the player firmware was not checked |
Read the British row fairly: that vendor shipped its fix faster than SpinetiX did, and it did so on a stack that sits in the highest-risk PHP configuration. A fast fix on an exposed stack and a clean non-PHP stack are both reasonable positions. Neither tells you anything about vendors we did not check.
Why most vendors said nothing
Among the signage vendors we looked at, SpinetiX is the only player hardware maker with a public PHP2Shell statement we could find. Most others published nothing. That is not negligence in itself. For many of them the product is not built on PHP, or the stack is not public, and a vendor with no PHP has nothing to announce. The silence becomes a problem only for a product that does run PHP and says nothing, and from the outside you cannot tell those two cases apart. That is why the useful move is to ask, in writing.
Five questions to ask your signage vendor this week
- Does any component of the player, the CMS or the vendor's cloud run PHP? A yes or no, per component, in writing.
- If yes, which PHP version and which web server interface? A version number is not enough; mod_php, PHP-FPM and FastCGI carry different exposure.
- Which release contains the fix, and when did it ship? Ask for the build number and the date, not "we are on it".
- Is the PHP branch still supported upstream, and if not, who maintains the patches? An end-of-life branch with vendor backports is a legitimate answer; it should be an explicit one.
- What should a customer do until the fix is installed? Expect a concrete network restriction, not a general reassurance.
Put the same questions into your next tender. The case against slow update cycles explains why the answer on the fixed release and its date matters more than any certificate on a datasheet.
What to do this week
If you run SpinetiX players, list which are below DSOS 5.0.0, confirm none is reachable from the internet, then update in stages, starting with a pilot group. If you run another vendor's system, send the five questions above and keep the replies on file. In both cases, check that management interfaces are not published to the internet, which is the control that limits the damage of this and the next vulnerability. If an unpatched device was exposed, move to the incident response playbook. For help auditing an estate, talk to Media La Vista.