On October 20, details of two serious PHP vulnerabilities went public, a day before the PHP team shipped fixes. Together they're being called PHP2Shell: CVE-2026-109618 and CVE-2026-109619, each rated 9.2 out of 10. A few of you emailed us about it, which we appreciated.
Sendy runs on PHP, so this one concerned us directly.
Both let someone run code on a server by sending it a crafted web request. No login needed, and nothing in the app itself can stop it, because PHP processes the request before any app code runs.
The first one (109618) abuses what happens when a request pushes PHP past its memory limit. PHP gives up halfway through setting the request up, and the cleanup step then trusts data that was never finished.
The second (109619) is about leftovers. A PHP worker can carry state over from one request into the next, and one confirmed way to cause that is through a feature called session upload progress, which tracks how far along a file upload is. It's on by default, even in apps that never use it.
The official PHP advisory has the full details, and Datadog's write-up is a good deeper read.
The PHP advisory lists a setting for each bug. We applied both on every Sendybay server.
For 109619, we turned session upload progress off. Before doing that we checked that Sendy doesn't use it anywhere, not for CSV imports and not for image uploads, so nothing changes for you.
For 109618, we removed PHP's per-request memory limit. That sounds backwards, but hitting the limit is what the known exploit relies on, so with no limit that trigger is gone.
A server-wide PHP setting can normally be switched back by a small config file sitting in a folder, so we didn't just change the main config. We locked both settings at the web server level, for every customer site and server-wide as a fallback, where folder files can't override them. Every new Sendybay site gets the same lock automatically. Then we checked on live requests that the settings were really in effect, rather than trusting the config files.
No. Your Sendy works the same as before, imports and image uploads included. If something looks off, reply to any of our emails or open a chat and we'll look at it.
If you run PHP under Apache with mod_php, this is roughly what we added. It goes inside each <VirtualHost>, and once at server scope in apache2.conf:
php_admin_value memory_limit -1
php_admin_flag session.upload_progress.enabled OffOn PHP-FPM, the equivalent goes in the pool config:
php_admin_value[memory_limit] = -1
php_admin_value[session.upload_progress.enabled] = 0Restart or reload every worker afterwards. ini_set() and .user.ini don't help here, since PHP has already parsed the request by the time they run. Two things to watch: with no memory limit, one runaway script can use all of the server's RAM, so the advisory suggests a container or cgroup memory cap too. And on PHP 8.5, also set fatal_error_backtraces=0.
To check it took effect, put a throwaway script in one of your sites, load it in a browser, then delete it:
<?php
echo ini_get('memory_limit'), ' ', var_export(ini_get('session.upload_progress.enabled'), true);
// expect: -1 '0'We'll keep watching new research on this. If anything changes for Sendybay, we'll write about it here.