rConfig: RCE mediante la cola de trabajos Redis (CVE-2026-124079)

Resumen

• rConfig Core 8.0.0 a 8.2.18 y Pro antes de 8.4.1 deserializan trabajos de una cola Horizon respaldada por Redis, por lo que un trabajo manipulado puede ejecutar código como el worker. VulnCheck publicó CVE-2026-124079 el 2026-11-09.
• Un atacante directo necesita un Redis accesible sin contraseña. Un usuario autenticado también puede apuntar un dispositivo a la dirección de loopback del servidor rConfig y escribir en la misma cola, como describe el aviso del proveedor.
• VulnCheck le asigna CVSS v3.1 9.8 Crítica y CVSS v4.0 9.3 Crítica. No se conoce explotación y no está en el catálogo KEV de CISA a fecha de 2026-11-09.
• Actualice Core a 8.2.19 o posterior y Pro a 8.4.1 o posterior. Rote los secretos almacenados después de la actualización; "¿Cómo lo corrijo?" cubre los controles provisionales.

¿Estoy afectado?

Todas estas condiciones deben cumplirse:

• Ejecuta rConfig Core 8.0.0 a 8.2.18, o rConfig Pro antes de 8.4.1.
• El despliegue usa el controlador de cola Redis con Laravel Horizon, que es el valor predeterminado de estas versiones.
• O bien Redis es accesible desde una red no confiable sin contraseña, o un atacante puede iniciar sesión y añadir o editar un dispositivo.

El proveedor incluye Core 8.2.18 como afectado aunque 8.2.18 añadió una lista de permitidos al trabajo TaskDownloadRun. La lista de permitidos cerró la inyección directa de argumentos de Artisan en ese trabajo. La cola siguió sin autenticación y un dispositivo todavía podía apuntar a la dirección de loopback del servidor. Core 8.2.19 es la primera versión que el proveedor indica como corregida.

Compruebe la versión instalada:

cat /var/www/html/rconfig/VERSION
# Docker:
docker exec rconfig_app cat /var/www/html/rconfig/VERSION

Compruebe si Redis exige una contraseña. Ejecute este comando en el host de rConfig:

grep -E '^REDIS_(HOST|PORT|PASSWORD)=' /var/www/html/rconfig/.env
redis-cli -h 127.0.0.1 -p 6379 ping

PONG significa que Redis aceptó la solicitud sin contraseña. NOAUTH significa que se requiere una contraseña. Si la respuesta es PONG y el puerto 6379 es accesible desde una red no confiable, la ruta directa está abierta.

Busque dispositivos que apunten al propio servidor:

mysql -u rconfig_user -p rconfig -e "
SELECT id, device_name, device_ip, device_port_override
FROM devices
WHERE device_ip IN ('127.0.0.1','localhost','::1','0.0.0.0')
   OR device_ip LIKE '127.%'
   OR device_ip LIKE '::ffff:127.%';"

¿Cómo lo corrijo?

Actualice Core a 8.2.19 o posterior. La versión 8.2.20 es la actual y también corrige la divulgación de credenciales mediante exportación de tablas, rCFG-SA-2026-10. Los usuarios de Pro deben actualizar a 8.4.1 o posterior; el proveedor indica que 8.4.2 está prevista en breve.

1. Para una instalación Core que se actualiza desde 8.2.18 o anterior, ejecute la secuencia de primera actualización del proveedor:

cd /var/www/html/rconfig
git pull
sudo ./update.sh --no-pull

1. Después de esa primera actualización, el único comando de actualización es:

sudo ./update.sh

1. Para Docker, fije la versión de la imagen en .env y luego descargue y recree el contenedor:

sed -i 's/^RCONFIG_VERSION=.*/RCONFIG_VERSION=8.2.20/' .env
docker compose pull
docker compose up -d

Las imágenes 8.2.19 y posteriores ejecutan Redis dentro del contenedor de la aplicación y generan su contraseña en el primer arranque.

1. Para Pro, siga las instrucciones de actualización de Pro del proveedor hasta 8.4.1 o posterior.

Si no puede actualizar ahora, aplique los dos controles que puede reproducir en 8.2.18. Primero, ponga una contraseña en Redis. El comando de 8.2.19 es php artisan rconfig:redis-secure, pero no existe en 8.2.18. En 8.2.18, aplique el mismo control manualmente, adaptado del servicio RedisSecurityService del proveedor:

