{
  "containers": {
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.storm:storm-webapp",
          "product": "Apache Storm Webapp",
          "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": "<b>Description</b><br><br>Three separate mechanisms allowed a web page on an unrelated origin to read responses that Storm's HTTP<br>components served to an authenticated user.<br><br>The Logviewer reflected the request's `Origin` header back in `Access-Control-Allow-Origin` while also<br>sending `Access-Control-Allow-Credentials: true`. The published security model documents a permissive<br>`Access-Control-Allow-Origin: *` posture as accepted, which is safe precisely because browsers refuse to<br>honour `*` together with credentials; reflecting the concrete origin removes that protection.<br><br>The shared CORS filter used by the UI, the Logviewer and DRPC was configured with a response header name<br>where an initialisation parameter name was expected. The container ignored the setting and applied its own<br>defaults, which allow credentials.<br><br>Finally, the UI and Logviewer wrapped API responses in a caller-supplied JSONP callback for every GET<br>request. A script element on any origin can load such a response, which bypasses the same-origin policy<br>entirely rather than negotiating it, and there was no way to turn the behaviour off.<br><br>In each case the effect is that a page visited by an authenticated operator can read cluster, topology and<br>log data on their behalf.<br><br><b>Mitigation</b><br><br>Upgrade to 3.1.0, where the Logviewer no longer reflects the request origin in a credentialed response, the<br>CORS filter is configured explicitly, and JSONP wrapping is governed by `ui.enable.jsonp`, which defaults to<br>false.<br><br>Note that disabling JSONP is a behaviour change for tooling that passes a `callback` query parameter; such<br>tooling should be moved to ordinary JSON requests.<br><br>Users who cannot upgrade immediately should place the UI, Logviewer and DRPC HTTP endpoints behind a reverse<br>proxy that strips `Access-Control-Allow-Origin` and `Access-Control-Allow-Credentials` from responses and<br>rejects requests carrying a `callback` parameter.<br><br><b>Credit</b><br><br>The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.<br>"
            }
          ],
          "value": "Description\n\nThree separate mechanisms allowed a web page on an unrelated origin to read responses that Storm's HTTP\ncomponents served to an authenticated user.\n\nThe Logviewer reflected the request's `Origin` header back in `Access-Control-Allow-Origin` while also\nsending `Access-Control-Allow-Credentials: true`. The published security model documents a permissive\n`Access-Control-Allow-Origin: *` posture as accepted, which is safe precisely because browsers refuse to\nhonour `*` together with credentials; reflecting the concrete origin removes that protection.\n\nThe shared CORS filter used by the UI, the Logviewer and DRPC was configured with a response header name\nwhere an initialisation parameter name was expected. The container ignored the setting and applied its own\ndefaults, which allow credentials.\n\nFinally, the UI and Logviewer wrapped API responses in a caller-supplied JSONP callback for every GET\nrequest. A script element on any origin can load such a response, which bypasses the same-origin policy\nentirely rather than negotiating it, and there was no way to turn the behaviour off.\n\nIn each case the effect is that a page visited by an authenticated operator can read cluster, topology and\nlog data on their behalf.\n\nMitigation\n\nUpgrade to 3.1.0, where the Logviewer no longer reflects the request origin in a credentialed response, the\nCORS filter is configured explicitly, and JSONP wrapping is governed by `ui.enable.jsonp`, which defaults to\nfalse.\n\nNote that disabling JSONP is a behaviour change for tooling that passes a `callback` query parameter; such\ntooling should be moved to ordinary JSON requests.\n\nUsers who cannot upgrade immediately should place the UI, Logviewer and DRPC HTTP endpoints behind a reverse\nproxy that strips `Access-Control-Allow-Origin` and `Access-Control-Allow-Credentials` from responses and\nrejects requests carrying a `callback` parameter.\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-346",
              "description": "CWE-346 Origin Validation Error",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-942",
              "description": "CWE-942 Permissive Cross-domain Security Policy with Untrusted Domains",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/2o7tl3hcdd865njxsn4d9cxp1frkctz3"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Authenticated API Responses Exposed to Arbitrary Web Origins",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "cveId": "CVE-2026-82438",
    "serial": 1,
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.0"
}