GHSA-qq9g-96v4-m3cj
MEDIUMCross-Site Scripting (XSS) via Select Schema Option Value Injection in @pdfme/schemas
Blast Radius
@pdfme/schemasReal-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 Select schema plugin in @pdfme/schemas constructs HTML from template-defined option values using unsanitized string interpolation and sets it via innerHTML, enabling arbitrary JavaScript execution.
Details
In packages/schemas/src/select/index.ts, lines 159-164, the Select schema's ui renderer builds <option> elements by directly interpolating option values from the template into an HTML string:
const options = Array.isArray(schema.options) ? schema.options : [];
selectElement.innerHTML = options
.map(
(option) =>
`<option value="${option}" ${option === value ? 'selected' : ''}>${option}</option>`,
)
.join('');
The option values come from schema.options, which is an array of strings defined in the template JSON. These values are interpolated directly into the HTML string without any escaping of <, >, ", &, or other HTML-special characters. An option value containing "> breaks out of the value attribute and allows injection of arbitrary HTML elements and event handlers.
Proof of Concept
Loading the following template into a pdfme Form or Designer component triggers JavaScript execution:
{
"basePdf": { "width": 210, "height": 297, "padding": [20, 20, 20, 20] },
"schemas": [[
{
"name": "malicious_select",
"type": "select",
"content": "Normal",
"options": [
"Normal",
"\"></option><img src=x onerror=\"alert(document.domain)\">"
],
"position": { "x": 20, "y": 20 },
"width": 80,
"height": 10
}
]]
}
The injected <img onerror> element executes JavaScript because it is parsed as HTML when assigned to selectElement.innerHTML.
Attack Vectors
The options array is defined in the template (not by form-filling end users). The attack requires a malicious template to be loaded, which can happen via:
- File upload (e.g., "Load Template" functionality in applications)
- Shared/imported templates in multi-tenant applications
- Templates stored in databases without content sanitization
- The
updateTemplate()API being called with untrusted data
This vulnerability is triggered in Form mode (for non-readOnly select fields) and Designer mode when the select element is rendered.
Impact
An attacker who can supply a malicious template can execute arbitrary JavaScript in the browser of any user who views or interacts with the template. This enables:
- Session hijacking via cookie/token theft
- Keylogging of form input data
- Phishing and page modification
- Data exfiltration
Suggested Fix
Use DOM APIs to create option elements safely instead of string interpolation:
options.forEach((option) => {
const optionEl = document.createElement('option');
optionEl.value = option;
optionEl.textContent = option;
if (option === value) optionEl.selected = true;
selectElement.appendChild(optionEl);
});
Alternatively, HTML-encode option values before interpolation:
const escape = (s) => s.replace(/&/g, '&').replace(/"/g, '"').replace(/</g, '<').replace(/>/g, '>');
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @pdfme/schemas | all versions | 5.5.9 |
Detection & mitigation playbook
Open-source dependencyDetect
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.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qq9g-96v4-m3cj 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-qq9g-96v4-m3cj 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-qq9g-96v4-m3cj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-qq9g-96v4-m3cj in your dependencies?
O3 detects GHSA-qq9g-96v4-m3cj across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.