rConfig : RCE via la file d'attente Redis (CVE-2026-124079)

En bref

• rConfig Core 8.0.0 à 8.2.18 et Pro avant 8.4.1 désérialisent les tâches d'une file d'attente Horizon adossée à Redis, donc une tâche forgée peut exécuter du code en tant que worker. VulnCheck a publié CVE-2026-124079 le 2026-11-09.
• Un attaquant direct a besoin d'un Redis joignable sans mot de passe. Un utilisateur connecté peut aussi pointer un équipement vers l'adresse de bouclage du serveur rConfig et écrire dans la même file, comme le décrit l'avis du fournisseur.
• VulnCheck le note CVSS v3.1 9,8 Critique et CVSS v4.0 9,3 Critique. Aucune exploitation n'est connue, et il n'est pas dans le catalogue KEV de la CISA au 2026-11-09.
• Mettez à niveau Core vers 8.2.19 ou plus et Pro vers 8.4.1 ou plus. Renouvelez les secrets stockés après la mise à niveau ; « Comment corriger ? » couvre les contrôles intermédiaires.

Suis-je concerné ?

Toutes ces conditions doivent être réunies :

• Vous exécutez rConfig Core 8.0.0 à 8.2.18, ou rConfig Pro avant 8.4.1.
• Le déploiement utilise le pilote de file d'attente Redis avec Laravel Horizon, qui est la valeur par défaut de ces versions.
• Soit Redis est joignable depuis un réseau non fiable sans mot de passe, soit un attaquant peut se connecter et ajouter ou modifier un équipement.

Le fournisseur liste Core 8.2.18 comme affecté même si 8.2.18 a ajouté une liste d'autorisation à la tâche TaskDownloadRun. La liste d'autorisation a fermé l'injection directe d'arguments Artisan dans cette tâche. La file d'attente est restée sans authentification, et un équipement pouvait encore pointer vers l'adresse de bouclage du serveur. Core 8.2.19 est la première version que le fournisseur liste comme corrigée.

Vérifiez la version installée :

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

Vérifiez si Redis exige un mot de passe. Exécutez cette commande sur l'hôte rConfig :

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

PONG signifie que Redis a accepté la requête sans mot de passe. NOAUTH signifie qu'un mot de passe est requis. Si la réponse est PONG et que le port 6379 est joignable depuis un réseau non fiable, le chemin direct est ouvert.

Trouvez les équipements pointant vers le serveur lui-même :

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.%';"

Comment corriger ?

Mettez à niveau Core vers 8.2.19 ou plus. La version 8.2.20 est la version actuelle et corrige aussi la divulgation d'identifiants par export de table, rCFG-SA-2026-10. Les utilisateurs de Pro passent à 8.4.1 ou plus ; le fournisseur indique que 8.4.2 est attendue prochainement.

1. Pour une installation Core mise à niveau depuis 8.2.18 ou antérieure, exécutez la séquence de première mise à niveau du fournisseur :

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

1. Après cette première mise à niveau, la commande de mise à niveau unique est :

sudo ./update.sh

1. Pour Docker, épinglez la version de l'image dans .env, puis tirez et recréez le conteneur :

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

Les images 8.2.19 et ultérieures exécutent Redis dans le conteneur applicatif et génèrent son mot de passe au premier démarrage.

1. Pour Pro, suivez les instructions de mise à niveau Pro du fournisseur vers 8.4.1 ou plus.

Si vous ne pouvez pas mettre à niveau maintenant, appliquez les deux contrôles que vous pouvez reproduire sur 8.2.18. D'abord, mettez un mot de passe sur Redis. La commande 8.2.19 est php artisan rconfig:redis-secure, mais elle n'existe pas sur 8.2.18. Sur 8.2.18, appliquez le même contrôle manuellement, adapté du service RedisSecurityService du fournisseur :

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

