Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
16 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact A vulnerability was found in Graylog's API endpoint for updating saved searches and dashboards. A user with edit permissions on a dashboard or saved search could grant owner permissions to an arbitrary account, which could then be used to delete the respective saved search or dashboard or to remove the original owner's access. Patches This issue has been patched in the following Graylog versions: 6.3.14, 7.0.9, 7.1.4. Affected users should upgrade to one of these versions or above to remediate the vulnerability. Graylog Cloud has already been patched. Workaround There is no known workaround. Upgrading to a patched version is recommended. Credits Thanks to Jan Kahmen, turingpoint for reporting.
Recommended action: Upgrade to 7.1.4, 7.0.9 or 6.3.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Graylog contains an insecure direct object reference (IDOR) vulnerability in the token revocation endpoint. An authenticated user can delete access tokens belonging to other users, including service account tokens and administrator tokens, if they know or can guess a valid token identifier. The issue does not expose token contents, but it allows unauthorized token deletion, leading to integrity impact and potential availability impact for access token based integrations. Patches The issue has been fixed in the following Graylog versions: 6.3.12, 7.0.7, 7.1.2. Users should upgrade to one of these versions or above to remediate the vulnerability. Graylog Cloud has already been patched. Workarounds There are no feasible workarounds for this issue. Upgrading to a patched version is recommended. Customers using Graylog Enterprise or Security can review the audit log[^1] for suspicious activity. Audit log lines for successful token deletions begin with access token deleted from…
Recommended action: Upgrade to 7.1.2, 7.0.7 or 6.3.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A security issue has been identified in Graylog affecting the parsing of syslog messages that use a key-value format, such as those generated by Fortigate devices. The vulnerability allows attackers to overwrite individual message fields, or to produce invalid messages which Graylog will discard. This effectively enables log evasion techniques to obscure malicious activity. Patches The issue has been fixed in the following Graylog versions: 6.3.12, 7.0.7, 7.1.2. Users should upgrade to one of these versions or above to remediate the vulnerability. Graylog Cloud has already been patched. Workarounds There are no feasible workarounds for this issue. Upgrading to a patched version is recommended. To find potentially discarded messages due to parsing errors, customers of Graylog Enterprise or Security can check the Indexing and Processing Failures Index[^1]. Credits Thanks to Jose Luis González, from Fundación Sarenet, with additional analysis by Borja Marcos from Sarenet. [^1]:…
Recommended action: Upgrade to 7.1.2, 7.0.7 or 6.3.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A vulnerability was found in Graylog's API endpoint for retrieving system catalog entity titles. Authenticated users could retrieve database fields of supported entities by sending a custom API request. These fields can include e.g. the password hash of a user (but not the password itself), which should not be returned through the API, regardless of the endpoint. Permission checks do still apply, so users can retrieve their own password hash, but not those of other users. The admin user (or any user with an admin role) can retrieve password hashes of all users. Patches This issue has been patched in Graylog 7.1.4. In this version, an allow list will be used to check if protected fields are being accessed, refusing those requests. Affected users should upgrade to 7.1.4 or above to remediate the vulnerability. Workarounds There is no known workaround. Upgrading to a patched version is recommended. Credits Thanks to Evelynkaz for reporting.
Recommended action: Upgrade to 7.1.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Graylog users can gain elevated privileges by creating and using API tokens for the local Administrator or any other user for whom the malicious user knows the ID. For the attack to succeed, the attacker needs a user account in Graylog. They can then proceed to issue hand-crafted requests to the Graylog REST API and exploit a weak permission check for token creation. Workarounds In Graylog version 6.2.0 and above, regular users can be restricted from creating API tokens. The respective configuration can be found in System Configuration Users "Allow users to create personal access tokens". This option should be Disabled, so that only administrators are allowed to create tokens. Recommended Actions After upgrading Graylog from a vulnerable version to a patched version, administrators are advised to perform the following steps to ensure the integrity of their system: Review API tokens An overview of all existing API tokens is available at System Users and Teams Token Management.…
Recommended action: Upgrade to 6.3.0-rc.2 (pre-release) or 6.2.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It is possible to obtain user session cookies by submitting an HTML form as part of an Event Definition Remediation Step field. For this attack to succeed, the attacker needs a user account with permissions to create event definitions, while the user must have permissions to view alerts. Additionally, an active Input must be present on the Graylog server that is capable of receiving form data (e.g. a HTTP input, TCP raw or syslog etc). Patches Workarounds None, as long as the relatively rare prerequisites are met. Analysis provided by Fabian Yamaguchi - Whirly Labs (Pty) Ltd
Recommended action: Upgrade to 6.1.10 or 6.0.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Two minor vulnerabilities were identified in the Graylog2 enterprise server, which can be combined to carry out a stored cross-site scripting attack. An attacker with the permission FILESCREATE can exploit these vulnerabilities to upload arbitrary Javascript code to the Graylog2 server, which - upon requesting of the file by a user of the API browser - results in the execution of this Javascript code in the context of the Graylog frontend application. This enables the attacker to carry out authenticated API requests with the permissions of the logged-in user, thereby taking over the user session. Patches The generic API has been removed in 6.2.0 rendering the attack vector unreachable and additional escaping has been added. Analysis provided by Fabian Yamaguchi - Whirly Labs (Pty) Ltd
Recommended action: Upgrade to 6.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Starting with 6.1, HTTP Inputs can be configured to check if a specified header is present and has a specified value to authenticate HTTP-based ingestion. Unfortunately, even though in cases of a missing header or a wrong value the correct HTTP response (401) is returned, the message will be ingested nonetheless. Patches Workarounds Disabling http-based inputs and allow only authenticated pull-based inputs. Analysis provided by Fabian Yamaguchi - Whirly Labs (Pty) Ltd
Recommended action: Upgrade to 6.1.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Reauthenticating with an existing session cookie would re-use that session id, even if for different user credentials. In this case, the pre-existing session could be used to gain elevated access to an existing Graylog login session, provided the malicious user could successfully inject their session cookie into someone else's browser. The complexity of such an attack is high, because it requires presenting a spoofed login screen and injection of a session cookie into an existing browser, potentially through an XSS attack. No such attack has been discovered. Patches Graylog 5.1.11 and 5.2.4, and any versions of the 6.0 development branch contain patches to not re-use sessions under any circumstances, making this type of attack impossible. Workarounds Using short session expiration and explicit log outs of unused sessions can help limiting the attack vector. Unpatched this vulnerability exists, but is relatively hard to exploit. A proxy could be leveraged to clear the…
Recommended action: Upgrade to 5.2.4 or 5.1.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Arbitrary classes can be loaded and instantiated using a HTTP PUT request to the /api/system/clusterconfig/ endpoint. Details Graylog's cluster config system uses fully qualified class names as config keys. To validate the existence of the requested class before using them, Graylog loads the class using the class loader. https://github.com/Graylog2/graylog2-server/blob/e458db8bf4f789d4d19f1b37f0263f910c8d036c/graylog2-server/src/main/java/org/graylog2/rest/resources/system/ClusterConfigResource.java#L208-L214 PoC A request of the following form will output the content of the /etc/passwd file: To perform the request, authorization is required. Only users posessing the clusterconfigentry:create and clusterconfigentry:edit permissions are allowed to do so. These permissions are usually only granted to Admin users. Impact If a user with the appropriate permissions performs the request, arbitrary classes with 1-arg String constructors can be instantiated. This will execute…
Recommended action: Upgrade to 5.2.4 or 5.1.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A partial path traversal vulnerability exists in Graylog's Support Bundle feature. The vulnerability is caused by incorrect user input validation in an HTTP API resource. Thanks to weiweiwei9811 for reporting this vulnerability and providing detailed information. Impact Graylog's Support Bundle feature allows an attacker with valid Admin role credentials to download or delete files in sibling directories of the support bundle directory. The default datadir in operating system packages (DEB, RPM) is set to /var/lib/graylog-server. The data directory for the Support Bundle feature is always <datadir/support-bundle. Due to the partial path traversal vulnerability, an attacker with valid Admin role credentials can read or delete files in directories that start with a /var/lib/graylog-server/support-bundle directory name. The vulnerability would allow the download or deletion of files in the following example directories. - /var/lib/graylog-server/support-bundle-test -…
Recommended action: Upgrade to 5.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Graylog utilises only one single source port for DNS queries. Details Graylog seems to bind a single socket for outgoing DNS queries. That socket is bound to a random port number which is not changed again. This goes against recommended practice since 2008, when Dan Kaminsky discovered how easy is to carry out DNS cache poisoning attacks. In order to prevent cache poisoning with spoofed DNS responses, it is necessary to maximise the uncertainty in the choice of a source port for a DNS query. PoC The attached figure shows the source ports distribution difference between Graylog configured to use a data adapter based on DNS queries and ISC Bind. The source port distribution of the DNS queries sent from Graylog to a recursive DNS name server running Bind (CLIENTQUERY) are depicted in purple, while the queries sent from the recursive DNS server to the authoritatives (RESOLVERQUERY) are plotted in green color. As it can be observed, in contrast to ISC Bind which presents a…
Recommended action: Upgrade to 5.1.3 or 5.0.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In a multi-node Graylog cluster, after a user has explicitly logged out, a user session may still be used for API requests until it has reached its original expiry time. Details Each node maintains an in-memory cache of user sessions. Upon a cache-miss, the session is loaded from the database. After that, the node operates solely on the cached session. Modifications to sessions will update the cached version as well as the session persisted in the database. However, each node maintains their isolated version of the session. When the user logs out, the session is removed from the node-local cache and deleted from the database. The other nodes will however still use the cached session. These nodes will only fail to accept the session id if they intent to update the session in the database. They will then notice that the session is gone. This is true for most API requests originating from user interaction with the Graylog UI because these will lead to an update of the session's…
Recommended action: Upgrade to 5.1.3 or 5.0.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Graylog before v2.4.4 has an XSS security issue with unescaped text in dashboard names, related to components/dashboard/Dashboard.jsx, components/dashboard/EditDashboardModal.jsx, and pages/ShowDashboardPage.jsx.
Recommended action: Upgrade to 2.4.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Graylog before v2.4.4 has an XSS security issue with unescaped text in notifications, related to toastr and util/UserNotification.js.
Recommended action: Upgrade to 2.4.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Graylog before 2.4.6, XSS was possible in typeahead components, related to components/common/TypeAheadInput.jsx and components/search/QueryInput.ts.
Recommended action: Upgrade to 2.4.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.