CVE-2026-104807 in MiVoice Office 400
Summary
by MITRE • 10/05/2026
DigitalCanion has discovered a stored Cross-Site Scripting (XSS) vulnerability that allows an authenticated malicious user to inject persistent JavaScript or HTML content into the web application.
The specific flaw exists within the web portal listening on TCP port 443, under Configuration → Domains, specifically in the “Description” field. The application fails to properly validate or sanitize user-supplied input before storing and subsequently rendering the field.
By injecting malicious JavaScript into the Description field, an attacker can modify the content and behavior of the affected page when it is viewed by other users. This could allow an attacker to alter the page's appearance, display attacker-controlled content, or construct convincing phishing scenarios within the application's trusted web context.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/05/2026
The identified vulnerability represents a classic instance of stored Cross-Site Scripting, formally categorized under CWE-79 in the Common Weakness Enumeration taxonomy. This specific flaw resides within the DigitalCanion web portal interface, accessible via TCP port 443, and is triggered through the Configuration module’s Domains section. The root cause lies in the application's failure to perform adequate input validation or output encoding on data submitted to the Description field. When an authenticated user provides malicious script content as part of this field, the server accepts it without sanitization and persists it within its backend storage system. This lack of proper filtering allows arbitrary JavaScript code to be embedded directly into the database records associated with domain configurations.
The operational impact of this vulnerability is significant because the injected payload becomes persistent rather than transient. Unlike reflected XSS attacks that require tricking a user into clicking a malicious link, stored XSS ensures that every time an administrator or authorized personnel views the affected configuration page, their browser executes the attacker-controlled script within the context of the trusted web application domain. This persistence transforms the vulnerability from a one-time exploitation opportunity into a continuous threat vector. The presence of authentication requirements limits the initial attack surface to compromised accounts or insiders with legitimate access credentials, but once inside, the potential for widespread impact increases due to the automatic execution upon page load by any viewer.
From an offensive security perspective, this flaw aligns closely with MITRE ATT&CK technique T1059.007, which covers JavaScript as a client-side scripting language used in web-based attacks. An attacker leveraging this vulnerability can achieve several malicious objectives within the trusted context of the application. These include stealing session cookies or authentication tokens through document.cookie access, performing actions on behalf of other users by manipulating DOM elements to submit forms automatically, or creating convincing phishing interfaces that mimic legitimate administrative functions to harvest additional credentials from unsuspecting administrators. The ability to alter page appearance and inject content also facilitates social engineering attacks where the attacker can display misleading information directly within the application's interface, eroding trust in the system's integrity.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Immediately, all instances of stored XSS payloads should be purged from the database to prevent further exposure to users. The primary technical fix involves implementing strict input validation on the server side for the Description field, ensuring that only expected character sets are accepted while rejecting or escaping special HTML characters such as angle brackets and quotation marks. Additionally, output encoding must be applied when rendering user-supplied data in web pages to ensure browsers interpret it as text rather than executable code. Adopting a Content Security Policy (CSP) header can further mitigate the impact by restricting the sources from which scripts are allowed to execute, thereby neutralizing many injection-based attacks even if input validation fails. Regular security audits and static application security testing should be integrated into the development lifecycle to detect such sanitization gaps before deployment.