文章总结： AISLE公司AI分析器在OpenEMR医疗记录平台发现38个安全漏洞，包括SQL注入、权限绕过等高风险问题，其中20个为授权缺失漏洞。AI不仅自主生成修复方案，还将检测集成至代码审查阶段，揭示医疗数字化速度远超安全建设的现状，建议医疗机构立即开展AI辅助安全评估并强化开发流程安全测试。 综合评分： 90 文章分类： 漏洞分析,AI安全,数据安全,安全运营,解决方案

医疗数据安全警钟：AI自主挖掘OpenEMRa医疗记录平台的38个CVE

原创

网空闲话 网空闲话

网空闲话plus

2026年4月30日 08:03 北京

在小说阅读器读本章

去阅读

人工智能在网络安全领域的应用正以惊人的速度改变漏洞发现与修复的格局。2026年4月28日，AISLE公司发布报告称，其AI驱动的自主分析引擎在开源电子健康记录平台OpenEMR的代码库中一次性发现了38个此前未披露的安全漏洞（CVE），占同期GitHub上OpenEMR所有安全公告的一半以上。这一成果不仅刷新了该平台安全审计的历史纪录，更向全球医疗行业敲响了警钟：医疗软件的数字化速度已远超其安全建设，而攻击者正在利用AI扩大这一差距。

一、AI效率碾压人工：从23到38的跨越

OpenEMR是全球最广泛采用的开源电子健康记录平台之一，服务于超过10万家医疗机构，覆盖全球2亿患者，支持34种语言。2026年2月发布的OpenEMR 8.0版已获得美国联邦卫生IT认证计划下的ONC认证，包括完整的隐私与安全标准（§ 170.315(d)(1)至(d)(13)）。如此广泛的覆盖范围，使得保护该平台的安全性至关重要。

然而，其安全历史并不乐观。2018年，由专业人类安全团队耗时数月完成的“Project Insecurity”独立审计，在国际媒体广泛报道下披露了23个漏洞。相比之下，AISLE的AI分析器在2026年第一季度内就发现了38个漏洞——仅一个季度的时间，数量远超人类团队数月的工作成果。AISLE在报告中直言：“医疗行业数字化速度快于安全建设。AI辅助诊断、远程医疗和自动计费正在以前所未有的速度扩大医疗服务的可及性，但保护这些系统的安全实践却未能跟上。”

二、三个标志性漏洞：从数据库沦陷到患者隐私泄露

在38个漏洞中，有三个特定漏洞尤为值得关注，代表了医疗软件中最危险的脆弱类型。

CVE-2026-24908：患者REST API中的SQL注入（CVSS 10.0，严重级）

该漏洞存在于OpenEMR患者REST API的_sort查询参数中。这是一个常见的REST模式——客户端通过该参数选择返回结果的排序方式。然而，传递给_sort的值被直接拼接到SQL ORDER BY子句中，没有任何验证、允许字段白名单或标识符转义。任何持有有效OAuth2 Bearer令牌的已认证客户端均可利用此漏洞实施三种攻击：UNION SELECT载荷提取凭据哈希或任意表内容；基于时间的盲注（通过SLEEP()）确认可利用性；若数据库用户具备FILE权限，则可升级为任意文件读写和远程代码执行。AISLE将其评为CVSS 10.0分，意味着无需复杂条件即可完全控制系统。

CVE-2026-23627：免疫接种搜索/报告中的SQL注入（CVSS 8.8，高危）

该漏洞存在于免疫接种模块的搜索和报告端点中，位于Web界面而非REST API。patient_id表单参数按逗号分割后，每个片段被直接拼接到SQL WHERE子句中，未经参数化或转义。由于注入点在WHERE子句而非ORDER BY，利用更加直接。攻击者可通过UNION SELECT在单次请求中从任何表中提取数据——包括患者健康信息（PHI）和登录凭据。若数据库用户具备FILE权限，同样可读取服务器文件或写入Web shell，升级至远程代码执行。值得注意的是，AISLE的AI分析器自主生成了该漏洞的完整补丁，OpenEMR维护人员直接采纳。

CVE-2026-24487：FHIR患者隔离区绕过（CVSS 6.5，高危）

这是一个典型的权限控制架构缺陷。OpenEMR的FHIR层使用PHP接口（IPatientCompartmentResourceService）作为标记，决定哪些服务应接受患者范围过滤。然而，FhirCareTeamService类未声明该接口，导致框架的instanceof检查静默失败，患者筛选器未被注入。尽管底层服务本身已支持按患者UUID过滤，但相关代码根本未被调用。结果，该端点返回了系统中每一位患者的护理团队数据，而非仅限请求者有权访问的单名患者。AISLE将其归类为“信息暴露”漏洞，严重级别为“高”。

三、漏洞全景：授权缺失居首，XSS与注入紧随其后

根据AISLE发布的全量漏洞列表，38个漏洞可归为三大类别：

1. 缺失或不正确的授权（约20项）—— 最大类别

这是本次发现中数量最多的脆弱类型。许多端点接受用户提供的记录标识符（患者ID、便签ID、表单ID等），却未验证调用者是否有权访问该记录。在访问控制术语中，这被称为“不安全直接对象引用”（IDOR）。一个相关的子集涉及完全省略访问控制列表（ACL）检查的端点，允许任何已认证用户访问本应仅限管理员或特定角色的功能。极端情况下，一个端点甚至完全绕过了身份验证（CVE-2026-24898：未经身份验证的患者身份信息披露，严重级）。其他典型漏洞包括：患者笔记Web UI中的IDOR（CVE-2026-34055）、文档和保险REST端点跳过ACL（CVE-2026-25164，高危）、以及zhAclCheck忽略显式ACL拒绝（CVE-2026-33302，高危）。

