Security - PHP RCEs reported

msplsh · 2026-10-23T03:06:03+0100

Thanks to Muhammad Moinur Rahman who is hilariously "bofh" and Bryan Drewery (bdrewery)

rotor · 2026-10-23T05:07:45+0100

Yeah, I've just switched all my 14.4 FreeBSD servers over to quarterly pkg updates.

That seems to be the current focus of the FreeBSD team regarding security for the 14 branch.

Franconian_Witchcraft · 2026-10-23T07:33:14+0100

SirDice said:
On https://pkg-status.freebsd.org/builds?jailname=144amd64 I can see the quarterly build was started Wed, 21 Oct 2026 19:31:46 GMT

Could please someone explain what "Exp builds", "Package builds" and "Qat builds" means on this site?

rotor said:
If one is interested in the security of the pkgs, and not the latest updates of the pkgs, should one use quarterly or latest?

My impression: it depends

E.g.: I'm running a Navidrome server at home. It was on quarterly and did not receive important security fixes at all. Why? Probably because Navidrome has no feature and bugfix releases. Just run the most recent feature release to also getsecurity fixes. So I've switched that server to latest.

rotor said:
That seems to be the current focus of the FreeBSD team regarding security for the 14 branch.

For me it seems to be random, which builds are started first and therefore finish first. Could anybody clarify?

TS · 2026-10-23T07:51:15+0100

~~I am still not seeing the update for PHP85 on my 14.4 (quarterly) machine~~.
Ok, I upgraded the system to 14.4p12 and now the update came through. Is this related?

It seems that the Fastly CDN is very, very slow to mirror the changes.
Would any of the FreeBSD Mirrors) have the latest updates, and how could I point pkg to download them?

angelvg · 2026-10-23T09:56:35+0100

Nothing for 15.1-RELEASE quarterly...

I’m starting to get worried. Three days, and nothing. I no longer know what to say at work to explain the time taken.

Should I change the servers in production to "latest"?

What do you recommend doing?

P.D.:
I started a Poudriere build yesterday to try and generate the binaries... I’ll check in a few hours to see if the build has finished.

SirDice · 2026-10-23T10:05:50+0100

Franconian_Witchcraft said:
Could please someone explain what "Exp builds", "Package builds" and "Qat builds" means on this site?

Only look at the package builds, those are the ones that will end up in the various repositories. You don't need to worry about the others.

covacat · 2026-10-23T10:15:23+0100

arm64 does not have it in latest either. just build it yourself

SirDice · 2026-10-23T12:34:39+0100

It's possible they might be waiting for www/node22, www/node24 and www/node26 to be updated. No inside information, just a guess.

Node.js — Wednesday, October 21, 2026 Security Releases

Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts.

nodejs.org

CVE-2026-111497 is an RCE.

Koen Martens · 2026-10-23T13:24:13+0100

angelvg said:
Nothing for 15.1-RELEASE quarterly...

I’m starting to get worried. Three days, and nothing. I no longer know what to say at work to explain the time taken.

Yeah, it's gone beyond embarrassing. I mean, FreeBSD was always lagging behind with security patches compared to most Linux distributions, but it's been days now.

angelvg said:
Should I change the servers in production to "latest"?

What do you recommend doing?

P.D.:
I started a Poudriere build yesterday to try and generate the binaries... I’ll check in a few hours to see if the build has finished.

Most of the servers I manage that are on FreeBSD and run PHP are still down because they're far from critical. There's one where after a day I couldn't justify waiting any longer, I've gone the ports route: checked out ports from git on the quarterly branch and installed all PHP packages I have installed on that server from ports. It should be OK since I'm using both the quarterly branch from the ports repo and the quarterly package repo for binary packages, so as soon as the packages are available in the pkg repository I'll just reinstall the lot from there.

drhowarddrfine · 2026-10-23T14:06:48+0100

Koen Martens said:
FreeBSD was always lagging behind with security patches compared to most Linux distributions

Linux doesn't take care of their distributions as a whole like FreeBSD does. Linux only takes care of their kernel. FreeBSD is a cohesive, complete system that all works together. When someone else screws things up, they don't rely on some outsiders to guarantee their work.

SirDice · 2026-10-23T16:28:57+0100

