CVE-2026-33677: Plaintext Credential Exposure in Vikunja Webhook API

Vikunja is an open-source, self-hosted task management platform that provides webhook integrations to notify external systems of project events. The platform exposes a REST API for managing these webhooks, allowing project members to view and configure destination URLs and authentication parameters. A vulnerability exists in the implementation of this webhook management API, tracked as CVE-2026-33677, which results in the exposure of sensitive information to unauthorized actors.

The flaw specifically affects the endpoint responsible for listing webhooks associated with a given project. When a client requests the webhook configuration, the API serializes the internal database models into JSON responses. While certain sensitive fields were historically redacted during this serialization process, newly introduced authentication fields were omitted from the redaction routine.

Consequently, the API transmits plaintext Basic Authentication credentials to any authenticated user possessing read-only permissions for the target project. This oversight breaks the principle of least privilege, granting low-privileged collaborators access to high-value secrets intended exclusively for automated system-to-system communication.

The root cause of CVE-2026-33677 is an oversight in the data serialization layer of the Vikunja API, specifically within the webhook management handlers. The application relies on database models to represent webhooks, which include configuration fields for external target URLs, event triggers, and authentication secrets. When a user requests the webhook list via GET /api/v1/projects/:project/webhooks, the application fetches these models from the database and serializes them into JSON.

Historically, the application correctly implemented a masking mechanism for the HMAC secret field. The serialization logic explicitly overwrote the secret value with placeholder asterisks before writing the JSON payload to the HTTP response body. This ensured that while users could see a webhook was configured with a secret, they could not extract the plaintext value itself.

In a subsequent feature update, developers introduced support for Basic Authentication, adding basic_auth_user and basic_auth_password fields to the webhook data model. However, the serialization logic was not updated to include these new fields in the redaction process. The application directly serialized the database records, emitting the plaintext username and password strings into the final JSON response.

Furthermore, the access control logic governing the GET /api/v1/projects/:project/webhooks endpoint only verifies that the requesting user holds "read" access to the specified project. Because the endpoint does not differentiate between standard configuration reads and administrative secret management, any read-only collaborator successfully passes the authorization check and triggers the vulnerable serialization path.

The vulnerability manifests in the data transformation boundary between the internal database representation and the external API response. The structural defect is evident in the serialization pipeline. The application fetches the webhook structure, which maps directly to the underlying database table containing all authentication columns.

In the vulnerable implementation, the API handler executes a data masking routine that targets specific fields based on identifiers. The routine successfully identifies the HMAC secret field and replaces its contents with a static string. The newly added Basic Authentication fields bypass this routine entirely because they lack the necessary struct tags or hardcoded references required by the masking function.

The patch for CVE-2026-33677 extends the masking mechanism to encompass the basic_auth_password field. By updating the serialization logic to recognize and redact the newly introduced authentication variables, the application correctly limits credential visibility to the server's internal memory space, preventing accidental exposure over the REST API interface.

Exploitation of CVE-2026-33677 requires the attacker to possess a valid account on the target Vikunja instance and read-only access to at least one project utilizing webhooks with Basic Authentication. The attack does not require any specialized tools or complex memory manipulation; it relies entirely on standard HTTP requests directed at the vulnerable API endpoint.

The attacker begins by identifying the target project ID. This identifier is readily available in the Vikunja user interface or can be enumerated via the GET /api/v1/projects endpoint. Once the project ID is obtained, the attacker constructs an authenticated GET request targeting the webhook listing route.

GET /api/v1/projects/<PROJECT_ID>/webhooks HTTP/1.1
Host: target-vikunja-instance.local
Authorization: Bearer <USER_TOKEN>
Accept: application/json

The server processes the request, performs the read-only authorization check, and returns an HTTP 200 OK response containing the unredacted webhook configurations. The attacker parses the resulting JSON payload, isolating the basic_auth_user and basic_auth_password key-value pairs.

[
  {
    "id": 1,
    "target_url": "https://external-service.com/webhook",
    "basic_auth_user": "admin_service",
    "basic_auth_password": "super_secret_password_123",
    "secret": "**********"
  }
]

The primary impact of CVE-2026-33677 is a direct loss of confidentiality for credentials entrusted to the Vikunja application. While the CVSS v3.1 score is 6.5 (Medium), the real-world severity depends entirely on the privileges associated with the exposed external credentials. The vulnerability allows an attacker to pivot from a low-privileged position within Vikunja to potentially high-privileged access on external systems.

Webhooks are frequently integrated with internal enterprise services, automation platforms like Jenkins or GitLab, and communication tools such as Slack. If the exposed Basic Authentication credentials authorize administrative actions on these downstream systems, the attacker can leverage them to achieve lateral movement, execute arbitrary code on CI/CD runners, or access sensitive corporate communications.

The vulnerability highlights the risks associated with storing third-party secrets within collaboration tools. Because the exposure is passive and occurs via standard API requests, exploitation leaves minimal forensic traces in application logs. Defenders cannot easily differentiate between a legitimate client synchronizing application state and an attacker harvesting external system credentials.

The mandatory remediation for CVE-2026-33677 is upgrading the Vikunja application to version 2.2.1 or later. The patched versions correctly apply the data masking routines to the basic_auth_password fields, ensuring that subsequent API requests do not leak sensitive configuration material to the client.

Upgrading the application does not remediate credentials that were previously exposed. Organizations must assume that any Basic Authentication credentials configured in Vikunja prior to the patch have been compromised. Administrators must identify all target systems integrated via Vikunja webhooks and immediately rotate the corresponding usernames, passwords, and API keys.

Detection of exploitation attempts requires deep packet inspection or proxy logging that captures API response bodies. Network defenders can implement detection rules looking for the concurrent presence of the strings basic_auth_user and basic_auth_password alongside recognizable credential patterns in responses from the /api/v1/projects/*/webhooks endpoint. Standard HTTP access logs are insufficient for detection, as they only record the request URI and status code, not the unredacted payload.