zbyszkok/cve-2025-49844-redishell-ai-made-revshellUntested completition of the Redishell PoC made by AI
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。
请仔细阅读：我们说的是，根据我们目前所知/所见。这不是绝对的说法，可能还有我们未考虑到的诀窍，毕竟有更厉害的二进制利用专家在。
注意Redis服务器保持稳定——我们将它从Docker中取出进行测试。可以通过连续发送数千次exploit来触发崩溃，我们尚未尝试将此暴力方法结合代码执行尝试，这可能是解决方案。
如你所见，原始PoC似乎也面临同样的问题，它自称是“简化版”，但并未完全清楚预期的结果是什么。
尚无进展...
$ while redis-cli -h localhost -p 6380 --eval korean.lua; do printf '.'; done
神秘的是，在Redis的补丁说明中，列出了一个完全不同的CVE——也被认为是二进制漏洞，但更简单，是一个基于栈的缓冲区溢出，可能实现RCE：
XACKDEL中的错误可能导致栈溢出和潜在的RCEhttps://github.com/redis/redis/compare/8.2.2...8.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.
看起来很眼熟？我不知道他们在那里做了什么……或者除了我没有人检查过？最近这个世界变得越来越奇怪了。