2. 跨站脚本攻击（XSS）（约9项）

用户控制的数据在未经过当编码的情况下被渲染到HTML或JavaScript中，允许攻击者注入代码并在其他用户的浏览器会话中执行。尤其危险的是，部分XSS漏洞跨越了患者门户与临床人员界面之间的信任边界——意味着患者可以向医生或管理员会话中注入恶意代码。典型漏洞包括：门户签名者模态框中的存储型DOM XSS（CVE-2026-32121，高危）、CCDA预览中的存储型XSS（CVE-2026-33932，高危）、以及门户支付中的存储型XSS（CVE-2026-33346，高危）。

3. SQL注入、路径遍历与会话缺陷（约6项）

除了前述两个严重SQL注入外，还包括一个会话超时绕过漏洞（CVE-2026-25476，高危），该漏洞通过skip_timeout_reset参数实现；以及两个路径遍历漏洞——传真端点中的任意文件泄露（CVE-2026-24488，中危）和压缩DICOM文件夹时的路径遍历（CVE-2026-25928，中危）。后者允许攻击者通过受控文件路径读取或写入服务器上的任意文件。

四、自主修复与上游防御：AI的进阶角色

AISLE不仅发现了漏洞，还为每一个CVE生成了“仓库原生修复方案”——复用OpenEMR自身的抽象层、授权模式和清理辅助函数。对于严重级CVE-2026-23627，AISLE独立生成了完整的补丁；在其他案例中，OpenEMR维护人员基于AISLE提出的修复建议进行了调整。

这种“发现+修复建议”的一体化能力大幅缩短了修复周期。AISLE与OpenEMR的合作始于2025年12月中旬，首批漏洞于2026年1月中旬披露。大部分修复随OpenEMR 8.0.0于2026年2月11日发布，距离首次披露仅约四周。其余修复于3月分三次补丁发布全部完成。

更值得关注的是，2026年4月初，双方正式将AISLE PRO——一款AI驱动的提交分析器——集成到OpenEMR的代码审查工作流中。这意味着，许多漏洞现在可以在代码审查阶段、进入生产环境之前就被检测并修复。

OpenEMR基金会执行主任Brady Miller博士对此评价道：“对于一个像OpenEMR这样——事关患者安全和健康数据隐私——的项目，我们对与AISLE的合作感到无比兴奋。他们的自主分析器在我们代码库中发现了数十个漏洞。现在，随着AISLE分析器在代码审查阶段的运行，我们正在漏洞进入生产环境之前就捕获并修复它们。”

五、深层次警示：医疗数字化的安全鸿沟与AI军备竞赛

AISLE在报告中开篇即点明核心矛盾：“医疗行业数字化速度快于安全建设……攻击者越来越频繁地使用AI比以往更快地发现漏洞。其结果是，医疗软件的能力与防御水平之间的差距正在扩大。”

这一论断得到了行业观察的支持。Dark Reading的报道（2026年4月30日）指出，AI工具已从根本上改变了漏洞研究的范式，将过去需要数月痛苦手动分析的工作压缩到数周甚至数天。然而，这种效率提升也带来了新挑战：安全团队面临漏洞洪流，且越来越担心恶意行为者在使用同样的AI工具，在防御者有机会修补之前就发现并利用漏洞。这一担忧直接催生了Anthropic公司的“Project Glasswing”等主动防御项目。

OpenEMR案例的启示是多层次的。第一，开源医疗软件虽然促进了创新与可及性，但其安全状况高度依赖于社区和维护者的响应能力。第二，AI驱动的漏洞发现已经成为“必需品”而非“奢侈品”——当攻击者已在使用AI时，防御者别无选择，只能跟进。第三，将AI能力“左移”到代码审查阶段，是缩小安全差距的切实路径。正如AISLE所言：“AI驱动的攻击越来越多地瞄准医疗机构，以窃取个人身份信息、勒索赎金、干扰救生护理的提供。防御者需要匹配的覆盖范围。”

【闲话简评】

OpenEMR中38个漏洞的披露，应成为我国医疗信息化领域的一剂清醒剂。尤其值得注意的是，其中约20个授权缺失漏洞——包括IDOR和ACL绕过——并非高深的技术缺陷，而是基础访问控制实践的缺失。这种“认证即信任”的惯性思维，在承载着数亿患者敏感信息的大规模系统中，无异于安全裸奔。

更严峻的是，AI已大幅降低了漏洞挖掘的门槛。攻击者不再需要资深专家的技能，即可通过AI工具批量扫描医疗系统的薄弱环节。我国大量医院核心HIS系统、区域卫生信息平台、互联网医院App，大量依赖开源组件或历史遗留代码，其中很可能潜藏着与OpenEMR类似的SQL注入和权限绕过漏洞。医疗机构和信息化厂商必须立即行动：第一，对在用系统进行AI辅助的自主安全评估，而非被动等待合规检查；第二，在开发流程中强制引入自动化安全测试，将漏洞扼杀在代码审查阶段。患者生命所系的数据，不应成为AI攻击时代的试验场。安全不是成本，而是医疗数字化的基石。

参考资源

1、https://aisle.com/blog/aisle-discovers-38-critical-security-vulnerabilities-in-healthcare-software-used-by-100000-providers

2、https://www.darkreading.com/vulnerabilities-threats/ai-finds-38-security-flaws-openemr

免责声明：

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

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

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

本文转载自：网空闲话plus 网空闲话 网空闲话《医疗数据安全警钟：AI自主挖掘OpenEMRa医疗记录平台的38个CVE》