Logo
Overview
an idor in openproject through meeting agenda items

an idor in openproject through meeting agenda items

b4r b4r
June 8, 2026
3 min read
vulnerability cve web exploitation idor

TL;DR

I got another CVE, this time in OpenProject: CVE-2026-49355.

The bug was in:

GET /api/v3/meetings/:meeting_id/agenda_items/:agenda_item_id

That endpoint could disclose private work package data from a linked work package that belonged to a private or otherwise inaccessible project.

So this was not some broad auth bypass across the whole app. It was narrower than that.

But it was still a real cross-boundary leak, and that was enough.

The bug

What made this one nice is that the issue sat in a place that looked pretty normal at first.

The request was for a meeting agenda item, not directly for the private work package itself.

That is exactly why it matters.

The API path looked like it was returning one object, but it was actually pulling in linked data from somewhere else. And that linked data was not being scoped tightly enough before it got returned.

So even if the user was not supposed to have access to the private project behind that work package, the single agenda item endpoint still leaked data from it.

That kind of bug is always worth paying attention to:

  • direct object access may be blocked
  • obvious project-level boundaries may look correct
  • but a linked-resource endpoint brings the exposure back in through the side door

Why I liked it

I like bugs like this because they come from trusting relationships between objects a little too much.

It is easy to secure the obvious endpoint and still miss the “secondary” place where the same data shows up again through an association.

Here, the sensitive bit was not the meeting object by itself. It was the fact that the agenda item could reach into a linked work package from a project the caller should not be able to see.

That makes the bug feel small on paper, but very real in practice.

What the impact actually was

According to the advisory, the confirmed issue was private work package data disclosure.

So this is primarily a confidentiality bug:

  • not an integrity bug
  • not an availability problem
  • not a full system compromise

Just a clean information leak across an authorization boundary.

The public advisory reflects that with:

  • Severity: Moderate
  • CVSS: 4.3
  • Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

That feels about right.

You still need a valid low-privileged authenticated context, but once you have that, the issue is straightforward and the leaked data belongs to a project you were not supposed to access.

Root cause in one line

The agenda item API trusted the linked work package relationship more than it trusted the caller’s actual access to the linked project.

That is really the whole story.

The bug was not “OpenProject forgot auth exists.”

The bug was that one endpoint exposed data through an object relationship that did not get re-checked strongly enough at the point of read.

Affected and fixed version

The public advisory lists:

  • Affected: 17.4.0
  • Patched: 17.4.1

The assigned CVE is:

  • CVE-2026-49355

Reference