Base de données CVE

OpenVPN 2.5.0 à 2.7.6 sous Windows utilisant le pilote tap-windows6 permet aux attaquants de déclencher une écriture hors limites via des entrées DOMAIN-SEARCH spécialement conçues.

Le service interactif Windows d’OpenVPN 2.7_alpha1 à 2.7.6 permet aux utilisateurs locaux authentifiés de contourner la contrainte du répertoire de configuration de confiance et de charger des fichiers de configuration arbitraires via des chemins spécialement conçus.

N-central est vulnérable à une exécution de code à distance pré-authentification. Ce problème affecte N-central : avant 2026.3.1.14.

Une vulnérabilité dans le filtre de contrôle d'accès à l'API interne de N-central permet un accès non autorisé aux API internes. Ceci est corrigé dans N-central 2026.3 HF3 et 2026.4

RouterOS contient une faille de gestion des arguments dans le chemin de connexion SSH impliquant des noms d'utilisateur commençant par un caractère interdit, permettant de modifier le masque de stratégie RouterOS de confiance, entraînant une élévation de privilèges. L'exploitation nécessite une session SSH non authentifiée pour atteindre l'assistant de connexion RouterOS. Ce problème a été corrigé dans les versions : 6.49.21 (Long-term), 7.23.4 (Long-term) et 7.24.2 (Stable)

RouterOS accepte une connexion btest « related » avant que la session primaire correspondante ait terminé son authentification. Un client non authentifié peut utiliser cet état pour démarrer un test UDP IPv4. Avec « random-data=false », l’émetteur transmet une queue non initialisée provenant d’un tampon de paquets du noyau. Un intervalle de taille de paquet distinct, non contrôlé et inversé, provoque un underflow d’entier non signé, une sortie fragmentée anormalement volumineuse et peut redémarrer le noyau de RouterOS. Ce problème a été corrigé dans les versions suivantes : 6.49.21 (Long-term), 7.23.4 (Long-term) et 7.24.2 (Stable)

RouterOS ne compare pas la clé publique RSA complète lors de la correspondance d'une demande d'authentification SSH avec une clé d'utilisateur autorisée, vérifiant le type de clé et le module mais omettant l'exposant. Comme la vérification de signature utilise la clé fournie par le client, un attaquant connaissant un module RSA autorisé peut fournir une clé avec exposant un, forger une signature valide et ouvrir un canal de commande SSH en tant qu'utilisateur cible sans la clé privée. Ce problème a été corrigé dans les versions : 6.49.21 (Long-term), 7.23.4 (Long-term) et 7.24.2 (Stable)

Un contournement d'authentification dans N-central < 2026.3 HF 3 mène à un contournement d'authentification dans les API internes uniquement

Tycon Systems TPDIN-Monitor-WEB3 versions 2.2.9 et antérieures sont vulnérables à une vulnérabilité d'autorisation manquante. Cela pourrait permettre à un attaquant d'extraire les identifiants système, les configurations ou le contenu flash.