Le signal horizon:terminate fait redémarrer Horizon par Supervisor avec le nouveau mot de passe. Si vous exécutez le planificateur séparément, redémarrez-le aussi.

Ensuite, limitez la modification des équipements aux administrateurs de confiance jusqu'à la mise à niveau. L'interface 8.2.18 accepte encore une adresse d'équipement 127.0.0.1 ou localhost, donc le chemin de bouclage reste ouvert à tout compte qui peut ajouter ou modifier un équipement.

Gardez Redis lié à la boucle locale ou à un réseau privé et filtrez le port 6379. Cela réduit le chemin direct, mais ne ferme pas le chemin de bouclage.

Après la mise à niveau, renouvelez les secrets que le worker pouvait lire. L'avis du fournisseur liste les jetons d'API REST, les mots de passe des équipements et d'activation, et les secrets SMTP, LDAP et RADIUS. Vérifiez la liste des utilisateurs pour les comptes que vous ne reconnaissez pas.

Quelle est la cause racine ?

La file d'attente est adossée à Redis via Laravel Horizon, et Redis n'avait pas de mot de passe par défaut. Le CallQueuedHandler de Laravel désérialise la charge utile de la tâche sans liste d'autorisation de classes. Une tâche qui nomme une classe avec une méthode handle() dangereuse exécute donc cette méthode.

La tâche TaskDownloadRun fournie était une de ces classes : avant 8.2.18, elle passait ses champs sérialisés task_command et id directement à Artisan::call().

À l'étiquette 8.2.18, config/database.php lignes 121 à 126 définit le mot de passe Redis à partir de REDIS_PASSWORD avec null par défaut :

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

Le fichier .env.example fournit REDIS_PASSWORD=null. Une installation par défaut se connecte donc à Redis sans authentification.

À l'étiquette 8.2.17, app/Jobs/TaskDownloadRun.php ligne 32 passait les champs de tâche sérialisés à Artisan :

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

Les propriétés de la tâche voyagent dans la charge utile de la file d'attente. Un attaquant qui peut écrire dans la file contrôle task_command et id, donc le worker exécute n'importe quelle commande Artisan, y compris tinker.

Le journal des modifications de 8.2.18 décrit le correctif dans ses propres termes. Il indique que TaskDownloadRun passait la commande et l'identifiant de ses propres propriétés sérialisées directement à Artisan::call(), donc une charge utile forgée pouvait exécuter n'importe quelle commande Artisan.

La version 8.2.18 a ajouté une liste d'autorisation dans app/Jobs/TaskDownloadRun.php lignes 58 à 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]]);

Cette liste d'autorisation a fermé l'injection directe d'arguments Artisan dans cette tâche. Elle n'a pas fermé la file d'attente elle-même, et elle n'a pas empêché un équipement de pointer vers le serveur. Le fournisseur liste 8.2.18 comme affecté et a corrigé les chemins restants dans 8.2.19.

Le second chemin est la cible de l'équipement. À l'étiquette 8.2.19, app/Rules/DeviceIpIsValid.php lignes 29 à 36 rejettent un équipement qui pointe vers le serveur :

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 règle est attachée à device_ip lors de la création et de la mise à jour d'un équipement dans app/Http/Requests/StoreDeviceRequest.php lignes 56 et 71. La connexion Telnet ouvre une socket TCP brute avec fsockopen($this->hostname, $this->port), et Send::sendString() y écrit $command . "\r\n". Un équipement sur 127.0.0.1 au port 6379 transforme donc le téléchargement de l'équipement en écrivain TCP brut vers Redis.

Le code de correctif du fournisseur énonce le risque dans app/Services/Utilities/RedisSecurityService.php. Il indique que Core exécute des workers Horizon qui désérialisent les charges utiles de la file d'attente. Un Redis non authentifié dans lequel n'importe quel processus local peut écrire est donc un chemin d'exécution de code.

L'impact était plus grave sur les installations natives parce que le worker de la file d'attente s'exécutait en tant que root. À l'étiquette 8.2.18, horizon_supervisor.ini définit user=root :

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

