Summary
iDocView contains a server-side request forgery vulnerability in the /doc/upload endpoint. An unauthenticated remote attacker who can use the hardcoded default token may cause the server to request attacker-selected URLs, potentially reading local files or accessing internal network services.
Affected context
The vulnerability occurs in iDocView deployments where the /doc/upload endpoint accepts attacker-influenced URLs, authentication can be bypassed with a default token, and URL schemes are not restricted. Risk is increased when the service has access to sensitive local files, cloud metadata endpoints, internal hosts, or administrative services.
Exploit preconditions
- Attack surface: The remotely reachable
/doc/uploadendpoint - Required access: No valid account may be required when the hardcoded default token is accepted
- Trigger point: Server-side processing of a supplied URL during document upload handling
- Why exploitation is possible: URL validation and scheme restrictions do not adequately constrain outbound requests, allowing the server to access local or internal resources on the attacker's behalf
Why this happens
The underlying bug is server-side request forgery, mapped to CWE-918. The application treats a client-controlled URL as a trusted resource location and uses the server's network and file-access privileges to retrieve it. Authentication weakness from a hardcoded default token and insufficient URL-scheme validation broaden the reachable attack surface.
Potential impact
- Attackers may read sensitive local files, including operating-system or application configuration data.
- Attackers could access internal network hosts and services that are not directly exposed to the internet.
- Cloud or infrastructure metadata may be disclosed where reachable from the server.
- Internal services could be scanned or abused through the vulnerable application.
- Exposed credentials may enable further compromise or lateral movement.
General mitigation guidance
Mitigation generally focuses on removing default authentication bypasses and enforcing a strict outbound request trust boundary.
Common defensive patterns include:
- Require strong, non-default authentication and authorization before URL retrieval.
- Permit only required URL schemes, such as HTTPS, and reject local-file and other unsafe schemes.
- Use allowlists for destination hosts, ports, and URL paths rather than accepting arbitrary destinations.
- Resolve hostnames safely and block loopback, link-local, private, and other restricted address ranges, including redirect targets.
- Route outbound requests through controlled egress proxies or network policies.
- Run the service with minimal filesystem, network, and operating-system privileges.
- Avoid exposing sensitive files and credentials to the service account.
How teams detect issues like this
High-level detection approaches include:
- Static analysis for user-controlled URLs passed to HTTP clients, file readers, or generic resource-fetching functions.
- Code review checks for default tokens, authentication bypass conditions, unrestricted URL schemes, and missing redirect validation.
- Runtime monitoring for unexpected outbound requests to loopback, private, link-local, metadata, or unusual external destinations.
- Web application firewall and gateway policies that restrict URL-fetching parameters and suspicious URI schemes.
- Network egress logging and alerting correlated with requests to sensitive internal address ranges.
- Automated security review tools can help identify SSRF sinks and hardcoded authentication values during development.
