文章总结： 德国SICKAG工业条码读取器Lector系列被曝存在CVE-2026-2331等高危漏洞，CVSS评分最高9.8。漏洞源于HTTP接口缺失认证及测试目录未清理，攻击者可无凭据读取明文密码并远程执行代码。建议用户立即升级固件至2.8.0，或采取限制端口访问、轮换密码及监控流量等临时措施。该事件凸显了工业设备安全开发流程的缺失。 综合评分： 92 文章分类： 漏洞分析,漏洞预警,IoT安全

工厂里的条码扫描仪，正在被人悄悄读取密码

原创

CVE-SEC CVE-SEC

CVE-SEC

2026年3月8日 09:00 四川

工厂里的条码扫描仪，正在被人悄悄读取密码

2026年3月6日，德国工业巨头 SICK AG 的产品安全团队发布了一份安全公告。

公告编号 SCA-2026-0006，内含两个漏洞，CVSS 评分分别为 9.8 和 9.4，均为最高危级别。受影响的，是一款你可能在工厂流水线、机场行李传送带、物流分拣中心见过的设备——SICK Lector85x / Lector83x 系列工业条码读取器。

漏洞编号：CVE-2026-2331。

这台设备是什么

SICK AG 成立于 1946 年，是德国老牌工业自动化传感器企业，在全球超过 75 个国家有业务布局。Lector85x 和 Lector83x 是该公司旗下的图像式工业条码读取器，支持一维码、二维码的高速识别，广泛用于制造业流水线质检、机场行李分拣、快递包裹处理等场景。

这类设备不只是”扫码”那么简单。它内置了一套叫做 SICK AppEngine 的运行时框架，允许用户用 Lua 脚本语言编写自定义应用（称为 SensorApp），部署在设备上运行，实现复杂的图像处理和业务逻辑。设备通过 HTTP、EtherNet/IP、PROFINET 等工业网络协议与上位系统通信，是工厂 OT 网络中的神经末梢。

漏洞在哪里

AppEngine 提供了一个叫做 Fileaccess 的 HTTP 接口，设计初衷是让远程管理工具（如 SICK AppStudio）能够读取设备参数、部署应用包。

问题在于：这个接口没有认证。

任何能访问到设备 HTTP 端口的人，不需要账号，不需要密码，不需要任何凭据，发一个普通的 HTTP GET 请求过去，就能直接读取设备文件系统里的内容。这其中包括：

• 设备网络配置文件
• 用户自定义的密码（明文存储）
• 应用运行参数

更严重的是，这个接口不只能读，还能写。

攻击者可以用 HTTP PUT 请求，向设备的 AppEngine 应用目录写入一个 Lua 脚本。设备下次重启或触发应用加载时，这段脚本会被 AppEngine 自动执行。至此，攻击者完成了从读取密码到在设备上执行任意代码的全过程。

CVSS 向量：AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，评分 9.8。翻译成人话：网络可达、无需权限、无需用户配合、机密性完整性可用性全部沦陷。

同批还有一个

同一份公告里，还有另一个漏洞 CVE-2026-2330，CVSS 9.4。

这个漏洞走的是另一条路——CROWN REST 接口。CROWN 是 SICK 设备上的对象通信协议，其 REST 接口本应通过白名单控制对文件系统目录的访问，但部分原本仅供内部测试使用的目录没有被纳入白名单保护。攻击者可以向这些目录写入篡改过的参数文件，设备重启后参数生效，网络配置、应用参数随之被改变。

两个漏洞，两条路径，指向同一批设备，根本原因高度相似：研发测试阶段留下的目录和接口，在生产固件中既没有被移除，也没有被保护。

攻击有多简单

整个攻击链条，技术门槛极低。

第一步，用 Shodan 或 ZoomEye 搜索暴露于公网的 SICK Lector 设备，这是公开平台，任何人都能做。

第二步，向目标设备的 HTTP 端口发送一个 GET 请求，路径指向 Fileaccess 接口，直接取回参数文件。不需要破解，不需要绕过，服务器直接返回 200 和文件内容。