SECRET=$(openssl rand -hex 32)
redis-cli -h 127.0.0.1 -p 6379 CONFIG SET requirepass "$SECRET"
redis-cli -h 127.0.0.1 -p 6379 -a "$SECRET" --no-auth-warning CONFIG REWRITE
sed -i "s/^REDIS_PASSWORD=.*/REDIS_PASSWORD=$SECRET/" /var/www/html/rconfig/.env
cd /var/www/html/rconfig
php artisan config:clear
php artisan horizon:terminate

La señal horizon:terminate hace que Supervisor reinicie Horizon con la nueva contraseña. Si ejecuta el planificador por separado, reinícielo también.

Después, limite la edición de dispositivos a administradores de confianza hasta que actualice. La interfaz de 8.2.18 todavía acepta una dirección de dispositivo 127.0.0.1 o localhost. La ruta de loopback sigue abierta a cualquier cuenta que pueda añadir o editar un dispositivo.

Mantenga Redis en loopback o en una red privada y filtre el puerto 6379. Eso reduce la ruta directa, pero no cierra la ruta de loopback.

Después de actualizar, rote los secretos que el worker podía leer. El aviso del proveedor enumera los tokens de la API REST, las contraseñas de dispositivos y de enable, y los secretos SMTP, LDAP y RADIUS. Revise la lista de usuarios por si hay cuentas que no reconoce.

¿Cuál es la causa raíz?

La cola está respaldada por Redis mediante Laravel Horizon, y Redis no tenía contraseña por defecto. El CallQueuedHandler de Laravel deserializa la carga útil del trabajo sin una lista de clases permitidas. Un trabajo que nombra una clase con un método handle() peligroso ejecuta ese método.

El trabajo TaskDownloadRun incluido era una de esas clases: antes de 8.2.18 pasaba sus campos serializados task_command e id directamente a Artisan::call().

En la etiqueta 8.2.18, config/database.php líneas 121 a 126 define la contraseña de Redis desde REDIS_PASSWORD con null por defecto:

'default' => [
    'host' => env('REDIS_HOST', '127.0.0.1'),
    'password' => env('REDIS_PASSWORD', null),
    'port' => env('REDIS_PORT', 6379),
    'database' => env('REDIS_DB', 0),
],

El archivo .env.example incluye REDIS_PASSWORD=null. Por lo tanto, una instalación predeterminada se conecta a Redis sin autenticación.

En la etiqueta 8.2.17, app/Jobs/TaskDownloadRun.php línea 32 pasaba los campos serializados del trabajo a Artisan:

Artisan::call($this->task['task_command'] . ' ' . $this->task['id']);

Las propiedades del trabajo viajan dentro de la carga útil de la cola. Un atacante que puede escribir en la cola controla task_command e id, por lo que el worker ejecuta cualquier comando de Artisan, incluido tinker.

El registro de cambios de 8.2.18 describe la corrección con sus propias palabras. Indica que TaskDownloadRun pasaba el comando y el identificador de sus propias propiedades serializadas directamente a Artisan::call(), por lo que una carga útil manipulada podía ejecutar cualquier comando de Artisan.

La versión 8.2.18 añadió una lista de permitidos en app/Jobs/TaskDownloadRun.php líneas 58 a 78:

$command = is_string($this->task['task_command'] ?? null) ? $this->task['task_command'] : '';

if (! in_array($command, self::ALLOWED_TASK_COMMANDS, true)) {
    Log::warning('TaskDownloadRun rejected an unexpected task command.', [
        'task_command' => $command,
    ]);

    return;
}

if (! is_numeric($this->task['id'] ?? null)) {
    Log::warning('TaskDownloadRun rejected a non-numeric task id.', [
        'id' => $this->task['id'] ?? null,
    ]);

    return;
}

$taskId = (int) $this->task['id'];

Artisan::call(self::RUN_COMMAND, ['taskid' => [$taskId]]);

Esa lista de permitidos cerró la inyección directa de argumentos de Artisan en este trabajo. No cerró la cola en sí, y no impidió que un dispositivo apuntara al servidor. El proveedor incluye 8.2.18 como afectado y corrigió las rutas restantes en 8.2.19.

La segunda ruta es el destino del dispositivo. En la etiqueta 8.2.19, app/Rules/DeviceIpIsValid.php líneas 29 a 36 rechazan un dispositivo que apunta al servidor:

