用友漏洞地址

用友的用友漏洞地址这事儿，圈内人其实都心照不宣。漏洞真正危险的地址从来不是那个公开的URL，而是用友你根本不知道它藏在哪里。

去年帮一家制造企业做安全审计，漏洞他们的地址用友NC系统跑着财务和供应链，对外只开了一个443端口。用友我顺着常规路径扫了一遍，漏洞没发现异常。地址但当我试着访问/servlet/~ic/com.ufida.web.action.ActionServlet这个老接口时，用友服务器直接吐出了一段堆栈信息——版本号、漏洞中间件类型、地址甚至数据库连接池的用友报错都清清楚楚。那一刻我就知道，漏洞这台机器等于裸奔。地址

用友的漏洞地址有个特点：它们往往不是独立的页面，而是藏在业务功能背后的“暗门”。比如/fs/目录下的文件上传接口，比如/u8cloud/的任意文件读取，再比如那个著名的/ServiceDispatcherServlet——这玩意儿能直接让你未授权调用后台服务。你从百度上搜“用友漏洞”，出来的多半是CNVD的编号，但真正有用的，是那些在GitHub上被反复fork的POC脚本里写死的路径。

有一回我拿到一个样本，攻击者利用的是/api/file/upload这个接口。他传了个伪装成图片的JSP马，后缀改成.jpg，但内容里带着<%Runtime.getRuntime().exec()%>。用友的系统居然没校验文件内容，直接把它存到了/webapps/下面。然后攻击者访问http://目标:8080/upload/xxx.jpg.jsp——注意，这个地址在官方文档里根本不存在，它是临时目录拼接出来的。但系统就这么执行了。

更麻烦的是，用友的补丁更新节奏跟不上漏洞披露速度。我记得2023年上半年曝出的/servlet/FileReceiveServlet反序列化漏洞，官方修复包拖了快两个月才出。期间网上已经有人把利用链写得明明白白，连payload都给好了。你没法指望每个运维都盯着安全社区，大部分企业连日志都没开全。

所以我的建议很直接：别去记那些具体的漏洞URL，没用。你得先摸清自家系统到底暴露了多少个端点。用友的安装目录里有个web.xml，里面列了所有Servlet映射——把那些带servlet、api、upload关键词的路径全揪出来，挨个测试是否需要认证。我见过太多企业只封了/admin，却忘了/service目录下还挂着一堆没设权限的接口。

另一个容易被忽略的地址是/console。用友的中间件管理控制台默认端口是8080，如果管理员没改初始密码（admin/admin），那你连登录界面都不用绕，直接进去就能部署war包。这比任何漏洞都高效。

最后说句掏心窝子的：漏洞地址是死的，人是活的。你花一晚上研究那些路径，不如花十分钟确认一下防火墙规则里有没有放行/upload目录的写权限。安全这行，永远在跟“懒惰”赛跑——不是攻击者懒，是防守方太懒。

本文地址：http://www.79wt.cn/news/754b1299233.html