Summary
Weaver e-Bridge contains an unauthenticated server-side request forgery vulnerability in the saveYZJFile endpoint. By supplying a crafted URL to the downloadUrl parameter, a remote attacker may read local files or make requests to internal network resources.
Affected context
The vulnerability occurs where the saveYZJFile endpoint accepts attacker-controlled values in the downloadUrl parameter and retrieves content from file: or HTTP(S) URLs. Risk is higher when the endpoint is internet-accessible without authentication and the server can access sensitive local files or internal services.
Exploit preconditions
- Attack surface: The remotely accessible
saveYZJFileendpoint - Required access: No authentication may be required
- Trigger point: Processing a user-supplied value in the
downloadUrlparameter - Why exploitation is possible: The server accepts URL schemes and destinations that are not sufficiently restricted, allowing it to read local resources or issue requests on the attacker's behalf
Why this happens
The underlying flaw is insufficient validation and destination control for server-side URL retrieval. The application treats attacker-controlled URL input as a trusted resource locator, permitting local file access and requests to protected network destinations. This behavior maps primarily to CWE-918: Server-Side Request Forgery, with the file-reading aspect representing an unsafe trust boundary around resource access.
Potential impact
- An attacker may read sensitive local files, including system or application configuration data
- Credentials, tokens, or other secrets could be disclosed
- The server could be used to query internal network services
- Internal service metadata or administrative interfaces may be exposed
- The vulnerability could support further compromise if retrieved information enables access to privileged systems
General mitigation guidance
Mitigation generally focuses on reducing trust in user-supplied URLs and separating content retrieval from security-sensitive server resources.
Common defensive patterns include:
- Allowing only explicitly approved URL schemes, hosts, ports, and paths
- Rejecting local-file and other nonessential resource schemes by default
- Applying centralized egress controls and network segmentation
- Blocking access to loopback, link-local, private, and metadata-service addresses
- Revalidating destinations after DNS resolution to reduce rebinding risks
- Avoiding unauthenticated exposure of file-fetching functionality
- Running the service with least-privilege filesystem and network permissions
- Returning controlled responses that do not expose raw retrieved content or detailed errors
How teams detect issues like this
Organizations can look for SSRF and arbitrary file retrieval risks through:
- Static analysis rules identifying URL fetches that consume request parameters
- Code review checks for unrestricted URL schemes, redirects, hostnames, and ports
- Tests covering local-file references, loopback addresses, private ranges, and cloud metadata endpoints
- Web application firewall or API-gateway policies restricting URL-bearing parameters
- Network monitoring for unexpected outbound connections from the application
- Audit logs that record destination URLs, response origins, and access to sensitive paths
- Automated security review tools that flag user-controlled input reaching network or filesystem APIs
