CVE-2026-75626 in SpiderFoot
Summary
by MITRE • 08/18/2026
SpiderFoot fails to HTML-escape correlation titles built from external scan data sources including server banners and metadata. Attackers can inject malicious HTML elements with event handlers into correlation results that execute scripts in the operator's browser when the correlations view is opened, potentially stealing API keys.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified as a Cross-Site Scripting (XSS) flaw within SpiderFoot stems from an insufficient sanitization of user-controllable input during the rendering phase of correlation titles. Specifically, the application constructs these titles by aggregating data retrieved from various external scan sources, such as server banners and metadata fields. Instead of applying strict HTML entity encoding or context-aware escaping to this untrusted data before it is inserted into the Document Object Model (DOM), SpiderFoot allows raw HTML content to pass through directly. This architectural oversight creates a direct path for malicious actors who can influence these external data sources to inject executable script payloads, thereby compromising the integrity and security of the operator's session when viewing correlation results.
From a technical perspective, this flaw represents an instance of Stored Cross-Site Scripting because the malicious payload is persisted within the application's output based on previously scanned or indexed data rather than being immediately reflected in a single request-response cycle. When an attacker manages to inject HTML elements containing event handlers, such as onload or onclick attributes, into fields like server banners, these scripts become dormant until triggered by user interaction. The trigger mechanism here is passive; simply opening the correlations view causes the browser to parse and execute the injected JavaScript code within the context of the SpiderFoot web interface. This execution environment grants the malicious script access to sensitive cookies, local storage data, and potentially API keys stored in memory or accessible via client-side scripts, leading to a severe compromise of confidentiality and integrity for the security operator using the tool.
The operational impact of this vulnerability is significant given that SpiderFoot operators often handle highly sensitive intelligence data and authentication credentials. Successful exploitation allows an attacker to perform actions such as session hijacking, where stolen cookies can be used to impersonate the legitimate user within the application. Furthermore, if API keys are accessible via JavaScript or stored in browser storage without adequate protection, they can be exfiltrated to a remote server controlled by the adversary. This could lead to unauthorized access to external scanning services, data theft from integrated platforms, and further lateral movement into other systems connected through those compromised credentials. The trust placed in SpiderFoot as an intelligence gathering tool is undermined if operators cannot rely on the safety of their own interface against injected content derived from scanned targets.
This vulnerability aligns with CWE-79, which classifies Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. It also maps to MITRE ATT&CK technique T1059, specifically sub-techniques involving JavaScript execution, and potentially T1204 for User Execution if the attack relies on social engineering to get an operator to view specific malicious correlations. To mitigate this risk, developers must implement rigorous input validation and output encoding strategies across all data flows that involve external sources. This includes applying context-sensitive HTML escaping when rendering correlation titles in the browser DOM. Additionally, implementing a Content Security Policy (CSP) with strict directives can provide a defense-in-depth layer by restricting the execution of inline scripts and limiting script sources to trusted domains only. Regular security audits focusing on data binding practices and automated static analysis tools configured to detect XSS patterns are also recommended to prevent similar flaws in future releases.