today at 6:18 AM
Patch looks like https://github.com/apache/httpd/commit/5ed39287660daacd1233c...
today at 11:05 AM
Appears to be the first issue ranked 'critical' since 2021. https://httpd.apache.org/security/vulnerabilities_24.html
today at 10:54 AM
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.
today at 12:19 PM
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).
today at 12:54 PM
I would suggest instead blocking 80 and 443 on UDP and TCP, via your firewall.
today at 11:18 AM
If I need to make sure apache doesn't restart I often type "syntax error" on the first line of httpd.conf
today at 5:04 AM
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.
today at 8:43 AM
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.
today at 10:28 AM
I would say that's actually a misfeature as it requires too many additional filesystem lookups to fulfil requests.
Modifying the web server config is a nonissue outside of shared hosting, which should have died out with the advent of VMs/containers.
today at 11:13 AM
> … too many additional filesystem lookups …
Caching is a thing. Only dump the cache when a changed is noticed.
today at 11:36 AM
And now you have 2 problems..
today at 9:24 AM
Does not Microsoft's IIS also have that with web.config files?
today at 12:08 PM
Yes, but then you're dealing with IIS and why would you want that?
today at 9:17 AM
Eh. You can use .htaccess in nginx too. I use that everyday.
today at 10:53 AM
Ah yes, htaccess. Another lovely source of security bugs for the past 30 years and may it continue to bear skiddie fruit for another 300.
Its model is fundamentally flawed precisely because it was based on the fundamentally flawed PHP model (website assets and code are stored and hosted from the same webroot). This allowed for shared hosting to exist but containers and reverse proxies are a far better way of organising such sites today.
The fact that in other webservers the server's configuration is configured through its configuration file and not the content of its webroot is a feature.
today at 11:53 AM
Yes apache has a config file too amazingly enough, .htaccess is optional
today at 11:57 AM
The point I was making is that having alternative sources of configuration (coming from the contents being served no less) is a misfeature.
Really not sure how one could possibly read my comment as me saying htaccess is the only way of configuring Apache?
today at 8:47 AM
PHP can go to hell. My hair is gray because of it. Nginx is superior, and I can get anything imaginable done with config files. And not to mention, it's much faster.
today at 9:32 AM
The http servers drag race finished 15 years ago on a tie, it's really much a matter of taste and familiarity more than performance at this point.
today at 10:11 AM
The lazy bastard in me prefers Caddy.
today at 11:37 AM
I don't understand this. NGINX can run PHP. PHP is not exclusive to Apache.
today at 11:59 AM
In general, the Apache php mod has had less drama than php-fpm over the years. Also, casting each domain under specific isolated itk server user(s) account(s) adds a layer of containment, where Nginx processes must run under a single user context.
Nginx uses way less memory in most use-cases (1/4 to 1/10), but with dynamic content like php it is only slightly better (maybe 15% if lucky). Also, setting up websocket proxy in Nginx is still a bit of a bodge.
Each server type has its own trade offs, and a list of known mitigations the uninitiated must learn. If you have a single domain high-traffic site with static media files, than Nginx is probably going to matter more. =3
today at 6:41 AM
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.)
today at 7:53 AM
i mostly use nginx lua to patch on some feature i had even on bare Apache, let alone all the core modules.
today at 5:48 AM
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.
today at 8:15 AM
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.
today at 10:46 AM
Exactly the same for me! I could switch to Nginx, it's one prompt away probably, but why?
today at 7:08 AM
Why would I not use apache if everything already works with it for me?
today at 7:26 AM
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
today at 8:43 AM
nginx has that too https://blog.nginx.org/blog/native-support-for-acme-protocol
today at 12:14 PM
There is a 7 year difference between those release announcements. Personally I've never liked nginx because of their attempts at monetising it, a lot of features are behind nginx plus which is really expensive and full of sales staff who try to reach out all the time, and when you start it, it says something along the lines of "Starting a high performance webserver" which always seemed strange
today at 5:50 AM
At work we use Apache because of mod_shib. We have yet to try nginx-http-shibboleth.
today at 12:25 PM
One should stop using SAML anyway as that has its own collection of problems. We learned a lot about problems with cryptographic protocols in the last 30 years that cannot be fixed in SAML.
today at 6:34 AM
Default Wordpress docker image uses it.
today at 8:25 AM
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.
today at 10:25 AM
> 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.
today at 11:12 AM
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.
today at 10:31 AM
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.
today at 10:34 AM
HTTP/3 was the real mistake. It basically reimplements TCP on top of UDP and from my testing (at least the existing implementations) it generally performs worser then HTTP/2. Even when testing on somewhat a bit lossy connection.
today at 3:16 AM
> What is CVE-2026-111497?
> CVE-2026-119618 is a critical, high-severity vulnerability involving....
two CVEs? (111497 != 11968)
today at 4:16 AM
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.
today at 4:27 AM
You'd think they'd have an LLM reviewing this by now. On the up side, it is refreshing to see good ol' human error still around on the surface!
today at 6:01 AM
What makes you think it's not already an LLM error?
today at 6:20 AM
Even a tiny model would pick up an error like this during review.
today at 10:46 AM
Even a tiny model might, if promoted correctly.
Even the latest and greatest big models miss trivial errors when simply asked to review a chunk of text.
today at 7:55 AM
just had claude today spew some basic firewall rules for port 5900 and 5901... it used 5900 and 59001
today at 7:38 AM
If you use modern LLMs a lot you'll know they are much better at catching these kind of copy and paste errors than humans are.
today at 9:06 AM
Chances are most Apache/PHP installations run mpm_prefork and aren’t affected by this.
today at 9:51 AM
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
today at 10:03 AM
IIRC popular apache/php platforms such as cpanel, official wordpress docker container image, etc use mpm_prefork by default.
today at 7:44 AM
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?
today at 10:31 AM
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).
today at 9:55 AM
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.
today at 6:52 AM
what is amazing, there are no apache updated containers / packages available yet.
today at 7:50 AM
Why are these things being disclosed before fixes have been rolled out? Is no-one following disclosure protocols any more?
today at 9:31 AM
Debian tracker: https://security-tracker.debian.org/tracker/CVE-2026-119618 - hopefully the fix lands soon
today at 10:41 AM
Debian has been patched just now and updates available : apache2 2.4.71-1~deb13u1
today at 7:00 AM
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.
today at 11:01 AM
everybody new Vulnerability makes me think how we are not so good a writing secure code?.
today at 12:59 PM
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.
today at 12:55 PM
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.
today at 11:21 AM
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.
today at 9:35 AM
What is the benefit of using Apache over enjinx?
today at 10:38 AM
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.
today at 9:48 AM
today at 5:23 AM
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.
today at 5:39 AM
Did it manage to produce a PoC for RCE? Apparently Redhat claimed there's a RCE, while Wiz said they don't have one.
today at 5:52 AM
[dead]
today at 7:31 AM
http2 race??
What exactly is the issue and does nginx have it
today at 6:51 AM
LiteSpeed and OpenLiteSpeed affected by this?
today at 7:30 AM
gno.security/repairer
today at 3:08 AM
>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? :)
today at 3:24 AM
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.
today at 9:16 AM
Another comment says it has a CVSS score of 9.8 which means CVE, easy to exploit, and an exploit gives LOTS of access.
Before we get too whiny about "it's only memory corruption without any RCE PoC", let's wait until the CVE is unembargoed.
today at 6:57 AM
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.
today at 3:16 AM
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.
today at 3:19 AM
But it's not a given that memory corruption is exploitable as an RCE specifically. I thought to call something an RCE you need a working exploit?
today at 3:44 AM
Presumably one of Anthropic, Google, or Apache possesses a working exploit, because the official Apache Foundation report on this CVE claims RCE is possible.
today at 3:25 AM
Isn't resource consumption a DoS?
today at 3:29 AM
A denial of service is a different class of vulnerability (a minor one, generally).
today at 3:48 AM
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?
today at 3:04 AM
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?
today at 3:43 AM
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...
today at 3:51 AM
today at 3:51 AM
today at 4:05 AM
[dead]
today at 3:36 AM
From 2.4.55 through 2.4.70? Jokes on you, my version is not that new!
today at 6:06 AM
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.
today at 4:20 AM
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
today at 4:57 AM
The C chansaw juggling doesn't get any safer from adding threads. Is the robust original (pre)fork configuration still supported?
today at 6:51 AM
I run apache with prefork on my personal sites. Still works. No idea if it supports http/2.
today at 6:40 AM
I don't know, but Claude is fixing that too! (doubt that makes it safer either...)
today at 7:23 AM
This has not been a good month for the LAMP stack…
today at 2:54 AM
It's not always HTTP/2. But it's a pretty safe bet.
today at 3:27 AM
The vulnerability affects deployments utilizing HTTP/2 capabilities
today at 4:18 AM
Even Apache is being filled with Claude commits, so great.....
today at 4:53 AM
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
today at 4:29 AM
[dead]
today at 5:04 AM
You prefer to leave it insecure?
today at 5:08 AM
It was a comment unrelated to this vulnerability
today at 4:10 AM
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.
today at 4:17 AM
isn't http/1.1 request smuggling a known risk in exactly the scenario you're using it in?
today at 6:51 AM
If I understand correctly that only affects reverse proxy chains, which people might just not have. Or not have in a way that is vulnerable to that?
I guess it makes sense that "the cloud" moves to it, but beyond that, it might be fine?
today at 6:34 AM
No CVSS severity level?
today at 8:17 AM
NIST doens't show one (yet?). I checked on RedHat and they list it at a 9.8
today at 8:56 AM
That's crazy high.
today at 11:59 AM
[flagged]
today at 7:22 AM
Time for a Rust based httpd replacement like https://xin.dev
today at 7:48 AM
How would Rust have fixed this security issue?
today at 10:18 AM
> > a concurrent execution race condition within the assign_headers() function when handling shared resources [...] can corrupt heap memory to achieve arbitrary code execution (RCE)
To my understanding, in safe Rust to share between threads the compiler will require something like Arc<Mutex<...>> - which prevents unsynchronized access or freeing while another thread is still using it.
today at 10:16 AM
One of the core claims of the language is data race safety because in safe rust, no memory location can be written by two or more owners at the same time. (see https://doc.rust-lang.org/nomicon/races.html for a more detailed discussion) Consequently, the kind of memory corruptions that this vulnerability seems to exploit are not possible in safe rust. Now, we don't know if a hypothetical rust-based apache implementation would have reached for unsafe in this context or done any other wild thing, but it's fair to assume that the likelihood of an exploitable RCE through memory corruption trends towards zero in programs written in Rust.
today at 10:27 AM
The details I've seen are too sparse to say with certainty, but it seems like the issue is concurrent access to the same value through a pointer.
In particular it's `req` in the function with this signature:
static void assign_headers(request_rec *r, const h2_request *req,
int no_body, int is_connect)
- apr_table_setn(req->headers, "Content-Length", "0");
+ apr_table_setn(r->headers_in, "Content-Length", "0");
In Rust this would've been `req: &h2_request` and the accidental write wouldn't have been possible (barring interior mutability). Even with interior mutability there is no thread interleaving during the write, which happens through a `&mut h2_request` probably obtained through a lock.
today at 7:57 AM
They've published an article last month on the Nginx vulnerabilities in light of their Rust implementation.
https://xin.dev/blog/multiple-nginx-vulnerabilities/
today at 9:52 AM
If you’re going to respond, at least make an attempt to answer the question.
today at 12:35 PM
It's not for Apache, that may be too recent (no blog post yet. For if you want to see how Rust can prevent vulnrs, the blog post explains it nicely.
Sorry for you I did not meet your standards. Pfff.
today at 7:55 AM
Cannot find the source... (Wanted to see if they use the RusTLS)
today at 10:46 AM
this looks vibecoded which is probably even worse
today at 5:39 AM
HTTP2 is insecure and 1.1 is slow. At this point just find a good H3 implementation and drop the old protocols.
today at 6:50 AM
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.
today at 10:52 AM
Well there's HTTP/0.9. Can't get much simpler than that.
today at 6:55 AM
Wiz is such an amazing company. Israeli-based and recently acquired by Google, the significance of their security contributions cannot be overstated.
today at 3:30 AM
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.
today at 4:37 AM
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.
today at 6:43 AM
Depends on exactly what it is that a project is objecting to. For example, here's Nura:
> AI tools have several ethical issues. They require an unreasonable amount of energy[1] and water[2] to build and operate, their models are built in part with heavily exploited workers in unacceptable working conditions[3], usually without consent from or compensation for creators of the source material[4] and oftentimes causing DDoS attacks against FOSS infrastructure in the process[5] (which in turn force the deployment of challenge-based protections and increase cost and complexity of self-hosting for everybody[6]). Furthermore, they are being used to undermine labor and justify layoffs[7]. These are harms that we do not want to perpetuate, even if only indirectly.
( https://docs.nura.eco/policies-and-processes/development/ai-... )
If you really believe that AI tools are automatically unethical because they destroy the environment, harm workers, and constitute an attack on FOSS infrastructure, then it doesn't really matter how the tool is being used. If you just don't want to see code quality decline, then it's probably not a problem.
today at 6:13 AM
> Depending on the context and content, I tend to be against AI pull requests that haven’t been edited by a human.
I've seen on a few open source projects I follow the 100% AI patch with notes to the effect of "I haven't compiled let alone tested these changes but AI said it's fine and my cursory glance agrees".
Like come on - I'm not going to judge using AI to make a useful change, but at least put in more than zero effort.
today at 5:55 AM
cough Zig... cough
> No LLMs for finding bugs.
today at 3:35 AM
> I want the rabidly AI-hating projects to stand their ground and refuse to fix vulnerabilities discovered with AI assistance.
Why?
today at 4:51 AM
same reason i'd imagine that one might have wanted medical assistance be denied to covid deniers who inevitably did contract covid, and started experiencing the FO part of FAFO: retribution and consistency
today at 7:46 AM
because it's just some slop generated by a bunch of stochastic parrots and can't be taken seriously :-)
today at 4:05 AM
today at 3:56 AM
[dead]