CVE-2026-24898: The Webhook That Handed Out Its Own Keys

---

A single unauthenticated POST to OpenEMR's MedEx callback endpoint forced a real, credentialed login to the MedEx service and then printed the resulting session token straight back to the caller. CVSS 10.0 per the GHSA advisory, and the patch is mostly a lesson in what a webhook should never say out loud.

The advisory in plain English

OpenEMR is a widely deployed open-source electronic health records system. It integrates with MedEx, a third-party patient-messaging platform, and ships a small "callback" endpoint at library/MedEx/MedEx.php so MedEx can push response data back into the practice's database in real time. To be reachable by an external service, that endpoint has to skip OpenEMR's normal session authentication.

That part is legitimate — plenty of webhook receivers are anonymous by design. The defect is what this one returned. Instead of treating the incoming request as untrusted and replying with a terse status, the endpoint performed a full, authenticated MedEx login using the practice's own stored API credentials and then serialized the entire login response — session token and all — into the HTTP body. Any anonymous visitor who sent a callback_key field received the practice's live MedEx token. With that token an attacker owns the practice's MedEx account: PHI exfiltration, fraudulent messaging, and a textbook HIPAA incident.

The flawed function

Here is the entire vulnerable handler. From library/MedEx/MedEx.php @ a0942e5, L38-L43:

if (!empty($_POST['callback_key'])) {
    $MedEx = new MedExApi\MedEx('MedExBank.com');
    $response = $MedEx->login('2');
    header('Content-type: application/json');
    echo json_encode($response);
    exit;
}

Six lines, and every one of them trusts the wrong party. The file sets $ignoreAuth = true before pulling in globals.php, so there is no session, no CSRF token, no ACL check guarding this code. The only gate is !empty($_POST['callback_key']) — the mere presence of a non-empty field, with no comparison against any secret stored locally. If that field exists, OpenEMR logs into MedEx and echo json_encode($response) dumps the result verbatim.

The critical misunderstanding is whose credentials authenticate that login. Look at what login('2') actually does. From library/MedEx/API.php @ a0942e5, L3346-L3354:

