Hey all, just wanted to get a consensus. I found a reflected dom-based XSS in a popular web application that developers use for color schemes/branding/ect. I emailed the founder/maintainer of the site he actually replied he was already aware of the vulnerability, but will not be fixing it. I typically do a little blog post about these things and add them to a bug trophy list. Does the community think this should be disclosed if the vendor is refusing to fix or just let it be?
2 Likes
You can publish the vulnerability so that consumers of the software can make a decision to use it or not. But try to do the right thing below, or send them a copy of it:
https://cve.mitre.org/cve/researcher_reservation_guidelines
I follow these guidelines generally, particularly this step:
4. If an advisory will not be published by the vendor or an established response team (e.g., CERT/CC), you may choose to announce the vulnerability to a public forum that allows others to validate the claims. Currently, those forums include the Bugtraq and Full-Disclosure mailing lists, and sites such as exploit-db and Packet Storm.
When possible, do not announce a vulnerability until the vendor has provided a patch. This could take between one day and six months, depending on the vendor and the nature of the problem. If you believe that the issue is urgent and the vendor is not responding quickly enough, try using a coordinator as described in #4. Also, you should avoid releasing precise details of the vulnerability until system administrators have time to apply the patch.
3 Likes
The whole point of giving a vendor a private disclosure is to enable them to respond responsibly and thoughtfully, including the technical and communications parts of response. Technically, they need to design, code, and test the fix. They need to craft communications to their customers and get them out. These are all hard to do when angry customers are calling.
You’ve given them a chance to fix it, now, as sickcodes says, you should release the vuln in a way that minimizes harm, but the PoC for an XSS is usually pretty easy to repurpose, and that’s beyond your control.
3 Likes
I’m going to have to agree with you and sickcodes.
2 Likes
Thanks for checking in! The developer stated they did not intend to fix the issue. I emailed them a few times with mitigation recommendations, stated I would rather wait to publish until a fix was live, waited 2 months, then ultimately the developer stopped responding and I published my research here, Tyler Butler | Colorhunt.co Reflective Cross-Site Scripting (XSS) via Pallet Type
2 Likes
Confirmed the proofs, well done and excellent research.
1 Like
blog link changed if anyone is interested, Tyler Butler | Colorhunt.co Reflective Cross-Site Scripting (XSS) via Pallet Type
2 Likes
Awesome thanks for taking a look!