fix(security): validate URL scheme before rendering href to block javascript: XSS

[aaronjmars]

Summary

Both compile_report.mjs scripts (event-prospecting + company-research) render attacker-controlled URL fields — LinkedIn / X / GitHub / blog / podcast / image / company website — into <a href="…"> via escapeHtml only. escapeHtml handles &, <, >, " but does not validate the URL scheme, so javascript:fetch(…) (and data:, vbscript:, etc.) survive unchanged and produce a clickable XSS link in the rendered report.

Impact

If an investigator runs event-prospecting against an attacker-controlled conference page (the OSINT-style use case the skill is built for), the page can plant a malicious linkedInProfile / website / image field. The subagent stores the URL verbatim into people/<slug>.md frontmatter, compile_report.mjs renders it into an <a href="javascript:…"> pill, and one click on the LINKEDIN pill of the attacker's own card runs JS in the report origin — exfiltrating the full report DOM (every speaker + every company researched in the run, not just the attacker's own data) to attacker.com via fetch().

file:// origin caps cookie scope, but outbound fetch() still works, and the report is the cross-target leak surface (everything researched in the run is one DOM tree).

Location

7 sinks share the root cause:

• skills/event-prospecting/scripts/compile_report.mjs:397 — link pills (linkedin/x/github/blog/podcast)
• skills/event-prospecting/scripts/compile_report.mjs:411 — per-card photo <img src>
• skills/event-prospecting/scripts/compile_report.mjs:582 — grouped-by-company website link
• skills/event-prospecting/scripts/compile_report.mjs:673 — companies-table website cell
• skills/event-prospecting/scripts/compile_report.mjs:680 — attendee LinkedIn cell
• skills/event-prospecting/scripts/compile_report.mjs:824 — per-company detail page website
• skills/company-research/scripts/compile_report.mjs:218 — companies-table website cell
• skills/company-research/scripts/compile_report.mjs:303 — per-company detail page website

(Line numbers post-patch — the originals were a few lines lower in each block.)

Fix

A small safeUrl(u) helper in each file. Allows http://, https://, mailto:, and protocol-relative //; rejects anything that parses as a URL with any other scheme by anchoring against [a-z][a-z0-9+.-]*:. Plain strings without a scheme pass through unchanged so relative paths still render. The helper is applied at every URL-bearing href / src sink before escapeHtml, and target="_blank" links pick up rel="noopener" consistently.

The safeUrl regex is intentionally allow-list-then-reject rather than a single regex — easier to extend (e.g. add tel: if needed) and the early-exit on plain strings keeps callers simple.

function safeUrl(u) {
  if (!u || typeof u !== 'string') return null;
  const trimmed = u.trim();
  if (/^(\/\/|https?:\/\/|mailto:)/i.test(trimmed)) return trimmed;
  if (/^[a-z][a-z0-9+.-]*:/i.test(trimmed)) return null;
  return trimmed;
}

+43 / -13 across the two files; no new dependencies, no behavior change for legitimate http(s) links.

Detected by

Aeon — manual review of the report-template URL sinks. Severity: medium (CWE-79). Picked up that escapeHtml doesn't touch : so any <scheme>:<payload> ride-along survives the encode.

Scanners on this run: semgrep=ok (no findings on the patched files; the 3 raw-html-format warnings on lines 426/427/430 are false positives — the values are already escapeHtml-wrapped or escapeAttr-wrapped); trufflehog=ok (filesystem 246 chunks + git history 740 chunks, 0 verified secrets); osv-scanner=ok (35 transitive CVEs across skills/safe-browser/templates/.../package-lock.json, skills/autobrowse/package-lock.json, skills/cookie-sync/package-lock.json — out of scope for this PR; happy to file a separate dep-bump PR if useful).

Verification

• node --check skills/event-prospecting/scripts/compile_report.mjs — clean.
• node --check skills/company-research/scripts/compile_report.mjs — clean.
• Spot-checked safeUrl against the obvious cases: https://example.com → passes through, javascript:alert(1) → null, data:text/html,<script> → null, vbscript:msgbox(1) → null, //cdn.example.com/x.js → passes through, mailto:hi@example.com → passes through, relative/path.html → passes through, "" / null / undefined → null.
• No test suite present in the repo for the report-render path, so verification is static.

Disclosure note

The repo doesn't have a SECURITY.md and PVR is off, so under our fix-PR-first policy a public fix PR is the right channel — diff is the disclosure but the fix lands at the same time. Happy to convert to a private advisory if maintainers prefer.

---

Filed by Aeon.

---

Note

Medium Risk
Touches HTML generation for multiple attacker-controlled link/image fields; low complexity but could inadvertently drop or alter legitimate non-http(s)/mailto URLs in generated reports.

Overview
Adds a safeUrl() allowlist-based URL sanitizer to both company-research and event-prospecting report compilers, stripping control characters and rejecting non-http(s)/mailto schemes to prevent javascript:-style XSS in generated HTML.

Applies safeUrl() to all rendered href/src sinks (company websites, social link pills, attendee LinkedIn links, and person images) and consistently adds rel="noopener" on target="_blank" links.

^{Reviewed by Cursor Bugbot for commit 39ac3ed. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 39b17fe. Configure here.}