Critical Apache HTTP/2 Flaw Could Let Unauthenticated Attackers Execute Code Remotely (thehackernews.com) 14
A critical flaw in Apache HTTP Server's HTTP/2 module could allow unauthenticated attackers to remotely execute code and potentially take control of affected server processes. Tracked as CVE-2026-119618, the vulnerability affects Apache HTTP Server 2.4.55 through 2.4.70 when HTTP/2 is enabled and is fixed in version 2.4.71. The Hacker News reports: The vendor's assessment, published yesterday, also says "public research has demonstrated a reliable exploit" against a server in its default configuration with mod_http2 enabled. It does not name or link that research. Security company Wiz said later that day that no exploit was available and that no exploitation in the wild had been reported.
HTTP/2 runs only where the Protocols directive turns it on, as the module documentation explains. The directive uses h2 for HTTP/2 over TLS and h2c for HTTP/2 over plain TCP. It can be set for the whole server or for a single virtual host, so admins should check the server-wide setting and every virtual host.
Standalone builds of the module, released on GitHub as mod_h2, are affected from version 2.0.8 through 2.0.42. Admins who run the Apache HTTP Server project's own releases should move to version 2.4.71, the fixed release named in its security advisory. That release also fixes a crash in mod_md, rated important, and a one-byte overwrite of stack memory in mod_vhost_alias, rated low.
HTTP/2 runs only where the Protocols directive turns it on, as the module documentation explains. The directive uses h2 for HTTP/2 over TLS and h2c for HTTP/2 over plain TCP. It can be set for the whole server or for a single virtual host, so admins should check the server-wide setting and every virtual host.
Standalone builds of the module, released on GitHub as mod_h2, are affected from version 2.0.8 through 2.0.42. Admins who run the Apache HTTP Server project's own releases should move to version 2.4.71, the fixed release named in its security advisory. That release also fixes a crash in mod_md, rated important, and a one-byte overwrite of stack memory in mod_vhost_alias, rated low.
Today I learned (Score:3)
Re: (Score:2)
Re: (Score:3)
Some of us haven't migrated from gopher yet.
Re: (Score:1)
Re: (Score:3)
Generally, LAMP still makes up a lot of the internet, nginx has taken a subset that is internet facing and needs nothing more than routing to an application of some description. However, Apache and mod_rewrite, mod_php, mod_perl etc is still very much alive and kicking.
I wouldn't say use Apache for everything, unless you need the features you can get from its modules then use something skinny, perhaps removing those modules is all you need, then you'll eventually have something closer to nginx anyhow :)
Re: (Score:2)
That's why this CVE isn't that big a deal in practice... "everything" has a cache in front of the actual server, so the internet can't see what is serving it anyway.
Re: (Score:2)
It's what I learned in the early '00s and that's what I'm sticking with!
Also, I don't load the mod_http2 module because I am an old man who yells at clouds.
now get off my lawn!
Re: (Score:2)
my web server is written in COBOL
Re: (Score:2)
That's mod_cgi not mod_http2
Re: (Score:2)
We use Micro Focus's COBOL web server. I don't know what language the server is written in, but it does such a great job I've never had to hassle with it since we started using it twenty years ago. I even have Puppet scripts to setup new instances that have never been used except to create dev and QA environments. It just works.
Why can't we install and forget anything? (Score:1)
LOL I've had an old Apache running for random reasons and figured it is just static content and not even TLS.
Re: (Score:2)
If you'd forgotten you wouldn't know you have it installed, though.
Not Enough Information (Score:3)
It isn't clear to me that this allows arbitrary remote code execution in otherwise-safe Apache configurations
The bug is
apr_table_setn(req->headers, "Content-Length", "0");
And the fix is
apr_table_setn(r->headers_in, "Content-Length", "0");
so it is clearly a bug.
But the context is: /* If we have a content-type, but already seen eos, no more
* data will come. Signal a zero content length explicitly.
*/
So, until later when we see an actual description of the problem, it doesn't look to me like it would allow arbitrary execution unless you're already allowing arbitrary execution and protecting it with some sort of access control. It seems more likely that it could allow execution of protected APIs in situations where they're running on the same server that also allows direct public connections. That's a pretty dubious setup to start with.
These days you should always have a thin caching layer in the front anyways, the public internet shouldn't actually be able to talk to the web server that's generating the content. So if this bug affects you... Bad sysadmin! No Biscuit!
Also, r is the sanitized/massaged request that's being built, req is the original request that was passed in. This is an example of something I'd hope to test for: is the data we're not supposed to change being changed? I guess the, "Change languages every 5 years... for security!" people will snear," That could have been prevented with a better type system." Which is true, but here I'd rather have lower overhead and more stable code. This particular function may not need to be changed again in the next 30 years. I'd rather that than have new bugs all the time because things are being rewritten to be "safer." Better is as here, to rake it over the coals until it's perfected.
The really good news is that the bug is in http2, not apr.