Vikunja is an open-source, self-hosted task management platform that supports project webhooks for integration with external services. In versions prior to 2.2.1, the API endpoint GET /api/v1/projects/:project/webhooks returns webhook configuration data, including BasicAuth credentials (basic_auth_user and basic_auth_password), in plaintext to any user with read access to the project. This occurs because while the HMAC secret field was masked properly, the BasicAuth credentials introduced in a later migration were not similarly protected. As a result, any read-only collaborator can retrieve these credentials and use them to authenticate against external webhook receivers, potentially gaining unauthorized access or triggering malicious webhook events. The vulnerability is classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). The CVSS 3.1 base score is 6.5, reflecting medium severity with network attack vector, low attack complexity, requiring privileges (read access), no user interaction, and high confidentiality impact but no integrity or availability impact. No known exploits are reported in the wild as of publication. The issue was fixed in Vikunja version 2.2.1 by masking or removing BasicAuth credential exposure in the webhook API response.

The primary impact of this vulnerability is the unauthorized disclosure of BasicAuth credentials used for authenticating webhook receivers. Attackers with read-only access to a project can steal these credentials and impersonate the webhook client, potentially triggering unauthorized webhook calls or accessing sensitive data on external systems integrated via webhooks. This can lead to data leakage, unauthorized actions on third-party services, and compromise of trust boundaries between Vikunja and external systems. Although the vulnerability does not allow modification of project data or direct compromise of Vikunja itself, the stolen credentials can be leveraged for lateral movement or further attacks on integrated services. Organizations relying on Vikunja for task management and automation workflows that use webhooks are at risk, especially if they grant read access to many users or external collaborators. The medium severity score reflects the significant confidentiality impact balanced by the requirement for read access privileges.

1. Upgrade Vikunja installations to version 2.2.1 or later, where the vulnerability is patched and BasicAuth credentials are no longer exposed in the webhook API response. 2. Review and restrict project read access permissions to only trusted users to minimize exposure risk. 3. Rotate any BasicAuth credentials used in webhooks that were potentially exposed prior to patching to invalidate stolen credentials. 4. Audit webhook configurations and external integrations for suspicious activity or unauthorized access attempts. 5. Implement network segmentation and monitoring on systems receiving webhook calls to detect anomalous behavior. 6. Consider using more secure authentication mechanisms for webhooks, such as OAuth tokens or signed requests, instead of BasicAuth credentials. 7. Regularly review and update access control policies and perform security assessments on self-hosted platforms like Vikunja.