PHP CVE-2026-109618 CVE-2026-109619 patch possibly?

Uncategorised Topics
1

For users with docker , will xibo be releasing a patched version of the current cms ? I’m a little paranoid as we had magic info compromised in the past of a reported vulnerability they neglected to patch.

2 Likes
2

We’re monitoring it. Once official information is released we’ll make a call on what needs to be done.

1 Like
3

We are preparing a release now.

In the interim, you can do:

docker compose exec cms-web bash
apt update && apt dist-upgrade -y
apt-cache policy php8.4

You should see 8.4.27-1+0~20261021.57+debian13~1.gbp7636b9 as the installed version.

If so, exit to come out of the container, and then restart it:
docker compose restart cms-web

XMR will need to be addressed too. That’s more tricky so an updated container will come for that.

5 Likes
4

Awesome thank you for the quick turn around

3 Likes
5

Looks like 3.3.13 was released. Will there be a patch coming for 4.5.4 as well?

6

Yes a 4.5.5 release is on the way. You’ll need to update XMR as well and new builds for that are coming too.

2 Likes
7

Do you recommend waiting until 4.5.5 or should we just go ahead with 4.5.4?

8

It’s fine to use the workaround above in the short term. The new image is coming soon. I can’t be more specific about exactly when, but we’re working on it now.

9

The new releases are both out and finalised: Changelog | Xibo Docs

Both contain a new XMR container - the older 3.3 release (XMR 0.9.1) has manual patches applied to fix the two CVEs, the 4.5 release (XMR 1.4) has the newest packages pulled in.

4 Likes
11

Thanks for getting out a new release so quickly. I hate to admit it, but I’ve been dragging my feet and have been running an old 2.3 CMS on an old AWS EC2 for the past 6 years. Xibo has been just a set it and forget it type program for me so I appreciate what you guys have built and maintained over the years.

This vulnerability got me off my @ss and I was able to do a fresh install on an AWS Lightsail instance for 60% less. Pretty painless. I’ll try to keep up with the updates from now on.

3 Likes
12

Hi team, thanks for getting this all patched so quickly!

I’ve encountered an issue when trying to pull XMR 0.9.1, getting a manifest unknown error. Looking at the container repo on GitHub, I can see 1.4 is there but not 0.9.1

13

Thanks for the rapid update.

We are running a number of 3.3.x instances and have applied the update to a test system following which we noticed a couple of issues:
The version number still reports as 3.3.12 which makes it unclear whether we have actually applied the update
As reported previously there is not XMR 0.9.1 to pull we had to revert to 0.9.0

Peter

14

Thanks for letting us know. It was built but it went to Dockerhub instead of Github Container Registry. It’s there now in ghcr too. If you’re using v3 then you should update the container to 0.9.1 as well.

15

Appreciate this makes it unclear, sorry about that. We focused on rebuilding the containers without additional code changes, and missed updating the version number.

So that we’re as clear as we can be:

  • Xibo Cloud platform = 3.3.12 is fully patched
  • Self-hosting with Docker = release-3.3.13 is fully patched, but reports 3.3.12 as it’s version number
  • Self-hosting on directly = patching is your responsibility – there are no code changes in 3.3.13 which can help

Thanks,
Dan

1 Like
16

The instructions using apt do not apply to a container within Xibo 3.0.3. That environment uses apk under Alpine Linux. The Xibo 3.0.3 web container runs PHP version 7.3.30. Based on my research, it’s not possible to easily upgrade to PHP version 8.4 using apk. Feel free to correct me if I’m wrong :slight_smile:

17

3.0.3 doesn’t receive any kind of updates. You need to update to 3.3.13 or 4.5.5.

18

okay, just working on an update to 3.3.12. thank you :slight_smile: … Unfortunately, after that, the website wouldn’t load anymore—it showed a proxy error—and about 100 clients reported the same error to Apache. After successfully completing about 50 updates, I actually thought I knew how to do this. ^^ Surprisingly, the old version stopped working too. An image restore fixed the problem. Well, I’ll take a closer look tomorrow.

19

3.3.13. The CMS will report as 3.3.12 but the 3.3.12 containers do not have the fix - you need the ones labelled 3.3.13.

20

okay got it. 3.3.12 up-and-running. two problems occured. the proxy-error could be fixed with an additional entry in config.env: MYSQL_HOST=cms-db
MariaDB-mysqldump posted an additional problem: "Access denied; you need (at least one of) the PROCESS privilege(s) … when trying to dump tablespaces".
solved with additional config:
“[mysqldump]
no-tablespaces”
loaded as file in a permanent mount under cms-web.
after recreating the web-container: Dump-Exitcode 0.

But: still some questions remaining:
Xibo 3.3.12 Docker image: outdated PHP and Alpine versions
I have successfully upgraded our Docker installation from Xibo 3.0.3 to 3.3.12 using:

ghcr.io/xibosignage/xibo-cms:release-3.3.12

The CMS is accessible and displays are checking in again. However, checking the container revealed:

  • Alpine Linux 3.15.11

  • PHP 7.4.33, Alpine package revision 7.4.33-r1

  • PHP build date: April 14, 2023

PHP 7.4 reached upstream end of support in November 2022, and Alpine 3.15 reached its regular end of support in November 2023.

Could you clarify whether this image includes security backports beyond those support dates? Is there a maintained image for Xibo 3, or is upgrading to a newer major Xibo version the recommended way to obtain a supported PHP and operating system base?

I would prefer to follow a supported upgrade path rather than replace PHP independently inside the container.

Thanks for your guidance.

21

You need to use release-3.3.13 which has backported security fixes.

The latest version of Xibo (4.5) is the only version that gets PHP upgrades as a matter of routine.

1 Like