Security Bulletins

• 1: KIALI-SECURITY-004 - Missing namespace authorization checks in Kiali Server API endpoints
• 2: KIALI-SECURITY-003 - Installation into ad-hoc namespaces
• 3: KIALI-SECURITY-002 - Authentication bypass when using the OpenID login strategy
• 4: KIALI-SECURITY-001 - Authentication bypass using forged credentials

1 - KIALI-SECURITY-004 - Missing namespace authorization checks in Kiali Server API endpoints

Description

• Disclosure date: November 2, 2026
• Affected Releases: Kiali Server 2.x releases prior to 2.34.1 (see per-finding details below)
• Impact Score: 4.3 - AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Several Kiali Server API endpoints returned data about namespaces the caller had no RBAC access to (CWE-862, missing authorization). The impact is confidentiality only: no secrets or traffic content were exposed and nothing could be modified. The issues were reported to the Kiali security team by a member of the community and were verified on Kiali Server 2.34.0.

Kiali users are exposed to these findings depending on the endpoint:

• Cluster health cache — GET /api/clusters/health?namespaces= served cached health data for any namespace. The internal health cache is populated by a background monitor running with Kiali’s ServiceAccount, and the handler only RBAC-filtered the response when the namespaces parameter was empty. This exposes application, service and workload names, replica counts, health statuses and traffic rates. Affected releases: v2.22.0 and later (the health cache is enabled by default since v2.22.0).
• ztunnel logs — GET /api/namespaces/{namespace}/pods/{pod}/logs?logType=ztunnel streamed ztunnel access-log lines for any namespace. The ztunnel log path fetches logs with Kiali’s ServiceAccount rather than the caller’s credentials, so the API server never enforced RBAC. Additionally, the log filter regexes were not anchored, so a pod name in the URL acted as a prefix that could match workloads other than the one requested. This exposes pod, workload and namespace names, SPIFFE identities, IP addresses and byte counts. Requires an ambient mesh. Affected releases: v2.11.0 and later.
• ztunnel config dump — GET /api/namespaces/{namespace}/pods/{pod}/config_dump_ztunnel returned the full mesh-wide configuration dump — every workload, service and policy in the mesh with pod IPs, service accounts and node information. The ztunnel pod was located by name across the cluster, so the namespace in the URL was irrelevant and no authorization check was performed. Requires an ambient mesh. Affected releases: all 2.x releases.
• Cluster-wide Istio config validations — GET /api/istio/config?validate=true correctly filtered the returned Istio config objects to the caller’s accessible namespaces, but the validation entries attached to the response were not filtered. Any authenticated user received validation entries (object kind, name, namespace, misconfiguration messages and references to related objects) for Istio objects in every namespace of the cluster. The namespace-scoped variant (GET /api/namespaces/{namespace}/istio?validate=true) is not affected.

In addition, the openshift authentication strategy accepted any token for which user-info lookup succeeded, without checking that the user can view any namespace — unlike the openid strategy, which rejects such users. This widened the audience of the findings above to any valid OpenShift token, including ServiceAccounts that cannot see any namespace.

Mitigation

If you can update:

• Update to Kiali Server v2.34.1 or later. In addition to fixing the findings above, this release makes namespace accessibility checks consistent across all namespace-scoped API endpoints (including tracing endpoints, which previously queried the tracing backend without a namespace check), and the openshift authentication strategy now rejects tokens that cannot view any namespace.

If you cannot update:

• Disable the internal health cache by setting kiali_internal.health_cache.enabled: false in the Kiali CR to close the cluster health exposure.
• Use the namespace-scoped Istio config validations endpoint (GET /api/namespaces/{namespace}/istio?validate=true) instead of the cluster-wide one.
• There is no configuration-level mitigation for the ztunnel log and ztunnel config dump endpoints. If you run an ambient mesh, restrict access to the Kiali Server API (for example, via network policy) so that only trusted users and workloads can reach it.

2 - KIALI-SECURITY-003 - Installation into ad-hoc namespaces

Description

• Disclosure date: May 11, 2021
• Affected Releases: prior to 1.33.0
• Impact Score: 6.6 - AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:L

A vulnerability was found in the Kiali Operator allowing installation of a specified image into any namespace.

Kiali users are exposed to this vulnerability if all the following conditions are met:

• Kiali operator is used for installation.
• Kiali CR was edited to install an image into an unapproved namespace.

This vulnerability is filed as CVE-2021-3495

Mitigation

If you can update:

• Update to Kiali Operator v1.33.0 or later.

If you can not update:

• Ensure only trusted individuals can create or edit a Kiali CRs (resources of kind “kiali”).

3 - KIALI-SECURITY-002 - Authentication bypass when using the OpenID login strategy