La version 8.2.19 remplace cela par user=RCONFIG_WEB_USER, donc une future faille de file d'attente ne s'exécute plus avec les droits système complets.

Comment la faille est-elle exploitée ?

1. Atteindre la file d'attente. Si Redis est joignable sans mot de passe, l'attaquant se connecte directement au port 6379.
2. Utiliser le chemin de l'équipement si Redis n'est accessible qu'en boucle locale. L'attaquant se connecte et crée ou modifie un équipement avec device_ip défini sur 127.0.0.1, localhost, ::1 ou 0.0.0.0, et device_port_override défini sur 6379.
3. Écrire une tâche. La connexion de l'équipement ouvre une socket TCP vers la cible et écrit la chaîne de commande. Pointée vers Redis, la même socket accepte la commande Redis qui pousse une tâche Laravel sérialisée dans la file Horizon.
4. Le worker la désérialise. Le CallQueuedHandler de Horizon désérialise la charge utile et appelle la méthode handle() de la tâche. La charge utile peut nommer TaskDownloadRun ou une autre classe avec un gestionnaire dangereux.
5. La tâche s'exécute. Sur les versions antérieures à 8.2.18, TaskDownloadRun exécute la commande Artisan de l'attaquant. Sur 8.2.18, la liste d'autorisation de cette tâche bloque la commande directe, mais la file désérialise encore d'autres classes et le chemin de bouclage reste ouvert. Le paquet laravel/tinker fourni transforme une commande Artisan en commandes PHP et système arbitraires.
6. L'attaquant persiste. La description de la CVE enregistre un shell web dans storage/app/public, ainsi que les identifiants de base de données, les identifiants d'équipements stockés et les jetons d'API.

Aucune preuve de concept publique n'est liée depuis l'avis ou l'enregistrement CVE au 2026-11-09. Ces étapes décrivent le mécanisme documenté par les sources ; ce n'est pas un exploit fonctionnel.

Comment se déroule l'attaque ?

Un attaquant qui peut atteindre la file d'attente Redis, directement ou via un équipement de bouclage, écrit une tâche sérialisée que Horizon désérialise et exécute en tant que worker.

Que peut faire un attaquant ?

L'attaquant exécute du code en tant que worker. Sur les installations natives qui utilisaient le stub supervisor de 8.2.18, cet utilisateur était root. Dans l'image Docker, le worker s'exécute en tant que www-data.

Les conditions d'impact sont :

• L'accès direct à Redis exige que le port Redis soit joignable depuis le réseau de l'attaquant et qu'il n'ait pas de mot de passe.
• Le chemin de bouclage exige un compte rConfig connecté qui peut créer ou modifier un équipement.
• Le worker de la file d'attente doit exécuter Horizon, qui est la valeur par défaut des versions affectées.

Avec l'exécution de code, la description de la CVE enregistre ces capacités :

• Écrire un shell web persistant dans le répertoire storage/app/public servi par le web.
• Lire les identifiants de base de données et les jetons d'API.
• Lire les identifiants d'équipements stockés pour les équipements réseau que rConfig gère.

Aucune exploitation en environnement réel n'est connue, et la CVE n'est pas dans le catalogue KEV de la CISA au 2026-11-09.

Pourquoi le correctif fonctionne-t-il ?

Le correctif ferme les deux chemins vers la file d'attente et réduit l'impact de toute future faille de file d'attente. L'avis du fournisseur liste Core 8.2.19 et Pro 8.4.1 comme versions corrigées.

Le premier changement rejette les cibles d'équipement qui pointent vers la boucle locale ou l'hôte Redis du serveur. Le diff 8.2.19 ajoute pointsAtThisServer() à la règle DeviceIpIsValid existante :

