Search
Search Results (5 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-67178 | 1 Misp | 1 Misp | 2026-07-28 | N/A |
| MISP installation scripts generated an Apache HTTP virtual-host configuration containing an incorrectly formatted HTTP-to-HTTPS redirect: Redirect permanent / https://misp.example Apache’s Redirect directive appends any portion of the requested path that follows the matched prefix to the configured destination URL. Because the destination did not end with /, attacker-controlled path content was appended directly to the hostname rather than to its URL path. For example, a request resembling: http://misp.example/@attacker.example/ could result in a redirect resembling: https://misp.example@attacker.example/ Under standard URL parsing, misp.example is interpreted as user information and attacker.example as the destination host. An unauthenticated remote attacker could therefore construct a URL hosted under the legitimate MISP domain that redirects users to an attacker-controlled website. The vulnerability could be used for phishing, credential collection, or potentially disclosing sensitive query-string information preserved during the redirect. Exploitation requires a user to follow the crafted HTTP URL. The fix adds the missing trailing slash to the redirect destination, ensuring that appended request data remains part of the path on the configured MISP host. Existing installationsExisting MISP installations should review their Apache HTTP virtual-host configuration and ensure that the HTTPS redirect destination ends with a trailing slash: Redirect permanent / https://misp.example/ After updating the configuration, validate it with apachectl configtest and reload or restart Apache for the change to take effect | ||||
| CVE-2026-62143 | 1 Misp | 1 Misp-modules | 2026-07-14 | N/A |
| A Server-Side Request Forgery (SSRF) protection bypass existed in the html_to_markdown expansion module of misp-modules. The module attempts to prevent requests to loopback, private, link-local, and other restricted IP address ranges. However, IP addresses were compared against the blocked ranges without first normalising IPv4-mapped IPv6 addresses. An authenticated attacker able to invoke the module could supply an IPv4-mapped IPv6 address, such as: http://[::ffff:127.0.0.1]/ http://[::ffff:169.254.169.254]/ Alternatively, the attacker could use a hostname that resolves to an IPv4-mapped IPv6 address. These addresses were treated as IPv6 addresses and therefore did not match the corresponding blocked IPv4 ranges. Successful exploitation could cause the misp-modules server to connect to services available through its loopback interface, internal network, or link-local network. This could expose internal web services, administrative interfaces, or cloud instance metadata, with retrieved content potentially returned to the attacker as converted Markdown. The vulnerability has been addressed by normalising IPv4-mapped IPv6 addresses to their underlying IPv4 representation before applying the blocked-range checks. URLs without a valid hostname are now also rejected. | ||||
| CVE-2026-61474 | 1 Misp | 1 Misp | 2026-07-09 | N/A |
| An improper authorization check in MISP’s attribute creation endpoint allowed an authenticated user with permission to add attributes to submit a sharing_group_id without triggering the corresponding sharing group authorization check, as long as the attribute distribution value was not explicitly set to 4 — “sharing group”. As a result, a user could reference or associate an attribute with a sharing group they were not authorized to use. This could lead to an access-control bypass affecting the integrity of attribute sharing metadata and potentially expose or misuse restricted sharing group relationships. The patch changes the authorization logic so that the sharing group permission check is performed whenever a non-empty sharing_group_id is provided, regardless of the selected distribution value. | ||||
| CVE-2026-60124 | 1 Misp | 1 Misp | 2026-07-08 | N/A |
| An authorization bypass in MISP’s EventsController::importModule() allowed authenticated users or read-only API keys with event view access to persist data to events they were not allowed to modify. When an import module returned results in the misp_standard format, the write path did not verify event modification rights before saving the module output. This could allow a view-only user to inject or alter event data, impacting the integrity of MISP event content. The issue was fixed by enforcing the same modification-rights check used by related module result handling paths before processing misp_standard imports. | ||||
| CVE-2026-60125 | 1 Misp | 1 Misp | 2026-07-08 | N/A |
| MISP’s importModule() path used getEnabledModule() to resolve a single import module by name, but this lookup did not enforce the per-organisation module restriction checked by getEnabledModules(). As a result, an authenticated user from an organisation that was not allowed to use a module restricted via Plugin.Import_<module>_restrict could still invoke that import module directly if they knew its name. This could allow unauthorised access to restricted import-module functionality and, depending on the module and the user’s event permissions, may allow unauthorised import or modification of event data through a module that should have been unavailable to the user’s organisation. | ||||
Page 1 of 1.