I tested an unpatched forgejo (enabling passwords temporarily, and even adding root to permitted users) and couldn't trigger this.
ETA: I could trigger it. You need to enable passwords and add a second user with a valid password, then git@ works. Obviously this still means the default forgejo is safe as you say.
Same issue with key reuse. Unless you have a policy to rotate them and verify which host they login from, someone's unencrypted hard drive from 5 years ago is more likely to have a key than password.
> someone's unencrypted hard drive from 5 years ago is more likely to have a key than password.
Even 5+ years ago, hardware-backed SSH keys were a thing (Yubikey). The only difference today is that its 100% easier to do keys properly because of the widespread commoditisation of secure enclaves in desktops and smartphones to support FIDO, its basically free of charge now because you're not obliged to buy a Yubikey.
> Its not asking for trouble, it is there will be trouble, not if but when.
Did any of those bots brute force a password? Because a 20 character random password is comparable in brute force complexity to an SSH key. The experiment you ran was just as valid for SSH keys on that port, and had no bearing on password vs key.
The point is they found the security by obscurity so-called "hidden" port in less than a couple of hours.
At that point, what they did is irrelevant. The point is that security by obscurity does not work in 2026.
> Because a 20 character random password is comparable in brute force complexity to an SSH key.
You can't be serious with your comment.
No its not.
And even then, SSH key is asymmetric, you're not sending the private key to the server. But with a password you are, which leaves you vulnerable to many attack vectors that simply do not exist with keys.
This is a sampling error - we're only hearing about the public disclosures.
(almost) No company actually has secret source code, only source code not publicly viewable. And the LLMs crawling those don't belong to people who make public disclosures.
> LLMs crawling those don't belong to people who make public disclosures
Using LLMs is a great way to empower the governments behind them (US and PRC) to cultivate a garden of undisclosed bugs in your closed commercial codebases.
> > Because a 20 character random password is comparable in brute force complexity to an SSH key.
> You can't be serious with your comment. \n\n No its not.
If you differ in opinion, maybe provide evidence? Especially for a claim like long randomly generated value 1 being absurdly ("can't be serious"-level) weak as compared to long randomly generated value 2
If you mean it's log(62^20,2)≈119 bits of entropy instead of 128+ and so it's theoretically weaker when we build a Dyson sphere around the sun to brute force that key (after somehow obtaining the shadow file, since an online attack would be way too slow), then sure
I just realised I hate paywalls so much that I always close nytimes rather than logging in (I have a subscription). This one was particularly gross, the paywall blocked all of the article but left a banner ad at the top full of women posing in underwear. It's like the old internet is back
> In comments, it's ok to ask how to read an article and to help other users do so. But please don't post complaints about paywalls. Those are off topic.
Can you give examples of kernel bugs that can be targeted on an otherwise locked down system? Let's say something running just LAMP and all other ports closed off with a software firewall. Even the one in this article seems very tricky to actually exploit.
There are plenty of out of support systems still in the wild and while I'm not arguing they are completely secure I was under the impression that kernel vulnerabilities generally make a minor exploit in something else worse (chained priv escalation for example) and generally are difficult to exploit on their own. If I'm mistaken I'd love to know
Any TCP packet (with IP options) you can send to a Linux kernel that doesn't get DROP'd by netfilter makes you technically vulnerable.
That includes the one port your LAMP stack uses.
Or, the attacker might be originating from the other side of a device, like within a LAN. Malicious employees/house guests/what-have-you could target devices from inside your network where most devices (not just servers) don't have as much protection and often have other open ports accessible, like file sharing/SMB, SSH, SMTP, RDP, databases etc.
I’d rather just some sort of tag. Because sometimes it can be useful. This is a case where the community here can scrutinize the output and actually pull out useful data or steps or even starting points when information is coming in so fast for a developing story/issue
The (pretty obviously Claude'd) responses with actual steps you could take to mitigate were 1000% more useful to me than the "SHUT EVERYTHING DOWN WE'RE GONNA DIE" and the "stop posting AI slop" posts were, that's for sure.
It was your response. Of course you prefer your response.
The fact is you had no idea how useful or dangerous your advice was. PHP maintainers said to shut it down, how many people followed your advice instead? Did it work or just leave them vulnerable? Do you know?
Because you're heavily implying that the people who knew about the details of the vulnerability were panicking and thank god we had you with an LLM
As far as I can tell none of this is related to the current vulnerability in PHP itself. Even having a site that just returns echo "phone us on XXXX" is vulnerable apparently.
A dynamic language having access to all of the files it has access to is not unique to PHP. Vulnerabilities are not unique to PHP, and I doubt the Dutch National Cyber Security Center took their website offline because they lack user-specific roles in the database: https://www.ncsc.nl/index-en.html
So maybe save your elitism for a day when so many of us aren't already putting out fires? Congratulations on not being part of the 75% of the internet affected.
PHP is definitely more at risk of this class of vulnerability because fatal errors are longjmps which skip resource clean-ups. In a runtime with real unwinding, this exploit class can't exist.
> Even having a site that just returns echo "phone us on XXXX" is vulnerable apparently.
Vulnerable but perhaps with no impact. If you've setup your web server well, the vulnerable PHP process is sandboxed, at least to some degree, and an attacker executing their own code within the compromised PHP process can't move laterally through your internal networks, write files to disk, read files from disk, etc because you've locked down the PHP process.
In 2026, perhaps it's possible to:
1. Use systemd socket activation with Accept=yes [1] and strict sandboxing applied to a systemd service that executes the PHP interpreter. The result being each incoming request is dealt with inside an isolated PHP process spawned specifically to handle the request. Compromise of a PHP process doesn't impact any other concurrent requests, or any future requests, except through defined sandbox interfaces such as access to a database server socket.
2. For each user of the web application (perhaps including an 'anonymous' user too if anonymous users have access to dynamic content), if using PostgreSQL, create a role in PostgreSQL for each web application user. Then use row-level-security permissions and security barrier views within the database, and have the PHP process accept credentials from the user which are then needed to be passed through to PostgreSQL to login as that individual user.
It's not without some significant downsides:
1. It's complex and you might be the only person in the world trying to use PHP in this secure way. And if you're going this far, for a complex web application, it'd be best to split it into smaller web applications each with their own systemd service defining specific sandboxing constraints. E.g. microservice architecture where "login", "file upload", "user administration" are all separated with different sandboxing constraints applied to each.
2. Performance will suffer and you'll need more resources--for spawning new PHP processes from scratch for each request (although this is already the case with php-fpm which is most widely used), and for dealing with row-level-security in PostgreSQL (see e.g. LEAKPROOF functions).
The more common pattern I've come across on public websites in recent times that might mirror some of the above is client-side JavaScript dynamic rendering with API calls to a GraphQL database exposed on the Internet (using e.g. field-level access control). The user isolation problem is essentially pushed from PHP+PostgreSQL to a GraphQL implementation.
The question to ask is should these defaults be tightened. For example, disallow read and execution of anything outside /var/www/, such as /usr/bin/sh. For example, block syscalls PHP won't ever use to limit chance of a compromised PHP process being able to utilise a LPE kernel vulnerability. And then update user installation documentation to explain the onus is on the user to open up very restrictive default permissions should they really have a need to do so.
reply