AISLE近日披露，其AI安全分析器在开源电子病历系统OpenEMR中发现38个CVE，并与OpenEMR维护者合作修复。
按AISLE的说法，这批漏洞在2026年一季度被发现，占同期OpenEMR GitHub安全公告的一半以上。主要修复进入了2026年2月11日发布的OpenEMR 8.0.0，剩余补丁在3月完成。
这件事容易被写成“AI又立功了”。我更在意的是另一个问题：当AI把漏洞发现速度拉上来，医疗开源软件的确认、修补、发布和下游升级，能不能跟上。
OpenEMR被称为服务超过10万医疗提供者、覆盖2亿患者，支持34种语言。病历系统里的漏洞，牵动的不是普通账号资料，而是诊断、处方、保险、账单、影像和患者身份信息等PHI。
OpenEMR为什么是高风险目标
OpenEMR的风险不只来自“用户多”。它还来自医疗软件本身的复杂度。
一套电子病历系统要处理临床流程、患者门户、账单、FHIR接口、OAuth2授权、影像和第三方系统接入。每多一条链路，就多一个权限边界。
AISLE披露的典型问题包括SQL注入、FHIR患者隔离绕过、缺失认证或授权、IDOR和XSS。这些不是冷门漏洞。它们更像老问题在复杂系统里的反复返潮。
最严重的场景可能导致PHI大规模泄露、数据库被接管。若数据库用户具备FILE权限等特定条件，SQL注入还可能进一步触发服务器文件读写，甚至远程代码执行。
这里要保留限制条件。不是每个漏洞都能无门槛利用，也不是38个CVE都等于Critical。有些利用需要认证，有些需要OAuth2 token，有些依赖数据库权限配置。
对医疗机构IT和安全负责人来说，风险评估不能只看新闻标题。要看自己跑的版本、暴露的入口、数据库权限、OAuth2和FHIR配置。差一项，影响面就可能完全不同。
38个CVE暴露的是权限边界和旧代码债
这批漏洞最有信息量的地方，不是数量本身，而是类型分布。
SQL注入指向输入处理和参数化查询的缺口。FHIR患者隔离绕过指向接口标记和权限过滤的耦合风险。IDOR和缺失ACL检查，则说明“能登录系统”和“能看哪份病历”之间的边界没有被稳定执行。
医疗系统尤其怕这个。医生、护士、账单人员、患者门户用户、第三方应用，可能都在同一套数据周围活动。权限模型如果散落在各处代码里，靠人工记忆维护，迟早会漏。
可以拿2018年Project Insecurity对OpenEMR的审计作一个参照。当时人工团队披露23个漏洞。AISLE这次称一个季度内发现38个CVE，至少说明AI分析器在扫旧代码、找重复模式、扩大覆盖面上有实际价值。
但这个对比也提醒一件事：安全债不会因为换了工具就消失。2018年的人工审计和2026年的AI分析，指向的是同一类问题——医疗软件越复杂，权限边界越需要被持续验证。
| 观察点 | AISLE披露的信息 | 更现实的判断 |
|---|---|---|
| 漏洞数量 | 发现38个CVE | 数量说明覆盖面强，不代表全部高危 |
| 漏洞类型 | SQL注入、FHIR隔离绕过、缺失认证/授权、IDOR、XSS | 共性集中在输入处理和访问控制 |
| 利用条件 | 部分需要认证、OAuth2 token或特定数据库权限 | 机构要按自身部署评估，不宜一刀切恐慌 |
| 修复状态 | 8.0.0承载主要修复，3月完成剩余补丁 | 公告发布不等于生产环境已安全 |
| 证据边界 | 主要来自AISLE博客和OpenEMR GitHub安全公告 | 不能写成第三方独立审计已完整验证 |
我不太买账的是把这件事包装成“AI自动修好了医疗系统”。更准确的说法是：AI把一批问题更快推到桌面上，维护者仍要判断补丁会不会破坏业务逻辑。
医疗机构和维护者现在该怎么做
AISLE称，其为每个CVE生成了贴合OpenEMR代码库的修复建议。部分补丁由AISLE直接产出，部分被维护者改写后合入。
关键点在后半句。OpenEMR维护者参与确认、审查和发布，说明AI没有绕过维护流程。医疗软件不能只追求“补上这一行代码”，还要确认权限语义、临床流程和兼容性没有被误伤。
对医疗机构IT与安全负责人，动作应当更具体：
- 确认是否已升级到OpenEMR 8.0.0，并纳入3月后续补丁；
- 对照OpenEMR GitHub安全公告，核查自身版本和暴露模块；
- 收敛数据库账号权限，尤其检查是否保留不必要的FILE等高危权限；
- 复核OAuth2、FHIR、患者门户和第三方应用接入的访问控制；
- 做一次补丁后验证，重点看患者隔离、IDOR、报表查询和门户页面。
这类机构还要考虑一个现实约束：医疗系统不能像普通网站一样随手停机升级。排期、备份、回滚、接口兼容和医生使用窗口，都会拖慢补丁进入生产环境。
所以更稳妥的做法不是“看到38个CVE就立刻大改”，而是把暴露面最高的入口排在前面。公网患者门户、FHIR接口、OAuth2集成、数据库高权限账号，应优先处理。
对开源医疗软件维护者，启发也很直接。AI安全分析应当更早进入代码评审和发布前检查，而不是等漏洞集中披露后再补洞。
但边界也要讲清。AI擅长找模式、扫重复、生成候选补丁；不擅长替人理解“这个角色在这家医疗机构到底该看什么”。权限模型、数据隔离和兼容性，仍要靠维护者把关。
接下来最该看的不是AISLE还能不能挖出更多漏洞，而是两件事。
一是OpenEMR社区会不会把这类自动化分析接入日常review，减少同类问题回潮。二是下游医疗机构的升级速度能不能跟上公告节奏。
漏洞被发现，只是灯亮了。真正决定风险的，是补丁有没有走到生产系统，权限有没有被收紧，旧配置有没有被清掉。