https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 01:26:37 +0000 https://vulnerability.circl.lu/vuln/cve-2026-82428 <p><strong>Affected:</strong> Apache Software Foundation Apache Storm Client</p> <p>Description</p> <p>Dependency artifacts uploaded with `storm jar --artifacts` were stored under a blob key derived only from the Maven coordinate, for example `dep---.jar`. The key was therefore identical for every user of the cluster and predictable in advance. When the blob already existed, the uploader caught `KeyAlreadyExistsException` and silently reused it, with no check that the existing blob&#39;s content or owner matched the artifact the submitter had resolved.</p> <p>A user who uploaded a blob under such a key first therefore controlled the bytes that every later submitter of the same coordinate would receive on the worker classpath, resulting in code execution inside another tenant&#39;s topology.</p> <p>This affects deployments where more than one principal may create blobs and where the `--artifacts` dependency feature is used.</p> <p>Mitigation</p> <p>Upgrade to 3.1.0, where each uploaded artifact receives a key carrying a freshly generated UUID and a pre-existing blob is no longer silently reused.</p> <p>Note that the corrected key generation is on the SUBMITTING CLIENT, so upgrading the cluster alone does not close this; every client that runs `storm jar --artifacts` must also be upgraded. Operators should audit existing `dep-` blobs for unexpected owners before upgrading. Users who cannot upgrade immediately should avoid the `--artifacts` mechanism in multi-tenant clusters and distribute dependencies inside the topology jar instead.</p> <p>Credit</p> <p>The ASF -- found using Claude agents to study the security o…</p> <p><strong>Affected:</strong> Apache Software Foundation Apache Storm Client</p> <p>Description</p> <p>Dependency artifacts uploaded with `storm jar --artifacts` were stored under a blob key derived only from the Maven coordinate, for example `dep---.jar`. The key was therefore identical for every user of the cluster and predictable in advance. When the blob already existed, the uploader caught `KeyAlreadyExistsException` and silently reused it, with no check that the existing blob&#39;s content or owner matched the artifact the submitter had resolved.</p> <p>A user who uploaded a blob under such a key first therefore controlled the bytes that every later submitter of the same coordinate would receive on the worker classpath, resulting in code execution inside another tenant&#39;s topology.</p> <p>This affects deployments where more than one principal may create blobs and where the `--artifacts` dependency feature is used.</p> <p>Mitigation</p> <p>Upgrade to 3.1.0, where each uploaded artifact receives a key carrying a freshly generated UUID and a pre-existing blob is no longer silently reused.</p> <p>Note that the corrected key generation is on the SUBMITTING CLIENT, so upgrading the cluster alone does not close this; every client that runs `storm jar --artifacts` must also be upgraded. Operators should audit existing `dep-` blobs for unexpected owners before upgrading. Users who cannot upgrade immediately should avoid the `--artifacts` mechanism in multi-tenant clusters and distribute dependencies inside the topology jar instead.</p> <p>Credit</p> <p>The ASF -- found using Claude agents to study the security o…</p> https://vulnerability.circl.lu/vuln/cve-2026-82428