Matomo Issues 5.14.2 Patch in Wake of "php2shell" Exploits
The open-source analytics vendor shipped a security update. The release closed two tickets, one flagging vulnerable PHP inside the Matomo UI and another hardening a certificate dependency.
Matomo 5.14.2 went out today. The team called it an urgent core release. The reason: two critical PHP vulnerabilities were disclosed the day before, and they are being exploited right now.
There's a wrinkle worth flagging. Updating Matomo alone does nothing to stop these bugs. Because Matomo runs on top of PHP, the actual fix has to happen in the installation underneath it. Upgrade the app and you've patched the wrong thing.
That's why the release opens with a warning banner aimed at self-hosted (On-Premise) users. It points to a Matomo security blog post published October 21. The guidance is a simple three-step checklist: check your PHP version, apply the latest security patch, verify the web server is serving the new build. Keep in mind that upgrading Matomo won't move that needle.
The php2shell vulnerability
Matomo itself had no bug to fix here. The story starts with the PHP runtime. On October 21, the PHP security team disclosed two vulnerabilities that affect the interpreter before any application code runs.
CVE-2026-109618 is a memory corruption flaw tied to how PHP handles out-of-memory errors. CVE-2026-109619 is an internal state management problem that can lead to unsafe memory access. Both score 9.2 out of 10 on the CVSS scale, and they carry the nickname "php2shell" because a successful exploit hands an attacker a shell on the victim server.
The danger is architectural. Datadog Security Labs put it best: application-level authentication can't block an attack, because PHP processes the malicious request before any application code runs. The flaws aren't in Matomo or WordPress or Laravel. They're in the language itself.
That includes mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed. Every PHP web deployment stands exposed at once.
This isn't a theoretical hole. AWS said it observed php2Shell exploitation attempts in the wild as early as October 17, 2026, roughly four days before the public disclosure. By October 21, multiple vendors including Tenable, Wiz, Huntress, and Patchstack confirmed untargeted scanning and active exploitation. The FBI Cyber Division issued its own warning.
The patched PHP versions are already out: 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Every supported branch from 8.2 onward is in scope. If you're still on 7.4, 8.0, or 8.1, you've passed normal upstream support, though the PHP team published minimal source backports for those branches. Check your OS vendor's advisory first, because packaged fixes sometimes ship without a version bump.
For those waiting to patch, some community stopgaps exist but fall short. Setting memory_limit to -1 blocks the known path for CVE-2026-109618 but isn't a real fix, and disabling session.upload_progress doesn't fully close CVE-2026-109619. A reverse proxy or WAF that trims oversized form submissions can buy you time. Patching is the only answer that holds up.
What Matomo shipped
The substantive changes in 5.14.2 are slim by design. Per Matomo's changelog, the release is a patch with an important security notice, and it closed just two tickets under Security.
Ticket #25566 is the one that matters. It adds a warning mechanism that flags On-Premise installations running a vulnerable PHP version, surfacing the risk directly inside the Matomo UI so admins can't overlook it. Ticket #25563 is more routine: it bumps composer/ca-bundle to 1.6.0, keeping Matomo's trusted root-certificate set current for outbound HTTPS requests.
Not a php2shell fix, but tidy supply-chain hygiene bundled into the same urgent release. There is no developer-facing API change either, which is exactly what you'd expect from a security patch. The work is internal and operational, not structural. No database upgrade is required, so the update itself should be quick and low-risk.
The clean split in Matomo's messaging is the quieter point of all. Cloud customers, Matomo says, are already protected because the company manages the underlying infrastructure and PHP upgrades for them. You don't track language releases or babysit a server.
Self-hosted users get a different ask. For the roughly 1.4 million sites that run Matomo on their own hardware, this is an urgent nudge to check versions, patch, and rebuild container images still running old PHP. It's a classic infrastructure snag: a CLI php -v can report a different version than the process actually serving the web app, so "patched" is something you verify rather than assume.
It's a bit ironic, honestly. Matomo is built as the privacy-respecting, self-hosted alternative to Google Analytics, and its own security note reminds users that the platform protecting their data depends on a layer it can't control. The source is GPLv3 and the insights are in-house, yet the exploit surface is owned by the PHP team.
That's the supply-chain reality of modern software in a nutshell. An application can ship a perfect patch and still leave its users exposed, purely because it lives on top of something else.
Head here to the changelog.
Install Matomo on Debian 13: Complete Self-Hosted Analytics Guide
This tutorial walks through installing the latest Matomo version on Debian 13, bypassing the outdated repository release to access features like AI chatbot detection, Dark Mode, and improved segment management.
Install Matomo on Debian 13: Complete Self-Hosted Analytics Guide
