AI 制作的 Revshell PoC
由 AI 制作的 Redishell PoC 的未测试完成版。
原始 PoC：
https://github.com/raminfp/redis_exploit/blob/main/exploit_poc.py
韩语部分：
https://github.com/dwisiswant0/CVE-2025-49844/blob/master/CVE-2025-49844.lua
我们后来又接入了 GDB——我们设法得到了基址，并发现了一些其他信息，但最重要的是，这似乎并不是一个简单的堆漏洞。无论我们怎么尝试，都无法实现代码执行。崩溃？可以。命令？不行。
我们对逆向已不再那么有把握，所以无法确定，但根据我们借助一些最强 AI 模型、花了数小时发现的所有线索来看，通过这个漏洞实现代码执行是不可能的（或者说一千次尝试里能成一次，但那纯粹是瞎猜）。
经过无数次尝试，我们最多也只能走到这一步：
Script attempted to access nonexistent global variable 'print' script: 67dfac1cecac4f99df897c7a0713f1d6fcef69a4, on @user_script:21.
很期待看到真正能实现代码执行的 PoC。
请仔细阅读：我们说的是，就我们目前所知/所见而言。这并不是绝对的结论，可能还有我们没想到的技巧或惊喜，外面有厉害得多的 BinEx 专家。
请注意，Redis 服务器始终保持稳定——我们把它从 Docker 中拿出来进行测试。你可以通过连续触发该 exploit 几千次来引发崩溃，而我们还没有尝试过将这种暴力破解方法与代码执行尝试结合起来，这也许就是解决方案。
如你所见，原始 PoC 似乎也面临着同样的问题，它自称是“简化版”，但完全不清楚预期的结果应该是什么。
暂无进展……
$ while redis-cli -h localhost -p 6380 --eval korean.lua; do printf '.'; done
神秘的是，在 Redis 的补丁说明中，列出了一个完全不同的 CVE——据说也是一个二进制漏洞利用，但简单得多：一个基于栈的缓冲区溢出，还可能实现 RCE：
XACKDEL 中的 Bug 可能导致栈溢出和潜在的 RCEhttps://github.com/redis/redis/compare/8.2.2...8.2
关于这个，我们找到的信息更少。在不自行编译的情况下，想找到一个未包含反向移植补丁的版本本身就很有挑战性，但也许那就是我们不得不走的路。
所有这些 POTENTIALS——我有潜力。现在我有 2 个潜力了。
62507 才是正道……虽然还没有 RCE，但看起来简单又有希望……
那么 CVE-2025-49844 只是个骗局吗？韩语拼图至今仍未产生崩溃——但针对我们自己编译的 8.2.2，它产生了完全不同的输出。不得不承认，连我也不禁开始想“是啊，崩溃，非常合理，可能很容易……”，然后就想当然地认为 CVE-2025-49844 的崩溃部分是有效的。但它从来没有崩溃过。抱歉之前说错了，但希望现在这事已经清楚了。CVE-2025-49844 不会崩溃，CVE-2025-62507 才会崩溃。
.(error) ERR user_script:16: Script attempted to access nonexistent global variable 'newproxy' script: 859491190bfb66357ec83aee16eb0554967c9c38, on @user_script:16.
看起来很眼熟吧？我不知道他们在那里做了什么……还是说除了我之外根本没人检查过？最近这个世界变得相当奇怪了。