CVE-2026-95813 in e621ng
Summary
by MITRE • 09/22/2026
e621ng versions before 26.09.16 pass untrusted request parameters directly to Rails url_for in PaginatorComponent and controller navigation links, allowing attackers to redirect pagination and navigation controls to attacker-controlled origins. Attackers can supply host, protocol, and port query parameters that are interpreted as URL generation options, causing pagination links to point to malicious domains while the initial page loads from the legitimate site.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in e621ng versions prior to 26.09.16 represents a critical security flaw rooted in improper neutralization of input parameters during URL generation, specifically classified under CWE-79: Improper Neutralization of Input During Web Page Generation Cross-site Scripting and CWE-80: Basic XSS with the specific mechanism of Open Redirect via Query Parameters. This issue arises within the PaginatorComponent and controller navigation links where untrusted request parameters are passed directly to the Rails url_for method without adequate validation or sanitization. The architectural design flaw allows external actors to manipulate how URLs are constructed by injecting malicious values into query strings that are subsequently interpreted as URL generation options rather than simple data inputs.
The technical mechanism of this vulnerability exploits the flexibility inherent in Ruby on Rails' url_for helper, which accepts a hash of parameters including host, protocol, and port to generate absolute or relative links. When an attacker supplies these specific parameters through HTTP requests, the framework interprets them as directives for URL construction rather than rejecting them as invalid input. Consequently, pagination controls and navigation elements that are rendered on legitimate pages begin to point toward domains controlled by the attacker. This behavior persists even when the initial page content is served from a trusted source, creating a deceptive environment where users interact with interface elements that appear native but lead elsewhere.
The operational impact of this vulnerability extends beyond simple link redirection, facilitating sophisticated phishing campaigns and session hijacking attempts. By embedding malicious links within legitimate pagination controls, attackers can trick users into entering credentials on counterfeit login pages or downloading malware disguised as safe content. The trust established by the initial page load from a reputable domain lowers user suspicion, significantly increasing the success rate of social engineering attacks. Furthermore, this flaw undermines the integrity of the application's navigation structure, potentially leading to broken links and degraded user experience if malicious parameters cause routing errors or unexpected behavior in edge cases.
From an offensive security perspective, this vulnerability aligns with MITRE ATT&CK technique T1566.002: Phishing: Spearphishing Link, where attackers use legitimate-looking infrastructure to deliver malicious payloads. The ability to control the destination of navigation links allows for seamless integration into phishing kits that mimic the target application's interface perfectly. This is particularly dangerous in community-driven platforms like e621ng, where user engagement relies heavily on trust and consistent branding. The lack of strict allow-listing or validation for URL components means that any parameter matching known URL keys can be exploited to redirect traffic away from secure endpoints.
Mitigation strategies must focus on implementing strict input validation and output encoding practices within the Rails application layer. Developers should avoid passing user-supplied parameters directly into url_for without first verifying them against a whitelist of allowed hosts, protocols, and ports. Alternatively, using relative paths for internal navigation links can prevent external domain specification entirely. Implementing Content Security Policy headers with restrictive connect-src directives can also mitigate the impact by preventing browsers from loading resources or navigating to unauthorized origins even if malicious URLs are generated server-side. Regular security audits focusing on URL generation functions across all controllers and components are essential to ensure that no other entry points exist for similar injection attacks in future releases.