CVE-2026-44696: OpenProject CSS Injection in Markdown Rendering (Medium)

Technical summary

OpenProject's markdown rendering pipeline delegates CSS sanitization to Sanitize::Config::RELAXED[:css], a permissive allowlist that essentially permits all CSS properties within style attributes on specific HTML elements (figure, img, table, th, tr, td). This configuration was intended to balance usability with security but fails to account for the breadth of CSS capabilities that can be abused for injection attacks. An attacker with authenticated write access can craft CSS that repositions elements off-screen, overlays transparent layers, modifies text visibility, exfiltrates data via CSS computed values, or otherwise manipulates the rendered page in ways invisible to input validation. The lack of stricter CSS property filtering means inline styles bypass the intended security boundary, violating CWE-79 (Improper Neutralization of Input During Web Page Generation).

Business impact

For organizations deploying OpenProject, the primary risk is internal fraud and phishing. Malicious insiders or compromised accounts can craft deceptive content that tricks other users into entering credentials or sensitive information into fake form overlays. In multi-tenant or open-collaboration scenarios—such as agencies using OpenProject for cross-organizational project tracking—the risk escalates: external partners with write access could compromise internal users. The attack also carries reputational risk; if users discover their project management platform is being used to deliver phishing payloads, trust in the system erodes. For vendors offering OpenProject as a managed service, this translates to potential customer churn and support burden during remediation.

Affected systems

All versions of OpenProject prior to 17.4.0 are affected. The vulnerability is present in any formattable text field: work package descriptions and comments are the highest-risk surfaces given their visibility across teams, followed by project descriptions and news items. Any OpenProject deployment where non-administrators have write access to these fields is potentially compromised, including self-hosted instances and SaaS offerings. Typical deployments in mid-market and enterprise environments are likely to have numerous users with write permissions, expanding the attack surface.

Exploitability

Exploitation is straightforward for anyone with valid account credentials and write access. No special tools, network positioning, or advanced techniques are required; crafting malicious CSS is within the capability of any developer or moderately skilled attacker. However, the attack requires user interaction—the victim must view the content containing the injected CSS for it to take effect—which prevents fully automated compromise. The requirement for prior authentication and active write access limits the attacker pool to insiders, compromised accounts, or invited collaborators. Public-facing instances without strict access controls face higher risk.

Remediation

Upgrade to OpenProject 17.4.0 or later, which implements stricter CSS property filtering in the sanitization pipeline. Organizations should prioritize patching in environments where external users, contractors, or guest accounts have write access to formattable fields. Prior to patching, consider restricting write permissions on sensitive projects and audit existing content for signs of injected CSS (particularly style attributes with unusual position, display, or z-index properties). Review access logs for suspicious edits to high-visibility items.

Patch guidance

Verify the availability of OpenProject 17.4.0 or later through the official OpenProject releases page or your vendor's advisory channels. If you are running a self-hosted instance, follow the standard upgrade procedure documented in the OpenProject administration guide, taking backups beforehand. Managed service customers should confirm their provider has scheduled or completed the upgrade; contact support for status. Test the patch in a non-production environment first to ensure compatibility with any custom plugins or configurations. The fix addresses the root cause (overly permissive CSS sanitization) rather than applying a band-aid, so no additional configuration is typically required post-patch.

Detection guidance

Monitor work package history and comment audit logs for edits introducing style attributes with suspicious CSS properties—particularly position:absolute, position:fixed, z-index, overflow:hidden, clip, or visibility properties that might indicate overlay injection. Search the database for style= attributes containing unusual values in description or comment fields. Intrusion detection on the application layer could flag requests with encoded or obfuscated CSS payloads, though encoding bypass is trivial. User awareness training on visual phishing is practical: educate teams to be skeptical of unexpected login prompts or unusual UI changes within project items.

Why prioritize this

Although the CVSS score is moderate (5.7), the vulnerability merits prioritization because it enables direct fraud and credential theft within a tool used daily by project teams. The attack is easy to execute, requires only common account access levels, and targets information workers who may be less security-conscious when interacting with tools they trust. In zero-trust security models, this is a material lateral-movement vector. Organizations with strict access controls or no external collaborators face lower risk and may defer patching slightly, but the ease of exploitation and the reputational impact of phishing from your own tools justify treating this as a near-term concern for most deployments.

Risk score, explained

The CVSS 3.1 score of 5.7 reflects a Medium severity reflecting low privileges required (authenticated user), low attack complexity, and no confidentiality or availability impact, balanced against high integrity impact (ability to inject arbitrary visual content and deceptive overlays). The score does not fully capture the social engineering and fraud risk inherent in phishing-capable injection; from a compliance and operational perspective, many organizations will treat this as higher priority than the numeric score suggests.

Frequently asked questions