Hey Amy, Matt asked about our CVE response in RHEL 7. As far as I know, we have the following CVEs (grouped below by category). Third Party: - CVE-2016-10735 (bootstrap) XSS Moderate - CVE-2018-14040 (bootstrap) XSS Moderate - CVE-2018-14042 (bootstrap) XSS Moderate - CVE-2019-8331 (bootstrap) XSS Moderate - CVE-2019-11358 (js-jquery) XSS/DoS Moderate - CVE-2015-9251 (js-jquery) XSS Moderate These I'd recommend CLOSE->WONTFIX ; all are more work than they are worth in the last RHEL 7 release. It requires updating our dependencies and then re-testing the entire web UIs. They're not stored XSS and I'm not sure there's actually a viable way to exploit these in a RHCS environment. They're mostly about a way for a third-party site to inject content run in a trusted execution environment on a RHCS instance. That requires substantial theme customization (and/or changes to the server-side code to load elements from a third-party site) to enable and is well outside the scope of our support. Additionally, all operations are audited in our customer's deployments, so tracking down _who_ did this would be possible. I think it is safe to close these in RHEL 7. I'd like to fix all of these in RHEL 8 eventually, but again, that requires significant work and validation that we didn't break anything. All of these third-party dependencies (Bootstrap, jquery, ...) are severely out of date, and updating them is likely to break stuff. Doable, but not fun. :-) First Party - CVE-2019-10178 (TPS UI) XSS Moderate - CVE-2019-10179 (KRA UI) XSS Moderate - CVE-2019-10180 (TPS UI) XSS Low - CVE-2020-1696 (TPS UI) XSS Moderate - CVE-2020-1721 (KRA UI) XSS Low - CVE-2019-10146 (CA UI) XSS Low We don't have fixes for these in RHEL 8 yet. I think we should fix them in RHEL 8 and close them in RHEL 7. Testing these is significantly easier, and backporting would be easier. In all cases, I believe our QE team was the reporter. Someone familiar with this UI should probably fix them (Endi? Jack? Christina? I'm not sure). I think the changes should probably be server-side sanitation coupled with better front-end injection to prevent XSS. I can review, but I wouldn't know where to start to fix them. I wouldn't consider backporting them until someone (Amy? the customer?) is concerned and we've fixed them. However, my same argument about third-party ones stands here too: access is audited so it should be easy to find out who did this. My 2c., but I think they should be RHEL 8.3 candidates and not RHEL 7.9. If fixes are required/requested by the customer, we can always add them in a batch update. Thanks, - Alex