The writing really feels like it was written by a 4GB gemini model running on a phone.
Even having "Which actions should security teams take?" is so incredibly stupid imo. If there is a vulnerability and new version is patched, and I am a security team member reading this, then..
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.
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.
> (...) 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.
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.
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.
> 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.
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.
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.
Just thinking out loud - I wonder what the total energy for an AI contribution is vs. a human. For a given programming task, it looks like a human required 3.5x the energy that AI requires, assuming training costs are amortized (probably a big assumption). That doesn’t seem like a reasonable argument.
I totally buy into the FOSS and DOS arguments, though. I just did a test: “implement `size_t strlcpy(char dst, const char src, size_t size)` in C”. In a one-shot, 3 of the top 5 LLMs will give OpenBSD’s implementation with the license stripped. The other two will do it in some cases where other context exists first (nothing prodding, just asking for other implementations). Similar results with qsort, but they split on two different implementations, change variable names, and fail to emit the original license.
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.
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.
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.
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.
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.)
I thought mod_lua was an official module. I've just checked with Debian stable, and their "apache2-bin" package depends on liblua5.
> Apache has plenty of life left
I would expect a project with "plenty of life left" to support HTTP3. And to use Git (or some modern DVCS) instead of Subversion.
BTW, a co-worker has to maintain an Apache server because its shibboleth mod is mandatory for that project, and he often complains about it, and so do I when they ask for help. Performance is worse than nginx, configuration is awful, documentation is uneven, some features (like .htaccess) are dangerous, etc.
Apache http is the only project that I know that still uses Subversion. They have published a Git clone on Github, but their main source is still svn. It's a bit worrying, because they won't attract new developers with that technical stack. Last I checked, the 2.5 branch looked dead, and the dev-list was barely active.
Apache has mod_md -- an acme client, which lets you obtain https certificates as easily as on caddy, without integrating with awkward separate programs.
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
That's interesting, I use a short bash script that shuts down apache, calls certbot (which starts apache just to get the certificates) then it restarts apache once certbot is done. This way, the certs are in the standard /etc/letsencrypt location in case I ever do switch web servers. I've run Apache since the 1990's so not likely but I like to keep concerns separated. It's still nice that there is an apache mod for it though.
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.
When your Wordpress site gets hacked the hackers are going to assume that you are running apache or nginx and put a .htaccess in the site root that messes the site up. When you are running on IIS the hackers can put in as many .htaccess files they feel like, it will not make any difference.
Network filesystems, consequences of mount shadowing, crazy access control extensions, etc.. Trying to recursively monitor directories with a htaccess file in them to know if a URL requested will reach one.. It is a typical layered system problem.
But then that removes the "feature Apache has that no other webserver does" and brings back GGP's point about "what does Apache offer over other webservers like nginx"
But you can selectively use the option: allowing the feature where it is useful (user web dirs perhaps, or individual dirs even more selectively) and disabling it elsewhere.
But, if we concede that it's a misfeature (and that it's not valid to criticize the project for having it, as it can be disabled), then what advantage is there in having it?
You can't have it both ways. Either it's a misfeature but it 'doesn't matter' because it can be disabled, or its a legitimate feature in which case you must therefore defend the existence and purpose of the feature.
When you need (or want) it, you turn it on and accept a few more filesystem look ups, in exchange for convenience and not having to edit the main config.
When you don't need it, great, you've got slightly better performance.
what about ~/public_html dirs on shared servers? Having the ability to have .htaccess there means users can impose access control without being able to modify the server config (which they shouldn't be able to do!).
> Apache has a feature that no other http server has replicated: .htaccess files.
That can expose your files for such a trivial reason as different end of line sequence that it expects. Instead of shutting down the access, it just happily ignores .htaccess and enables DirectoryIndex.
This is the software that's responsible for majority of data leaks in the world.
Indeed, but it's interesting how web serving in general has shifted away from files. In the original era of web servers, the path component of the URL was the filesystem path on the web server; these days, we expect to match it against a table of routes. Even most PHP apps use routing takes. If you want to bring things back to the filesystem you don't just need to bring back .htaccess - you need a whole new framework.
> 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?
definitely not for me. Think I had a dozen tutorial examples open for simply configuring nginx to server matrix chat to the web, ended up in crazy nginx docs, things not working properly.
Copy and pasting got things to work eventually - but my next matrix install had a similar loop where I learned about some gotchas and 'dont do this thing!' stuff with nginx.
I tried caddy instead at some point which seemed like a nicer / easier to read and do type of thing.. but then compatibility issues with Debian + Matrix + Caddy just became another time sink.
apache things would of been easier for me if the matrix tutorials including it.
then some nginx updates and other things - I would not call it easier to configure.
definitely some nice things in there though - loved seeing the power of how it can work and it makes sense. It may be worth it, but not easier I feel.
I just set up an Apache a couple days ago. I had an old PHP site that used mod_auth_cas, and I needed to migrate to OIDC. The site was running on Nginx, but Nginx's OIDC module only works on Nginx+. There's a free OIDC module for Apache, so I switched. Wasn't hard.
Also, Nginx's maintainers are weird about standards. e.g., last time I checked, tabs in header field line whitespace were rejected by the Nginx parser, even though the RFC says to allow it. The maintainers at the time didn't care and wouldn't fix, reasoning that Nginx had been behaving this way for so long that anything sending tabs in header field lines would have stopped by now. I don't love that attitude.
Apache is way better in this regard. (Though I think Nginx may have cleaned up its act recently?)
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.
I'd argue that HTTP 1.1 is simpler than Thrift (especially if you include the serialization formats), but more underspecified. The underspecified-ness is where the complexity in handling HTTP 1.1 in correct and secure ways comes from.
Variables named "r" and "req" in the same function, both being different representations of the same request, is a bad idea. If they were named sensibly and/or the function was named "assign_headers_on_request_record", this may have been caught in a code review.
Well, very high severity obviously indicates more urgency. For example, a significant number of organizations even shut their websites down while waiting for the PHP2Shell patch. Not many vulnerabilities provoke such drastic measures.
At least wrt the linux kernel, Greg kh explained that there's no point in delayed disclosures anymore, one LLM reporting a bug is often followed by several more reporting the same bug on the same day. So you can assume it's public knowledge by the time it's reported.
1. Don't disclose, ignore vuln.
2. Disclose to highest bidder, even criminals or state agencies.
3. Disclose to vendor, no follow up.
4. Disclose to vendor, release to public after a set delay.
5. Disclose to public.
4 & 5 are "responsible disclosure". 4 is also "coordinated disclosure". The other options ignore the ethical duty engineers have to the public.
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.
> > 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.
My read on this is that `req` is meant to be a readonly value in this function, which is why it's marked `const`. And being readonly, it would be safe to access concurrently. However, someone accidentally wrote through this pointer.
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.
For what it is worth, the code block that precedes this one is an if-condition that has a call to apr_table_setn with as `r` vs. req as the first parameter. This could very well be a case of a developer missing one code block. It could also be that the repo's compiler settings aren't strict enough to flag this as an issue -> writing to a const.
Where this is one such oversight, there are likely others. An LLM isn't needed to find these, likely stricter compiler flags.
I don't believe C's const catches this regardless of compiler settings. What's disallowed by const here is `req->header = x`, but the type of `req->header` is a pointer, which is not const. The constness of pointers is not transitive like that. By contrast, in Rust: `t.u` when `t` is `&T`, is `&U`.
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).
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.
185 comments
[ 0.16 ms ] story [ 42.9 ms ] threadIs that just crappy LLM generated copy that is assuming that GitHub the company is responsible for that module because it’s hosted there?
Even having "Which actions should security teams take?" is so incredibly stupid imo. If there is a vulnerability and new version is patched, and I am a security team member reading this, then..
Of course that is crappy LLM generated copy.
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.
Before we get too whiny about "it's only memory corruption without any RCE PoC", let's wait until the CVE is unembargoed.
> (...) 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 by Anthropic (Oct 26) and Google (Nov 3), so I'm pretty sure it exists: https://httpd.apache.org/security/vulnerabilities_24
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.
> CVE-2026-119618 is a critical, high-severity vulnerability involving....
two CVEs? (111497 != 11968)
Even the latest and greatest big models miss trivial errors when simply asked to review a chunk of text.
I want the rabidly AI-hating projects to stand their ground and refuse to fix vulnerabilities discovered with AI assistance.
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.
> No LLMs for finding bugs.
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.
> 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.
I totally buy into the FOSS and DOS arguments, though. I just did a test: “implement `size_t strlcpy(char dst, const char src, size_t size)` in C”. In a one-shot, 3 of the top 5 LLMs will give OpenBSD’s implementation with the license stripped. The other two will do it in some cases where other context exists first (nothing prodding, just asking for other implementations). Similar results with qsort, but they split on two different implementations, change variable names, and fail to emit the original license.
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.
I thought mod_lua was an official module. I've just checked with Debian stable, and their "apache2-bin" package depends on liblua5.
> Apache has plenty of life left
I would expect a project with "plenty of life left" to support HTTP3. And to use Git (or some modern DVCS) instead of Subversion.
BTW, a co-worker has to maintain an Apache server because its shibboleth mod is mandatory for that project, and he often complains about it, and so do I when they ask for help. Performance is worse than nginx, configuration is awful, documentation is uneven, some features (like .htaccess) are dangerous, etc.
Apache http is the only project that I know that still uses Subversion. They have published a Git clone on Github, but their main source is still svn. It's a bit worrying, because they won't attract new developers with that technical stack. Last I checked, the 2.5 branch looked dead, and the dev-list was barely active.
* https://httpd.apache.org/docs/2.4/mod/mod_lua.html
?
https://httpd.apache.org/docs/trunk/mod/mod_md.html
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.
Perfect security.
Modifying the web server config is a nonissue outside of shared hosting, which should have died out with the advent of VMs/containers.
Caching is a thing. Only dump the cache when a changed is noticed.
Its use is optional: set "AllowOverride None" and it's disabled.
* https://httpd.apache.org/docs/current/mod/core.html#allowove...
…? But disabling the feature does not remove it?
It's there for those that happen to need it, and gets out of the way for those that do not. If you need it Nginx provides no solution at all.
My car has the feature of cruise control: if I do not turn it on does it get "removed"?
You can't have it both ways. Either it's a misfeature but it 'doesn't matter' because it can be disabled, or its a legitimate feature in which case you must therefore defend the existence and purpose of the feature.
When you don't need it, great, you've got slightly better performance.
Why would this be conceded?
Really not sure how one could possibly read my comment as me saying htaccess is the only way of configuring Apache?
That can expose your files for such a trivial reason as different end of line sequence that it expects. Instead of shutting down the access, it just happily ignores .htaccess and enables DirectoryIndex.
This is the software that's responsible for majority of data leaks in the world.
Stop using it.
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
Copy and pasting got things to work eventually - but my next matrix install had a similar loop where I learned about some gotchas and 'dont do this thing!' stuff with nginx.
I tried caddy instead at some point which seemed like a nicer / easier to read and do type of thing.. but then compatibility issues with Debian + Matrix + Caddy just became another time sink.
apache things would of been easier for me if the matrix tutorials including it. then some nginx updates and other things - I would not call it easier to configure.
definitely some nice things in there though - loved seeing the power of how it can work and it makes sense. It may be worth it, but not easier I feel.
Also, Nginx's maintainers are weird about standards. e.g., last time I checked, tabs in header field line whitespace were rejected by the Nginx parser, even though the RFC says to allow it. The maintainers at the time didn't care and wouldn't fix, reasoning that Nginx had been behaving this way for so long that anything sending tabs in header field lines would have stopped by now. I don't love that attitude.
Apache is way better in this regard. (Though I think Nginx may have cleaned up its act recently?)
Disabling h2 is the mitigation and is effective. The patch itself seems a little odd as a fix to me personally, but eh.
What exactly is the issue and does nginx have it
If it was even enabled that is.
1. Don't disclose, ignore vuln. 2. Disclose to highest bidder, even criminals or state agencies. 3. Disclose to vendor, no follow up. 4. Disclose to vendor, release to public after a set delay. 5. Disclose to public.
4 & 5 are "responsible disclosure". 4 is also "coordinated disclosure". The other options ignore the ethical duty engineers have to the public.
https://xin.dev/blog/multiple-nginx-vulnerabilities/
Sorry for you I did not meet your standards. Pfff.
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.
In particular it's `req` in the function with this signature:
The fix being: My read on this is that `req` is meant to be a readonly value in this function, which is why it's marked `const`. And being readonly, it would be safe to access concurrently. However, someone accidentally wrote through this pointer.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.
Where this is one such oversight, there are likely others. An LLM isn't needed to find these, likely stricter compiler flags.
https://github.com/icing/mod_h2/commit/1b468851c89cdbf6d0f98...
Looks like he made the change on the Transfer-Encoding line when he was moving things around, but missed doing the same on the Content-Length line.
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.
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).
https://httpd.apache.org/docs/current/mpm.html#defaults
(I personally think it's slow and ugly, but to each their own)