NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
📦 npm
Not in CISA KEV

@grackle-ai/server: Unescaped Error String in renderPairingPage() HTML TemplateGHSA-7q9x-8g6p-3x75

GHSA-7q9x-8g6p-3x75 is a security vulnerability in @grackle-ai/server. A fix is available for @grackle-ai/server — see the affected versions and patch details below.

Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Mar 25, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

1other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
@grackle-ai/servernpm
466downloads / week

Description

Impact

The renderPairingPage() function embeds the error parameter directly into HTML without escaping:

const errorHtml = error ? `<p style="color:#e74c3c">${error}</p>` : "";

All current call sites pass hardcoded strings, so this is not exploitable today. However, the function is architecturally fragile — if a future code change passes user-controlled or dynamic content into the error parameter, it would create an XSS vulnerability.

The renderAuthorizePage() function in the same file correctly uses escapeHtml() for dynamic content, making this an inconsistency.

Affected code:

  • packages/server/src/index.ts:64-89 — renderPairingPage() with unescaped error interpolation
  • Compare: packages/server/src/index.ts:130 — renderAuthorizePage() correctly uses escapeHtml()

Patches

v0.70.1

Fix: Apply escapeHtml() to the error parameter:

const errorHtml = error ? `<p style="color:#e74c3c">${escapeHtml(error)}</p>` : "";

Workarounds

No workaround needed — all current callers pass hardcoded strings.

Resources

  • CWE-79: Improper Neutralization of Input During Web Page Generation
  • File: packages/server/src/index.ts

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npm@grackle-ai/serverall versions0.70.1npm install @grackle-ai/server@0.70.1

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @grackle-ai/server, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update @grackle-ai/server to 0.70.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7q9x-8g6p-3x75 is resolved across your whole dependency graph.

  3. Workarounds

    Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.

Frequently Asked Questions

### Impact The `renderPairingPage()` function embeds the `error` parameter directly into HTML without escaping: ```typescript const errorHtml = error ? `<p style="color:#e74c3c">${error}</p>` : ""; ``` All current call sites pass hardcoded strings, so this is **not exploitable today**. However, the function is architecturally fragile — if a future code change passes user-controlled or dynamic content into the error parameter, it would create an XSS vulnerability. The `renderAuthorizePage()` function in the same file correctly uses `escapeHtml()` for dynamic content, making this an inconsist
O3 Security · Impact-Aware SCA

Is GHSA-7q9x-8g6p-3x75 in your dependencies?

Find it across npm, including transitive dependencies.

Scan my dependencies How O3 SCA works
@grackle-ai/server: Unescaped Error String in…