XSS and Encoded Script Injection via HTML/JavaScript Payload

How the attack works

An attacker crafts input containing HTML/JavaScript attack patterns: inline <script> tags, javascript: URIs inside img/a tags, onerror/onload event handlers, external script sources, or data: URIs. To dodge simple keyword filters, the payload may be encoded, e.g. using String.fromCharCode or HTML entities to hide the word 'script' or 'javascript'. The attacker sends this as a normal prompt or message to the agent. If the agent renders the input back out (in a browser-based UI, a rendered markdown view, or a generated web page) without sanitising it, the injected script executes in that context.

Netzilo detection

Why it matters

If the payload executes, an attacker can run arbitrary JavaScript in the context of whoever views the agent's output — enabling session hijacking, credential theft, or further malicious redirects. This rule only flags the injection attempt itself, not confirmation that rendering or execution actually occurred.

What you can do

• →Sanitise or strip HTML/JavaScript from any user input before it is rendered, echoed, or displayed by the agent or downstream UI.
• →Render agent output as plain text or through a markdown renderer that escapes script tags and event handlers by default.
• →Apply a strict Content Security Policy on any web surface that displays agent-generated content.
• →Review flagged inputs manually — expect false positives from security training material, CTF write-ups, and legitimate discussions of HTML/JS attributes.

Known benign look-alikes

• Security education content discussing XSS techniques with sanitised examples
• CTF write-ups or penetration testing reports containing example payloads
• Web development discussions about HTML attributes in legitimate code context

References

• https://agentthreatrule.org/en/rules/ATR-2026-00497

Related threats