Khoj Automation Stored XSS Payload Submission
This rule flags attempts to plant executable script code inside the task-instruction field of Khoj's automation feature, a known unpatched sink before version 1.15.0. It catches the moment the malicious markup is written, not whether it later executes in a victim's browser.
How the attack works
An automated process (an agent or script) sends an HTTP request to Khoj's /api/automation endpoint, placing script tags or event-handler markup (like <script> or <svg onload=...>) into the 'q' parameter used for task instructions. The rule traces this back through the process lineage to confirm the submitting session had genuine prior interaction with the same Khoj deployment, ruling out simple payload echoing. It also checks whether any external host referenced inside the payload (e.g. in a fetch() or image src call) has already been contacted by that same session, which strengthens suspicion of a live exfiltration attempt. The detection stops at the point of submission — it cannot see whether the script actually renders and runs when a victim later views the automation task.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 3f1c8a7e-6b24-4d9a-9c05-2e7d41b8af63
- Severity
- Medium
Why it matters
If the injected script does render and execute later, an attacker could steal session tokens or hijack a user's Khoj session; but this rule only proves malicious content was written to the vulnerable field, not that the compromise succeeded.
What you can do
- →Upgrade Khoj to version 1.15.0 or later, which sanitises the automation task-instruction field.
- →Review any flagged submissions for embedded external URLs in script contexts (fetch, Image src) as a sign of possible data exfiltration setup.
- →Treat alerts from known scanners or CI/pentest tools as expected noise, but verify the submitting process lineage before dismissing.
- →Add server-side output encoding on any user-supplied text rendered in the Khoj UI, independent of this specific endpoint.
Known benign look-alikes
- Security engineers or AppSec CI validating the 1.15.0 fix by firing canonical XSS payloads (<script>alert(1)</script>, <svg/onload=...>) at /api/automation. These are genuine matches; the rule reports rather than blocks precisely so that this work is never interrupted, and the kill chain names the submitting process lineage so a scanner/pentest host is obvious at triage.
- Automated web scanners (Burp, ZAP, nuclei) reachable through the agent proxy that spray payloads across every parameter of every endpoint.
- Legitimate automation tasks about front-end work — "review this snippet", "explain what <img onerror=...> does", "summarise the CSP report for this inline script" — where the user genuinely pastes markup into the task instruction field.
- Developer documentation, XSS cheat-sheets or security training content copied into a Khoj automation for summarisation.
- The Khoj UI re-submitting or PUT-updating an automation record that already contains the same markup, which would otherwise alert once per edit (suppressed by the one-hour per-payload dedupe in the rule store).