rConfig's Redis queue became an unauthenticated code path
Network configuration management systems hold credentials for the devices they manage. They are high-value because a single login can reach routers, switches, firewalls, and the configuration history that explains how those devices were built. CVE-2026-124079 adds a second problem: in affected rConfig deployments, the job queue itself may be reachable without authentication.
The CVE record describes unsafe deserialization in rConfig Core before 8.2.19 and rConfig Pro before 8.4.1. An unauthenticated network attacker can push a crafted serialized job onto a Redis-backed Laravel Horizon queue. When a worker processes the job, the payload can result in arbitrary code execution. The vulnerability is not a browser-side trick that needs a logged-in administrator. It is an exposed internal control plane being treated as if it were safe because it sits behind the web application.
rConfig's documentation says Redis is used for the job queue, cache, and sessions. Its own security guidance recognizes that an installation with no Redis password needs optimization and provides a command to secure the service. That detail matters: the application-layer login is not a boundary for a Redis port that a separate network path can reach.
The attack path is architectural
Laravel Horizon provides a dashboard and queue workers for Redis-backed jobs. A worker deserializes job payloads so it can execute the PHP class and method named in the payload. That is normal design. It becomes dangerous when an untrusted network client can write arbitrary serialized data into the same queue or when application-side validation assumes every queued object came from a trusted producer.
The CVE description says the vulnerable deployments have an unauthenticated Redis-backed Horizon queue. An attacker therefore does not need to exploit a web form first. The queue becomes the entry point. Once code runs as the worker, the attacker inherits the worker's filesystem access, configuration files, database connections, and ability to launch further jobs. In a network automation product, those privileges can include device credentials.
This is why patch version alone is not the whole answer. rConfig may be behind a reverse proxy while the Redis service remains reachable through a container network, a cloud security-group mistake, or a shared internal VLAN. The application can be patched and still expose a powerful service to the wrong network.
Confirm the version and the listener
Inventory rConfig Core and Pro separately. The CVE names Core before 8.2.19 and Pro before 8.4.1, but the vendor advisory is the authority for the exact fixed build. Use the vendor's current security advisory rather than assuming that a neighboring version string is sufficient.
Then map Redis exposure. Check listeners, container port mappings, Kubernetes Services, ingress rules, firewall policy, and cloud load balancers. Determine whether authentication is enabled, whether TLS is required, and which hosts can open a connection. A Redis instance bound to localhost is materially different from one bound to a shared container interface.
Review Horizon access separately. The dashboard should be restricted to administrators and a management network. A queue dashboard that reveals failed jobs, payloads, and environment details can support reconnaissance even when it is not directly exploitable. Limit who can enqueue jobs and which job classes are allowed.
Detection and recovery
Look for unexpected Redis clients and unusually large or malformed job payloads. Correlate Redis connection logs with Horizon worker activity, PHP process creation, web-shell indicators, and changes to rConfig users or scheduled tasks. A queue compromise may leave little application-level evidence because the worker is executing commands it considers part of its normal function.
If compromise is suspected, stop the queue workers before clearing anything. Preserve Redis data and application logs, then rotate rConfig database credentials, API tokens, device credentials, and any cloud or SMTP secrets available to the worker. Review device configuration history for unauthorized changes, not only rConfig user activity.
Upgrade to the vendor-listed fixed release, enable Redis authentication, and place the queue on a private network that accepts connections only from the application and workers. Disable unneeded Horizon features and restrict the dashboard with both network policy and application authorization. Add a deployment test that attempts a Redis connection from an untrusted namespace and expects failure.
The deeper control is to stop treating a queue as an internal implementation detail. It is a write path into code execution. If Redis or Horizon is reachable by an untrusted party, the team has exposed an execution interface even when the web login remains closed.
Top comments (0)