In Eclipse BaSyx AAS Web UI versions v2-241220 through releases before v2-260924, the shared request handler attached the selected infrastructure's Authorization header to outgoing requests without checking the destination origin. In deployments using authentication, an attacker could induce a user to open a crafted Web UI link whose aas or path query parameter points to an attacker-controlled endpoint. The user's browser would then send the configured Basic Authentication credentials, Bearer token, or an available OAuth2 access token to that endpoint. The attacker could reuse the disclosed credential to access protected AAS services with the victim's privileges. The issue is fixed in v2-260924.

In Eclipse BaSyx Helm Charts version 2.2.0 of the aas-basyx-v2-full chart, deployments with the bundled Keycloak enabled store the client secret of the basyx-technical-user OAuth2 client in cleartext in a Kubernetes ConfigMap. This client uses the client-credentials grant and its service account holds the realm admin role.

The chart correctly writes keycloak.technicalUser.clientSecret to a Kubernetes Secret, but the template basyx-keycloak-realm.yaml also substitutes the same value into the Keycloak realm-import JSON, which is stored in the ConfigMap <keycloak.fullnameOverride>-realm. A principal that can read ConfigMaps but not Secrets in the release namespace, such as a holder of the built-in Kubernetes view ClusterRole, can read the client secret from the ConfigMap. They can then exchange it at the Keycloak token endpoint for an access token with the admin role. That token grants full create, read, update, delete and execute rights on all BaSyx repositories and registries in the deployment.

The bundled Keycloak is disabled by default. No fixed release of the aas-basyx-v2-full chart exists. Affected users should migrate to the basyx chart, or deploy without the bundled Keycloak and rotate the basyx-technical-user client secret.

In Eclipse BaSyx Go Components versions up to and including 1.1.3, ABAC-enabled deployments match ROUTE access rules against the fully decoded request path, while the router routes on the raw, still encoded path. An encoded slash (%2F) inside a path value is a segment separator for the access check but part of the value for the router, so a request can match a narrow ROUTE rule while the handler returns a different, larger resource.

An authenticated caller whose rules grant READ only on parts of a resource can therefore read the whole resource. In the DPP API, a rule such as /v1/dpps//elements/, meant to grant only passport elements, also grants the complete passport whose identifier contains /elements/. In the Submodel Repository, AAS Repository and AAS Environment, a rule such as /submodels//submodel-elements//attachment, meant to grant only file attachments, also grants the complete element whose stored idShort contains %2F.

The issue is fixed in Eclipse BaSyx Go Components v1.1.4.