FKIE_CVE-2026-22444

Vulnerability from fkie_nvd - Published: 2026-01-21 14:16 - Updated: 2026-01-27 20:30
Severity ?
7.1 (High) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
Summary
The "create core" API of Apache Solr 8.6 through 9.10.0 lacks sufficient input validation on some API parameters, which can cause Solr to check the existence of and attempt to read file-system paths that should be disallowed by Solr's "allowPaths" security setting https://https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solr-element .  These read-only accesses can allow users to create cores using unexpected configsets if any are accessible via the filesystem.  On Windows systems configured to allow UNC paths this can additionally cause disclosure of NTLM "user" hashes.  Solr deployments are subject to this vulnerability if they meet the following criteria: * Solr is running in its "standalone" mode. * Solr's "allowPath" setting is being used to restrict file access to certain directories. * Solr's "create core" API is exposed and accessible to untrusted users.  This can happen if Solr's RuleBasedAuthorizationPlugin https://solr.apache.org/guide/solr/latest/deployment-guide/rule-based-authorization-plugin.html is disabled, or if it is enabled but the "core-admin-edit" predefined permission (or an equivalent custom permission) is given to low-trust (i.e. non-admin) user roles. Users can mitigate this by enabling Solr's RuleBasedAuthorizationPlugin (if disabled) and configuring a permission-list that prevents untrusted users from creating new Solr cores.  Users should also upgrade to Apache Solr 9.10.1 or greater, which contain fixes for this issue.
References
security@apache.orghttps://lists.apache.org/thread/qkrb9dd4xrlqmmq73lrhkbfkttto2d1mMailing List
af854a3a-2127-422b-91ae-364da2661108http://www.openwall.com/lists/oss-security/2026/01/20/5Mailing List
Impacted products
Vendor Product Version
apache solr *
To clipboard 

{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:apache:solr:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "8EEA3BEF-03F1-4D74-A368-95EDEAA65966",
              "versionEndExcluding": "9.10.1",
              "versionStartIncluding": "8.6.0",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "The \"create core\" API of Apache Solr 8.6 through 9.10.0 lacks sufficient input validation on some API parameters, which can cause Solr to check the existence of and attempt to read file-system paths that should be disallowed by Solr\u0027s  \"allowPaths\" security setting https://https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solr-element .\u00a0 These read-only accesses can allow users to create cores using unexpected configsets if any are accessible via the filesystem.\u00a0 On Windows systems configured to allow UNC paths this can additionally cause disclosure of NTLM \"user\" hashes.\u00a0\n\nSolr deployments are subject to this vulnerability if they meet the following criteria:\n  *  Solr is running in its \"standalone\" mode.\n  *  Solr\u0027s \"allowPath\" setting is being used to restrict file access to certain directories.\n  *  Solr\u0027s \"create core\" API is exposed and accessible to untrusted users.\u00a0 This can happen if Solr\u0027s  RuleBasedAuthorizationPlugin https://solr.apache.org/guide/solr/latest/deployment-guide/rule-based-authorization-plugin.html  is disabled, or if it is enabled but the \"core-admin-edit\" predefined permission (or an equivalent custom permission) is given to low-trust (i.e. non-admin) user roles.\n\nUsers can mitigate this by enabling Solr\u0027s RuleBasedAuthorizationPlugin (if disabled) and configuring a permission-list that prevents untrusted users from creating new Solr cores.\u00a0 Users should also upgrade to Apache Solr 9.10.1 or greater, which contain fixes for this issue."
    },
    {
      "lang": "es",
      "value": "La API \u0027create core\u0027 de Apache Solr 8.6 hasta 9.10.0 carece de suficiente validaci\u00f3n de entrada en algunos par\u00e1metros de la API, lo que puede hacer que Solr compruebe la existencia e intente leer rutas del sistema de archivos que deber\u00edan ser denegadas por la configuraci\u00f3n de seguridad \u0027allowPaths\u0027 de Solr https://https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solr-element . Estos accesos de solo lectura pueden permitir a los usuarios crear n\u00facleos utilizando conjuntos de configuraci\u00f3n (configsets) inesperados si alguno es accesible a trav\u00e9s del sistema de archivos. En sistemas Windows configurados para permitir rutas UNC, esto puede causar adicionalmente la divulgaci\u00f3n de hashes NTLM de \u0027usuario\u0027.\n\nLas implementaciones de Solr est\u00e1n sujetas a esta vulnerabilidad si cumplen los siguientes criterios:\n  * Solr se est\u00e1 ejecutando en su modo \u0027standalone\u0027.\n  * La configuraci\u00f3n \u0027allowPath\u0027 de Solr se est\u00e1 utilizando para restringir el acceso a archivos a ciertos directorios.\n  * La API \u0027create core\u0027 de Solr est\u00e1 expuesta y es accesible para usuarios no confiables. Esto puede ocurrir si el RuleBasedAuthorizationPlugin de Solr https://solr.apache.org/guide/solr/latest/deployment-guide/rule-based-authorization-plugin.html est\u00e1 deshabilitado, o si est\u00e1 habilitado pero el permiso predefinido \u0027core-admin-edit\u0027 (o un permiso personalizado equivalente) se otorga a roles de usuario de baja confianza (es decir, no administradores).\n\nLos usuarios pueden mitigar esto habilitando el RuleBasedAuthorizationPlugin de Solr (si est\u00e1 deshabilitado) y configurando una lista de permisos que impida a los usuarios no confiables crear nuevos n\u00facleos de Solr. Los usuarios tambi\u00e9n deber\u00edan actualizar a Apache Solr 9.10.1 o superior, que contienen correcciones para este problema."
    }
  ],
  "id": "CVE-2026-22444",
  "lastModified": "2026-01-27T20:30:40.703",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 7.1,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "LOW",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 4.2,
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-01-21T14:16:06.707",
  "references": [
    {
      "source": "security@apache.org",
      "tags": [
        "Mailing List"
      ],
      "url": "https://lists.apache.org/thread/qkrb9dd4xrlqmmq73lrhkbfkttto2d1m"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Mailing List"
      ],
      "url": "http://www.openwall.com/lists/oss-security/2026/01/20/5"
    }
  ],
  "sourceIdentifier": "security@apache.org",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-20"
        }
      ],
      "source": "security@apache.org",
      "type": "Secondary"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.