Search
Search Results (9 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-73374 | 1 Circl | 1 Vulnerability-lookup | 2026-08-13 | N/A |
| A stored cross-site scripting (XSS) vulnerability existed in Vulnerability-Lookup in the render_tag_badges Jinja filter used to display reference tags associated with vulnerability records. Values from containers.cna.references[].tags[] were directly interpolated into HTML badge elements and the resulting string was wrapped in markupsafe.Markup. Because Markup marks the generated content as safe, Jinja's automatic HTML escaping was bypassed. An authenticated user with permissions to create or modify vulnerability records, such as a user holding the vulnerability:create or vulnerability:modify permission, could submit a crafted reference tag through the CNA API containing arbitrary HTML or JavaScript-capable markup. The malicious value would subsequently be stored as part of the vulnerability record. When another user visited the corresponding public /cve/<id> or /vuln/<id> page, the crafted tag would be rendered as HTML in the viewer's browser. This could result in JavaScript execution in the security context of the Vulnerability-Lookup application. Successful exploitation could allow an attacker to perform actions in the context of a victim, access information available to the victim's browser session, or modify page content. As the affected vulnerability pages can be accessed publicly, exploitation may affect users who are not authenticated. The issue was corrected by applying markupsafe.escape() to each reference tag before inserting it into the HTML badge markup, while retaining Markup only for the static HTML scaffolding. | ||||
| CVE-2026-73405 | 1 Circl | 1 Vulnerability-lookup | 2026-08-13 | N/A |
| An authorization bypass vulnerability in Vulnerability-Lookup allowed inactive or unconfirmed accounts to subscribe to Server-Sent Events (SSE) streams through the /pubsub/subscribe/<topic> endpoint. The token_required decorator used by the Pub/Sub interface authenticated requests solely by matching the X-API-KEY header against an existing user API key. Unlike the REST API authentication mechanism, it did not verify the account's is_active and is_confirmed state. Because the self-registration process issues an API key before account confirmation is completed, an attacker could create an account and immediately use the resulting API key to access Pub/Sub topics that should only be available to active, confirmed users. This could expose stream events that would otherwise be inaccessible through the REST API, including newly submitted or not-yet-moderated data such as comments. The vulnerability results from inconsistent authorization enforcement between the REST API and the SSE streaming interface. The patch corrects the issue by requiring accounts to be both active and confirmed before permitting access to Pub/Sub streams, bringing the SSE authorization boundary in line with the REST API. | ||||
| CVE-2026-73431 | 1 Circl | 1 Vulnerability-lookup | 2026-08-13 | N/A |
| Vulnerability-Lookup contains an authentication weakness in its account activation and password-recovery mechanism. Activation and recovery links were generated using stateless signed tokens containing only the user's login. Although the token signature and age were validated, the application did not track whether a token had already been successfully used. As a result, a captured activation or password-recovery link remained valid for the entire configured TOKEN_VALIDITY_PERIOD, even after the associated password had been changed. An attacker who obtains a valid activation or recovery token could therefore replay it multiple times during its validity period to set a new password and repeatedly take control of the affected account. In addition, tokens were not bound to a specific purpose, allowing the same token mechanism to be used across activation and recovery workflows. The patch introduces purpose-bound tokens and a random nonce whose SHA-256 digest is stored with the user account. The nonce is invalidated after a successful password change, making tokens single-use, while issuing a new token invalidates any previously issued token. The password-setting operation now explicitly consumes the token before committing the account change. Successful exploitation requires the attacker to obtain a currently valid activation or recovery link, but does not require knowledge of the victim's existing password or an authenticated session. | ||||
| CVE-2026-73432 | 1 Circl | 1 Vulnerability-lookup | 2026-08-13 | N/A |
| Vulnerability-Lookup contains a server-side request forgery (SSRF) vulnerability in the remote-instance synchronization functionality. Remote instance addresses were validated only for basic URL syntax before being stored, while the synchronization worker later dereferenced these addresses using requests.get() with automatic redirect handling and without enforcing network-boundary restrictions. An authenticated administrator with the admin:access permission could configure a remote instance whose address points to an internal, loopback, link-local, or cloud metadata HTTP(S) service. When synchronization is performed, the Vulnerability-Lookup server would issue the request from its own network context. An attacker could also use a publicly accessible URL that redirects to an internal destination, because redirects were previously followed without revalidating the destination. Successful exploitation could allow a privileged attacker to probe or interact with services that are accessible from the Vulnerability-Lookup server but not directly reachable by the attacker, including private network services or cloud instance metadata endpoints. The exact confidentiality, integrity, or availability impact depends on the services reachable from the application server. The patch introduces a shared outbound URL policy that restricts remote instances to HTTP(S), rejects non-public IP addresses, resolves hostnames at request time, and manually validates each redirect destination before following it. The implementation explicitly blocks private, loopback, link-local, multicast, reserved, and unspecified addresses. | ||||
| CVE-2026-72761 | 1 Circl | 1 Vulnerability-lookup | 2026-08-11 | N/A |
| The webhook URL validator in `website/notifications/webhooks.py` uses `ip.is_global` to reject non-public addresses after DNS resolution. IPv6 transition addresses (NAT64 `64:ff9b::/96`, 6to4 `2002::/16`, Teredo `2001:0000::/32`) are classified as globally routable by IANA, so `is_global` returns `True` even when the embedded IPv4 targets a private, loopback, or cloud metadata destination. An attacker can register a webhook pointing at a hostname that resolves to a transition address to bypass the SSRF guard and exfiltrate vulnerability data to an internal endpoint. The vulnerability was introduced on a non-release version. The fix was already done on HEAD. It only affects organisation running the HEAD. | ||||
| CVE-2025-42616 | 1 Circl | 1 Vulnerability-lookup | 2026-04-15 | N/A |
| Some endpoints in vulnerability-lookup that modified application state (e.g. changing database entries, user data, configurations, or other privileged actions) may have been accessible via HTTP GET requests without requiring a CSRF token. This flaw leaves the application vulnerable to Cross-Site Request Forgery (CSRF) attacks: an attacker who tricks a logged-in user into visiting a malicious website could cause the user’s browser to issue GET requests that perform unintended state-changing operations in the context of their authenticated session. Because the server would treat these GET requests as valid (since no CSRF protection or POST method enforcement was in place), the attacker could exploit this to escalate privileges, change settings, or carry out other unauthorized actions without needing the user’s explicit consent or awareness. The fix ensures that all state-changing endpoints now require HTTP POST requests and include a valid CSRF token. This enforces that state changes cannot be triggered by arbitrary cross-site GET requests. This issue affects Vulnerability-Lookup: before 2.18.0. | ||||
| CVE-2025-60249 | 1 Circl | 1 Vulnerability-lookup | 2026-04-15 | 6.4 Medium |
| vulnerability-lookup 2.16.0 allows XSS in bundle.py, comment.py, and user.py, by a user on a vulnerability-lookup instance who can add bundles, comments, or sightings. A cross-site scripting (XSS) vulnerability was discovered in the handling of user-supplied input in the Bundles, Comments, and Sightings components. Untrusted data was not properly sanitized before being rendered in templates and tables, which could allow attackers to inject arbitrary JavaScript into the application. The issue was due to unsafe use of innerHTML and insufficient validation of dynamic URLs and model fields. This vulnerability has been fixed by escaping untrusted data, replacing innerHTML assignments with safer DOM methods, encoding URLs with encodeURIComponent, and improving input validation in the affected models. | ||||
| CVE-2025-42615 | 1 Circl | 1 Vulnerability-lookup | 2026-04-15 | N/A |
| In affected versions, vulnerability-lookup did not track or limit failed One-Time Password (OTP) attempts during Two-Factor Authentication (2FA) verification. An attacker who already knew or guessed a valid username and password could submit an arbitrary number of OTP codes without causing the account to be locked or generating any specific alert for administrators. This lack of rate-limiting and lockout on OTP failures significantly lowers the cost of online brute-force attacks against 2FA codes and increases the risk of successful account takeover, especially if OTP entropy is reduced (e.g. short numeric codes, user reuse, or predictable tokens). Additionally, administrators had no direct visibility into accounts experiencing repeated 2FA failures, making targeted attacks harder to detect and investigate. The patch introduces a persistent failed_otp_attempts counter on user accounts, locks the user after 5 invalid OTP submissions, resets the counter on successful verification, and surfaces failed 2FA attempts in the admin user list. This enforces an account lockout policy for OTP brute-force attempts and improves monitoring capabilities for suspicious 2FA activity.This issue affects Vulnerability-Lookup: before 2.18.0. | ||||
| CVE-2025-42620 | 1 Circl | 1 Vulnerability-lookup | 2026-04-15 | N/A |
| In affected versions, vulnerability-lookup handled user-controlled content in comments and bundles in an unsafe way, which could lead to stored Cross-Site Scripting (XSS). On the backend, the related_vulnerabilities field of bundles accepted arbitrary strings without format validation or proper sanitization. On the frontend, comment and bundle descriptions were converted from Markdown to HTML and then injected directly into the DOM using string templates and innerHTML. This combination allowed an attacker who could create or edit comments or bundles to store crafted HTML/JavaScript payloads which would later be rendered and executed in the browser of any user visiting the affected profile page (user.html). This issue affects Vulnerability-Lookup: before 2.18.0. | ||||
Page 1 of 1.