Pinned Tweet
Where to find me:
🔴 Hacking Videos: youtube.com/LiveOverflow
📜 Articles: liveoverflow.com
💻 Start Hacking? liveoverflow.com/start-hacking
🥰 Support: liveoverflow.com/support
📹 2nd Channel: youtube.com/LiveUnderflow
🤳 Instagram: instagram.com/liveoverflow
🔴 Hacking Videos: youtube.com/LiveOverflow
📜 Articles: liveoverflow.com
💻 Start Hacking? liveoverflow.com/start-hacking
🥰 Support: liveoverflow.com/support
📹 2nd Channel: youtube.com/LiveUnderflow
🤳 Instagram: instagram.com/liveoverflow
15
108
662
Preliminary result of my "realistic traffic" php2shell benchmark with `nginx -> Apache (15 workers) + mod_php` and PHP 8.4.26.
This setup is interesting, because reverse-proxies are common, and you cannot control the worker you are going to reach.
- Blue: success rate of the mems rate of command execution.
- x-axis: requests/s benign traffic in parallel
Everything is default config, except Apache with 15 workers (default 150). I lowered it, because I wanted it to be easier to saturate the workers with the traffic.
With 100req/s traffic on 150 workers, the exploit still had 100% success rate. With 15 workers, it starts to drop to 94%.
Traffic is being generated on the host itself directly, to avoid it looking like a DoS attempt over the network. But the exploit is being executed on my laptop to the remote host, so we don't have any advantage with low ping (we need to wait for the cookie leak, before sending the next stage).
The exploit uses a fanout strategy, throwing 15 requests per stage (so 60 in total). For 150 workers it would be 600 requests.
This setup is interesting, because reverse-proxies are common, and you cannot control the worker you are going to reach.
- Blue: success rate of the mems rate of command execution.
- x-axis: requests/s benign traffic in parallel
Everything is default config, except Apache with 15 workers (default 150). I lowered it, because I wanted it to be easier to saturate the workers with the traffic.
With 100req/s traffic on 150 workers, the exploit still had 100% success rate. With 15 workers, it starts to drop to 94%.
Traffic is being generated on the host itself directly, to avoid it looking like a DoS attempt over the network. But the exploit is being executed on my laptop to the remote host, so we don't have any advantage with low ping (we need to wait for the cookie leak, before sending the next stage).
The exploit uses a fanout strategy, throwing 15 requests per stage (so 60 in total). For 150 workers it would be 600 requests.
3
0
22
2,411
I think `nginx -> Apache+mod_php` is a really good one and very representative. But is there a particular server setup or config you would like to see tested? Feel free to send me a Gist describing a server test setup, and I might give it to agent and run it.
If you keep yel, I have to disappoint you. I have not looked at it yet... Once everybody agrees that Apache+mod_php is so easy, that you are also wondering why the fuck the mass exploitation is not happening, then I can move on.
Also I am just leavin the screenshot from Calif's @lcfr_hax blog. There is even a leakless exploit version for at least a php-fpm exploit targeting WordPress.
If you keep yel, I have to disappoint you. I have not looked at it yet... Once everybody agrees that Apache+mod_php is so easy, that you are also wondering why the fuck the mass exploitation is not happening, then I can move on.
Also I am just leavin the screenshot from Calif's @lcfr_hax blog. There is even a leakless exploit version for at least a php-fpm exploit targeting WordPress.
1
0
2
703
LiveOverflow 🔴 hextree.io retweeted
We noticed some concerning behaviour in a popular open source model.
It’s either an incidental relic from training or an intentional ‘call home’ mechanism. Either way it’s surprising and highlights the significance of how you choose which models to use.
It’s either an incidental relic from training or an intentional ‘call home’ mechanism. Either way it’s surprising and highlights the significance of how you choose which models to use.
While evaluating Qwen3.8-Flash-Next in a controlled sandbox environment, Cohere's research team observed something unexpected.
Asked to generate a defensive cybersecurity detection rule, the model instead inventoried aspects of the machine it was running on and attempted to upload a probe file to an Alibaba Cloud storage bucket in Beijing. Notably, the model's reasoning trace stated that it would not invoke any tools before taking these actions.
Cohere's sandbox blocked the attempt, and no external communication succeeded. We have not determined the root cause, and we are not asserting malicious intent.
But the incident raises important questions for organizations deploying agentic AI systems: Can models take actions that differ from their stated reasoning, and how should security teams evaluate trust, provenance, and behavior in open-weight models?
We are publishing our findings because organizations making model adoption decisions deserve as much information as possible. We hope this contributes to greater transparency, stronger security practices, and continued collaboration across the AI ecosystem.
Read the full report: cohere.com/blog/concernin…
73
61
1,301
155,354
LiveOverflow 🔴 hextree.io retweeted
php2shell is one of the most impactful bugs in recent times, yet threat actors aren’t mass exploiting it
the bug is so complex that even porting the exploit between targets takes serious skill, human or ai
so i benchmarked how well open and frontier models can do it. 🧵
the bug is so complex that even porting the exploit between targets takes serious skill, human or ai
so i benchmarked how well open and frontier models can do it. 🧵
34
46
482
36,853
I think @hextreeio accidentally became the sponsor of the first good public php2shell exploit 🙈
5
9
246
11,988
See my video how that happened:
youtube.com/watch?v=VhNiMW…
youtube.com/watch?v=VhNiMW…
0
4
26
3,368
LiveOverflow 🔴 hextree.io retweeted
Hello everyone! I know this is not LinkedIn, but I'm searching for an offensive security position worldwide. I have found and exploited many vulnerabilties in the latest years.
You can read about my work at berardinellidaniele.com
You can read about my work at berardinellidaniele.com
1
5
21
2,482
A few more days have passed and my php2shell exploit starts to get really good...
Here is how StealMyBitcoin challenge was solved. And what does it actually tell us?
youtube.com/watch?v=VhNiMW…
Here is how StealMyBitcoin challenge was solved. And what does it actually tell us?
youtube.com/watch?v=VhNiMW…
5
11
181
9,893
My php2shell videos and tweets are sponsored by @thsottiaux Codex resets. thank you for supporting small creator 🥰
3
0
76
5,347
LiveOverflow 🔴 hextree.io retweeted
Congrats to @killa who solved stealmybitcoin.com hours ago but I screwed up which key went on the server (the flag was a root wallet WIF instead of the branch WIF).
Check out their awesome writeup here: github.com/KillaBoi/Steal…
Check out their awesome writeup here: github.com/KillaBoi/Steal…
42
217
2,033
500,228
stealmybitcoin was just solved by @killa. Or rather solved a few hours ago. He was confused because the wallet address was wrong. Turns out the server didn't have the right wallet :P
I took a closer look at the stealmybitcoin.com CTF, which aims to demonstrate that PHP2SHELL is not realistically exploitable. So I gave it a try.
Note: My analysis could be wrong, and I'm more than happy to be proven otherwise.
Here’s what I found:
• The server responds X-Powered-By: PHP/8.4.26.
• My differential fingerprinting scanner independently confirmed at least PHP 8.2+
• Hypotheses: I considered two possible setups:
◦ nginx → PHP-FPM
◦ nginx → Apache → PHP-FPM/mod_php
• After comparing the server's behavior against local test environments, the closest match appears to be nginx → PHP cli-server.
Plot twist: the response behavior is consistent with the PHP cli-server serving a static index.html rather than an index.php. If that's indeed the case, the challenge appears to be intentionally made unexploitable.
My conclusion (for now) is that I'm questioning whether this is a good-faith challenge.
Happy to be corrected if I've missed something!
43
48
783
129,163
And here are my exploiters hoping for the server to be available T_T sad.... I was so close.
1
1
81
13,657
I have now a super reliable fast exploit against PHP 8.4.26 with: nginx -> php -S
I hope you are not running this realistic deployment in production 🙃
I hope you are not running this realistic deployment in production 🙃
2
1
103
12,082
I took a closer look at the stealmybitcoin.com CTF, which aims to demonstrate that PHP2SHELL is not realistically exploitable. So I gave it a try.
Note: My analysis could be wrong, and I'm more than happy to be proven otherwise.
Here’s what I found:
• The server responds X-Powered-By: PHP/8.4.26.
• My differential fingerprinting scanner independently confirmed at least PHP 8.2+
• Hypotheses: I considered two possible setups:
◦ nginx → PHP-FPM
◦ nginx → Apache → PHP-FPM/mod_php
• After comparing the server's behavior against local test environments, the closest match appears to be nginx → PHP cli-server.
Plot twist: the response behavior is consistent with the PHP cli-server serving a static index.html rather than an index.php. If that's indeed the case, the challenge appears to be intentionally made unexploitable.
My conclusion (for now) is that I'm questioning whether this is a good-faith challenge.
Happy to be corrected if I've missed something!
Note: My analysis could be wrong, and I'm more than happy to be proven otherwise.
Here’s what I found:
• The server responds X-Powered-By: PHP/8.4.26.
• My differential fingerprinting scanner independently confirmed at least PHP 8.2+
• Hypotheses: I considered two possible setups:
◦ nginx → PHP-FPM
◦ nginx → Apache → PHP-FPM/mod_php
• After comparing the server's behavior against local test environments, the closest match appears to be nginx → PHP cli-server.
Plot twist: the response behavior is consistent with the PHP cli-server serving a static index.html rather than an index.php. If that's indeed the case, the challenge appears to be intentionally made unexploitable.
My conclusion (for now) is that I'm questioning whether this is a good-faith challenge.
Happy to be corrected if I've missed something!
89
98
2,192
568,015
I got confirmation that the original version just had an index.html. So there never was any php code executed hahaha.
But they added now an actual .php file (like 18h after they started the challenge. So the 21 hours without successful hack is misleading)
Now it should be ourse it’s incredibly hard to do so when the service gets hammaered and crashing like crazy. Keep in mind, tons and tons of php service don’t get hammered like this. So if somebody gets it now, then that’s actually crazy!
But they added now an actual .php file (like 18h after they started the challenge. So the 21 hours without successful hack is misleading)
Now it should be ourse it’s incredibly hard to do so when the service gets hammaered and crashing like crazy. Keep in mind, tons and tons of php service don’t get hammered like this. So if somebody gets it now, then that’s actually crazy!
12
8
226
30,732
LiveOverflow 🔴 hextree.io retweeted
This is baffling to me. Even though it's only exploitable against the management interface, the whole reason threat actors target these appliances is because those interfaces are too often reachable.
‼️ Palo Alto confirms the PHP2Shell code execution flaws hit the management interface of its PAN-OS firewalls and Panorama.
It says it knows of no exploitation. Hotfixes are due 26 to 30 October.
Kevin Beaumont expects them "after they’ve finished scratching their arse."
3
2
16
3,583