Privilege escalation via SSRF when using HTTP auth

The SSRF vulnerability in FreshRSS allows an attacker to craft malicious requests that the application will then forward to internal or external resources. Specifically, when FreshRSS is behind a reverse proxy using HTTP authentication, an attacker can leverage the Remote-User or X-WebAuth-User headers to impersonate any user. Successful exploitation requires the attacker to know the IP address of the proxied FreshRSS instance and the administrator's username, along with having an account on the instance. This could lead to unauthorized access to sensitive internal services and data, potentially compromising the entire system. The impact is amplified if the internal services accessed contain sensitive information or provide administrative functionality.

Organizations using FreshRSS behind a reverse proxy with HTTP authentication are at risk. This includes users of shared hosting environments where FreshRSS is deployed, as well as those with legacy configurations that do not properly validate HTTP headers.

• linux / server: Monitor access logs for requests containing suspicious Remote-User or X-WebAuth-User headers, particularly those originating from external sources.

grep -i 'Remote-User|X-WebAuth-User' /var/log/nginx/access.log | grep -v '127.0.0.1'

• generic web: Use curl to test the 'add feed' endpoint with a URL pointing to an internal service. Check the response headers for unexpected behavior.

curl -I 'http://your-freshrss-instance/add_feed?url=http://internal-service/'

1. 2025-06-04Disclosure

   disclosure

1. Gereserveerd2025-04-22
2. Gepubliceerd2025-06-04
3. EPSS bijgewerkt2026-03-23

The primary mitigation for CVE-2025-46341 is to upgrade FreshRSS to version 1.26.2 or later. If upgrading immediately is not feasible, consider implementing stricter HTTP header validation on the reverse proxy to prevent the injection of malicious Remote-User or X-WebAuth-User headers. Additionally, review and restrict access to internal services to minimize the potential impact of a successful SSRF attack. After upgrading, verify the fix by attempting to add a feed with a crafted URL designed to trigger the SSRF vulnerability; the request should be rejected.