Goobi Viewer Hit by Unauthenticated CVE-2026-45083: Digital Archives At Risk

A critical vulnerability that lets anyone reach an entire cultural-heritage database without authentication has been found in "Goobi viewer," the open-source platform used by libraries, museums and universities to publish their digitized holdings. Tracked as CVE-2026-45083 with a CVSS score of 9.8, the issue was disclosed on May 27, 2026 by the maintainer, Germany-based intranda, as a GitHub Security Advisory (GHSA-2rgp-f66f-4499).

The root cause is that the POST /api/v1/index/stream REST endpoint forwards arbitrary Solr streaming expressions received from unauthenticated requests straight to the backend Solr server without any validation. As a result, an attacker could anonymously read the entire Solr index, including embargoed material that was supposed to be protected by access controls such as moving walls (publication embargoes), license restrictions or IP restrictions. By sending update() or delete() expressions, the attacker could even tamper with metadata or wipe entire collections.

Versions 4.8.0 through 26.04.0 are affected. The fixed release, v26.04.1, removes the offending endpoint altogether (fix commit 326980f). Cultural-institution digital archives serve as a trusted knowledge base for researchers and the public, where "authenticity of the data" is treated as paramount, so the community impact here is even larger than the raw CVSS 9.8 number suggests.

What Disappears When the Authenticity of Cultural Records Breaks

A library or museum archive draws a different class of operator than a bank ledger or a CAD repository does. The motive is not cash but the rewriting or erasure of the past. The Solr streaming endpoint on Goobi viewer sitting open without authentication was, for that class, an unusually generous opportunity.

The list of interested parties reads off a different map than ordinary cybercrime: state-aligned propaganda units rewriting colonial-era administrative records and wartime documents to fit a preferred national narrative, militant groups targeting heritage on the other side of a religious or ethnic dispute, antiquities-market brokers leaking restricted manuscripts and banned works into the underground trade for wealthy collectors, hacktivists out to dent the authority of national libraries and museums, and scholarly rivals trying to sabotage the publication pipeline of a specific researcher. What they reach for is the primary material kept behind a moving wall, donor-restricted correspondence under contractual embargo, excavation photographs still under metadata curation, and IP-restricted high-resolution scans of rare books — material that is explicitly "not yet, or never to be, public." Passing arbitrary Solr streaming expressions into this endpoint not only reads those records anonymously; layering update() and delete() expressions on the same path lets them substitute or wipe the historical record itself. The endpoint is, in effect, a window for editing the past as much as for reading it.

This is not data exfiltration in the usual sense — it sits in the category of "integrity attack." Write access to the Solr index lets an operator swap one historical figure for another, shift a date by a year, or remove a paragraph that contained an inconvenient passage, with the alteration showing no exterior trace. A digital archive becomes dangerous precisely because researchers, students, and journalists cite it on the premise that an institutional source must be correct, and that citation is reproduced in papers, textbooks, and news copy. Where the deployment feeds aggregators such as Europeana, one tampered row propagates across the European reference network. Academia carries a second blast radius: when unpublished research material is exfiltrated ahead of release, the multi-year plans of collaborators and supervised graduate students built atop it lose most of their forward value.

As a technical metric, CVSS 9.8 marks the ceiling of severity. For a cultural institution, the actual wound is not a server going down — it is that the historical record meant to be passed from one generation to the next is silently handed over in a tampered, partially deleted form that no one notices is wrong.

What Goobi Viewer Is

Goobi viewer is an open-source platform developed by Germany-based intranda that lets libraries, museums and archives publish digitized manuscripts, old books, maps, photographs and newspapers online, with full-text search. Combined with the company's scanning workflow tool Goobi workflow, it covers the full lifecycle of "scan the material, add metadata, publish it."

Typical use cases include the following.

• University and national libraries operating public-facing viewers for rare books and out-of-print works
• Museums and art galleries publishing collection images with descriptive metadata online
• Archives publishing old administrative documents in OCR-enabled, full-text-searchable form
• Research institutions building and operating digital archives of research materials
• Source platforms feeding pan-European cultural aggregators such as Europeana

It is in production at hundreds of cultural institutions worldwide, especially in European public bodies and German-speaking university libraries, and is one of the de-facto viewer platforms for the digital humanities. It has also seen adoption at a handful of Japanese universities and research institutions, and is gaining recognition as an option for cultural-heritage DX projects.

Technically, it is a Java/Spring web application that uses Apache Solr as its full-text search engine. The issue here is that the front-end "window" into that Solr instance, which should have been very narrowly opened, instead left the door open for anyone on the network to invoke arbitrary Solr functionality without authentication.

Inside CVE-2026-45083

The root cause sits in the design of the POST /api/v1/index/stream endpoint shipped by Goobi viewer. NVD classifies it as CWE-306 (Missing Authentication for Critical Function).

Solr streaming expressions are a powerful data-manipulation language provided by Apache Solr. They go far beyond search and include record updates (update()), deletions (delete()), joins across Solr collections and even machine-learning-oriented operations. They are meant to be invoked by administrators or from within the application, never by end users directly.

When an attacker can reach this endpoint without authentication, the available attack surface looks like this.

