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.
account42 13 hours ago [-]
> 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.
markasoftware 6 hours ago [-]
No, it makes things dramatically better when there are lots of small assets. You used to need a ton of tiny TCP connections to make that kind of site work. Try writing a web scraper and observe how much faster it goes with http2 on (which is one of my biggest gripes with wget and other recursive downloaders: no http2! And the "wget2" project is trash and crashes constantly)
Woodi 12 hours ago [-]
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.
kbolino 5 hours ago [-]
> Apache is dead shell at this point
There's far more to HTTP than just the transport. There are, for example, 4 governing RFCs for modern HTTP implementations:
The nghttp2 library is only going to cover 1/4 of those. Apache is directly responsible for implementing 2/4 of those, and since it provides its own HTTP/1.1 implementation as far as I know, it's actually 3/4 of those.
newsoftheday 6 hours ago [-]
> mod_http2 use external library nghttp2[.org] so Apache is dead shell at this point.
Edge, Brave, Opera, Vivaldi, Arc and Electron use Chromium, are those browsers dead shell?
Netflix, LinkedIn, and Uber, most major corporations as well as the desktop version of Minecraft use the JVM, are they dead shell?
Woodi 5 hours ago [-]
If there is some serious level of development then that thing isn't dead.
Edge is a fork, Brave is ad machine, Electron is trash and in last days it shows nicely in media. Vivaldi and Arc probably are just shells.
> Netflix, LinkedIn, and Uber, most major corporations as well as the desktop version of Minecraft use the JVM, are they dead shell?
Comparing oranges to planets is a thing now ??
newsoftheday 5 hours ago [-]
I extrapolated your use case concerning one popular app being dead simply because it uses a library, to reusable software modules; which is what libraries are. No oranges, apples, fruit or planets were used in the question.
Woodi 3 hours ago [-]
Apache httpd is HTTP protocol iomplementation and it do not have own HTTP/2 implementation.
And there is v3 in production for years now and I didn't see anything with '3' in the name in sources.
Extrapolation failed. That "library" do heavy lifting so it's not a "simple usage " of some support library like eg. JSON lib could be but total failure of implementing core functionality.
At best it's a stopped development. So dead project.
Someon on HN posted link to patch, it's a one-liner. But Apache organization sugest downgrade to 90's instead. "Compile that open sources ASAP!" would be much more sensible.
mogoh 13 hours ago [-]
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.
mono442 13 hours ago [-]
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.
load-bearing 10 hours ago [-]
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.
kibwen 10 hours ago [-]
Agreed. Too much complexity for too little gain for too narrow use cases. HTTP/1.1 will outlive HTTP/2.
throooooo 18 hours ago [-]
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.
hannob 15 hours ago [-]
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.
account42 13 hours ago [-]
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.
throw0101c 10 hours ago [-]
> I would say that's actually a misfeature as it requires too many additional filesystem lookups to fulfil requests.
Its use is optional: set "AllowOverride None" (the default) and it's disabled.
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"
throw0101c 8 hours ago [-]
> But then that removes the "feature Apache has that no other webserver does" […]
Disabling the feature does not remove it.
If I do not turn on my car's windshield wipers, do they get "removed"?
DaSHacka 5 hours ago [-]
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.
throw0101d 1 hours ago [-]
> But, if we concede that it's a misfeature […]
Why would this be conceded?
> 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.
Just because I don't (currently) use it doesn't preclude someone else from doing so, and if that someone else wants to explain their use-case that's their prerogative.
BenjiWiebe 4 hours ago [-]
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.
1 hours ago [-]
dspillett 8 hours ago [-]
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.
jagged-chisel 12 hours ago [-]
> … too many additional filesystem lookups …
Caching is a thing. Only dump the cache when a changed is noticed.
canibalrex 12 hours ago [-]
And now you have 2 problems..
BenjiWiebe 4 hours ago [-]
I believe the OS actually caches it, and since you only modify it by interacting with the OS, the cache gets invalidated when needed.
canibalrex 2 hours ago [-]
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.
bch 10 hours ago [-]
Webserver/filesystem management, cache invalidation, and off-by-one errors.
sscaryterry 9 hours ago [-]
Your forgot naming things :)
flir 8 hours ago [-]
ok, five problems
cozzyd 8 hours ago [-]
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!).
vbezhenar 9 hours ago [-]
Why shared hosting should die? It's still the cheapest way to publish a dynamic website.
ForHackernews 7 hours ago [-]
Shared hosting was and still is a great idea, IMHO it just should be limited to static files, not running server-side webapps.
Alghranokk 14 hours ago [-]
Does not Microsoft's IIS also have that with web.config files?
cozzyd 8 hours ago [-]
Does IIS run on Linux?
joseda-hg 11 hours ago [-]
Yes, but then you're dealing with IIS and why would you want that?
Alghranokk 9 hours ago [-]
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.
Perfect security.
mitxela 7 hours ago [-]
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.
HackerThemAll 10 hours ago [-]
> 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 than what 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.
cyphar 13 hours ago [-]
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.
anonreplier 12 hours ago [-]
Yes apache has a config file too amazingly enough, .htaccess is optional
cyphar 11 hours ago [-]
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?
system2 15 hours ago [-]
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.
ezst 14 hours ago [-]
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.
arcanemachiner 13 hours ago [-]
The lazy bastard in me prefers Caddy.
theandrewbailey 12 hours ago [-]
I don't understand this. NGINX can run PHP. PHP is not exclusive to Apache.
Joel_Mckay 11 hours ago [-]
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
tredre3 6 hours ago [-]
There is a way nginx/fpm to host multiple domain where each domain has its own user and group and they maintain 0750 permissions so they can't see eachother but nginx and php can both access them:
- php-fpm is easy, you can make the pool run as the domain's user/group directly
- nginx: you must add nginx's user (www-data) to the domain personal's group
The downside to this approach is that it's harder to reason about for someone unfamiliar with it and it's easy to misconfigure file permissions. There is also a limited number of extra groups a user can be part of before it becomes an issue (plus one fpm pool per user takes memory).
That being said the best massively-shared hosting system I've ever used was apache mpm_prefork with mod_php and mod_ruid2. It used as much(little) memory as a single user setup, it scaled to 10k users if you wanted, and file permissions were all naturally handled.
The way mod_ruid2 worked was to use linux capabilities to change the effective user/group of the apache process before serving the request, so it would run as the tenant's group and user, then switch back to nobody/nobody. It had very little overhead compared to things like mod_suphp and, more importantly, it also worked on static files and .htaccess!
The module has been abandoned and was never that popular so I always wondered if it was found to be exploitable or something... Thanks to Linux Capabilities an exploiter couldn't gain root, but as seen from the recent exploit apache's mod_php doesn't do a full cleanup so maybe there was leakage when the process was reused (but then that is solvable by limiting the requested to 1)
ransom1538 14 hours ago [-]
Eh. You can use .htaccess in nginx too. I use that everyday.
orev 18 hours ago [-]
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.
nine_k 17 hours ago [-]
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 mostly use nginx lua to patch on some feature i had even on bare Apache, let alone all the core modules.
idoubtit 10 hours ago [-]
> (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.
throw0101c 10 hours ago [-]
> 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?
Probably depends on what one you learned first. I learned Apache first, around 1995 - 96. Nginx felt "weird" to me, though I do prefer it now.
newsoftheday 7 hours ago [-]
Hard disagree, for me Apache's rule sets which look a bit like XML but predate XML by several years, are easier to read, understand and maintain.
stevenicr 6 hours ago [-]
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.
cozzyd 8 hours ago [-]
Not if you've been using Apache for 20+ years...
lobo_tuerto 8 hours ago [-]
For starters it doesn't have a Critical RCE Vulnerability.
lozf 8 hours ago [-]
s/a/a\ known
Zambyte 6 hours ago [-]
For sta knownrters it doesn't have a Critical RCE Vulnerability.
lozf 52 minutes ago [-]
Whoops :)
fhn 5 hours ago [-]
you've missed a number of other 'a's :)
saltcured 5 hours ago [-]
Without the "g" option, the "s" command is only addressing the first match.
throw0101c 8 hours ago [-]
[dead]
nik282000 15 hours ago [-]
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.
tasuki 13 hours ago [-]
Exactly the same for me! I could switch to Nginx, it's one prompt away probably, but why?
bkallus 6 hours ago [-]
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?)
skeletal88 16 hours ago [-]
Why would I not use apache if everything already works with it for me?
load-bearing 16 hours ago [-]
Apache has mod_md -- an acme client, which lets you obtain https certificates as easily as on caddy, without integrating with awkward separate programs.
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.
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
JodieBenitez 18 hours ago [-]
At work we use Apache because of mod_shib. We have yet to try nginx-http-shibboleth.
throwaway7356 11 hours ago [-]
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.
JodieBenitez 8 hours ago [-]
Yeah, I wish we would, but I have no say here.
dawnerd 17 hours ago [-]
Default Wordpress docker image uses it.
DaSHacka 8 hours ago [-]
MediaWiki also has it as a dependency OOTB.
cozzyd 8 hours ago [-]
apache comes standard on EL systems and I've never had a reason to replace it for what I do...
dizhn 15 hours ago [-]
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.
rurcliped 12 hours ago [-]
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.
speleding 10 hours ago [-]
Shutting down Apache is perhaps overcautious? Simply doing `sudo a2dismod http2` and then restarting Apache should be enough as far as I can tell
bennofs 11 hours ago [-]
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).
lionkor 10 hours ago [-]
I would suggest instead blocking 80 and 443 on UDP and TCP, via your firewall.
0x0 12 hours ago [-]
If I need to make sure apache doesn't restart I often type "syntax error" on the first line of httpd.conf
> CVE-2026-119618 is a critical, high-severity vulnerability involving....
two CVEs? (111497 != 11968)
kbenson 19 hours ago [-]
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.
2bird3 19 hours ago [-]
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!
davisr 17 hours ago [-]
What makes you think it's not already an LLM error?
brabel 17 hours ago [-]
Even a tiny model would pick up an error like this during review.
amluto 13 hours ago [-]
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.
iririririr 15 hours ago [-]
just had claude today spew some basic firewall rules for port 5900 and 5901... it used 5900 and 59001
spuz 16 hours ago [-]
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.
spuz 16 hours ago [-]
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?
glawre 13 hours ago [-]
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.
necovek 13 hours ago [-]
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).
neurostimulant 14 hours ago [-]
Chances are most Apache/PHP installations run mpm_prefork and aren’t affected by this.
ezst 14 hours ago [-]
why? mod_mpm_event is what can be assumed to be the default since apache 2.4 (± 2012):
IIRC popular apache/php platforms such as cpanel, official wordpress docker container image, etc use mpm_prefork by default.
palominoz 4 hours ago [-]
I don't see http2 module enabled by default in ubuntu22 lts
z3ratul163071 17 hours ago [-]
what is amazing, there are no apache updated containers / packages available yet.
Deukhoofd 16 hours ago [-]
Why are these things being disclosed before fixes have been rolled out? Is no-one following disclosure protocols any more?
SAI_Peregrinus 8 hours ago [-]
Full disclosure has always been an option.
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.
load-bearing 10 hours ago [-]
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.
sherr 13 hours ago [-]
Debian has been patched just now and updates available : apache2 2.4.71-1~deb13u1
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.
ian-g 5 hours ago [-]
I'd like to point out, really quickly, that the patched version of open source mod_http2 is listed as 2.0.24 and newer while the affected versions are 2.0.8 through 2.0.42.
I think they meant to say the first patched version is 2.0.43
Fortunately for me EL8/9 don't enable http/2 and I never bothered enabling it anywhere. (EL8 is not vulnerable anyway since its httpd is too old).
jerrythegerbil 18 hours ago [-]
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.
NitpickLawyer 18 hours ago [-]
Did it manage to produce a PoC for RCE? Apparently Redhat claimed there's a RCE, while Wiz said they don't have one.
lifeisloving 18 hours ago [-]
[dead]
EGreg 16 hours ago [-]
http2 race??
What exactly is the issue and does nginx have it
eptcyka 14 hours ago [-]
What is the benefit of using Apache over enjinx?
mhitza 13 hours ago [-]
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.
14 hours ago [-]
jgalt212 5 hours ago [-]
It seems HTTP/2 is not enabled by default in apache.
ankit9673 12 hours ago [-]
everybody new Vulnerability makes me think how we are not so good a writing secure code?.
lionkor 10 hours ago [-]
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.
gib444 12 hours ago [-]
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.
brazukadev 10 hours ago [-]
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.
yunuserturk 17 hours ago [-]
LiteSpeed and OpenLiteSpeed affected by this?
dspillett 8 hours ago [-]
Highly unlikely. It is a bug in Apache.
jaekwon 16 hours ago [-]
gno.security/repairer
kgeist 20 hours ago [-]
>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? :)
woodruffw 20 hours ago [-]
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.
thephyber 14 hours ago [-]
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.
uptrails 16 hours ago [-]
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.
fooqux 20 hours ago [-]
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.
kgeist 20 hours ago [-]
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?
stonogo 20 hours ago [-]
Presumably one of Anthropic, Google, or Apache possesses a working exploit, because the official Apache Foundation report on this CVE claims RCE is possible.
edoceo 20 hours ago [-]
Isn't resource consumption a DoS?
woodruffw 20 hours ago [-]
A denial of service is a different class of vulnerability (a minor one, generally).
perching_aix 20 hours ago [-]
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.
From 2.4.55 through 2.4.70? Jokes on you, my version is not that new!
jamesfinlayson 17 hours ago [-]
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.
toast0 19 hours ago [-]
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
fulafel 18 hours ago [-]
The C chansaw juggling doesn't get any safer from adding threads. Is the robust original (pre)fork configuration still supported?
toast0 17 hours ago [-]
I run apache with prefork on my personal sites. Still works. No idea if it supports http/2.
fock 17 hours ago [-]
I don't know, but Claude is fixing that too! (doubt that makes it safer either...)
weryberl5 8 hours ago [-]
First PHP had that php2shell vulnerability and now Apache?
Not a good month for the legacy wares.
dspillett 6 hours ago [-]
PHP and Apache have been around a log while, but they are still actively used even for new installs, so calling them legacy is a bit of a stretch.
haradion 16 hours ago [-]
This has not been a good month for the LAMP stack…
superkuh 20 hours ago [-]
It's not always HTTP/2. But it's a pretty safe bet.
userbinator 20 hours ago [-]
The vulnerability affects deployments utilizing HTTP/2 capabilities
cubefox 17 hours ago [-]
No CVSS severity level?
8-prime 15 hours ago [-]
NIST doens't show one (yet?). I checked on RedHat and they list it at a 9.8
cubefox 14 hours ago [-]
That's crazy high.
bell-cot 8 hours ago [-]
When the headline says "Critical RCE Vulnerability in {internet-facing software}" - how might the exact severity number matter to you?
cubefox 7 hours ago [-]
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.
TZubiri 19 hours ago [-]
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.
perching_aix 19 hours ago [-]
isn't http/1.1 request smuggling a known risk in exactly the scenario you're using it in?
hypfer 17 hours ago [-]
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?
TZubiri 5 hours ago [-]
Well I have an apache reverse proxy that terminates TLS and redirects to my backends based on the domain from the host header. So that's a reverse proxy chain of size 1? maybe 2 depending on how you count?
Seems like the Attack Complexity would be quite high, especially without access to my source code.
And again the backend is usually just a python server that opens port 80 with sockets and parses and generates the HTTP strings in code. Maybe a raw flask server when I was feeling naughty, so maybe you can smuggle a request there or something, but as long as there's no RCE + LPE it's not something I'd be worried about.
At any rate, any project that has a sufficient sensitivity and budget threshold gets their own VPS and apache is dropped and you just have the raw python server with stunnel or an external SSL terminator like ELB, so there isn't much to gain from such a sophisticated attack on Apache, since that gets dropped once the paydirt becomes juicy enough.
g-b-r 19 hours ago [-]
Even Apache is being filled with Claude commits, so great.....
g-b-r 19 hours ago [-]
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
perching_aix 19 hours ago [-]
The vulnerability first shipped on Jan 17, 2023. That puts it to 1, B.C. (Before Claude). Or tbh just a few months B.C., but hey. Some might even argue it was in 3 B.C.!
The fix commit was a one liner by Apache developer Eric Covener, so unsurprisingly, no Claude in sight there either.
Or did you mean in general? Not exactly coinciding news, so a bit odd if so...
pixel_popping 18 hours ago [-]
You prefer to leave it insecure?
g-b-r 18 hours ago [-]
It was a comment unrelated to this vulnerability
shipsafestack 5 hours ago [-]
[flagged]
cnczeric 9 hours ago [-]
[flagged]
yoy0721 11 hours ago [-]
[flagged]
spencerawlson 10 hours ago [-]
[flagged]
tgma 16 hours ago [-]
Time for a Rust based httpd replacement like https://xin.dev
hnarn 16 hours ago [-]
How would Rust have fixed this security issue?
Xylakant 13 hours ago [-]
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.
K0nserv 13 hours ago [-]
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)
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.
jhatax 7 hours ago [-]
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.
testplzignore 5 hours ago [-]
Here's the commit from 4 years ago that refactored the code into its current state:
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.
Ukv 13 hours ago [-]
> > 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.
flossly 15 hours ago [-]
They've published an article last month on the Nginx vulnerabilities in light of their Rust implementation.
If you’re going to respond, at least make an attempt to answer the question.
flossly 11 hours ago [-]
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.
yjftsjthsd-h 8 hours ago [-]
The question was how rust would prevent this vulnerability.
flossly 15 hours ago [-]
Cannot find the source... (Wanted to see if they use the RusTLS)
mono442 13 hours ago [-]
this looks vibecoded which is probably even worse
tancop 18 hours ago [-]
HTTP2 is insecure and 1.1 is slow. At this point just find a good H3 implementation and drop the old protocols.
nine_k 17 hours ago [-]
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.
zbentley 9 hours ago [-]
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.
account42 13 hours ago [-]
Well there's HTTP/0.9. Can't get much simpler than that.
krembo 16 hours ago [-]
Wiz is such an amazing company. Israeli-based and recently acquired by Google, the significance of their security contributions cannot be overstated.
lakeviewterrace 20 hours ago [-]
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.
jonhohle 19 hours ago [-]
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.
yjftsjthsd-h 17 hours ago [-]
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.
jonhohle 5 hours ago [-]
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.
jamesfinlayson 17 hours ago [-]
> 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.
JodieBenitez 17 hours ago [-]
cough Zig... cough
> No LLMs for finding bugs.
nozzlegear 20 hours ago [-]
> I want the rabidly AI-hating projects to stand their ground and refuse to fix vulnerabilities discovered with AI assistance.
Why?
patchtopic 16 hours ago [-]
because it's just some slop generated by a bunch of stochastic parrots and can't be taken seriously :-)
perching_aix 19 hours ago [-]
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
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.
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.
There's far more to HTTP than just the transport. There are, for example, 4 governing RFCs for modern HTTP implementations:
The nghttp2 library is only going to cover 1/4 of those. Apache is directly responsible for implementing 2/4 of those, and since it provides its own HTTP/1.1 implementation as far as I know, it's actually 3/4 of those.Edge, Brave, Opera, Vivaldi, Arc and Electron use Chromium, are those browsers dead shell?
Netflix, LinkedIn, and Uber, most major corporations as well as the desktop version of Minecraft use the JVM, are they dead shell?
Edge is a fork, Brave is ad machine, Electron is trash and in last days it shows nicely in media. Vivaldi and Arc probably are just shells.
> Netflix, LinkedIn, and Uber, most major corporations as well as the desktop version of Minecraft use the JVM, are they dead shell?
Comparing oranges to planets is a thing now ??
And there is v3 in production for years now and I didn't see anything with '3' in the name in sources.
Extrapolation failed. That "library" do heavy lifting so it's not a "simple usage " of some support library like eg. JSON lib could be but total failure of implementing core functionality.
At best it's a stopped development. So dead project.
Someon on HN posted link to patch, it's a one-liner. But Apache organization sugest downgrade to 90's instead. "Compile that open sources ASAP!" would be much more sensible.
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.
Modifying the web server config is a nonissue outside of shared hosting, which should have died out with the advent of VMs/containers.
Its use is optional: set "AllowOverride None" (the default) and it's disabled.
* https://httpd.apache.org/docs/2.4/mod/core.html#allowoverrid...
Disabling the feature does not remove it.
If I do not turn on my car's windshield wipers, do they 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.
Why would this be conceded?
> 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.
Just because I don't (currently) use it doesn't preclude someone else from doing so, and if that someone else wants to explain their use-case that's their prerogative.
When you don't need it, great, you've got slightly better performance.
Caching is a thing. Only dump the cache when a changed is noticed.
Perfect security.
That can expose your files for such a trivial reason as different end of line sequence than what 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.
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.
Really not sure how one could possibly read my comment as me saying htaccess is the only way of configuring Apache?
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
- php-fpm is easy, you can make the pool run as the domain's user/group directly
- nginx: you must add nginx's user (www-data) to the domain personal's group
The downside to this approach is that it's harder to reason about for someone unfamiliar with it and it's easy to misconfigure file permissions. There is also a limited number of extra groups a user can be part of before it becomes an issue (plus one fpm pool per user takes memory).
That being said the best massively-shared hosting system I've ever used was apache mpm_prefork with mod_php and mod_ruid2. It used as much(little) memory as a single user setup, it scaled to 10k users if you wanted, and file permissions were all naturally handled.
The way mod_ruid2 worked was to use linux capabilities to change the effective user/group of the apache process before serving the request, so it would run as the tenant's group and user, then switch back to nobody/nobody. It had very little overhead compared to things like mod_suphp and, more importantly, it also worked on static files and .htaccess!
The module has been abandoned and was never that popular so I always wondered if it was found to be exploitable or something... Thanks to Linux Capabilities an exploiter couldn't gain root, but as seen from the recent exploit apache's mod_php doesn't do a full cleanup so maybe there was leakage when the process was reused (but then that is solvable by limiting the requested to 1)
* https://httpd.apache.org/docs/2.4/mod/mod_lua.html
?
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.
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?)
https://httpd.apache.org/docs/trunk/mod/mod_md.html
> 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.
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
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.
If it was even enabled that is.
I think they meant to say the first patched version is 2.0.43
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
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.
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.
>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? :)
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.
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.
> (...) 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?
Is that just crappy LLM generated copy that is assuming that GitHub the company is responsible for that module because it’s hosted there?
Not a good month for the legacy wares.
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 guess it makes sense that "the cloud" moves to it, but beyond that, it might be fine?
Seems like the Attack Complexity would be quite high, especially without access to my source code.
And again the backend is usually just a python server that opens port 80 with sockets and parses and generates the HTTP strings in code. Maybe a raw flask server when I was feeling naughty, so maybe you can smuggle a request there or something, but as long as there's no RCE + LPE it's not something I'd be worried about.
At any rate, any project that has a sufficient sensitivity and budget threshold gets their own VPS and apache is dropped and you just have the raw python server with stunnel or an external SSL terminator like ELB, so there isn't much to gain from such a sophisticated attack on Apache, since that gets dropped once the paydirt becomes juicy enough.
The fix commit was a one liner by Apache developer Eric Covener, so unsurprisingly, no Claude in sight there either.
Or did you mean in general? Not exactly coinciding news, so a bit odd if so...
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.
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.
https://xin.dev/blog/multiple-nginx-vulnerabilities/
Sorry for you I did not meet your standards. Pfff.
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.
> 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'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.
> No LLMs for finding bugs.
Why?