Skip to main content
OneCon26: Gain the advantage in the AI era. Oct. 20–22 in Las Vegas.Register Now
Vulnerability Database/CVE-2026-69190

CVE-2026-69190: Graylog Privilege Escalation Vulnerability

CVE-2026-69190 is a privilege escalation flaw in Graylog that allows users with edit permissions to grant themselves owner rights through the view update API. This post covers technical details, affected versions, security impact, and mitigation steps.

Published:

CVE-2026-69190 Overview

CVE-2026-69190 is a broken access control vulnerability in Graylog, an open-source log management platform. The view update API for saved searches and dashboards permits a user with edit permission but without entity ownership to include a shareRequest that grants owner permissions to an arbitrary account. Once elevated, the selected account can delete the saved search or dashboard, or revoke the original owner's access. The flaw affects Graylog versions from 6.3.0 through 6.3.13, 7.0.0 through 7.0.8, and 7.1.0 through 7.1.3. Graylog Cloud was patched before the advisory was published. The weakness is classified as [CWE-639] Authorization Bypass Through User-Controlled Key.

Critical Impact

Authenticated users with edit-only permissions can seize ownership of saved searches or dashboards, delete shared content, and remove legitimate owners from their own entities.

Affected Products

  • Graylog Server versions 6.3.0 through 6.3.13
  • Graylog Server versions 7.0.0 through 7.0.8
  • Graylog Server versions 7.1.0 through 7.1.3

Discovery Timeline

  • 2026-09-21 - CVE-2026-69190 published to NVD
  • 2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-69190

Vulnerability Analysis

The vulnerability resides in the Graylog ViewsResource REST endpoint that handles updates to saved searches and dashboards. When processing an update request, the server accepts an embedded shareRequest object that modifies ownership and sharing grants on the target view. The pre-patch code path did not verify that the requester actually owned the view before applying the sharing changes. Any authenticated user holding edit permission on the entity could therefore rewrite ownership grants.

An attacker exploiting this flaw can assign owner-level permissions to any account they control. Once ownership is transferred, that account can delete the saved search or dashboard or strip access from the original owner. This produces integrity and availability impacts on shared analytics assets used by security and operations teams.

Root Cause

The root cause is missing ownership validation on the share-modification path of the view update handler in graylog2-server/src/main/java/org/graylog/plugins/views/search/rest/ViewsResource.java. The controller merged shareRequest payloads without confirming the caller was the entity's owner, conflating edit permission with the authority to change sharing state. This is a classic authorization bypass through a user-controlled key ([CWE-639]).

Attack Vector

Exploitation requires network access to the Graylog API and a valid account with edit permission on a target saved search or dashboard. The attacker submits a PUT request to the view update API containing a crafted shareRequest that grants owner rights to an attacker-controlled principal. No user interaction from the legitimate owner is required.

java
// Patch context: ViewsResource.java imports added to enforce
// Graylog Resource Name (GRN) ownership validation on share updates.
 import jakarta.ws.rs.core.MediaType;
 import jakarta.ws.rs.core.Response;
 import org.apache.shiro.authz.annotation.RequiresAuthentication;
+import org.graylog.grn.GRNType;
 import org.graylog.grn.GRNTypes;
 import org.graylog.plugins.views.audit.ViewsAuditEventTypes;
 import org.graylog.plugins.views.search.Query;
// Source: https://github.com/Graylog2/graylog2-server/commit/9303f395dd29c03abd8885f1c7d1c90f8aae72d4

The upstream changelog entry summarizes the fix: Validate ownership for share requests when updating view (search/dashboard). See Graylog Pull Request #26344 for the full patch.

Detection Methods for CVE-2026-69190

Indicators of Compromise

  • Unexpected changes to the owner field on saved searches or dashboards in the Graylog audit log, particularly ownership transfers initiated by non-owner accounts.
  • Deletion of saved searches or dashboards shortly after a share-permission change performed by a different user.
  • HTTP PUT requests to /api/views/{id} containing a shareRequest body from accounts that are not the entity owner.

Detection Strategies

  • Review Graylog audit events of type views:update and correlate the acting user_id against the entity's original owner to identify unauthorized ownership grants.
  • Alert on any share-permission mutation where the acting principal is not present in the entity's prior owner grants.
  • Baseline normal API usage patterns and flag anomalous shareRequest payloads originating from low-privilege accounts.

Monitoring Recommendations

  • Forward Graylog server audit logs and REST API access logs to a centralized SIEM for correlation and long-term retention.
  • Enable HTTP request-body logging on the Graylog API tier where privacy policy permits, so shareRequest contents can be reconstructed during investigation.
  • Track deletion events on dashboards and saved searches and pair them with recent ownership-change events to surface likely abuse chains.

How to Mitigate CVE-2026-69190

Immediate Actions Required

  • Upgrade Graylog to version 6.3.14, 7.0.9, or 7.1.4 depending on your current release branch.
  • Audit existing saved searches and dashboards for unexpected owner changes since deployment of an affected version.
  • Restrict edit permissions on sensitive views to a minimum set of trusted users until patching is complete.

Patch Information

The fix is delivered in Graylog Release 6.3.14, Graylog Release 7.0.9, and Graylog Release 7.1.4. The relevant code change adds ownership validation for share requests in the view update handler; see Graylog Commit 9303f39, Graylog Commit ac1c0b1, and Graylog Commit c878796. Graylog Cloud tenants were patched before publication of Graylog Security Advisory GHSA-m9c2-85gv-8xr5.

Workarounds

  • Revoke edit-level access from users who do not require it on shared dashboards and saved searches to reduce the pool of accounts that can trigger the flaw.
  • Place the Graylog API behind a reverse proxy that blocks PUT requests to view endpoints containing a shareRequest field until the upgrade is applied.
  • Snapshot the Graylog MongoDB database on a regular schedule so unauthorized deletions of saved searches or dashboards can be recovered.
bash
# Verify installed Graylog version and confirm it is patched
curl -s -u "$GRAYLOG_USER:$GRAYLOG_PASS" \
  "$GRAYLOG_URL/api/system" | jq -r '.version'

# Expected output: 6.3.14, 7.0.9, 7.1.4 or later

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.

Try SentinelOne