CVE-2026-7291
Server-Side Request Forgery in o2oa URL Fetching Component
Publication date: 2026-04-28
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| zhejiang_land_network_technology_co_ltd | o2oa | 10.0 |
| zhejiang_land_network_technology_co_ltd | o2oa | to 10.0 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-7291 is an authenticated Server-Side Request Forgery (SSRF) vulnerability in O2OA versions up to 10.0. It affects the file import feature where an authenticated user can submit a JSON payload containing a fileUrl parameter. The server fetches the file from this URL and stores it without properly validating the host.
Because the HTTP allowlist is set to "*" by default, the server does not restrict which URLs can be fetched, allowing attackers to supply URLs pointing to internal or loopback addresses that are normally inaccessible externally.
An attacker can exploit this to make the server fetch internal resources, potentially accessing sensitive internal services or data by downloading the fetched content later.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability CVE-2026-7291 allows authenticated attackers to perform server-side request forgery (SSRF) on the O2OA platform, enabling internal network reconnaissance and unauthorized data retrieval from internal services. This can lead to unauthorized access to sensitive information and potential data breaches.
Such unauthorized access and potential data exposure could negatively impact compliance with common standards and regulations like GDPR and HIPAA, which require strict controls on data confidentiality, integrity, and access. The SSRF vulnerability increases the risk of data leakage or unauthorized internal system access, which may result in violations of these regulations.
Mitigating this vulnerability by restricting URL fetches, validating hosts, and limiting feature access is essential to maintain compliance with data protection and privacy standards.
How can this vulnerability impact me? :
This vulnerability allows authenticated attackers to perform internal network reconnaissance and retrieve data from internal services that are not exposed externally.
- Attackers can access local administration interfaces or development services bound to loopback addresses.
- They can retrieve sensitive information from cloud metadata endpoints or other internal HTTP/HTTPS resources.
- This can lead to unauthorized data disclosure and potentially further compromise of internal systems.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for authenticated POST requests to the endpoint `/x_file_assemble_control/jaxrs/file/upload/with/url` that include a JSON payload with the `fileUrl` parameter. Such requests indicate attempts to exploit the server-side request forgery (SSRF) vulnerability.
A practical detection method is to look for unusual or unauthorized internal URL fetches initiated by the server, especially those targeting internal IP addresses like 127.0.0.1 or private network ranges.
Example commands to detect exploitation attempts include:
- Using web server logs (e.g., grep) to find suspicious POST requests: `grep "/x_file_assemble_control/jaxrs/file/upload/with/url" /var/log/nginx/access.log`
- Using network monitoring tools (e.g., tcpdump) to capture outbound HTTP requests from the server to internal IPs: `tcpdump -i eth0 host 127.0.0.1 and tcp port 80`
- Checking application logs for entries related to file uploads with URLs pointing to internal or suspicious hosts.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include restricting and validating the URLs that the server fetches when processing the upload-by-URL feature.
- Configure the HTTP allowlist to include only trusted domains or endpoints, avoiding the use of a wildcard "*" which disables host filtering.
- Implement server-side checks to block requests to loopback, link-local, private, multicast, and cloud metadata IP ranges.
- Disable or limit following HTTP redirects during the fetch operation.
- Restrict the upload-by-URL feature to administrative users or disable it entirely if not required.
- Apply network-level isolation to prevent outbound fetches from reaching sensitive internal services.