PHP Vulnerability Question

[gleckey]

Do the new PHP Vulnerabilities’ CVE-2026-109618 (RCE via OOM corruption) and CVE-2026-109619 (RCE via stale global state) apply to FOG? And if so, will there be a patch?

[Tom Elliott]

@gleckey no patch would be necessary for FOG. The PHP vulnerability applies to PHP packages, not to fog.

Now, you can update the packages using your OS package management, or you can rerun the installer for FOG which also tries to update any of the packages FOG may need. Either option will work.

[gleckey]

@Tom-Elliott I figured it was more-so on the internal end of things that we had to take care. But, wanted to make sure. Thank you for your response!

[Dominique]

@Tom-Elliott Hi Tom

We have a Red Hat 8 server with FOG Project version 1.5.10.
The PHP version is 7.2.24.
We can upgrade this to the latest one without having issues with FOG console and registering, uni or multicast imaging?

Thx!

[Tom Elliott]

@Dominique Running such an old version of PHP and FOG probably not a good thing.

While 1.5.10 worked on the 7.2 line I don’t recall if it accounted for 8.X versions of PHP, You’re willing to attempt it but I would still highly recommend updating to the latest for both the stable and php versions (and if you’re updating FOG may as well update to the rc-1.6.0 version as I plan on mid november timeframe to make it official and need feedback to ensure all is well.

Thank you!

[Dominique]

@Tom-Elliott Thx for your reply.

We use FOG in a production environment. So I will hold for version 1.6.0 till GA .
I will test the RC in a test environment.

I will upgrade PHP on the Redhat server. Should I re-install FOG project with the original settings after upgrading PHP. Or isn’t that necessary?

[Tom Elliott]

@Dominique If you’re able to, I’d highly suggest to snapshot the server first, or otherwise ensure you have a path to reinstall php down to 7.2 just incase updating to 8.X breaks your 1.5.10 availability.

No, you shouldn’t need to re-install fog after updating PHP, but it also wouldn’t hurt anything (but again I highly recommend snapshotting if possible just due to the age of 1.5.10 vs the stable branch code base.)

[Dominique]

@Tom-Elliott Any idea which PHP 8 version is best suitable for 1.5.10?

[Tom Elliott]

@Dominique I can’t promise that, no.

1.5.10 is the original release, and it is a long way behind now. It was built and tested against PHP 7.x. It may run fine on PHP 8, but I don’t know which PHP 8 version, if any, would be safe for it.

What we do know works on PHP 8 is the current stable branch. Here is how the branches fit together:

• master is the official 1.5.10 release. We don’t work on it directly.
• dev-branch is where all the bug fixes and maintenance happen.
• stable gets everything from dev-branch rolled into it once a month.

So stable is 1.5.10 plus a few years of fixes, PHP 8 support among them.

If you want to move to PHP 8 before 1.6.0 comes out, I’d do it in this order:

• Snapshot the server first, so you can roll back.
• Update FOG to the stable branch and run the installer. Do this while you are still on PHP 7.2.
• Then move PHP to 8.2. On Red Hat 8 the installer will not do that for you; it installs whichever PHP module is enabled. Run dnf module reset php then dnf module enable php:8.2, then dnf distro-sync.
• Re-run the FOG installer, so it picks up the new PHP packages.
• Test the web console, a host registration, and a unicast and a multicast deploy before you call it done.

Since this is production, your plan to wait for 1.6.0 and try the RC in a test environment first is a good one too.