@@ -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 règle rejette désormais localhost, l'hôte Redis configuré, toutes les adresses de 127.0.0.0/8, 0.0.0.0, ::1, :: et les formes IPv6 mappées IPv4. Le chemin de bouclage authentifié est fermé.

Le second changement met un mot de passe sur Redis. La nouvelle commande rconfig:redis-secure appelle RedisSecurityService::secure(), qui génère un secret de 32 octets, écrit REDIS_PASSWORD dans .env et l'exige sur le serveur actif :

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

Elle exécute ensuite CONFIG REWRITE pour que le mot de passe survive à un redémarrage, et redémarre les consommateurs de la file d'attente. L'installateur et le point d'entrée Docker génèrent le même mot de passe sur les nouvelles installations. Le chemin direct non authentifié est fermé.

Le troisième changement exécute Horizon et le planificateur en tant qu'utilisateur web. Le fichier horizon_supervisor.ini de 8.2.19 remplace user=root par user=RCONFIG_WEB_USER, et les notes de version indiquent que les services ne s'exécutent plus en tant que root. Si une autre faille de file d'attente apparaît, le worker n'a plus les droits système complets.

L'avis du fournisseur liste 8.2.19 et 8.4.1 comme versions corrigées pour cette CVE.

Comment vérifier si j'ai été compromis ?

Aucun indicateur de compromission public n'est publié pour CVE-2026-124079. Ces vérifications recherchent les deux chemins d'accès et la persistance décrite par la CVE.

Vérifiez si Redis est ouvert et ce qui est en file d'attente :

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 un mot de passe, ajoutez -a "$REDIS_PASSWORD" --no-auth-warning à chaque commande. Le scan liste les clés de file d'attente. Inspectez toute clé de liste renvoyée avec lrange <key> 0 -1. Une file vide est normale. Une charge utile sérialisée qui nomme une classe inattendue est une piste à examiner.

Recherchez les équipements pointant vers le serveur :

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.%';"

Recherchez un shell web PHP dans le répertoire de stockage public :

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

Les téléversements légitimes de rConfig n'ont pas besoin d'un fichier PHP dans storage/app/public. Considérez tout fichier PHP à cet endroit comme suspect et comparez-le à une sauvegarde de confiance.

Vérifiez les journaux de l'application et de la file d'attente pour les tâches rejetées ou les commandes Artisan inattendues :

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

Une tâche rejetée signifie que quelqu'un a envoyé une commande inattendue. Un résultat peut être une tentative échouée plutôt qu'une compromission. Aucun indicateur public n'existe, donc une tentative échouée peut ne laisser aucune trace.

Chronologie

• 2026-10-08 : rConfig Core 8.2.18 est publié avec une liste d'autorisation dans TaskDownloadRun, un correctif partiel de l'injection d'arguments Artisan.
• 2026-10-27 : rConfig Core 8.2.19 est publié avec l'authentification Redis, des workers de file d'attente non root et le blocage des équipements en boucle locale.
• 2026-11-06 : rConfig publie l'avis rCFG-SA-2026-09 pour cette CVE et la version Core 8.2.20, qui corrige aussi rCFG-SA-2026-10, la divulgation d'identifiants par export de table.
• 2026-11-09 : VulnCheck publie CVE-2026-124079 et crédite komi Sergio Hognaglo (manasse).

L'écart entre le correctif partiel 8.2.18 et la publication de la CVE était de 32 jours.

FAQ

CVE-2026-124079 est-elle exploitée en environnement réel ?

Aucune exploitation n'est connue. Ni l'avis du fournisseur ni l'avis de VulnCheck ne signalent d'attaques, et la CVE n'est pas dans le catalogue KEV de la CISA au 2026-11-09.

La faille affecte-t-elle rConfig Pro ?

Oui. rConfig Pro avant 8.4.1 est affecté, et le fournisseur l'a corrigé dans 8.4.1. Le fournisseur indique que 8.4.2 est attendue prochainement avec d'autres correctifs.

Core 8.2.18 est-il corrigé ?

