What happened
rConfig is a network configuration management tool. It regularly logs in to routers, switches and firewalls, downloads their settings, keeps backups and can also run commands on those devices. It comes in two editions, rConfig Core and rConfig Pro.
On November 6, 2026, the vendor published security advisory rCFG-SA-2026-09, rated “Critical”. The flaw sits in the job queue that rConfig uses for background work, which is built on the Redis database and Laravel Horizon. Attackers can use it to run arbitrary commands on the server. The issue was reported through VulnCheck and appeared in the US National Vulnerability Database (NVD) as CVE-2026-124079 on November 9, 2026.
Fixed releases are available: rConfig Core 8.2.19 and rConfig Pro 8.4.1. At the time of writing, neither the vendor nor the US agency CISA has confirmed exploitation in the wild, and the flaw is not in CISA’s Known Exploited Vulnerabilities (KEV) catalog. The EU Vulnerability Database (EUVD) lists it as EUVD-2026-120037, also with no exploitation reported.
Why it is dangerous
This is a deserialization of untrusted data flaw (CWE-502). The application stores jobs in its queue as “packed” objects and later “unpacks” and runs them. Think of a mailroom that carries out any instruction in an envelope as long as the envelope looks official. Anyone who can slip their own envelope into the queue can tell the server to do anything.
According to VulnCheck, Redis runs without a password in affected deployments, so an attacker only needs network access to it and does not have to log in anywhere. Where Redis is not reachable from the network, a signed-in rConfig user can take a detour: they create a device whose address points back at the rConfig server itself. The vendor’s advisory describes exactly this signed-in user scenario.
VulnCheck says an attacker can run commands as the queue worker’s user, plant a persistent web shell (a hidden backdoor reachable over the web) and read database credentials, stored device passwords and API tokens. The vendor adds that on some installs this worker ran as root, meaning full control of the server. With stolen router and firewall passwords, an attacker could move further into the network.
The CVSS score rates severity on a scale up to ten. VulnCheck assigned 9.8 under CVSS 3.1 and 9.3 under the newer CVSS 4.0, both in the critical range. CISA’s KEV catalog lists flaws that are known to be exploited. This one is not on it yet, and no EPSS score, which estimates the likelihood of exploitation, has been published for it so far. Still, do not put off the fix.
Who is affected
The vendor and VulnCheck list these versions as affected:
- rConfig Core 8.0.0 through 8.2.18 (fixed in 8.2.19)
- rConfig Pro up to and including 8.4.0 (fixed in 8.4.1)
rConfig typically runs on a dedicated Linux server or in Docker inside the company network, often in the management segment from which it can reach routers, switches and firewalls. It is used by IT departments, network service providers and administrators who need configuration backups. The risk is highest where the web interface or Redis is reachable from the internet or from a wider network.
If you do not use rConfig, this flaw does not affect you. For Core, both the vendor and VulnCheck name 8.0.0 as the first affected version.
How to check if you are affected
The commands below change nothing, they only read. Run them on the server in the directory where rConfig is installed. If you installed it with git, the latest tag shows the version:
git describe --tagsA result of core-8.2.18 or older means a vulnerable version. To see the PHP version, which matters before you upgrade, run:
php -vCheck which addresses Redis listens on and whether it requires a password. ss needs root rights to show process names. If redis-cli ping answers PONG without a password, Redis has no authentication. If the local address column shows anything other than the loopback address, for example an asterisk or the server’s IP address, Redis is reachable from the network.
sudo ss -ltnp | grep -i redis
redis-cli pingThe next command shows which user Horizon runs as. If the first column says root, the process has full control of the server.
ps -eo user,cmd | grep -i horizonHow to fix it
The vendor calls 8.2.19 a security release and recommends it for all 8.x installations. On its security advisories page, it advises taking Core straight to 8.2.20 or later, because that release also fixes a separate flaw that could leak stored passwords through table export (rCFG-SA-2026-10). Upgrade Pro to 8.4.1 or later. The vendor says 8.4.2 is due shortly with further fixes.
- Back up the server or snapshot the virtual machine, including the rConfig database.
- Update PHP to at least 8.2.35, 8.3.36 or 8.4.27. Otherwise Composer will refuse the upgrade.
- For the first Core upgrade from 8.2.18 or earlier, run
git pullin the rConfig directory, thensudo ./update.sh --no-pull. After that,sudo ./update.shis the only upgrade command you need. - Confirm that Horizon no longer runs as root, using
php artisan rconfig:check-worker-useror the Worker Privilege check on the dashboard. - Rotate every secret stored in rConfig: REST API tokens, device and enable passwords, and SMTP, LDAP and RADIUS secrets. Review the user list and remove accounts you do not recognize.
The fix adds a password to Redis, stops Horizon and the scheduler from running as root, and blocks devices from targeting the rConfig server itself. Note the service changes: the Supervisor program is now called rconfig-core-horizon and the scheduler has moved to /etc/cron.d/rconfig-core.
The vendor does not list a separate workaround. If you cannot upgrade right away, as a general measure make sure Redis is not reachable from the network and requires a password, and limit access to the rConfig web interface to the management network or a VPN.
What if you may already be compromised
If your Redis or rConfig was reachable from the internet or a wider network while running a vulnerable version, assume an attacker may have obtained every stored password. Rotating secrets after the upgrade is therefore not optional.
- Check the
storage/app/publicdirectory of your rConfig installation. VulnCheck says attackers can drop a web shell there. Be especially wary of.phpfiles you did not put there. - Look through the device list for entries whose address points at the rConfig server itself, for example
localhostor another loopback address. - Review users both in rConfig and in the operating system for accounts you do not recognize.
- On your network devices, look for recent configuration changes and logins that do not match your team’s work.
find storage/app/public -name "*.php" -lsIf you find anything suspicious, upgrading alone is not enough. Disconnect the server from the network, preserve the logs and bring in an incident response specialist. If the queue worker ran as root, a possible attacker could have had full control of the server, so make the review all the more thorough. You can also contact the vendor at [email protected].