CVE-2026-71445

The CVSS 8.2 score for this XSS in AIL Framework's /tag/add_tags endpoint likely overstates the actual risk, but you need to verify two critical conditions before deprioritizing. First, determine whether /tag/add_tags requires authentication. The CVE narrative mentions a "crafted link to authenticated user," which suggests the endpoint is behind a login wall. If an unauthenticated attacker cannot reach the endpoint at all, this shifts from a direct reflected XSS to an attack requiring victim interaction—significantly reducing the exploitability. Check your AIL deployment's authentication configuration on this specific route. Second, and more importantly, verify the data flow into str(res[0]). This is an error handler, not normal output code. The CVE uses conditional language ("if attacker-controlled input was included") because the original researcher could not confirm what actually populates res[0] when the error triggers. If res[0] contains only internal errors (database constraint violations, file I/O failures, downstream service timeouts), an attacker cannot inject payloads—they would need to first exploit another vulnerability to place controlled content into that error path. However, if res[0] captures validation failures on user-supplied tag names, then crafted tag parameters like <img src=x onerror=alert(1)> injected into the request will reflect unsanitized in the error response—making this a direct reflected XSS. The error handler bypasses main sanitization routines that protect normal tag display and storage. Auditing the happy-path code for escaping is insufficient. You must test the error response specifically: send a malformed or malicious tag to /tag/add_tags and inspect the error message returned. If the payload executes, the CVSS 8.2 is accurate. If the error contains only generic failure messages with no user input reflection, the actual severity is much lower and you can deprioritize.

Reviewed through automated stages and approved by a human before publication.