文章总结： 本文分析了OpenEMR开源医疗系统的满分漏洞CVE-2026-24898。漏洞源于MedEx模块认证缺失与Token泄露，攻击者仅需发送POST请求即可获取API凭据，危及2亿患者数据。文章详细解析了攻击原理与法律后果，并建议立即升级至8.0.0版本，或采取禁用模块、IP限制等应急措施修复。 综合评分： 90 文章分类： 漏洞预警,漏洞分析,WEB安全,应急响应

满分漏洞预警：一行POST请求，2亿患者健康档案门户洞开

原创

CVE-SEC CVE-SEC

CVE-SEC

2026年3月9日 08:01 四川

满分漏洞预警：一行POST请求，2亿患者健康档案门户洞开

CVE-2026-24898 | OpenEMR | CVSS 10.0 | 披露日期：2026-03-03

事情有多严重

2026年3月3日，一个CVSS评分满分10.0的严重漏洞被公开披露。

受影响的系统叫做OpenEMR——全球部署最广泛的开源电子健康档案系统，被超过10万家医疗机构使用，管理着超过2亿人的患者病历。国际计划生育联合会、美国和平队、肯尼亚地区医院，都是它的用户。

漏洞的利用方式极为简单：攻击者向目标发送一条普通的HTTP POST请求，不需要账户，不需要密码，不需要任何凭据，服务器会主动将医疗机构的API认证Token完整地返回在响应体中。

拿到这个Token，攻击者就掌握了该医疗机构在第三方通知平台上的完整控制权，可以读取、导出、篡改患者的预约记录、联系方式和临床提醒内容。这些数据在美国法律框架下属于受保护健康信息（PHI），一旦泄露，涉事机构将面临HIPAA强制报告义务，民事罚款上限每年150万美元，情节严重者面临刑事追责。

漏洞出在哪里

问题发生在OpenEMR的MedEx消息通知模块里。

MedEx是一个可选的商业集成模块，帮助医疗机构通过短信、电话、邮件向患者发送预约提醒。它的工作方式是：MedEx的服务器定期向OpenEMR发送Webhook回调请求，触发数据同步。

这个回调端点的代码文件是 library/MedEx/MedEx.php，问题出在第38到47行，由三个同时存在的缺陷叠加而成。

第一个缺陷：认证被完全关闭。

文件顶部有一行代码：

$ignoreAuth = true;

这是OpenEMR框架提供的一个合法机制，本意是允许少数需要接受外部未认证请求的端点绕过全局会话检查。使用这个标志的前提，是端点自身必须实现替代性的身份验证。这个端点用了这个标志，但没有实现任何替代验证。

第二个缺陷：密钥参数从不校验。

代码逻辑是：只要POST请求中包含 callback_key 这个参数，就执行MedEx平台的登录流程。这个参数的值是什么，代码完全不在乎。任意字符串都能触发。这个参数的名字暗示它应当作为共享密钥使用，但代码里从来没有进行过比对校验。

第三个缺陷：完整API响应原样返回给请求方。

执行MedEx平台登录后，代码将MedEx服务器返回的完整JSON响应体直接echo给了HTTP调用方。这个响应里包含JWT格式的API会话Token、诊所信息、患者活动事件数据。

三个缺陷合在一起，结果就是：任何人发一条POST请求，就能拿到医疗机构的完整API凭据。

攻击过程

攻击者的操作步骤如下。

第一步，在Shodan、FOFA或ZoomEye上搜索暴露在互联网上的OpenEMR实例，查询语句分别是 http.title:"OpenEMR"、title="OpenEMR"、app:"OpenEMR"，筛选出版本低于8.0.0的目标。

第二步，确认目标已启用MedEx模块——访问端点路径，看是否返回非404响应。

第三步，发送一条POST请求：

POST /library/MedEx/MedEx.php HTTP/1.1
Host: 目标地址
Content-Type: application/x-www-form-urlencoded

callback_key=test

第四步，从响应中提取 token 字段，拿着这个Token直接向MedExBank.com发起认证请求，以目标医疗机构的身份访问其在MedEx平台上的全部数据。

整个过程可以完全自动化，适合批量扫描。从发现目标到取得Token，只需要两次HTTP请求。

拿到Token之后能做什么

持有有效的MedEx API Token，攻击者以该医疗机构的身份登录MedEx平台，可以：

• 查询并导出全部患者的姓名、电话、邮件地址、预约时间、就诊医生信息
• 读取由OpenEMR临床决策规则生成的临床提醒内容，其中可能包含诊断、用药等深度医疗信息
• 修改或取消已排期的患者预约提醒，制造医疗混乱
• 以医疗机构名义向患者批量发送虚假通知
• 在Token有效期内持续监控后续同步数据，持续获取患者信息更新

这不是OpenEMR第一次出类似问题

2018年，安全研究机构Project Insecurity对OpenEMR 5.0.1.3进行审计，发现了超过20个安全漏洞，其中包括一个患者门户认证绕过漏洞，成因是 verify_session.php 只检查Session变量是否存在，而不验证其合法性——任何知道参数名称的人都可以绕过认证访问受保护资源。

CVE-2026-24898在本质上重复了同样的设计失误：以参数的存在性替代参数的合法性作为认证依据。

这种模式在医疗信息系统中反复出现，根源在于功能开发阶段对Webhook等外部集成接口的安全设计缺乏系统性审查。开发者正确地判断了”这个端点需要接受外部请求”，但错误地将这一判断等同于”这个端点不需要验证请求方身份”。

影响范围有多广

OpenEMR本身的体量决定了这个漏洞的潜在影响面。