It seems we're not out of the woods yet. Even if you updated PHP one way or another.

We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector. This setting was already listed as a mitigation in the GHSA-6wmf-4rv5-p3rp advisory for CVE-2026-109619 published on Oct 21st, 2026.

PHP: News Archive - 2026

PHP is a popular general-purpose scripting language that powers everything from your blog to the most popular websites in the world.

www.php.net

mer · 2026-10-23T17:14:33+0100

jmos said:
And as it works for me as written in the docs: No, you don't have to run a pkg update prior to a pkg upgrade.

I would imagine that to be correct if one is staying on the same base (quarterly vs latest). If you have been pulling quarterly and switch to latest I think the pkg update -f is almost mandatory.

angelvg · 2026-10-23T17:20:35+0100

mer said:
I would imagine that to be correct if one is staying on the same base (quarterly vs latest). If you have been pulling quarterly and switch to latest I think the pkg update -f is almost mandatory.

Of the three servers I manage, on one that is for testing, I made the change from quarterly to latest like this:

 

# mkdir -p /usr/local/etc/pkg/repos



# cat << 'EOF' > /usr/local/etc/pkg/repos/FreeBSD.conf

FreeBSD-ports: {

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

}

EOF



# pkg upgrade

 

# pkg info | grep 'php8[2-5]-[0-9].*'

Code:

mod_php85-8.5.12               PHP Scripting Language (8.5.X branch)
php85-8.5.12                   PHP Scripting Language (8.5.X branch)

After running the 'pkg upgrade' command, the new packages were immediately displayed; the 'pkg update' command was not required.

mer · 2026-10-23T17:47:53+0100

angelvg said:
Of the three servers I manage, on one that is for testing, I made the change from quarterly to latest like this:

# mkdir -p /usr/local/etc/pkg/repos # cat << 'EOF' > /usr/local/etc/pkg/repos/FreeBSD.conf FreeBSD-ports: { url: "pkg+https://pkg.freebsd.org/${ABI}/latest" } EOF # pkg upgrade

# pkg info | grep 'php8[2-5]-[0-9].*'

Code:

mod_php85-8.5.12 PHP Scripting Language (8.5.X branch) php85-8.5.12 PHP Scripting Language (8.5.X branch)

After running the 'pkg upgrade' command, the new packages were immediately displayed; the 'pkg update' command was not required.

Cool. I wonder if pkg upgrade pulls in the "latest" catalogs based on the current config. As in when configured for quarterly, pkg upgrade pulls in that catalog, then if user switches to latest, the next pkg upgrade pulls in the "latest catalog for latest" before running upgrade.

angelvg · 2026-10-23T20:54:59+0100

Good news

 

# date

Code:

Fri Oct 23 14:50:36 -05 2026

 

# freebsd-version

Code:

15.1-RELEASE-p5

 

# pkg upgrade

Code:

Updating FreeBSD-ports repository catalogue...
Fetching data: 100%  9296 KiB   3.2 MB/s    00:03    
Processing entries: 100%
FreeBSD-ports repository update completed. 38288 packages processed.
Updating FreeBSD-ports-kmods repository catalogue...
Fetching data: 100%    46 KiB  46.9 kB/s    00:01    
Processing entries: 100%
FreeBSD-ports-kmods repository update completed. 295 packages processed.
All repositories are up to date.
Checking for upgrades (30 candidates): 100%
Processing candidates (30 candidates): 100%
The following 30 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
    acme-dns: 1.0_42,1 -> 1.0_43,1 [FreeBSD-ports]
    ca_root_nss: 3.131 -> 3.131.1 [FreeBSD-ports]
    curl: 8.22.0 -> 8.23.0 [FreeBSD-ports]
    mod_php85: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    nss: 3.131 -> 3.131.1 [FreeBSD-ports]
    php85: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-calendar: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-ctype: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-curl: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-dom: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-fileinfo: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-filter: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-gd: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-iconv: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-intl: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-ldap: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-mbstring: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-pdo: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-pdo_dblib: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-pdo_pgsql: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-pgsql: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-phar: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-session: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-simplexml: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-tokenizer: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-xml: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-xmlreader: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-xmlwriter: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-zip: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]
    php85-zlib: 8.5.11 -> 8.5.12_1 [FreeBSD-ports]

