Overview 14 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
14matches
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
14
100.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
14
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
3
21.4%
Forecast only
0
0.0%
No public exploit
11
78.6%
split by
peak 4 / year
20183
No exploit published3
Medium3
not blocked3
No public exploit3
20190
20200
20210
20220
20232
No exploit published2
Medium1
Low1
not blocked2
Proof of concept only2
20242
No exploit published2
High1
Medium1
not blocked2
Proof of concept only1
No public exploit1
20253
No exploit published3
High2
Medium1
not blocked3
No public exploit3
20264
No exploit published4
High1
Medium3
not blocked4
No public exploit4
201820192020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-69190 | Medium | 2026-09-21 | No exploit published | No public exploit | Graylog is a free and open log management platform. From 6.3.0 until 6.3.14, 7.0.9, and 7.1.4, 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. The selected account can then delete the saved search or dashboard or remove the original owner's access. Graylog Cloud was patched before the advisory was published. This issue is fixed in versions 6.3.14, 7.0.9, and 7.1.4. |
| CVE-2026-55867 | Medium | 2026-08-28 | No exploit published | No public exploit | Graylog is a free and open log management platform. From 6.2.0 until 6.3.12, 7.0.7, and 7.1.2, the DELETE /users/{userId}/tokens/{idOrToken} endpoint implemented by UsersResource.revokeToken() in graylog2-server/src/main/java/org/graylog2/rest/resources/users/UsersResource.java checks USERS_TOKENREMOVE permission against the attacker-controlled userId path parameter before resolving the token selected by idOrToken. An authenticated user can provide an authorized userId while accessTokenService.loadById() or accessTokenService.load() resolves a token belonging to another user, including a service account or administrator, after which accessTokenService.destroy() deletes that token without checking AccessToken.getUserName(). The issue does not expose token contents, but unauthorized deletion causes integrity impact and can disrupt access-token-based integrations. This issue is fixed in versions 6.3.12, 7.0.7, and 7.1.2. |
| CVE-2026-55841 | High | 2026-08-28 | No exploit published | No public exploit | Graylog is a free and open log management platform. Prior to Graylog Server versions 6.3.12, 7.0.7, and 7.1.2 and Graylog Forwarder version 7.3, the FortiGate key-value syslog parser in graylog2-server/src/main/java/org/graylog2/inputs/codecs/GLFortiGateSyslogEvent.java and graylog2-server/src/main/java/org/graylog2/inputs/codecs/SyslogCodec.java mishandles field-like text inside quoted values. GLFortiGateSyslogEvent.getFields() uses KV_PATTERN and QUOTED_KV_PATTERN, while SyslogCodec.parse() invokes the FortiGateSyslogEvent parser; crafted values containing = or backslash-escaped quotes can cause embedded keys such as srcip, dstip, date, time, and tz to remove or overwrite original top-level fields or produce an invalid message that Graylog discards. An unauthenticated network sender who can submit syslog messages can therefore manipulate security-log fields or evade logging to obscure malicious activity. This issue is fixed in Graylog Server versions 6.3.12, 7.0.7, and 7.1.2 and Graylog Forwarder version 7.3. |
| CVE-2026-55425 | Medium | 2026-08-28 | No exploit published | No public exploit | Graylog is a free and open log management platform. From 7.1.0 until 7.1.4 and 7.2.0-alpha.2, the System Catalog entity titles endpoint in graylog2-server/src/main/java/org/graylog2/rest/resources/system/contentpacks/titles/EntityTitleServiceImpl.java allows an authenticated user to request composite display fields without verifying that every selected field is readable. A user can retrieve protected values, including the password hash on a readable user record; ordinary users are limited to their own permitted records, while administrators can retrieve hashes for all users. This issue is fixed in versions 7.1.4 and 7.2.0-alpha.2. |
| CVE-2025-53106 | High | 2025-07-02 | No exploit published | No public exploit | Graylog is a free and open log management platform. In versions 6.2.0 to before 6.2.4 and 6.3.0-alpha.1 to before 6.3.0-rc.2, 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. This issue has been patched in versions 6.2.4 and 6.3.0-rc.2. A workaround involves disabling the respective configuration found in System > Configuration > Users > "Allow users to create personal access tokens". |
| CVE-2025-46827 | High | 2025-05-07 | No exploit published | No public exploit | Graylog is a free and open log management platform. Prior to versions 6.0.14, 6.1.10, and 6.2.0, 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). Versions 6.0.14, 6.1.10, and 6.2.0 fix the issue. No known workarounds are available, as long as the relatively rare prerequisites are met. |
| CVE-2025-30373 | Medium | 2025-04-07 | No exploit published | No public exploit | Graylog is a free and open log management platform. 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. To mitigate the vulnerability, disable http-based inputs and allow only authenticated pull-based inputs. This vulnerability is fixed in 6.1.9. |
| CVE-2024-24824 | High | 2024-02-07 | No exploit published | Proof of concept only | Graylog is a free and open log management platform. Starting in version 2.0.0 and prior to versions 5.1.11 and 5.2.4, arbitrary classes can be loaded and instantiated using a HTTP PUT request to the `/api/system/cluster_config/` endpoint. 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. If a user with the appropriate permissions performs the request, arbitrary classes with 1-arg String constructors can be instantiated. This will execute arbitrary code that is run during class instantiation. In the specific use case of `java.io.File`, the behavior of the internal web-server stack will lead to information exposure by including the entire file content in the response to the REST request. Versions 5.1.11 and 5.2.4 contain a fix for this issue. |
| CVE-2024-24823 | Medium | 2024-02-07 | No exploit published | No public exploit | Graylog is a free and open log management platform. Starting in version 4.3.0 and prior to versions 5.1.11 and 5.2.4, 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 a cross-site scripting attack. No such attack has been discovered. 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. Some workarounds are available. 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 `authentication` cookie for the Graylog server URL for the `/api/system/sessions` endpoint, as that is the only one vulnerable. |
| CVE-2023-41045 | Medium | 2023-08-31 | No exploit published | Proof of concept only | Graylog is a free and open log management platform. Graylog makes use of only one single source port for DNS queries. Graylog binds a single socket for outgoing DNS queries and while that socket is bound to a random port number it is never 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. Although unlikely in many setups, an external attacker could inject forged DNS responses into a Graylog's lookup table cache. In order to prevent this, it is at least recommendable to distribute the DNS queries through a pool of distinct sockets, each of them with a random source port and renew them periodically. This issue has been addressed in versions 5.0.9 and 5.1.3. Users are advised to upgrade. There are no known workarounds for this issue. |
| CVE-2023-41041 | Low | 2023-08-30 | No exploit published | Proof of concept only | Graylog is a free and open log management platform. 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. 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 "last access" timestamp. If the session update is however prevented by setting the `X-Graylog-No-Session-Extension:true` header in the request, the node will consider the (cached) session valid until the session is expired according to its timeout setting. No session identifiers are leaked. After a user has logged out, the UI shows the login screen again, which gives the user the impression that their session is not valid anymore. However, if the session becomes compromised later, it can still be used to perform API requests against the Graylog cluster. The time frame for this is limited to the configured session lifetime, starting from the time when the user logged out. This issue has been addressed in versions 5.0.9 and 5.1.3. Users are advised to upgrade. |
| CVE-2018-14380 | Medium | 2018-07-18 | No exploit published | No public exploit | In Graylog before 2.4.6, XSS was possible in typeahead components, related to components/common/TypeAheadInput.jsx and components/search/QueryInput.ts. |
| CVE-2018-11651 | Medium | 2018-06-01 | No exploit published | No public exploit | 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. |
| CVE-2018-11650 | Medium | 2018-06-01 | No exploit published | No public exploit | Graylog before v2.4.4 has an XSS security issue with unescaped text in notifications, related to toastr and util/UserNotification.js. |