Cedric Bonhomme

**Name of the Vulnerable Software and Affected Versions** Vulnerability-Lookup (affected versions not specified) **Description** 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. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vulnerability-Lookup (affected versions not specified) **Description** 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. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vulnerability-Lookup (affected versions not specified) **Description** 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. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vulnerability-Lookup (affected versions not specified) **Description** 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. **Recommendations** Apply the available patch to implement a shared outbound URL policy that restricts remote instances to HTTP(S), rejects non-public IP addresses, resolves hostnames at request time, and validates each redirect destination. As a temporary mitigation, restrict the `admin:access` permission to trusted users only.

**Name of the Vulnerable Software and Affected Versions** vulnerability-lookup (affected versions not specified) **Description** 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. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.