This stored XSS in AVideo's user registration phone field exemplifies a privilege boundary failure, not merely a sanitization oversight. The attack chain is straightforward but dangerous: an unauthenticated attacker injects malicious JavaScript through the phone field at registration, and that payload executes when an administrator visits the user management panel. The phone field is the entry point; the admin session is the detonation point. This distinction matters because it reframes the vulnerability as a trust boundary failure rather than an input validation error — the attacker doesn't need admin credentials, only data that the admin's browser will willingly execute.
The technical root cause is straightforward: the developer used innerHTML to render the phone field when textContent would have been appropriate. Phone numbers contain no HTML markup and should never require innerHTML's parsing capabilities. Using innerHTML bypasses the browser's automatic escaping, and if the value isn't explicitly sanitized at render time, the result is stored XSS. This is a developer ergonomics failure — innerHTML is often chosen for convenience (clean child replacement, newline handling) without considering the sanitization obligation it creates. The phone field specifically likely fell below the developer's threat model threshold precisely because phone numbers feel semantically 'safe' compared to fields like bio or display name where HTML injection is expected.
The admin-triggered execution model is what elevates this from noise to high-severity. Stored XSS that only executes for the victim user is self-contained; stored XSS that fires when privileged users visit is a compromise pathway. This is functionally equivalent to a watering hole attack — the attacker plants malicious data and waits for a high-value target to consume it. Automated security scanning frequently misses this pattern because scans don't simulate admin workflow traversal.
Remediation requires more than patching the render path. First, verify that all user-supplied fields in the admin user management interface use textContent or equivalent safe rendering methods — the phone field is likely not isolated. Second, audit the registration flow for other fields that use innerHTML where textContent would suffice. Third, recognize this as a recurring vulnerability genotype: fields semantically classified as 'data not content' (phone numbers, URLs, timestamps) enter data models, inherit template rendering patterns without security review, and slip through threat modeling because they don't invite suspicion. The fix is not better developer training but architectural enforcement — output encoding should be consistent at the template layer so individual developer choices cannot bypass it. Finally, audit historical user records written during the exposure window; each unsanitized phone value in the database is an independent payload waiting for admin access.