HN

Comments (51)

• Menu

  xx_ns
  "No successful PHP2Shell exploits seen so far"... in the wild, specifically in Wiz's honeypot. The vulnerability itself has been successfully exploited, most notably for the "Steal my Bitcoin" challenge [1] as one example.Dan Guido, of Trail of Bits, claims they have an "universal" exploit [2]. Knowing their track record, I don't currently have a reason to doubt this claim.[1]: https://stealmybitcoin.com/[2]: https://news.ycombinator.com/item?id=50226010EDIT: The HN title has been changed since posting this comment.
• denysvitali
  > but these scanners did successfully exploit Adel Karimi's honeypot, which was a likely contributing factor to CISA’s decision to include PHP2Shell in their KEV list.Adel is doing an amazing job. Both in open source (https://github.com/perplexityai/bumblebee, https://github.com/perplexityai/numbat, https://github.com/0x4D31/galah) and with his reports.So proud of him!
• Menu

  pizlonator
  This is all it takes to port PHP to Fil-C and according to our tests this turns all of the exploits into DoShttps://github.com/pizlonator/fil-c/blob/deluge/projects/php...
• Menu

  rprouse
  And at the same time Bleeping Computer is saying it has been successfully exploited, https://www.bleepingcomputer.com/news/security/php2shell-sec...
• CircuitsFit44
  For teams still working through the patching, the practical first step is an inventory of which internet-facing hosts and containers actually run an affected PHP version, since that list is often incomplete. Patching also does not remove anything already planted, so on exposed hosts it is worth checking web roots and upload directories for new or modified PHP files and reviewing access logs from before the patch date. Honeypot data showing few successful attempts is a useful trend signal, but it says little about whether your own servers were hit.
• paaloeye
  Everyday is a zero-day nowadays
• 6_7
  I'm so sorry, exposure is down how many percent?
• makmanalp
  This has been my hyperfixation for the last few days, and I've been trying to keep together a detailed and timestamped timeline of the evolving situation:https://claude.ai/artifact/5cZex56WutyVnpMBrWXxzVTLDR is multiple entries that show successful exploitation against particular setups (quite often honeypots that were kinda set up to be exploitable e.g. single worker mod_php or lab setups that are unclear on how well they match real deployments), one claim from dan guido / trail of bits about a broad exploit (but few details), millions of attempts in the wild but very little evidence of actual compromise (unit 42 withdrew theirs).
• larahawkinsauth
  Great Breakdown
• jehykyle
  [flagged]
• Menu

  EGreg
  A lot of PHP environments were set up years ago, and run versions below PHP 8.1. If they don’t do something, eventually, they might be exploited, and turned into botnets or worse. A lot of the old PHP forums and other websites might get back door doors and impersonate people, etc.I developed a proxy that sanitizes input before it reaches PHP. I had to put it together quickly, but since then, I’ve made it a lot more user-friendly, including PHP installation scripts that automatically scan your Web server configuration, and suggest exactly how to install the proxy. The proxy itself is written in C, and I recommend running it under a Linux user that has absolutely no file permissions. All it’s supposed to do is transform input into safe output. I would argue that this proxy might even be safer than the patch, because it might prevent other vulnerabilities that researchers haven’t found yet.It’s just a generally good idea to sanitize input before it reaches your app servers anyway. But if you are running and older PHP environment, I don’t think there are any other good options than this…https://github.com/Qbix/proxy
• anon
  undefined
• Menu

  phplovesong
  PHP just sucks so bad.