Summary Wings does not consider SQLite max parameter limit when processing activity log entries allowing for low privileged user to trigger a condition that floods the panel with activity records
Details After wings sends activity logs to the panel it deletes the processed activity entries from the wings SQLite database. However, it does not consider the max parameter limit of SQLite, 32766 as of SQLite 3.32.0.
If wings attempts to delete more than 32766 entries from the SQLite database in one query, it triggers an error (SQL logic error: too many SQL variables (1)) and does not remove any entries from the database. These entries are then indefinitely re-processed and resent to the panel each time the cron runs.
https://github.com/pterodactyl/wings/blob/9ffbcdcdb1163da823cf9959b9602df9f7dcb54a/internal/cron/activitycron.go#L81 https://github.com/pterodactyl/wings/blob/9ffbcdcdb1163da823cf9959b9602df9f7dcb54a/internal/cron/sftpcron.go#L86
PoC Any method that can create the required 32767+ activity entries can trigger this vulnerability. It can (and has) been triggered by normal (non-malicious) use. I attached a simple PoC I used while verifying this that uses sftp to quickly create many small files, thus creating activity entries in the SQLite database. https://ptero.co/mococesoca.go
Impact By successfully exploiting this vulnerability you can trigger a situation where wings will keep uploading the same activity data to the panel repeatedly (growing each time to include new activity) until the panels’ database server runs out of disk space.
Wings is Pterodactyl's server control plane. This vulnerability can be used to delete files and directories recursively on the host system. This vulnerability can be combined with GHSA-p8r3-83r8-jwj5 to overwrite files on the host system. In order to use this exploit, an attacker must have an existing "server" allocated and controlled by Wings. This vulnerability has been resolved in version v1.11.4 of Wings, and has been back-ported to the 1.7 release series in v1.7.4. Anyone running v1.11.x should upgrade to v1.11.4 and anyone running v1.7.x should upgrade to v1.7.4. There are no known workarounds for this issue.