Yii 1.1.29本身无官方RCE漏洞，但存在反序列化风险：显式unserialize调用、未校验Cookie、危险函数使用及反射调用等编码模式可触发RCE；缓解需禁用危险函数、强制Cookie签名、清理unserialize点并重写__wakeup方法。
Yii 1.1.29 本身没有官方发布的 RCE 漏洞（如 Yii 2.x 中的 CVE-2020-15148），但它存在已知的反序列化风险点，尤其在启用CActiveRecord、CHttpCookie或自定义unserialize()调用时，若配合可控输入（如未校验的 Cookie、GET/POST 参数、缓存数据），仍可能被构造 POP 链触发远程命令执行。
关键风险入口不依赖框架版本，而依赖代码写法
即使不升级，以下几类常见编码模式会直接引入 RCE 风险：
- 显式调用
unserialize($_GET['data'])或类似逻辑（尤其在控制器、组件初始化、日志解析等位置） - 使用
CHttpCookie且未开启validation或密钥硬编码/泄露（攻击者可伪造含恶意对象的 Cookie） - 将用户输入传入
eval()、create_function()、assert()、preg_replace('/.*/e')等危险函数 - 通过
CGridView、CListView的dataProvider或filter参数间接触发反射调用（如传入可控回调）
不升级也能落地的缓解措施
核心思路是：**切断反序列化入口 + 封堵危险函数调用 + 收紧输入信任边界**：
-
全局禁用危险函数：在
php.ini中设置disable_functions = unserialize,eval,exec,passthru,shell_exec,system,proc_open,popen,call_user_func,call_user_func_array；若无法改配置，可在入口文件（如index.php）顶部加ini_set('disable_functions', '...'); -
强制校验所有 Cookie：确保
CHttpCookie启用签名验证，检查config/main.php是否设置了'enableCookieValidation'=>true和强随机'cookieValidationKey'（不能为空或弱值如'test'） -
扫描并清理所有 unserialize 调用点：用
grep -r "unserialize(" . --include="*.php"找出所有位置，逐一确认参数是否绝对可信；不可信来源一律改用json_decode()或白名单校验后转数组 -
重写关键组件的 __wakeup() 方法：对自定义模型或继承自
CComponent的类，手动添加空的__wakeup(){throw new CException('Deserialization disabled');}，防止魔术方法被链式利用
必须检查的配置与代码细节
这些地方哪怕只漏一处，就可能让防护失效：
-
config/main.php中'components' => ['cache'=>['class'=>'CMemCache']]类型配置——如果缓存内容来自用户输入且未过滤，反序列化可能发生在底层驱动中 - 日志模块（
CFileLogRoute）是否记录了原始 POST 数据；攻击者可能通过日志注入恶意 payload，再由后台定时任务读取反序列化 - 是否启用了
debug模式（'debug'=>true）且暴露了YII_DEBUG常量；某些调试组件会动态加载类名，构成反射调用跳板
不升级框架不是问题，问题在于是否清楚自己代码里藏着多少“反序列化开关”。只要把输入校验做实、危险函数关死、签名机制配牢，Yii 1.1.29 依然可以安全运行多年。
