<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T00:15:28.147857+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-55867</id>
    <title>fkie_cve-2026-55867</title>
    <updated>2026-10-02T00:15:28.163892+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-55867"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-j769-9gv9-65gr</id>
    <title>GHSA-j769-9gv9-65gr — Graylog token revocation endpoint allows authenticated users to delete other users’ access tokens</title>
    <updated>2026-10-02T00:15:28.163960+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Maven: org.graylog2:graylog2-server</p>
<p>### Impact</p>
<p>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.</p>
<p>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.</p>
<p>### Patches</p>
<p>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.</p>
<p>Graylog Cloud has already been patched.</p>
<p>### Workarounds</p>
<p>There are no feasible workarounds for this issue. Upgrading to a patched version is recommended.</p>
<p>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 user`.</p>
<p>### Credits</p>
<p>Thanks to [michaelddickenson](https://github.com/michaelddickenson) and [sreelim](https://github.com/sreelim) for reporting.</p>
<p>[^1]: https://go2docs.graylog.org/current/interacting_with_your_log_data/audit_log.html</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-j769-9gv9-65gr"/>
  </entry>
</feed>
