Apache Solr EUVD-2026-33602

Exploitation requires that the target Solr cluster was bootstrapped for Basic Authentication using the 'bin/solr auth enable' setup tool on an affected version (9.4.0-9.10.1 or 10.0.0), AND that at least one of the auto-installed template users (superadmin, admin, search, index) still carries its publicly known default password. Where those conditions hold, an unauthenticated remote attacker (PR:N) needs only network reachability to the Solr endpoint and knowledge of the default credentials - no user interaction, no special complexity. Exploitation is explicitly limited by configuration: clusters that never used 'bin/solr auth enable' to bootstrap BasicAuth, or that assigned strong passwords to the template users after bootstrap, are not affected. Network exposure of the Solr admin API is the other practical limiter.

The signals are genuinely mixed and should be reconciled rather than taken at face value. CVSS 3.1 is 9.8 (AV:N/AC:L/PR:N/UI:N, full C/I/A) and SSVC rates technical impact as 'total', consistent with complete cluster compromise via known credentials. However, SSVC also marks Exploitation as 'none' and Automatable as 'no', and EPSS is only 0.21% (44th percentile), so there is no evidence of active exploitation or mass automated scanning yet. Crucially, exploitability is gated by a deployment condition not reflected in the raw vector: the cluster must have been bootstrapped with 'bin/solr auth enable' AND still retain the default template passwords - clusters that never used that tool, or that re-passworded the template users, are not affected. This means the 9.8 accurately describes worst-case impact but overstates population-wide exploitability; the practical priority is 'urgently audit whether your Solr security.json contains the template users,' not 'assume every Solr instance is instantly ownable.' No KEV listing exists, so this is not confirmed in-the-wild exploitation.

An attacker discovers an internet- or intranet-reachable Solr instance and simply logs into the admin API using one of the publicly documented default template credentials (e.g., the superadmin account) that 'bin/solr auth enable' installed. With full administrative access they can read or exfiltrate all indexed data, alter collections, and leverage Solr's config/plugin capabilities to pivot toward remote code execution. No exploit code is required beyond the known username/password pair; no public exploit has been identified, but the technique is trivial where the condition holds.