CVE-2026-93848 in Mattermost
Summary
by MITRE • 10/26/2026
Mattermost versions 11.7.x <= 11.7.10 fail to apply outbound internal-connection filtering to the OpenID discovery endpoint request which allows a System Administrator to determine whether internal addresses and ports are reachable from the server via an unauthenticated login request that triggers the discovery fetch.. Mattermost Advisory ID: MMSA-2026-00774
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in Mattermost versions 11.7.x through 11.7.10 represents a critical misconfiguration in how the application handles outbound network requests during authentication flows, specifically targeting the OpenID Connect discovery endpoint. This flaw stems from an insufficient implementation of internal-connection filtering mechanisms that are designed to prevent servers from initiating connections to private or local IP addresses and ports. In standard secure architectures, such as those enforcing Server-Side Request Forgery mitigations, applications must strictly validate outbound URLs against a deny list of reserved address ranges defined by RFC 1918 for IPv4 and similar standards for IPv6 before executing the request. The absence of this validation in the specified Mattermost versions allows an attacker to manipulate the authentication process into making network probes that reveal information about the internal network topology.
From a technical perspective, the exploitation vector relies on the unauthenticated nature of the initial login trigger combined with the server's behavior when processing OpenID discovery requests. When a user attempts to log in using an identity provider configured via OpenID Connect, Mattermost fetches metadata from the issuer's well-known URI endpoint. Due to the missing filter, if this URI is controlled by or points toward an internal service within the same network segment as the Mattermost server, the application will successfully resolve and connect to that internal address. This behavior effectively turns the authentication subsystem into a port scanner or host reachability checker from the perspective of the external attacker who initiates the login attempt. The system administrator role is not required for this initial probe; rather, any unauthenticated user can trigger the request, although full exploitation may require specific contextual knowledge depending on the deployment environment.
The operational impact of this vulnerability extends beyond simple information disclosure. By systematically varying the target IP addresses and ports in the crafted OpenID discovery URLs, an attacker can perform network reconnaissance to map out internal services that are otherwise not exposed to the public internet. This capability facilitates further attacks such as Server-Side Request Forgery (SSRF) exploitation against vulnerable internal applications, credential harvesting from internal authentication endpoints, or even lateral movement preparation if combined with other vulnerabilities. The ability to determine which internal addresses and ports are reachable provides a significant advantage in attack planning, allowing adversaries to identify high-value targets within the organization's infrastructure without direct network access. This aligns closely with CWE-918, which describes Server-Side Request Forgery flaws where the web server makes requests to unintended destinations, as well as CWE-200 regarding exposure of sensitive information through error messages or side channels like timing and reachability analysis.
In terms of threat modeling, this vulnerability maps directly to MITRE ATT&CK technique T1598.004, specifically Phishing for Information within Cloud Environments, where the attacker uses social engineering (in this case, a fake login page) to induce the server into performing actions that leak internal network data. It also relates to T1046 Network Service Discovery, as the vulnerability allows an external actor to discover services running on internal hosts by observing successful versus failed connection attempts during the authentication handshake. The severity is heightened because it bypasses traditional perimeter defenses since the request originates from a trusted server IP address that may be whitelisted in firewall rules for outbound traffic.
To mitigate this risk, organizations must immediately upgrade Mattermost to version 11.7.11 or later, where the internal-connection filtering has been properly implemented and enforced on all outbound HTTP requests initiated by the application logic. Until an upgrade is feasible, administrators should consider implementing network-level controls such as egress firewall rules that restrict the Mattermost server's ability to initiate connections to private IP ranges (such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) unless explicitly required for business operations. Additionally, deploying a Web Application Firewall with SSRF detection capabilities can provide an additional layer of defense by inspecting outbound traffic patterns associated with authentication endpoints. Regular security audits should include testing for open redirect vulnerabilities and improper URL validation in all external-facing services to prevent similar misconfigurations in other components of the infrastructure.