CVE-2026-112288 in laravel-crm
Summary
by MITRE • 10/19/2026
Krayin CRM 2.2.5 before 2.2.7 contains a server-side request forgery filter bypass that allows users with webhook permissions to reach internal addresses via DNS rebinding. Attackers can return a public address during WebhookService::isSafeEndpoint() validation and an internal address when Guzzle re-resolves, sending blind requests to internal services and cloud metadata endpoints.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in Krayin CRM versions prior to 2.2.7 represents a sophisticated server-side request forgery flaw rooted in the application's webhook handling mechanism. This specific implementation allows authenticated users possessing webhook permissions to bypass security filters designed to restrict outbound requests to internal or untrusted network segments. The core of the issue lies in how the application validates endpoint safety during the creation and execution of webhooks, specifically within the WebhookService::isSafeEndpoint function which serves as a gatekeeper for outgoing HTTP traffic.
The technical flaw exploits a race condition inherent in DNS resolution processes combined with inadequate validation persistence. When an attacker initiates a webhook request, the initial validation step checks if the target domain resolves to a public IP address that is deemed safe by the application's whitelist or logic. The attacker configures their controlled DNS server to return this approved public IP during the initial check performed by Krayin CRM. However, because HTTP clients like Guzzle perform their own independent DNS resolution at the time of actual request transmission, there is a window where the domain can resolve differently. By manipulating the Time-to-Live values or leveraging specific network conditions, an attacker can cause the subsequent resolution step to return an internal private IP address instead of the originally validated public one.
This discrepancy between validation and execution effectively bypasses the server-side filter, allowing the application to send requests directly to internal services that are not accessible from the external internet. This technique is commonly referred to as DNS rebinding or SSRF via DNS resolution race conditions. The impact extends beyond simple network access; attackers can leverage this capability to probe internal infrastructure, exfiltrate data from local APIs, and interact with cloud metadata endpoints such as those found in AWS EC2 or Google Cloud Platform instances. Accessing these metadata services is particularly dangerous as it often provides temporary credentials for other cloud resources, potentially leading to full compromise of the underlying infrastructure hosting the Krayin CRM instance.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery and specifically illustrates the risks associated with improper validation of user-supplied input during network operations. It also maps to MITRE ATT&CK techniques related to Discovery and Lateral Movement, as attackers use internal service probing to map out the network topology and access sensitive resources that are otherwise isolated from external threats. The blind nature of these requests means that while immediate feedback might not be visible in the application interface, successful exploitation can lead to significant data breaches or further system compromise through credential theft via metadata endpoints.
Mitigation strategies must focus on closing this validation gap. The most effective remediation involves ensuring that DNS resolution occurs only once and is cached securely for the duration of the request lifecycle, preventing any possibility of rebinding during execution. Alternatively, applications should validate IP addresses directly rather than relying solely on domain names, as IP addresses do not suffer from re-resolution issues if resolved correctly at validation time. Additionally, implementing strict allowlists that include both domains and their corresponding static IPs can prevent such bypasses. For organizations unable to immediately patch to version 2.2.7 or later, deploying a Web Application Firewall with rules capable of detecting DNS rebinding patterns or restricting outbound traffic from the application server to only explicitly whitelisted internal subnets can provide an essential layer of defense against this type of exploitation.