GHSA-g66v-54v9-52pr: Vikunja has SSRF via Todoist/Trello Migration File Attachment URLs that Allows Reading Internal Network Resources
SummaryThe migration helper functions `DownloadFile` and `DownloadFileWithHeaders` in `pkg/modules/migration/helpers.go` make arbitrary HTTP GET requests without any SSRF protection. When a user triggers a Todoist or Trello migration, file attachment URLs from the third-party API response are passed directly to these functions, allowing an attacker to force the Vikunja server to fetch internal network resources and return the response as a downloadable task attachment.DetailsThe vulnerability exists because the migration HTTP client uses a plain `http.Client{}` with no URL validation, no private IP blocklist, no redirect restrictions, and no response size limit.**Vulnerable code** in `pkg/modules/migration/helpers.go:38-59`:**Call site in Todoist migration** (`pkg/modules/migration/todoist/todoist.go:433-435`):The `FileURL` is deserialized directly from the Todoist Sync API response (`json:"file_url"` tag at line 125) with no validation.**Call sites in Trello migration** (`pkg/modules/migration/trello/trello.go`):Line 263: `migration.DownloadFile(board.Prefs.BackgroundImage)` — board backgroundLine 345: `migration.DownloadFileWithHeaders(attachment.URL, ...)` — card attachmentsLine 381: `migration.DownloadFile(cover.URL)` — card cover imagesNotably, the webhooks module in the same codebase was recently patched (commit `8d9bc3e`) to add SSRF protection using the `daenney/ssrf` library, but this protection was **not applied** to the migration module — making this an incomplete fix.**Attack flow:**Attacker creates a Todoist accountUsing the Todoist Sync API, attacker creates a note with `file_attachment.file_url` set to an internal URL (e.g., `http://169.254.169.254/latest/meta-data/iam/security-credentials/`)Attacker authenticates to the target Vikunja instance and initiates a Todoist migrationVikunja's server fetches the internal URL and stores the response body as a task attachmentAttacker downloads the attachment through the normal Vikunja API, reading the internal resource contentsPoC**Prerequisites:**Vikunja instance with Todoist migration enabled (admin has configured OAuth client ID/secret)Authenticated Vikunja user accountTodoist account controlled by the attacker**Step 1: Craft malicious Todoist data**Using the Todoist Sync API, create a note with an internal URL as the file attachment:**Step 2: Trigger migration on Vikunja****Step 3: Download the attachment containing internal data**ImpactAn authenticated attacker can:**Read cloud instance metadata**: Access `http://169.254.169.254/` to retrieve IAM credentials, instance identity, and configuration data on AWS/GCP/Azure deployments**Probe internal network services**: Map internal infrastructure by making requests to RFC1918 addresses (10.x, 172.16.x, 192.168.x)**Access internal APIs**: Reach internal services that trust requests from the Vikunja server's network position**Denial of service**: Since `buf.ReadFrom(resp.Body)` has no size limit, pointing to a large or streaming resource causes unbounded memory allocation on the Vikunja serverThe attack requires the target Vikunja instance to have Todoist or Trello migration enabled (requires admin configuration of OAuth credentials), but this is a standard deployment configuration.Recommended FixApply the same SSRF protection already used for webhooks (`daenney/ssrf`) to the migration HTTP clients. In `pkg/modules/migration/helpers.go`:Apply the same pattern to `DoGetWithHeaders` and `DoPostWithHeaders` in the same file.
CVSS v3.1: 6.4