Apache Solr XXE remote code execution (CVE-2017-12629)

A single unauthenticated HTTP request is all it takes to turn an internet-facing Apache Solr search server into a remote shell. CVE-2017-12629 chains an XML External Entity (XXE) flaw in Solr's XML Query Parser with the platform's own RunExecutableListener feature to achieve full remote code execution (RCE) — no credentials, no social engineering, and in many historical deployments, no meaningful network segmentation standing in the way. Because Solr ships embedded inside dozens of downstream products (search appliances, CMS platforms, log analytics stacks, and internal developer tools), the blast radius of this bug extended well beyond teams who thought of themselves as "Solr users" at all.

What's actually vulnerable

CVE-2017-12629 is really two bugs wired together:

1. XXE in the XML Query Parser. When Solr is configured (or an attacker can coerce it) to parse a request using defType=xmlparser, the underlying XML parser resolves external entities by default. That lets an attacker define a DOCTYPE with an external entity reference, enabling classic XXE primitives — local file disclosure, server-side request forgery (SSRF) against internal services, and out-of-band data exfiltration.
2. Command execution via RunExecutableListener. Solr's Config API historically allowed unauthenticated clients to register a RunExecutableListener — a legitimate but dangerous plugin designed to run an arbitrary local executable in response to update events. An attacker who can reach the Config API can register this listener pointing at a shell command, then trigger it via a crafted update/document event. Combined with the XXE path as a delivery and triggering mechanism, this gives a reliable route from "can send HTTP requests to Solr" to "can run OS commands as the Solr process user."

The net effect: an attacker with network access to a vulnerable Solr instance's HTTP API can achieve RCE with the privileges of the Solr service account — frequently root or an equivalent high-privilege service identity in older, poorly hardened deployments.

Affected versions and components: Apache Solr versions 1.3 through 7.0.1 — effectively every release prior to 7.1 — are affected. The vulnerable surface spans the XML Query Parser (defType=xmlparser, sometimes referenced as the "XML Query Request Handler") and the Config API's listener registration endpoint. Because Solr is frequently bundled or vendored inside other products, organizations running content management systems, e-commerce platforms, enterprise search appliances, and log/SIEM tooling that embed Solr should treat this as a supply-chain issue, not just a direct-dependency one — patch status needs to be verified at the vendor level, not just checked against your own Solr installs.

Severity, exploitability, and exploitation context

NVD scores CVE-2017-12629 at 9.8 (Critical) under CVSS v3, reflecting network-exploitable, unauthenticated, low-complexity access to full system compromise with high impact to confidentiality, integrity, and availability. There is no privilege requirement and no user interaction — the textbook profile for a wormable bug.

EPSS (Exploit Prediction Scoring System) data for aging, high-severity, publicly weaponized CVEs like this one consistently sits in the upper percentiles: proof-of-concept exploit code has circulated publicly since shortly after disclosure, and the bug's simplicity (a single crafted HTTP POST) makes it trivial to fold into mass-scanning tooling. In the years following disclosure, internet-wide scanning campaigns and opportunistic botnet/cryptomining operators repeatedly targeted exposed Solr instances running vulnerable versions — a pattern consistent with several other Apache Solr flaws from the same era, including CVE-2019-0193 (DataImportHandler RCE), which has since been added to CISA's Known Exploited Vulnerabilities (KEV) catalog. Whether or not CVE-2017-12629 itself is currently tracked in every KEV feed you consult, its practical exploitation history and the trivial reliability of the exploit chain warrant KEV-equivalent urgency: if you have an internet-facing or otherwise reachable pre-7.1 Solr instance today, assume it is being probed.

Timeline

• Pre-2017: Solr's XML Query Parser and RunExecutableListener ship without entity-resolution restrictions or authentication requirements on the Config API, as they had for multiple prior major versions.
• 2017: Security researchers report the combined XXE-to-RCE chain to the Apache Solr security team, demonstrating that the two independently-known-risky features could be combined into a reliable unauthenticated RCE.
• October 2017: Apache releases Solr 7.1, which disables external entity resolution in the XML parser by default and removes/restricts unauthenticated registration of RunExecutableListener, closing the practical exploitation path.
• November 2017: CVE-2017-12629 is published, along with the related XXE-only CVE-2017-12628 covering a narrower slice of the same parser weakness.
• 2018–2020: Public writeups, Metasploit-style modules, and scanner signatures proliferate; mass-exploitation attempts against unpatched, internet-facing Solr instances are widely reported by researchers and honeypot operators, often tied to cryptomining and botnet recruitment campaigns.
• Ongoing: Vulnerable Solr versions continue to surface in modern environments — usually not as a direct, deliberately-outdated install, but as a transitive dependency buried inside a third-party appliance, container base image, or legacy internal tool nobody has re-evaluated since it was stood up.

Remediation: what to actually do

1. Upgrade Solr to 7.1 or later — ideally the current supported release. This is the only complete fix; every mitigation below is a stopgap for environments where an immediate upgrade isn't possible.
2. If you can't patch immediately, disable RunExecutableListener explicitly. Audit solrconfig.xml for any registered RunExecutableListener entries and remove them, and block Config API write requests (POST /solr/<collection>/config) at the reverse proxy or WAF layer.
3. Restrict or disable the XML Query Parser. If defType=xmlparser isn't a feature your application actually needs, block requests that set it, or front Solr with a proxy that strips/validates that parameter.
4. Never expose Solr's HTTP API directly to the internet. Solr historically shipped without authentication enabled by default. Place it behind a VPN, private network, or authenticating reverse proxy, and enable Solr's built-in Basic Auth or Kerberos authentication plugins regardless of network placement — defense in depth matters here because internal networks get breached too.
5. Firewall Solr's ports (default 8983, and any configured Zookeeper ports) to a tight allowlist of application servers, not broad internal ranges.
6. Hunt for embedded/vendored Solr instances. Inventory every product in your environment that might bundle Solr — search appliances, CMS platforms, analytics tools — and confirm the vendor has shipped a patched build, since you may not control the underlying solrconfig.xml directly.
7. Review logs for indicators of compromise: unexpected POST requests to /solr/*/config, XML payloads containing <!DOCTYPE or <!ENTITY declarations in query parameters, and unexplained outbound connections or child processes spawned by the Solr service account.
8. Rotate credentials and audit for persistence if you find evidence of prior unpatched exposure — RCE-capable bugs left unpatched for years are a reasonable basis to assume compromise, not just vulnerability.

How Safeguard Helps

Finding "Solr somewhere in the stack" is easy; knowing whether the vulnerable XML parser and RunExecutableListener code paths are actually reachable in your specific deployment is what determines real risk — and that's exactly what Safeguard's reachability analysis is built to answer, cutting through SBOM noise to tell you which pre-7.1 Solr instances are truly exploitable versus merely present. Safeguard's SBOM generation and ingest pipeline surfaces embedded and transitive Solr dependencies hiding inside third-party appliances and vendored components that traditional dependency scanning misses. Griffin AI correlates that exposure with live threat intelligence and your environment's actual network posture to prioritize CVE-2017-12629-class findings the moment they matter, rather than burying them in a generic severity list. And where remediation is straightforward — a version bump to Solr 7.1+, or a config change disabling RunExecutableListener — Safeguard can generate an auto-fix pull request so your team ships the patch instead of just tracking the ticket.