How can web server logs be leveraged to perform Cross-Site Scripting (XSSI?

GUI text browsers and standard text editors do not execute JavaScript, so opening log files in such tools displays the XSS payload as inert literal text without triggering script execution.

XSS payloads stored in log entries do not corrupt log formatting or prevent logs from being read; they remain fully legible and do not impair the availability or readability of the logging system.

When an attacker sends HTTP requests containing XSS payloads in fields that get logged - such as User-Agent headers or malformed URL parameters - the web server records the malicious string verbatim in its log files. If an administrator later views those logs through a web-based management interface, the browser parses the log content as HTML and executes the embedded script, potentially allowing the attacker to steal the admin's session cookie or perform privileged actions on their behalf. This technique is sometimes called log poisoning or second-order XSS via log injection.

Terminal-based log viewers render content as plain text without an HTML rendering engine, so XSS payloads cannot be interpreted as executable script or escape to the underlying shell from a command-line context.