For anyone temporarily shutting off an Apache httpd, there's one step that's sometimes missed: a cron job or systemd timer for certbot. This can restart httpd and leave it running. In other words, in some common uses of Let's Encrypt, standard instructions such as "systemctl disable --now apache2" aren't sufficient to keep httpd off.
When using systemd, "systemctl mask apache2" can make sure that it's impossible for the unit to be started again (remove the mask with systemctl unmask once you've applied the patch).
I have a lot of Linux sysadmin experience but haven't touched Apache in more than a decade. I thought it's mostly nginx or other solutions at this point.
> I thought it's mostly nginx or other solutions at this point.
What advantage(s) does nginx have over Apache?
Back in the day (Apache 2.0) there was certainly a performance with nginx being event-driver, but with Apache 2.4 and mpm_event, does that still apply?
Apache has a feature that no other http server has replicated: .htaccess files.
They provide limited configurability of server functionality within a webroot. That's extremely convenient for PHP webapps. For many PHP apps, deploying them on anything that is not apache means touching the server config itself.
Apache has plenty of life left, it just worksā¢, supports almost everything, and currently is about as efficient as nginx WRT connection handling. Sometimes you want what .htacces gives you. (No built-in Lua though.)
At least 21% of web sites use Apache httpd, and of course many sites donāt report the software used at all. Nginx is also frequently used as a reverse proxy, with Apache used behind it.
Apache has mod_md -- an acme client, which lets you obtain https certificates as easily as on caddy, without integrating with awkward separate programs.
> in Apache HTTP Serverās HTTP/2 module (mod_http2)
I feel like in hindsight, HTTP/2 was a mistake. The theoretical benefits just don't justify the added complexity. It definitely shouldn't have been fasttracked like it was.
Where do you live? I'm hundreds of milliseconds away from all major datacenters, http2 adoption has been incredible at reducing web latency to tolerable levels. Much less staring at empty or half loaded pages.
I don't understand what they mean by "51% of cloud environments" have a publicly exposed instance. What is a "cloud environment"? Do they mean a cloud hosting provider like AWS or Google? Are they saying that between those two only one of them has an instance of a vulnerable Apache server running?
My guess is that they are collecting stats on running HTTP daemon software and thus they estimate that 64% of "cloud accounts" have Apache somewhere, and 51% of the total are publicly exposed instances (not on VPCs and such).
As they make a note that this does not account for configuration, so if you've got the http2 module disabled, it sounds like you are protected ā though they only recommend hard-coding the protocol version to 1.1 instead of disabling the module (I've got the module disabled as that was the default when I set up my homelab server, for instance).
Nobody ever was. The big argument against needing safer languages was basically "but if you're an expert at C/C++/whatever, your code is pretty much safe". And these are usually the people who don't run extensive fuzzing and test suites.
We knew we weren't, deep down. Some people did better than others at writing more secure of course. It was just about good enough in a world where ā compared to today ā it took much more time, skill and effort to find bad bugs.
The mistake is to think that the 'magical' LLMs don't write buggy code and that there isn't some tradeoff in using them. There are always tradeoffs in engineering.
later
And, security is always relative to the adversary and landscape, which has massively changed recently.
Depends on use-case. As a reverse proxy I might use Caddy, for no fuss https. I prefer Apache over nginx for modules that are not available in the later, or they are not for free.
This took 7 minutes and $0.02 in deepseek spend through a subscription to reproduce. The prompt was simply directed at a vulnerable version and told to find a h2 race, which is generically the most common culprit these days. Once it found one, I had it attempt the same against a patched version (which failed).
Disabling h2 is the mitigation and is effective. The patch itself seems a little odd as a fix to me personally, but eh.
>Due to improper synchronization when executing concurrent threads sharing resources, an attacker can trigger heap corruption.
>As of the time of this blogās publication, no exploit is available and there are no reports of exploitation in the wild.
Since when does "memory corruption" = "RCE"? Last week I found and reproduced a memory corruption (a use-after-free) in PHP's runtime after running an on-premise agent for just 30 minutes. There's nothing about it on the internet. Should I write a blog post about a scary new vulnerability? :)
I was prepared to disagree with you, but I agree: I'd say there's a strong norm of not calling things RCE unless you can actually demonstrate RCE, or at least have a clean pathway to demonstrating it (e.g. a full write-what-where).
It's perfectly sufficient to have a CVE for just memory corruption, so the "RCE" framing here feels overstated. Particularly when an LLM should easily prove RCE out if it is in fact present.
I don't know the backstory here, but there's a long and colorful history of vendors and other parties guessing that some contrived memory corruption bug isn't exploitable and then being proven wrong, so the industry now more or less defaults to the assumption that it's exploitable.
Let me remind you that in response to the PHP bug, one of the front-page HN posts was a guy saying it's probably not exploitable and another offering Bitcoin to anyone who pops their server... with predictable results.
People can be pretty creative with exploitation primitives, and LLMs now replicate that at a scale. And yep, if you found a use-after-free that can be triggered remotely in PHP under some reasonable assumptions, you should probably treat it as a security bug.
If you can corrupt memory in a controllable way, you can get a computer to do just about anything that process has rights to. Possibly even the kernel, if you can get at some shared memory.
> (...) public research has demonstrated a reliable exploit against a default-configured server with the mod_http2 module enabled. Successful exploitation allows an attacker to execute arbitrary commands, gain full control of the server process, and access or modify sensitive information.
Well I know someone who will get bitten - a couple of years I did some work (because security said so) to make sure we always pulled latest Apache when building our Docker container. Someone ripped that change out not long ago because it was too hard to maintain the Debian repo config changes needed to pull it in, and as a result they'll probably get stung by having a version right in the meaty part of that range.
all my handwritten sockets servers are fine because I use HTTP/1.1
I have 1 apache acting as a proxy for vhosts and
> a2dismod http2
gives me
> Module http2 already disabled
I donāt want to tempt fate (and hackers ) but I have dodged lots of major vulns this year with my strategy of writing code by hand instead of pip installing everything
only vuln I was exposed to was copy.fail, but that was a defense in depth weakness, and I was vulnerable to the kvm weakness if there was a malicious tenant in my hostās hypervisor, but thatās not fair Iām poor so I donāt have a dedi.
maybe the tcp vuln was the most exposed Iāve been but that was a very short window that got auto upgraded by apt with a high attack complexity
maybe I can write about how I survived 2026 without getting a supply chain vuln and get some work or students on new years? I feel thatāll be a pretty big accolade.
Not everything benefits from pipelineling and multiplexing. I wish there existed a protocol that's even simpler than HTTP 1.1, which would be good for exposing APIs. Something like Thrift, but maybe even simpler and more bulletproof.
Depending on the context and content, I tend to be against AI pull requests that havenāt been edited by a human.
AI finding vulns? I donāt see how itās different from valgrind, static analysis, afl, or other fuzzer. I donāt think getting fresh, high-signal analysis is what AI-hating projects are concerned with.
Patch looks like https://github.com/apache/httpd/commit/5ed39287660daacd1233c...
For anyone temporarily shutting off an Apache httpd, there's one step that's sometimes missed: a cron job or systemd timer for certbot. This can restart httpd and leave it running. In other words, in some common uses of Let's Encrypt, standard instructions such as "systemctl disable --now apache2" aren't sufficient to keep httpd off.
Shutting down Apache is perhaps overcautious? Simply doing `sudo a2dismod http2` and then restarting Apache should be enough as far as I can tell
When using systemd, "systemctl mask apache2" can make sure that it's impossible for the unit to be started again (remove the mask with systemctl unmask once you've applied the patch).
I would suggest instead blocking 80 and 443 on UDP and TCP, via your firewall.
If I need to make sure apache doesn't restart I often type "syntax error" on the first line of httpd.conf
I have a lot of Linux sysadmin experience but haven't touched Apache in more than a decade. I thought it's mostly nginx or other solutions at this point.
> I thought it's mostly nginx or other solutions at this point.
What advantage(s) does nginx have over Apache?
Back in the day (Apache 2.0) there was certainly a performance with nginx being event-driver, but with Apache 2.4 and mpm_event, does that still apply?
* https://httpd.apache.org/docs/2.4/mod/event.html
Apache has a feature that no other http server has replicated: .htaccess files.
They provide limited configurability of server functionality within a webroot. That's extremely convenient for PHP webapps. For many PHP apps, deploying them on anything that is not apache means touching the server config itself.
Apache has plenty of life left, it just worksā¢, supports almost everything, and currently is about as efficient as nginx WRT connection handling. Sometimes you want what .htacces gives you. (No built-in Lua though.)
At least 21% of web sites use Apache httpd, and of course many sites donāt report the software used at all. Nginx is also frequently used as a reverse proxy, with Apache used behind it.
My whole selfhosted mess is built around Apache. It was what I started with and I haven't run into any edge cases that it can't cover.
Why would I not use apache if everything already works with it for me?
Apache has mod_md -- an acme client, which lets you obtain https certificates as easily as on caddy, without integrating with awkward separate programs.
https://httpd.apache.org/docs/trunk/mod/mod_md.html
At work we use Apache because of mod_shib. We have yet to try nginx-http-shibboleth.
Default Wordpress docker image uses it.
I am the same way. I use Caddy if I can. But I have a lot of docker containers running apache and nginx. You probably might too.
Appears to be the first issue ranked 'critical' since 2021. https://httpd.apache.org/security/vulnerabilities_24.html
> in Apache HTTP Serverās HTTP/2 module (mod_http2)
I feel like in hindsight, HTTP/2 was a mistake. The theoretical benefits just don't justify the added complexity. It definitely shouldn't have been fasttracked like it was.
But if you have more then one httpd server - eg. some fcgi - then HTTP/1.1 is almost architectural backdor: HTTP Request Smuggling, at minimum.
Apache even don't have it's own HTTP/2: mod_http2 use external library nghttp2[.org] so Apache is dead shell at this point.
Where do you live? I'm hundreds of milliseconds away from all major datacenters, http2 adoption has been incredible at reducing web latency to tolerable levels. Much less staring at empty or half loaded pages.
I don't think it was fast tracked. Was it? I heard the rational to do HTTP 2 and soon later HTTP 3 was to split improvements and ease transition.
Agreed. Too much complexity for too little gain for too narrow use cases. HTTP/1.1 will outlive HTTP/2.
> What is CVE-2026-111497?
> CVE-2026-119618 is a critical, high-severity vulnerability involving....
two CVEs? (111497 != 11968)
I saw that too. CVE-2026-111497 is the Brotli CVE, so my guess is they reused that prior page as a base to start with and missed changing that.
Chances are most Apache/PHP installations run mpm_prefork and arenāt affected by this.
why? mod_mpm_event is what can be assumed to be the default since apache 2.4 (Ā± 2012):
https://httpd.apache.org/docs/current/mpm.html#defaults
I don't understand what they mean by "51% of cloud environments" have a publicly exposed instance. What is a "cloud environment"? Do they mean a cloud hosting provider like AWS or Google? Are they saying that between those two only one of them has an instance of a vulnerable Apache server running?
My guess is that they are collecting stats on running HTTP daemon software and thus they estimate that 64% of "cloud accounts" have Apache somewhere, and 51% of the total are publicly exposed instances (not on VPCs and such).
As they make a note that this does not account for configuration, so if you've got the http2 module disabled, it sounds like you are protected ā though they only recommend hard-coding the protocol version to 1.1 instead of disabling the module (I've got the module disabled as that was the default when I set up my homelab server, for instance).
I think theyāre likely referring to either a Cloud Org (AWS Organisation, Google Cloud Org, Azure Tenant).
Wiz works by plugging their tool into your Cloud Org, so presumably theyāre saying 51% of their enterprise-y customers have an exposed instance.
duplicate of https://news.ycombinator.com/item?id=50453368
what is amazing, there are no apache updated containers / packages available yet.
Debian has been patched just now and updates available : apache2 2.4.71-1~deb13u1
Why are these things being disclosed before fixes have been rolled out? Is no-one following disclosure protocols any more?
Debian tracker: https://security-tracker.debian.org/tracker/CVE-2026-119618 - hopefully the fix lands soon
At least disabling http2 is an easy countermeasure that will probably in most setups not have any real downsides.
If it was even enabled that is.
everybody new Vulnerability makes me think how we are not so good a writing secure code?.
Nobody ever was. The big argument against needing safer languages was basically "but if you're an expert at C/C++/whatever, your code is pretty much safe". And these are usually the people who don't run extensive fuzzing and test suites.
We knew we weren't, deep down. Some people did better than others at writing more secure of course. It was just about good enough in a world where ā compared to today ā it took much more time, skill and effort to find bad bugs.
The mistake is to think that the 'magical' LLMs don't write buggy code and that there isn't some tradeoff in using them. There are always tradeoffs in engineering.
later
And, security is always relative to the adversary and landscape, which has massively changed recently.
it is also quite difficult to make a house safe if there are millions of people willing to breach it.
The offender side evolved, the defender needs to evolve too and that will be very, very expensive but much cheaper than not fixing the problems.
What is the benefit of using Apache over enjinx?
Depends on use-case. As a reverse proxy I might use Caddy, for no fuss https. I prefer Apache over nginx for modules that are not available in the later, or they are not for free.
This took 7 minutes and $0.02 in deepseek spend through a subscription to reproduce. The prompt was simply directed at a vulnerable version and told to find a h2 race, which is generically the most common culprit these days. Once it found one, I had it attempt the same against a patched version (which failed).
Disabling h2 is the mitigation and is effective. The patch itself seems a little odd as a fix to me personally, but eh.
Did it manage to produce a PoC for RCE? Apparently Redhat claimed there's a RCE, while Wiz said they don't have one.
http2 race??
What exactly is the issue and does nginx have it
LiteSpeed and OpenLiteSpeed affected by this?
gno.security/repairer
No CVSS severity level?
NIST doens't show one (yet?). I checked on RedHat and they list it at a 9.8
>Due to improper synchronization when executing concurrent threads sharing resources, an attacker can trigger heap corruption.
>As of the time of this blogās publication, no exploit is available and there are no reports of exploitation in the wild.
Since when does "memory corruption" = "RCE"? Last week I found and reproduced a memory corruption (a use-after-free) in PHP's runtime after running an on-premise agent for just 30 minutes. There's nothing about it on the internet. Should I write a blog post about a scary new vulnerability? :)
I was prepared to disagree with you, but I agree: I'd say there's a strong norm of not calling things RCE unless you can actually demonstrate RCE, or at least have a clean pathway to demonstrating it (e.g. a full write-what-where).
It's perfectly sufficient to have a CVE for just memory corruption, so the "RCE" framing here feels overstated. Particularly when an LLM should easily prove RCE out if it is in fact present.
I don't know the backstory here, but there's a long and colorful history of vendors and other parties guessing that some contrived memory corruption bug isn't exploitable and then being proven wrong, so the industry now more or less defaults to the assumption that it's exploitable.
Let me remind you that in response to the PHP bug, one of the front-page HN posts was a guy saying it's probably not exploitable and another offering Bitcoin to anyone who pops their server... with predictable results.
People can be pretty creative with exploitation primitives, and LLMs now replicate that at a scale. And yep, if you found a use-after-free that can be triggered remotely in PHP under some reasonable assumptions, you should probably treat it as a security bug.
If you can corrupt memory in a controllable way, you can get a computer to do just about anything that process has rights to. Possibly even the kernel, if you can get at some shared memory.
RedHat claims there's a working RCE:
> (...) public research has demonstrated a reliable exploit against a default-configured server with the mod_http2 module enabled. Successful exploitation allows an attacker to execute arbitrary commands, gain full control of the server process, and access or modify sensitive information.
https://access.redhat.com/security/cve/cve-2026-119618
Discovered independently by Anthropic (Oct 26) and Google (Nov 3), so I'm compelled to believe it: https://httpd.apache.org/security/vulnerabilities_24
But maybe someone will post another HN challenge like with the PHP thing?
Why does it say the āvendorā for this is GitHub (for mod_h2)?
Is that just crappy LLM generated copy that is assuming that GitHub the company is responsible for that module because itās hosted there?
Yes, this is slop, extruded from reading the patch and the official announcement, which is at https://httpd.apache.org/security/vulnerabilities_24.html#CV...
From 2.4.55 through 2.4.70? Jokes on you, my version is not that new!
Well I know someone who will get bitten - a couple of years I did some work (because security said so) to make sure we always pulled latest Apache when building our Docker container. Someone ripped that change out not long ago because it was too hard to maintain the Debian repo config changes needed to pull it in, and as a result they'll probably get stung by having a version right in the meaty part of that range.
I'm guessing you missed out on Heartbleed too :P At work we managed to upgrade to a vulnerable version 1 month before that came out .... ugh
The C chansaw juggling doesn't get any safer from adding threads. Is the robust original (pre)fork configuration still supported?
I run apache with prefork on my personal sites. Still works. No idea if it supports http/2.
I don't know, but Claude is fixing that too! (doubt that makes it safer either...)
This has not been a good month for the LAMP stackā¦
It's not always HTTP/2. But it's a pretty safe bet.
The vulnerability affects deployments utilizing HTTP/2 capabilities
Even Apache is being filled with Claude commits, so great.....
I don't know why your comment is dead, but I meant in general perching_aix , it's just what I noticed looking up this
You prefer to leave it insecure?
all my handwritten sockets servers are fine because I use HTTP/1.1
I have 1 apache acting as a proxy for vhosts and
> a2dismod http2
gives me
> Module http2 already disabled
I donāt want to tempt fate (and hackers ) but I have dodged lots of major vulns this year with my strategy of writing code by hand instead of pip installing everything
only vuln I was exposed to was copy.fail, but that was a defense in depth weakness, and I was vulnerable to the kvm weakness if there was a malicious tenant in my hostās hypervisor, but thatās not fair Iām poor so I donāt have a dedi.
maybe the tcp vuln was the most exposed Iāve been but that was a very short window that got auto upgraded by apt with a high attack complexity
maybe I can write about how I survived 2026 without getting a supply chain vuln and get some work or students on new years? I feel thatāll be a pretty big accolade.
isn't http/1.1 request smuggling a known risk in exactly the scenario you're using it in?
Time for a Rust based httpd replacement like https://xin.dev
How would Rust have fixed this security issue?
Cannot find the source... (Wanted to see if they use the RusTLS)
this looks vibecoded which is probably even worse
HTTP2 is insecure and 1.1 is slow. At this point just find a good H3 implementation and drop the old protocols.
Not everything benefits from pipelineling and multiplexing. I wish there existed a protocol that's even simpler than HTTP 1.1, which would be good for exposing APIs. Something like Thrift, but maybe even simpler and more bulletproof.
Wiz is such an amazing company. Israeli-based and recently acquired by Google, the significance of their security contributions cannot be overstated.
Another critical bug discovered by AI.
I want the rabidly AI-hating projects to stand their ground and refuse to fix vulnerabilities discovered with AI assistance.
Depending on the context and content, I tend to be against AI pull requests that havenāt been edited by a human.
AI finding vulns? I donāt see how itās different from valgrind, static analysis, afl, or other fuzzer. I donāt think getting fresh, high-signal analysis is what AI-hating projects are concerned with.
> I want the rabidly AI-hating projects to stand their ground and refuse to fix vulnerabilities discovered with AI assistance.
Why?