Summary

When the server is using HTTP auth via reverse proxy, it's possible to impersonate any user either via the Remote-User header or the X-WebAuth-User header by making specially crafted requests via the add feed functionality and obtaining the CSRF token via XPath scraping

Details

The attacker has to know the IP address of the proxied FreshRSS instance and the admin's username, while also having an account on the instance.
An example server configuration that is vulnerable to the attack is running Authentik where the Proxy provider is being used, with the Remote-User or X-WebAuth-User header being passed to the FreshRSS instance.
Note that the IP address under which the FreshRSS instance is running must be included in the TRUSTED_PROXY environment variable.
This happens when both Authentik and FreshRSS are running under Docker.

PoC

Let's say that the proxy is running under the http://192.168.91.132:80 URL, and the FreshRSS instance is at http://192.168.91.132:8080
An external attacker wouldn't be able to spoof the Remote-User header from their IP address, because it is not included in the TRUSTED_PROXY environment variable.
However, the FreshRSS instance IP address is, so those are the following steps that have to be taken:

First, let's obtain the CSRF token as such, assuming that the admin user is akadmin:
(xpath is //*[@id="mark-read-aside"]/input/@value)

Now, this is what we'll see in our feed if we haven't gotten an error:

Now, all we have to do is promote ourselves using the CSRF token:
used URL is http://192.168.91.132:8080/i/?c=user&a=manage&username=example and xpath is //*[@id="dialogMsg"]
POST body is _csrf=[token]&action=promote

We'll observe that we're admin now after sending the request:

Impact

An attacker can send specially crafted requests in order to gain unauthorized access to internal services. This can also lead to privilege escalation like in the demonstrated scenario, although users that have setup OIDC are not affected by privilege escalation.