Graylog Security Update Addresses 1 Vulnerability
Tech GuruQuick Answer
Graylog CVE-2026-69190 lets a user who can edit a saved search or dashboard grant ownership of that object to another account. That account could then delete it or remove the original owner's access. For self-managed servers, the listed fixes are 6.3.14, 7.0.9 and 7.1.4 in their respective branches. Graylog reports that its Cloud service has already been patched.
Confirm Scope And Apply The Supported Fix
What to do now: identify self-managed Graylog server versions and who can edit shared searches and dashboards. Upgrade the affected branch through the supported channel, then verify that editors cannot grant ownership without authorization. Cloud customers should confirm service status with Graylog rather than install a server package themselves.
Source recheck: October 2, 2026 UTC. The linked project advisories were checked for this revision; deployment applicability and successful remediation still require local evidence. Recheck the supported release before changing production.
Scope And Authority
| Product scope | Graylog packages and release streams identified in the project advisories |
|---|---|
| Advisory | GHSA-m9c2-85gv-8xr5 |
| CVE | CVE-2026-69190 |
| Authoritative release date | 2026-07-07 UTC (project advisory dates, not database ingestion) |
| Authority revision date | 2026-08-03 UTC (project advisory dates, not database ingestion) |
| Affected versions | org.graylog2:graylog2-server >= 6.3.0, < 6.3.14; org.graylog2:graylog2-server >= 7.0.0, < 7.0.9; org.graylog2:graylog2-server >= 7.1.0, < 7.1.4 |
| Fixed version | org.graylog2:graylog2-server 6.3.14; org.graylog2:graylog2-server 7.0.9; org.graylog2:graylog2-server 7.1.4 |
| CVSS base score | 6.3 (CVSS v3) |
| CVSS severity | Medium |
| Exploitation status | Not stated by the authority; no exploitation claim is inferred. |
What Changed
The update corrects authorization on the API that changes saved searches and dashboards. This is object-level ownership escalation, not a stated route to operating-system or global administrator access. The project lists no known workaround; review unexpected sharing/ownership changes without treating their absence as proof that no misuse occurred.
What To Validate Now
- Inventory. Record the self-managed server branch, cluster nodes and owners of shared searches/dashboards; distinguish these from vendor-managed Cloud tenants.
- Establish applicability. Match self-managed 6.3, 7.0 and 7.1 installations to the branch ranges in the table, then check vendor support before selecting the target release.
- Remediate. Install 6.3.14, 7.0.9 or 7.1.4 as the issue-specific minimum in the corresponding supported branch, or a later supported fix; follow Graylog's cluster upgrade procedure.
- Validate. Check every node's resulting version, normal dashboard/search behavior and test-account ownership boundaries on disposable objects. Keep legitimate owner access intact.
- Retain evidence. Preserve asset and owner identifiers, the applicability decision, before-and-after versions, change approval, installation output, validation results, and any exception or rollback record.
Operational Cautions
Use the exact supported release stream and repository. Test dependencies, clusters, integrations, and rollback before broad deployment; a CVSS rating or reachable feature is not evidence of exploitation.
Evidence To Retain
- Exact product, release stream, package or application version, enabled feature, environment, and accountable owner.
- UTC timestamps, authority revision, approved change record, installer or package-manager output, and resulting version.
- Relevant logs and monitoring evidence, test results, exceptions, compensating controls, and rollback decisions.
Related TechGeeks Resources
Authoritative References
Correction policy: If the authority changes affected versions, fixed versions, severity, exploitation information, mitigations, or required action, TechGeeks will update this notice and its verification date.