if ($this->pointsAtThisServer($value)) {
    $fail('The :attribute cannot point at this rConfig server (loopback, localhost or its Redis host).');
}

/**
 * A device is something rConfig connects out to from its own server, so a device on
 * loopback lets device editors make rConfig write into its own Redis. See RCO-1813.
 */

La regla se aplica a device_ip tanto al crear como al actualizar un dispositivo en app/Http/Requests/StoreDeviceRequest.php líneas 56 y 71. La conexión Telnet abre un socket TCP sin procesar con fsockopen($this->hostname, $this->port), y Send::sendString() escribe $command . "\r\n" en él. Un dispositivo en 127.0.0.1 en el puerto 6379 convierte la descarga del dispositivo en un escritor TCP sin procesar hacia Redis.

El código de corrección del proveedor declara el riesgo en app/Services/Utilities/RedisSecurityService.php. Indica que Core ejecuta workers de Horizon que deserializan cargas útiles de la cola. Un Redis sin autenticación en el que cualquier proceso local puede escribir es una ruta de ejecución de código.

El impacto era mayor en instalaciones nativas porque el worker de la cola se ejecutaba como root. En la etiqueta 8.2.18, horizon_supervisor.ini define user=root:

[program:horizon]
process_name=%(program_name)s
command=php /var/www/html/rconfig/artisan horizon
autostart=true
autorestart=true
user=root

La versión 8.2.19 lo cambia a user=RCONFIG_WEB_USER, por lo que un futuro fallo de la cola ya no se ejecuta con todos los derechos del sistema.

¿Cómo se explota?

1. Llegar a la cola. Si Redis es accesible sin contraseña, el atacante se conecta directamente al puerto 6379.
2. Usar la ruta del dispositivo si Redis solo está en loopback. El atacante inicia sesión y crea o edita un dispositivo con device_ip establecido en 127.0.0.1, localhost, ::1 o 0.0.0.0, y device_port_override establecido en 6379.
3. Escribir un trabajo. La conexión del dispositivo abre un socket TCP hacia el objetivo y escribe la cadena de comando. Apuntado a Redis, el mismo socket acepta el comando de Redis que empuja un trabajo serializado de Laravel a la cola de Horizon.
4. El worker lo deserializa. El CallQueuedHandler de Horizon deserializa la carga útil y llama al método handle() del trabajo. La carga útil puede nombrar TaskDownloadRun u otra clase con un manejador peligroso.
5. El trabajo se ejecuta. En versiones anteriores a 8.2.18, TaskDownloadRun ejecuta el comando de Artisan del atacante. En 8.2.18, la lista de permitidos de ese trabajo bloquea el comando directo, pero la cola sigue deserializando otras clases y la ruta de loopback permanece. El paquete laravel/tinker incluido convierte un comando de Artisan en comandos PHP y del sistema operativo arbitrarios.
6. El atacante persiste. La descripción de la CVE registra un shell web en storage/app/public, además de credenciales de base de datos, credenciales de dispositivos almacenadas y tokens de API.

No hay una prueba de concepto pública enlazada desde el aviso ni desde el registro de la CVE a fecha de 2026-11-09. Estos pasos describen el mecanismo que documentan las fuentes; no son un exploit funcional.

¿Cómo se desarrolla el ataque?

Un atacante que puede llegar a la cola de Redis, directamente o mediante un dispositivo en loopback, escribe un trabajo serializado que Horizon deserializa y ejecuta como el worker.

¿Qué puede hacer un atacante?

El atacante ejecuta código como el worker. En las instalaciones nativas que usaban el stub de supervisor de 8.2.18, ese usuario era root. En la imagen de Docker, el worker se ejecuta como www-data.

Las condiciones de impacto son:

• El acceso directo a Redis requiere que el puerto de Redis sea accesible desde la red del atacante y que no tenga contraseña.
• La ruta de loopback requiere una cuenta de rConfig autenticada que pueda crear o editar un dispositivo.
• El worker de la cola debe ejecutar Horizon, que es el valor predeterminado de las versiones afectadas.

Con la ejecución de código, la descripción de la CVE registra estas capacidades:

• Escribir un shell web persistente en el directorio storage/app/public servido por la web.
• Leer credenciales de base de datos y tokens de API.
• Leer las credenciales de dispositivos almacenadas para los dispositivos de red que gestiona rConfig.

