2026年4月，Black Hat Asia 2026大会披露了一项名为“Ghost Bits（幽灵比特位）”的系统性安全威胁，直指Java生态底层编码缺陷，可让主流WAF/IDS防护形同虚设。

该风险的核心在于：安全检测链路与应用执行链路对同一输入的编码解释不一致，可能导致前置防护判定为无害，而后端执行阶段恢复为高风险语义。该问题本质属于“端到端语义不一致”而非单一组件缺陷。

1.Ghost Bits编码原理

Ghost Bits（幽灵比特）可理解为：在字符到字节的收窄转换中，被静默丢弃但影响安全语义的高位比特。

以 Java 为例：

- char 是 16 位（UTF-16 code unit）

- byte 是 8 位

- 当代码出现 (byte) ch、ch & 0xFF、write(int) 仅写低 8 位等行为时，高 8 位会被丢弃

这意味着一个 Unicode 字符在某些链路里会“退化”为另一个字节值。攻击者可利用这种差异构造“前后语义不一致”的输入：前置检测看到 A，后端执行却是 B。

2.攻击者如何利用Ghost Bits编码绕过检测

攻击者利用“高位静默丢弃”这一特性，将攻击的payload中关键ASCII字符经过精心构造的Unicode字符替换(低8位与payload保持一致)，WAF看到的Unicode字符是无害的字符，而到后端Java服务器解码时高位截断只选取低位从而还原成攻击载荷，从而绕过WAF检测，并能真正执行命令。

Ghost Bits 攻击的可怕之处在于“一穿多”——利用同一个底层缺陷，可触发多种高危攻击链：

处置优先级：高。该漏洞无需权限、无需用户交互、默认配置即可触发，且 POC/EXP 已公开，利用门槛低，修复复杂度中等。

面对 Ghost Bits 编码绕过，单纯依赖字符串特征匹配的WAF规则已力不从心。绿盟WAF早已完成针对性防御布局——不是事后补救，而是事前免疫。绿盟WAF的解决思路是：在解码层面进行语义检测，从源头消除“端到端语义不一致”。

1.产品能力现状：已默认支持Unicode Ghost Bits检测

绿盟WAF当前已支持针对 Unicode 类型 Ghost Bits 编码绕过的检测，默认配置下均已开启：

6090版本：在 Web 解码引擎中默认开启 Unicode 解码，可直接识别并告警 Ghost Bits 变形 Payload。

6081 & 6073版本：在语义分析引擎中开启 Unicode 解码后即可实现同等防护能力。

2.检测验证：实战拦截，有据可查

以 SQL 注入检测为例，绿盟WAF已完成针对性验证：

6090页面告警：

6081页面告警截图：

无论是标准 Unicode 编码还是经过 Ghost Bits 变形的 Payload，绿盟WAF均能在解码阶段完成语义还原，让隐藏的“幽灵”在到达业务系统前现形。

WAF是防线，但不是唯一防线。针对 Ghost Bits 攻击，建议从以下五个维度构建纵深防御：

1.统一输入语义：全链路固定UTF-8

全链路固定使用 UTF-8 编解码，禁止使用“自动猜编解码”。编码不一致是 Ghost Bits 攻击滋生的土壤，统一编码标准可大幅降低风险面。

2.输入规范化   白名单校验

• 在业务校验前做 Unicode 规范化（NFC/NFKC）。

• 对高风险字段（用户名、文件名、SQL相关参数、路径）实施字符集白名单。

• 明确拒绝不可见控制字符、异常混淆字符及超预期字符集。

3.数据库执行层：参数化兜底

参数化查询是防注入的最终保险。即使前端WAF被绕过，数据库层的参数化执行也能阻断攻击载荷的实际生效。

4.代码审计：排查高危写法

重点排查业务代码中的 Ghost Bits 典型写法：

(byte)ch

ch & 0xFF

baos.write(ch)

DataOutputStream#writeBytes()

应改为：String.getBytes(StandardCharsets.UTF_8) 等明确指定编码方式的安全写法。

5.网络层面：收缩攻击面

对暴露在公网的 Java 应用服务，限制访问来源，在完成代码修复前通过IP白名单、VPN等方式降低暴露面。

Ghost Bits 攻击再次证明：安全防护不能只看“表面字符”，必须深入“底层语义”。绿盟WAF通过解码层语义检测能力，已在 Ghost Bits 威胁公开前完成防御布局。面对日益复杂的绕过技术，“事前免疫”永远比“事后补救”更有价值。