*June 2024 – Written exclusively for security practitioners and REDCap users.*


CVE-2024-56311 uncovers a flaw in REDCap up to version 14.9.6 that lets attackers abuse the Notes section of calendar events to silently log users out by exploiting missing CSRF protections on the system’s logout function. This long-read explains the vulnerability, covers how an attacker can use it against unsuspecting users, and provides simple code examples.

What Is REDCap and Why Does This Matter?

REDCap is a well-known web application used by thousands of institutions to manage research data, often involving sensitive information. Calendar events in REDCap allow users to add notes, making collaboration easier—but this handy feature became the pathway for a significant security issue.

Understanding the Vulnerability

Affected versions:
REDCap through 14.9.6

Component:
Calendar Event Notes

Vulnerability type:
Cross-Site Request Forgery (CSRF) – Unauthorized actions performed by tricking a user’s browser.

How Does CSRF Work Here?

Normally, sensitive actions like logout, account changes, etc., should only be possible if the server can confirm the request genuinely came from the user—usually by checking a secret token (CSRF token). If there is no check, simply making a request can perform the action, even if the user didn’t intend to.

In this case:

Notes in calendar events accept HTML content.

- An attacker who crafts a malicious note with embedded HTML can force requests to the logout endpoint as soon as a user views that note.

Once the victim views the event, they get logged out instantly, breaking their session—unpleasant for users and potentially a stepping stone for further attacks (like session fixation, or disrupting user workflows).

Step 1: Crafting a Malicious Note

An attacker who can write in a calendar event (or social engineer someone into pasting this payload) adds a note like:

<!-- Malicious note injected by attacker -->
<img src="/redcap/index.php?logout=1" style="display:none">

The <img> tag tries to load an image from the logout URL.

- As soon as the calendar event is viewed and the HTML is rendered, the browser sends a GET request to /index.php?logout=1.

Step 2: Triggering the Attack

Any REDCap user who opens this event will be logged out, possibly confused and inconvenienced. Attackers might use this as a pain-point during conferences, shared studies, or administrative tasks.

Here’s a minimal CSRF attack

<!-- Log out victim as soon as they load the note -->
<img src="/redcap/index.php?logout=1" style="display:none" />

Or, for broader compatibility (and bypassing some filters)

<!-- Using JavaScript in the note if JavaScript is allowed (not default in REDCap) -->
<script>
  var img = new Image();
  img.src = '/redcap/index.php?logout=1';
</script>

Note: REDCap by default does not execute JavaScript in notes, but if filters are bypassed, this would work on even more endpoints.

### Video Demo / Screenshots

While public demos can be risky, you can view the official REDCap security notice for acknowledgement and, if available, demo GIFs.

Annoyance attacks: Attackers can “spam” these notes to disrupt workflows.

- Bypass Authentication: Similar patterns could be used on more dangerous functions if other endpoints lack CSRF protection.

Note: So far, this specific bug only affects logout, but always check for broader missing CSRF defenses.

For REDCap admins

- Upgrade to REDCap 14.9.7 or higher, which patches the hole by adding CSRF checks to the logout route.

References and Further Reading

- Official REDCap Security Updates
- MITRE CVE Record for CVE-2024-56311 *(pending publication - check for updates)*


In conclusion:
CVE-2024-56311 highlights the importance of CSRF protection on every sensitive endpoint—not just login, but logout and other state-changing actions. While this bug only impacted session termination, it underscores that “minor” oversights can have real-world effects. Always keep your REDCap installations up-to-date!


*If you found this guide helpful, share it with your local IT or research data administrator to help keep your institution secure.*

Timeline

Published on: 12/22/2024 21:15:16 UTC
Last modified on: 03/13/2025 19:15:48 UTC