• Reading: Pull every document in the Solr index, including non-public material that was supposed to be protected by Goobi viewer's access controls such as moving walls, license restrictions and IP restrictions
• Tampering: Use update() to rewrite metadata fields. Access-control values can be rewritten too, flipping items that should be restricted to "public"
• Destruction: Use delete() to wipe entire collections. Recovery requires re-indexing, which on a large archive means days to weeks of downtime
• Breaking document structure: Upsert unintended fields and break schema consistency

These four malicious operations simultaneously break all three core values a digital archive must defend: authenticity, integrity and availability. For a cultural institution, the catalog is not just a "database" but the very basis on which researchers and citizens decide "this record is correct." Rebuilding that trust after a tampering incident takes a long time.

Why Even The Restricted Holdings Leak

Goobi viewer implements three access-restriction patterns that are characteristic of the library community. All three are bypassed simultaneously by this vulnerability.

Moving wall: A pattern common in digital editions of newspapers and magazines, where "issues older than N years are free, the latest N years are paid." Goobi viewer correlates publication date with access rights at the display layer, but the Solr index itself still contains all of the data, so direct Solr access bypasses the wall.

License restrictions: For digitized books, contracts with rights holders or publishers often limit access to "users on the research institution's network only" or "students of a specific degree program only." Libraries implement these rules through Goobi viewer's display layer, but the underlying content lives in the Solr index, so CVE-2026-45083 lets it leak straight through.

IP restrictions: Operational rules such as "viewable only from on-campus." This is also an authorization rule implemented in the Goobi viewer front-end, and it does not apply to a direct path into Solr. If the CVE-2026-45083 endpoint is exposed externally, the IP rule simply does not kick in.

In many cases these access restrictions are not just operational choices but legal obligations imposed by copyright law and by contracts with publishers and donors. If a leak via this vulnerability can be confirmed, the library suddenly faces contractual liability, research-ethics accountability and a reporting duty to donors all at once. Although there is no technical RCE, the social impact is at least as serious.

What To Do Now

1. Upgrade Goobi viewer to v26.04.1 or later. Pull the latest release from the GitHub releases page. If you run it as a Docker image, point your intranda/goobi-viewer tags to the latest version. Because the fix commit 326980f removes the endpoint outright, organizations that were relying on its functionality will need to plan for an alternative.

2. If you cannot upgrade right away, block the endpoint at the reverse proxy. If Apache httpd sits in front of Goobi viewer, deny requests to the affected endpoint using a LocationMatch directive. If you front it with Tomcat, add a security-constraint to web.xml to require authentication.

# Apache httpd example
<LocationMatch "^/api/v1/index/stream">
    Require all denied
</LocationMatch>

3. Audit the past six months of access logs. Search for POST requests to /api/v1/index/stream. Any request you do not recognize, especially ones with abnormally long bodies or Solr expressions containing update or delete, should be treated as a possible tampering or deletion attempt.

4. Verify Solr index integrity. Compare the current Solr index against older backups and look for suspicious metadata changes. Pay particular attention to access-control fields (those related to moving wall, license restriction and IP restriction).

5. Confirm that materials which should remain restricted have not been flipped to "public." Cross-check, item by item, the library's metadata policy (Creative Commons licenses, access-rights operational guidelines) against the actual values currently stored in Solr. If an attacker was active for a long time, specific rare items may have been quietly switched to "public."

6. Run a legal review of potential impact on donors, rights holders and contractual partners. If you exposed an affected version externally, work with your legal and compliance teams to assess whether contractually restricted materials may have leaked. Map out the notification obligations under copyright law, the reporting duties under research ethics and the accountability obligations under donation agreements, and prepare to notify the relevant parties as required.

Security Management For Cultural-Heritage OSS

Libraries, museums and archives are a sector where domain-specific OSS such as Goobi viewer is often preferred over closed-source commercial products. Budget constraints at research institutions, long-term-preservation requirements, the desire to avoid vendor lock-in and the appeal of community-driven feature extension all push in that direction.

At the same time, IT operations in cultural institutions are chronically short-staffed compared with commercial enterprises, and tracking OSS vulnerabilities and applying patches quickly is rarely a core strength. A CVE like this one in Goobi viewer would make the news on day one if it landed in a major commercial vendor's product, yet in the cultural-heritage OSS world the same severity can quietly go under-publicized.

In Japan, digital-archive projects are advancing in contexts such as cultural-heritage DX, regional materials digitization and university repositories. It is time to apply continuous-monitoring approaches such as the OSS Supply-Chain Scanner to cultural institutions as well, and to build a culture in which CVEs for domain-specific OSS like Goobi viewer, DSpace, Omeka, Greenstone, Invenio and Mukurtu are shared across municipal and university IT teams.

On this site we keep an ongoing list of CVEs that CISA has confirmed as exploited, together with their remediation deadlines, on the CISA KEV Dashboard (Japanese). Goobi viewer is not on KEV at the time of writing, but cultural-institution digital archives have been targeted by attack campaigns before, and the picture can change quickly once exploitation is observed in the wild.

References

• ▸ NVD - CVE-2026-45083 Detail
• ▸ GitHub Security Advisory - GHSA-2rgp-f66f-4499
• ▸ Goobi viewer-core GitHub Releases
• ▸ intranda Official Site
• ▸ Apache Solr - Streaming Expressions Guide
• ▸ CISA - Known Exploited Vulnerabilities Catalog