Number of packages to be upgraded: 30

26 MiB to be downloaded.

Proceed with this action? [y/N]: y

 

# pkg info | grep php

Code:

mod_php85-8.5.12_1             PHP Scripting Language (8.5.X branch)
php85-8.5.12_1                 PHP Scripting Language (8.5.X branch)
php85-calendar-8.5.12_1        The calendar shared extension for php
php85-composer-2.10.3          Dependency Manager for PHP
php85-ctype-8.5.12_1           The ctype shared extension for php
php85-curl-8.5.12_1            The curl shared extension for php
php85-dom-8.5.12_1             The dom shared extension for php
php85-fileinfo-8.5.12_1        The fileinfo shared extension for php
php85-filter-8.5.12_1          The filter shared extension for php
php85-gd-8.5.12_1              The gd shared extension for php
php85-iconv-8.5.12_1           The iconv shared extension for php
php85-intl-8.5.12_1            The intl shared extension for php
php85-ldap-8.5.12_1            The ldap shared extension for php
php85-mbstring-8.5.12_1        The mbstring shared extension for php
php85-pdo-8.5.12_1             The pdo shared extension for php
php85-pdo_dblib-8.5.12_1       The pdo_dblib shared extension for php
php85-pdo_pgsql-8.5.12_1       The pdo_pgsql shared extension for php
php85-pecl-imagick-3.8.1       PHP wrapper to the ImageMagick/GraphicsMagick library
php85-pgsql-8.5.12_1           The pgsql shared extension for php
php85-phar-8.5.12_1            The phar shared extension for php
php85-session-8.5.12_1         The session shared extension for php
php85-simplexml-8.5.12_1       The simplexml shared extension for php
php85-tokenizer-8.5.12_1       The tokenizer shared extension for php
php85-xml-8.5.12_1             The xml shared extension for php
php85-xmlreader-8.5.12_1       The xmlreader shared extension for php
php85-xmlwriter-8.5.12_1       The xmlwriter shared extension for php
php85-zip-8.5.12_1             The zip shared extension for php
php85-zlib-8.5.12_1            The zlib shared extension for php

Great!

richardtoohey2 · 2026-10-23T23:23:22+0100

angelvg said:
Good news

Thanks, I bumped a few production servers to latest to get the newer PHP on latest. Now I've changed those servers back to quarterly so I keep production on quarterly (meant I had to accept going down an expat level, but on the plus side I went up a curl level. And mainly on the plus side, all production servers now back to quarterly packages).

cracauer@ · 2026-10-24T07:47:29+0100

Explanation of the bug, with pictures:

php2shell by Calif Research

A tale of two PHP remote vulnerabilities

calif.io

mtu · 2026-10-24T10:59:31+0100

Well, this has been a terrible experience. Three days waiting for the new pkgs to land in 14.5-RELEASE, for a vulnerability so severe it was covered in global media on day 1.

And for whatever reason, the vulnerable packages were never even flagged in periodic/VuXML mail notifications. I was informed by the BBC before I was informed by my own server.

I spent years compiling my own packages in the ports collection with make, and then even more years constantly wrestling with ports-mgmt/poudriere/. Only for all of it to become unpractical on home servers, thanks to a new version of lang/rust taking 10 goddamned hours to compile every week. The FreeBSD vibe has always been: build your own packages or gtfo, loser. This has come back to bite us all in the ass this week, big time.

I've been running and loving FreeBSD for all my home server needs for over ten years now. This is the first time I'm having serious doubts, thinking I might be better off back on Linux.

Thank you for ignoring my screaming into the void

siladi · 2026-10-24T11:22:45+0100

mtu said:
Well, this has been a terrible experience. Three days waiting for the new pkgs to land in 14.5-RELEASE, for a vulnerability so severe it was covered in global media on day 1.

And for whatever reason, the vulnerable packages were never even flagged in periodic/VuXML mail notifications. I was informed by the BBC before I was informed by my own server.

