CVE-2026-33301
Open-Emr Openemr ≤ 8.0.0.2
Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-33301 is a high-severity Improper Encoding or Escaping of Output (CWE-116) vulnerability in Open-Emr Openemr. Its CVSS base score is 7.1 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Content Injection (T1659); ranked at the 37th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-33301 is an arbitrary file read vulnerability in OpenEMR, a free and open source electronic health records and medical practice management application. The issue affects versions prior to 8.0.0.2 and resides in the PDF creation function for Eye Exam forms within patient encounters. Specifically, form answers submitted by users are parsed as unescaped HTML, enabling the inclusion of arbitrary image files from the server in the generated PDF. The vulnerability is rated with a CVSS v3.1 base score of 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) and is associated with CWE-116 (Improper Encoding or Escaping of Output).
The vulnerability can be exploited by authenticated users holding the "Notes - my encounters" role, who have permission to fill Eye Exam forms in patient encounters. By injecting malicious HTML into form answers that references arbitrary image files on the server, an attacker can trigger the PDF generation process to embed sensitive file contents as images. This results in high confidentiality and integrity impacts, allowing unauthorized access to and exposure of server files through the downloadable PDF, without requiring user interaction beyond normal workflow.
Mitigation is addressed in OpenEMR version 8.0.0.2, which fixes the unescaped HTML parsing in the PDF creation function. Security practitioners should upgrade to this version immediately. Additional details are available in the GitHub security advisory (GHSA-v9v3-q973-xp2h) and the fixing commit (dccc962f06bdf6105ca85c277915167caf3e7c28).
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-13162
Vulnerability Data
OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.0.0.2, users with the `Notes - my encounters` role can fill Eye Exam forms in patient encounters. The answers to the form can…
more
be printed out in PDF form. An arbitrary file read vulnerability was identified in the PDF creation function where the form answers are parsed as unescaped HTML, allowing an attacker to include arbitrary image files from the server in the generated PDF. Version 8.0.0.2 fixes the issue.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.1.2V1.2.1V1.2.3
Likely Mitigating Controls AI
Per-CVE control mapping for this CVE has not run yet; the list below is derived from the weakness types (CWEs) cited in the NVD entry.
Validating that output matches expected content directly mitigates failures to properly encode or escape data for its destination context.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require proper output encoding to prevent injection and message malformation.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Secure coding standards explicitly require correct output encoding and escaping to preserve message structure.
Security testing can detect missing or incorrect encoding but does not itself implement the control.
Secure development life cycle mandates output encoding/escaping practices that directly prevent improper encoding.
Application security requirements include explicit rules for safe output handling and encoding.
Secure architecture principles reduce the likelihood of missing encoding but do not prescribe the actual technique.