Comment by tkz1312

7 hours ago

wasn't it setup in an unexploitable configuration (not actually serving a php page IIRC?) for most of the time, and then got popped within like 2 hours once fixed?

11 comments

tkz1312

Reply
lifeisloving  7 hours ago

The point is, under normal configurations when you're serving the PHP server correctly with table-stakes best practices the server is not exploitable

This was not a scary vuln at all.

  • literalAardvark  4 hours ago

    Under normal configurations the server is highly exploitable.

    It's a horrible vuln and I don't understand what's with all the flat infosec society coming out of the woodwork.

    The challenge server had vibe coded infra that made it hard or impossible to hack, but it was a configuration that can't be used in production and no one uses ( it was deployed as a PHP static content server instead of a dynamic site generator )

    • pixl97  3 hours ago

      >I don't understand what's with all the flat infosec society coming out of the woodwork.

      Ha, while most of these are probably humans that are just being driven mad by AI, I wonder how long before we get AI driven botnets that try to under play any security vulns to give them more time to take over and collect assets for themselves?

  • Urd-  6 hours ago

    Normal configuration of a PHP server is to not run any PHP code and serve a static html file?

    • lifeisloving  5 hours ago

      Where is all the evidence of exploits if most of the webs PHP servers were vulnerable?

      This is a seperate chained exploit itself, seemingly executed by a nation stae. There are thousands of exploits infiltrating web servers around the world daily, and they arent php2shell.

      You only care about this because it falls into a weird viral narrative about "AI saftey".

      3 replies →

  • cowlevel  6 hours ago

    Which best practices did you use to prevent exploitability?

    And would you stake your bitcoin on it?