July 2026 CVE of the Month: The Apache Solr Backdoor You Installed on Purpose (CVE-2026-44825)
Four years ago I wrote a monthly column at Kenna Security about the vulnerabilities the headlines were missing. It's back: same idea, better models. A year ago this week, every security team in the world was sprinting to patch SharePoint's ToolShell. This series is about the other kind of vulnerability, the kind that is covered in the feeds and present in the scanners but sitting nowhere near the top of anyone's queue, even while our exploitation telemetry says it should be. This month's pick comes with a particularly cruel twist: it only affects the administrators who tried to do the right thing.
This month's CVE of the Month is CVE-2026-44825
From the advisory description
Hardcoded credentials in the Basic Authentication setup tool (bin/solr auth enable) in Apache Solr versions 9.4.0 through 9.10.1 and 10.0.0 allows a remote attacker to gain full administrative access to the cluster via publicly known default credentials installed silently alongside the user-specified account.
As an immediate workaround without upgrading, delete the template users (superadmin, admin, search, index) from security.json or change their passwords. The future, not yet released, versions 9.11.0 and 10.1.0 will not be vulnerable, and it will be enough to upgrade to solve the issue.
Not affected: Clusters where bin/solr auth enable was not used to bootstrap BasicAuth Clusters where template users have been assigned strong passwords after bootstrap
CVE-2026-44825 was published June 1, 2026, affecting Apache (solr).
At a glance
Why CVE-2026-44825 matters
• The Empirical Global model places it in the 99th percentile of all scored CVEs.
• Empirical's exploitation telemetry shows in-the-wild exploitation within the last 7 days (most recent activity July 18, 2026). This signal is from our own sensors and is not yet reflected in public feeds like KEV.
• Our classifier flags 1 GitHub repository as possible proof-of-concept code (unconfirmed, and not a driver of the score).
Solr is the search engine hiding inside the enterprise: product catalogs, document repositories, log and case-management search, and a long list of commercial products that embed it (IBM's advisory for Operational Decision Manager is already in the reference list below; if you don't run Solr directly, check what does). Here's the twist that makes this one sting. The vulnerability only exists on clusters where an administrator ran bin/solr auth enable, the official tool for turning authentication on. Alongside the admin account you created, the tool silently installed four template users (superadmin, admin, search, and index) with publicly known default passwords. There is no exploit to develop and no memory corruption to win; an attacker simply logs in, and full administrative control of the cluster means reading or tampering with every document in every collection. Security teams that diligently enabled auth believe these clusters are locked down. They aren't.
What's driving the score?
| Indicator | Weight | Detail |
|---|---|---|
| Exploitation | +3.82 | 1-7 days (2, wt=4); 31-90 days (1, wt=0.2) |
| Vuln Attributes | +0.12 | Nothing Interesting |
| Threat Intel | -0.09 | Nothing Interesting |
| Exploit Code | -0.02 | GitHub (0, wt=-0.02); ExploitDB (0, wt=0.005); Metasploit (0, wt=0.002) |
| Chatter | -0.02 | Sightings (29, wt=-0.01) |
| Vendor | +0.01 | Nothing Significant |
| References | -0.00 | CVE Refs (2, wt=-0.006) |
Bottom line
Be clear about where this signal comes from: the 99th-percentile Global score is driven almost entirely by exploitation activity observed in Empirical's own telemetry, activity that hasn't yet reached the public feeds. It isn't in CISA KEV. EPSS, which forecasts exploitation from public signals, currently scores it 0.005 (68th percentile; EPSS v3 says 84th), well below the roughly 0.1 threshold many EPSS-driven programs use as their remediation cut line. None of those systems is wrong; they just see the world later than a sensor does. A composite CVSS+KEV+EPSS policy will schedule this bug behind noisier CVEs, and our sensors say attackers are not waiting for the paperwork. That gap, between what is being exploited and what the public signals have caught up to, is exactly what this column exists to close.
Mitigation status
Per the Apache advisory, versions 9.4.0 through 9.10.1 and 10.0.0 are affected, and the fix is slated for 9.11.0 and 10.1.0. We checked the Apache Solr downloads page today (July 20): neither fixed version has shipped yet, so the workaround is the remediation. Delete the template users (superadmin, admin, search, index) or assign them strong passwords. One operational note: on SolrCloud, security.json lives in ZooKeeper, not on the local filesystem, so manage the accounts through Solr's Authentication API rather than grepping disks and concluding you're safe. Clusters that never used bin/solr auth enable to bootstrap Basic Authentication, or that already re-passworded the template accounts, are not affected. To find exposure at scale, scanner coverage exists (Tenable plugin 318228 is in the references). And before assuming you're clean, remember that a default Solr install does not log authenticated usernames. Check audit logging if you've enabled it, or the access logs of whatever proxy or load balancer fronts the cluster; an exposed, unremediated cluster with no log trail should be treated as suspect, not clean.
References
https://nvd.nist.gov/vuln/detail/CVE-2026-44825
https://www.cisa.gov/news-events/bulletins/sb26-159
https://lists.apache.org/thread/5xg6xr99glocp3zsg9ht2zlbwlrst7ch
https://securityonline.info/apache-solr-default-credentials-cve-2026-44825
https://www.mail-archive.com/announce@apache.org/msg11159.html
http://www.openwall.com/lists/oss-security/2026/05/29/6
https://access.redhat.com/security/cve/cve-2026-44825
https://bsky.app/profile/cyberhub.blog/post/3mnbe3fsyxi26
Every month we feature a CVE where our Global model's output diverges sharply from the conventional signals, and we show our work. Empirical customers get the same signals (exploitation telemetry, exploit-code intelligence, and percentile-ranked prioritization) across their entire vulnerability portfolio, every day. See how your portfolio ranks at empiricalsecurity.com.
