CVE-2026-103939 · Runtime
NO FIX YET · SEE WHAT TO DO
OpenEMR's Weno e-prescribing module has a download script with no access check or CSRF protection, so any logged-in user, or a cross-site request triggered through a logged-in victim, can delete the weno_pharmacy table. A failed re-download can leave the pharmacy directory empty and e-prescribing unavailable.
first public Aug 18, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Clinics and practices running OpenEMR before 8.3.0 with the Weno e-prescribing module enabled. Installations without the Weno module, or running 8.3.0 or later, are not affected.
Not affected if openemr-8.3.0-or-later, weno-module-disabled
Who cares healthcare, openemr, php, self-hosted
composer.json; versions below 8.3.0 are affected.interface/modules/custom_modules/oe-module-weno exists).8.3.0 or later.OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.3.0, interface/modules/custom_modules/oe-module-weno/scripts/file_download.php has no ACL or CSRF check and ignores the result of validateAdminCredentials(). When the Weno module is enabled, the default GET path calls PharmacyService::removeWenoPharmacies() before attempting a refetch, allowing any authenticated user to truncate the weno_pharmacy table and allowing a cross-site request to trigger the same operation through a logged-in victim. A failed later download can leave the e-prescribing pharmacy directory empty and unavailable. This issue is fixed in version 8.3.0.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.