No se conoce explotación en entornos reales, y la CVE no está en el catálogo KEV de CISA a fecha de 2026-11-09.

¿Por qué funciona la corrección?

La corrección cierra las dos rutas hacia la cola y reduce el impacto de cualquier futuro fallo de la cola. El aviso del proveedor indica Core 8.2.19 y Pro 8.4.1 como versiones corregidas.

El primer cambio rechaza los destinos de dispositivo que apuntan al loopback o al host de Redis del servidor. El diff de 8.2.19 añade pointsAtThisServer() a la regla DeviceIpIsValid existente:

@@ -22,7 +22,48 @@
         // Check if it's a valid IP address or hostname/FQDN
         if (! $this->isValidIpAddress($value) && ! $this->isValidHostname($value)) {
             $fail('The :attribute must be a valid IP address or FQDN/Hostname.');
+
+            return;
+        }
+
+        if ($this->pointsAtThisServer($value)) {
+            $fail('The :attribute cannot point at this rConfig server (loopback, localhost or its Redis host).');
+        }
+    }
+
+    /**
+     * A device is something rConfig connects out to from its own server, so a device on
+     * loopback lets device editors make rConfig write into its own Redis. See RCO-1813.
+     */
+    private function pointsAtThisServer(string $value): bool
+    {
+        $host = strtolower(rtrim($value, '.'));
+
+        if ($host === 'localhost' || str_ends_with($host, '.localhost')) {
+            return true;
+        }
+
+        if ($host === strtolower((string) config('database.redis.default.host'))) {
+            return true;
+        }
+
+        $packed = @inet_pton($host);
+
+        if ($packed === false) {
+            return false;
+        }
+
+        // IPv4-mapped IPv6 (::ffff:127.0.0.1) reaches the same IPv4 address.
+        if (strlen($packed) === 16 && str_starts_with($packed, str_repeat("\0", 10) . "\xff\xff")) {
+            $packed = substr($packed, 12);
+        }
+
+        if (strlen($packed) === 4) {
+            // 127.0.0.0/8 is loopback, and Linux routes a connect to 0.0.0.0 to the local host.
+            return $packed[0] === "\x7f" || $packed === "\0\0\0\0";
+        }
+
+        return $packed === inet_pton('::1') || $packed === inet_pton('::');
     }

La regla ahora rechaza localhost, el host de Redis configurado, todas las direcciones de 127.0.0.0/8, 0.0.0.0, ::1, :: y las formas IPv6 mapeadas de IPv4. La ruta de loopback autenticada queda cerrada.

El segundo cambio pone una contraseña en Redis. El nuevo comando rconfig:redis-secure llama a RedisSecurityService::secure(), que genera un secreto de 32 bytes, escribe REDIS_PASSWORD en .env y lo exige en el servidor activo:

$this->makeClient($current)->executeRaw(['CONFIG', 'SET', 'requirepass', $secret]);

Después ejecuta CONFIG REWRITE para que la contraseña sobreviva a un reinicio, y reinicia los consumidores de la cola. El instalador y el punto de entrada de Docker generan la misma contraseña en instalaciones nuevas. La ruta directa sin autenticación queda cerrada.

El tercer cambio ejecuta Horizon y el planificador como el usuario web. El archivo horizon_supervisor.ini de 8.2.19 sustituye user=root por user=RCONFIG_WEB_USER, y las notas de la versión indican que los servicios ya no se ejecutan como root. Si aparece otro fallo de la cola, el worker ya no tiene todos los derechos del sistema.

El aviso del proveedor indica 8.2.19 y 8.4.1 como versiones corregidas para esta CVE.

¿Cómo compruebo si estuve comprometido?

No se publican indicadores de compromiso públicos para CVE-2026-124079. Estas comprobaciones buscan las dos rutas de acceso y la persistencia que registra la descripción de la CVE.

Compruebe si Redis está abierto y qué hay en la cola:

redis-cli -h 127.0.0.1 -p 6379 ping
redis-cli -h 127.0.0.1 -p 6379 --scan --pattern '*horizon*'
redis-cli -h 127.0.0.1 -p 6379 --scan --pattern '*queues*'

