User accounts can be hijacked, credentials could be stolen, sensitive data could be exfiltrated, and lastly, access to your client computers can be obtained.

Very generic impact description.

Please further elaborate on how this is possible with 1.8.0 (your report specifies the vulnerability to apply to all versions up to and including 1.8.0).

In order to exploit this, a target user would have to be identified for attack, then talked into entering malicious code into the user name field, and THEN with 1.8.0 some JS would be executed, but no credentials could be stolen.

I find it highly unlikely to find a publicly accessible instance (which is highly discouraged by the project), successfully identify an admin user of this instance, contact them, then be able to socially engineer said instance admin to create a new user, with - to the targeted user - complete garbage as the username. And if - on the other hand - an attacker has already access to the instance, they need Admin rights to do this and it would also not make a whole bunch of sense to do it given they already have Admin rights then in the first place.

I went through the CVSS 3.1 calculator and based on that classify this as CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N for OctoPrint 1.8.0+. That means "Low" severity with a score of 2.5.

hey sorry for the multiple report, i agree that the impact was low, so how about the patch and other procedures?

@admin can you assign a CVE for this ?

If the maintainer is happy to assign a CVE, we can proceed with this :)

@maintainer hey can you assign a CVE for this please..🙏😇

Considering that @researcher tried to game the system here with a secondary issue of basically the same problem (since marked as Spam after asking @admin how to proceed) and (on the other report even repeated) re-upgrading of the severity after I l downgraded it, and the extremely low likelihood of this issue seeing any kind of active exploitation AND with 1.8.0 said exploitation also being fruitless even if it succeeded, I frankly don't see why I should reward this behaviour I saw with a CVE.

Reports like this put a LOT of stress on maintainers. I want to keep my users secure, security fixes have the utmost priority for me, but when a gamified platform like this one comes into the mix, I get very careful that this willingness of mine isn't abused by people trying to play the platform by overstating the severity, misclassification or panicky impact analyses, because that only invites more and more to do the same and ramps up the stress factor even more (and I'm already running above capacity).

Hey the severity issue was just an accident because we both were editing that at same time.. I hope you will understand that.. 🙄.. Eww whatever just leave it...

closing this issue🚫

@Gina - I've shared your feedback and we are currently working on mechanisms to ensure that you have better control over your experience on the platform. As Pavlos mentioned, you will be able to control the reputation threshold of researchers that you receive reports from 👍

If you have any further ideas or thoughts on how we can make the experience better, feel free to create a feature request on our public board:

https://github.com/418sec/huntr/issues/new