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
465 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
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.