This looks like a trap. We have a working RCE that would claim this, but I don't want to demonstrate that because it might leak what we built to others. We still have a window for people to patch and I don't want to risk that.
Seems like everyone here has an exploit but they're all busy washing their hair, or thinking of the children, or making huge amounts selling their exploit on the darknet instead.
Given there are public patches and explanations of the issue, isn't it a little late to try to keep this under wraps?
Over a day or two we'll see whether people have an exploit - if more than a few people do, someone will claim this $1k soon. Out of curiosity, what do you plan to do with your exploit that you're holding back?
I think there's still going to be a massive long tail of sites that will never be protected or upgraded, unfortunately that's the reality. So no amount of delay will help them, and most active sites will have patched by now after 5 days.
There are already many people claiming they have an exploit, some in this thread, I think this is a useful measure of just how easy it is - thankfully it doesn't look too easy as it's still up at time of writing, though surely someone will manage it soon.
If it does get taken quickly I think that's useful information on just how serious this is.
If it doesn't, that's also useful info though not hard proof there is no exploit. It does mean that there is no exploit in the hands of script kiddies with chatgpt or similar.
Shared host Wordpress sites basically run in unprotected untrusted mode since WP has so many RCEs already and they can be in any random plugin someone adds at any time. So even if there's an RCE a lot of these sites just shrug at the attack. You would need to figure out how to chain it for something useful.
I'm not sure what this page proves except that not all set-ups are in danger. Especially if the site does nothing and has a nginx in front that caps all requests to 1mb.
There are, afaict, at least half a dozen choices a PHP server could have made that mitigates all (known) exploits. Putting some bitcoins behind one of them isn't exactly proof of anything, except as a PR stunt to convince people PHP is not a pile of tightly coupled hot-c garbage.
---
Other projects that get CVEs talk about what went wrong and how to improve. So far i've only seen PHP people defensive and telling each other that ok because other projects also get CVEs.
But the Dutch government websites do generally (I hope) have users, which is one of the ways the "I need to hit the same php worker, uninterrupted, for about 10 to 30 seconds while absolutely no other traffic hits the site AND I can isolate the one worker from the pool" approach to exploiting fails.
Luck is not a security boundary, they should patch their servers, everyone should. It's not a good thing to have shitty memory management on your server.
However, is this really that exploitable in real world conditions? (no)
"There does not exists" and "I've not heard off" are different things. This is motivated reasoning on your part to tell the story that this isn't a big deal.
Most variants require a few requests to infer some settings, and then they can spam their arming-stage, and then their exploit stage. Granted, its not quite as easy as that, but hitting _a_ worker twice on a server once is not all that lucky.
So according to you they could have just imposed an upload cap instead and been safe? If all the cybersecurity experts had given useful advice like that earlier in the week people could have been safer and less panicked.
The only thing I read about why Dutch gov websites "went down" was as a precautionary measure against this exploit (awaiting the patch), not because they actually got hacked.
Can you link any reports about any site being afflicted by this exploit? (Dutch government website, or other)
The parent comment is implying PHP servers arent at risk, because default nginx limits requests to 1mb. I'm saying that is a bad argument, and a lot of real websites that went offline voluntarily, like the dutch gov, would have endpoints that accept >1mb requests.
Putting https://stealmybitcoin.com/ behind a default nginx proxy and giving it no features is a toy PR stunt hoping to salvage PHP's reputation.
> I think there's still going to be a massive long tail of sites that will never be protected or upgraded,
Ok? But that's super common, and there's thousands of ways to exploit unmaintained systems, nothing special about this.
From a technical level as well, this is not an easy bug to exploit, it's CVSS Attack Complexity:High, it requires a lot of per-target work, it's definitely not copy.fail level
I think we’re saying the same thing - at this stage there’s not much point in withholding details,
That’s why I brought up the sites that will
never patch - that’s normal and at some point it helps more to release more details.
But wait, weren't we all told that exploits where already happening all over the place and thats why the embargo was broken?
Cloudflare even claimed they mitigated a bunch of it.
Which is true here? There was widespread usage of this exploit prior to the patch and just after, or that there were "basically no malicious actors had exploits"?
There's a lot of smoke being blown by companies with a financial stake in coming off as "security-minded" or something.
There's apparently _some_ exploit usage in the wild before the embargo breaking, but it very much looks like they didn't even achieve RCE, or if they did it was not widespread at all. It doesn't mean it wasn't possible by a group more sophisticated, it just didn't happen thankfully.
After the embargo was broken, RCEs were still not widespread, especially not before a huge number of sites patched themselves.
So, no, the narrative that skids with agents were busting down doors as soon as the embargo was broken is not accurate. But breaking the embargo before a patch was ready only hurt the situation for defenders.
Unfortunately I left all my easy PHP exploits together with my pre-2023 writing that Pangram flags as 100% AI in Canada with my long-distance girlfriend.
It's done, anyone still talking about this is in the business of monetizing trending keywords (or crime), not in the business of cyberdefense.
Anyone that's thinking about defending basically stopped thinking professionally about this on Thursday midday when the PHP update was released and the patch was applied. Maybe on Friday we learned that there were no confirmed exploits or even theoretical exploits, so we discarded the marginal possibility of our servers being exploited stealthily and having a dormant attacker in our perimeter (it was a buffer overflow attack after all, very hard to execute).
So it's out of mind for us, it's almost saturday, the only reason to think about this anymore is to grift or to think about the social contagion angle. To many of us it was a random tuesday, business as usual, but some people are still thinking this was a somehow special event? My guess is that it was the fact that there was an embargo break and it caused some issues in that 12 hour period between the leak and the patch, but it was a nothingburger, now it just needs to die, at least after it makes its round through the content-creators whose 9 to 5 is looking at trend charts and monetizing views.
Sure, for those who could upgrade their servers in a day that's fine.
For some, it might be relevant to assess the actual risk of being exploited while you figure out how to upgrade the PHP 5.x (or 7.x whatever) stack. There are still important decisions to make when you're put into such a sucky situation: do you take the site down? do you rush the upgrade? (faster probably means more money and bugs) or is it feasible to just chill and upgrade the servers at the normal pace?
I'm glad I don't maintain anything related to PHP but sometimes you don't get to choose your circumstances.
If someone can't upgrade the php version, then they don't have other levers to pull, there's not much for them to think about, they are just not in charge.
Started a job a two weeks ago with lots of php 5 websites that can't be updated because they are abandonware and management don't want to fork out for a replacement.
I used httrack to create a static version of the site and thats whats public now. Has bought me time to talk with management and convince them of what needs doing.
Yeah, we have one legacy, abandoned PHP service that isn't readily updatable and is being replaced, so in the interim it runs fully isolated in its own VPC with only Cloudflare able to reach it to help protect it. The container runs non-root with read-only filesystem and the host has no egress allowed at all for the UID running the service (not even DNS, no new outbound traffic for that UID at at all), it can only be connected to by CF's hosts.
It has survived perfectly fine so far and is on a _very_ vulnerable PHP version based on the php2shell writeup. Management knows it could supposedly get popped at any time, and we'd have to rollback to a snapshot, spin it back up, and wait for it to get popped again. Rinse/repeat.
Well... For me it's more about seeing if I COULD have done it had I heard about it in time. The first thing I did when I heard about it was recon and found the wallet, then checked it and saw the contents are already in a pending transfer out meaning that someone already beat this particular CTF. I'm old though so for me, CTFs are still about the fun of seeing if I can.
Whether it is a trap or not doesn't change the OP's point... they are trying to push back on the idea that all servers that have this vulnerability are going to be instantly hacked by bot swarms. If AIs are at the point now where they can all instantly create an exploit from a known vulnerability, then you would have no need to keep your exploit secret because everyone would already have one.
The fact that you keeping your exploit secret means anything already proves their point.
Wrong move. Exploiting this box proves it's exploitable. Not exploiting the box makes the entire computer security profession look like a bunch of worry worts and that the consulting fees are better off not paid. At worst, the owner of the box gets... what? Working exploit code that they'll have to reverse engineer anyway?
The implication of your comment is that the exploit is not trivial and magically available to anyone with some tokens to bash together, which refutes the position that there is an horde of AI agents and people compromising sites en-masse.
Yep. I pointed an agent at the Twitter post about the "working exploit that gets a shell on an unmodified MediaWiki installation.". 5 minutes later it spins up a stock MediaWiki and proves its POC. It modified someone else's POC from Github, but that's still trivial.
Everyone knows that MediaWiki is exploitable. The story running around is exactly that this is generally exploitable even for simple apps serving static content like this.
I have a PoC generated by an LLM that can crash sites using php2shell, but crashing != RCE. The issue is that, to achieve actual RCE, recreating the RCE PoC based on the git diff of the patch and blog posts about php2shell isn't enough. You would still need to develop a working exploit chain, bypass ASLR, and so on to actually achieve RCE.
Also, this site runs Nginx with PHP-FPM, not Apache, which is harder than using mod_php exploit mode for this exploit.
So you would need to develop a working exploit chain and then essentially "burn" it by exposing it to the site owner.
In other words, someone is offering $500 for a working exploit chain.
Lots of people said the embargo should be broken early because "the exploit is already in the wild". That does not normally mean an infosec researcher has a PoC on their private laptop, that means it has leaked, one way or another.
Had it, though? If it was in the wild at day -1, surely some script kiddie will be happy to run that exploit at day +4, because if they didn't someone else would.
There were many people saying things with great confidence and this is one interesting way to gauge what was behind those words.
Yeah. Turns out you're on this Patch the Planet team, so I'm guessing there's some other things or relationships worth a tad more than $2000 that you "don't want to risk".
So an exploit that's difficult to reproduce even despite having access to the patch changes and all the insights into the vulnerability, would somehow be easier to recreate from just a few server logs?
Can you explain how the trap works? The exploit gives you access to the machine which you can then use to wipe the evidence of your intrusion - right? There is nothing to leak by taking control of the machine.
Is the trap theory that this server isn’t really running a vulnerable version of php, and is instead recording all traffic?
They can be running a vulnerable version of PHP but also recording all traffic in a way that does not allow for wiping evidence afterwards. For example, if the PHP server was behind another server routing the raw IP packets and running tcpdump. Since the author of the site controls the TLS cert private key, TLS does not protect again the author eavesdropping.
1. there's no actual evidence that the key to the wallet is on this machine at all. it would be trivial to add a service that would sign challenges to prove so
2. a working RCE against PHP is worth much more than $1000, attacking this machine would easily burn that
>it would be trivial to add a service that would sign challenges to prove so
If the author was being dishonest about the key, they could just keep the key on another secure server and have the vulnerable one forward the challenge requests to it.
Why should anyone believe you? This reminds me of that middle-school trope of responding to social challenges with claims of having a girlfriend in another country.
Because he's Dan Guido of Trail of Bits. If anyone has the exploit, it would probably be them
I think it's clear at this point that the exploit exists, but is very hard to discover even with AI. It's likely that only top security groups and nation states have it right now, no one who would care about $2,000
Your bar for what is clear and trustworthy is a lot lower than mine. Poker players bluff as a matter of course.
It’s easy to close this matter: Dan can communicate the wallet key to the contest operator out of band, and if the operator affirms, then we know it’s true (assuming they are not conspiring to deceive the public, which seems unlikely).
He doesn’t have anything that could generically target random websites and achieve shell. He may have something that works in a controlled lab environment, under specific conditions he controls. Or he might have something that relies on other, undisclosed vulnerabilities. Those things are not the same ;)
No, author says right here in this threads that it's been hardened versus default:
> For those who are saying that the nginx config is unfairly difficult, intention was just to replicate a fairly normal config that was more realistic than you'd get in a lab environment. If we get to 24 hr+ with no solves I'll see about making it easier. In the meantime, seems like you can perhaps mitigate PHP2Shell with the right nginx config, so that's pretty neat!
Assuming you do have a working RCE - this is some weird game theory. Do it and potentially leak the exploit. Don't do it and you lose control of the narrative/lose your credibility/have people not take the risk seriously anymore (this comment is losing the fight with another comment for top comment, and the other comment is concluding that yeah this proof that the whole thing was overblown).
And then there's the third option that actually this server is unexploitable or there's no wallet or something and simultaneously you give someone the exploit and lose your credibility at the same time. Really no good way out huh?
Seems like everyone here has an exploit but they're all busy washing their hair, or thinking of the children, or making huge amounts selling their exploit on the darknet instead.
Given there are public patches and explanations of the issue, isn't it a little late to try to keep this under wraps?
Over a day or two we'll see whether people have an exploit - if more than a few people do, someone will claim this $1k soon. Out of curiosity, what do you plan to do with your exploit that you're holding back?
The only reason Php2shell wasn't as bad as it could've been was because basically no malicious actors had exploits that were useful in time.
Whoever broke the embargo is a moron and it could have resulted in much more damage than was done.
I think there's still going to be a massive long tail of sites that will never be protected or upgraded, unfortunately that's the reality. So no amount of delay will help them, and most active sites will have patched by now after 5 days.
There are already many people claiming they have an exploit, some in this thread, I think this is a useful measure of just how easy it is - thankfully it doesn't look too easy as it's still up at time of writing, though surely someone will manage it soon.
If it does get taken quickly I think that's useful information on just how serious this is.
If it doesn't, that's also useful info though not hard proof there is no exploit. It does mean that there is no exploit in the hands of script kiddies with chatgpt or similar.
Shared host Wordpress sites basically run in unprotected untrusted mode since WP has so many RCEs already and they can be in any random plugin someone adds at any time. So even if there's an RCE a lot of these sites just shrug at the attack. You would need to figure out how to chain it for something useful.
I too have various websites that dont get hacked.
I'm not sure what this page proves except that not all set-ups are in danger. Especially if the site does nothing and has a nginx in front that caps all requests to 1mb.
There are, afaict, at least half a dozen choices a PHP server could have made that mitigates all (known) exploits. Putting some bitcoins behind one of them isn't exactly proof of anything, except as a PR stunt to convince people PHP is not a pile of tightly coupled hot-c garbage.
---
Other projects that get CVEs talk about what went wrong and how to improve. So far i've only seen PHP people defensive and telling each other that ok because other projects also get CVEs.
Hey, you're leaving out that nginx's default is to cap at 1m, btw.
The Dutch government websites that went down have multiple endpoints to upload files that do not have a 1MiB cap.
But the Dutch government websites do generally (I hope) have users, which is one of the ways the "I need to hit the same php worker, uninterrupted, for about 10 to 30 seconds while absolutely no other traffic hits the site AND I can isolate the one worker from the pool" approach to exploiting fails.
Luck is not a security boundary, they should patch their servers, everyone should. It's not a good thing to have shitty memory management on your server.
However, is this really that exploitable in real world conditions? (no)
"There does not exists" and "I've not heard off" are different things. This is motivated reasoning on your part to tell the story that this isn't a big deal.
Most variants require a few requests to infer some settings, and then they can spam their arming-stage, and then their exploit stage. Granted, its not quite as easy as that, but hitting _a_ worker twice on a server once is not all that lucky.
Also, 03:00 at night is not a busy time.
So according to you they could have just imposed an upload cap instead and been safe? If all the cybersecurity experts had given useful advice like that earlier in the week people could have been safer and less panicked.
That is quite literally what I said yes: https://news.ycombinator.com/item?id=50224916#50228891
Comment not found?
The only thing I read about why Dutch gov websites "went down" was as a precautionary measure against this exploit (awaiting the patch), not because they actually got hacked.
Can you link any reports about any site being afflicted by this exploit? (Dutch government website, or other)
They didn't get hacked as far as we know.
The parent comment is implying PHP servers arent at risk, because default nginx limits requests to 1mb. I'm saying that is a bad argument, and a lot of real websites that went offline voluntarily, like the dutch gov, would have endpoints that accept >1mb requests.
Putting https://stealmybitcoin.com/ behind a default nginx proxy and giving it no features is a toy PR stunt hoping to salvage PHP's reputation.
> I think there's still going to be a massive long tail of sites that will never be protected or upgraded,
Ok? But that's super common, and there's thousands of ways to exploit unmaintained systems, nothing special about this.
From a technical level as well, this is not an easy bug to exploit, it's CVSS Attack Complexity:High, it requires a lot of per-target work, it's definitely not copy.fail level
I think we’re saying the same thing - at this stage there’s not much point in withholding details, That’s why I brought up the sites that will never patch - that’s normal and at some point it helps more to release more details.
But wait, weren't we all told that exploits where already happening all over the place and thats why the embargo was broken?
Cloudflare even claimed they mitigated a bunch of it.
Which is true here? There was widespread usage of this exploit prior to the patch and just after, or that there were "basically no malicious actors had exploits"?
There's a lot of smoke being blown by companies with a financial stake in coming off as "security-minded" or something.
There's apparently _some_ exploit usage in the wild before the embargo breaking, but it very much looks like they didn't even achieve RCE, or if they did it was not widespread at all. It doesn't mean it wasn't possible by a group more sophisticated, it just didn't happen thankfully.
After the embargo was broken, RCEs were still not widespread, especially not before a huge number of sites patched themselves.
So, no, the narrative that skids with agents were busting down doors as soon as the embargo was broken is not accurate. But breaking the embargo before a patch was ready only hurt the situation for defenders.
Virtue signalling
Unfortunately I left all my easy PHP exploits together with my pre-2023 writing that Pangram flags as 100% AI in Canada with my long-distance girlfriend.
Oh, you left your other pants with her?
Yeah I had it all on a CASIO JD-6000 in the jeans pocket.
My man
I have discoverd a truly marvelous RCE which this margin is too narrow to contain.
lmao
It's done, anyone still talking about this is in the business of monetizing trending keywords (or crime), not in the business of cyberdefense.
Anyone that's thinking about defending basically stopped thinking professionally about this on Thursday midday when the PHP update was released and the patch was applied. Maybe on Friday we learned that there were no confirmed exploits or even theoretical exploits, so we discarded the marginal possibility of our servers being exploited stealthily and having a dormant attacker in our perimeter (it was a buffer overflow attack after all, very hard to execute).
So it's out of mind for us, it's almost saturday, the only reason to think about this anymore is to grift or to think about the social contagion angle. To many of us it was a random tuesday, business as usual, but some people are still thinking this was a somehow special event? My guess is that it was the fact that there was an embargo break and it caused some issues in that 12 hour period between the leak and the patch, but it was a nothingburger, now it just needs to die, at least after it makes its round through the content-creators whose 9 to 5 is looking at trend charts and monetizing views.
It’s Sunday already! (or almost Sunday, depending on your timezone)
Sure, for those who could upgrade their servers in a day that's fine.
For some, it might be relevant to assess the actual risk of being exploited while you figure out how to upgrade the PHP 5.x (or 7.x whatever) stack. There are still important decisions to make when you're put into such a sucky situation: do you take the site down? do you rush the upgrade? (faster probably means more money and bugs) or is it feasible to just chill and upgrade the servers at the normal pace?
I'm glad I don't maintain anything related to PHP but sometimes you don't get to choose your circumstances.
If someone can't upgrade the php version, then they don't have other levers to pull, there's not much for them to think about, they are just not in charge.
Started a job a two weeks ago with lots of php 5 websites that can't be updated because they are abandonware and management don't want to fork out for a replacement.
I used httrack to create a static version of the site and thats whats public now. Has bought me time to talk with management and convince them of what needs doing.
Yeah, we have one legacy, abandoned PHP service that isn't readily updatable and is being replaced, so in the interim it runs fully isolated in its own VPC with only Cloudflare able to reach it to help protect it. The container runs non-root with read-only filesystem and the host has no egress allowed at all for the UID running the service (not even DNS, no new outbound traffic for that UID at at all), it can only be connected to by CF's hosts.
It has survived perfectly fine so far and is on a _very_ vulnerable PHP version based on the php2shell writeup. Management knows it could supposedly get popped at any time, and we'd have to rollback to a snapshot, spin it back up, and wait for it to get popped again. Rinse/repeat.
Well... For me it's more about seeing if I COULD have done it had I heard about it in time. The first thing I did when I heard about it was recon and found the wallet, then checked it and saw the contents are already in a pending transfer out meaning that someone already beat this particular CTF. I'm old though so for me, CTFs are still about the fun of seeing if I can.
100% this.
Then the guy never replied, "got busy", etc. A classic here.
Whether it is a trap or not doesn't change the OP's point... they are trying to push back on the idea that all servers that have this vulnerability are going to be instantly hacked by bot swarms. If AIs are at the point now where they can all instantly create an exploit from a known vulnerability, then you would have no need to keep your exploit secret because everyone would already have one.
The fact that you keeping your exploit secret means anything already proves their point.
Wrong move. Exploiting this box proves it's exploitable. Not exploiting the box makes the entire computer security profession look like a bunch of worry worts and that the consulting fees are better off not paid. At worst, the owner of the box gets... what? Working exploit code that they'll have to reverse engineer anyway?
The implication of your comment is that the exploit is not trivial and magically available to anyone with some tokens to bash together, which refutes the position that there is an horde of AI agents and people compromising sites en-masse.
Yep. I pointed an agent at the Twitter post about the "working exploit that gets a shell on an unmodified MediaWiki installation.". 5 minutes later it spins up a stock MediaWiki and proves its POC. It modified someone else's POC from Github, but that's still trivial.
Everyone knows that MediaWiki is exploitable. The story running around is exactly that this is generally exploitable even for simple apps serving static content like this.
I have a PoC generated by an LLM that can crash sites using php2shell, but crashing != RCE. The issue is that, to achieve actual RCE, recreating the RCE PoC based on the git diff of the patch and blog posts about php2shell isn't enough. You would still need to develop a working exploit chain, bypass ASLR, and so on to actually achieve RCE.
Also, this site runs Nginx with PHP-FPM, not Apache, which is harder than using mod_php exploit mode for this exploit.
So you would need to develop a working exploit chain and then essentially "burn" it by exposing it to the site owner.
In other words, someone is offering $500 for a working exploit chain.
Lots of people said the embargo should be broken early because "the exploit is already in the wild". That does not normally mean an infosec researcher has a PoC on their private laptop, that means it has leaked, one way or another.
Had it, though? If it was in the wild at day -1, surely some script kiddie will be happy to run that exploit at day +4, because if they didn't someone else would.
There were many people saying things with great confidence and this is one interesting way to gauge what was behind those words.
Yeah. Turns out you're on this Patch the Planet team, so I'm guessing there's some other things or relationships worth a tad more than $2000 that you "don't want to risk".
https://news.ycombinator.com/item?id=50226366
So an exploit that's difficult to reproduce even despite having access to the patch changes and all the insights into the vulnerability, would somehow be easier to recreate from just a few server logs?
Can you explain how the trap works? The exploit gives you access to the machine which you can then use to wipe the evidence of your intrusion - right? There is nothing to leak by taking control of the machine.
Is the trap theory that this server isn’t really running a vulnerable version of php, and is instead recording all traffic?
The exploit gives you access to a machine, not necessarily the one terminating TLS and keeping logs.
They can be running a vulnerable version of PHP but also recording all traffic in a way that does not allow for wiping evidence afterwards. For example, if the PHP server was behind another server routing the raw IP packets and running tcpdump. Since the author of the site controls the TLS cert private key, TLS does not protect again the author eavesdropping.
really?
1. there's no actual evidence that the key to the wallet is on this machine at all. it would be trivial to add a service that would sign challenges to prove so
2. a working RCE against PHP is worth much more than $1000, attacking this machine would easily burn that
>it would be trivial to add a service that would sign challenges to prove so
If the author was being dishonest about the key, they could just keep the key on another secure server and have the vulnerable one forward the challenge requests to it.
fair
Serious question: Worth more how?
After the fact you are going to clean an append-only log on a separate box?
Why should anyone believe you? This reminds me of that middle-school trope of responding to social challenges with claims of having a girlfriend in another country.
Because he's Dan Guido of Trail of Bits. If anyone has the exploit, it would probably be them
I think it's clear at this point that the exploit exists, but is very hard to discover even with AI. It's likely that only top security groups and nation states have it right now, no one who would care about $2,000
Your bar for what is clear and trustworthy is a lot lower than mine. Poker players bluff as a matter of course.
It’s easy to close this matter: Dan can communicate the wallet key to the contest operator out of band, and if the operator affirms, then we know it’s true (assuming they are not conspiring to deceive the public, which seems unlikely).
Your comment makes zero sense. You have nothing :)
This is the CEO of ToB. It makes total sense why he'd not want to share his proof of concept.
Expand on that acronym for us
Trail of Bits is a well-known security research and audit firm
Thanks! Appreciated.
And a lead on Patch the Planet https://openai.com/index/patch-the-planet/
I can't possibly think of any conflicts of interest there.
Indeed, particularly none of the type that might be worth more than $500 (or by now, $2000).
Nobody cares. The patches are public.
He doesn’t have anything that could generically target random websites and achieve shell. He may have something that works in a controlled lab environment, under specific conditions he controls. Or he might have something that relies on other, undisclosed vulnerabilities. Those things are not the same ;)
Please don't affirm things that you perfectly know you don't know.
Don’t worry about me, what I know or don’t know ;)
I'm worried!
Do you think CEOs never lie?
Sure you do. My girlfriend is a model she just couldn’t come out tonight also. Clown.
From that latest update, your window seems to be closing now
Yeah this smells bad. Especially given the box is set up to not accept the exploit (1mb vs 12mb).
You mean the sever is setup with nginx defaults?
No, author says right here in this threads that it's been hardened versus default:
> For those who are saying that the nginx config is unfairly difficult, intention was just to replicate a fairly normal config that was more realistic than you'd get in a lab environment. If we get to 24 hr+ with no solves I'll see about making it easier. In the meantime, seems like you can perhaps mitigate PHP2Shell with the right nginx config, so that's pretty neat!
https://stackoverflow.com/questions/28476643/default-nginx-c...
That's the default though
Assuming you do have a working RCE - this is some weird game theory. Do it and potentially leak the exploit. Don't do it and you lose control of the narrative/lose your credibility/have people not take the risk seriously anymore (this comment is losing the fight with another comment for top comment, and the other comment is concluding that yeah this proof that the whole thing was overblown).
And then there's the third option that actually this server is unexploitable or there's no wallet or something and simultaneously you give someone the exploit and lose your credibility at the same time. Really no good way out huh?