Impact
An accepted node could download the policies of other nodes (when knowing their Rudder node id) managed by the same server or relay. This bug is present since Rudder 4.2. Policies should not contain secrets but can still contain sensitive information about the applied configuration.
In particular, when having relays, it is possible to enumerate other nodes managed from the relay by fetching the relay's policies.
Exploitation logs
You can check the server's and relay's Apache httpd logs for exploitation traces using this script:
Checking /var/log/rudder/apache2/access.log
Found line, node 222f83f2-502c-4bc8-9039-0aeb7ad487e6 downloading policies for 23952265-30bc-4d15-83f4-dc22ac045878:
> 192.168.215.131 - 222f83f2-502c-4bc8-9039-0aeb7ad487e6 [30/Oct/2025:01:43:46 +0100] "GET /policies/23952265-30bc-4d15-83f4-dc22ac045878/rules/rudder.tar.bz2 HTTP/1.1" 200 87866 "-" "curl/7.88.1"
Found suspicious line, node 222f83f2-502c-4bc8-9039-0aeb7ad487e6 downloading policies for 23952265-30bc-4d15-83f4-dc22ac045878:
> 192.168.215.131 - 222f83f2-502c-4bc8-9039-0aeb7ad487e6 [30/Oct/2025:08:32:15 +0100] "GET /policies/23952265-30bc-4d15-83f4-dc22ac045878/rules/rudder.tar.bz2 HTTP/1.1" 200 87866 "-" "curl/7.88.1"
Found suspicious line, node 222f83f2-502c-4bc8-9039-0aeb7ad487e6 downloading policies for 23952265-30bc-4d15-83f4-dc22ac045878:
> 192.168.215.131 - 222f83f2-502c-4bc8-9039-0aeb7ad487e6 [30/Oct/2025:08:33:02 +0100] "GET /policies/23952265-30bc-4d15-83f4-dc22ac045878/rules/cfengine-community/run_interval HTTP/1.1" 200 2111 "-" "curl/7.88.1"
Checking /var/log/rudder/apache2/access.log.1
Checking /var/log/rudder/apache2/access.log.10.gz
Workarounds
Replace the affected configuration file with the patched version on all the servers and relays. It will be automatically updated on the next Rudder upgrade, there is nothing to do.
For Rudder 8.3 (& 8.2)
On all Rudder 8.3 servers and relays:
- put the patched rudder-apache-relay-ssl.conf into
/opt/rudder/etc/rudder-apache-relay-ssl.conf
- restart the
apache2/httpd service to apply the change
Note: Rudder 8.2 is now unmaintained, but the patch works as well.
For Rudder 9.0
On all Rudder 9.0 servers and relays:
- put the patched rudder-apache-relay-ssl.conf.j2 into
/opt/rudder/etc/rudder-apache-relay-ssl.conf.j2
- run the agent with
rudder agent run to apply the change
Cause
The problem comes from an incorrect ACL in the HTTPS policy download configuration. The configuration files are served from /var/rudder/share/{node_id}/, and its access is controlled by a RewriteRule which redirects the URL to the actual files when the ID in the certificate (that needs to be accepted in the inventory) matches the required policies:
RewriteCond "%{SSL:SSL_CLIENT_S_DN_UID}=$1" "^(.*?)=\1"
RewriteRule /policies/(.*?)/(.*) /var/rudder/share/$1/$2
As the policies are lacking a SSLVerifyClient at the virtual host level, the client certificate is not read and SSL_CLIENT_S_DN_UID is always empty. And due to a missing $ anchor in the regex, the RewriteCond guarding the access is defined when the variable is empty, leading to a bypass of the ACL:
[Wed Oct 29 22:11:18.072897 2025] [rewrite:trace4] [pid 64704:tid 64722] mod_rewrite.c(4305): [client 192.168.2.3:59478] 192.168.2.3 - - [server/sid#7f5c26168a08][rid#7f5c242290a0/initial] RewriteCond: input='=18c3a1a6-2dad-40eb-a1dd-2fb04a070d94' pattern='^(.*?)=\\1' => matched
The policies directory configuration has a SSLVerifyClient require option, but it comes too late and only enforces the validity of the certificate against the list of accepted nodes. This means that the only applied controls are the allowed networks restrictions and the validity of the certificate (which makes the download only possible with an accepted node's key & certificate).
Patches
References
Impact
An accepted node could download the policies of other nodes (when knowing their Rudder node id) managed by the same server or relay. This bug is present since Rudder 4.2. Policies should not contain secrets but can still contain sensitive information about the applied configuration.
In particular, when having relays, it is possible to enumerate other nodes managed from the relay by fetching the relay's policies.
Exploitation logs
You can check the server's and relay's Apache httpd logs for exploitation traces using this script:
Workarounds
Replace the affected configuration file with the patched version on all the servers and relays. It will be automatically updated on the next Rudder upgrade, there is nothing to do.
For Rudder 8.3 (& 8.2)
On all Rudder 8.3 servers and relays:
/opt/rudder/etc/rudder-apache-relay-ssl.confapache2/httpdservice to apply the changeNote: Rudder 8.2 is now unmaintained, but the patch works as well.
For Rudder 9.0
On all Rudder 9.0 servers and relays:
/opt/rudder/etc/rudder-apache-relay-ssl.conf.j2rudder agent runto apply the changeCause
The problem comes from an incorrect ACL in the HTTPS policy download configuration. The configuration files are served from
/var/rudder/share/{node_id}/, and its access is controlled by aRewriteRulewhich redirects the URL to the actual files when the ID in the certificate (that needs to be accepted in the inventory) matches the required policies:As the policies are lacking a
SSLVerifyClientat the virtual host level, the client certificate is not read andSSL_CLIENT_S_DN_UIDis always empty. And due to a missing$anchor in the regex, theRewriteCondguarding the access is defined when the variable is empty, leading to a bypass of the ACL:The policies directory configuration has a
SSLVerifyClient requireoption, but it comes too late and only enforces the validity of the certificate against the list of accepted nodes. This means that the only applied controls are the allowed networks restrictions and the validity of the certificate (which makes the download only possible with an accepted node's key & certificate).Patches
References