CVE-2026-86464: Eclipse aeriOS Auth Bypass Vulnerability

CVE-2026-86464 Overview

CVE-2026-86464 affects the development version of Eclipse aeriOS Identity Manager (IdM), which has not yet reached an official release. The vulnerability stems from insecure default configurations and hardcoded credentials across the IdM deployment stack. The Helm chart exposed Keycloak and its PostgreSQL backing database through Kubernetes NodePort services, while the Docker Compose deployment bound PostgreSQL to all network interfaces. Fixed default credentials for the Keycloak administrator and PostgreSQL database user were shipped without adequate secret management. Predefined application users with published credentials were also provided for development and testing without production warnings. This vulnerability maps to [CWE-200] Exposure of Sensitive Information.

Critical Impact
An attacker reachable on the network can authenticate with published default credentials, gain administrative control over the Identity Manager, and mint privileged tokens accepted by other aeriOS components.

Affected Products

Eclipse aeriOS Identity Manager (development version, pre-release)
Eclipse aeriOS IdM Helm chart deployments
Eclipse aeriOS IdM Docker Compose deployments

Discovery Timeline

2026-09-08 - CVE-2026-86464 published to NVD
2026-09-09 - Last updated in NVD database

Technical Details for CVE-2026-86464

Vulnerability Analysis

The Eclipse aeriOS IdM deployment bundled multiple insecure defaults in a single trust chain. The Keycloak administrator account and the PostgreSQL database user shipped with fixed, publicly documented credentials. The prior Helm chart did not route those credentials through Kubernetes Secrets, leaving them in plaintext manifest values. Predefined application users intended for testing were installed with known passwords and no production removal guidance. Compromise of the Keycloak administrator grants full control over users, roles, client credentials, sessions, and cryptographic key material managed by the IdM. Because other aeriOS components trust tokens issued by the IdM, an attacker can pivot laterally by minting privileged tokens or forging identities across the platform.

Root Cause

The root cause is a combination of insecure default configuration and hardcoded credentials. The Helm chart exposed Keycloak and PostgreSQL through NodePort services by default, making them reachable outside the cluster. The Docker Compose deployment bound PostgreSQL to all interfaces rather than an internal-only network. Static administrator and database credentials were embedded in the deployment templates without dynamic generation or Secret-based storage.

Attack Vector

An unauthenticated remote attacker who can reach the exposed NodePort or exposed PostgreSQL port can authenticate directly using the published default credentials. No user interaction and no prior privileges are required. The attacker can log in to the Keycloak admin console, connect to the PostgreSQL backend, or authenticate as one of the predefined test users.

text

# Security patch: helm/idm/templates/_helpers.tpl
# Adds proper resolution of Keycloak admin credentials via Kubernetes Secret

{{/*
Component keycloak admin credentials secret
*/}}

{{/*
Resolve the Keycloak admin username.
*/}}
{{- define "keycloak.adminUsername" -}}
{{- default "admin" .Values.keycloak.credentials.adminUsername -}}
{{- end -}}

{{/*
Name of the Secret containing Keycloak bootstrapadmin credentials.
*/}}
{{- define "keycloak.adminSecretName" -}}
{{- if .Values.keycloak.credentials.existingSecret -}}
{{- .Values.keycloak.credentials.existingSecret -}}
{{- else -}}
{{- printf "%s-admin" (include "keycloak.fullname" .) -}}
{{- end -}}
{{- end -}}

Source: GitHub Commit 364a8cc

Detection Methods for CVE-2026-86464

Indicators of Compromise

Successful Keycloak administrator logins from unexpected source IPs, particularly outside the cluster CIDR range.
PostgreSQL authentication events from external hosts against the IdM backing database.
Creation of new Keycloak realms, clients, or administrative users not tied to an approved change request.
Issuance of tokens for the predefined development or test users in production environments.

Detection Strategies

Audit Keycloak admin-events and login-events logs for authentication using the default admin account or documented test user identifiers.
Enumerate exposed Kubernetes services and identify any NodePort bindings for the Keycloak or PostgreSQL workloads.
Query Docker Compose deployments for PostgreSQL containers with published ports bound to 0.0.0.0.

Monitoring Recommendations

Forward Keycloak and PostgreSQL logs to a central SIEM and alert on privileged role assignments and client secret changes.
Monitor egress and ingress on Kubernetes node IPs for connections to Keycloak (8080, 8443) and PostgreSQL (5432) service ports.
Track OIDC token issuance patterns for unusual client_id, scope, or subject claims that indicate forged identities.

How to Mitigate CVE-2026-86464

Immediate Actions Required

Upgrade the Eclipse aeriOS IdM deployment to include the fixes from commits 364a8cc and c6135f3.
Rotate the Keycloak administrator password and the PostgreSQL database user password immediately after upgrade.
Remove or change credentials for all predefined development and test users before promoting the environment to production.
Restrict PostgreSQL and OpenLDAP to internal cluster services and disable any NodePort exposure of Keycloak.

Patch Information

The issue is addressed in the upstream eclipse-aerios/idm repository. The fixes generate a random Keycloak administrator password by default, manage Keycloak and PostgreSQL credentials through Kubernetes Secrets, and restrict PostgreSQL and OpenLDAP to internal-only services in both the Helm chart and Docker Compose deployment. Documentation now warns that predefined development users must not be used in production. See GitHub Pull Request #1 and GitLab Vulnerability Report #808.

Workarounds

Override the default Keycloak service type in values.yaml from NodePort to ClusterIP and expose access only through an authenticated ingress.
Bind the Docker Compose PostgreSQL service to 127.0.0.1 or an internal Docker network rather than 0.0.0.0.
Supply custom administrator and database credentials via Kubernetes Secrets using the existingSecret value rather than chart defaults.
Apply network policies to block ingress to Keycloak and PostgreSQL pods from outside the cluster.

bash

# Deploy IdM with ClusterIP service and existing Secret for admin credentials
kubectl create secret generic idm-keycloak-admin \
  --from-literal=username="admin" \
  --from-literal=password="$(openssl rand -base64 32)"

helm upgrade --install idm ./helm/idm \
  --set keycloak.service.type=ClusterIP \
  --set keycloak.credentials.existingSecret=idm-keycloak-admin \
  --set postgresql.service.type=ClusterIP