CVE-2026-61529 in Endatix
Summary
by MITRE • 10/28/2026
Endatix is a self-hosted form and survey management platform with a headless API. Prior to 0.7.0, the anonymous `POST /forms/{formId}/submissions` endpoint stores attacker-controlled `JsonData` after checking only that the JSON is well formed. A file object with `name`, `type` and `content` fields can contain an HTTP or HTTPS URL. When a staff member with `submissions.view` permission invokes `POST /forms/{formId}/submissions/{submissionId}/files`, `GetFilesHandler` passes the stored data to `SubmissionFileExtractor` in `src/Endatix.Infrastructure/Features/Submissions/SubmissionFileExtractor.cs`, which calls `HttpClient.GetAsync` without validating the destination URL, host or resolved IP addresses against internal address ranges. This permits stored, second-order server-side GET requests to internal services, cloud metadata, loopback and link-local addresses from the server's network position. The form must have `IsPublic` and `IsEnabled` set, and an anonymous submission must pass reCAPTCHA v3 when configured. The fetched response is placed in the staff viewer's ZIP, not returned directly to the attacker, so disclosure to the attacker is blind or indirect through observable request behavior or information exposed by the viewer. No integrity or availability impact is asserted; data: and raw-base64 `content` are decoded locally without network requests. This issue is fixed in version 0.7.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in Endatix prior to version 0.7.0 represents a classic instance of Second-Order Server-Side Request Forgery, commonly categorized under CWE-918 and mapped to the ATT&CK technique T1560.002 which involves data staging via cloud infrastructure or internal network probes. This flaw resides within the form submission handling mechanism, specifically affecting how file attachments are processed when viewed by administrative staff members with specific permissions. The application allows anonymous users to submit forms containing JSON data that includes file objects defined by name, type, and content fields. While the system performs basic validation to ensure the submitted JSON is well-formed, it fails to validate the semantic validity or safety of the URL contained within these file objects during the initial submission phase. This lack of input sanitization at ingestion allows an attacker to store a maliciously crafted HTTP or HTTPS URL as part of the form data without immediate detection.
The exploitation vector activates when a privileged user, possessing the submissions.view permission, accesses the details of a specific submission through the GET files endpoint. Upon this invocation, the GetFilesHandler retrieves the stored JSON data and passes it to the SubmissionFileExtractor component located in the infrastructure layer. This extractor is responsible for processing file attachments but critically fails to validate the destination URL, host, or resolved IP addresses against internal address ranges before initiating network requests. Consequently, when the application attempts to fetch these files using HttpClient.GetAsync, it executes a GET request from the server's own network position toward the attacker-controlled target. Because this action is triggered by an authorized user interaction rather than directly by the external attacker, it bypasses many standard authentication and authorization checks that might otherwise block such requests if initiated directly by an unauthenticated actor.
The operational impact of this vulnerability centers on information disclosure through blind or indirect channels. The fetched response from the internal service or cloud metadata endpoint is not returned directly to the original attacker in the HTTP response body. Instead, it is packaged into a ZIP file intended for download by the staff member viewing the submission. This design means that direct exfiltration of data via this specific vector is not feasible unless there are additional side channels available to the attacker. However, significant risks remain regarding network reconnaissance and internal service enumeration. An attacker can leverage timing differences or error responses observable through other application behaviors to infer information about internal services, cloud metadata endpoints such as those found in AWS EC2 or Azure Instance Metadata Service, loopback addresses like 127.0.0.1, and link-local addresses. This capability allows for detailed mapping of the internal network topology and identification of vulnerable backend services that may not be exposed to the public internet but are accessible from the application server's context.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary fix involves upgrading Endatix to version 0.7.0 or later, where this validation logic has been corrected to ensure URLs are properly validated against internal ranges before any network request is made. For environments unable to upgrade immediately, defensive measures should include implementing strict allow-listing of permitted URL schemes and hostnames within the form submission processing pipeline. Additionally, deploying a web application firewall with rules capable of detecting outbound requests to non-whitelisted IP addresses or known cloud metadata endpoints can provide an additional layer of defense. It is also advisable to restrict the permissions required for viewing submissions where possible, ensuring that only essential personnel have access to data containing potentially malicious file attachments. Regular security audits focusing on server-side request forgery patterns in form handling components are recommended to prevent similar vulnerabilities from being introduced during future development cycles.