I spent years compiling my own packages in the ports collection with make, and then even more years constantly wrestling with ports-mgmt/poudriere/. Only for all of it to become unpractical on home servers, thanks to a new version of lang/rust taking 10 goddamned hours to compile every week. The FreeBSD vibe has always been: build your own packages or gtfo, loser. This has come back to bite us all in the ass this week, big time.

I've been running and loving FreeBSD for all my home server needs for over ten years now. This is the first time I'm having serious doubts, thinking I might be better off back on Linux.

Thank you for ignoring my screaming into the void

As pointed out multiple times in this thead , you can remove anything rust (or any other delay fish pkgs for that matter...) from your poudrier config. And then compile your php packages very very fast.

Competence yes? We all strive for more of that.

mtu · 2026-10-24T11:42:03+0100

siladi said:
As pointed out multiple times in this thead , you can remove anything rust (or any other delay fish pkgs for that matter...) from your poudrier config. And then compile your php packages very fast.

Only if you have a working poudriere pipeline already in place, with an an up-to-date ports tree as a working basis and local machines hooked into the built package repositories.

I had all of that for years, but was forced to give up on it. Because in the long run, you either resign to rebuilding rust every few days or weeks, or you resign to waiting for days and weeks for patches to land.

And no, it's not generally workable to just skip rust for urgent builds, or just let poudriere fetch a rust pkg and use that for building. rust introduces "breaking changes" ridiculously often, and the ports tree and the pkg collection are out of sync most of the time. In practice, the dependency hell that arises from this situation will almost never allow you to take poudriere shortcuts around building rust.

You can get lucky sometimes, yes, and this time it worked for PHP rebuilds for many people. Good for them.

But the overall picture just goes to prove my point: If you're relying on the official pkg repos, you're shafted waiting for updates. If you don't, you can turn off the central heating for your house, because your living space is heated by building rust. Even in summer.

cracauer@ · 2026-10-24T12:55:20+0100

It was possible to just take a new ports tree after the commit and compile php there (not in poudriere). That's how I got the updated package. Not guaranteed to work in every situation, but it did in this one.

Doesn't mean I disagree with the point.,

drhowarddrfine · 2026-10-24T14:05:04+0100

Some of the comments in this thread just make me go **sigh**

mer · 2026-10-24T16:05:00+0100

drhowarddrfine said:
Some of the comments in this thread just make me go **sigh**

That and make the dent on my desk from my forehead deeper.
I think it's often a problem with expectations against resources.
Heck even MS winds up hearing about problems and then taking a finite amount of time to fix them.
Toss in the nature of Open Source, the limited committers and yeah, it may take some finite time to fix something in all supported branches.

That why I've always looked at any security thing to see if there are mitigations. Some you can simply disable a piece. Others you need to decide "do I need this feature".

Things like PHP and the intertwining with "the web" may be harder.

cracauer@ · 2026-10-24T17:26:02+0100

mer said:
That and make the dent on my desk from my forehead deeper.
I think it's often a problem with expectations against resources.
.

Well, FreeBSD has the hardware to build packages for everything. And the software to do it efficiently - when building all paclages. There is just a big, big pile of issues getting in the way of quickly building individual packages and inserting them into the pkg mirrors. By-hand intervention worked for some targets but not for others in this case. The expectations are not unrealistic, they are just not currently realized.

mtu · 2026-10-24T17:41:23+0100

cracauer@ said:
Well, FreeBSD has the hardware to build packages for everything. And the software to do it efficiently - when building all paclages. There is just a big, big pile of issues getting in the way of quickly building individual packages and inserting them into the pkg mirrors. By-hand intervention worked for some targets but not for others in this case. The expectations are not unrealistic, they are just not currently realized.

Indeed. The challenge wasn't fundamentally different for Debian, and they had packages in the repos within 1 hour.

Security - PHP RCEs reported

msplsh

rotor

Franconian_Witchcraft

TS

angelvg

SirDice

Administrator

covacat

SirDice

Administrator

Node.js — Wednesday, October 21, 2026 Security Releases

Koen Martens

drhowarddrfine

SirDice

Administrator

PHP: News Archive - 2026

mer

angelvg

mer

angelvg

richardtoohey2

cracauer@

php2shell by Calif Research

mtu

siladi

mtu

cracauer@

drhowarddrfine

mer

cracauer@

mtu