REDCap servers face a 9.8-rated unauthenticated RCE
A maximum-severity flaw in REDCap, the survey and research data platform used by thousands of institutions, lets an unauthenticated attacker run code on the server.
What the REDCap flaw allows
A vulnerability published in the National Vulnerability Database on 20 September lets an attacker run their own code on a REDCap server without logging in at all. The record, CVE-2026-90817, carries a CVSS 3.1 score of 9.8 out of 10, which is the top band: it is reachable over the network, needs no account, needs no trick to convince a user to click, and would leave the attacker in control of the host.
The flaw sits in two places that meet in the middle. REDCap's survey passthrough routing can be pushed, by manipulating HTTP requests, into reaching a controller route it should never expose from a public survey context. The Data Import handling then accepts a crafted file-path or stream parameter, and the combination is enough to execute arbitrary code. The database entry classifies it under CWE-73, external control of a file name or path, and CWE-94, code injection.
One condition matters. Exploitation requires the attacker to know a valid public survey hash, and the record states plainly that they do not need to authenticate. That is a lower bar than it sounds, because public surveys are shared by link with participants, and those links carry the hash.
The affected range is broad for a project that is deliberately versioned conservatively: the record says the vulnerability exists in REDCap 13.3.0 and higher. The disclosure is credited to Securifera, whose own advisories index lists the same identifier as REDCap DataImport Remote Code Execution.
Why research software is a target worth taking
REDCap, short for Research Electronic Data Capture, is not a consumer product. It is the survey and database software behind a large share of clinical and academic research, built at Vanderbilt University in 2004 and coordinated through a consortium that now counts 8,427 institutions across 166 countries, with about 2.8 million projects and 4.5 million users.
The project describes itself as a secure web application for building and managing online surveys and databases, and its own documentation makes a point of the fact that institutions host their own installations and therefore control their own security posture. That autonomy is the strength of the model and also the weak point of it: there is no vendor-run service to patch quietly behind the scenes, so every hospital, university and research group that runs REDCap is responsible for finding out about a flaw like this and acting on it.
What is confirmed, and what is not
The severity score, the affected versions, the exploitation path and the authentication requirement all come from the published CVE record, and the researcher who reported it lists the advisory on their own site. What the public record does not carry is a vendor statement. No fixed-version note or security bulletin for CVE-2026-90817 was available on the project's own site at the time of writing, so the practical advice is the unglamorous kind: administrators running an internet-facing REDCap installation should confirm which version they are on, treat 13.3.0 and later as affected, and check with the project or their consortium representative for guidance before assuming an update has landed.
Our opinion
The score here will do more work than the code behind it. A 9.8 next to a product that hospitals and universities depend on will trigger emergency calls in some IT departments and be quietly filed in others, because research infrastructure so often runs on a single administrator who inherited the server along with a grant. That is the real vulnerability class: not the path parameter, but the assumption that a system built for collecting sensitive data must somehow already be watched. REDCap's designers gave the world a tool that made rigorous data collection possible for small teams, and then gave each team the job of defending it alone. The most useful thing that can come out of this disclosure is not a patch note nobody reads, but a consortium-level answer to a simple question: who is responsible for telling 8,000 installations that they need to act?