CVE-2026-112358 in Lespass
Summary
by MITRE • 10/20/2026
A weakness has been identified in TiBillet Lespass up to 10e87909c5d526dffa6d424c104fc12860740537. This vulnerability affects the function get_img_from_url of the file ApiBillet/serializers.py of the component APIv1. Executing a manipulation of the argument img_url/image_url can lead to server-side request forgery. The attack can be launched remotely. A high complexity level is associated with this attack. It is stated that the exploitability is difficult. The vendor confirms: "[T]he fix (destination IP validation, redirect re-checks, timeout and size limit on remote image download) is already planned in our v2 API, which replaces the affected v1 endpoints. The v1 API, including the three affected serializers, will be removed in our next major release."
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The identified vulnerability resides within the TiBillet Lespass application, specifically affecting versions up to commit 10e87909c5d526dffa6d424c104fc12860740537. The flaw is located in the get_img_from_url function within the ApiBillet/serializers.py file, which serves as part of the APIv1 component. This architectural placement indicates that the vulnerability impacts the data serialization layer responsible for processing incoming requests related to image resources. When an attacker manipulates the img_url or image_url argument passed to this function, they can trigger a Server-Side Request Forgery attack. In such scenarios, the vulnerable server acts as a proxy, fetching content from URLs controlled by the attacker rather than legitimate sources. This behavior allows the application to be used as a pivot point for further network reconnaissance or attacks against internal services that may not be directly accessible from the external internet.
The operational impact of this vulnerability is significant due to its remote exploitability and potential for data exfiltration or internal network mapping. Although the complexity level is rated as high, meaning specific conditions are required to successfully execute the attack, the ability to force a server to make arbitrary HTTP requests remains a critical security risk. Attackers can leverage SSRF to access sensitive metadata from cloud provider instances, scan internal ports and services, or attempt to exploit other vulnerabilities on backend systems by directing traffic toward them. The difficulty of exploitation suggests that while automated scanning tools might identify the vector, successful attacks may require manual tuning or specific environmental configurations within the target infrastructure. This aligns with common patterns observed in web application security where SSRF flaws often depend on the presence of internal services and the configuration of network segmentation.
From a standards perspective, this vulnerability corresponds to CWE-918, which defines Server-Side Request Forgery (SSRF) as a weakness that enables an attacker to cause the server-side application to make requests to arbitrary URLs. This classification highlights the failure in validating user-supplied input before it is processed by backend systems. Furthermore, within the MITRE ATT&CK framework, this behavior maps to T1571, which covers Non-Standard Application Layer Protocols or services used for lateral movement and data exfiltration via SSRF techniques. The lack of proper validation on destination IPs allows attackers to bypass standard perimeter defenses that typically filter outbound traffic based on known malicious domains rather than internal IP ranges.
The vendor has acknowledged the severity of this issue and confirmed that a comprehensive fix is already planned for their v2 API, which is designed to replace the affected v1 endpoints. The proposed remediation strategy includes multiple layers of defense: destination IP validation to prevent requests to private or reserved address spaces, redirect re-checks to ensure final destinations are authorized, timeouts to mitigate denial-of-service risks associated with slow HTTP attacks, and size limits on remote image downloads to control resource consumption. These measures represent industry best practices for securing SSRF-prone functions by enforcing strict allow-listing of permitted domains and validating the final resolved IP address against a list of safe internal ranges.
Until the v2 API is deployed and the vulnerable v1 endpoints are removed in the next major release, organizations running affected versions should implement compensating controls at the network or application gateway level. This includes configuring web application firewalls to inspect outbound HTTP requests from the server for signs of SSRF attempts, such as requests targeting private IP ranges like 10.x.x.x, 172.16.x.x through 172.31.x.x, and 192.168.x.x. Additionally, restricting egress traffic to only required external domains can significantly reduce the attack surface. Monitoring logs for unusual outbound connection patterns from the application server will also aid in early detection of exploitation attempts while waiting for the permanent software update.