CVE-2026-111313 in JobOps
Summary
by MITRE • 10/16/2026
JobOps through 0.13.1 contains a server-side request forgery vulnerability in the POST /api/manual-jobs/fetch handler that allows authenticated users, or unauthenticated clients in demo mode, to make the server fetch internal destinations. Attackers can supply loopback, private, or cloud metadata addresses in the url field to read returned page content, disclosing instance metadata and internal service data.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
JobOps versions through 0.13.1 are susceptible to a Server-Side Request Forgery vulnerability within the POST /api/manual-jobs/fetch endpoint. This flaw arises from insufficient validation of user-supplied input in the url parameter, allowing an attacker to instruct the server to initiate HTTP requests to arbitrary destinations controlled by the client rather than legitimate external services intended for job fetching operations. The vulnerability is particularly severe because it permits access to internal network resources that are typically isolated from direct internet exposure, effectively bypassing perimeter security controls such as firewalls and web application firewalls that rely on source IP verification or request origin assumptions.
The operational impact of this vulnerability is significant due to the potential for data exfiltration and reconnaissance against internal infrastructure. By supplying loopback addresses like 127.0.0.1, private network ranges such as 192.168.x.x, or cloud metadata endpoints like http://169.254.169.254, an attacker can force the JobOps server to retrieve sensitive information from internal services. In cloud environments, this often leads to the disclosure of instance metadata and credentials, which can be leveraged for further lateral movement within the network. Additionally, attackers may probe internal web applications or APIs running on non-standard ports that are not exposed publicly but remain accessible via localhost or private IP ranges, potentially revealing configuration details, session tokens, or other proprietary data stored in response bodies.
Authentication requirements vary depending on the deployment mode of JobOps. In standard configurations, authenticated users can exploit this flaw to access internal resources using their existing credentials. However, in demo modes where authentication is disabled or relaxed, unauthenticated external actors can directly interact with the vulnerable endpoint without any prior login process. This significantly lowers the barrier for exploitation and increases the risk profile for public-facing instances running in demonstration mode. The ability to read returned page content means that not only are requests made, but the server acts as a proxy, returning the full response from the internal target back to the attacker, facilitating comprehensive data harvesting without requiring complex post-exploitation techniques.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), which describes flaws where an application fetches a remote resource without validating the user-supplied URL. It also maps to MITRE ATT&CK technique T1557, specifically Adversary-in-the-Middle or Lateral Tool Transfer variants that utilize SSRF for network reconnaissance and credential theft. The exploitation path involves manipulating input parameters (CWE-20) to redirect server-side logic toward unintended internal destinations, violating the principle of least privilege by granting web applications excessive access to internal networks.
Mitigation strategies should prioritize immediate patching to version 0.13.2 or later where this issue has been addressed through stricter URL validation and allow-listing mechanisms. In the interim, administrators running older versions in production environments should restrict network egress from JobOps servers using firewall rules that block outbound connections to private IP ranges and cloud metadata endpoints unless explicitly required for business logic. Input sanitization at the application layer is critical; developers must implement a whitelist of allowed domains or schemes rather than relying on blacklist approaches, which are prone to bypass via encoding tricks or protocol variations such as HTTP redirects to internal addresses. Additionally, disabling demo mode in production deployments eliminates the risk posed by unauthenticated actors and reduces the attack surface significantly.