Dans Ignition 8.1.53 et versions antérieures, le paramètre Gateway "Create Project Role(s)" était livré vide, ce qui permettait à tout utilisateur authentifié de créer des projets (s'il peut exécuter des gateway scripts). Ignition 8.1.54 restreint la création de projets aux sessions Designer et ne s'appuie plus sur ce paramètre. La série 8.3 n'est pas affectée.

La neutralisation incorrecte des séquences CRLF dans IXON VPN Client avant la version 1.4.7 permet à un attaquant d'exécuter des commandes en tant que root ou SYSTEM. Les valeurs de configuration acceptées par le service local sont écrites dans un fichier consommé ultérieurement par un sous-processus privilégié, sans que les séquences de fin de ligne soient neutralisées, ce qui permet d'introduire des directives supplémentaires dans ce fichier. L'interface de configuration accepte les modifications sans authentifier ni vérifier l'origine du demandeur. La configuration injectée persiste sur le disque après les redémarrages du client et du système d'exploitation, et la connexion VPN continue de fonctionner normalement, de sorte qu'aucun changement de comportement n'est visible pour l'utilisateur.

Tycon Systems TPDIN-Monitor-WEB3 versions 2.2.9 et antérieures sont vulnérables à une vulnérabilité de type cross-site request forgery. Cela pourrait permettre à un attaquant d'effectuer des opérations modifiant l'état sur l'appareil.

Tycon Systems TPDIN-Monitor-WEB3 versions 2.2.9 et antérieures sont vulnérables à une vulnérabilité d'utilisation d'identifiant codé en dur. Cela pourrait permettre à un attaquant d'intercepter des informations sensibles ou des identifiants.

Dans le noyau Linux, la vulnérabilité suivante a été corrigée : xfrm: ah6: validate routing header segments_left AH6 réorganise les adresses de l’en-tête de routage avant de calculer ou de vérifier l’ICV. ipv6_rearrange_rthdr() suppose que segments_left n’est pas supérieur au nombre d’adresses décrites par le champ hdrlen de l’en-tête de routage. Cette hypothèse ne tient pas pour les paquets IPv6 bruts HDRINCL. Un paquet avec hdrlen égal à 2 décrit une adresse, mais peut contenir une valeur segments_left arbitraire. Avec segments_left égal à 255, la fonction déplace son pointeur d’adresse de 4 064 octets vers l’arrière et transmet une longueur de 4 064 octets à memmove(), ce qui entraîne un accès hors limites. Valider localement l’invariant avant de modifier l’en-tête de routage ou d’effectuer toute arithmétique sur le pointeur d’adresse, et propager les erreurs d’en-tête malformé vers les chemins d’erreur d’entrée et de sortie AH6 existants.

Dans le noyau Linux, la vulnérabilité suivante a été résolue : HID: magicmouse: empêcher la récursion non bornée dans magicmouse_raw_event() magicmouse_raw_event() traite les paquets DOUBLE_REPORT_ID (0xf7), qui regroupent deux rapports tactiles en un seul, en divisant le paquet et en s'appelant elle-même sur chaque moitié. La seule protection contre l'emballement de la récursion est un contrôle "size < 1", qui arrête les appels de taille nulle mais ne limite pas la profondeur de récursion. Un périphérique HID malveillant correspondant à ce pilote peut envoyer un rapport commençant par DOUBLE_REPORT_ID et rempli avec la séquence [0xf7, 0x00]. Chaque niveau consomme deux octets et effectue une récursion sur le reste, de sorte qu'un rapport entrant allant jusqu'à HID_MAX_BUFFER_SIZE (16 KiB) provoque environ 8000 appels imbriqués. Cela épuise facilement la pile du noyau de 16 KiB, conduisant à un stack overflow : un panic avec CONFIG_VMAP_STACK, ou une corruption de mémoire sans elle. Un double rapport n'encapsule jamais que deux rapports normaux ; il n'est jamais légitimement imbriqué. Refuser de ré-entrer dans le cas DOUBLE_REPORT_ID à partir d'un appel récursif afin que la profondeur de récursion soit limitée à deux, tandis que tous les paquets valides continuent d'être analysés exactement comme avant.

Dans le noyau Linux, la vulnérabilité suivante a été résolue : HID: pidff: correction d'une écriture hors limites lorsque hid->inputs est vide hid_pidff_init_with_quirks() dérive son input_dev de list_entry(hid->inputs.next, struct hid_input, list) sans vérifier d'abord que hid->inputs n'est pas vide. Le membre list de struct hid_input se trouve à l'offset 0, donc sur une liste vide list_entry() renvoie &hid->inputs lui-même et le chargement suivant hidinput->input lit un membre sans rapport de struct hid_device. dev est alors un pointeur confondu au niveau des types, et l'initialisation du retour de force écrit à travers lui : chaque set_bit(FF_*, dev->ffbit) stocke 8 octets à dev + 192, au-delà de la fin de l'objet auquel dev est en réalité un alias, et input_ff_create() ajoute d'autres écritures d'un pointeur de tas et de deux pointeurs de fonction. Jusqu'à hid-universal-pidff, le seul appelant était hid_pidff_init() depuis usbhid, qui s'exécute sous HID_CLAIMED_INPUT et a donc toujours au moins un hid_input. universal_pidff_probe() démarre le périphérique avec HID_CONNECT_DEFAULT & ~HID_CONNECT_FF puis appelle directement hid_pidff_init_with_quirks() chaque fois que le descripteur contient une page d'usage PID, contournant ainsi cette barrière. Un descripteur de rapport dont la seule collection d'application est sur HID_UP_PID laisse hid->inputs vide alors que hid_connect() réussit encore via la revendication hidraw, de sorte que probe atteint le list_entry() non protégé. L'écriture se produit dans le chemin de sonde USB, sur la file de travail du hotplug, donc brancher un périphérique malveillant suffit à la déclencher ; aucun logiciel d'attaque ni utilisateur connecté n'est requis. KASAN signale une écriture hors limites de 8 octets dans hid_pidff_init_with_quirks() atteinte depuis universal_pidff_probe(). Vérifier que la liste est vide avant de dériver dev et renvoyer -ENODEV, comme le font déjà les autres pilotes HID de retour de force. universal_pidff_probe() propage l'erreur et déroule. Découvert par XBOW, trié par Baul Lee <[email protected]>

Dans le noyau Linux, la vulnérabilité suivante a été résolue : HID: nintendo: correction d'une lecture hors limites dans joycon_ctlr_read_handler() joycon_ctlr_read_handler() convertit un rapport d'entrée HID entrant en struct joycon_input_report et l'analyse, en ne protégeant la conversion que par un contrôle de longueur de 12 octets : if (size >= 12) /* make sure it contains the input report */ joycon_parse_report(ctlr, (struct joycon_input_report *)data); struct joycon_input_report fait 49 octets : un en-tête de 13 octets suivi d'une union dont le membre IMU fait 36 octets. Pour un rapport IMU, joycon_parse_report() -> joycon_parse_imu_report() parcourt cette union (décalages de structure 13..48), de sorte qu'un rapport d'exactement 12 octets avec data[0] == JC_INPUT_IMU_DATA passe le contrôle tout en étant lu jusqu'à 37 octets au-delà de sa longueur déclarée. Les octets lus en excès sont décodés en valeurs d'accéléromètre/gyroscope et transmis à l'espace utilisateur via le périphérique d'entrée « (IMU) », ce qui divulgue de la mémoire interne du pilote. data[0] et size sont entièrement contrôlés par une manette Joy-Con/Pro malveillante ou usurpée. Les tampons de réception sont dimensionnés à la longueur maximale de rapport, il s'agit donc d'une lecture excessive au sein de l'allocation plutôt que d'une lecture hors limites de slab, mais les octets décodés parviennent quand même à l'espace utilisateur. Le chemin frère subcmd dans joycon_ctlr_handle_event() borne déjà correctement la même conversion : if (size < sizeof(struct joycon_input_report) || data[0] != JC_INPUT_SUBCMD_REPLY) break; Utilisez ici la même borne sizeof(struct joycon_input_report).

Dans le noyau Linux, la vulnérabilité suivante a été résolue : HID: nintendo: enregistrer le périphérique d'entrée après la configuration des capacités input_register_device() expose immédiatement le périphérique à l'espace utilisateur. Dans joycon_input_create(), il a été appelé avant que joycon_config_rumble() configure la capacité FF_RUMBLE et le périphérique force-feedback memless, donc un EVIOCSFF concurrent pouvait déréférencer un dev->ff NULL. Un enregistrement précoce signifie également que l'événement udev initial manque d'informations sur les boutons et les axes, ce qui peut amener les gestionnaires d'entrée à ignorer le périphérique. Déplacer input_register_device() à la fin de joycon_input_create(), après que toutes les capacités, le périphérique d'entrée IMU et les callbacks force-feedback ont été configurés.

Dans le noyau Linux, la vulnérabilité suivante a été corrigée : HID: nintendo: arrêter les E/S du périphérique avant hid_hw_stop en cas d'échec du probe nintendo_hid_probe() appelle hid_device_io_start() avant joycon_init() et joycon_leds_create(). Si l'un ou l'autre échoue, le chemin d'erreur passe à err_close qui appelle hid_hw_close()/hid_hw_stop() sans d'abord appeler hid_device_io_stop(). hid_hw_stop() n'arrête pas les E/S du périphérique, donc hid_input_report() peut encore s'exécuter et accéder aux données du pilote en cours de destruction, ce qui provoque une utilisation après libération. Ajouter une étiquette err_io_stop qui appelle hid_device_io_stop() avant hid_hw_close(), et faire pointer vers elle les deux chemins d'erreur suivant io_start.