kindeditor编辑器漏洞

2017年冬天，编辑一个做企业站的器漏朋友半夜给我打电话，说网站被挂马了。编辑我登上服务器一看，器漏根目录多出个upload_json.php，编辑内容就一行——接收POST参数，器漏直接move_uploaded_file。编辑这文件不是器漏他写的。翻日志，编辑攻击者从/kindeditor/php/file_manager_json.php进来的器漏，路径明晃晃挂在URL里，编辑连伪装都懒得做。器漏

KindEditor这个编辑器，编辑国内做站的器漏人太熟了。开源、编辑轻量、中文文档齐全，2010年前后几乎成了CMS标配。问题就出在它“太方便”上——为了方便演示，官方包里的php/upload_json.php和php/file_manager_json.php默认就带着，而且默认配置几乎不设防。你下载解压，往服务器一扔，路径都没改，攻击者用扫描器跑一遍/kindeditor/php/upload_json.php，就能直接往你服务器写文件。

漏洞的核心不在编辑器本身，在那些“示例文件”。upload_json.php里有个$save_path变量，默认是../../attached/，但很多开发者直接把它改成网站根目录，或者更糟——保留默认相对路径却不做任何后缀白名单。攻击者上传一个shell.php，Content-Type改成image/jpeg，后端只检查了$_FILES['imgFile']['type']，这玩意儿客户端随便伪造。文件落地，路径可猜，直接访问，服务器就姓了别人的姓。

我后来专门扫过一批站。用FOFA搜kindeditor/php/upload_json.php，结果里至少三成页面直接返回{ "error":0,"url":"..."}，意思是接口活着，而且没鉴权。更离谱的是有些站把编辑器目录放在/static/kindeditor/下，上传目录也设在同层，攻击者传完马，URL就是/static/kindeditor/attached/shell.php，连目录遍历都省了。

有人觉得这事怪KindEditor官方。官方其实在4.1.5之后加了$php_upload_max_size和扩展名检查，但默认配置文件upload_json.php里那段in_array($file_ext, $ext_arr)的判断，很多老版本压根没有。更麻烦的是，大量CMS把KindEditor二次打包，改了路径、改了变量名，却忘了删示例文件。你搜“KindEditor 漏洞”，出来的文章十篇有八篇在讲XSS，真正要命的文件上传反而被一笔带过。

修复这事其实不复杂。第一，生产环境直接删掉php/、asp/、jsp/这些示例目录，一个不留。第二，如果非要用自带上传接口，把upload_json.php里的$ext_arr改成白名单，只留jpg|png|gif，并且用getimagesize()验证真实图片类型。第三，上传目录设成不可执行——Nginx里加location ~* /attached/.*\.(php|php5|phtml)$ { deny all; }，Apache用.htaccess关掉php_flag engine off。这三步做完，99%的脚本小子就进不来了。

但现实是，我去年帮一个客户做应急，发现他们用的还是KindEditor 4.1.4，上传接口没鉴权，目录可执行。问运维，运维说“这编辑器是外包公司五年前装的，没人敢动”。你看，漏洞从来不只是技术问题。一个2013年就被公开的利用方式，到2024年还在被批量扫描，说明什么？说明大量站点的技术债根本没还，而攻击者比运维更勤快。

最后说个细节。KindEditor的GitHub仓库最后一次commit停在2021年，作者早就不维护了。但国内各种下载站还在推“KindEditor最新版”，压缩包里照样带着php/upload_json.php。你下下来直接用，等于在服务器上开了个后门。别问我是怎么知道的——我帮人擦过太多次屁股了。