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.
zkldi•29m ago
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.
cookiengineer•19m ago
> 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) on GitHub ... in case you still think this is somehow "a secret" for the attacking party.
(and this is setting aside that 99% of servers probably run standard versions of Magento, Wordpress, etc, which are all reproducible in their hosting setup, built package versions, etc, because again this is not a secret, it's publicly available information and easy to build a victim and test container with those packages)
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.
cookiengineer•56m ago
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.
zkldi•29m ago
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.
cookiengineer•19m ago
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) on GitHub ... in case you still think this is somehow "a secret" for the attacking party.
(and this is setting aside that 99% of servers probably run standard versions of Magento, Wordpress, etc, which are all reproducible in their hosting setup, built package versions, etc, because again this is not a secret, it's publicly available information and easy to build a victim and test container with those packages)
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.