---
id: "CVE-2026-55459"
kind: "vulnerability"
aliases: ["CVE-2026-55459"]
title: "Goobi viewer: OpenID token audience not enforced, allowing account takeover"
severity: "high"
cvss: 7.4
epss: 0.00241
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["goobi-viewer", "java", "openid-connect", "package", "self-hosted"]
not_affected_if: ["default-config", "no-openid-login"]
published_at: "2026-10-23T15:17:33+00:00"
first_seen_at: "2026-10-23T21:57:34+00:00"
updated_at: "2026-10-25T12:38:49+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55459", "first_seen_at": "2026-10-23T21:57:34+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-55459", "first_seen_at": "2026-10-25T12:38:49+00:00"}]
---

# Goobi viewer: OpenID token audience not enforced, allowing account takeover

Goobi viewer accepts OpenID tokens issued for a different relying party when the audience is a single string matching its client ID, because the audience check is incomplete. An attacker holding such a token from a shared identity provider can sign in as the token's subject.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the Goobi viewer version deployed, for example in the application's pom.xml or the running build, and confirm whether it is between `25.01` and `26.05`.
- Check whether the viewer uses OpenID login against an identity provider that also serves other relying parties.

## Fix

- Upgrade Goobi viewer to `26.05` or later.

## Timeline

- 2026-10-23T21:57:34+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-55459
- 2026-10-25T12:38:49+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-55459

## From the sources

The Goobi viewer is a web application that allows digitised material to be displayed in a web browser. From version 25.01 to before version 26.05, AuthenticationEndpoint.verifyOpenIdToken builds its verifier as JWT.require(algorithm).withIssuer(issuer).build() and does not enforce the aud claim during cryptographic validation. The aud check is performed manually afterwards via a single string-equality call, which only handles single-string aud values. In a multi-RP IdP setup, a token whose single-string aud matches the viewer's client ID but was issued for a different relying party passes the check and authenticates the attacker as the token's sub. This issue has been patched in version 26.05.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_