CVE-2026-59101: AutoBangumi SSRF Vulnerability – Patch to 3.2.8

Technical summary

The vulnerability exists in the POST /api/v1/setup/test-downloader endpoint, which lacks proper input validation and authentication controls. During the initial setup window, the endpoint accepts arbitrary host parameters and causes the AutoBangumi server to issue HTTP GET requests on behalf of the attacker. Connection errors and responses are echoed back to the client, enabling information disclosure about internal network topology, service availability, and configuration. The root cause is CWE-918 (Server-Side Request Forgery), where user-supplied input is used to construct requests without sanitization or validation against restricted address ranges (loopback, private subnets, link-local, metadata services, etc.).

Business impact

An attacker exploiting this vulnerability gains reconnaissance capabilities without authentication. Organizations can suffer reconnaissance attacks that map internal infrastructure, identify running services, and detect network segmentation weaknesses. While the CVSS score is MEDIUM (5.8), the business risk depends on network topology: organizations with internet-facing AutoBangumi instances and sensitive internal services on the same network face higher risk. Data leakage through error messages could expose service versions, hostnames, or availability status. This is particularly concerning in scenarios where AutoBangumi is deployed in cloud or containerized environments where it might reach metadata services (AWS EC2 metadata, Kubernetes API servers, etc.).

Affected systems

AutoBangumi versions prior to 3.2.8 are affected. Organizations should verify their installed version immediately. The vulnerability is only exploitable during the initial setup window; once AutoBangumi is fully configured and setup endpoints are disabled, the attack surface is reduced. However, any deployment that has not been upgraded and retains setup endpoints accessible remains at risk.

Exploitability

Exploitability is straightforward from a technical perspective: the endpoint is unauthenticated and accessible over the network with minimal complexity (AC:L). An attacker requires only network access and the ability to craft HTTP POST requests with arbitrary host parameters. No user interaction is required (UI:N). The attack does not require authentication (PR:N). The primary barrier to exploitation is discovery—the attacker must identify that AutoBangumi is running and in setup mode, or have prior knowledge of the deployment. Proof-of-concept exploitation requires minimal sophistication.

Remediation

Upgrade AutoBangumi to version 3.2.8 or later immediately. This patch version addresses the SSRF vulnerability by implementing input validation and restricting the endpoint from accepting requests to internal, reserved, or metadata service addresses. For organizations unable to patch immediately, restrict network access to the POST /api/v1/setup endpoint via firewall or reverse proxy rules, limit the setup window duration, and ensure AutoBangumi is not exposed directly to the internet during initial deployment. Disable or remove setup endpoints once configuration is complete.

Patch guidance

Verify that you are running AutoBangumi 3.2.8 or later by checking the version in your deployment (typically visible in admin panels or logs). If running an earlier version, update through your package manager, container registry, or by downloading the latest release from the official AutoBangumi repository. After patching, restart the service and confirm that the setup endpoints now properly validate and reject requests to restricted address ranges. Test by attempting to access internal IP ranges (127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) through the endpoint; requests should be rejected rather than processed. For containerized deployments, rebuild images using the patched base image and redeploy.

Detection guidance

Monitor HTTP logs for POST requests to /api/v1/setup/test-downloader, particularly during setup phases or from unexpected sources. Look for requests containing non-standard host parameters, internal IP addresses, localhost references, or cloud metadata service endpoints (169.254.169.254, kubernetes.default.svc.cluster.local). Implement network-based detection rules that flag outbound requests from AutoBangumi to internal networks or reserved addresses during the setup window. Review application logs for connection error messages that may indicate SSRF probe attempts. Deploy WAF rules to restrict the setup endpoint to expected source IP ranges (e.g., administrative subnets only). In containerized environments, monitor egress traffic from AutoBangumi pods for unexpected internal service communication.

Why prioritize this

While the CVSS score is MEDIUM (5.8), prioritize this vulnerability if AutoBangumi is internet-facing or accessible from untrusted networks. The lack of authentication and ease of exploitation make it a quick-win target for reconnaissance. Organizations with internal services reachable from the AutoBangumi network (especially in flat network architectures or shared cloud environments) should treat this as higher priority. Cloud-native deployments with access to metadata services or Kubernetes APIs are at increased risk and should patch urgently.

Risk score, explained

The CVSS 3.1 score of 5.8 (MEDIUM) reflects the vulnerability's moderate severity: it requires network access but no authentication (AV:N, PR:N), is easily exploitable (AC:L), and causes confidentiality impact through information disclosure (C:L). The impact is limited to the confidentiality of internal network information; there is no integrity or availability impact (I:N, A:N). The scope is changed (S:C) because the vulnerability affects systems beyond the vulnerable component itself (internal services). The score appropriately reflects that this is a reconnaissance and information-gathering vulnerability rather than a direct system compromise vector, but organizations should contextualize the score against their network architecture and sensitivity of internal services.

Frequently asked questions