CVE-2026-24890: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-24890 is an authorization bypass vulnerability in OpenEMR's patient portal signature endpoint that allows authenticated portal users to forge provider signatures on medical documents. Affecting all OpenEMR versions prior to 8.0.0, the flaw enables portal patients to upload and overwrite any provider's signature by manipulating the type=admin-signature parameter and specifying an arbitrary provider user ID. It was published on February 25, 2026, with a fix released in version 8.0.0. The CVSS v3.1 base score is 6.5 (Medium) per NVD, though the GitHub Security Advisory rates it 8.1 (High) due to combined confidentiality and integrity impact (GitHub Advisory, Red Hat CVE).

The root cause is CWE-285 (Improper Authorization) in portal/sign/lib/save-signature.php. When a portal session is detected, the code sets $ignoreAuth_onsite_portal = true and bypasses standard authorization; however, it fails to restrict the type parameter, allowing portal users to submit type=admin-signature. When this type is set, the patient PID is forced to 0, effectively bypassing patient-specific checks, while the $user parameter (provider ID) is accepted directly from POST data without any validation or privilege check. The backend does not enforce UI-level restrictions that would normally hide the admin signature functionality from portal users, making direct API calls sufficient to exploit the flaw (GitHub Advisory, Patch Commit).

Successful exploitation allows an authenticated portal patient to overwrite any provider's signature in the onsite_signatures database table with attacker-controlled image data, enabling signature forgery on medical documents such as prescriptions, treatment authorizations, and legal health records. This creates significant risk of healthcare fraud, legal compliance violations (e.g., HIPAA, medical record integrity requirements), and potential patient safety issues if forged signatures are used to authorize treatments or medications. The integrity impact is high, as any provider's signature can be permanently replaced; there is no direct confidentiality or availability impact (GitHub Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, including a working curl command demonstrating the attack. As of the time of disclosure, there is no evidence of active in-the-wild exploitation. The EPSS score is approximately 0.028% (0.000280), indicating low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires only a valid portal patient account and session, making it accessible to any registered patient user (GitHub Advisory).

1. Obtain Portal Access: Register or log in to the OpenEMR patient portal as any valid patient to obtain a session cookie (OpenEMR=YOUR_PORTAL_SESSION_COOKIE).
2. Identify Target Provider: Enumerate or guess a target provider's user ID (e.g., user ID 5 for "Dr. Smith") from any accessible OpenEMR interface or document.
3. Craft Malicious POST Request: Send a POST request directly to the signature endpoint, bypassing the UI, with type=admin-signature, the target provider's user ID, and a base64-encoded forged signature image:

curl -X POST "https://target-openemr.com/portal/sign/lib/save-signature.php" \
  -H "Content-Type: application/json" \
  -H "Cookie: OpenEMR=YOUR_PORTAL_SESSION_COOKIE" \
  -d '{"is_portal": 1, "type": "admin-signature", "user": 5, "signer": "Dr. Smith", "output": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..."}'

4. Verify Overwrite: Confirm the provider's signature was replaced by querying the database (SELECT * FROM onsite_signatures WHERE user = 5 AND type = 'admin-signature';) or by generating a document that uses the provider's signature and observing the forged image.
5. Abuse Forged Signature: Use the forged signature on medical documents, prescriptions, or authorizations to commit fraud or create falsified records (GitHub Advisory).

• Network: Unexpected POST requests to /portal/sign/lib/save-signature.php from portal user sessions containing type=admin-signature in the request body; requests where the user field does not match the authenticated patient's own ID.
• Logs: Web server access logs showing POST requests to save-signature.php with JSON bodies including "type":"admin-signature" from portal session cookies; repeated requests targeting multiple provider user IDs.
• Database: Unexpected or recent changes to the onsite_signatures table where type='admin-signature' and pid=0, particularly if the created or lastmod timestamps are recent or inconsistent with normal provider activity; signature image data (output field) that does not match the provider's known signature.
• File System: No direct file system artifacts expected, as the exploit operates via database writes only (GitHub Advisory).

Upgrade OpenEMR to version 8.0.0 or later, which blocks portal users from submitting type=admin-signature and overrides the user parameter with the session PID for all portal requests (Patch Commit). For organizations unable to patch immediately, implement network-level access controls to restrict direct API access to the patient portal signature endpoint, and consider temporarily disabling the patient portal if feasible. After patching, review the onsite_signatures database table for any unauthorized modifications (entries with type='admin-signature' and pid=0 created by portal sessions), and validate the integrity of provider signatures on critical medical documents created prior to the patch (GitHub Advisory).

The vulnerability was reported by researchers simecek (reporter) and pavelkohout396 (analyst) and published by OpenEMR maintainer bradymiller via GitHub Security Advisories on February 25, 2026. The issue was noted in the context of a broader disclosure of 38 critical security vulnerabilities in healthcare software used by 100,000 providers, as reported by Aisle (Aisle Blog). The vulnerability received coverage on security aggregators including Vulners, CVEFeed, and ENISA's EUVD, and was briefly discussed on Mastodon security channels shortly after disclosure.