> [!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 Langium **Project id:** ecd.langium **Repository:** https://github.com/eclipse-langium/langium </details> <details> <summary><strong>What are the affected versions?</strong></summary> `langium-sprotty` ≥ 3.0.0 (every release that contains `hover-popup.ts`: v3.0.0 – v4.2.2 inclusive, and current `main`). </details> <details> <summary><strong>Details of the issue</strong></summary> # Summary `addHoverPopupHandler()` in `langium-sprotty` builds an HTML hover-popup for diagnostic markers by interpolating `diagnostic.message` into a template string with no HTML escaping, then ships the result to the Sprotty client as `PreRenderedElement.code`. Sprotty's `PreRenderedView` parses that string with `DOMParser` and copies **all** attributes — including `onerror`/`onclick` — into snabbdom's `attrs` module, which applies them via `setAttribute()`. An inline event-handler attribute set this way is live. Diagnostic messages routinely embed text taken from the (untrusted) source file being analysed. Langium's own default unresolved-reference message does: ``Could not resolve reference to ${type} named '${ref.$refText}'.`` In a Langium-based language whose grammar allows a `STRING`-backed cross-reference, opening a malicious source file, viewing its Sprotty diagram, and hovering the error marker executes attacker-supplied JavaScript in the diagram webview/browser. # Severity **Low.** This is a real missing-escape bug in first-party code, but exploitation requires a long chain of opt-ins that are not present in any product shipped from this repository, nor in any public consumer found via GitHub code search: 1. The downstream language must depend on the optional `langium-sprotty` package and render a Sprotty diagram in a browser/webview. 2. It must explicitly call `addHoverPopupHandler(services)` — an opt-in helper, never called inside this repo. 3. Its diagram generator must call `services.diagram.DiagnosticMarkerProvider.addDiagnosticMarker(...)` so that markers carrying diagnostics actually appear in the model. 4. A diagnostic on a diagram-mapped node must contain attacker-controlled `<`/`>`/`"` characters. The shortest in-framework path is a grammar with a cross-reference whose terminal admits those characters (e.g. `target=[Type:STRING]`); the more general path is any custom validator that interpolates a string-literal token value into its message text — which is common practice but is downstream code. 5. The victim must hover the marker. None of the example languages in this repo (arithmetics, domainmodel, requirements, statemachine) wire up `addHoverPopupHandler`, and no cross-reference in the repo uses a terminal broader than `ID`/`QualifiedName` (`ID ('.' ID)*`). GitHub code search for `addHoverPopupHandler` returns only the definition site. Under the rubric (Critical = fresh quickstart, no preconditions; High = realistic preconditions; Medium = significant positioning; Low = unrealistic preconditions), the stacked opt-ins plus the absence of any known affected consumer place this at **Low**. It is reported rather than dismissed because (a) the helper is the documented, public way to get diagnostic tooltips in Langium+Sprotty diagrams, (b) LSP `Diagnostic.message` is plain text by spec, so a downstream author has no reason to pre-escape it, and (c) the fix is a one-liner. # Weakness CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-Site Scripting). Specifically, server-side template injection of plain text into an HTML context without entity-encoding. # Location - Sink: `packages/langium-sprotty/src/hover-popup.ts:61-73` (`generateDiagnosticInfo`) and `:38-45` (wrapping in `PreRenderedElement`). - Feed: `packages/langium-sprotty/src/diagnostic-marker-provider.ts:42-45` (`message: diagnostic.message` copied verbatim from `document.diagnostics`). - Built-in source containing untrusted text: `packages/langium/src/references/linker.ts:367` (default linking-error message embeds `refInfo.reference.$refText`). - Renderer (third-party, for context only): `sprotty` package, `src/lib/virtualize.ts` `buildVNodeData()` puts every attribute except `style`/`class` into `data.attrs`; snabbdom's attributes module applies them with `elm.setAttribute(name, value)`. # Origin Introduced in commit `2a308c51` "New features for langium-sprotty: selection synchronization, diagnostic markers" (first released in **v3.0.0**; unchanged through current `main` / v4.2.2). # Methodology Manual source review of the monorepo focused on places where untrusted input (workspace source files, LSP request payloads, workspace config) reaches a sink (HTML, file system, child process, dynamic property assignment). Candidate sinks were enumerated by grepping for `innerHTML`, `webview.html`, `exec`/`spawn`, `JSON.parse`, `obj[k] =`, template-literal HTML, and by reading each package's entry points. For each candidate the data source was traced back across the trust boundary; sinks fed only by developer-authored grammar or config were ruled out. The remaining candidate (this finding) was validated with a runnable reproduction against the built `lib/` output, and the client-side renderer behaviour was confirmed by reading the upstream Sprotty source. The following sinks were examined and **ruled out** (see *Other areas reviewed* below for one-line rationales): railroad webview HTML, JSON serializer/hydrator prototype pollution, `ConfigurationProvider` settings write, scope/`MultiMap` symbol storage, DI `_merge`, parser `assign()`, `RenameProvider` `changes[uri]`, `generator-langium` `spawnSync`, `langium-vscode` `langium-config.json` ingestion, and `langium-cli` template generation. # Validation Reproduction script (committed alongside this report as `test-sprotty-hover-xss.mjs` at the repo root) drives the real `addHoverPopupHandler` with a marker whose `issues[0].message` is the default linker error containing `<img src="x" onerror="alert(document.domain)"/>`, captures the dispatched `SetPopupModelAction`, and inspects `newRoot.children[0].code`. ``` $ node test-sprotty-hover-xss.mjs === PreRenderedElement sent to sprotty client === type: pre-rendered code: <div class="sprotty-infoBlock"> <div class="sprotty-infoRow"> <div class="sprotty-infoText"> <span class="sprotty-error">Could not resolve reference to Entity named '<img src="x" onerror="alert(document.domain)"/>'.</span> </div> </div> </div> === Verdict === code contains literal "<img": true code contains literal "onerror=": true VULNERABLE: diagnostic message reaches PreRenderedElement.code unescaped. ``` The emitted `code` is well-formed XML (Sprotty parses with `DOMParser.parseFromString(html, "application/xml")`), so the `<img>` element is created with `src` and `onerror` attributes intact. Client-side confirmation (Sprotty `virtualize.ts`, master): ```ts function buildVNodeData(attrs) { const addData = (memo, name) => { if (name !== 'style' && name !== 'class') { const val = unescapeEntities(attrs[name]); memo ? memo[name] = val : memo = { [name]: val }; } return memo; }; const _attrs = Object.keys(attrs).reduce(addData, null); if (_attrs) data.attrs = _attrs; ... } ``` snabbdom's `attributesModule` then does `elm.setAttribute(key, cur)` for each entry, so `onerror` becomes a live inline handler. # Detail `expandToString` (`packages/langium/src/generate/template-string.ts:26`) is a whitespace-alignment helper for code generation; it performs **no** HTML-entity encoding. `generateDiagnosticInfo` uses it to splice `issue.message` (and `issue.severity`) into HTML: ```ts function generateDiagnosticInfo(marker: SDiagnosticMarker): string { return expandToString` <div class="sprotty-infoBlock"> <div class="sprotty-infoRow"> ${marker.issues.map(issue => expandToString` <div class="sprotty-infoText"> <span class="sprotty-${issue.severity}">${issue.message}</span> </div> `).join()} </div> </div> `; } ``` `issue.message` is populated by `DefaultDiagnosticMarkerProvider`: ```ts const issues = diagnostics.map(diagnostic => ({ message: diagnostic.message, // ← verbatim severity: convertSeverity(diagnostic) }) satisfies LangiumSprottyIssue); ``` `document.diagnostics` is the standard validation/linking output. Langium's own `DefaultLinker.createLinkingErrorMessage` (`packages/langium/src/references/linker.ts`) produces: ```ts return `Could not resolve reference to ${referenceType} named '${refInfo.reference.$refText}'.`; ``` `$refText` is the literal token text the parser consumed for the cross-reference. With the default `[Type:ID]` syntax it is restricted to `/\^?[_a-zA-Z][\w_]*/` and cannot carry `<`. But Langium explicitly supports arbitrary terminals here — `[Type:STRING]` is the documented pattern for languages whose identifiers may contain spaces/punctuation, and the `STRING` terminal admits any character. Downstream custom validators that quote a string-literal value in their message (`"Unknown import '${node.path}'"` etc.) reach the same sink without needing the linker path. `severity` is mapped through `convertSeverity()` to one of `'error' | 'warning' | 'info'`, so the `class="sprotty-${issue.severity}"` interpolation is not independently exploitable. # Other areas reviewed (ruled out) | Sink | File | Why not a finding | |---|---|---| | Railroad webview (`enableScripts:true`) | `packages/langium-vscode/src/railroad-webview.ts:84-110`, `packages/langium-railroad/src/grammar-railroad.ts:109,131` | Rule names are `ID`-only; keyword text reaches `railroad-diagrams` `Terminal`, whose `escapeString` entity-encodes `< & [ ] * _ \``. Verified by running a grammar with `'<img src=x onerror=alert(1)>'` as a keyword: output contained `&\#60;img ...`. | | `JsonSerializer.deserialize` → `linkNode` `node[prop]=` | `packages/langium/src/serializer/json-serializer.ts:147+` | Only reachable via `loadGrammarFromJson` on developer-generated grammar JSON bundled at build time; not attacker-reachable. | | `Hydrator.hydrateAstNode` `astNode[name]=` | `packages/langium/src/serializer/hydrator.ts:222-237` | Property names come from the grammar's reflection metadata (trusted); values come from worker-thread `structuredClone` of an AST the same process produced. | | `ConfigurationProvider` `this.settings[section]=` | `packages/langium/src/workspace/configuration.ts:154` | `section` derives from `services.LanguageMetaData.languageId` (developer constant) or from `DidChangeConfigurationParams` sent by the trusted editor; mutates a fresh `{}` instance, not a prototype. | | Scope symbol storage by attacker-chosen name | `packages/langium/src/references/scope.ts`, `packages/langium/src/utils/collections.ts` | All name→description maps are `Map`/`MultiMap` (backed by `new Map()`), immune to `__proto__`/`constructor` keys. | | DI `_merge` deep-merge | `packages/langium/src/dependency-injection.ts:153-182` | Inputs are developer-authored service modules; never fed untrusted data. | | `LangiumParser.assign` `obj[feature]=` | `packages/langium/src/parser/langium-parser.ts:557-583` | `feature` is a grammar `Assignment.feature` name — fixed at parser-build time from the (trusted) grammar, not from the parsed source. | | `RenameProvider` `changes[uri]=` | `packages/langium/src/lsp/rename-provider.ts:89` | `uri` is `ref.sourceUri.toString()` produced by the framework from indexed documents; not raw client input, and target is a fresh `{}`. | | `generator-langium` npm install | `packages/generator-langium/src/index.ts:350-354` | `spawnSync('npm', ['install'], opts)` with array argv and no `shell:true`; project name is regex-validated. | | `langium-vscode` workspace `langium-config.json` | `packages/langium-vscode/src/language-server/config-handler.ts` | Untrusted JSON is read, but the only consumed field is `validation` assigned to `validator.options` and read back as `this.options.types || 'normal'` — a string mode flag with no further sink. | | `langium-cli` code-gen templates | `packages/langium-cli/**` | Inputs are the developer's own `.langium` grammar + `langium-config.json`, executed at build time by the developer; the developer is trusted per the threat model. | | `WorkspaceManager.traverseFolder` | `packages/langium/src/workspace/workspace-manager.ts:200-215` | Reads directory listings under workspace roots supplied by the trusted editor; no path is taken from file contents. | | `DefaultAstNodeLocator.getAstNode` segment lookup | `packages/langium/src/workspace/ast-node-locator.ts:60-75` | `(node as Record)[segment]` reads only; path strings originate from `getAstNodePath` (framework-generated) or serialized refs (trusted per above). No write, so no pollution. | | `partialRegExp` / `getTerminalParts` regex handling | `packages/langium/src/utils/regexp-utils.ts` | Regex sources come from grammar terminal definitions (developer-trusted), not from parsed source files. | --- **Verification verdict:** TRUE POSITIVE ### Verification details Negative PoCs all pass, confirming the exploit's preconditions are load-bearing. Completing the record with the systematic devil's advocate checklist, then the final verdict. # Verification report: HTML injection in `langium-sprotty` diagnostic hover popup — completed record </details> <details> <summary><strong>Verdict: TRUE POSITIVE (severity Low, as reported)</strong></summary> Everything from my earlier analysis stands; this message adds the negative PoCs and the systematic devil's advocate review that were missing, and restates the full result. **Project status:** no EOL/deprecation/moved notices in any README or CONTRIBUTING doc (there is no SECURITY.md). Langium is actively maintained — cloned HEAD `89d49680` is the v4.4.0 release commit — so the affected range extends beyond the report's claim to **langium-sprotty 3.0.0 – 4.4.0 inclusive, plus main**. </details> <details> <summary><strong>Positive PoC (executed, published packages)</strong></summary> - **Server:** drove the real `addHoverPopupHandler` from npm `langium-sprotty@4.4.0`; the dispatched `SetPopupModelAction.newRoot.children[0].code` contained `<img src="x" onerror="alert(document.domain)"/>` verbatim inside the popup HTML. - **Client:** fed that exact string through the real `sprotty@1.4.0` `virtualize()` + snabbdom `attributesModule` (what `PreRenderedView.render` does) under jsdom. No parser error; an `<img>` element was created with the `onerror` attribute, it compiled to a **live handler**, and the handler **executed** when the error event fired. - `Diagnostic.getMessageString` (the one code drift at HEAD vs the report's `diagnostic.message`) was proven to return a plain-string message unchanged. </details> <details> <summary><strong>Negative PoCs (executed — exploit preconditions are real)</strong></summary> - **(A) Escaped message** (what the proposed one-line fix produces, and what any `<`-free token yields): popup renders, but **no `<img>` element is created and no code runs** — the entities stay inert text. This validates the fix and proves a literal `<` in the diagnostic message is required. - **(B) Non-well-formed-XML payload** (unclosed `<img>` — valid HTML, invalid XML): Sprotty's `DOMParser.parseFromString(code, "application/xml")` rejects the **entire popup** (`parsererror`), no element is created, nothing runs. The payload must keep the whole popup well-formed XML (trivially met by self-closing, but a genuine constraint). - **(C) Default terminal constraint:** Langium's conventional `terminal ID: /\^?[_a-zA-Z][\w_]*/` (confirmed at `packages/langium/src/grammar/langium-grammar.langium:232`) cannot match `<img…` — with default `[Type:ID]` cross-references the built-in linker message **cannot** carry the payload. The attack needs a downstream grammar with a permissive terminal (e.g. `[Type:STRING]`) or a custom validator that interpolates string-literal source text. </details> <details> <summary><strong>Devil's advocate — 13-item checklist</strong></summary> 1. **Full validation chain:** traced source→sink across all three files; the only transforms are `getMessageString` (identity for strings) and `expandToString` (whitespace only, read in full). No escaping exists anywhere in `langium-sprotty/src` (grep confirmed). 1a. **Conditional reachability:** the handler requires `element.type === 'marker'` with an `issues` array — exactly what `DefaultDiagnosticMarkerProvider` produces; no condition blocks the flow. 2. **Defensive patterns:** none present; `convertSeverity` constrains only the `severity` interpolation (fixed enum, not independently exploitable), not `message`. 3. **Confirmed data path:** proven by executing the real code, not inferred. 4. **Data source trust:** `document.diagnostics` messages embed literal source-file text (`$refText`, linker.ts:405/225/248) — attacker-controlled when the victim opens an attacker-authored file; LSP spec says `Diagnostic.message` is plain text, so downstream authors have no reason to pre-escape. 5. **Bounds logic:** N/A (injection, not memory). 6. **TOCTOU:** N/A. 7. **API contracts:** checked both sides — `expandToString` documents no encoding; Sprotty's `buildVNodeData` deliberately copies all attributes except `style`/`class`, and snabbdom's `attributesModule` uses `setAttribute`, which makes `on*` attributes live. The XML-parsing contract is a real constraint, handled (negative PoC B). 8. **Internal vs external input:** the marker `id`/`severity` are framework-internal; only `message` carries external text — correctly the sole claimed vector. 9. **Pattern vs analysis:** verdict rests on executed end-to-end PoCs, not pattern-matching. 10. **Concurrency:** N/A. 11. **Real impact:** arbitrary JavaScript execution in the Sprotty client — a `sprotty-vscode` webview (typically `enableScripts: true`) or the hosting page's origin. Real security impact, not operational. 12. **Primary vs defense-in-depth:** this escaping *is* the primary control — nothing downstream (Sprotty, snabbdom) sanitizes; both explicitly preserve attributes. VS Code workspace trust is an environmental mitigant for one delivery route, not a control in this code. 13. **Applied systematically:** all items worked through; the honest weakness is not exploitability of the code (proven) but the stack of downstream opt-ins — no caller of `addHoverPopupHandler` exists in-repo or was found publicly — which is exactly what caps severity at Low rather than refuting the finding. </details> <details> <summary><strong>Gate review</strong></summary> - **Process** — PASS: claim restated, data flow traced, exploitability proven, impact assessed, positive + negative PoCs executed, devil's advocate completed. - **Reachability** — PASS (conditional): sink reachable whenever a downstream consumer wires up the documented helper; unreachable in this repo's own examples (severity-relevant, not verdict-relevant). - **Real impact** — PASS: script execution in webview/page origin. - **PoC validation** — PASS: positive PoC executes attacker JS end-to-end through real published server and client code; negative PoCs show escaping, XML well-formedness, and the default `ID` terminal each independently block it. - **Math bounds** — N/A. - **Environment** — PASS with caveat: needs a scripts-enabled webview/browser host and, for the VS Code route, a trusted workspace; both are the normal deployment for Sprotty diagrams. </details> <details> <summary><strong>Classification</strong></summary> EXPOSURE: DEV-TIME The attacker must plant a malicious source file in a workspace a developer opens in a Langium-based tool whose language opted into Sprotty diagrams and `addHoverPopupHandler`; the payload runs in that developer's diagram webview/page only when they hover the diagnostic marker. SCOPE: PRODUCTION `langium-sprotty` is shipped npm library code, presented by its README as the integration package ("This package provides glue code for Langium and Sprotty… The counterpart of this integration is the sprotty-vscode package, which provides Sprotty diagrams embedded in VS Code webviews") — not a demo or dev-only tool. Worth reporting upstream: real missing-escape in first-party code, actively maintained project, one-line fix (entity-escape `issue.message` in `generateDiagnosticInfo`; also `.join()` → `.join('')`). The stacked opt-ins justify Low severity, not dismissal. </details> <details> <summary><strong>Steps to reproduce</strong></summary> Hypothetical downstream language `Foo` with grammar: **Proof of concept:** [poc-1.txt](/uploads/7f135871c856b82b6d356a0deae6b587/poc-1.txt) Attacker commits `evil.foo` to a repository the victim opens: **Proof of concept:** [poc-2.txt](/uploads/45f22cef8e54adb0bbb3ebbf40966c27/poc-2.txt) The reference does not resolve → linker emits a diagnostic on the `Link` node whose message embeds the payload verbatim → the diagram generator calls `addDiagnosticMarker(linkElement, linkAst, ctx)` → a `marker` child with that message is added → victim hovers the red marker in the diagram view → `addHoverPopupHandler`'s action handler builds the unescaped `PreRenderedElement` shown above → Sprotty client virtualises it → snabbdom sets `onerror` on a real `<img>` → browser fires the handler when the image fails to load. In a VS Code `sprotty-vscode` webview this runs inside the extension's webview origin (typically with `enableScripts: true`); in a browser-hosted Sprotty diagram it runs in the page origin. </details> <details> <summary><strong>Do you know any mitigations of the issue?</strong></summary> HTML-escape the interpolated text in `generateDiagnosticInfo`: **Suggested fix:** [fix.ts](/uploads/4222ab7f15ad0f488c3c364c0f03b062/fix.ts) (Also note `.join()` defaults to `,` as separator — `.join('')` is almost certainly what was intended; harmless cosmetically but worth fixing in the same patch.) <!-- l1-helper-dup: e7847db01782938bdc0fee4821232e584db5901cde645db94bf2d29806cf0c56 --> </details>