Loading vulnerability…
CVE-2026-22444 is an input validation flaw in the Apache Solr "create core" API affecting Solr 8.6 through 9.10.0. In standalone deployments, certain core-creation parameters are not validated sufficiently before Solr checks for the existence of and attempts to read filesystem paths that should be blocked by the configured "allowPaths" restriction. As a result, an attacker with access to the core-creation interface can induce read-only access attempts outside the intended path policy and, if suitable configsets are reachable on the filesystem, create cores using unexpected configsets. On Windows systems where UNC paths are permitted, the behavior can also trigger disclosure of NTLM user hashes during remote path access attempts.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
2 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos.
Repository purpose: an operational PoC exploit chain for CVE-2026-22444 (Apache Solr UNC path validation issue) targeting Windows Solr in standalone mode. The exploit abuses Solr core creation with a UNC-based configSet to coerce Solr into fetching an attacker-controlled configset over SMB before path validation occurs, then achieves RCE via a scripted update processor. Structure: - exploit.py: Main orchestrator. Starts a local SMB server (impacket SimpleSMBServer) sharing ./files, then sends an HTTP GET to /solr/admin/cores with action=CREATE and configSet=//<attacker_smb>/<share> to create a new core with attacker config. After core creation, it POSTs to /solr/<core>/update with wt=json and cmd=whoami to validate execution, then drops into an interactive loop that repeatedly POSTs to the same update endpoint with cmd=<user command> and prints stdout/stderr/exit_code from the JSON response. - files/conf/solrconfig.xml: Defines an updateRequestProcessorChain (rce-chain) using solr.StatelessScriptUpdateProcessorFactory to load rce.js, and makes it the default chain for /update. - files/rce.js: JavaScript payload executed inside Solr’s scripting processor. Reads request parameter 'cmd' and runs it via java.lang.Runtime.exec(["cmd.exe","/c",cmd]); captures stdout/stderr and returns them in the Solr response. If cmd is missing, launches calc.exe. - files/conf/schema.xml and managed-schema: Minimal schema to support update requests. - requirements.txt: requests + impacket. Exploit capabilities: 1) Hosts malicious Solr configset over SMB (attacker-controlled). 2) Remote core creation on target Solr via admin API with UNC configSet injection. 3) Remote command execution on Windows through Solr update processing, with output capture. 4) Interactive pseudo-shell over HTTP by repeatedly invoking /update with cmd parameter. Notable targeting assumptions: Solr admin endpoint reachable; authentication absent or attacker authorized to create cores; target can reach attacker SMB (TCP/445); payload is Windows-specific (cmd.exe/calc.exe).
Repository is a working exploit PoC for CVE-2026-22444 (Apache Solr UNC path validation issue) targeting Windows Solr in standalone mode. Structure: (1) exploit.py orchestrates the attack by starting an attacker-controlled SMB server (impacket SimpleSMBServer) exporting the local ./files directory as a share, then sending an HTTP GET to /solr/admin/cores with action=CREATE and configSet=//SMB_HOST/SHARE to coerce Solr into fetching a configset over UNC/SMB before path validation. (2) The exported configset under files/conf/ contains solrconfig.xml that sets a default update.chain (rce-chain) using solr.StatelessScriptUpdateProcessorFactory to run files/rce.js. (3) After core creation, exploit.py triggers execution by POSTing to /solr/{core}/update and passing a cmd parameter; rce.js executes cmd.exe /c <cmd> and returns stdout/stderr/exit_code in the JSON response, enabling an interactive shell loop in exploit.py. Fingerprintable targets/endpoints include the Solr admin cores endpoint, the per-core update endpoint, the UNC path //{smb_host}/{share_name}, and the SMB listener on 0.0.0.0:445. Overall purpose: achieve RCE by combining UNC-based configset loading with a scripted update processor chain that runs arbitrary OS commands.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
8 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A high-severity Apache Solr vulnerability involving insufficient file-access checking during core creation, enabling a file-access checking bypass.
Input validation flaw in Apache Solr create-core API enabling disallowed filesystem path checks/reads despite allowPaths restrictions; on Windows with UNC paths can disclose NTLM user hashes.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.