Vulnerability-Lookup

GHSA-5F32-8637-HCRG

Vulnerability from github – Published: 2026-09-14 15:32 – Updated: 2026-09-14 21:31

Details

Description

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's content or owner matched the artifact the submitter had resolved.

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's topology.

This affects deployments where more than one principal may create blobs and where the --artifacts dependency feature is used.

Mitigation

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.

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.

Credit

The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-82428"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-14T15:17:09Z",
    "severity": "HIGH"
  },
  "details": "Description\n\nDependency artifacts uploaded with `storm jar --artifacts` were stored under a blob key derived only from\nthe Maven coordinate, for example `dep---.jar`. The key was therefore identical\nfor every user of the cluster and predictable in advance. When the blob already existed, the uploader\ncaught `KeyAlreadyExistsException` and silently reused it, with no check that the existing blob\u0027s content\nor owner matched the artifact the submitter had resolved.\n\nA user who uploaded a blob under such a key first therefore controlled the bytes that every later submitter\nof the same coordinate would receive on the worker classpath, resulting in code execution inside another\ntenant\u0027s topology.\n\nThis affects deployments where more than one principal may create blobs and where the `--artifacts`\ndependency feature is used.\n\nMitigation\n\nUpgrade to 3.1.0, where each uploaded artifact receives a key carrying a freshly generated UUID and a\npre-existing blob is no longer silently reused.\n\nNote that the corrected key generation is on the SUBMITTING CLIENT, so upgrading the cluster alone does not\nclose this; every client that runs `storm jar --artifacts` must also be upgraded. Operators should audit\nexisting `dep-` blobs for unexpected owners before upgrading. Users who cannot upgrade immediately should\navoid the `--artifacts` mechanism in multi-tenant clusters and distribute dependencies inside the topology\njar instead.\n\nCredit\n\nThe ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.",
  "id": "GHSA-5f32-8637-hcrg",
  "modified": "2026-09-14T21:31:38Z",
  "published": "2026-09-14T15:32:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82428"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/pj3fspp4l10fgk2jkvrnqsmxycmjv622"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/09/13/8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CVE-2026-82428 (GCVE-0-2026-82428)

Vulnerability from cvelistv5 – Published: 2026-09-14 14:18 – Updated: 2026-09-14 19:59

Title

Apache Storm Client: Cross-Tenant Dependency Jar Substitution via Predictable Blob Keys

Summary

Description 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's content or owner matched the artifact the submitter had resolved. 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's topology. This affects deployments where more than one principal may create blobs and where the `--artifacts` dependency feature is used. Mitigation 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. 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. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

Severity

8.8 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

SSVC

Exploitation: none Automatable: no Technical Impact: total

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-09-14 19:58 UTC

CWE

CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Assigner

apache mitre root

References

2 references

URL	Tags
https://lists.apache.org/thread/pj3fspp4l10fgk2jk…	vendor-advisory
http://www.openwall.com/lists/oss-security/2026/09/13/8

Impacted products

1 product

Vendor	Product	Version
Apache Software Foundation	Apache Storm Client	Affected: 3.0.0 , < 3.1.0 (semver)

Credits

The ASF using Claude Agents

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-09-14T15:13:41.895Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/09/13/8"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "NETWORK",
              "availabilityImpact": "HIGH",
              "baseScore": 8.8,
              "baseSeverity": "HIGH",
              "confidentialityImpact": "HIGH",
              "integrityImpact": "HIGH",
              "privilegesRequired": "LOW",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-82428",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-14T19:58:03.203886Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-14T19:59:04.884Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.storm:storm-client",
          "product": "Apache Storm Client",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "3.1.0",
              "status": "affected",
              "version": "3.0.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "The ASF using Claude Agents"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cb\u003eDescription\u003c/b\u003e\u003cbr\u003e\u003cbr\u003eDependency artifacts uploaded with `storm jar --artifacts` were stored under a blob key derived only from\u003cbr\u003ethe Maven coordinate, for example `dep---.jar`. The key was therefore identical\u003cbr\u003efor every user of the cluster and predictable in advance. When the blob already existed, the uploader\u003cbr\u003ecaught `KeyAlreadyExistsException` and silently reused it, with no check that the existing blob\u0027s content\u003cbr\u003eor owner matched the artifact the submitter had resolved.\u003cbr\u003e\u003cbr\u003eA user who uploaded a blob under such a key first therefore controlled the bytes that every later submitter\u003cbr\u003eof the same coordinate would receive on the worker classpath, resulting in code execution inside another\u003cbr\u003etenant\u0027s topology.\u003cbr\u003e\u003cbr\u003eThis affects deployments where more than one principal may create blobs and where the `--artifacts`\u003cbr\u003edependency feature is used.\u003cbr\u003e\u003cbr\u003e\u003cb\u003eMitigation\u003c/b\u003e\u003cbr\u003e\u003cbr\u003eUpgrade to 3.1.0, where each uploaded artifact receives a key carrying a freshly generated UUID and a\u003cbr\u003epre-existing blob is no longer silently reused.\u003cbr\u003e\u003cbr\u003eNote that the corrected key generation is on the SUBMITTING CLIENT, so upgrading the cluster alone does not\u003cbr\u003eclose this; every client that runs `storm jar --artifacts` must also be upgraded. Operators should audit\u003cbr\u003eexisting `dep-` blobs for unexpected owners before upgrading. Users who cannot upgrade immediately should\u003cbr\u003eavoid the `--artifacts` mechanism in multi-tenant clusters and distribute dependencies inside the topology\u003cbr\u003ejar instead.\u003cbr\u003e\u003cbr\u003e\u003cb\u003eCredit\u003c/b\u003e\u003cbr\u003e\u003cbr\u003eThe ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.\u003cbr\u003e"
            }
          ],
          "value": "Description\n\nDependency artifacts uploaded with `storm jar --artifacts` were stored under a blob key derived only from\nthe Maven coordinate, for example `dep---.jar`. The key was therefore identical\nfor every user of the cluster and predictable in advance. When the blob already existed, the uploader\ncaught `KeyAlreadyExistsException` and silently reused it, with no check that the existing blob\u0027s content\nor owner matched the artifact the submitter had resolved.\n\nA user who uploaded a blob under such a key first therefore controlled the bytes that every later submitter\nof the same coordinate would receive on the worker classpath, resulting in code execution inside another\ntenant\u0027s topology.\n\nThis affects deployments where more than one principal may create blobs and where the `--artifacts`\ndependency feature is used.\n\nMitigation\n\nUpgrade to 3.1.0, where each uploaded artifact receives a key carrying a freshly generated UUID and a\npre-existing blob is no longer silently reused.\n\nNote that the corrected key generation is on the SUBMITTING CLIENT, so upgrading the cluster alone does not\nclose this; every client that runs `storm jar --artifacts` must also be upgraded. Operators should audit\nexisting `dep-` blobs for unexpected owners before upgrading. Users who cannot upgrade immediately should\navoid the `--artifacts` mechanism in multi-tenant clusters and distribute dependencies inside the topology\njar instead.\n\nCredit\n\nThe ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-22",
              "description": "CWE-22  Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-14T14:18:09.921Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/pj3fspp4l10fgk2jkvrnqsmxycmjv622"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Storm Client: Cross-Tenant Dependency Jar Substitution via Predictable Blob Keys",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-82428",
    "datePublished": "2026-09-14T14:18:09.921Z",
    "dateReserved": "2026-08-29T10:09:55.176Z",
    "dateUpdated": "2026-09-14T19:59:04.884Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.