CVE-2026-61696 in Forem
Summary
by MITRE • 08/18/2026
Forem is open source software for building communities. In versions before commit 92eacd16a82cf9007ba8e16a2258b42e3b53ca9c, a malicious value submitted through feedback_message[message] is stored without sanitization and rendered in app/views/admin/feedback_messages/_feedback_message.html.erb through raw(feedback_message.message) when offender_id is present. Viewing the abuse report executes arbitrary JavaScript in an administrator's browser and may expose sensitive in-page data, abuse CSRF tokens, or perform administrative actions in the victim's session. The public FeedbackMessagesController accepts the report without authorization and previously permitted a submitted offender_id, making the vulnerable rendering path reachable by an unauthenticated attacker. This issue is fixed in commit 92eacd16a82cf9007ba8e16a2258b42e3b53ca9c
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
Forem, a widely utilized open-source platform for building online communities, suffered from a critical stored cross-site scripting vulnerability in versions prior to commit 92eacd16a82cf9007ba8e16a2258b42e3b53ca9c. This flaw stemmed from inadequate input sanitization within the feedback submission mechanism, specifically affecting the message content submitted via the feedback_message[message] parameter. The vulnerability was exacerbated by a flawed authorization model in the public FeedbackMessagesController, which accepted abuse reports without requiring authentication and previously allowed the inclusion of an offender_id field. This combination created a scenario where unauthenticated attackers could inject malicious payloads into the system's database through legitimate-looking report submissions.
The technical core of the issue lay in how the application rendered these stored messages within the administrative interface. When viewing an abuse report, the application executed raw(feedback_message.message) inside the app/views/admin/feedback_messages/_feedback_message.html.erb template, but only when a specific offender_id was present. Because the input was not sanitized upon storage and then explicitly marked as safe for rendering without proper context-aware escaping, any JavaScript code embedded in the feedback message would be interpreted directly by the browser of an administrator viewing that report. This represents a classic stored cross-site scripting flaw where malicious scripts are permanently stored on the target server and executed whenever users retrieve the affected data.
The operational impact of this vulnerability is severe due to its potential for privilege escalation and session hijacking. An attacker could craft a feedback message containing arbitrary JavaScript designed to exploit the administrator's active browser session. This could lead to the exfiltration of sensitive in-page data, including personal information or internal system configurations visible only to admins. Furthermore, attackers could steal anti-CSRF tokens stored within the page DOM, enabling them to forge authenticated requests on behalf of the victim. In a worst-case scenario, this allows for complete administrative takeover, where an attacker can perform any action available to a site administrator, such as modifying user accounts, changing settings, or accessing private community data.
This vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. The attack vector leverages the Trust Relationship between users and the application's administrative interface, falling under MITRE ATT&CK technique T1059, specifically Command and Scripting Interpreter: JavaScript, used to execute arbitrary code within the victim's browser context. It also relates to CWE-862 for Missing Authorization, as the initial submission endpoint lacked proper access controls that would have prevented unauthenticated users from triggering the vulnerable rendering path by supplying an offender_id.
To mitigate this risk and prevent similar issues in future development, it is essential to implement strict output encoding rather than relying on raw rendering of user-supplied data. The application should utilize built-in templating engine features for automatic escaping or employ a robust sanitization library that whitelists safe HTML tags while stripping out script elements and event handlers. Additionally, the FeedbackMessagesController must enforce authentication checks before processing any feedback submissions, ensuring that only authorized personnel can submit reports with offender identifiers. Implementing Content Security Policy headers can also provide an additional layer of defense by restricting the sources from which scripts are allowed to execute, thereby mitigating the impact if a bypass occurs.