CVE-2026-75340 in JetLinks
Summary
by MITRE • 08/27/2026
The device metadata import interface /device/instance/{productId}/property-metadata/import of jetlinks community 2.11 is vulnerable to Server-side request forgery (SSRF).
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/27/2026
A critical security vulnerability has been identified in the JetLinks Community Edition version 2.11, specifically within the device metadata import interface located at /device/instance/{productId}/property-metadata/import. This flaw manifests as a Server-Side Request Forgery, commonly referred to as SSRF, which allows an attacker to manipulate server-side requests by supplying maliciously crafted input parameters. The vulnerability stems from insufficient validation and sanitization of user-supplied data before it is processed by the backend application logic that handles device metadata imports. When this endpoint receives a request containing a URL or resource identifier in its payload, the system fails to adequately restrict the destination hosts or protocols, thereby enabling an unauthorized actor to force the server to initiate connections to arbitrary internal or external resources.
The technical mechanism of this vulnerability relies on the application's ability to fetch remote metadata definitions for device instances. In a typical operation, the server might retrieve schema files or configuration templates from specified URLs to populate device properties. However, due to the lack of strict allow-listing mechanisms or proper URL parsing validation, an attacker can inject internal network addresses such as those belonging to cloud provider instance metadata services (e.g., 169.254.169.254), local loopback interfaces, or other sensitive backend microservices that are not directly exposed to the public internet but are accessible from within the application's execution environment. This capability effectively bypasses network perimeter defenses because the requests originate from a trusted internal source, allowing the attacker to probe and interact with services that would otherwise remain hidden behind firewalls or security groups.
The operational impact of this SSRF vulnerability is severe, particularly in environments where JetLinks is deployed within containerized architectures like Kubernetes or Docker networks, or on cloud infrastructure such as AWS EC2 instances. An authenticated attacker can leverage this flaw to perform internal network reconnaissance, identifying live hosts and open ports across the private subnet. More critically, the attacker may access sensitive metadata endpoints that store authentication tokens, secret keys, or configuration details essential for maintaining system integrity. In worst-case scenarios, if combined with other vulnerabilities such as deserialization flaws in the target services, this SSRF could lead to remote code execution on internal servers. The ability to read local files via file:// protocols further exacerbates the risk by potentially exposing sensitive configuration files stored on the server's filesystem.
This vulnerability aligns closely with CWE-918, which defines Server-Side Request Forgery as a weakness where a web application fetches a remote resource without validating the user-supplied URL. It also maps to MITRE ATT&CK technique T1571, specifically the component of Non-Standard Port or Protocol usage if attackers attempt to bypass standard filtering rules by using uncommon ports or protocols like gopher or file schemes. The lack of input validation represents a fundamental failure in secure coding practices regarding external resource interaction, highlighting the need for rigorous sanitization routines before any network activity is initiated based on user input.
To mitigate this vulnerability, immediate remediation steps should focus on implementing strict allow-listing for all URLs processed by the metadata import interface. The application should only permit connections to known and trusted domains or IP ranges required for legitimate device metadata retrieval. Additionally, developers must enforce protocol restrictions to prevent the use of dangerous schemes such as file://, gopher://, or ftp:// unless absolutely necessary and securely configured. Network-level controls should also be reviewed; deploying web application firewalls that detect SSRF patterns can provide an additional layer of defense, while ensuring that the server running JetLinks does not have unnecessary access to sensitive internal metadata endpoints is crucial for reducing the attack surface. Regular security audits and static code analysis tools capable of detecting unsafe HTTP client usage are recommended to prevent similar issues in future updates.