Description

• Disclosure date: March 5, 2021
• Affected Releases: 1.26.0, 1.26.1, 1.26.2, 1.27.0, 1.28.0, 1.28.1, 1.29.0, 1.29.1, 1.30.0
• Impact Score: 7.0 - AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N/E:F/RL:X/RC:C

A vulnerability was found in Kiali allowing an attacker to bypass the authentication mechanism. The vulnerability lets an attacker build forged credentials and use them to gain unauthorized access to Kiali.

Kiali users are exposed to this vulnerability if all the following conditions are met:

• Kiali is setup with the openid authentication strategy.
• As a result of configurations in both Kiali and your OpenID server, Kiali uses the implicit flow of the OpenID specification to negotiate authentication.
• Kiali is setup with RBAC turned off.

This vulnerability is filed as CVE-2021-20278

Mitigation

If you can update:

• Update to Kiali v1.31.0 or later.
• If you need an earlier version, only Kiali 1.26.3 and 1.29.2 are fixed.

If you are locked with an older version of Kiali, you have three options:

• Configure Kiali to use the authorization code flow of the OpenID specification; or
• Configure Kiali to use the implicit flow of the OpenID specification and enable RBAC; or
• Configure Kiali to use any of the other available authentication mechanisms.

4 - KIALI-SECURITY-001 - Authentication bypass using forged credentials

Description

• Disclosure date: March 25, 2020
• Affected Releases: 0.4.0 to 1.15.0
• Impact Score: 9.4 - AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H

A vulnerability was found in Kiali allowing an attacker to bypass the authentication mechanism. Currently, Kiali has four authentication mechanisms: login, token, openshift and ldap. All are vulnerable.

The vulnerability lets an attacker build forged credentials and use them to gain unauthorized access to Kiali.

Additionally, it was found that Kiali credentials were not being validated properly. Depending on the authentication mechanism configured in Kiali, this could facilitate unauthorized access into Kiali with forged and/or invalid credentials.

These vulnerabilities are filed as CVE-2020-1762 and CVE-2020-1764

Detection

Use the following bash script to check if you are vulnerable:

KIALI_VERSION=$(kubectl get pods -n istio-system -l app=kiali -o yaml | sed -n 's/^.*image: .*:v\(.*\)$/\1/p' | sort -u)
kubectl get deploy kiali -n istio-system -o yaml | grep -q LOGIN_TOKEN_SIGNING_KEY
TEST_KEY_ENV=$?
kubectl get cm kiali -n istio-system -o yaml | grep signing_key | grep -vq kiali
TEST_KEY_CFG=$?
VERSION_ENTRIES=(${KIALI_VERSION//./ })
echo "Your Kiali version found: ${KIALI_VERSION}"
[ ${VERSION_ENTRIES[0]} -lt "1" ] || ([ ${VERSION_ENTRIES[0]} -eq "1" ] && (\
  [ ${VERSION_ENTRIES[1]} -lt "15" ] || ([ ${VERSION_ENTRIES[1]} -eq "15" ] && ( \
  [ ${VERSION_ENTRIES[2]} -le "0" ])))) && echo "Your Kiali version is vulnerable"
[ $TEST_KEY_ENV -eq 1 ] && [ $TEST_KEY_CFG -eq 1 ] && echo "Your Kiali configuration looks vulnerable"

The script output will be similar to this:

Your Kiali version found: 1.14.0
Your Kiali version is vulnerable
Your Kiali configuration looks vulnerable

Mitigation

• Update to Kiali 1.15.1 or later.

Alternatively, if you cannot update to version 1.15.1, mitigation is possible by setting a secure signing key when deploying Kiali. If you installed via Kiali operator, you could use the following bash script:

SIGN_KEY=$(chars=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890; for i in {1..20}; do echo -n "${chars:RANDOM%${#chars}:1}"; done; echo)
kubectl get kiali -n $(kubectl get kiali --all-namespaces --no-headers -o custom-columns=NS:.metadata.namespace) -o yaml | sed "s/spec:/spec:\n    login_token:\n      signing_key: $SIGN_KEY/" | kubectl apply -f -

If you installed via Istio helm charts or istioctl command, you could use the following bash script:

KIALI_INSTALL_NAMESPACE=istio-system
SIGN_KEY=$(chars=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890; for i in {1..20}; do echo -n "${chars:RANDOM%${#chars}:1}"; done; echo)
kubectl get cm kiali -n $KIALI_INSTALL_NAMESPACE -o yaml | sed "s/server:/login_token:\\n      signing_key: $SIGN_KEY\\n    server:/" | kubectl apply -f -
kubectl delete pod -l app=kiali -n $KIALI_INSTALL_NAMESPACE