Non. Core 8.2.18 a ajouté une liste d'autorisation à la tâche TaskDownloadRun, mais le fournisseur liste 8.2.18 comme affecté. Core 8.2.19 est la première version que le fournisseur liste comme corrigée.

Mon instance est-elle exposée si Redis n'est accessible qu'en boucle locale ?

Elle peut l'être. Un utilisateur connecté qui peut ajouter ou modifier un équipement peut pointer cet équipement vers 127.0.0.1 au port 6379, et rConfig se connecte aux cibles des équipements. Si la modification des équipements est limitée aux administrateurs de confiance et que Redis a un mot de passe, l'exposition est plus faible. La mise à niveau reste toutefois le correctif.

Quels secrets dois-je renouveler ?

Renouvelez les jetons d'API REST, les mots de passe stockés des équipements et d'activation, et les secrets SMTP, LDAP et RADIUS. L'avis du fournisseur demande aussi de vérifier la liste des utilisateurs pour les comptes que vous ne reconnaissez pas.

Un pare-feu peut-il remplacer la mise à niveau ?

Non. Un pare-feu ou une liaison Redis limitée à la boucle locale réduit le chemin direct, mais ne ferme pas le chemin de bouclage de l'équipement. Appliquez le mot de passe Redis et limitez la modification des équipements jusqu'à la mise à niveau.

Trouvez les serveurs rConfig exposés avec Ostorlab

La découverte de surface d'attaque d'Ostorlab inventorie les hôtes exposés à Internet. Elle vous permet de trouver les instances rConfig qui ne devraient pas être joignables et de les corriger en priorité. Commencez sur ostorlab.co/product/attacksurface_discovery.

Références

• 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 (vérifié le 9 novembre 2026).
• CVE Program, « CVE-2026-124079 », https://www.cve.org/CVERecord?id=CVE-2026-124079 (vérifié le 9 novembre 2026).
• rConfig, « Security Advisories & Vulnerability Disclosures », https://www.rconfig.com/security-advisories (vérifié le 9 novembre 2026).
• rConfig, « rConfig V8 Core 8.2.19 », https://github.com/rconfig/rconfig/releases/tag/core-8.2.19 (vérifié le 9 novembre 2026).
• rConfig, « rConfig V8 Core 8.2.20 », https://github.com/rconfig/rconfig/releases/tag/core-8.2.20 (vérifié le 9 novembre 2026).
• rConfig, « CHANGELOG.md at core-8.2.19 », https://github.com/rconfig/rconfig/blob/core-8.2.19/CHANGELOG.md (vérifié le 9 novembre 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 (vérifié le 9 novembre 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 (vérifié le 9 novembre 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 (vérifié le 9 novembre 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 (vérifié le 9 novembre 2026).
• rConfig, « config/database.php at core-8.2.18 », https://github.com/rconfig/rconfig/blob/core-8.2.18/config/database.php (vérifié le 9 novembre 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 (vérifié le 9 novembre 2026).
• rConfig, « horizon_supervisor.ini at core-8.2.18 », https://github.com/rconfig/rconfig/blob/core-8.2.18/horizon_supervisor.ini (vérifié le 9 novembre 2026).
• rConfig, « horizon_supervisor.ini at core-8.2.19 », https://github.com/rconfig/rconfig/blob/core-8.2.19/horizon_supervisor.ini (vérifié le 9 novembre 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 (vérifié le 9 novembre 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 (vérifié le 9 novembre 2026).
• CISA, « Known Exploited Vulnerabilities Catalog », https://www.cisa.gov/known-exploited-vulnerabilities-catalog (vérifié le 9 novembre 2026).
• rConfig, « rconfig/rconfig on GitHub », https://github.com/rconfig/rconfig (vérifié le 9 novembre 2026).
• Docker Hub, « rconfig/rconfig », https://hub.docker.com/r/rconfig/rconfig (vérifié le 9 novembre 2026).