Si Redis exige una contraseña, añada -a "$REDIS_PASSWORD" --no-auth-warning a cada comando. El escaneo lista las claves de la cola. Inspeccione cualquier clave de lista que devuelva con lrange <key> 0 -1. Una cola vacía es normal. Una carga útil serializada que nombra una clase inesperada es una pista que investigar.

Busque dispositivos que apunten al servidor:

mysql -u rconfig_user -p rconfig -e "
SELECT id, device_name, device_ip, device_port_override, created_at
FROM devices
WHERE device_ip IN ('127.0.0.1','localhost','::1','0.0.0.0')
   OR device_ip LIKE '127.%'
   OR device_ip LIKE '::ffff:127.%';"

Busque un shell web PHP en el directorio de almacenamiento público:

find /var/www/html/rconfig/storage/app/public -type f -name '*.php' -printf '%TY-%Tm-%Td %TH:%TM %p\n'
grep -rIl '<?php' /var/www/html/rconfig/storage/app/public

Las cargas legítimas de rConfig no necesitan un archivo PHP en storage/app/public. Trate cualquier archivo PHP allí como sospechoso y compárelo con una copia de seguridad de confianza.

Revise los registros de la aplicación y de la cola en busca de trabajos rechazados o comandos de Artisan inesperados:

grep -i 'TaskDownloadRun rejected' /var/www/html/rconfig/storage/logs/laravel.log
grep -iE 'tinker|artisan' /var/www/html/rconfig/storage/logs/laravel.log /var/www/html/rconfig/storage/logs/horizon.log

Un trabajo rechazado significa que alguien envió un comando inesperado. Un hallazgo puede ser un intento fallido en lugar de un compromiso. No existen indicadores públicos, por lo que un intento fallido puede no dejar rastro.

Cronología

• 2026-10-08: se publica rConfig Core 8.2.18 con una lista de permitidos en TaskDownloadRun, una corrección parcial de la inyección de argumentos de Artisan.
• 2026-10-27: se publica rConfig Core 8.2.19 con autenticación de Redis, workers de cola sin root y el bloqueo de dispositivos en loopback.
• 2026-11-06: rConfig publica el aviso rCFG-SA-2026-09 para esta CVE y la versión Core 8.2.20, que también corrige rCFG-SA-2026-10, la divulgación de credenciales mediante exportación de tablas.
• 2026-11-09: VulnCheck publica CVE-2026-124079 y acredita a komi Sergio Hognaglo (manasse).

La diferencia entre la corrección parcial de 8.2.18 y la publicación de la CVE fue de 32 días.

Preguntas frecuentes

¿Se explota CVE-2026-124079 en entornos reales?

No se conoce explotación. Ni el aviso del proveedor ni el de VulnCheck informan de ataques, y la CVE no está en el catálogo KEV de CISA a fecha de 2026-11-09.

¿Afecta el fallo a rConfig Pro?

Sí. rConfig Pro antes de 8.4.1 está afectado, y el proveedor lo corrigió en 8.4.1. El proveedor indica que 8.4.2 está prevista en breve con más correcciones.

¿Está corregido Core 8.2.18?

No. Core 8.2.18 añadió una lista de permitidos al trabajo TaskDownloadRun, pero el proveedor incluye 8.2.18 como afectado. Core 8.2.19 es la primera versión que el proveedor indica como corregida.

¿Está expuesta mi instalación si Redis solo está en loopback?

Puede estarlo. Un usuario autenticado que pueda añadir o editar un dispositivo puede apuntar ese dispositivo a 127.0.0.1 en el puerto 6379, y rConfig se conecta a los destinos de los dispositivos. Si la edición de dispositivos está limitada a administradores de confianza y Redis tiene contraseña, la exposición es menor, pero la actualización sigue siendo la corrección.

¿Qué secretos debo rotar?

Rote los tokens de la API REST, las contraseñas almacenadas de dispositivos y de enable, y los secretos SMTP, LDAP y RADIUS. El aviso del proveedor también pide revisar la lista de usuarios por si hay cuentas que no reconoce.

¿Puede un firewall sustituir la actualización?

No. Un firewall o una vinculación de Redis solo a loopback reduce la ruta directa, pero no cierra la ruta de loopback del dispositivo. Aplique la contraseña de Redis y limite la edición de dispositivos hasta que actualice.

Encuentre servidores rConfig expuestos con Ostorlab

