CVE-2026-102508 Apache PLC4X OPC UA 驱动签名与证书校验缺陷
影响中间人可冒充 OPC UA 服务器，读取、伪造或篡改安全通道流量并窃取用户凭据
Apache PLC4X（PLC4J）的 OPC UA 驱动在加密签名校验与服务器证书验证上存在缺陷，处于客户端与服务器之间网络位置的攻击者可冒充 OPC UA 服务器。该缺陷在不同版本中表现不同：0.9.0 至 0.11.0 中签名校验失败仅记录日志而不阻断，且不验证服务器证书；0.12.0 至 0.13.1 中签名校验逻辑被反转，且默认不校验证书信任链。所有受影响版本默认安全策略均为 None，攻击者可借此读取、伪造或修改安全通道流量，包括客户端发送的用户凭据。
影响范围
受影响组件为 Apache PLC4X（PLC4J）的 OPC UA 驱动，涉及版本 0.9.0 至 0.11.0 以及 0.12.0 至 0.13.1；其他版本是否受影响暂无公开信息。
漏洞详情
漏洞类型为加密签名验证不当与证书校验不当。成因在于驱动未正确强制校验消息签名，且未对服务器证书建立信任锚验证，部分版本甚至将签名校验结果反转。利用方式是攻击者位于客户端与服务器之间的网络路径上，冒充 OPC UA 服务器与客户端建立安全通道，从而读取、伪造或篡改流量并获取用户凭据。
利用条件与风险
利用前提是攻击者具备客户端与服务器之间的网络中间人位置，且目标使用默认安全策略 None 或较弱策略。实战中可导致凭据泄露与通信被篡改，风险较高；仅检查单一机制的用户可能误判为不受影响。
修复建议
建议升级至官方修复版本，并显式配置强安全策略与证书信任锚，避免使用默认的 None 策略。临时缓解措施包括在网络层限制中间人访问、启用并强制校验签名与服务器证书；具体修复版本与官方补丁信息暂无公开信息。
Improper Verification of Cryptographic Signature and Improper Certificate Validation in the OPC UA driver of Apache PLC4X (PLC4J) allows an attacker in a network position between client and server to impersonate the OPC UA server and to read, forge or modify secure-channel traffic, including user credential ssent by the client.
The defect manifests differently depending on the version:
– In 0.9.0 through 0.11.0 a failed message-signature check is only logged and never enforced, and there is no mechanism to verify the server certificate: it is taken from the unauthenticated GetEndpoints discovery response and used to encrypt the user’s password.
– In 0.12.0 through 0.13.1 the signature check is inverted (valid signatures are rejected, invalid ones accepted), and server certificates are accepted without a trust anchor by default.
– In all affected versions the default security policy is None. Starting with 0.12.0 the driver additionally continues silently at a weaker security policy than the one configured, and starting with 0.13.0 endpoint selection prefers the weakest matching endpoint.
Users checking only for one of these mechanisms may wrongly conclude they are unaffected.
This issue affects Apache PLC4X: from 0.9.0 before 1.0.0.
Users are recommended to upgrade to version 1.0.0, which fixes the issue. Version 1.0.0 verifies message signatures correctly, refuses to connect unless the server certificate can be verified against a configured trust store or pinned certificate, defaults to Basic256Sha256 with SignAndEncrypt, and fails the
connection if the negotiated security policy is weaker than the configured one.