Security - PHP RCEs reported

Switching to latest is the recommended way for a production server? :-/
No, security patches are always merged to quarterly. For critical production servers, quarterly is always the best choice as changes that land in latest may break stuff occasionally (especially if toy languages are involved that break stuff left and right even in minor or patch releases...)

Setting up ports with build tools on each webserver? 🙈
No, that's what poudriere is there for. If you run a considerable number of hosts this has a lot of other benefits; first and foremost: you can change build options and drastically decrease the number of dependencies dragged in on every system.

For single hosts, just build the port locally. The requirements/dependencies are dictated by the port(s) you are building. Major rule of thumb (also if you don't build yourself): Avoid bloatware that has a ton of bloated/obscure/fast moving dependencies or adjust its build options if possible to make them bearable.
 
Are the official repositories rebuilt concurrently? Seems to be serving vulnerable versions still at this time...
Code:
# pkg search '^php8[2-5]-[0-9].*'
php82-8.2.34                   PHP Scripting Language (8.2.X branch)
php83-8.3.35                   PHP Scripting Language (8.3.X branch)
php84-8.4.26                   PHP Scripting Language (8.4.X branch)
php85-8.5.11                   PHP Scripting Language (8.5.X branch)
# pkg -vv | grep url
    url             : "pkg+https://pkg.freebsd.org/FreeBSD:14:amd64/latest",
    url             : "pkg+https://pkg.freebsd.org/FreeBSD:14:amd64/kmods_latest_5",
# freebsd-version
14.5-RELEASE-p2
# date
Thu Oct 22 11:05:35 CEST 2026
 
also relevant:
The official mirrors of the FreeBSD project are made up of many machines operated by the project cluster administrators and behind GeoDNS to direct users to the closest available mirror.

So it may take some time for your local mirror to sync.

Caching by fastly may also be involved (depending on how quick fastly handles upstram changes)
 
Any ETA till PHP packages are build and available?
Because imho this is taking quite long. Even though i think this PHP CVE is massively overhyped. There are probably less savvy people, or people that dont want to mix with ports or switch to ports.
 
right now, the "german/europe" mirror doas not have the latest builds available:

Code:
root@zabbix:~ # pkg search '^php8[2-5]-[0-9].*'
php82-8.2.34                   PHP Scripting Language (8.2.X branch)
php83-8.3.35                   PHP Scripting Language (8.3.X branch)
php84-8.4.26                   PHP Scripting Language (8.4.X branch)
php85-8.5.11                   PHP Scripting Language (8.5.X branch)
 
right now, the "german/europe" mirror doas not have the latest builds available
As far as I can tell the build server hasn't even built the updates for quarterly yet, so no mirror will have them.

I would suggest switching to latest, at least temporarily, if you really, really need those updates. 2026Q4 is relatively new, so quarterly and latest haven't diverged much yet.
 
When somebody else throws a wrench into a system you are responsible for, it's ones responsibility to make sure it all holds together still. Unlike others where things are thrown together piecemeal.
 
I have just taken my sites offline again for the second time after discovering another problem with PHP parsing which suddenly stops and sends the rest of the code as page output! It's possible the rush to get the upgrade out the door before it was planned has let another critical bug slip through. I have e-mailed the ports secteam although I suspect the problem will be upstream.

I would recommend others take their sites offline if they have applied the upgrade until we have more clarity what is going on.
 
No, security patches are always merged to quarterly. For critical production servers, quarterly is always the best choice as changes that land in latest may break stuff occasionally (especially if toy languages are involved that break stuff left and right even in minor or patch releases...)
Well that question actually was ironic. Therefore the smiley. I know that security patches are merged in quarterly, but now quarterly is no option. The patches should have been there yesterday, but they even won't arrive today, maybe tomorrow or even later.
Therefore the situation now is: one cannot run a server with php on quarterly packages.

I do not run critical services with php, I've just switched those server to latest. But the same thing will happen with other services again.
 
But why will it pay off?
You control what and when things are updated. You can easily rollback patches/updates too (had to rollback certain ports in the past, the update broke things). Or set your own preferred defaults, options and whatnot. You control when and how things get updated and are not solely depended on external parties.
 
The patches should have been there yesterday

from git log on quarterly:
Code:
commit cb05cf3614f3a551a3736a4e79d4dcc2de1eedfb
Author: Muhammad Moinur Rahman <bofh@FreeBSD.org>
Date:   Wed Oct 21 15:40:09 2026 +0200

    lang/php85: Update version 8.5.11=>8.5.12
    
    Changelog: https://www.php.net/ChangeLog-8.php#8.5.12
    (cherry picked from commit e8700f53ce9c77397edbd655f8295be28ba028bb)

commit 7a6267b36ff10bafe4cbd6d1bf08944e28b4ab5b
Author: Muhammad Moinur Rahman <bofh@FreeBSD.org>
Date:   Wed Oct 21 15:39:59 2026 +0200

    lang/php84: Update version 8.4.26=>8.4.27
    
    Changelog: https://www.php.net/ChangeLog-8.php#8.4.27
    (cherry picked from commit ea776f8034d60817544042ae3e998946d17b5a0f)

commit ee859888d2aa31a6ea2e1a2bc4028ad309142619
Author: Muhammad Moinur Rahman <bofh@FreeBSD.org>
Date:   Wed Oct 21 15:39:49 2026 +0200

    lang/php83: Update version 8.3.35=>8.3.36
    
    Changelog: https://www.php.net/ChangeLog-8.php#8.3.36
    (cherry picked from commit 7ec44607534ad09fb0519502d382ead218958d69)

commit 6d1e46896a39ba8c5c2860cb1e11bf1e9cba76cd
Author: Muhammad Moinur Rahman <bofh@FreeBSD.org>
Date:   Wed Oct 21 15:39:04 2026 +0200

    lang/php82: Update version 8.2.34=>8.2.35
    
    Changelog: https://www.php.net/ChangeLog-8.php#8.2.35
    (cherry picked from commit 8db9e9b204799193fa62d38bbe568ee29a47e7ab)
 
I have just taken my sites offline again for the second time after discovering another problem with PHP parsing which suddenly stops and sends the rest of the code as page output! It's possible the rush to get the upgrade out the door before it was planned has let another critical bug slip through. I have e-mailed the ports secteam although I suspect the problem will be upstream.

I would recommend others take their sites offline if they have applied the upgrade until we have more clarity what is going on.
False alarm! Apparently PHP wasn't running on the page so all the code up to the first > was seen by the browser as one giant unknown HTML tag! Now I have to find out why PHP wasn't being used.
 
You control what and when things are updated. You can easily rollback patches/updates too (had to rollback certain ports in the past, the update broke things). Or set your own preferred defaults, options and whatnot. You control when and how things get updated and are not solely depended on external parties.
OK, for now I just relied on bectl to rollback, if an update failed.

from git log on quarterly:
But no ready to use package.
 
Hi,

What is the recommendation for FreeBSD 15.1 servers in production: continue using "quarterly" or switch to "latest"?

The FreeBSD servers I have in production have this:


# date

Code:
Thu Oct 22 08:28:52 -05 2026


# freebsd-version

Code:
15.1-RELEASE-p5


# cat /etc/pkg/FreeBSD.conf

Code:
#
# To disable a repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file, e.g.:
#
#   mkdir -p /usr/local/etc/pkg/repos
#   echo "FreeBSD-ports: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#   echo "FreeBSD-ports-kmods: { enabled: no }" >> /usr/local/etc/pkg/repos/FreeBSD.conf
#
# Note that the FreeBSD-base repository is disabled by default.
#

FreeBSD-ports: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/quarterly",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
FreeBSD-ports-kmods: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_quarterly_${VERSION_MINOR}",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
FreeBSD-base: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/base_release_${VERSION_MINOR}",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkgbase-${VERSION_MAJOR}",
  enabled: no
}

That's why I'm using "quarterly"



In the past, for a desktop FreeBSD release I was using, I have in my notes that I made the change from "quarterly" to "latest" using this procedure:


# mkdir -p /usr/local/etc/pkg/repos
# edit /usr/local/etc/pkg/repos/FreeBSD.conf


Code:
FreeBSD: {
  url: "pkg+https://pkg.freebsd.org/${ABI}/latest"
}


# /usr/sbin/pkg


Code:
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y

# pkg update
# pkg install -y rsync


Is this still the procedure?


Thank you for your responses!
 
Back
Top