{
  "containers": {
    "cna": {
      "providerMetadata": {
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09"
      },
      "title": "Brute force attack possible to determine valid user names",
      "problemTypes": [
        {
          "descriptions": [
            {
              "description": "CWE-208 Observable Timing Discrepancy",
              "lang": "en",
              "cweId": "CWE-208",
              "type": "CWE"
            }
          ]
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "affected": [
        {
          "vendor": "Apache Software Foundation",
          "product": "Apache Shiro",
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "packageName": "org.apache.shiro:shiro-core",
          "versions": [
            {
              "status": "affected",
              "version": "0",
              "lessThan": "2.0.7",
              "versionType": "semver"
            }
          ],
          "defaultStatus": "unaffected"
        }
      ],
      "descriptions": [
        {
          "value": "Observable Timing Discrepancy vulnerability in Apache Shiro.\n\nThis issue affects Apache Shiro: from 1.*, 2.* before 2.0.7.\n\nUsers are recommended to upgrade to version 2.0.7 or later, which fixes the issue.\n\nPrior to Shiro 2.0.7, code paths for non-existent vs. existing users are different enough,\nthat a brute-force attack may be able to tell, by timing the requests only, determine if\nthe request failed because of a non-existent user vs. wrong password.\n\nThe most likely attack vector is a local attack only.\nShiro security model\u00a0 https://shiro.apache.org/security-model.html#username_enumeration \u00a0discusses this as well.\n\nTypically, brute force attack can be mitigated at the infrastructure level.",
          "lang": "en",
          "supportingMedia": [
            {
              "type": "text/html",
              "base64": false,
              "value": "<p>Observable Timing Discrepancy vulnerability in Apache Shiro.</p><p>This issue affects Apache Shiro: from 1.*, 2.* before 2.0.7.</p><p>Users are recommended to upgrade to version 2.0.7 or later, which fixes the issue.</p>Prior to Shiro 2.0.7, code paths for non-existent vs. existing users are different enough,<br>that a brute-force attack may be able to tell, by timing the requests only, determine if<br>the request failed because of a non-existent user vs. wrong password.<br><br>The most likely attack vector is a local attack only.<br>Shiro security model&nbsp;<a target=\"_blank\" rel=\"nofollow\" href=\"https://shiro.apache.org/security-model.html#username_enumeration\">https://shiro.apache.org/security-model.html#username_enumeration</a>&nbsp;discusses this as well.<br><br>Typically, brute force attack can be mitigated at the infrastructure level."
            }
          ]
        }
      ],
      "references": [
        {
          "url": "https://lists.apache.org/thread/mm1jct9b86jvnh3y44tj22xvjtx3xhhh",
          "tags": [
            "vendor-advisory"
          ]
        }
      ],
      "metrics": [
        {
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ],
          "cvssV4_0": {
            "version": "4.0",
            "attackVector": "LOCAL",
            "attackComplexity": "HIGH",
            "attackRequirements": "PRESENT",
            "privilegesRequired": "LOW",
            "userInteraction": "ACTIVE",
            "vulnConfidentialityImpact": "LOW",
            "subConfidentialityImpact": "LOW",
            "vulnIntegrityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "vulnAvailabilityImpact": "NONE",
            "subAvailabilityImpact": "NONE",
            "Safety": "NEGLIGIBLE",
            "Automatable": "YES",
            "Recovery": "AUTOMATIC",
            "valueDensity": "CONCENTRATED",
            "vulnerabilityResponseEffort": "LOW",
            "providerUrgency": "GREEN",
            "baseSeverity": "LOW",
            "baseScore": 1,
            "vectorString": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:A/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/S:N/AU:Y/R:A/V:C/RE:L/U:Green"
          }
        },
        {
          "other": {
            "type": "Textual description of severity",
            "content": {
              "text": "low"
            }
          }
        }
      ],
      "credits": [
        {
          "lang": "en",
          "value": "4ra1n",
          "type": "finder"
        },
        {
          "lang": "en",
          "value": "Y4tacker",
          "type": "finder"
        },
        {
          "lang": "en",
          "value": "lprimak",
          "type": "remediation developer"
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "cveId": "CVE-2026-23901",
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "serial": 1,
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}