CVE-2026-26211 in Ekushey Project Manager CRM
Summary
by MITRE • 08/25/2026
Ekushey Project Manager CRM stores the administrator-configured system name and writes it to the login page without output encoding. The value is emitted in three places on that page: the content attribute of the description meta element, the title element, and the text of an h4 element in the page header. The h4 occurrence is parsed as markup, so HTML placed in the system name field is rendered as markup and any event handler it carries runs. The login page is served without authentication, so the stored value executes in the browser of every visitor who loads it, including visitors who are not signed in, within the origin that serves the login form and alongside the credential fields on it. Storing the value requires an administrator session; the resulting script runs for unauthenticated visitors and persists until the setting is changed.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified involves a stored cross-site scripting flaw within the Ekushey Project Manager CRM application, specifically affecting the login page interface. This security issue arises from the system's failure to properly sanitize or encode user-supplied input when rendering administrator-configured settings back into HTML content. The core technical deficiency lies in the lack of output encoding for the system name value, which is retrieved from the database and injected directly into multiple locations on the unauthenticated login page. This includes the description meta element, the document title, and critically, an h4 header element within the page structure. While some contexts might offer partial protection through browser default behaviors or less sensitive HTML attributes, the injection point within the h4 tag is parsed as active markup by modern web browsers. Consequently, any script tags or event handlers embedded in the system name are executed immediately upon page load, bypassing standard security controls that rely on context-aware encoding to prevent code execution.
From an operational perspective, this vulnerability presents a significant risk because it allows for persistent malicious payload delivery without requiring user interaction beyond visiting the login URL. Since the affected page is served without authentication requirements, every visitor who accesses the system encounters the injected script in their browser environment. This includes potential attackers, competitors conducting reconnaissance, or legitimate users attempting to log in. The persistence of this vulnerability means that a single administrative action—configuring an arbitrary string as the system name—is sufficient to compromise all subsequent visitors until the setting is reverted. The impact extends beyond simple defacement; because the script executes within the origin context of the login form, it has access to sensitive data such as credentials entered by users, session cookies, and other browser-stored information associated with that domain. This facilitates credential theft, session hijacking, or further exploitation through drive-by downloads if combined with additional malicious payloads.
The technical classification of this flaw aligns closely with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting (XSS). Specifically, it represents a stored XSS variant where the payload is saved on the server and served to multiple victims over time. In terms of adversary tactics, this vulnerability maps to ATT&CK technique T1059, Command and Scripting Interpreter, particularly when used for client-side script execution like JavaScript or VBScript. It also relates to T1189, Drive-by Client Setup, as the malicious code executes automatically upon page load without explicit user consent beyond navigation. The severity is heightened by the fact that the attack vector does not require social engineering or complex phishing campaigns; simply accessing the application's public-facing login interface triggers the exploit, making it a high-impact vulnerability for any organization relying on this CRM system.
Mitigation strategies must focus on implementing robust input validation and output encoding mechanisms within the web application framework. Developers should ensure that all dynamic content inserted into HTML contexts is properly encoded according to the specific context in which it appears. For text nodes like those inside an h4 element, character-level escaping of special characters such as ampersands, less-than signs, greater-than signs, and quotes is essential to prevent them from being interpreted as markup or script delimiters. Additionally, implementing a Content Security Policy (CSP) can provide a layer of defense by restricting the sources from which scripts are allowed to execute, thereby mitigating the impact even if an injection occurs. Regular security audits and static code analysis tools configured to detect missing output encoding patterns should be employed during development cycles to prevent similar vulnerabilities in other parts of the application architecture.