Cedric Bonhomme

A stored cross-site scripting (XSS) issue exists in the `render tag badges` Jinja filter used to display reference tags for vulnerability records. The application directly interpolates values from `containers.cna.references[].tags[]` into HTML badge elements and wraps the result in `markupsafe.Markup`, which bypasses Jinja's automatic HTML escaping. An authenticated user with `vulnerability:create` or `vulnerability:modify` permissions can submit crafted reference tags via the CNA API containing arbitrary HTML or JavaScript. This malicious content is stored and subsequently executed in the browser of any user visiting the public `/cve/<id>` or `/vuln/<id>` endpoints. This could allow an attacker to perform actions on behalf of the victim, access session information, or modify page content, potentially affecting unauthenticated users.

An authorization bypass exists due to inconsistent enforcement between the REST API and the Server-Sent Events (SSE) streaming interface. The Pub/Sub interface uses a `token required` decorator that authenticates requests by matching the `X-API-KEY` header against a user API key but fails to verify if the account is active or confirmed. Since API keys are issued during self-registration before confirmation is complete, unauthorized users can access the `/pubsub/subscribe/<topic>` endpoint. This allows access to stream events, such as unmoderated comments, that are otherwise restricted via the REST API.

An authentication weakness exists in the account activation and password-recovery mechanism. The system uses stateless signed tokens containing only the user's login. While the signature and age are validated, the application fails to track if a token has already been used. Consequently, a captured activation or recovery link remains valid for the duration of the `TOKEN VALIDITY PERIOD`, even after a password change. This allows an attacker with a valid token to replay it multiple times to reset the password and take control of the account. Furthermore, tokens are not bound to a specific purpose, enabling the same token to be used for both activation and recovery workflows. Exploitation requires obtaining a valid link but does not require the victim's current password or an active session.

A server-side request forgery (SSRF) issue exists in the remote-instance synchronization functionality. The system validated remote instance addresses only for basic URL syntax before storage, while the synchronization worker later processed these addresses using `requests.get()` with automatic redirect handling and no network-boundary restrictions. An authenticated administrator with `admin:access` permission could configure a remote instance pointing to internal, loopback, link-local, or cloud metadata HTTP(S) services. Additionally, a publicly accessible URL could be used to redirect to an internal destination since redirects were followed without revalidation. This allows a privileged attacker to probe or interact with services accessible from the server's network context, such as private network services or cloud instance metadata endpoints.

The webhook URL validator in `website/notifications/webhooks.py` uses `ip.is global` to reject non-public addresses after DNS resolution. However, IPv6 transition addresses, such as NAT64 `64:ff9b::/96`, 6to4 `2002::/16`, and Teredo `2001:0000::/32`, are classified as globally routable by IANA. Consequently, `is global` returns `True` even if the embedded IPv4 targets a private, loopback, or cloud metadata destination. This allows an attacker to register a webhook pointing to a hostname that resolves to a transition address, bypassing the Server-Side Request Forgery (SSRF) guard to exfiltrate data to an internal endpoint.