CVE-2026-44825 is a hardcoded credentials vulnerability in Apache Solr’s Basic Authentication setup tool, Exploitation requires no prior authentication. When an administrator uses The practical impact is full administrative control of the cluster. An attacker who authenticates as Apache Solr versions 9.4.0 through 9.10.1 and version 10.0.0 are affected. The vulnerability is specific to SolrCloud deployments where administrators have enabled Basic Authentication using Apache Solr powers enterprise search, e-commerce product catalogs, log analytics pipelines, and document management platforms across a wide range of industries. SolrCloud clusters are commonly internet-facing or reachable from cloud environments, and administrative interfaces are often left accessible beyond the intended perimeter during initial setup or after infrastructure changes.<\/p>\n\n\n\n The silent installation of template accounts compounds the risk: administrators who verify their own account credentials after setup have no obvious reason to check for additional accounts they did not create. The template users may persist for extended periods without detection.<\/p>\n\n\n\n Using the CyCognito platform, we identified externally reachable Apache Solr assets that may be exposed to this issue across a range of industries. Because no asset file was provided for this advisory, per-sector percentages are not available for this post.<\/p>\n\n\n\n The nature of Apache Solr deployments, widely adopted across data-heavy industries including retail, media, financial services, and enterprise IT, suggests that exposure is broadly distributed rather than concentrated in a single sector. Organizations running Solr as part of search or analytics infrastructure often inherit the software through platform bundles or third-party applications, which can delay visibility into version currency and authentication state.<\/p>\n\n\n\n Cross-sector deployments of this kind also tend to accumulate transitional infrastructure: Solr clusters stood up for a specific application and never decommissioned, or upgraded to a new version in production while older instances remain accessible in staging or development environments.<\/p>\n\n\n\n Patches are available. Apache has released Solr 9.11.0 and 10.1.0 to address CVE-2026-44825. Organizations running any version from 9.4.0 through 9.10.1, or version 10.0.0, should upgrade to the respective fixed release.<\/p>\n\n\n\n For deployments where an immediate upgrade is not possible, Apache recommends deleting the template accounts created by Defenders should verify directly with Apache’s security advisory and their deployment’s Until patching is confirmed, defenders should:<\/p>\n\n\n\nbin\/solr auth enable<\/code>, that can silently install undocumented template accounts with publicly known default credentials, giving a remote attacker full administrative access to the SolrCloud cluster. The vulnerability carries a CVSS v3.1 base score of 8.1 (High).<\/p>\n\n\n\nbin\/solr auth enable<\/code> to configure BasicAuth, the tool writes a security.json<\/code> file that may include additional template user accounts, including accounts named superadmin<\/code>, admin<\/code>, search<\/code>, and index<\/code>, each configured with a password that matches the username. Because the credentials are identical to documented defaults, any attacker aware of the issue can attempt authentication with no additional reconnaissance.<\/p>\n\n\n\nsuperadmin<\/code> can read, modify, or delete any index, alter cluster configuration, and pivot to any system the Solr cluster is authorized to reach.<\/p>\n\n\n\nWhat assets are affected by CVE-2026-44825?<\/h2>\n\n\n\n
bin\/solr auth enable<\/code>. Deployments that configured BasicAuth through other means, or that never enabled BasicAuth at all, are not affected by this specific issue.<\/p>\n\n\n\nWhat does our data show about exposure patterns?<\/h2>\n\n\n\n
Are fixes available?<\/h2>\n\n\n\n
bin\/solr auth enable<\/code>. The accounts to audit and remove are superadmin<\/code>, admin<\/code>, search<\/code>, and index<\/code>. These accounts are defined in security.json<\/code> and can be removed or have their credentials rotated through the Solr Security API.<\/p>\n\n\n\nsecurity.json<\/code> contents rather than assuming a prior authentication review was comprehensive. The absence of self-created accounts with weak credentials does not rule out the presence of silently installed template accounts.<\/p>\n\n\n\nAre there any other recommended actions to take?<\/h2>\n\n\n\n