Graylog: Manager-to-Owner Privilege Escalation on Dashboards and Saved Searches

A user who merely holds Manager access on a shared dashboard or saved search grants the Owner capability to an arbitrary second account through the update endpoint, and then uses that account to delete the entity or to remove the original owner's access.

Advisory ID: TP-2026-038
Product: Graylog (open-source platform for centralised log management and security analytics with streams, dashboards and saved searches)
Vulnerability type: Missing authorization check when changing entity shares (CWE-862, CWE-639)
CVE: CVE-2026-69190
CVSS 3.1: 6.3 (Medium) · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
Vendor advisory: GHSA-m9c2-85gv-8xr5
Affected versions: >= 6.3.0
Fixed in: 6.3.14, 7.0.9, 7.1.4
Reported: 12 June 2026

Summary

Graylog is an open-source platform for centralised log management whose dashboards and saved searches are shared by their owners through a capability model with the levels Viewer, Manager and Owner. The endpoint that updates such a view accepts a change of the shares in the same request, but authorizes it with the edit permission only and not with ownership, while the dedicated sharing endpoint performs exactly that check. A user who holds a dashboard only as Manager therefore grants the Owner capability to an arbitrary second account. Through that account they then delete the entity or remove the original owner's access, both operations that their own Manager capability is refused. The escalation stays bounded to entities already shared to the attacker as Manager and reaches no system or administrator permissions; turingpoint verified the finding live and reported it to the vendor, who fixed it in 6.3.14, 7.0.9 and 7.1.4.

Root cause

ViewsResource.update (graylog2-server/src/main/java/org/graylog/plugins/views/search/rest/ViewsResource.java:389-404) accepts the optional share_request field in the request body and passes it unchanged to entitySharesService.updateEntityShares at the end of the method through updateViewSharing (:402, :287-292). The only authorization this path runs is validateDto with searchUser.canUpdateView (:398, :408, plugins/views/search/permissions/SearchUser.java:96-101), that is the view:edit permission, which the MANAGE capability covers and OWN is not required for. The endpoint intended for share changes, POST /api/authz/shares/entities/{grn}, checks ownership at the same place: checkOwnership (security/rest/EntitySharesResource.java:160-165, security/rest/RestResourceWithOwnerCheck.java:31) requires Permission.ENTITY_OWN before the identical service call. EntitySharesService.updateEntityShares (security/shares/EntitySharesService.java:237-258) does not check the caller itself, and its only safeguard merely prevents an entity from being left without an owner (:397). CapabilityRegistry.java:39-82 bundles ENTITY_OWN into OWN only (:60) and not into MANAGE, which is why the update path applies the weaker check and a Manager grants Owner rights to an account of their choosing.

Proof of Concept

# Starting point: attacker A holds only MANAGE on dashboard <view-id>,
# <puppet-id> is a second account controlled by A with the plain Reader role.

# 1) The dedicated sharing endpoint refuses the owner grant:
POST /api/authz/shares/entities/grn::::dashboard:<view-id>
X-Requested-By: cli
{"selected_grantee_capabilities":{"grn::::user:<puppet-id>":"own"}}
# -> 403 {"message":"Not authorized to access entity ..."}

# 2) The same grant inside the view update's share_request is accepted:
PUT /api/views/<view-id>
X-Requested-By: cli
{"entity":{ ...unchanged view fields including "id" ... },
 "share_request":{"selected_grantee_capabilities":{"grn::::user:<puppet-id>":"own"}}}
# -> 200, the grant shows up in active_shares with capability "own"

# 3) The upgraded account passes the OWN gate and deletes the entity:
DELETE /api/views/<view-id>
# -> 200, the following GET on the same id -> 404

The difference is the path alone: step 1 and step 2 call the same service with the same payload, but step 1 checks ownership first and step 2 does not. Verified live on version 7.1.3 with three accounts holding the Reader role: the owner shares the dashboard to A as Manager, A grants own to the puppet account through the update path, and the puppet account deletes the dashboard successfully while A is refused the same deletion with HTTP 403.

Impact

  • Granting the Owner capability on someone else's dashboard or saved search to an arbitrary account without being the owner.
  • Deletion of the entity through the upgraded account, although the same person is not allowed to delete it with their Manager capability.
  • Removal of access for the original owner, who can no longer open their own dashboard afterwards.
  • An ordinary collaboration share at Manager level is enough as a starting position; the escalation stays limited to the already shared entity, however, and does not lead to system or administrator permissions.

References

Is Something Like This in Your Software?

Our team found this vulnerability in the course of its work. Have your applications tested by the same specialists, with a penetration test from turingpoint.

Request a Pentest