CVE-2026-82955: Eclipse aeriOS Auth Bypass Vulnerability

CVE-2026-82955 Overview

CVE-2026-82955 affects the development version of Eclipse aeriOS, specifically the KrakenD instance bundled with the API Gateway component. The disable_jwk_security parameter was hard-coded to true in the Helm chart templates, with no operator-facing option to override it. This setting disables TLS certificate verification when KrakenD retrieves the JSON Web Key Set (JWKS) used to validate bearer tokens. An attacker positioned to intercept the JWKS retrieval traffic can serve a malicious key set and forge or accept crafted JWTs, undermining API authentication. The issue is tracked under [CWE-295: Improper Certificate Validation].

Critical Impact

An attacker capable of intercepting the KrakenD-to-Keycloak JWKS communication can substitute the JWKS response and compromise bearer token validation across the API Gateway.

Affected Products

• Eclipse aeriOS (current development version, no official release yet)
• Eclipse aeriOS API Gateway component (KrakenD instance)
• Helm chart templates _benchmark.tpl and _dataFabric.tpl

Discovery Timeline

• 2026-09-02 - CVE-2026-82955 published to NVD
• 2026-09-02 - Last updated in NVD database

Technical Details for CVE-2026-82955

Vulnerability Analysis

KrakenD validates bearer tokens by fetching the issuer's JWKS from a configured URL, typically a Keycloak realm certificates endpoint. When disable_jwk_security is set to true, KrakenD skips TLS certificate verification on that outbound HTTPS request. The Eclipse aeriOS Helm chart hard-coded this flag in both the benchmark and data fabric API Gateway configurations, so every deployment inherited the insecure default. Because the JWKS is the source of truth for signature verification, an attacker who can intercept and modify this connection controls which public keys KrakenD will trust. Forged tokens signed with the attacker's key then pass validation, granting unauthorized access to any protected upstream service behind the gateway.

Root Cause

The root cause is an insecure hard-coded configuration in the Helm chart templates. The KrakenD JSON configuration set "disable_jwk_security": true as a static value rather than parameterizing it through Helm values. Operators had no supported mechanism to enable TLS verification without forking the chart.

Attack Vector

Exploitation requires a network position between the KrakenD gateway and the Keycloak identity provider. This includes compromised intermediate infrastructure, DNS spoofing, ARP poisoning within the cluster network, or a malicious egress proxy. Once positioned, the attacker returns a JWKS containing attacker-controlled keys and issues bearer tokens accepted as valid by KrakenD.

// Vulnerable Helm template (before patch)
"jwk_url": "{{ $.Values.krakend.config.keycloakUrl }}/realms/{{ $.Values.krakend.config.keycloakRealm }}/protocol/openid-connect/certs",
"disable_jwk_security": true

// Patched Helm template
"jwk_url": "{{ $.Values.krakend.config.keycloakUrl }}/realms/{{ $.Values.krakend.config.keycloakRealm }}/protocol/openid-connect/certs",
"disable_jwk_security": {{ $.Values.krakend.config.disableJwkSecurity }}

Source: GitHub Commit e680c69

Detection Methods for CVE-2026-82955

Indicators of Compromise

• Unexpected JWKS responses from the Keycloak endpoint containing key IDs (kid) or public keys not issued by the legitimate identity provider.
• Successful KrakenD token validations for JWTs whose iss or kid claims do not match the authorized Keycloak realm.
• TLS handshake anomalies or certificate mismatches on egress connections from the API Gateway pod to the Keycloak service.

Detection Strategies

• Inspect rendered KrakenD configuration inside the API Gateway pod and confirm whether disable_jwk_security is set to true.
• Audit deployed Helm releases with helm get values to identify chart versions that predate the krakend.config.disableJwkSecurity value.
• Capture and review outbound traffic from KrakenD to the JWKS endpoint to confirm TLS certificate chain validation is enforced.

Monitoring Recommendations

• Alert on API Gateway authentication events that reference unknown signing key identifiers.
• Monitor Kubernetes network policies and DNS resolution paths between the API Gateway and Keycloak for tampering.
• Log and review changes to Helm values controlling the KrakenD configuration.

How to Mitigate CVE-2026-82955

Immediate Actions Required

• Update the Eclipse aeriOS API Gateway Helm chart to the version containing commit e680c69c34b82db4944517198330cc447a1e8f98.
• Explicitly set krakend.config.disableJwkSecurity to false in your Helm values to enforce TLS certificate verification.
• Rotate any bearer tokens or client secrets that may have been exposed while the vulnerable configuration was active.

Patch Information

The fix introduces a new Helm value krakend.config.disableJwkSecurity, defaulting to false, and threads it through both helm-chart/templates/_benchmark.tpl and helm-chart/templates/_dataFabric.tpl. See the GitHub Commit Update and the Eclipse Security Vulnerability Report for full details.

Workarounds

• Fork the Helm chart and manually replace the hard-coded "disable_jwk_security": true with false in the affected templates until the patched chart can be adopted.
• Restrict egress from the API Gateway namespace so the JWKS URL can only resolve to the trusted Keycloak service using a Kubernetes NetworkPolicy or service mesh policy.
• Terminate the JWKS connection at a trusted in-cluster proxy that enforces certificate pinning to the Keycloak endpoint.

# Configuration example: patched Helm values
krakend:
  config:
    keycloakUrl: "https://keycloak.example.internal"
    keycloakRealm: "aerios"
    disableJwkSecurity: false