OSSEVA FOR APACHE SOLR
Solr 8 ended 25 October 2024. Your index did not.
Search clusters are rebuilt, not upgraded — schema, analysers, query parsers and relevance tuning are all version-coupled. That is why so many production estates are still on Solr 8 nearly a year after upstream stopped patching it, and on Solr 7 four years after.
Last reviewed
Trusted globally by enterprises
Why now
Solr 8 has been unpatched since 25 October 2024
Apache Solr 8 reached end of life on 25 October 2024, with 8.11.4 as its final release. Solr 7 ended on 11 May 2022. Solr 10, released 3 March 2026, is the current line, and Apache shipped 9.11.0 on 4 October 2026 as the last 9.x release. Nothing is backported below 9.
Solr is frequently the most exposed service in the estate
Solr has a long history of remote code execution advisories reached through the config API, the VelocityResponseWriter, the DataImportHandler and the streaming expression handlers. Many deployments were stood up behind an assumption of network isolation that no longer matches how the application calls them. Deserialization and SSRF classes hit this component hard.
Upgrading Solr means re-validating relevance, not just swapping a binary
Lucene index formats change between majors, analysers are deprecated, and query parser behaviour shifts in ways that move result ordering. A Solr upgrade is a reindex plus a relevance regression cycle plus sign-off from whoever owns search quality. Extended support is what buys the time to do that properly.
Versions covered
All versions below receive active CVE patches from OSSeva. Version numbers in monospace are exact release identifiers.
| Version | Status | Active CVEs |
|---|---|---|
| 6.x(Community EOL 13 Mar 2019 — OSSeva patched) | EOL | Clean |
| 7.x(Community EOL 11 May 2022 — OSSeva patched) | EOL | Clean |
| 8.x(Community EOL 25 Oct 2024 — OSSeva patched) | EOL | Clean |
| 9.x(9.11.0 is the last upstream 9.x release) | Extended | Clean |
| 10.x(Released 3 Mar 2026) | Current | Clean |
What you get
Three tiers — pick the level of engagement that matches your team's operational needs and compliance requirements.
OSSeva Patch
CVE patches for Solr 6, 7 and 8 with the index format unchanged.
- Security backports for 6.x, 7.x and 8.x — no reindex required
- Config API, VelocityResponseWriter and DIH advisory coverage
- Bundled Lucene, Jetty and Zookeeper client patching
- Docker / tarball / WAR delivery
- Signed artifacts (GPG)
- Relevance regression testing
- 24/7 managed operations
OSSeva Assure
Patch plus exposure audit and a reindex-aware upgrade plan.
- Everything in Patch
- Handler and request-path exposure audit
- SolrCloud and ZooKeeper ensemble security review
- Schema and analyser deprecation inventory for 9.x / 10.x
- SOC 2 / HIPAA attestation package
- Reindex strategy and relevance regression plan
- 24/7 managed operations
OSSeva Operate
Full MSP: 24/7 cluster monitoring, 15-min SLA, named search engineers.
- Everything in Assure
- 24/7 query latency, shard health and replica monitoring
- 15-minute P1 incident response SLA
- Named senior Solr / Lucene engineer
- Index optimisation and segment merge management
- Upgrade execution with parallel-index cutover
- Quarterly relevance and capacity reviews
All tiers priced per cluster/application — not per core. Contact for pricing →
How it installs
OSSeva artifacts arrive via your existing package infrastructure. Pull the patched version the same way you pull upstream today — just from the OSSeva registry.
# Version, JVM and uptime
curl -s 'http://solr:8983/solr/admin/info/system?wt=json' \
| jq '.lucene["solr-spec-version"], .jvm.version'
# Anything at 8.x or below receives no upstream security fixes.
# List enabled request handlers — the historical RCE paths live here
curl -s 'http://solr:8983/solr/mycore/config?wt=json' \
| jq '.config.requestHandler | keys'# Drop-in replacement, same index format, same schema
docker pull artifacts.osseva.io/solr:8.11.4-osseva-1
docker run -d --name solr \
-p 8983:8983 \
-v /var/solr:/var/solr \
artifacts.osseva.io/solr:8.11.4-osseva-1 \
solr-foregroundMigrate from Unsupported community Solr 7.x and 8.x
OSSeva ships patched Solr builds on the line you already run, so the Lucene index format, schema and analyser chain stay exactly as they are and no reindex is required to become secure. The upgrade to Solr 9 or 10 is then planned properly, with a parallel index and a relevance regression cycle rather than a rushed cutover.
Pricing model
OSSeva for Apache Solr is priced per cluster — not per node, core, shard or indexed document.
Frequently asked questions
Is Solr 8.11 still getting security fixes?
No. Solr 8.11.4 was the last release, and the Solr download page describes 9.11.0, released 4 October 2026, as the last 9.x release. CVE-2026-22444, disclosed in January 2026, affects Solr 8.6 through 9.10.0 and is fixed only in 9.10.1, so 8.11.4 stays exposed. OSSeva ships patched Solr 8.11 builds today with fixes like this backported.
When did Apache Solr 8 reach end of life?
Apache Solr 8 reached end of life on 25 October 2024. On that date the Lucene and Solr PMCs announced that, with Lucene 8 at end of life, no further Solr 8 releases would ship. Solr 8.11.4, released on 24 September 2024, is the final 8.x release. Solr 10.0.0, released on 3 March 2026, is the current major, and 9.11.0, released 4 October 2026, is the last 9.x release.
Can I patch Solr without reindexing?
Yes — that is the point of backporting onto your existing line. OSSeva builds keep the Lucene index format, schema handling and analyser behaviour of the release you are on, so patched binaries drop onto the same data directory. Reindexing only becomes necessary when you move to a new major version.
Why are Solr upgrades harder than most component upgrades?
Because search behaviour is part of the contract. Lucene index formats change between majors, analysers and query parsers are deprecated or altered, and result ordering can shift in ways that are invisible to a health check but obvious to users. A Solr major upgrade is a reindex plus a relevance regression cycle, which is why it is deferred far longer than a typical library bump.
Does OSSeva cover SolrCloud and the ZooKeeper ensemble behind it?
Yes to both. SolrCloud deployments coordinate through ZooKeeper, and that ensemble is usually older than the Solr cluster itself. OSSeva patches the Solr nodes and the ensemble under the same engagement — see the ZooKeeper coverage for how those ensembles are handled.
What about the Solr CVEs that come from bundled libraries?
They are included. A large share of Solr advisories arrive through bundled Lucene, Jetty, the ZooKeeper client and logging libraries rather than Solr's own code. OSSeva patches the shipped dependency set as part of the build.
Ready to get Apache Solr patched and supported?
Start with a 45-minute discovery call. We confirm your version coverage, scope the engagement, and have you onboarded within your first quarter.