CVE-2026-52781: OpenProject HTML Sanitization Bypass Allows Unauthorized Redirects

Technical summary

The vulnerability resides in OpenProject's HTML sanitization layer, which fails to adequately restrict data-* attributes on <macro> elements. An authenticated attacker crafts a work package description containing data-controller="poll-for-changes", which binds to a Stimulus controller. When the description is viewed, this controller fetches an attacker-controlled attachment and passes its contents to Turbo Stream's renderStreamMessage() function. Turbo Stream then interprets and executes arbitrary stream actions—including redirect_to—in the victim's authenticated session context. The issue stems from overly permissive sanitization rules that allow :data wildcard patterns rather than explicit attribute whitelisting.

Business impact

Organizations using OpenProject face unauthorized session hijacking of authenticated users. An internal actor or attacker with valid credentials can silently redirect employees to malicious websites, phishing pages, or credential-harvesting sites during normal project management workflows. This is particularly risky in multi-team environments where work packages are widely shared. The attack requires no user interaction beyond viewing a compromised work package, making it difficult to detect or prevent without patching. Incident response teams may struggle to trace redirects back to their source if logging is incomplete.

Affected systems

OpenProject versions prior to 17.3.3 (in the 17.3.x branch) and prior to 17.4.1 (in the 17.4.x branch) are affected. The vulnerability requires an authenticated user account to inject the malicious payload, so only instances with user registration or shared team environments face direct risk. Self-hosted and SaaS deployments are equally vulnerable if not updated.

Exploitability

Exploitation requires prior authentication to the OpenProject instance, which limits the attack surface to internal users or individuals with valid credentials obtained through other means. However, once authenticated, the attack is trivial to execute—no special privileges, complex interaction, or client-side user action is needed beyond a victim viewing the infected work package. The payload is stored in the work package description, ensuring persistence and broad reach across the team. This combination of low complexity and high impact makes the vulnerability moderately dangerous in collaborative environments.

Remediation

Upgrade OpenProject to version 17.3.3 or later (for 17.3.x deployments) or to version 17.4.1 or later (for 17.4.x deployments). These versions implement stricter HTML sanitization that explicitly whitelists safe data-* attributes rather than permitting wildcards. Verify the patched version before and after deployment. Organizations unable to patch immediately should restrict work package visibility to trusted users and monitor for suspicious redirects in web server logs.

Patch guidance

OpenProject maintainers have released fixes in versions 17.3.3 and 17.4.1. Review your current version via the OpenProject admin dashboard or command line (openproject --version). Plan a maintenance window to apply the update, as it may require a restart of the application server. Test the update in a staging environment first to confirm compatibility with any custom macros or extensions. After patching, confirm that Stimulus controllers are correctly bound and that no legacy data-* attributes remain in existing work package descriptions. Refer to the official OpenProject release notes for detailed upgrade procedures.

Detection guidance

Search your OpenProject instance for work package descriptions containing data-controller="poll-for-changes" or similar suspicious data-* attribute patterns. Enable HTTP request logging and alert on redirect_to actions originating from Turbo Stream responses. Monitor for unusual attachment uploads by users with edit permissions on shared work packages. Correlate any user-reported unexpected redirects during project management sessions with the timestamps of work package updates. If your instance is internet-facing, analyze web server logs for abnormal referrer patterns or destination IPs associated with your OpenProject domain.

Why prioritize this

Although the CVSS score is 6.4 (MEDIUM), the vulnerability should be treated as HIGH priority in collaborative environments. The attack requires authentication but no user interaction, achieves session-level privilege escalation effects, and affects all authenticated users viewing a compromised work package. The reputational and compliance risk of unauthorized redirects, combined with the trivial exploitation difficulty, justifies rapid patching. Organizations using OpenProject for sensitive project planning or with non-technical user bases should prioritize this within days rather than weeks.

Risk score, explained

CVSS 3.1 score of 6.4 reflects: Network-accessible attack vector (AV:N), low attack complexity (AC:L), low privilege requirement (PR:L), no user interaction needed (UI:N), and scope change (S:C) because the attack affects other authenticated users. Confidentiality and integrity are slightly impacted (C:L, I:L) through potential phishing and session manipulation, but availability is not directly compromised (A:N). The score appropriately captures authentication as a prerequisite but does not fully weight the ease of exploitation or the insider threat dimension; contextualize this as MEDIUM within your organization's risk model, adjusting upward if OpenProject hosts critical or sensitive projects.

Frequently asked questions