You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@tremor021 thanks for your additional contributions! I get the changes in the install script but could you explain the backup/restore part in the update function? From what i tested, it is not really necessary to backup the data before an update, since the .env and db files are not being overwritten by the fetch_and_deploy_gh_release function because i did not set CLEAN_INSTALL=1.
Did you encounter problems during update (using the original update function) or is the backup stuff more like a good practice? 😄
Its more of a good practice, as you can't know what kind of change they will make to the tarball in the future.
CLEAN_INSTALL ensures that the directory is emptied out before deploying a new tarball. For this reason i'm backing up all relevant directories and restoring after fresh deployment.
@tremor021 I have a couple more improvements that could be made. Let me know what you think of them and whether you want to implement them yourself or if i should create a PR:
Update kutt.json to use port 443 instead of 3000
Add note to kutt.json that caddy is installed for ssl termination since it is required for Kutt
Use :443 instead of $LOCAL_IP to make it work when the IP of the LXC changes
Ask the user during install if they want to use their own reverse proxy for ssl termination or let the script install caddy for that
If chosen to use their own reverse proxy, maybe ask for the hostname to directly set it in the .env file
@tremor021 I created a PR for the changes. But i could not use :443 in the Caddyfile since then Caddy would not create/serve an SSL certificate. I think the reason being that there is no subject caddy could issue a cert for.
@tremor021 and @CrazyWolf13 From my side everything seems to be working as it's supposed to. Do you guys want to test this or what is the process to get this into the main repository?
The kutt script is ready for testing: bash -c "$(curl -fsSL https://github.com/community-scripts/ProxmoxVED/raw/main/ct/kutt.sh)"
Kutt needs so be served with an SSL certificate for its login to work. During install, you will be prompted to choose if you want to have Caddy installed for SSL termination or if you want to use your own reverse proxy (in that case point your reverse porxy to port 3000).
Note: This is not in the official repo yet—it's just a dev version! After merging into ProxmoxVE, it will need to be recreated.
@tomfrenzel When testing the script I noticed the following issue:
It seems to copy the protocol twice to the clipboard, is this known?
Did you experience this too when using caddy and a selfsigned cert, internal?
I'm seeing that as well. Although in my current setup, i use my own reverse proxy and not caddy inside the same LXC.
When selecting Show advanced options and choosing the local IP of the LXC instead of my configured domain, i also get the double https://
I think the issue is that the DEFAULT_DOMAIN in .env always contains https://.
I tried removing it and now the URL copied to the clipboard is correct. I also tested it with a custom domain configured and it worked as well.
I'll create a PR later, to remove the https:// prefixes
@CrazyWolf13 I have not taken a look into that yet as my focus was getting the app running. However i can try to check tomorrow if those vulnerabilities are actually exploitable of if they are false positives 😉
@CrazyWolf13 I checked the vulnerabilities and none are really exploitable.
Most come from packages that are not referenced directly but ship as a dependencies from other packages. The vulnerable methods seem not to get used by the Kutt code with the exception of express.js. It uses the vulnerable method call (express.urlencoded({ extended: true })). The attack vector would be to send a payload congaing so many nested objects that the memory runs full. But to create such a big payload, it would have be multiple MB big and the default payload limit of express.js is 100kb. So since the max payload size is not overwritten to something bigger than that, the vulnerability is not really exploitable 😄
Activity
tomfrenzel commentedon Jan 3, 2026
@tremor021 thanks for your additional contributions! I get the changes in the install script but could you explain the backup/restore part in the update function? From what i tested, it is not really necessary to backup the data before an update, since the
.envanddbfiles are not being overwritten by thefetch_and_deploy_gh_releasefunction because i did not setCLEAN_INSTALL=1.Did you encounter problems during update (using the original update function) or is the backup stuff more like a good practice? 😄
tremor021 commentedon Jan 3, 2026
Its more of a good practice, as you can't know what kind of change they will make to the tarball in the future.
CLEAN_INSTALL ensures that the directory is emptied out before deploying a new tarball. For this reason i'm backing up all relevant directories and restoring after fresh deployment.
tomfrenzel commentedon Jan 3, 2026
True, with that possibility it makes sense to backup and restore the data 👍🏼
tomfrenzel commentedon Jan 3, 2026
@tremor021 I have a couple more improvements that could be made. Let me know what you think of them and whether you want to implement them yourself or if i should create a PR:
:443instead of$LOCAL_IPto make it work when the IP of the LXC changes.envfiletremor021 commentedon Jan 3, 2026
Sounds good to me
tomfrenzel commentedon Jan 4, 2026
@tremor021 I created a PR for the changes. But i could not use
:443in theCaddyfilesince then Caddy would not create/serve an SSL certificate. I think the reason being that there is no subject caddy could issue a cert for.tomfrenzel commentedon Jan 7, 2026
@tremor021 and @CrazyWolf13 From my side everything seems to be working as it's supposed to. Do you guys want to test this or what is the process to get this into the main repository?
github-actions commentedon Jan 9, 2026
The kutt script is ready for testing:
bash -c "$(curl -fsSL https://github.com/community-scripts/ProxmoxVED/raw/main/ct/kutt.sh)"Kutt needs so be served with an SSL certificate for its login to work. During install, you will be prompted to choose if you want to have Caddy installed for SSL termination or if you want to use your own reverse proxy (in that case point your reverse porxy to port 3000).
Note: This is not in the official repo yet—it's just a dev version! After merging into ProxmoxVE, it will need to be recreated.
CrazyWolf13 commentedon Jan 9, 2026
@tomfrenzel When testing the script I noticed the following issue:
It seems to copy the protocol twice to the clipboard, is this known?
Did you experience this too when using caddy and a selfsigned cert, internal?
tomfrenzel commentedon Jan 9, 2026
I'm seeing that as well. Although in my current setup, i use my own reverse proxy and not caddy inside the same LXC.
When selecting Show advanced options and choosing the local IP of the LXC instead of my configured domain, i also get the double
https://I'll see if i can figure out the cause 😄
tomfrenzel commentedon Jan 9, 2026
I think the issue is that the
DEFAULT_DOMAINin.envalways containshttps://.I tried removing it and now the URL copied to the clipboard is correct. I also tested it with a custom domain configured and it worked as well.
I'll create a PR later, to remove the
https://prefixesCrazyWolf13 commentedon Jan 9, 2026
@tomfrenzel for me everything looks good, install and update seem to work fine, however something catched my eyes:
There seem to be quite some vulnerabilites:
Do you have any idea if they are critical to this project?
tomfrenzel commentedon Jan 9, 2026
@CrazyWolf13 I have not taken a look into that yet as my focus was getting the app running. However i can try to check tomorrow if those vulnerabilities are actually exploitable of if they are false positives 😉
tomfrenzel commentedon Jan 10, 2026
@CrazyWolf13 I checked the vulnerabilities and none are really exploitable.
Most come from packages that are not referenced directly but ship as a dependencies from other packages. The vulnerable methods seem not to get used by the Kutt code with the exception of
express.js. It uses the vulnerable method call (express.urlencoded({ extended: true })). The attack vector would be to send a payload congaing so many nested objects that the memory runs full. But to create such a big payload, it would have be multiple MB big and the default payload limit ofexpress.jsis 100kb. So since the max payload size is not overwritten to something bigger than that, the vulnerability is not really exploitable 😄CrazyWolf13 commentedon Jan 10, 2026
Thanks for the detailed checkup!
I think then we are "fine" to accept this and leave the fix to the upstream app maintainers
github-actions commentedon Jan 14, 2026
A PR has been created for kutt: community-scripts/ProxmoxVE#10812
michelroegl-brunner commentedon Jan 14, 2026
Merged with #10812 in ProxmoxVE
github-actions commentedon Jan 14, 2026
Files deleted with PR #1284