CVE-2026-52783: OpenProject Plaintext OAuth Token Cache Exposure

Technical summary

The Storages module in OpenProject uses userless OAuth flows to obtain Azure AD bearer tokens for OneDrive/SharePoint integration. These access_tokens are cached persistently under deterministic keys (storage.<id>.httpx_access_token) using Rails.cache, which supports three backends: file_store, memcache, and redis. None of these backends apply encryption-at-rest by default, leaving tokens readable to anyone with access to the underlying cache system. The tokens are repopulated continuously—both by an hourly background job and on each OAuth-authenticated request—creating multiple write opportunities and a persistent attack surface. An attacker with network or filesystem access can trivially retrieve tokens via the memcached binary protocol or Redis commands without authentication, yielding valid Azure AD application-tier bearer tokens.

Business impact

Compromise of these tokens enables unauthorized access to organizational cloud storage, potentially exposing confidential documents, intellectual property, contracts, and personal data stored in SharePoint or OneDrive. An attacker can read, modify, or delete files without triggering user-level audit trails, complicating forensic investigation. For organizations relying on OpenProject as a central collaboration hub, this creates a backdoor into Microsoft 365 that bypasses user authentication and conditional access policies. The risk is heightened in multi-tenant deployments where a single token compromise affects all users accessing that storage integration.

Affected systems

OpenProject versions prior to 17.3.3 and 17.4.1 are affected when the Storages module is enabled and configured for OneDrive or SharePoint integration. The vulnerability exists regardless of which cache backend is in use (file_store, memcache, or redis), as none apply encryption-at-rest. Organizations running older versions with active cloud storage connectors are vulnerable; air-gapped or file-only deployments are not directly at risk.

Exploitability

Exploitation requires read access to the cache backend, which is a lower bar than many vulnerabilities suggest. In environments where memcache or redis is exposed on the internal network without authentication (common in containerized or cloud deployments), any networked attacker can retrieve tokens anonymously. File-store backends require filesystem access, which may be available to other containerized services or a compromised host. Once tokens are obtained, no additional steps are required—they are immediately valid bearer tokens usable against Microsoft Graph API. The deterministic key structure makes discovery straightforward. However, the attacker must already have some form of network or system-level access; this is not a remote unauthenticated attack against OpenProject itself.

Remediation

Upgrade to OpenProject 17.3.3 or 17.4.1 or later. These versions implement encryption-at-rest for cached tokens, rendering them unreadable even if the cache backend is compromised. Organizations unable to patch immediately should restrict network access to cache backends (memcache, redis) to only the OpenProject application servers, use authentication and encryption options available in redis, and monitor cache access logs for suspicious read patterns. Consider temporarily disabling OneDrive/SharePoint integrations until patches are deployed in high-sensitivity environments.

Patch guidance

Apply OpenProject 17.3.3 if running the 17.3.x line, or 17.4.1 if running 17.4.x or later. Verify patch availability through your OpenProject deployment channel (self-hosted, cloud, or Docker image). After upgrade, clear the existing cache to purge any unencrypted tokens; restart OpenProject services to force re-authentication with Microsoft. Test cloud storage connectivity to confirm functionality post-patch. For large deployments, stage patches in a non-production environment first to verify no integration breaks.

Detection guidance

Review cache backend access logs (memcached stats, redis slowlog, or filesystem audit logs) for unusual read patterns, especially repeated reads of keys matching storage.*.httpx_access_token. Monitor Azure AD sign-in logs and audit trails for bearer token usage from OpenProject's service principal that coincides with unexpected file access in OneDrive or SharePoint. Check OpenProject application logs for failed or repeated OAuth refresh attempts, which may indicate token exposure or revocation. Network segmentation monitoring can flag cache backend traffic from unexpected sources.

Why prioritize this

This vulnerability scores HIGH (8.2 CVSS) due to the combination of high-impact token exposure (confidentiality and integrity breach across cloud storage), relatively low barrier to exploitation (read access to cache), and organizational scope (affects all users sharing that storage integration). While not remotely exploitable without prior access, the deterministic key structure, persistent token storage, and typical lack of cache backend hardening make it a practical attack path in many deployments. Organizations with strict data governance, regulated cloud storage use, or sensitive IP in SharePoint should prioritize this immediately.

Risk score, explained

CVSS 8.2 (HIGH) reflects: Attack Vector Network (N) because cache backends are often accessible over LAN or in containerized environments; Attack Complexity High (H) because read access to the cache backend is required; Privileges Required Low (L) because many cache systems lack authentication or allow broad read access; Scope Changed (C) because token compromise affects downstream Microsoft systems; Confidentiality High (C) because file contents and metadata in cloud storage are exposed; Integrity High (I) because files can be modified or deleted; Availability None (A) because the token itself does not enable denial-of-service. The score reflects realistic deployment practices where cache backends are insufficiently isolated.

Frequently asked questions