After being downvoted for writing that this exploit is actually feasible, and me pointing out that it's just a little heap feng shui work that any agentic LLM will find out by themselves ...
Here we go, 12 hours later, end-to-end exploit of an index.php that echoes "ok" and nothing more. Pinned PHP versions, reproducible containers for each of the CVE and exploit path/killchain variants and everything.
php.ini set intentionally to defaults. max_input_vars set to defaulted value of 1000 so it's actually harder to exploit than with a higher value.
Implemented using my Exocomp agentic environment, and my post-trained Qwen3.8 27B model that I trained on reasoning traces of DeepSeek v4 Pro. All on my github, needs a single 48GB Radeon VRAM GPU for training/inference via Vulkan (before someone claims it's too expensive).
Wake up folks, your assumptions about what is hard to do and what is not is the wrong rationality here. Humans are sequential beings, therefore we think that a lot of tasks are harder to achieve. But that's not the correct metric.
Heap Feng Shui work is gruntwork, therefore LLMs are better and faster at this than any human could ever be.
Hi, you haven't looked at the code in your exploit.
Take a look at the php files you're shipping with your "stock" server - theyre pretty contrived, no? fatal.php? producer.php boom() str repeat X 32?
You use that to get the constants for the RCE, but without that information you're in trouble. How transferrable are these constants? Do they work with any config changes?
Again, the vuln is real and you should patch, but an exploit is not easy; this is not log4shell/heartbleed etc.
> Hi, you haven't looked at the code in your exploit.
No, I did. But thanks for leading with an offensive comment, makes reading the rest much more enjoyable /s
> Take a look at the php files you're shipping with your "stock" server - theyre pretty contrived, no? fatal.php? producer.php boom() str repeat X 32?
> You use that to get the constants for the RCE, but without that information you're in trouble. How transferrable are these constants? Do they work with any config changes?
Yes, they work with changes. The point is that you have to use a container to have a reproducible memory layout that you can target. And that _is_ known and _is_ reproducible.
It's not that hard to find out which OS images or which PHP version you're running on the server, there's plenty of well working scanning tools (e.g. projectdiscovery).
And this is setting aside that 99% of servers probably run standard versions of Ubuntu or Debian combined with the distribution packages of Magento, Wordpress, etc. And those are also reproducible in their memory layout, hosting setup, built package versions, etc.
Just as a disclaimer because I know where this is going: No, I didn't target muslc. Because most operating systems still don't use it, and that's the actual problem here we should discuss here.
After being downvoted for writing that this exploit is actually feasible, and me pointing out that it's just a little heap feng shui work that any agentic LLM will find out by themselves ...
Here we go, 12 hours later, end-to-end exploit of an index.php that echoes "ok" and nothing more. Pinned PHP versions, reproducible containers for each of the CVE and exploit path/killchain variants and everything.
php.ini set intentionally to defaults. max_input_vars set to defaulted value of 1000 so it's actually harder to exploit than with a higher value.
Implemented using my Exocomp agentic environment, and my post-trained Qwen3.8 27B model that I trained on reasoning traces of DeepSeek v4 Pro. All on my github, needs a single 48GB Radeon VRAM GPU for training/inference via Vulkan (before someone claims it's too expensive).
Wake up folks, your assumptions about what is hard to do and what is not is the wrong rationality here. Humans are sequential beings, therefore we think that a lot of tasks are harder to achieve. But that's not the correct metric.
Heap Feng Shui work is gruntwork, therefore LLMs are better and faster at this than any human could ever be.
Hi, you haven't looked at the code in your exploit.
Take a look at the php files you're shipping with your "stock" server - theyre pretty contrived, no? fatal.php? producer.php boom() str repeat X 32?
You use that to get the constants for the RCE, but without that information you're in trouble. How transferrable are these constants? Do they work with any config changes?
Again, the vuln is real and you should patch, but an exploit is not easy; this is not log4shell/heartbleed etc.
> Hi, you haven't looked at the code in your exploit.
No, I did. But thanks for leading with an offensive comment, makes reading the rest much more enjoyable /s
> Take a look at the php files you're shipping with your "stock" server - theyre pretty contrived, no? fatal.php? producer.php boom() str repeat X 32?
> You use that to get the constants for the RCE, but without that information you're in trouble. How transferrable are these constants? Do they work with any config changes?
Yes, they work with changes. The point is that you have to use a container to have a reproducible memory layout that you can target. And that _is_ known and _is_ reproducible.
It's not that hard to find out which OS images or which PHP version you're running on the server, there's plenty of well working scanning tools (e.g. projectdiscovery).
And this is setting aside that 99% of servers probably run standard versions of Ubuntu or Debian combined with the distribution packages of Magento, Wordpress, etc. And those are also reproducible in their memory layout, hosting setup, built package versions, etc.
Just as a disclaimer because I know where this is going: No, I didn't target muslc. Because most operating systems still don't use it, and that's the actual problem here we should discuss here.