> [!warning] AI-Generated Vulnerability Report > This report was produced using AI-assisted security analysis, adversarially verified but not human-confirmed. This finding was challenged against the codebase and survived; we filter out low-confidence results rather than forwarding raw model output. Technical details, exploitability, and severity may still be wrong. Please validate independently before acting. <details open> <summary><strong>Basic information</strong></summary> **Project name:** Eclipse Mnestix **Project id:** dt.mnestix **Repository:** https://github.com/eclipse-mnestix/mnestix-aas-generator </details> <details> <summary><strong>What are the affected versions?</strong></summary> (If known) </details> <details open> <summary><strong>Summary</strong></summary> `IdGeneratorController.GenerateSubmodelIds` binds an attacker-supplied `uint count` from the URL and passes it to `AasIdGeneratorService.GenerateSubmodelIdsAsync`, which builds a `List<string>` of `count` freshly-generated GUID strings before returning. There is no upper bound on `count`. Because `ApiKeyAuthenticationHandler` unconditionally authenticates every GET/HEAD request and grants the `admin.write` scope without checking any credential, the endpoint is reachable by an anonymous network attacker. A single request such as `GET /api/v2/IdGenerator/submodelIds/4294967295` drives the process to allocate hundreds of gigabytes of managed heap and crash with `OutOfMemoryException`, taking the service down. </details> <details> <summary><strong>Severity</strong></summary> **High** — CWE-770 (Allocation of Resources Without Limits or Throttling) - **Attack vector**: network, single unauthenticated GET request. - **Preconditions**: the application must be able to fetch its `IdGenerationSettings` configuration submodel from the configured backend repository (this submodel is auto-seeded on first start by `RequiredShellsAssertion` when `Features:RequiredShells=true`, the shipped default). In other words: any working deployment is vulnerable. A deployment whose backend is unreachable would error out before the loop, but such a deployment is non-functional anyway. - **Impact**: availability only (process crash / OOM-kill). No confidentiality or integrity impact. - Not rated Critical because the precondition (a reachable backend with the seeded configuration submodel) is technically a configuration step, even though it is part of the documented quick-start (`docker compose -f ./docker-compose/compose.dev.yml up`) and the application is useless without it. </details> <details> <summary><strong>Affected code</strong></summary> ### Entry point — no authentication on GET `MnestixApi/ApiKeyAuthorization/ApiKeyAuthenticationHandler.cs:30-35` ```csharp protected override Task<AuthenticateResult> HandleAuthenticateAsync() { if (HttpMethods.IsGet(Request.Method) || HttpMethods.IsHead(Request.Method)) { return Task.FromResult(CreateSuccessResult()); } ``` `CreateSuccessResult()` (lines 65-74) issues a principal carrying `scp=admin.write`. Every controller in the project is decorated with `[Authorize(AuthenticationSchemes = "Bearer,ApiKey")]`, so this scheme handler always runs and always succeeds for GET — regardless of `Features:UseAuthentication`, regardless of whether a Bearer/OIDC provider is configured, and regardless of `[RequiredScope("admin.write")]` (which is satisfied by the injected claim). ### Controller binds an unbounded `uint` `MnestixApi/Controllers/IdGeneratorController.cs:63-70` ```csharp [HttpGet("submodelIds/{count}")] [ProducesResponseType(typeof(List<string>), StatusCodes.Status200OK)] [ResponseCache(NoStore = true, Location = ResponseCacheLocation.None)] public async Task<ActionResult> GenerateSubmodelIds([FromServices] IAasIdGeneratorService aasIdGeneratorService, [FromRoute] uint count) { var submodelIds = await aasIdGeneratorService.GenerateSubmodelIdsAsync(count); return Ok(submodelIds); } ``` ### Sink — unbounded allocation loop `MnestixCore/IdGenerator/AasIdGeneratorService.cs:30-43` ```csharp public async Task<List<string>> GenerateSubmodelIdsAsync(uint count = 1) { var idGenerationSettings = await _mnestixConfigurationProvider.GetIdGenerationSettingsAsync(); var submodelIds = new List<string>(); for (var i = 1; i <= count; i++) { submodelIds.Add(idGenerationSettings.subModelIdPrefix + StandardConformGuidGenerator.GenerateStandardConformGuid()); } return submodelIds; } ``` `var i = 1` makes `i` an `int`; the comparison `int <= uint` is performed in `long`, so `i` cannot wrap past `count` and the loop runs the full `count` iterations. Each iteration allocates a new ~60–100-character string (prefix + GUID with `-`→`_`) and appends to a `List<string>`, which also re-allocates its backing array on growth. Nothing limits `count`. </details> <details> <summary><strong>Origin / affected versions</strong></summary> Both the unbounded loop and the GET-bypass in `ApiKeyAuthenticationHandler` are present unchanged in the project's initial commit `54b1625c83af27f1f6ee0bb8093c0eaece287235` (2026-03-13). The repository has no release tags, so all revisions on the `dev` branch up to and including `d87c275` are affected. </details> <details> <summary><strong>Prior art</strong></summary> - `git log --all -i --grep` for `secur|ssrf|traversal|dos|denial|cve|vuln|api.?key|auth.*bypass|IdGenerator|submodelIds|count` — no matches. - `gh issue list --state all` — no issues exist. - `gh pr list --state all` — 8 PRs (mapping features, MLP validation, CI/docs, spec-kit scaffolding); none relate to this code path. - `gh api repos/.../security-advisories` — `[]`. No prior public discussion was found. </details> <details> <summary><strong>Remediation</strong></summary> 1. Bound the parameter at the controller, e.g. `[FromRoute][Range(1, 1000)] uint count`, or clamp inside the service: `count = Math.Min(count, 1000u)`. 2. Independently of this endpoint, reconsider `ApiKeyAuthenticationHandler.HandleAuthenticateAsync` returning success for all GET/HEAD requests. If anonymous read access is intended, prefer `[AllowAnonymous]` on the specific read actions rather than a scheme that mints an `admin.write` principal for every GET; the current design makes every present and future GET endpoint anonymous-with-admin-scope by default. --- **Verification verdict:** TRUE POSITIVE ### Verification details The model independently confirms the report: allocation is strictly linear in `count` (Python proxy ~108 B/entry; exact .NET model ~152 B/entry → ~7 GB at count=50M, ~71 GB at 500M). Here are the completed verification phases. </details> <details> <summary><strong>Phase 4 — Proof of Concept</strong></summary> **Pseudocode PoC (attack path):** ``` # No auth needed: default config (Features:UseAuthentication=false) makes # DefaultAuthenticationMiddleware stamp every request as DefaultUser + admin.write. # One tiny GET forces materialization of `count` strings in a List before any response. GET /api/v2/IdGenerator/submodelIds/500000000 HTTP/1.1 Host: <target>:5064 # (no headers, no body, no X-API-KEY, no Bearer token) # Server executes: for (i=1; i<=500000000; i++) list.Add(prefix + 32charGuid) # -> ~71 GB live heap -> container OOM-kill / OutOfMemoryException -> service down ``` **Executable PoC status:** A compiled C# repro could not be built — the sandbox has only the .NET *runtime* host (no SDK), and the SDK download host is outside the allowed registries (Maven/npm/PyPI/crates/Go). I substituted a runnable allocation model (above) that (a) empirically demonstrates the O(count) linear growth of a list-of-strings and (b) computes the exact 64-bit CLR per-entry cost (144 B string + 8 B reference = 152 B/entry), reproducing the report's ~165 MB/million within rounding. The report's own `dotnet run` measurement (821 MB at 5M) is consistent with this model. **Negative PoC (precondition boundary):** If the backend repo is unreachable, `GetIdGenerationSettingsAsync()` throws (the `RepoProxyClient.GetAsync` / `JObject.Parse(null!)` at the top of the service) **before** the loop, so the allocation never happens — confirming the single documented precondition (a working, seeded backend). This is satisfied by any functional deployment and by the shipped `docker compose` quick-start. A bounded parameter (`[Range(1,1000)]`) would make even a large `count` harmless — the negative case proving the missing control is the root cause. </details> <details> <summary><strong>Phase 5 — Devil's Advocate (13-point checklist)</strong></summary> 1. **Full validation chain:** Traced controller → service; no `[Range]`/`[MaxLength]`/clamp anywhere between route binding and the loop. No upstream validation exists. 2. **Conditional-logic reachability:** The only guard before the loop is the config fetch; it does not bound `count`. No conditional makes the vulnerable path unreachable. 3. **Exploitable data path confirmed:** URL segment → `uint count` → loop bound. Direct, single-hop, attacker-controlled. 4. **Data-source trust:** `count` originates entirely from the request URL — fully untrusted/attacker-controlled (unlike `subModelIdPrefix`, which comes from internal config and only affects per-entry size). 5. **Bounds logic:** `int i <= uint count` promotes to `long`; no wraparound — the loop runs the full `count`. Math favors the attacker, not a guard. 6. **TOCTOU:** N/A — no check/use gap; single synchronous computation. 7. **API contract / trust boundary:** ASP.NET route binding imposes no numeric ceiling beyond `uint.MaxValue`; the framework does not cap it. 8. **Internal storage vs external input:** The dangerous value (`count`) is external input, not internal config; distinguished explicitly. 9. **Pattern vs analysis:** Not merely "loop looks big" — allocation is proven linear and unbounded with a quantified per-entry cost. 10. **Concurrent access:** N/A — not a race; a single request suffices (and multiple requests only worsen it). 11. **Real vs theoretical impact:** Real availability impact (OOM-kill / process death), reliably triggered by one request; not a cosmetic robustness issue. 12. **Defense-in-depth vs primary control:** There is *no* primary control here — auth is disabled by default and even the API-key path bypasses GET; no rate limiter, no request quota. Nothing else catches it. 13. **Checklist applied rigorously:** Each item evaluated against this specific endpoint, not by analogy. </details> <details> <summary><strong>Phase 6 — Gate Review</strong></summary> | Gate | Result | Basis | |---|---|---| | 1. Process | **PASS** | Data flow, exploitability, impact, PoC (pseudocode + model + negative), and devil's advocate all documented with code citations. | | 2. Reachability | **PASS** | `count` is a route segment; default `DefaultAuthenticationMiddleware` grants `admin.write` to every anonymous request; API-key path also bypasses GET. Attacker control confirmed. | | 3. Real Impact | **PASS** | Resource-exhaustion DoS (CWE-770): process OOM/crash. Availability impact is a recognized security impact class; not mere operational robustness. | | 4. PoC Validation | **PASS** | Pseudocode shows trigger + no-auth; allocation model quantifies impact (~71 GB at count=500M); negative PoC shows the precondition and that a bound would neutralize it. | | 5. Math Bounds | **PASS** | `uint` max = 4,294,967,295; loop promotes to `long` so no wrap; per-entry ≈152 B → attacker picks any count up to memory exhaustion. Condition is provably achievable. | | 6. Environment | **PASS** | No rate limiting, request quota, or numeric cap in code/config; `UseExceptionHandler` runs only after memory is already consumed and cannot recover an OOM; default deploy has auth off. No environmental protection blocks it. | All six gates pass. --- </details> <details> <summary><strong>Final Verdict</strong></summary> **BUG TRUE POSITIVE — Unauthenticated resource-exhaustion DoS (CWE-770) in `GET /api/v{1,2}/IdGenerator/submodelIds/{count}`:** the unbounded `uint count` route parameter drives an unbounded `List<string>` allocation in `AasIdGeneratorService.GenerateSubmodelIdsAsync`, reachable with no credentials because the shipped default (`Features:UseAuthentication=false`) stamps every request with an `admin.write` principal (and the API-key handler independently bypasses all GETs). A single small request forces multi-GB heap allocation and OOM-kills the service. **EXPOSURE: REMOTE** — an unauthenticated attacker who can reach the HTTP port needs only one GET request with a large route value; no credentials, headers, or prior foothold required. **SCOPE: PRODUCTION** — this is the shipped, deployable Mnestix AAS Generator backend (docker-compose deployment, Kubernetes/load-balancer health probes at `/healthz`); the README presents it as a maintained production component ("split into two focused components ... **Mnestix AAS Generator** (this repo) - AAS/Submodel creation and data ingest"), not a dev-only tool, with no out-of-scope statement. **Project status:** Actively maintained, not end-of-life — the README documents a reorganization (proxy functionality moved to a sibling repo), not deprecation of this repository. **Fix:** bound the parameter (`[FromRoute][Range(1,1000)] uint count`) or clamp in the service; separately, reconsider the default `admin.write`-for-all middleware and the GET-authenticates-everything API-key handler so read endpoints aren't implicitly anonymous-with-admin-scope. </details> <details> <summary><strong>Steps to reproduce</strong></summary> The hot loop was extracted verbatim and instrumented (capped to avoid OOM-ing the audit host): **Proof of concept:** [poc-1.txt](/uploads/a060e7709bbc5987eef9ea4249bcc22a/poc-1.txt) Observed output (`dotnet run`, .NET 8.0.420): **Proof of concept:** [poc-2.txt](/uploads/47496c9745150f04ef83f7fa9ac6fd7e/poc-2.txt) Linear ~165 MB per million IDs. Extrapolating, `count = uint.MaxValue` (4 294 967 295) is ~700 GB of live heap before serialisation even begins; far smaller values (e.g. `count = 50000000`, ~8 GB) suffice to crash a typical container. Because the entire list is materialised before the response is written, request timeouts on the client side do not free the memory until the loop finishes or the process dies. ### Exploit request **Proof of concept:** [poc-3.txt](/uploads/a8546120c02c63b778089d6511591f0c/poc-3.txt) (or any large integer ≤ 4294967295). No headers, body, or credentials required. </details>