upvote
It's free, MIT open source. It was the best I could do. Run it under a Linux user with no permissions to access anything. All it's supposed to do is proxy requests. Don't give it access to any files.
reply
> It was the best I could do.

Honestly, and not to be harsh, but doing absolutely nothing is better than what you've done here.

Not only is this proxy unlikely to actually protect against the issues, but this code almost certainly has its own, equally bad security vulnerabilities. A 30 second check with Opus 5.5 found at least one heap overflow, multiple memory leaks, and a number of bugs that shows that it doesn't even succeed at doing what it claims. I appreciate that you're trying to help, but there are better tools for the approach that you're going for here, and injecting noise with AI slop that isn't even reviewed at a basic level is causing noise, confusion, and potential harm in an already urgent, tense situation.

reply
[flagged]
reply
deleted
reply
I'm going to engage only because I do not wish others to come across this project and think it's serious. I did open the project and read the code, and I did throw it into an LLM as I previously said for some very basic security posture checks, and found a number problems immediately, but I don't trust them (and neither should you, which is part of the problem here), so I went digging a bit deeper. I don't have the time to go through all of them, so here's a big one of my own finding: There's a parser differential in how multipart boundaries are handled, your proxy only deals with ;, the PHP interpreter accepts , as well, and the proxy will pass it through unchanged to the upstream. That's a full bypass of what the proxy is trying to do.

https://github.com/Qbix/proxy/blob/main/src/sanitize.c#L41 https://github.com/php/php-src/blob/master/main/SAPI.c#L162

The article linked from your own README (https://sansec.io/research/php2shell) has a better partial mitigation in existing, battle-tested reverse proxies. Even still, as that article says, everything here is a partial mitigation. The description of the issues in your project's README is an inaccurate understatement of the severity of the issues. "CVE-2026-109618 — heap use-after-free in the session.upload_progress handler" is an incomplete understatement of the issue, the session.upload_progress handler is only one of a number of potential exploitation paths. https://github.com/php/php-src/security/advisories/GHSA-w8hw... has some hints at other paths, of which there are many.

From an LLM, and quickly validated by me, a heap overflow, likely an RCE.

> src/http.c:101-116 and src/util.c:9

Attacker supplied value in strtoul, the size-limit checks are unsigned addition that can wrap, and you can follow the chain from there.

> or better yet submit a request.

This project is not deserving of fixing, it should just be deleted and direct people to more serious documentation of fixes and mitigations. This code is clearly AI-generated slop, it is not my responsibility to fix your project.

> I could understand if you actually at least clicked and looked at the repository, and read what it’s about. But you chose to simply write generic text without looking at anything. You want to discourage people from protecting their servers, in order to feel good about yourself. What amount of effort have you put into understanding what you’re even talking about?

Every accusation is an admission.

reply
[flagged]
reply