Take our word for none of it.

The finding came back Not Fixed because while the reported payload was blocked, the underlying vulnerability still reproduces through a different attack vector that the partial fix leaves open.

Here's what happened: the target's fix encodes angle brackets and ampersands to entities, which blocks the original reported payload (<script>alert(1)</script>). But that encoding only address one reflection context. The actual HTML reflects the input inside an attribute value, and the fix left double quotes unencoded.

An attacker can break out of that attribute using a raw quote character, then inject an event handler like " autofocus onfocus=alert(document.domain) x=". That handler fires on page load in the real browser. The finding's evidence captured the JavaScript firing three times out of three in the retest, proving the XSS still executes, just by a route the reporter's original steps didn't follow.

The distinction matters because it shows the developer stopped at blocking one technique without fixing the underlying flaw. Reflected XSS prevention requires encoding all special characters for the context they land in, or using a framework that does it. Encoding only some characters (angle brackets, ampersands) while leaving quotes raw leaves the attribute-injection vector open. That is why the retest landed on Not Fixed rather than Fixed, even though the specific payload from the original report no longer works.

You sent the payload " autofocus onfocus=alert(document.domain) x=" Network Request #82, and it landed raw and unencoded inside the HTML attribute value of the search input field.

The response body shows where it broke through:

Here's what happened: the target encodes angle brackets and ampersands (which blocks <script> payloads), but the double-quote character passed through unencoded. That quote sits inside an attribute context — the value="" attribute of the input. Your payload starts with a double quote, which closes that attribute, then injects autofocus onfocus=alert(document.domain) as raw attributes on the same tag, and x="" closes the syntax. The onfocus event handler fires on page load, executing the JavaScript three times in the retest.

The fix addressed the tag-injection vector but missed the attribute-escape vector entirely, because the developer encoded for one reflection context without accounting for where that reflection actually lands in the HTML structure.

The fix held against two techniques, but the third one broke through.

Alternative tag names Network Request #66: You tried <svg onload=alert(1)>, and the response encoded the angle brackets to entities, rendering it as <svg onload=alert(1)> inside the attribute value. The fix blocked this vector entirely.

Encoding/parser differential Network Request #75: You tried double URL-encoded %253Cscript%253Ealert(1)%253C%252Fscript%253E, but the response still encoded the angle brackets to entities: <script>alert(1)</script>. The fix held against the normalization bypass as well.

Context escape — this one succeeded. The payload " autofocus onfocus=alert(document.domain) x=" passed through the response unencoded in the attribute value, because the fix did not encode double quotes. That raw quote character breaks out of the attribute context and admits the event handler, which fired in the real browser.

So the fix's encoding strategy effectively blocked tag-injection and encoding-bypass techniques, but it was incomplete, because it left the attribute-escape vector open by not encoding quotes.

Based on the evidence captured in this retest, there is no indication that the fix introduced regressions elsewhere in the application.

The verdict reasoning makes no mention of functional side effects or broken functionality, focusing entirely on the security implications of the encoding strategy. The observe stage captured full 200 responses with complete page content, showing the search interface remained functional Network Request #37, and the search input continued to accept and reflect user input normally.

The fix itself is selective, encoding only angle brackets and ampersands to entities, while leaving other characters (like double quotes) unencoded. A surgical character encoding strategy like this is unlikely to break legitimate search functionality or page rendering, because HTML search inputs typically do not rely on angle brackets or ampersands in normal user queries.

That said, the retest only verified the security angle and the live target's responses, not an exhaustive functional test suite. If your application has edge cases where legitimate users search for terms containing < or > or & characters, those searches would now reflect with entities instead of raw characters, which might affect display or matching logic if the front-end or results handler does not expect encoded text. The evidence here does not show whether such edge cases were tested or whether any functional impact assessment was performed beyond the security retest's scope.