There's a narrative going around that anyone who spent time on things like learning vim has wasted their time because agents write the bulk of the code now, but it's actually the other way around. Remote dev envs, agents in worktrees, ... all make TUI/CLI tools even more useful
vim mode in a shell only feels like a minor improvement compared to the default Emacs-style readline bindings but when you're connected to a shell from a phone it actually makes using the shell 10x less painful
Jujutsu workspaces work really really well with parallel agent work despite agents defaulting to git too much
Think the main thing is just not needing stupidly rigid branches for everything but being able to use the commit graph however you want
The whole messaging around this thing is a mess. I'm guessing that because there's not an exhaustive list of exploit chains available to the PHP team, they can't definitively say what settings prevent what exploits, so we just get a vague list of potential mitigations.
Some random pieces of information from what I've gathered:
- Apache + mod_php are the easiest to exploit, but the main POC on GH (which claims to deal with ASLR) also uses session upload progress which was said to not be a full mitigation
- You need to send at least a few requests to a single worker, so max_requests=1 would mitigate at least some exploit paths fully (?)
- Some of the POCs seem to try to keep other workers busy to guarantee their followup requests reuse the same worker
- *Attempts* at exploiting a worker can cause it to crash, so perhaps looking at worker crashes can be informative?
- It's possible many targets are individually exploitable with enough work, but it'd take some time. OTOH some POCs claim to work in seconds. But then again no reports of mass exploitation?
- Seems it remains reasonable to keep upload progress disabled even on the patched versions
Related, I'm seeing a lot of conflicting claims by people who have or claim to have POCs/exploits.
Some are LLM slop and seem to require you to manually provide some addresses.
Others purport to defeat ASLR. And others talk about new exploits in the patched versions.
Tagging @ethicalhack3r @OliverSild @photomatt and @perezbox so you can loop in @GoDaddy if you still have contacts there. And looping in @gdb because he and @eastdakota are appearing together. Guys we haven't seen a single hacked WP site from #php2shell and we're (@wordfence is) protecting over 5 million PHP/WP sites. You know the deal. If it's exploitable, we all see site cleanings. No one in cybersecurity wants to minimize a vulnerability in case it does blow up. We're seeing reports from @Cloudflare and @eastdakota of attack attempts. We're seeing attack attempts in our telemetry. But we're not seeing a single compromised site. No one wants to say that it's not exploitable against vanilla PHP because it may turn out to be. I think we all know CVSS scores are imperfect. And the messaging here is off the charts. This has gone mainstream, but no one is talking about the fact that no one is seeing hacks. It's easy to take a bow and claim industry success, "go team cyber" and all that. But you know if these things are a legit risk you'll see compromised sites. Especially in the PHP/WP space where there are a lot of individual boxes out there with owners on vacation or MIA. And nothing. Not one. So I think the conversation that needs to happen is something like this: We're going to find scary vulnerabilities with the amazing capabilities that @OpenAI and @AnthropicAI are bringing online, but we need to calibrate the messaging to take into account how exploitable and scriptable each vuln is, or we risk alert fatigue and blowing credibility which we'll badly need when an exploitable scriptable vulnerability shows up.
Docker Hub is taking forever to build the new images, seems like the best option is to just build the tags yourself for now and rebuild server images without --pull?
docker build -t php:8.4-fpm-bookworm "https://github[dot]com/docker-library/php.git#e3eaff845f7a9f7259c31da54dce0320b47a3bbd:8.4/bookworm/fpm"
New PHP versions in nixpkgs master but not yet nixos-unstable, looks like an overlay using PHP packages from a separate input is needed for now
If you're running an EOL PHP version in prod — the Sury debian packages seem to patch more versions than github.com/remicollet/php-sr… at this time
If you need the patches themselves, you can find the tarballs here packages.sury.org/php/pool/m… and extract the debian/patches dir
The PHP team also went out of their way to release special official backports for:
- 7.4 github.com/php/php-src/tree/…
- 8.0 github.com/php/php-src/tree/…
- 8.1 github.com/php/php-src/tree/…
In case this helps anyone — seems like the PHP RCE is already being exploited (or people are at least trying) and the patch isn't out yet.
Known partial mitigations:
- `session.upload_progress.enabled = Off` in php.ini
- Block all multipart requests in nginx/WAF. Breaks uploads
If you have serious projects on GitHub, it's a good idea to set up mirrors of your repos on other forges. Very easy to do with Gitea/Forgejo.
Self-hosting Forgejo is also super easy, if you have a NixOS server you can just add it as a service and put it behind nginx like this
banning someone from github without a warning is fucked up @github @Microsoft
i need to copy my repos damn
Here's what a full server configuration can look like gist.github.com/stancl/589c4…
Samuel Stancl retweeted
Thank you @vonderleyen, very cool!
