Observations from Running stealmybitcoin.com

本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

Observations from Running stealmybitcoin.com

Observations from Running stealmybitcoin.com Oct 30, 2026 Security Table of Contents Last week, I saw an article on the front page of the New York Times website reporting that a critical vulnerability in PHP had been found. The article, and others like it, claimed any attacker could achieve arbitrary remote code execution on any of the millions of running PHP services worldwide simply by sending a few unauthenticated web requests that exploited the PHP2Shell vulnerability.

运行 stealmybitcoin.com 的观察结果 2026 年 10 月 30 日 安全 目录 上周，我在《纽约时报》网站头版看到一篇报道，称发现了一个 PHP 关键漏洞。该文章及其他类似报道声称，任何攻击者只需发送几个未经身份验证的 Web 请求来利用 PHP2Shell 漏洞，即可在全球数百万个运行中的 PHP 服务上实现任意远程代码执行。

My office Slack was buzzing, as were several of my Signal chats with colleagues and friends across the security community. Rumors swirled about how in-the-wild exploitation caused one tech company to break embargo and leak news of the vulnerability hours before the rest of the community could coordinate disclosure. That hackers were already hacking websites, in the wild, with this exploit and that every hour mattered to get the patches rolled out across 70% of the internet.

我办公室的 Slack 频道里议论纷纷，我在安全社区同事和朋友的多个 Signal 聊天群组中也是如此。有传言称，由于现实中的漏洞利用，一家科技公司打破了禁令，在社区其他成员协调披露之前，提前数小时泄露了该漏洞的消息。传言还称，黑客已经在现实中利用此漏洞攻击网站，且每一小时对于在互联网 70% 的范围内推广补丁都至关重要。

The Question Was PHP2Shell the hallmark of a new era whereby uplifted randos could hack any website with a few well-crafted prompts to an AI model? I looked out my window, expecting perhaps to see the dull apocalyptic glow of fires on the horizon as society collapsed in real time. Nothing. While online articles and tweets made the rounds about the eleven alarm cyberapocalypse upon us, I struggled to find any reference to a specific website that had been hacked.

问题：PHP2Shell 是否标志着一个新时代的到来，即普通人只需向 AI 模型输入几个精心设计的提示词，就能黑掉任何网站？我看向窗外，本以为会看到地平线上因社会实时崩溃而产生的暗淡末日火光。什么都没有。尽管网上充斥着关于我们正面临“十一级警报”网络末日的文章和推文，但我却难以找到任何关于特定网站被黑的参考信息。

Over the following days, a few iconoclasts had pointed out that the vulnerability was rather fiddly in practice (Elias Taylor; Lucas Luitjes) and that hacker groups, while initially quite excited by the exploit’s potential, had started to view it as impractical or difficult (KELA). Yet at the same time, the national and international press continued to cover a herculean emergency effort to hunt down and patch PHP-based websites across the internet. Rather than wait around and wonder, I decided to try to figure things out for myself. I had two fundamental questions: Was PHP2Shell actually exploitable outside of a lab environment? Would relatively unskilled attackers with access to AI and the PHP source code be able to exploit this class of vulnerability?

在接下来的几天里，一些特立独行的人指出，该漏洞在实践中相当棘手（Elias Taylor；Lucas Luitjes），而且黑客组织虽然最初对该漏洞的潜力感到非常兴奋，但已开始认为它不切实际或难以利用（KELA）。然而与此同时，国内外媒体继续报道着一场旨在搜寻并修补互联网上所有基于 PHP 的网站的艰巨紧急行动。与其坐等疑惑，我决定亲自一探究竟。我有两个根本性的问题：PHP2Shell 在实验室环境之外是否真的可被利用？能够接触到 AI 和 PHP 源代码的相对缺乏经验的攻击者，是否能够利用这类漏洞？

The Results Directly, the answers to the questions are: 1) Was PHP2Shell actually exploitable outside of a lab environment? Yes. Absolutely. The challenge winner, who has posted a writeup, exploited my server directly over an open internet connection and did so using the PHP2Shell vulnerability (e.g. he did not exploit some other vulnerability in my setup). He did this through a specially crafted exploit which targeted the specific configuration of my PHP installation and the ways in which it was set up on the server.

结果：直接回答这些问题：1) PHP2Shell 在实验室环境之外是否真的可被利用？是的，绝对可以。挑战赛的获胜者发布了一份报告，他通过开放的互联网连接直接利用了我的服务器，并且使用的是 PHP2Shell 漏洞（即他没有利用我设置中的其他漏洞）。他通过一个专门设计的漏洞利用程序做到了这一点，该程序针对的是我 PHP 安装的具体配置以及它在服务器上的设置方式。

2. Would relatively unskilled attackers with access to AI and the PHP source code be able to exploit this class of vulnerability? Not yet. Of tens of thousands of people who attempted the exploit - including in a 9 hour period when the challenge was active after the first successful solve (more on that below…) - only two managed to trigger the print-flag binary and only one, the winner of the challenge, managed to do so in such a way as to extract useful content from the application.

