CVE-2026-112040 in diem
Summary
by MITRE • 10/19/2026
A vulnerability was determined in diem-project diem up to 116974edfb9a5b8bd69cb13586dc62bcdbb485ad. This affects an unknown part of the file dmCorePlugin/plugins/dmUserPlugin/modules/dmUser/lib/BasedmUserActions.class.php of the component Sign-In. This manipulation of the argument Referer causes open redirect. The attack is possible to be carried out remotely. The exploit has been publicly disclosed and may be utilized. This product adopts a rolling release strategy to maintain continuous delivery. Therefore, version details for affected or updated releases cannot be specified. The project was informed of the problem early through an issue report but has not responded yet.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The identified vulnerability resides within the diem-project content management system, specifically affecting versions up to commit 116974edfb9a5b8bd69cb13586dc62bcdbb485ad. The flaw is located in the dmUserPlugin module, which handles user authentication and session management tasks. More precisely, the defect exists within the BasedmUserActions.class.php file responsible for processing sign-in operations. This component plays a critical role in managing user access to protected areas of the application, making any weakness here particularly significant from a security perspective. The vulnerability manifests as an open redirect issue triggered by improper validation of the Referer HTTP header argument passed during authentication flows.
Open redirects occur when a web application accepts untrusted input for redirection purposes without adequately validating whether the target URL is safe or belongs to the same domain. In this specific instance, the application fails to properly sanitize or verify the destination address provided via the Referer parameter before redirecting the user agent. This lack of rigorous validation allows an attacker to construct a malicious link that appears legitimate but ultimately directs the victim to a phishing site controlled by the adversary. The technical root cause is classified under CWE-601, which defines URL Redirection to Untrusted Site (Open Redirect). This classification highlights the failure in input validation logic where external data influences control flow without sufficient checks against an allowlist or domain verification mechanisms.
The operational impact of this vulnerability extends beyond simple redirection. Attackers can leverage open redirects for sophisticated social engineering campaigns. By embedding the malicious redirect link within emails, messages, or legitimate-looking web pages, adversaries can trick users into believing they are interacting with a trusted service while being silently transferred to a fraudulent login page designed to harvest credentials. This technique is frequently employed in phishing attacks where maintaining the illusion of trustworthiness is crucial for success. Furthermore, open redirects can be used to bypass security controls that rely on referrer checking or to facilitate cross-site request forgery scenarios by masking the true origin of malicious requests. The ability to redirect users arbitrarily undermines user confidence and compromises the integrity of the authentication process.
This vulnerability is remotely exploitable, meaning an attacker does not need prior access to the system or valid credentials to initiate the attack. The exploit has been publicly disclosed, which significantly increases the risk landscape as automated scanning tools and malicious actors can readily utilize this knowledge to target vulnerable instances. Given that diem-project employs a rolling release strategy for continuous delivery, pinpointing exact version numbers is challenging. However, any deployment utilizing code up to the specified commit hash remains susceptible unless specific patches or workarounds have been manually applied by administrators. The lack of response from the project maintainers regarding early issue reports suggests that users must rely on community-driven fixes or self-implemented mitigations rather than official updates for immediate protection.
To mitigate this risk, developers and system administrators should implement strict validation rules for all redirection parameters. This includes verifying that redirect URLs belong to a predefined list of trusted domains or ensuring they are relative paths within the application itself. Input sanitization techniques such as encoding special characters and rejecting absolute URLs with different hosts can effectively neutralize open redirect attempts. Additionally, implementing security headers like Content-Security-Policy with appropriate directives can help restrict navigation targets in modern browsers. Organizations should also consider deploying Web Application Firewalls configured to detect and block patterns associated with open redirect attacks. Regular code reviews focusing on authentication modules are essential to identify similar flaws before they reach production environments. Continuous monitoring for suspicious redirection activity can provide early warning of exploitation attempts, allowing for rapid incident response.