Thanks to Digilol for the pentest. You can read the full report here: https://www.digilol.net/pentests/kyun-api-web.pdf.
Critical severity
Using a regular user account, one could execute arbitrary commands as root(!) on the node (physical server) their VM was on, by injecting the command in the "url" parameter while performing a cloud-init (quick) install.
This was brought to my attention during the pentest and solved immediately with a quick workaround.
Shortly after, the entire API -> node communication system was reworked and the Kyun API backend no longer has any kind of SSH access to the nodes, so any similar RCE exploit should not be possible anymore.
High severity
When logging out via the user panel, the actual user session token was not being immediately revoked by the backend, instead it was only removed from the browser's localStorage, so any attacker that managed to grab the session token would continue to have access to the user account until the token expired (7 days from login). This is now fixed.
Medium severity
It's possible to check whether a username or email has a Kyun account associated with it by calling the /user/login API method and checking the returned error message.
The suggested fix is to return the same error message in roughly the same amount of time whether or not the account exists, but it would be trivial to exploit the /user/register method instead.
Other suggested methods of fixing it are stricter rate limits per IP, which would not work with Tor, or a CAPTCHA system, which was actually implemented back when Kyun first started but I removed it because I feel a good, bot-resistant CAPTCHA disrupts human user experience too much.
To fix this, I will be implementing an "account number" system, similar to what Mullvad does. Instead of logging in using the email or username, login will be done using a long random string generated on account creation.