TL;DR
I got CVE-2026-50539 in Xibo CMS.
This one was a pretty direct object-level authorization bug on notification attachments.
The vulnerable route was:
/notification/export/{id}According to the public advisory, any authenticated user could iterate over sequential notification IDs and download attachments from notifications they did not own, including notifications created by administrators.
That is a simple bug, but still a very useful one.
The bug
The advisory describes the issue as missing ACL on the notification export path.
That matters because the attacker did not need some weird elevated role. The only capability called out in the public advisory was standard authenticated access to the Notification Centre so the user could view past notifications.
Once the route accepted an attacker-controlled notification ID without object-level authorization, the rest was predictable:
- notification IDs were sequential
- attachments were tied to those notifications
- the export route would serve the attachment if the ID existed
So the real boundary was never “can this user open the Notification Centre at all?”
The real boundary should have been:
does this notification attachment belong to a notification this specific user is allowed to export?
That is the question the route failed to ask.
Why I liked it
I like bugs like this because they are easy to under-rate at first.
There is no fancy chain here. No race condition, no parser trick, no multi-step pivot.
It is just an authenticated route taking an object ID too literally.
But once that object is an administrator-generated notification with an attachment, the impact becomes much less boring. The data is still private, and the attacker still should not have had it.
What the attacker needs
The public advisory keeps the attacker requirements pretty light:
- authenticated user
- standard access to the Notification Centre
That is important because the bug was not framed as “admin can download admin files.”
It was framed as a normal authenticated user path missing object-level authorization on export.
Impact
The public advisory states the impact directly:
- any authenticated user could download attachments from any notification
- this included notifications created by administrators
- exploitation worked by iterating over sequential notification IDs
So this was a confidentiality issue, not an integrity bug.
The advisory severity data lists:
- Severity:
Moderate - CVSS:
6.5 - Vector:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N - CWE:
CWE-862
That feels about right. The attacker still needed an authenticated session, but after that the missing object-level check made the attachment export path too trusting.
Versions
The public advisory lists:
- CVE:
CVE-2026-50539 - Affected:
4.4.2 - Patched:
>= 4.4.3
The advisory was published on June 21, 2026.
What the public advisory did and did not give
This is one of those advisories that is strong on the boundary and weaker on the code detail.
The useful public part is clear:
- route
- attacker class
- object-level bug
- affected and patched versions
But the advisory does not publish an internal code snippet for the missing ACL check itself, so I am not padding this write-up with guessed controller internals.
The bug is already clear enough without pretending we got a source diff from the advisory page.
Reference
