dajneem23/CVE-2025-49844

# CVE-2025-49844 RediShell 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 Server 保持稳定——我们将其从 docker 中拉出进行测试。你可以通过连续几千次发送漏洞利用来触发崩溃，但我们还没有尝试将这种暴力方法与代码执行尝试结合起来，这可能是解决方案。  ## 原始 PoC 如你所见，原始 PoC 似乎也存在同样的问题，它声称是"简化版"，但完全不清楚结果应该是什么。  ## 韩国分析片段 暂无进展... ``` $ while redis-cli -h localhost -p 6380 --eval korean.lua; do printf '.'; done ```  ## 故事继续... 奇怪的是，在 Redis 补丁说明中，列出了一个完全不同的 CVE——也是一个所谓的二进制漏洞利用，但更简单，一个带有预期 RCE 的栈缓冲区溢出： #### CVE-2025-62507 - `XACKDEL` 中的 Bug 可能导致栈溢出和潜在 RCE https://github.com/redis/redis/compare/8.2.2...8.2 我们找到的相关信息更少。已经很难找到一个未 backport 的版本，可能需要自己编译，但那可能是我们必须走的路。 所有这些"潜在"——我有潜力。现在我有两个潜力。 ## 确实会崩溃！ 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. ``` 看起来眼熟？不知道他们做了什么...或者除了我之外没人检查过？最近世界变得越来越奇怪了。

标签：CISA项目, CVE-2025-49844, GDB调试, Go语言工具, Lua脚本, PoC, Redis, RediShell, rizin, 二进制漏洞, 代码执行, 反弹Shell, 堆漏洞, 开放策略代理, 搜索引擎查询, 暴力破解, 漏洞分析, 路径探测, 逆向工具