CVE-2026-55095

Executive Summary

CVE-2026-55095 is an authorization bypass vulnerability in OpenProject, an open-source web-based project management platform, affecting versions 17.5.1 and earlier. An authenticated non-admin project member can trigger an inplace-edit dialog for a raw custom_field project attribute, causing the application to resolve the custom field without enforcing the admin_only visibility scope. This flaw results in the disclosure of hidden comment text associated with the custom field; it does not permit disclosure of the field's value, nor does it allow write or mutation operations. OpenProject reports the issue fixed in version 17.6.0; no CVSS score has been assigned, and no exploit code or CISA KEV listing exists at the time of writing.

Technical Analysis

The vulnerability resides in the OpenProject dialog-handling mechanism for project custom fields. In affected versions (17.5.1 and earlier), a raw custom_field project attribute can be requested via the inplace-edit dialog by an authenticated, non-admin project member. The vulnerable code path resolves the project custom field by its raw identifier without first enforcing the admin_only visibility scope check.

The flaw class is CWE-862 (Missing Authorization). Specifically, the application fails to verify that the requesting principal possesses the administrative privilege required to view the custom field's metadata — particularly its associated comment text. The custom field is rendered in read-only mode within the dialog, meaning the disclosure is limited to the comment string stored on the field definition. The admin_only flag, which normally gates visibility to administrators only, is bypassed during the inplace-edit request handling.

The attack surface is the authenticated web UI — specifically the project settings/custom fields area where inline editing dialogs are served. The vulnerability requires:

1. Valid authentication (any project member role — not necessarily administrator).
2. Knowledge of, or ability to enumerate, a raw custom-field identifier belonging to a field marked admin_only.
3. Interaction with the inplace-edit dialog endpoint to trigger resolution of that identifier.

No memory corruption, injection, or remote code execution is involved. The impact is strictly confidentiality — partial disclosure of hidden comment text. The confidentiality impact is limited to the comment strings attached to admin-only custom fields, not the field values themselves, and no integrity or availability impact exists.

Insider threat is a likely concern: a legitimate, non-admin project collaborator can probe for admin-only custom field comments across projects they are members of. Given that this is a web application, no direct network-level exploitation occurs — the vulnerability is exercised via HTTPS requests to the application's dialog endpoints.

Exploitation Scenarios

No public PoC or exploit code is available; the attack chain below is inferred from the vulnerability class and NVD description.

Step 1 — Reconnaissance / Target Identification: An authenticated attacker (a non-admin project member) enumerates custom fields on a target project. This may be done by browsing project settings, observing custom field names in views, or by probing the application's JavaScript routes and dialog request patterns that reveal field identifiers. The attacker specifically seeks raw identifiers for custom fields not visible in normal UI rendering (i.e., fields flagged admin_only).

Step 2 — Triggering the Flaw: The attacker sends a request to the inplace-edit dialog endpoint, supplying the raw identifier of an admin-only custom field. This request is made with standard session cookies, so the application treats the attacker as an authorized project member. Because the vulnerable code path skips the admin_only scope check, the dialog is constructed and returned.

Step 3 — Payload / Execution: No injection payload is used. The attack is purely a malformed/invalid-privilege request: an HTTP GET (or equivalent) to the dialog resource with a raw field identifier that the requesting user should not be allowed to resolve. The server responds with a rendered read-only dialog containing the hidden comment text.

Step 4 — Post-Exploitation Impact: The attacker exfiltrates the comment text. This could contain sensitive internal notes, project metadata, or contextual information about the field's purpose. The attacker cannot modify the field, cannot read the field's stored value, and cannot pivot to other admin functions. Repeated requests across multiple project IDs and field identifiers could be automated to harvest hidden comments across the instance.

Impact Assessment

Business Impact: The primary risk is information disclosure. Admin-only custom field comments may contain business-sensitive annotations, internal decision rationale, or confidential project metadata. A non-admin collaborator (including external contractors or third-party partners granted limited project access) can harvest these comments.

Affected Systems: All OpenProject deployments running version 17.5.1 or earlier with admin-only custom fields in use. Self-hosted instances are the primary concern; managed/saas deployments are patched centrally by OpenProject.

Blast Radius: The disclosure is limited to comment text of admin-only custom fields. No authentication bypass for full account takeover, no data modification, no cross-tenant leakage unless a single instance hosts multiple tenants with shared custom-field identifiers. The severity is moderate: confidentiality-only impact, requiring valid credentials, with a narrow disclosure scope.

CVSS / Scoring: No CVSS vector has been published. Given the authentication requirement, the limited confidentiality impact, and the absence of integrity/availability impact, an estimated CVSS v3.1 score would likely fall in the 4.3–6.5 (Medium) range. However, insufficient technical detail is available to compute an authoritative score; treat this as unrated until the vendor publishes CVSS data.

CISA KEV: Not listed in CISA's Known Exploited Vulnerabilities catalog.

Detection Guidance

Sigma Rule

