CVE-2026-55465: Goobi viewer: Solr injection exposes restricted records

MEDIUM

Published October 23, 2026

CISO Take

Goobi viewer, a web application for displaying digitised cultural-heritage material, has an unauthenticated REST endpoint that passes the user-supplied region parameter straight into a Solr query. An attacker can inject Solr local-param syntax and boolean operators to bypass access-condition filters and read georeferenced records that should be restricted. This is a medium-severity (CVSS 5.3) confidentiality-only flaw. It is not in CISA KEV, no public exploit or Nuclei template exists, and no EPSS score is available yet, so near-term mass exploitation looks unlikely. The AI/ML link is tenuous: Goobi viewer is a digital library platform and is not an AI package in itself, so exposure matters only if its Solr index feeds AI or RAG pipelines. Upgrade to version 26.05 or later; if you cannot patch now, restrict access to the /api/v1/index/*/spatial/search endpoint at the reverse proxy.

Sources:NVDGitHub AdvisoryATLAS

What is the risk?

Low-to-medium. The attack is network-reachable, needs no authentication or user interaction, and has low complexity (AV:N/AC:L/PR:N/UI:N). Impact is limited to low confidentiality loss, with no integrity or availability effect. There is no KEV listing, no known public exploit and no scanner template. Risk rises where restricted collections hold sensitive or licensed material, or where the Solr index is reused by downstream AI/ML services. Affected versions run from 22.04 up to, but not including, 26.05. The AI relevance of this CVE is low.

How does the attack unfold?

Initial Access

The attacker finds a public Goobi viewer instance and calls the unauthenticated spatial/search endpoint.

AML.T0049

Exploitation

A crafted region parameter injects Solr local-param syntax ({!parent}, {!join}) and boolean operators into the query.

AML.T0049

Collection

The injected query makes access-restricted georeferenced records match, which bypasses the access-condition filter.

AML.T0036

Impact

Restricted record metadata is disclosed to an unauthorised party, a low-severity confidentiality loss.

Initial Access

The attacker finds a public Goobi viewer instance and calls the unauthenticated spatial/search endpoint.

AML.T0049

Exploitation

A crafted region parameter injects Solr local-param syntax ({!parent}, {!join}) and boolean operators into the query.

AML.T0049

Collection

The injected query makes access-restricted georeferenced records match, which bypasses the access-condition filter.

AML.T0036

Impact

Restricted record metadata is disclosed to an unauthorised party, a low-severity confidentiality loss.

How severe is it?

CVSS 3.1

5.3 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 18% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SUnchanged

CLow

INone

ANone

What should I do?

1 step

1) Upgrade Goobi viewer to 26.05 or later, which includes the fix (commit 46fb8759, GHSA-v5h4-qrx3-qg3h). 2) As a temporary measure, block or authenticate requests to /api/v1/index/{solrField}/spatial/search at the WAF or reverse proxy. Reject region values that contain '{!', or that contain Solr operators or special characters. 3) Keep Solr off the public network and run it with least-privilege, read-only access. 4) Detection: search web and Solr logs for requests to the spatial/search endpoint with a region value containing '{!parent', '{!join' or unusual boolean operators. 5) Audit the Solr index for restricted records that were returned to unauthenticated sessions, and check whether any downstream AI/RAG ingestion reads from this index.

How is it classified?

Data LeakageAuth BypassFrameworkAPIAML.T0036- Data from Information Repositories AML.T0049- Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.7.2-Data for development and enhancement of AI systems

NIST AI RMF

MANAGE 2.3-Respond to and recover from previously unknown risks

OWASP LLM Top 10

LLM02-Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-55465?

Is CVE-2026-55465 actively exploited?

No confirmed active exploitation of CVE-2026-55465 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-55465?

1) Upgrade Goobi viewer to 26.05 or later, which includes the fix (commit 46fb8759, GHSA-v5h4-qrx3-qg3h). 2) As a temporary measure, block or authenticate requests to /api/v1/index/{solrField}/spatial/search at the WAF or reverse proxy. Reject region values that contain '{!', or that contain Solr operators or special characters. 3) Keep Solr off the public network and run it with least-privilege, read-only access. 4) Detection: search web and Solr logs for requests to the spatial/search endpoint with a region value containing '{!parent', '{!join' or unusual boolean operators. 5) Audit the Solr index for restricted records that were returned to unauthenticated sessions, and check whether any downstream AI/RAG ingestion reads from this index.

What systems are affected by CVE-2026-55465?

This vulnerability affects the following AI/ML architecture patterns: Web application search backends, Solr-backed search indexes, Digital library platforms, RAG data sources (indirect).

What is the CVSS score for CVE-2026-55465?

CVE-2026-55465 has a CVSS v3.1 base score of 5.3 (MEDIUM). The EPSS exploitation probability is 0.26%.

What is the AI security impact?

Affected AI Architectures

Web application search backendsSolr-backed search indexesDigital library platformsRAG data sources (indirect)

MITRE ATLAS Techniques

AML.T0036Data from Information Repositories

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

ISO 42001: A.7.2

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

The Goobi viewer is a web application that allows digitised material to be displayed in a web browser. From version 22.04 to before version 26.05, the unauthenticated REST endpoint GET /api/v1/index/{solrField}/spatial/search concatenates the user-supplied region query parameter directly into a Solr query string with no escaping, no local-param stripping, and no runtime schema enforcement (the OpenAPI @Schema(pattern=...) annotation is documentation-only at the JAX-RS layer). An attacker can inject Solr local-param syntax ({!parent ...}, {!join ...}) and boolean operators to make access-restricted georeferenced records match the query, bypassing the access-condition filter. This issue has been patched in version 26.05.

Exploitation Scenario

An unauthenticated attacker discovers a public Goobi viewer instance and sends a GET request to /api/v1/index/{field}/spatial/search with a crafted region parameter such as one containing {!parent which=...} or a boolean OR clause that is always true. Solr evaluates the injected syntax and returns georeferenced records that the access-condition filter would normally hide. The attacker harvests the metadata and identifiers of restricted items. If an organisation later feeds this index into an AI search or RAG assistant, the leaked or poisoned content could carry into that system.

Weaknesses (CWE)

CWE-89Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')Primary CWE-943Improper Neutralization of Special Elements in Data Query LogicPrimary CWE-89Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')CWE-943Improper Neutralization of Special Elements in Data Query Logic

CWE-89 — Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'): The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.
[Architecture and Design] If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]

Source: MITRE CWE corpus.