<!--############################ Do not remove the line above ############################--> <!--Note that this issue is configured (see the quick actions at the bottom) to be created as confidential. Note that a vulnerability does not need to actually be resolved before it is reported and that these reports can be revised as needed (reopen the issue to request changes). If you do not know how to fill certain fields, mark that in the comment and we will help you.--> <!--Required. Specify the project's name (e.g., "Eclipse Dash") and Eclipse Foundation ID, e.g., "technology.dash".--> # Submodel element list returns elements outside the caller's ABAC grant ## Basic information Project name: Eclipse BaSyx Project id: dt.basyx Component: [eclipse-basyx/basyx-go-components](https://github.com/eclipse-basyx/basyx-go-components), images [`aasenvironment-go`](https://github.com/eclipse-basyx/basyx-go-components/tree/fefb8ba56abed1f66ebab6469f495ff8c58da32f/cmd/aasenvironmentservice) and [`submodelrepository-go`](https://github.com/eclipse-basyx/basyx-go-components/tree/fefb8ba56abed1f66ebab6469f495ff8c58da32f/cmd/submodelrepositoryservice) (CWE-863, Incorrect Authorization; severity left to the maintainers) ## What are the affected versions? - Builds run (chart [`basyx` 3.14.0](https://github.com/eclipse-basyx/charts/releases/tag/basyx-3.14.0)): - [v1.1.2](https://github.com/eclipse-basyx/basyx-go-components/releases/tag/v1.1.2) ([commit fefb8ba](https://github.com/eclipse-basyx/basyx-go-components/commit/fefb8ba56abed1f66ebab6469f495ff8c58da32f), latest release on 2026-11-09): [`eclipsebasyx/aasenvironment-go@sha256:b15fc06d1ffe34496c7aec7fb50184497e928d3c2f29b355c20c894f54dae9d0`](https://hub.docker.com/r/eclipsebasyx/aasenvironment-go/tags?name=1.1.2), [`eclipsebasyx/submodelrepository-go@sha256:1ce0d3ed4bbf090e130799d8082b79ba44bcbd73e13f969db9acb4ac30af80cc`](https://hub.docker.com/r/eclipsebasyx/submodelrepository-go/tags?name=1.1.2) - main snapshot [de15c1d4](https://github.com/eclipse-basyx/basyx-go-components/commit/de15c1d4474ea76bce714a85c31e8679be601c0c) (newest published image on 2026-11-09): [`eclipsebasyx/aasenvironment-go:SNAPSHOT-20261106-092530-de15c1d4@sha256:6230879bcacc87fb67d1ab302ace92c6e1bb9fe482e8191c8ca23e0f07f44d3d`](https://hub.docker.com/r/eclipsebasyx/aasenvironment-go/tags?name=SNAPSHOT-20261106-092530-de15c1d4), [`eclipsebasyx/submodelrepository-go:SNAPSHOT-20261106-092534-de15c1d4@sha256:cb66d0a8b96caca3b5a07aac70e5b633380cd1a6c27a1963800076faba09a479`](https://hub.docker.com/r/eclipsebasyx/submodelrepository-go/tags?name=SNAPSHOT-20261106-092534-de15c1d4) Main has [later commits](https://github.com/eclipse-basyx/basyx-go-components/compare/de15c1d4474ea76bce714a85c31e8679be601c0c...8332d6ceaca6f06509198e0555e93871720f617c) without a published image yet, among them [#854](https://github.com/eclipse-basyx/basyx-go-components/pull/854), which changes [`internal/submodelrepository/persistence/submodel_read_database.go`](https://github.com/eclipse-basyx/basyx-go-components/blob/8332d6ceaca6f06509198e0555e93871720f617c/internal/submodelrepository/persistence/submodel_read_database.go). That state was not run. Earlier versions not checked. ## Details of the issue With ABAC on, a caller whose rules grant READ on one Submodel Element of a Submodel gets every element of that Submodel, with values, from `GET /submodels/{id}/submodel-elements`. This happens in both `aasenvironment-go` and `submodelrepository-go`. The single-element route enforces the grant: the granted element answers `200`, every other element answers `403`. The full read (`GET /submodels/{id}`, `/$value`) answers `403`. Only the list route returns the ungranted elements. A caller with a valid token and no matching rule gets `200` with an empty list, so the route does filter, but one matching element exposes the whole list. The documented semantics say a `$sme` `REFERABLE` covers "the named element and all descendants at segment boundaries" ([security_architecture.md L408–425](https://github.com/eclipse-basyx/basyx-go-components/blob/fefb8ba56abed1f66ebab6469f495ff8c58da32f/docu/developer/security_architecture.md#L408-L425)), not its siblings. Expected: `GET /submodels/{id}/submodel-elements` returns only the elements the caller's rules cover (here `GearRatio`), or `403`, consistent with the single-element route. We evaluate BaSyx Go as provider backend in a Catena-X research demonstrator, where access per business partner is a core requirement. Element-level grants are the natural way to share part of a submodel with one partner; with this behaviour they leak the rest of it. I'm reporting this privately so it can be fixed before it is discussed in public. Request scripts and raw responses are available on request. ## Steps to reproduce 1. AAS environment (`/aas-environment`) or submodel repository (`/submodel-repo`) with ABAC on and OIDC (Keycloak), a Submodel `urn:uuid:design-poc-001` with five Properties (`GearRatio`, `MagnetGrade`, `RatedTorqueNm`, `StatorLaminationSteel`, `WindingScheme`), created by a caller with full rights. 2. Access rules: the restricted caller (claim `Edc-Bpn` = `BPNL00000003AZQP`, role `view_digital_twin`) may read one element: ```json { "AllAccessPermissionRules": { "DEFATTRIBUTES": [{ "name": "role_attr", "attributes": [{ "CLAIMPATH": "/role" }] }], "DEFOBJECTS": [ { "name": "everything", "objects": [{ "IDENTIFIABLE": "$aas(\"*\")" }, { "IDENTIFIABLE": "$sm(\"*\")" }, { "IDENTIFIABLE": "$cd(\"*\")" }] }, { "name": "b_objects", "objects": [{ "REFERABLE": "$sme(\"urn:uuid:design-poc-001\").GearRatio" }] } ], "DEFACLS": [ { "name": "token_all", "acl": { "USEATTRIBUTES": "role_attr", "RIGHTS": ["ALL"], "ACCESS": "ALLOW" } }, { "name": "token_read", "acl": { "USEATTRIBUTES": "role_attr", "RIGHTS": ["READ"], "ACCESS": "ALLOW" } } ], "DEFFORMULAS": [ { "name": "is_provider", "formula": { "$contains": [{ "$attribute": { "CLAIMPATH": "/role" } }, { "$strVal": "add_digital_twin" }] } }, { "name": "bpn_b", "formula": { "$and": [ { "$contains": [{ "$attribute": { "CLAIMPATH": "/role" } }, { "$strVal": "view_digital_twin" }] }, { "$eq": [{ "$attribute": { "CLAIM": "Edc-Bpn" } }, { "$strVal": "BPNL00000003AZQP" }] } ] } } ], "rules": [ { "USEACL": "token_all", "USEOBJECTS": ["everything"], "USEFORMULA": "is_provider" }, { "USEACL": "token_read", "USEOBJECTS": ["b_objects"], "USEFORMULA": "bpn_b" } ] } } ``` 3. With a token carrying `Edc-Bpn: BPNL00000003AZQP`: - `GET /submodels/{id}/submodel-elements/GearRatio` → `200` - `GET /submodels/{id}/submodel-elements/MagnetGrade` → `403` - `GET /submodels/{id}` and `/$value` → `403` - `GET /submodels/{id}/submodel-elements` → `200`, all five elements with values 4. Same request with a token without `Edc-Bpn` → `200`, `[]`. Observed running on 2026-11-09: - AAS environment v1.1.2, with a second partner's rule added once as per-element `REFERABLE` grants and once as `IDENTIFIABLE $sm(...)`. The result for the restricted caller was the same in both. - AAS environment and submodel repository, each on v1.1.2 and on the main snapshot de15c1d4, with the rules above: same result in all four. ## Do you know any mitigations of the issue? Not tested as a fix. Avoid `$sme` `REFERABLE` grants for callers who must not see the rest of the submodel. Grant such callers only whole submodels (`IDENTIFIABLE $sm(...)`) and move data they must not see into a separate submodel. Reporter: eric.nowak@msg.group