Re: Apache24 and CVE-2026-23918

If someone is updating Apache, could they please also take a look at 
this unhandled months-old bug report 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291447>? It is 
categorized as being in ports-mgmt/synth, but a little backstory is 
probably relevant:

(1) About half a year ago, as usual Synth would build Apache, but 
suddenly upon inspecting the built package at the end of the build 
process, it would complain that it "has more dependencies than the port 
requires", and remove the package from the repository because of that.

(2) After having it fail like this for a few days in a row, I opened the 
linked bug about the problem. I categorized it as being in www/apache24, 
not as being in ports-mgmt/synth. I didn't (and don't) know much about 
the low-level details of the package or of building packages in general, 
so (while admitting that up front) I put forth a couple more-or-less 
ignorant guesses in the initial report:

(A) One of the things it was depending on was Perl, which seemed weird 
to me (this guess was incorrect).

(B) Another of those things was databases/gdbm, and I noticed that the 
www/apache24 makefile had been changed to add this -- in some but not 
all situations -- right around the time that the problem started 
occurring (this guess was correct).

(3) The person who had made that change to Apache's makefile replied, 
essentially saying that he put it in as a workaround to another issue 
which was (I think) upstream, and that since it works fine in Poudriere, 
it must be a Synth problem. He then changed the bug report to be 
categorized in ports-mgmt/synth instead of in www/apache24.

(4) His explanation of his change frankly seemed pretty kludgy to me, 
but again, I don't know much about all this. So, I took to the Synth 
forums to report the issue there.

(5) The Synth maintainer agreed with my feeling that it was an Apache 
issue, not a Synth issue, and posted a comment in the Bugzilla thread 
explaining his thoughts on the matter. Again the details are beyond me, 
but the gist is that the Apache makefile change would be problematic for 
clean-environment builds in general on machines that don't actually use 
gdbm, not just problematic for Synth (which always does 
clean-environment builds).

The Synth maintainer also gave me a kludgy workaround in Synth for the 
seemingly-kludgy workaround in Apache just to get things working for me, 
which helped.

(6) Based on that, I changed the category back to www/apache24.

(7) The guy who had changed the Apache makefile replied again, more or 
less reiterating that it's not an Apache problem. He once again changed 
the category back to ports-mgmt/synth.

(8) Various back-and-forth, including with some other people (at least 
some of whom, if I remember correctly, were having the same problem).

(9) Somebody then noticed that the FreeBSD Porters' Handbook 
specifically describes the sort of change that was made to the Apache 
makefile as "wrong", and (if made) will cause problems exactly like were 
happening here. But...

(10) ... by that time the guy who changed the Apache makefile had 
removed himself from the thread.

(11) It was then suggested that someone get in touch with "the Apache 
group" about it. Time passed apparently without anyone having done so. 
In particular, I didn't, at first because I didn't know who "the Apache 
group" was referring to, and later because I was feeling kind of 
uncomfortable with all the DRAMA that had transpired. Especially given 
that of all the people involved in the situation, I'm clearly the most 
ignorant with respect to it.

I still don't feel entirely comfortable asking about this again, but 
here I am. Anyway, if someone could please take a look, I'd appreciate 
it. Thank you.

On 5/5/2026 7:49 PM, Angel Hess wrote:
> Hi can someone update the pkg Apache24 to patch the CVE-2026-23918 
> vulnerability. Apache already offered a patch version apache24-2.4.67. 
> FreeBSD pkg is still version apache24-2.4.66. Info here 
> https://www.cve.org/CVERecord?id=CVE-2026-23918
>
> Thank you.
>
> Gracias,
> Angel Hess
> angelhess.com
>