The search query is reflected back to the user, and injected in a form, so that the user can click on the "next page", etc. However, a specially crafted POST request can be used to reflect a DOM XSS, which can get automatically executed. 

The XSS requires the victim to have installed their RHCS certificate in the web browser. If that certificate has sufficient permissions, the XSS can be used to execute arbitrary code, including sending and signing arbitrary certificates.

Vulnerable page : /ca/ee/ca/listCerts (there might be other pages vulnerable to a similar attack)

```
document.write(
"<button NAME=begin onClick='doNext(this)' VALUE='|<<' width='72'>|<<</button>\n"+
"<button "+disabledUp+" NAME=up onClick='doNext(this)' VALUE='<' width='72'><</button>\n"+
[...]
"<INPUT TYPE=hidden NAME=skipNonValid VALUE='"+
(result.header.skipNonValid ? result.header.skipNonValid : "") + "'>\n"+
```

Several POST parameters, including `skipNonValid`, are being reflected back to the browser without having been sanitized by the server. An attacker can use that to inject JavaScript in the DOM.

Attack scenario :
A victim authenticated in RHCS web UI (the corresponding web browser has the required key/cert installed for client authentication), is tricked into clicking a button on an attacker-controlled website. The XSS can then be used to execute arbitrary JavaScript in the context of RHCS.