security(core): escape "<" in the res.expose script island (stored XSS via app name)

[ar2rsawseen]

Summary

The dashboard serializes the exposed countlyGlobal object into an inline script block in dashboard.html:

<script><%- javascript %></script>

frontend/express/libs/express-expose.js produced that JavaScript and tried to prevent a breakout by replacing the exact sequence </script>. But the HTML tokenizer also ends a <script> element at </script >, </script/> and other whitespace/slash spellings, which the exact-match replace missed. An application name containing such a spelling therefore broke out of the script block.

Because a global admin's dashboard lists every app, an app admin of a single app could set their own app's name to a </script >-based payload; when any global admin loaded the dashboard, the payload executed in the global admin's own session. From there it can read the session token / api_key and drive global-admin-only endpoints, i.e. escalate a single app-admin account to full instance control.

Requires an authenticated app-admin account, so this is Medium under SECURITY.md.

Root cause

• The primitive branch escaped only the literal </script> (and <!--), not the other end-tag spellings the parser accepts.
• escape_js_string (used for object keys) escaped quotes, backticks and control chars but never <, so a hostile key could break out even with the exact spelling.

Fix

Escape every < as < in both serialization paths — string values and object keys. < parses back to <, so every value read out of the exposed object is unchanged; this is the value-preserving JS-string escaping direction of the previous fix (aa33b31, which removed the old value-changing escape_html), not a return to HTML-entity escaping.

Separately, the active-app name is now rendered with .text() instead of .html() in countly.template.js (line 2406) — an independent DOM sink for the same value, and the only .html() sink fed by an app name anywhere in the frontend or plugins (the others render trusted templates, clear content, decode numeric metrics, or i18n strings).

Why this does not break the dashboard

The escaping that broke dashboards historically was escape_html (<→<), which changed the runtime values. < does not: it is exactly < after the JS parser reads it. Verified by an eval round-trip:

• Security: no raw < survives for </script>, </script >, </script/>, </script\t>, </script\n>, <img …>, <!--, <script> — in values and keys.
• Safety: evaluating the serialized output reproduces the input object byte-for-byte, and matches the previous serializer's output exactly — no dashboard-visible change.

Notes

• Structurally moving the island to a non-executed <script type="application/json"> data block would retire this class entirely, but is intentionally out of scope here (larger change to a UI being phased out).
• Reported through the security bug bounty program (received 2026-08-17).

🤖 Generated with Claude Code