88
There isn't an easy exploit for this PHP vulnerability
(eliastaylor.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 22 Oct 2026
88 points (88.6% liked)
Selfhosted
63189 readers
249 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 3 years ago
MODERATORS
Yes the vulns are real. No that does not mean a system with the vuln is automatically and noticeably exploitable: that assumes there are no other defense systems or simply other happenstance logical walls around (firewalls, datacenter range blocks, seven proxies, 28 NATs, Anubis, whathaveyou).
My understanding is that CVEs are ranked not by Real World conditions but rather under an "idealized threat condition" that imagines your machine is essentially connected with a straight wire to the root DNS serves of the internet, given a public IPv4 address, and the off switch is dislodged or somehow made unavailable.
I don't think any of those walls help except for a WAF that knows what to look for. I don't know exactly what the real exploits look like but I heard something about constructing multipart form bodies that expand to a surprisingly large amount of PHP memory compared to the size of the request body, and that's probably something a heuristic on a WAF could detect. I would want to do more research before relying on that.
So a multipart form "zip bomb"? Sounds like the kind of thing that would do... well, that. But also, by that point you don't even need a WAF to block it, IIRC multipart forms can be disabled or their memory limit clamped on php.ini.
(Not that I'd rely on that; not everyone has access to php.ini. But then again, we are talking about a world where there are more than one (1) ways of dealing with problems)
I don't know if they can be disabled, but I think the memory limit is actually the problem. One of the vulnerabilities is related to how PHP handles exceeding a memory limit. I don't know if it's the same limit you're thinking of. I have been avoiding PHP for a long time. If it were that simple, I'd have expected the advisories to mention it as a mitigation.