public function login($force = '')
{
    $info = $this->getPreferences();
    if (empty($info) || empty($info['ME_username']) ||
        empty($info['ME_api_key']) || empty($info['MedEx_id']) ||
        ($GLOBALS['medex_enable'] !== '1')) {
        return false;
    }
    $info['callback_key'] = $_POST['callback_key'];

The username, API key, and MedEx ID are read from the local medex_prefs table — the practice's own secrets. The attacker-supplied callback_key is merely tacked on as one more field. Authentication against MedEx succeeds because of the stored API key, not because the caller knew anything. The visitor's callback_key can be any junk string; it never needs to be correct for the privileged login to go through.

After the credentials check, login() hands the assembled $info to just_login(), which enriches the response with the live token and ships it back. From library/MedEx/API.php @ a0942e5, L3335-L3342:

if (!empty($response['token'])) {
    $response['practice'] = $this->practice->sync($response['token']);
    $response['generate'] = $this->events->generate($response['token'], $response['campaigns']['events']);
    $response['success']  = "200";
}
$sql = "UPDATE medex_prefs set status = ?";
sqlQuery($sql, [json_encode($response)]);
return $response;

That $response['token'] is the MedEx session token used as &token= in every subsequent API call the integration makes — sync, patient sync, SMS dispatch. It is the crown jewel, and it rides the return $response all the way back up to the echo in MedEx.php.

Why the check was insufficient

The endpoint conflated three distinct questions and answered only the easiest one:

1. Is a callback_key present? — Yes/no, the only thing actually checked.
2. Is this caller authorized to trigger a login? — Never asked. $ignoreAuth = true plus a presence-only test means the answer is always "sure."
3. Should the response body contain secrets? — Implicitly "yes," because the code serialized the whole $response object without ever deciding what was safe to expose.

Tracing the actual data path makes the failure concrete: the attacker-controlled $_POST['callback_key'] enters at API.php:L3354, flows through just_login() as the login is performed, the curl response is captured into $response, the token is attached at L3335-L3337, return $response propagates back through login('2') at MedEx.php:L40, and the object is serialized to the wire at MedEx.php:L42 — echo json_encode($response). There is no sanitizer, no field allow-list, and no authentication gate anywhere along that path. The source is the request; the sink prints the server's secrets.

A webhook receiver should be an inbox, not an oracle. This one answered every knock by reading its own diary aloud. Even the original file header bragged about "multiple authentication steps for security: local API_key, MedEx username, session token, MedEx generated token" — but those steps authenticated OpenEMR to MedEx. None of them authenticated the caller to OpenEMR, which is the trust boundary that actually mattered here.

What the fix changed

Commit 8e4de59 rewrites the handler around one principle: the callback may cause work, but it may never learn anything sensitive. Three changes, in order of importance.

First and most important, the response is now a bare status flag — the token never leaves the process. From library/MedEx/MedEx.php @ 8e4de59, L61-L70:

// Return only success/failure status, not sensitive tokens
if (isset($response['success']) && $response['success']) {
    EventAuditLogger::getInstance()->newEvent('medex-webhook', '', '', 1, "Sync successful from $remoteAddr");
    echo json_encode(['success' => true]);
} else {
    $error = $MedEx->getLastError() ?: 'Sync failed';
    EventAuditLogger::getInstance()->newEvent('medex-webhook', '', '', 0, "Sync failed from $remoteAddr: $error");
    echo json_encode(['error' => $error]);
}

Second, the endpoint returns 404 if MedEx isn't even enabled, hiding its existence from scanners. Third, it rejects requests with a missing callback_key with a 400 and an audit-log entry recording the remote address. The validation of the callback_key itself is delegated to MedEx server-side, where it belongs — but the security no longer depends on it, because there is nothing sensitive left to leak even if the path is exercised. Every webhook attempt is now logged via EventAuditLogger, so the next anonymous probe leaves a trail.

Notably, the fix does not try to fix the bug by demanding the caller prove they know the secret. It accepts that the endpoint is anonymous and instead removes the reward. That's the right instinct: when you can't fully authenticate a caller, make sure there's nothing worth stealing in the reply.

The lesson

The bug class here is information disclosure born of over-sharing in a serialized response (CWE-200, exposure of sensitive information in a sent response) — the same family as leaking a stack trace or dumping an entire ORM object to JSON. The triggering insight is that "this endpoint must be unauthenticated" was treated as license to skip output discipline, not just input discipline.

Three durable takeaways:

• $ignoreAuth = true is a load-bearing comment. Any file that disables authentication should be read as "everything below runs for anonymous internet users" and audited line-by-line for what it reveals, not just what it does.
• Presence is not authorization. !empty($_POST['secret']) checks that a field exists, never that it's correct. A secret you don't compare against is not a secret.
• Webhooks reply with status, not state. A receiver that echoes the result of privileged internal work turns a fire-and-forget callback into a credential vending machine. Decide explicitly what each field in a response is allowed to contain; default to "nothing."

OpenEMR 8.0.0 closes the hole. The deeper fix — assuming every anonymous endpoint is being probed and giving it nothing to confess — is the one worth carrying to the next codebase.

References

• NVD: CVE-2026-24898
• Fix commit: https://github.com/openemr/openemr/commit/8e4de59ab58222f13abc4e4040128737d857db9c
• Advisory: https://github.com/openemr/openemr/security/advisories/GHSA-qwff-3mw7-7rc7
• Vulnerable handler: https://github.com/openemr/openemr/blob/a0942e5d2ab3981b7ce6f83421e62cb7704f0aa1/library/MedEx/MedEx.php#L38-L43
• Login + token enrichment: https://github.com/openemr/openemr/blob/a0942e5d2ab3981b7ce6f83421e62cb7704f0aa1/library/MedEx/API.php#L3306-L3360
• Patched handler: https://github.com/openemr/openemr/blob/8e4de59ab58222f13abc4e4040128737d857db9c/library/MedEx/MedEx.php#L48-L70