<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Thu, 01 Oct 2026 23:49:45 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-54746</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-54746</link>
      <description>&lt;p&gt;Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. From 0.40.0 until 0.91.1, the Dispatcher gRPC service does not verify that a request&amp;#39;s worker ID belongs to the tenant identified by the bearer-token context in Dispatcher/UpsertWorkerLabels and Dispatcher/Unsubscribe. An authenticated owner of any tenant who guesses another tenant&amp;#39;s worker UUID can overwrite that worker&amp;#39;s affinity labels or disconnect the worker from the dispatcher. This can cause cross-tenant integrity impact and denial of service on multi-tenant Hatchet Cloud or shared self-hosted deployments. Single-tenant deployments are not practically affected because the attacker and target tenant are the same. This issue is fixed in version 0.91.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. From 0.40.0 until 0.91.1, the Dispatcher gRPC service does not verify that a request&amp;#39;s worker ID belongs to the tenant identified by the bearer-token context in Dispatcher/UpsertWorkerLabels and Dispatcher/Unsubscribe. An authenticated owner of any tenant who guesses another tenant&amp;#39;s worker UUID can overwrite that worker&amp;#39;s affinity labels or disconnect the worker from the dispatcher. This can cause cross-tenant integrity impact and denial of service on multi-tenant Hatchet Cloud or shared self-hosted deployments. Single-tenant deployments are not practically affected because the attacker and target tenant are the same. This issue is fixed in version 0.91.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-54746</guid>
    </item>
    <item>
      <title>GHSA-8x7x-83cf-c3pg — Hatchet allows cross-tenant write/DoS to other tenants' workers via Dispatcher gRPC UpsertWorkerLabels and Unsubscribe</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-8x7x-83cf-c3pg</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/hatchet-dev/hatchet&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A **cross-tenant write / DoS** vulnerability in the Hatchet `Dispatcher` gRPC service allows any holder of a normal tenant-scoped API token (the lowest credential Hatchet issues — an `OWNER` of a brand-new tenant) to overwrite the affinity labels of, or disconnect from the dispatcher, any worker UUID belonging to any other tenant on the same Hatchet instance. The two affected RPCs — `Dispatcher/UpsertWorkerLabels` and `Dispatcher/Unsubscribe` — read the caller&amp;#39;s tenant from the bearer-token context only for analytics and response shaping, and never use it to authorise the `worker_id` from the request body.&lt;/p&gt;
&lt;p&gt;### Impact
This CVE requires the attacker to successfully guess the target UUID. 
**Who is impacted.** Any Hatchet deployment that hosts more than one tenant on the same instance:
- **Hatchet Cloud (multi-tenant SaaS)** — every tenant is exposed to every other tenant.
- **Self-hosted Hatchet with multiple internal teams / business units sharing one instance** — each team is exposed to every other team on the box.
- **Any deployment where a single tenant&amp;#39;s API token can be obtained by an attacker** (e.g. a leaked low-privilege CI token from a single tenant). One token is enough to attack every other tenant on the same instance.&lt;/p&gt;
&lt;p&gt;Single-tenant self-hosted deployments are unaffected in practice (the &amp;#34;victim&amp;#34; and &amp;#34;attacker&amp;#34; tenants would be the same).&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/hatchet-dev/hatchet&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A **cross-tenant write / DoS** vulnerability in the Hatchet `Dispatcher` gRPC service allows any holder of a normal tenant-scoped API token (the lowest credential Hatchet issues — an `OWNER` of a brand-new tenant) to overwrite the affinity labels of, or disconnect from the dispatcher, any worker UUID belonging to any other tenant on the same Hatchet instance. The two affected RPCs — `Dispatcher/UpsertWorkerLabels` and `Dispatcher/Unsubscribe` — read the caller&amp;#39;s tenant from the bearer-token context only for analytics and response shaping, and never use it to authorise the `worker_id` from the request body.&lt;/p&gt;
&lt;p&gt;### Impact
This CVE requires the attacker to successfully guess the target UUID. 
**Who is impacted.** Any Hatchet deployment that hosts more than one tenant on the same instance:
- **Hatchet Cloud (multi-tenant SaaS)** — every tenant is exposed to every other tenant.
- **Self-hosted Hatchet with multiple internal teams / business units sharing one instance** — each team is exposed to every other team on the box.
- **Any deployment where a single tenant&amp;#39;s API token can be obtained by an attacker** (e.g. a leaked low-privilege CI token from a single tenant). One token is enough to attack every other tenant on the same instance.&lt;/p&gt;
&lt;p&gt;Single-tenant self-hosted deployments are unaffected in practice (the &amp;#34;victim&amp;#34; and &amp;#34;attacker&amp;#34; tenants would be the same).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-8x7x-83cf-c3pg</guid>
    </item>
  </channel>
</rss>
