CVE-2026-119709 in Grimoire
Summary
by MITRE • 10/30/2026
Grimoire before 1.0.0 contains an unauthenticated server-side request forgery vulnerability in the /api/fetch-metadata POST handler that passes user-supplied URLs to getMetadata() without authentication checks. Attackers can submit URLs targeting loopback, internal-network, or cloud metadata endpoints and read the parsed title, description, and page content returned.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The software Grimoire prior to version 1.0.0 contains a critical server-side request forgery vulnerability within its API endpoint responsible for fetching web metadata. This flaw resides specifically in the POST handler located at /api/fetch-metadata, which is designed to retrieve title, description, and page content from user-provided URLs. The core technical deficiency lies in the absence of authentication checks combined with a lack of input validation regarding the destination addresses. When an attacker submits a URL via this endpoint, the server processes it by passing the value directly into a function named getMetadata without verifying whether the requestor is authorized or whether the target address is safe. This architectural oversight allows any unauthenticated actor to instruct the application server to make HTTP requests on their behalf, effectively turning the vulnerable service into an open proxy for internal network reconnaissance and data exfiltration.
The operational impact of this vulnerability is significant because it enables attackers to bypass perimeter security controls that typically restrict direct access to internal resources. By crafting malicious payloads with URLs pointing to loopback addresses such as 127.0.0.1 or localhost, an attacker can interact with services running on the same host but not exposed to the public internet, including administrative panels, database interfaces, or monitoring tools. Furthermore, targeting private IP ranges allows for scanning and exploitation of other devices within the internal network segment. A particularly dangerous vector involves requesting cloud metadata endpoints, such as those found in AWS EC2 instances at 169.254.169.254. Successful exploitation can lead to the theft of temporary security credentials, instance identity documents, or user data stored in these metadata services, potentially granting attackers full control over compromised infrastructure without needing valid login credentials for the target systems.
This vulnerability aligns with Common Weakness Enumeration category CWE-918, which describes Server-Side Request Forgery (SSRF). The specific mechanism involves the server making requests to unintended destinations based on user input, violating the principle of least privilege and proper access control. In terms of offensive security frameworks, this behavior maps directly to MITRE ATT&CK technique T1557, known as Adversary-in-the-Middle or Lateral Tool Transfer via SSRF, where attackers use compromised systems to pivot laterally within a network environment. The lack of authentication on the /api/fetch-metadata endpoint further exacerbates the risk by removing any barrier that might prevent unauthorized users from initiating these malicious requests, making it trivial for automated tools to discover and exploit this flaw across large deployments.
To mitigate this vulnerability, immediate remediation efforts should focus on implementing strict access controls for all API endpoints, ensuring that sensitive operations like fetching external metadata require valid authentication tokens or session validation. Additionally, developers must enforce rigorous input validation by maintaining a whitelist of allowed domains or IP ranges rather than relying solely on blacklist approaches which are prone to bypass techniques such as DNS rebinding or URL encoding tricks. Implementing network-level controls is also recommended; this includes configuring the application server's outbound traffic rules to block requests to private IP address spaces, loopback addresses, and known cloud metadata endpoints unless explicitly required for business logic. Finally, deploying a Web Application Firewall with SSRF detection capabilities can provide an additional layer of defense by identifying and blocking anomalous request patterns directed at internal resources before they reach the application code.