El descubrimiento de superficie de ataque de Ostorlab inventaría los hosts expuestos a Internet, para que pueda encontrar las instancias de rConfig que no deberían ser accesibles y corregirlas primero. Empiece en ostorlab.co/product/attacksurface_discovery.

Referencias

• VulnCheck, "rConfig Core 8.0.0 before 8.2.19 and rConfig Pro before 8.4.1 RCE via Unauthenticated Redis Queue Poisoning", https://www.vulncheck.com/advisories/rconfig-core-before-and-rconfig-pro-before-rce-via-unauthenticated-redis-queue-poisoning (verificado el 9 de noviembre de 2026).
• CVE Program, "CVE-2026-124079", https://www.cve.org/CVERecord?id=CVE-2026-124079 (verificado el 9 de noviembre de 2026).
• rConfig, "Security Advisories & Vulnerability Disclosures", https://www.rconfig.com/security-advisories (verificado el 9 de noviembre de 2026).
• rConfig, "rConfig V8 Core 8.2.19", https://github.com/rconfig/rconfig/releases/tag/core-8.2.19 (verificado el 9 de noviembre de 2026).
• rConfig, "rConfig V8 Core 8.2.20", https://github.com/rconfig/rconfig/releases/tag/core-8.2.20 (verificado el 9 de noviembre de 2026).
• rConfig, "CHANGELOG.md at core-8.2.19", https://github.com/rconfig/rconfig/blob/core-8.2.19/CHANGELOG.md (verificado el 9 de noviembre de 2026).
• rConfig, "app/Jobs/TaskDownloadRun.php at core-8.2.17", https://github.com/rconfig/rconfig/blob/core-8.2.17/app/Jobs/TaskDownloadRun.php (verificado el 9 de noviembre de 2026).
• rConfig, "app/Jobs/TaskDownloadRun.php at core-8.2.18", https://github.com/rconfig/rconfig/blob/core-8.2.18/app/Jobs/TaskDownloadRun.php (verificado el 9 de noviembre de 2026).
• rConfig, "app/Rules/DeviceIpIsValid.php at core-8.2.19", https://github.com/rconfig/rconfig/blob/core-8.2.19/app/Rules/DeviceIpIsValid.php (verificado el 9 de noviembre de 2026).
• rConfig, "app/Http/Requests/StoreDeviceRequest.php at core-8.2.19", https://github.com/rconfig/rconfig/blob/core-8.2.19/app/Http/Requests/StoreDeviceRequest.php (verificado el 9 de noviembre de 2026).
• rConfig, "config/database.php at core-8.2.18", https://github.com/rconfig/rconfig/blob/core-8.2.18/config/database.php (verificado el 9 de noviembre de 2026).
• rConfig, "app/Services/Utilities/RedisSecurityService.php at core-8.2.19", https://github.com/rconfig/rconfig/blob/core-8.2.19/app/Services/Utilities/RedisSecurityService.php (verificado el 9 de noviembre de 2026).
• rConfig, "horizon_supervisor.ini at core-8.2.18", https://github.com/rconfig/rconfig/blob/core-8.2.18/horizon_supervisor.ini (verificado el 9 de noviembre de 2026).
• rConfig, "horizon_supervisor.ini at core-8.2.19", https://github.com/rconfig/rconfig/blob/core-8.2.19/horizon_supervisor.ini (verificado el 9 de noviembre de 2026).
• rConfig, "app/Http/Controllers/Connections/Telnet/Connect.php at core-8.2.18", https://github.com/rconfig/rconfig/blob/core-8.2.18/app/Http/Controllers/Connections/Telnet/Connect.php (verificado el 9 de noviembre de 2026).
• rConfig, "app/Http/Controllers/Connections/Telnet/Send.php at core-8.2.18", https://github.com/rconfig/rconfig/blob/core-8.2.18/app/Http/Controllers/Connections/Telnet/Send.php (verificado el 9 de noviembre de 2026).
• CISA, "Known Exploited Vulnerabilities Catalog", https://www.cisa.gov/known-exploited-vulnerabilities-catalog (verificado el 9 de noviembre de 2026).
• rConfig, "rconfig/rconfig on GitHub", https://github.com/rconfig/rconfig (verificado el 9 de noviembre de 2026).
• Docker Hub, "rconfig/rconfig", https://hub.docker.com/r/rconfig/rconfig (verificado el 9 de noviembre de 2026).