Description

bisheng through 2.6.0-fix2 contains a server-side request forgery vulnerability in the POST /api/v1/workflow/report/callback endpoint that lacks authentication and applies no URL scheme restrictions or host filtering. Unauthenticated attackers can supply arbitrary URLs to enumerate internal network services and cloud metadata endpoints, then retrieve captured responses from object storage using caller-supplied object names.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.2",
  "pubDate": "2026-08-28T20:20:19.953Z",
  "pubdate": "2026-08-28T20:20:19.953Z",
  "executiveSummary": "A critical Server-Side Request Forgery (SSRF) vulnerability exists in the bisheng application, affecting versions up to and including 2.6.0-fix2.\nThe vulnerability resides within the POST /api/v1/workflow/report/callback endpoint, which fails to implement necessary authentication checks or input validation.\nBy design, the application processes user-supplied URLs without restricting URL schemes or applying host filtering, effectively allowing an attacker to leverage the server as a proxy.\nThe potential impact includes the unauthorized enumeration of internal network services, reconnaissance of cloud provider metadata endpoints (e.g., AWS/GCP/Azure instance metadata), and the retrieval of sensitive data.\nSuccessful exploitation requires no prior authentication, allowing remote, unauthenticated attackers to conduct arbitrary request forwarding from the server's context.\nThe vulnerability poses a severe risk to internal network security, potentially exposing services hidden behind firewalls or non-public interfaces that trust the bisheng host.\nAttackers can further weaponize this flaw to exfiltrate captured responses by specifying destination object names within object storage, significantly escalating the impact to data confidentiality.",
  "technicalDetails": "The vulnerability is a classic Server-Side Request Forgery (SSRF) flaw located in the POST /api/v1/workflow/report/callback endpoint of the bisheng workflow management system.\nThe root cause of this vulnerability is the lack of authorization controls and the absence of a server-side input validation mechanism for URLs provided in the request body.\nWhen a request is made to the aforementioned callback endpoint, the application logic parses the provided URL and initiates an outbound HTTP request without validating the target destination or the protocol scheme.\nBecause the application does not enforce an allowlist of permitted hosts or restrict access to local network segments (e.g., 127.0.0.1, 169.254.169.254), an attacker can craft a payload that targets internal infrastructure or cloud metadata services.\nThe attack flow proceeds as follows: First, an unauthenticated attacker sends a malicious POST request to the /api/v1/workflow/report/callback endpoint. Second, the attacker embeds a target URL within the request parameters. Third, the bisheng server, operating with the identity of the backend service, executes the request to the specified target. Fourth, the server processes the response from the target and stores it in configured object storage, utilizing an attacker-supplied object name as the storage identifier. Finally, the attacker retrieves the captured content from the object storage, completing the data exfiltration chain.\nThe vulnerability affects all bisheng versions through 2.6.0-fix2. It is particularly dangerous in cloud-native environments, as it allows attackers to query cloud provider metadata endpoints, which often contain sensitive configuration data, temporary security credentials, or environment-specific environment variables.\nBecause the system performs these requests without any authentication requirements, it bypasses network-level perimeter defenses that would otherwise block direct access to internal services. The ability to manipulate the final destination of the captured response within object storage facilitates easy exfiltration of retrieved data, even if the direct output of the callback API is obscured."
}