Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach unauthenticated search endpoint
-
DeliverySubmit {{!...}} double-brace query
-
ExploitBypass greedy-regex cleanUpQuery sanitizer
-
ExecutionSolr executes injected local param
-
ImpactInfer access-restricted record structure
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Input validation, allowlisting
|
| Exploitation Conditions | Exploitation requires reaching a Goobi viewer core endpoint that forwards user-supplied query strings through SolrTools.cleanUpQuery() to Solr (the shared sanitizer, so any such endpoint qualifies), on versions >=23.03 and before 26.05 - the double-brace {{!...}} bypass specifically applies from v23.10 where the greedy \{(.+)\} regex was introduced, while a bare-!join rewrap path exists from v23.03. No authentication, user interaction, or non-default configuration is needed (AV:N/AC:L/PR:N/UI:N); the attacker only needs to wrap a Solr local parameter in a second pair of curly braces. The key LIMITING factor on impact is that the injected local params cannot directly return access-restricted content - the outer access-condition filter still constrains returned documents - so exploitation is confined to structural inference (which open-access records have access-restricted sub-documents) rather than disclosure of the restricted content itself. |
| Impact | The signals point to a genuine but modest-severity issue rather than an urgent priority. The supplied CVSS is 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N): network-reachable, low complexity, unauthenticated (PR:N), but only low confidentiality impact and no integrity or availability impact. No EPSS score is provided in the input, so exploitation probability cannot be quantified. The vulnerability is NOT in CISA KEV and no public exploit is identified at time of analysis - the only references are the vendor GHSA advisory and patch commits. The vuln.today decision label is 'this_month', consistent with a medium-severity, non-emergency item. A full SSVC decision (automatable / technical-impact fields) is not supplied. The most important nuance, stated explicitly by the vendor advisory, is that the flaw does NOT by itself disclose access-restricted content: the outer access-condition filter still applies to returned documents, so the realistic impact is limited to inferring structural facts (e.g. which open-access top-level records have access-restricted sub-documents). This tempers the unauthenticated-network vector - real-world risk is low-to-medium information leakage, not a high-impact breach. Missing data to note: no EPSS, no KEV, no independent SSVC exploitation status. |
| Exploit ScenarioDerived | An unauthenticated attacker submits a crafted search query to any Goobi viewer endpoint that routes input through SolrTools.cleanUpQuery(), wrapping a Solr local parameter in a second pair of curly braces (e.g. {{!join from=PI_TOPSTRUCT to=PI}}) so the sanitizer strips only the outer braces and forwards the intact inner {!...} to Solr. By injecting block-join, graph-traversal or function-query local params the attacker can infer which open-access top-level records have access-restricted sub-documents. No public exploit is identified, though the patch commit includes test cases that demonstrate the double-brace bypass concretely. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 23, 2026
Solr local-parameter injection in Goobi viewer core (23.03 through 26.05) lets unauthenticated remote attackers slip structural Solr parameters past the shared SolrTools.cleanUpQuery() sanitizer by wrapping them in a second pair of braces ({{!...}}): the greedy regex strips only the outer pair and a valid {!...} local parameter is forwarded to Solr. Any endpoint that routes user-supplied query strings through cleanUpQuery is exposed, and injected parent/child block joins, graph traversal or function queries can reveal which open-access top-level records have access-restricted sub-documents, although the outer access-condition filter still applies so the restricted content itself is not returned. The issue is fixed in 26.05, no public exploit was identified at time of analysis, and priority is assessed as this-month rather than immediate.
RemediationAI
Upgrade Goobi viewer core to 26.05, the release that closes both the double-brace bypass and the bare-!join rewrap path; deployments that cannot take the full release can cherry-pick the two fix commits 330da2f8255a9ed2200ba46b98bb9b6a88748a4e and 5a59ffa5d76169a4ad3cc396023ad4a4eca217da, and the advisory GHSA-2r24-qxpf-cj65 should be consulted for the authoritative fix details. Be aware that the new sanitizer is a whitelist: only {!join from=PI_TOPSTRUCT to=PI}, {!join from=IDDOC to=IDDOC_OWNER} and {!terms f=PI_TOPSTRUCT} pass through unchanged, so any local installation that has customised query generation to rely on other internal Solr local params will have those stripped after updating - validate calendar-day range queries and PI_TOPSTRUCT rewrites in a staging environment first. No workaround is documented in the advisory; until the update is applied, the residual exposure is limited to structural inference (learning which open-access records carry access-restricted sub-documents) rather than retrieval of the restricted documents themselves, since the outer access-condition filter remains in force.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Goobi viewer core is a Java/Maven artifact (io.goobi.viewer:viewer-core) that builds Apache Solr queries from user input. Solr's query parser supports local parameters - prefixed blocks such as {!parent which=...}, {!join from=... to=...}, {!graph ...}, {!func} and {!terms f=...} - which alter how the remainder of a query is parsed, so untrusted input reaching them can reshape query structure rather than merely supply terms. This is CWE-20 (improper input validation), with the advisory additionally tagging CWE-116 (improper encoding/escaping): cleanUpQuery() attempted to neutralise local params with the greedy pattern \{(.+)\}, which matches from the first '{' to the last '}' in the string. Wrapping a payload as {{!parent which="ISWORK:true"}} means the outer braces are consumed and the inner {!...} survives intact. The double-brace form applies from v23.10 where that greedy regex was introduced; from v23.03 a related path unconditionally rewrapped a bare "!join from=PI_TOPSTRUCT to=PI" fragment into a local parameter, producing a comparable double-brace condition. Because the flaw sits in the shared sanitizer rather than in one servlet, every caller forwarding cleanUpQuery output to Solr without its own neutralisation is affected. The 26.05 fix replaces the regex with a placeholder scheme: the three internal local params the application itself emits ({!join from=PI_TOPSTRUCT to=PI}, {!join from=IDDOC to=IDDOC_OWNER}, {!terms f=PI_TOPSTRUCT}) are swapped for opaque " WLP<n>" tokens, innermost brace blocks are stripped repeatedly so arbitrary wrapping depth collapses, blocks starting with '!' or still containing a placeholder are dropped entirely, and the whitelisted params are restored at the end.
Know when Solr gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Unauthenticated network endpoint with a trivial double-brace bypass gives AV:N/AC:L/PR:N/UI:N; impact is limited structural inference (C:L) with no integrity or availability effect and no scope change.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.org
The Goobi viewer is a web application that allows digitised material to be displayed in a web browser. From version 23.03 to before version 26.05, SolrTools.cleanUpQuery() strips Solr local-parameter syntax ({!...}) from user-supplied query strings before they reach Solr. Its regex can be bypassed by wrapping the local parameter in a second pair of curly braces ({{!...}}): the outer braces are stripped, the inner {!...} survives intact, and a valid Solr local parameter is forwarded. The flaw is in the shared sanitizer, so it affects any endpoint that routes user input through cleanUpQuery. The double-brace bypass applies from v23.10 (the greedy \{(.+)\} regex); a related bare-!join rewrap path is present. This issue has been patched in version 26.05.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resour
Remote code execution occurs in Apache Solr before 7.1 with Apache Lucene before 7.1 by exploiting XXE in conjunction wi
Directory traversal vulnerability in SolrResourceLoader in Apache Solr before 4.6 allows remote attackers to read arbitr
Apache Solr 5.0.0 to Apache Solr 8.3.1 are vulnerable to a Remote Code Execution through the VelocityResponseWriter. Rat
Full administrative cluster takeover in Apache Solr 9.4.0-9.10.1 and 10.0.0 arises because the 'bin/solr auth enable' se
Improper Authentication vulnerability in Apache Solr. Rated critical severity (CVSS 9.8), this vulnerability is remotely
The ReplicationHandler (normally registered at "/replication" under a Solr core) in Apache Solr has a "masterUrl" (also
The 8.1.1 and 8.2.0 releases of Apache Solr contain an insecure setting for the ENABLE_REMOTE_JMX_OPTS configuration opt
In Apache Solr versions 5.0.0 to 5.5.5 and 6.0.0 to 6.6.5, the Config API allows to configure the JMX server via an HTTP
SimpleXML (latest version 2.7.1) is vulnerable to an XXE vulnerability resulting SSRF, information disclosure, DoS and s
An XXE issue in SAXBuilder in JDOM through 2.0.6 allows attackers to cause a denial of service via a crafted HTTP reques
Solr versions 1.3.0 to 1.4.1, 3.1.0 to 3.6.2 and 4.0.0 to 4.10.4 are vulnerable to an XML resource consumption attack (a
EUVD-2026-109084
NVD
CVE.org
EPSS
GitHub
Exploit-DB