第三步，向 AppEngine 应用目录发送 PUT 请求，上传一段 Lua 脚本。

第四步，等待设备重载应用。脚本执行，设备逻辑被接管。

从这台设备出发，攻击者可以利用获取的凭据横向移动到同网段的其他工业设备，以这台条码读取器为跳板，向更深处的 OT 网络渗透。

为什么工业设备的漏洞更值得重视

IT 系统里打一个高危漏洞，流程相对成熟：推补丁、自动更新、重启服务，通常能在几天内完成。

工业设备不一样。

生产线不能随意停机，固件升级需要维护窗口期，部分设备的更新周期以年计。这意味着临时缓解措施——网络隔离、防火墙限制——往往会从”临时”变成”长期”。与此同时，OT 网络中的安全监控能力普遍弱于 IT 网络，攻击行为往往难以被及时发现。

更关键的是，工业设备的”可用性”和”物理安全”是交织在一起的。一台流水线上的条码读取器被攻击者接管，轻则生产数据被篡改、产品追溯链断裂，重则设备异常动作引发安全事故。这是 IT 漏洞的危害模型很难直接类比的。

这枚 CVSS 9.8 的漏洞，在工业环境中的实际风险，比分数本身更高。

受影响范围

根据 OffSeq Threat Radar 等威胁情报平台的披露，受影响设备涉及德国、美国、中国、日本、韩国、法国、意大利、英国、加拿大、荷兰等国。考虑到 SICK 产品在全球制造业的渗透深度，中国工厂中部署的 Lector 设备不在少数。

受影响固件版本：Lector85x / Lector83x，2.6.0 至 2.7.0（含）。

目前状态与修复方案

截至本文发布时，暂无公开的概念验证代码（PoC），也未见在野利用记录。但漏洞信息已完整公开，技术门槛本身极低，这一窗口不会维持太久。

官方修复方案明确：将设备固件升级至 2.8.0 版本。

如果当前无法立即升级，应当：

一、通过防火墙或 ACL，将设备 HTTP 端口的访问来源严格限制为已知管理主机，禁止任何外部网络直接访问。

二、立即轮换设备参数文件中存储的所有密码，不论是否能确认设备曾被访问，都应当执行此操作。

三、检查设备 AppEngine 应用目录，确认是否存在不明来源的 Lua 脚本文件。

四、在工业网络中部署流量监控，对 /fileaccess/ 路径的 HTTP 请求设置告警规则。

官方安全公告：https://www.sick.com/psirt

最后

这次漏洞的根源，不是什么复杂的加密算法缺陷，也不是精心构造的协议漏洞。它只是：一个 HTTP 接口，忘记加认证了。

工业设备的安全开发生命周期，在这个问题上暴露得很彻底——接口上线时没有做权限审计，测试阶段遗留的目录路径没有在发布前清理，多个接口层面存在类似设计缺陷。这不是一个工程师的失误，而是一套流程的缺位。

对于使用 SICK Lector 系列设备的运营商和安全团队，现在该做的事情很清楚。对于整个工业控制系统安全领域，这次事件提供的教训同样清楚：OT 设备的暴露面管理和固件生命周期管理，不能等到漏洞披露之后再开始重视。

参考来源

• NVD CVE-2026-2331：https://nvd.nist.gov/vuln/detail/CVE-2026-2331
• NVD CVE-2026-2330：https://nvd.nist.gov/vuln/detail/CVE-2026-2330
• SICK AG 官方安全公告 SCA-2026-0006：https://www.sick.com/.well-known/csaf/white/2026/sca-2026-0006.pdf
• SICK PSIRT：https://www.sick.com/psirt
• CVE 官方记录：https://www.cve.org/CVERecord?id=CVE-2026-2331

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：CVE-SEC CVE-SEC CVE-SEC《工厂里的条码扫描仪，正在被人悄悄读取密码》