title: OpenProject Inplace-Edit Dialog Access to Admin-Only Custom Field
id: 2f1b8c43-5d76-4e9a-b3f2-7a1c66d9e052
status: experimental
description: Detects authenticated requests to OpenProject inplace-edit dialog endpoints referencing custom field identifiers, which may indicate an attempt to bypass admin_only visibility scope (CVE-2026-55095).
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-55095
author: valtersit.com Threat Intelligence
date: 2026/05/14
logsource:
    category: webserver
    product: nginx
    detection:
        selection:
            http.url|contains:
                - '/custom_fields/'
                - '/inplace_edit'
                - 'custom_field'
        filter:
            http.method: 'GET'
            http.url|contains: '/admin'
        condition: selection and not filter
    fields:
        - client.ip
        - user_agent
        - http.url
falsepositives:
    - Legitimate administrators editing custom field settings
    - Admin UI requests that include custom_field in path
level: medium

YARA Rule

rule OpenProject_CVE_2026_55095_CustomField_Disclosure
{
    meta:
        author = "valtersit.com Threat Intelligence"
        description = "Detects HTTP request patterns associated with OpenProject inplace-edit dialog retrieval of raw custom field identifiers"
        cve = "CVE-2026-55095"
        date = "2026-05-14"
        severity = "medium"
    strings:
        $s1 = "inplace_edit" ascii nocase
        $s2 = "custom_field" ascii nocase
        $s3 = "admin_only" ascii nocase
        $s4 = "work_packages" ascii nocase
        $s5 = "/projects/" ascii nocase
        $s6 = ".json" ascii nocase
    condition:
        any of ($s1, $s2) and any of ($s5, $s4) and filesize < 4KB
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"ET WEB_SPECIFIC_APPS OpenProject Inplace-Edit Admin Custom Field Access Attempt (CVE-2026-55095)"; flow:established,to_server; content:"GET"; http_method; content:"/custom_fields/"; http_uri; nocase; content:"inplace"; http_uri; nocase; content:!"/admin"; http_uri; nocase; threshold:type both, track by_src, count 5, seconds 60; classtype:attempted-recon; sid:2026950950; rev:1; metadata:created_at 2026_05_14, updated_at 2026_05_14, cve CVE_2026_55095;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [network where destination.port == 443 and process.name == "nginx" and
   http.request.uri contains "/custom_fields/"]
  [http where http.request.uri contains "inplace" and
   http.request.uri not contains "/admin"]

Note: The EQL above assumes standard Beats fields (source.ip, destination.port). Adjust field names per your Elastic indexing strategy.

Splunk SPL Query

index=web sourcetype=access_combined_w3c
| uri_path=*custom_fields*
| NOT uri_path=*admin*
| eval is_disclosure=if(match(uri_path, "inplace"), "TRUE", "FALSE")
| stats count by clientip, uri_path, is_disclosure, user_agent
| where is_disclosure="TRUE"
| sort - count

Wazuh OSSEC Rule

<group name="openproject,">
  <rule id="550951" level="10">
    <decoded_as>json</decoded_as>
    <field name="url">\.*custom_fields\.*</field>
    <field name="url">\.*inplace\.*</field>
    <description>OpenProject inplace-edit dialog requested for custom field without admin path - possible CVE-2026-55095 exploitation attempt</description>
    <mitre>
      <id>T1530</id>
    </mitre>
    <group>openproject_cve_2026_55095,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 2/4 — CLAIMED. A single source (OSV) reports the issue fixed in version 17.6.0. This is not independently confirmed by a vendor advisory (e.g., OpenProject security blog or release notes). Organizations should verify the patch in their own test environment before production deployment.

Immediate Mitigations:

1. If possible, upgrade to OpenProject 17.6.0 immediately. If the patch cannot be verified, maintain the current version but restrict project membership to trusted personnel only.
2. Review all existing custom fields flagged admin_only. If the comment text contains sensitive information, consider removing or relocating it.
3. Monitor access logs for anomalous patterns of custom_fields and inplace URI requests from non-admin users.
4. Limit project membership — audit and remove dormant or unnecessary accounts, especially those of external collaborators.

Patch/Upgrade Steps:

1. Back up the OpenProject database and file storage.
2. Review the 17.6.0 release notes and changelog to confirm the fix addresses admin_only visibility enforcement in the inplace-edit dialog path.
3. Upgrade in a staging environment first; validate that admin-only custom fields are no longer resolvable via inplace-edit requests from non-admin accounts.
4. Deploy to production; use the detection rules above to monitor for residual post-upgrade exploitation attempts.

Long-Term Hardening:

• Establish a process to vet security-relevant code changes before upgrading — track OpenProject security announcements and subscribe to relevant mailing lists.
• Run OpenProject behind a WAF with rate limiting and anomaly detection for dialog endpoint abuse.
• Implement least-privilege project membership: regular audits of who can view project custom fields.
• Consider using OpenProject's built-in audit log to review custom field access patterns periodically.

References

• NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-55095
• OSV Vulnerability Record: https://osv.dev/vulnerability/CVE-2026-55095
• OpenProject Official Site / Release Notes: https://www.openproject.org/ (main site; check release notes for version 17.6.0)
• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-55095 NOT listed)

Threat Actor Activity: No public reports of in-the-wild exploitation, exploit code, or threat actor campaigns exist for this vulnerability at the time of writing. The issue was identified through coordinated vulnerability disclosure channels (OSV). Organizations should treat this as an information-disclosure risk requiring standard patch hygiene rather than an actively exploited zero-day.