3. 能够接触到 AI 和 PHP 源代码的相对缺乏经验的攻击者，是否能够利用这类漏洞？目前还不能。在数以万计尝试利用该漏洞的人中——包括在首次成功破解后挑战赛持续的 9 小时内——只有两人成功触发了 print-flag 二进制文件，且只有一人（即挑战赛获胜者）成功以这种方式从应用程序中提取了有用的内容。

The Experiment The core idea was pretty simple. I’d rent a cheap VPS for a few weeks, slap a PHP website on it along with the key to a bitcoin wallet, and then wait and see if anyone managed to drain the wallet. Miraculously, the domain name “stealmybitcoin.com” was available, so I took this as a sign from the fates themselves that this experiment had the mandate of heaven. I slapped $500 of bitcoin into a clean wallet, rented a $2.50/month Debian VPS from a web hosting provider, and told Codex to make me a basic webpage and stick it on the internet with PHP.

实验：核心想法很简单。我租了一个便宜的 VPS 几周，在上面放了一个 PHP 网站以及一个比特币钱包的密钥，然后等着看是否有人能清空这个钱包。奇迹般的是，“stealmybitcoin.com”这个域名竟然可用，所以我将其视为命运的旨意，认为这个实验得到了天命。我往一个干净的钱包里存了 500 美元的比特币，从一家网络托管服务商那里租了一个每月 2.50 美元的 Debian VPS，并让 Codex 为我制作了一个基本的网页，通过 PHP 将其发布到互联网上。

I configured the server such that a single executable binary print-flag had permissions to read a flag file containing the WIF, took down my firewall, and posted the link to Hacker News to see if anyone would give the challenge a shot. Things got a little crazy from there. Within the first hour of posting, the link had climbed to the front page of Hacker News (where it stayed for essentially an entire day) and my $2.50/month VPS was under so much load I couldn’t maintain an SSH session.

我配置了服务器，使得一个名为 print-flag 的可执行二进制文件有权读取包含 WIF（钱包导入格式）的 flag 文件，关闭了防火墙，并将链接发布到 Hacker News，看看是否有人愿意尝试这个挑战。从那以后，情况变得有些疯狂。发布后的第一个小时内，该链接就爬上了 Hacker News 的头版（并在那里停留了几乎整整一天），我的每月 2.50 美元的 VPS 负载过高，以至于我无法维持 SSH 会话。

I eventually scaled my VPS up from 1 vCPU, 500 MB RAM and 10GB of disk space all the way to 2 vCPU, 4096 MB RAM, and 80 GB of SSD. Over the course of the challenge my VPS host temporarily took my site down once because they suspected it was subject to a Distributed Denial of Service attack and once because “we have determined your CPU resource utilization profile is excessive.” Additionally, due to the nature of the exploit, people were pretty continuously taking down individual PHP workers from high request load, partially successful memory exploitation attempts, and general shenanigans.

我最终将 VPS 从 1 个 vCPU、500 MB 内存和 10GB 磁盘空间扩展到了 2 个 vCPU、4096 MB 内存和 80 GB SSD。在挑战赛期间，我的 VPS 主机商曾两次暂时关闭了我的网站，一次是因为他们怀疑网站遭受了分布式拒绝服务攻击，另一次是因为“我们确定您的 CPU 资源利用率过高”。此外，由于该漏洞的性质，人们不断地导致单个 PHP 工作进程崩溃，原因包括高请求负载、部分成功的内存利用尝试以及各种恶作剧。

Eventually I managed to get things into a relatively steady state (e.g. most people could connect to the website most of the time), with regular resets and health checks standing in for true high-availability hosting. Once the link dropped off the front page of Hacker News, traffic quieted down quite a bit as well. Some Stats Due to flaky monitoring, it’s hard to get representative statistics regarding visitor count and traffic patterns. I had set up some pretty reliable logging so I could know if/when the print-flag binary was called and some best-effort logging of web request headers and payloads so I could hopefully understand what happened around that time; for the first few hours of virality, I was blowing through my logrotate configuration (for ~80MB of storage) roughly every 4 minutes thanks to the attention on the site.

最终，我设法使系统进入了一个相对稳定的状态（例如，大多数人大部分时间都能连接到网站），通过定期的重置和健康检查来替代真正的高可用性托管。一旦链接从 Hacker News 的头版撤下，流量也随之平静了许多。一些统计数据：由于监控不稳定，很难获得关于访问者数量和流量模式的代表性统计数据。我设置了一些相当可靠的日志记录，以便了解 print-flag 二进制文件是否/何时被调用，并尽力记录了 Web 请求头和有效载荷，希望能借此了解当时发生的情况；在网站走红的最初几个小时里，由于网站受到的关注，我的 logrotate 配置（约 80MB 存储空间）大约每 4 分钟就会被填满。

As a result, logs of certain PHP crashes and activity around the print-flag file were essentially complete over the duration of the challenge. Broader web request logging only covered 600-ish of the challenge’s 1,600-ish minute duration. During the 10 hours when I had reliable web request logging: Around

因此，在挑战赛期间，关于某些 PHP 崩溃和 print-flag 文件周围活动的日志基本上是完整的。更广泛的 Web 请求日志仅覆盖了挑战赛约 1,600 分钟时长中的 600 分钟左右。在我拥有可靠 Web 请求日志的 10 小时内：大约