People should not blindly copy and paste some long scripts they found on a forum.
Migrating from launchpad to packages.sury.org is simple and documented officially here:
https://packages.sury.org/php/README.txt
I urge the MIAB team to release an update that moves to the new repo ASAP.
You can also follow the discussion with Ondrej here: #145 - Upcoming Critical PHP Security Release - oerdnj/deb.sury.org - Codeberg.org
fmonts that was the perfect link. Thank you. I used the readme to move from launchpad to packages.sury.org, and the apt update shows that the new version got installed. Restarted the box and unblocked http and https.
Thanks, I used the script and everything works 
I’ve switched from https://launchpadcontent.net to http://launchpad.net, because I was getting 503 errors. However, I was a bit baffled when I noticed that I have a whole PHP version museum (8.0, 8.1, 8.2, 8.3, 8.4) installed and running, and miab uses only 8.0. I’m a bit hesitant to change the php upstream in nginx to like 8.4 and disable the other php services. Has anyone done that, and can confirm that there are no regressions?
had the same,
what worked was chatgpt’s attempt to allow for higher timeout and retries and ipv4 only, worked for me - if all are needed, i havent tested, but allowed me to do it without doing any modifications
sudo apt-get -o Acquire::Retries=10 -o Acquire::http::Timeout=60 -o Acquire::https::Timeout=60 -o Acquire::ForceIPv4=true upgrade --download-only
took a bit, and then upgrade:
sudo apt-get upgrade --no-download
I haven’t changed any repos, just:
# apt -y update
# apt -y upgrade
# zcat /usr/share/doc/php8.0-common/changelog.Debian.gz | grep -A1 'CVE-2026-109618, CVE-2026-109619'
+ [CVE-2026-109618, CVE-2026-109619]: Avoid state corruption via
bailout.
# apt list --installed | grep php
libawl-php/jammy,now 0.62-1 all [installed]
php-common/jammy,now 2:101~+ubuntu22.04.1+deb.sury.org+1 all [installed,automatic]
php-pear/jammy,now 1:1.10.16+submodules+notgz-2+ubuntu22.04.1+deb.sury.org+1 all [installed,automatic]
php8.0-apcu/jammy,now 5.1.28-2+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-bcmath/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-cli/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-common/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-curl/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-dev/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-fpm/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-gd/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-gmp/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-imagick/jammy,now 3.8.1-1+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-imap/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-intl/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-mbstring/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-opcache/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed,automatic]
php8.0-pspell/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-readline/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed,automatic]
php8.0-soap/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-sqlite3/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-xml/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0-zip/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 amd64 [installed]
php8.0/jammy,now 1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1 all [installed]
pkg-php-tools/jammy,now 1.42build1 all [installed,automatic]
PHP2Shell (CVE-2026-109618 / CVE-2026-109619) affects Mail-in-a-Box on Ubuntu 22.04.
Roundcube, Nextcloud and Z-Push run on php8.0-fpm from ppa:ondrej/php. It’s critical, unauthenticated RCE in the interpreter itself, and I’ve already seen a php2shell-scan probe on my box. Unattended upgrades won’t pick up the fix by default, because it comes from the PPA.
PHP 8.0 is EOL. There’s no official 8.0 release with the fix. Ondřej has packaged PHP’s own source backport as 1:8.0.30-25.
sudo apt update
apt-cache policy php8.0-fpm # candidate should be 1:8.0.30-25 or later
sudo apt install --only-upgrade 'php8.0*'
sudo systemctl restart php8.0-fpm # restart, not reload, so every worker is replaced
zgrep CVE-2026-10961 /usr/share/doc/php8.0-fpm/changelog.Debian.gz
php -v shows 8.0.30 either way.-25 isn’t on your mirror yet: sudo systemctl stop php8.0-fpm && sudo systemctl mask php8.0-fpm. Masking stops apt or a setup run from starting it again. SMTP, IMAP and /admin keep working. Webmail, Nextcloud/CalDAV/CardDAV and ActiveSync phones stop until you unmask it.session.upload_progress.enabled=0 and an admin-level memory_limit=-1, then restart all workers. Both are partial.php2shell-scan and the error log for Allowed memory size. Also look for repeated 500s after multipart POSTs, oversized PHPSESSID cookies and unexplained FPM worker restarts. That user agent is just one tool, so a clean grep means no indicators found, not that nobody tried.systemctl stop nginx
– is the current remediation, until MIAB releases an update that runs on something newer than php8.0 which has been out of support for like 2 years, and it’s not getting a patch –
so no, apt update /upgrade will not patch this issue.
You can probably hack a newer version of php in, (I have RC running on another server with newer php, it’s not that hard to do) but what’s going to happen when the official update is released by MIAB, and it fails because you’ve hacked it up
The quickest fix is to drop both 443 from the UFW and that’s it. It is also quite easy to make it permanent across setup runs by forking and adding it to the setup process.
A bit more complicated: remove all PHP services (Push, Roundcube and NextCloud). Panel stays.
As a matter of fact: The MiaB is not getting the love it desreves. It is still running on ancient OS, and ancient software stack. I am starting to consider to leave the boat for something else.
Since the publically available web services rely on the systems installed php version, and we have already determined that the current php repository has pushed the backported fixes, an apt upgrade of the php packages will suffice.
There is a strong candidate for Ubuntu 26.04, which migrates most applications to their latest versions, including php to it’s latest at time of configuration, php8.5.
In a timely manner, @JoshData will review all candidates and provide his own input. Due to the limited amount of time he can dedicate to this task, please be patient.
no need now – I’m installing v78, which was announced 4 minutes ago
well it sounded good, – only the php.ini has been updated, and while the ‘work-around’ has been put in, that’s not foolproof.
This appears to be patched in Ubuntu now via a backport. I haven’t updated Mail-in-a-Box, but I’ve updated the Ubuntu 22.04 LTS server, and php -v now shows:
PHP 8.0.30 (cli) (built: Oct 21 2026 14:24:26) ( NTS )
and zless /usr/share/doc/php8.0-cli/changelog.Debian.gz now shows:
php8.0 (1:8.0.30-25+ubuntu22.04.1+deb.sury.org+1) jammy; urgency=medium
* Backported from 8.2.35
+ [CVE-2026-109618, CVE-2026-109619]: Avoid state corruption via
bailout.
-- Ondřej Surý <ondrej@debian.org> Wed, 21 Oct 2026 06:51:39 +0200
So I think we’re good to just update Ubuntu at the moment.