v2.3.0

• Kubernetes: update Redis Sentinel to 8.2.2 in order to fix CVE-2025-49844.
• Docker: update Redis to 8.2.2 in order to fix CVE-2025-49844.

See the update instructions for Kubernetes and Docker.

v2.2.2

• (Kubernetes only) the Redis Docker image has been moved to openanalytics/redis and openanalytics/redis-sentinel since Bitnami will remove the images.

See the announcement for more information.

v2.2.1

• add maven assembly configuration to correctly combine the services file provided by the fabric8 kubernetes client. Fixes an issue with the operator stopping to receive events after some time.

v2.2.0

• update to JDK 21
• add Docker support
• add labels property
• add memory-request, memory-limit, cpu-request and cpu-limit properties
• add dns support
• create Kubernetes events during reconciliation or failure

v2.1.0

• update to JDK 17
• support multiple FQDNs
• add anti-affinity rule to not schedule multiple replicas on the same node
• allow to modify the Service resource by using kubernetesServicePatches
• Fix: operator not syncing after some time
• Fix: update Ingress resource if kubernetesIngressPatches has changed

v2.0.0

See https://github.com/openanalytics/shinyproxy-operator/tree/v2.0.0#update-to-200

v1.1.0

This release makes the ShinyProxy Operator compatible with Kubernetes 1.22 and later (contributed by @dev-rowbot).

v1.0.3

This release contains a security update of the log4j library. This fixes CVE-2021-45105 see GHSA-p6xc-xr62-6r2g.

Version 1.0.1 of the operator includes log4j 2.15.0, which fixes CVE-2021-44228 and version 1.0.2 of the operator includes log4j 2.16.0 which fixes CVE-2021-45046. This release updates log4j to 2.17.0 in order to fix CVE-2021-45105.
In the case of the Operator, the possibilities to exploit this vulnerability are low. The operator only handles input from the Kubernetes API and does not expose any network service. Therefore an attacker must be able to create ShinyProxy resources in order to exploit this vulnerability.

Note: ShinyProxy itself is not vulnerable, as it uses logback as logging backend.

v1.0.2

This release contains a security update of the log4j library. This fixes CVE-2021-45046, see GHSA-7rjr-3q55-vv33 .

Version 1.0.1 of the operator includes log4j 2.15.0, which fixes CVE-2021-44228, however this fix is incomplete. This release updates log4j to 2.16.0.
In the case of the Operator, the possibilities to exploit this vulnerability are low. The operator only handles input from the Kubernetes API and does not expose any network service. Therefore an attacker must be able to create ShinyProxy resources in order to exploit this vulnerability.

Note: ShinyProxy itself is not vulnerable, as it uses logback as logging backend.

v1.0.1

This release contains a security update of the log4j library. This fixes CVE-2021-44228, see GHSA-jfh8-c2jp-5v3q .

In the case of the Operator, the possibilities to exploit this vulnerability are low. The operator only handles input from the Kubernetes API and does not expose any network service. Therefore an attacker must be able to create ShinyProxy resources in order to exploit this vulnerability.

Note: ShinyProxy itself is not vulnerable, as it uses logback as logging backend.