根据OpenEMR社区基于下载量的保守估计，该系统在全球超过100个国家和地区部署，管理超过2亿人的患者记录。由于其开源免费的特性，大量中小型诊所和欠发达地区的医疗机构倾向于将系统直接暴露在互联网上以便远程访问。这些机构往往缺乏专职安全团队，版本更新滞后，是这类漏洞的主要受害群体。

部署量排在前列的国家依据历史研究记录分别是美国、印度和巴西。此外，在肯尼亚等东非地区，MedEx所处理的临床提醒数据还可能涉及HIV/TB治疗项目的患者记录，数据敏感程度更高。

法律层面的后果

在美国法律框架下，这个漏洞的后果远不止技术层面的安全事件。

HIPAA违规通知规则（45 CFR §§ 164.400-414）规定，MedEx API Token泄露在法律上被推定为可报告的安全事件。由于该Token可直接用于访问MedEx平台上存储的PHI，受影响机构几乎无法举证证明PHI被实际获取的可能性极低。

一旦触发强制报告义务：

• 受影响超过500人：须向所有受影响个人发出通知，同时向HHS OCR即时报告，事件被公示至公开的违规名单
• 民事罚款最高每年150万美元
• 故意忽视且未纠正的情形：最高25万美元罚款及10年有期徒刑

IBM 2023年的成本报告显示，医疗行业数据泄露的平均总成本为1,093万美元，在所有行业中最高。

官方如何修复

OpenEMR团队在响应效率上表现不错。CVE编号保留于2026年1月27日，补丁代码由开发者Michael A. Smith于2026年1月28日提交，正式修复包含在2026年2月13日发布的OpenEMR 8.0.0版本中，早于公开披露约18天。

补丁对 library/MedEx/MedEx.php 进行了四项改动：

第一，增加服务状态检查。若MedEx模块未在全局设置中启用，端点直接返回HTTP 404，不执行任何业务逻辑。这从根本上对未启用MedEx的实例消除了攻击面。

第二，增加参数存在性校验。callback_key 参数缺失或为空时，返回HTTP 400并写入审计日志。

第三，响应数据完全脱敏。这是本次修复的核心改动。端点不再将MedEx API的完整响应返回给请求方，改为仅返回同步操作的成功或失败状态，不含任何凭据信息。

第四，增加全面的审计日志记录。所有调用尝试均被记录，包括请求方IP地址、密钥存在状态和同步结果，便于事后溯源。

值得注意的是，补丁并未引入真正的共享密钥比对机制——callback_key 的值依然不被校验。但由于响应数据已完全脱敏，即使请求成功触发，也不再有Token可以泄露，漏洞的实际危害被彻底消除。

如果还没升级，现在该做什么

如果你运营着OpenEMR实例且版本低于8.0.0，按以下优先级处理：

首要行动：升级至8.0.0。 官方下载地址：https://www.open-emr.org/

暂时无法升级的应急措施：

若未使用MedEx模块，在OpenEMR管理后台关闭它：全局设置 > 连接器 > 取消勾选”Enable MedEx Communication Service”。

若使用MedEx模块，在Web服务器层封锁该端点对外部的访问，仅允许MedExBank.com官方IP通过：

Nginx配置示例：

location = /library/MedEx/MedEx.php {
&nbsp; &nbsp; allow <MedExBank.com官方IP>;
&nbsp; &nbsp; deny all;
}

Token应急处置：

即使暂未发现攻击迹象，只要系统此前暴露在互联网上且版本低于8.0.0，建议立即联系MedExBank.com支持团队，申请吊销当前API Token并重新签发，同时检查MedEx账户的访问日志，评估是否存在历史未授权访问记录，并通知合规团队评估HIPAA报告义务。

检测是否曾遭攻击：

在服务器访问日志中执行：

grep "POST /library/MedEx/MedEx.php" /var/log/apache2/access.log

任何命中记录都值得进一步排查。

一点延伸思考

这个漏洞的技术原理并不复杂，但它指向一个在医疗信息系统开发中反复出现的结构性问题。

Webhook回调接口是现代系统集成的常见组件。开发者在设计这类接口时，往往更关注功能的正确实现，而对”外部请求方身份验证”这一安全需求缺乏系统性的设计意识。HMAC签名验证、预共享密钥比对、IP白名单——这些都是成熟的Webhook安全实践，在主流开发文档中均有清晰的说明，但它们并不总是被实施。

更值得关注的是最小暴露原则的缺失：即使认证机制存在缺陷，如果响应体中不包含认证Token，这个漏洞的危害也会大幅降低。一个Webhook回调端点返回的内容，只应该包含完成其目的所必需的最少信息。将第三方平台的完整API响应转发给请求方，在功能上没有必要，在安全上是严重的设计缺陷。

OpenEMR的案例提示我们：对于处理高度敏感数据的医疗系统而言，每一个接受外部请求的端点，无论其功能多么边缘，都值得进行专项的安全审查。

漏洞编号：CVE-2026-24898

CVSS v3.1：10.0（Critical）

影响版本：OpenEMR < 8.0.0

安全版本：OpenEMR 8.0.0

漏洞披露：2026-03-03

发现者：@simecek（分析：@pavelkohout396）

官方安全公告：https://github.com/openemr/openemr/security/advisories/GHSA-qwff-3mw7-7rc7

NVD详情：https://nvd.nist.gov/vuln/detail/CVE-2026-24898

免责声明：

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

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

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

本文转载自：CVE-SEC CVE-SEC CVE-SEC《满分漏洞预警：一行POST请求，2亿患者健康档案门户洞开》