CVE-2026-117565 in Artalk
Summary
by MITRE • 10/27/2026
Artalk before 2.10.1 contains an unauthenticated server-side request forgery vulnerability that allows remote attackers to make the server fetch arbitrary URLs by submitting anonymous comments to /api/v2/comments. Attackers can set a page_key to an internal URL, which GetTitleByURL fetches after only scheme validation, then read the page title through the public comment list.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in Artalk versions prior to 2.10.1 represents a critical server-side request forgery flaw that stems from insufficient input validation within the application's comment submission API endpoint. Specifically, the /api/v2/comments route accepts anonymous comments containing a page_key parameter which is subsequently processed by the GetTitleByURL function. This function is designed to fetch metadata such as the title of a webpage associated with the comment context. However, the implementation only performs a basic validation on the URL scheme, checking for standard protocols like http or https, while failing to validate the destination host against an allowlist or restrict access to internal network resources. This architectural oversight allows remote attackers who do not require authentication to manipulate this parameter and direct the server to make requests to arbitrary URLs under their control or within the target's private infrastructure.
The operational impact of this vulnerability is significant due to its unauthenticated nature, which lowers the barrier for exploitation considerably. An attacker can submit a crafted comment payload where the page_key points to an internal IP address, such as those belonging to cloud metadata services like 169.254.169.254 commonly used by AWS or Azure, or other sensitive internal endpoints that are not exposed to the public internet but are accessible from within the server's network environment. By leveraging this capability, an attacker can force the Artalk server to act as a proxy, fetching content from these restricted resources. The retrieved data, such as instance metadata containing IAM credentials or configuration details, is then stored in the database associated with the comment entry.
Exploitation becomes particularly effective because the fetched information is subsequently exposed through the public comment list interface. Since the vulnerability allows reading the page title via this mechanism, and potentially other content depending on how GetTitleByURL processes the response, an attacker can retrieve sensitive internal data simply by viewing the comments section of any blog or article hosted on the vulnerable instance. This transforms a seemingly benign user interaction into a powerful tool for information disclosure, enabling attackers to map out internal network structures, steal cloud credentials, and potentially pivot further into more critical systems within the organization's infrastructure.
This vulnerability aligns with CWE-918, which classifies Server-Side Request Forgery (SSRF) flaws where web applications fetch remote resources without validating user-supplied URLs. It also maps to MITRE ATT&CK technique T1557, specifically Adversary-in-the-Middle or Lateral Tool Transfer variants that involve server-side request forgery for credential theft and internal network reconnaissance. The lack of strict host validation is a common pattern in web applications that assume the underlying infrastructure is secure enough not to require additional application-level restrictions on outbound requests.
To mitigate this vulnerability, organizations running Artalk versions earlier than 2.10.1 should immediately upgrade to version 2.10.1 or later where these checks have been implemented. For environments where upgrading is not immediately feasible, a network-level mitigation involves configuring the server's firewall rules to block outbound connections from the application process to internal IP ranges and cloud metadata endpoints such as 169.254.169.254. Additionally, implementing an allowlist of permitted domains for the page_key parameter within the application configuration can provide a robust defense-in-depth strategy against SSRF attacks. Regular security audits focusing on input validation in API endpoints are essential to prevent similar issues from arising in other parts of the application stack.