Database CVE

Adobe Commerce è affetto da una vulnerabilità di Improper Neutralization of Special Elements Used in a Template Engine che potrebbe comportare l'esecuzione di codice arbitrario nel contesto dell'utente corrente. Un attaccante potrebbe sfruttare questa vulnerabilità per eseguire codice arbitrario. Lo sfruttamento di questo problema non richiede interazione da parte dell'utente. L'ambito è cambiato.

N-central è vulnerabile a una remote code execution pre-auth Questo problema interessa N-central: prima di 2026.3.1.14.

Una vulnerabilità nel filtro di controllo degli accessi alle API interne di N-central consente l'accesso non autorizzato alle API interne. Il problema è stato corretto in N-central 2026.3 HF3 e 2026.4

RouterOS contiene una falla nella gestione degli argomenti nel percorso di login SSH involving username che iniziano con un carattere proibito, consentendo la modifica del trusted RouterOS policy mask, con conseguente privilege escalation. Lo sfruttamento richiede una sessione SSH non autenticata per raggiungere il RouterOS login helper. Il problema è stato corretto nelle versioni: 6.49.21 (Long-term), 7.23.4 (Long-term) e 7.24.2 (Stable)

RouterOS non confronta la chiave pubblica RSA completa quando associa una richiesta di autenticazione SSH a una chiave utente autorizzata, controllando il tipo di chiave e il modulo ma omettendo l'esponente. Poiché la verifica della firma utilizza la chiave fornita dal client, un attaccante che conosce un modulo RSA autorizzato può fornire una chiave con esponente uno, falsificare una firma valida e aprire un canale di comando SSH come utente di destinazione senza la chiave privata. Questo problema è stato corretto nelle versioni: 6.49.21 (Long-term), 7.23.4 (Long-term) e 7.24.2 (Stable)

Un bypass dell'autenticazione in N-central < 2026.3 HF 3 porta al bypass dell'autenticazione nelle API solo interne

Tycon Systems TPDIN-Monitor-WEB3 versioni 2.2.9 e precedenti sono vulnerabili a una vulnerabilità di Missing Authorization. Ciò potrebbe consentire a un attaccante di estrarre credenziali di sistema, configurazioni o contenuti flash.

In Ignition 8.1.53 e versioni precedenti, l'impostazione del Gateway "Create Project Role(s)" veniva fornita vuota, il che consentiva a qualsiasi utente autenticato di creare progetti (se in grado di eseguire gateway scripts). Ignition 8.1.54 limita la creazione dei progetti alle sessioni Designer e non si basa più su questa impostazione. La serie 8.3 non è interessata.

Neutralizzazione impropria delle sequenze CRLF in IXON VPN Client prima della versione 1.4.7 consente a un utente malintenzionato di eseguire comandi come root o SYSTEM. I valori di configurazione accettati dal servizio locale vengono scritti in un file successivamente letto da un sottoprocesso privilegiato, senza che le sequenze di fine riga vengano neutralizzate, il che consente di introdurre direttive aggiuntive in tale file. L'interfaccia di configurazione accetta modifiche senza autenticare o verificare l'origine del richiedente. La configurazione iniettata persiste su disco attraverso i riavvii del client e del sistema operativo e la connessione VPN continua a funzionare normalmente, quindi non vi è alcun cambiamento comportamentale visibile per l'utente.

Tycon Systems TPDIN-Monitor-WEB3 versioni 2.2.9 e precedenti sono vulnerabili a una vulnerabilità di cross-site request forgery. Ciò potrebbe consentire a un attaccante di eseguire operazioni di modifica dello stato sul dispositivo.

Le versioni 2.2.9 e precedenti di Tycon Systems TPDIN-Monitor-WEB3 sono vulnerabili a una vulnerabilità di utilizzo di credenziali hard-coded. Ciò potrebbe consentire a un attaccante di intercettare informazioni sensibili o credenziali.

Nel kernel Linux, la seguente vulnerabilità è stata risolta: HID: magicmouse: prevenire la ricorsione illimitata in magicmouse_raw_event() magicmouse_raw_event() gestisce i pacchetti DOUBLE_REPORT_ID (0xf7), che raggruppano due report di tocco in uno, suddividendo il pacchetto e richiamando sé stessa su ciascuna metà. L'unica protezione contro la ricorsione incontrollata è un controllo "size < 1", che blocca le chiamate di dimensione zero ma non limita la profondità di ricorsione. Un dispositivo HID dannoso associato a questo driver può inviare un report che inizia con DOUBLE_REPORT_ID e riempito con la sequenza [0xf7, 0x00]. Ogni livello consuma due byte e ricorre sul resto, così un report in ingresso fino a HID_MAX_BUFFER_SIZE (16 KiB) genera circa 8000 chiamate annidate. Ciò esaurisce facilmente lo stack del kernel da 16 KiB, causando uno stack overflow: un panic con CONFIG_VMAP_STACK, o corruzione della memoria senza di esso. Un double report racchiude sempre e solo due report normali; non è mai legittimamente annidato. Impedire il rientro nel caso DOUBLE_REPORT_ID da una chiamata ricorsiva in modo che la profondità di ricorsione sia limitata a due, mentre tutti i pacchetti validi continuano a essere analizzati esattamente come prima.

Nel kernel Linux, è stata risolta la seguente vulnerabilità: HID: pidff: corregge la scrittura OOB quando hid->inputs è vuoto hid_pidff_init_with_quirks() ricava il proprio input_dev da list_entry(hid->inputs.next, struct hid_input, list) senza prima verificare che hid->inputs non sia vuoto. Il membro list di struct hid_input si trova all'offset 0, quindi, con una lista vuota, list_entry() restituisce &hid->inputs stessa e il successivo caricamento di hidinput->input legge un membro non correlato di struct hid_device. dev è quindi un puntatore con tipo errato e l'inizializzazione del force-feedback scrive attraverso di esso: ogni set_bit(FF_*, dev->ffbit) memorizza 8 byte all'indirizzo dev + 192, oltre la fine dell'oggetto a cui dev fa effettivamente riferimento, mentre input_ff_create() aggiunge ulteriori scritture di un puntatore heap e di due puntatori a funzione. Fino a hid-universal-pidff l'unico chiamante era hid_pidff_init() da usbhid, che viene eseguito in HID_CLAIMED_INPUT e pertanto ha sempre almeno un hid_input. universal_pidff_probe() avvia il dispositivo con HID_CONNECT_DEFAULT & ~HID_CONNECT_FF e quindi chiama direttamente hid_pidff_init_with_quirks() ogni volta che il descrittore contiene una pagina di utilizzo PID, aggirando tale controllo. Un descrittore di report la cui unica application collection è su HID_UP_PID lascia hid->inputs vuoto mentre hid_connect() ha comunque esito positivo tramite la richiesta hidraw, quindi probe raggiunge list_entry() senza controllo. La scrittura avviene nel percorso di probe USB, sulla workqueue hotplug, quindi è sufficiente collegare un dispositivo malevolo per attivarla; non sono richiesti software dell'attaccante né un utente autenticato. KASAN segnala una scrittura di 8 byte fuori dai limiti in hid_pidff_init_with_quirks(), raggiunta da universal_pidff_probe(). Verificare la presenza di una lista vuota prima di ricavare dev e restituire -ENODEV, come già fanno gli altri driver HID force-feedback. universal_pidff_probe() propaga l'errore e annulla le operazioni effettuate. Scoperta da XBOW, sottoposta a triage da Baul Lee <[email protected]>

Nel kernel Linux è stata risolta la seguente vulnerabilità: HID: nintendo: correzione di una lettura fuori dai limiti in joycon_ctlr_read_handler() joycon_ctlr_read_handler() esegue il cast di un report di input HID in arrivo a struct joycon_input_report e lo analizza, proteggendo il cast solo con un controllo di lunghezza di 12 byte: if (size >= 12) /* make sure it contains the input report */ joycon_parse_report(ctlr, (struct joycon_input_report *)data); struct joycon_input_report è di 49 byte: un'intestazione di 13 byte seguita da una union il cui braccio IMU è di 36 byte. Per un report IMU joycon_parse_report() -> joycon_parse_imu_report() percorre quella union (offset della struct 13..48), quindi un report di esattamente 12 byte con data[0] == JC_INPUT_IMU_DATA supera il controllo ma viene letto fino a 37 byte oltre la lunghezza dichiarata. I byte letti in eccesso vengono decodificati in valori di accelerometro/giroscopio e inoltrati allo spazio utente tramite il dispositivo di input "(IMU)", facendo

Nel kernel Linux, la seguente vulnerabilità è stata risolta: HID: nintendo: registrare il dispositivo di input dopo aver impostato le capabilities input_register_device() espone immediatamente il dispositivo allo userspace. In joycon_input_create() veniva chiamata prima che joycon_config_rumble() configuri la capability FF_RUMBLE e il dispositivo force-feedback memless, quindi un EVIOCSFF concorrente potrebbe dereferenziare un dev->ff NULL. La registrazione anticipata significa anche che l'evento udev iniziale è privo di informazioni su pulsanti e assi, il che può portare gli input manager a ignorare il dispositivo. Spostare input_register_device() alla fine di joycon_input_create(), dopo che tutte le capabilities, il dispositivo di input IMU e le callback force-feedback sono state configurate.

Nel kernel Linux, la seguente vulnerabilità è stata risolta: HID: nintendo: interrompere l'IO del dispositivo prima di hid_hw_stop in caso di fallimento del probe nintendo_hid_probe() chiama hid_device_io_start() prima di joycon_init() e joycon_leds_create(). Se una delle due fallisce, il percorso di errore salta a err_close che chiama hid_hw_close()/hid_hw_stop() senza prima chiamare hid_device_io_stop(). hid_hw_stop() non interrompe l'IO del dispositivo, quindi hid_input_report() potrebbe ancora essere in esecuzione e accedere ai dati del driver in fase di smantellamento, con conseguente use-after-free. Aggiungi un'etichetta err_io_stop che chiama hid_device_io_stop() prima di hid_hw_close(), e indirizza a essa i due percorsi di errore successivi a io_start.

Nel kernel Linux, la seguente vulnerabilità è stata risolta: HID: ft260: corretta scrittura stack-use-after-return in race di lettura I2C ft260_i2c_read() punta dev->read_buf a un buffer fornito dal chiamante (spesso una variabile sullo stack), attiva un completion e attende fino a cinque secondi che il dispositivo restituisca i dati. La callback di input HID ft260_raw_event() viene eseguita nel percorso input/IRQ, indipendentemente dal mutex dev->lock trattenuto dal percorso di lettura, e copia il payload fornito dal dispositivo in dev->read_buf dopo un semplice controllo NULL. Questi due percorsi condividono read_buf, read_idx e read_len senza alcuna serializzazione. Se il dispositivo ritarda la sua risposta fino al timeout della lettura, ft260_i2c_read() resetta il controller, cancella read_buf e ritorna, svolgendo lo stack frame in cui risiedeva il buffer. Una risposta che arriva in quel momento permette a ft260_raw_event() di superare il controllo NULL e di eseguire quindi il memcpy() del payload controllato dal dispositivo nella posizione di stack ora liberata, una scrittura stack-use-after-return limitata ma influenzabile dall'attaccante, attivabile da hardware malevolo o malfunzionante. Aggiungere uno spinlock dedicato che serializza ogni accesso a read_buf, read_idx e read_len. ft260_raw_event() ora lo trattiene attraverso il controllo NULL, il memcpy e l'aggiornamento dell'indice, mentre il percorso di lettura lo acquisisce quando attiva e quando cancella il buffer, così che il teardown non possa più scivolare tra il controllo e la copia.

Nel kernel Linux, la seguente vulnerabilità è stata risolta: HID: sensor: custom: Correzione di use-after-free in enable_sensor enable_sensor_store() può chiamare set_power_report_state(), che dereferenzia sensor_inst->power_state e sensor_inst->report_state. Questi puntatori fanno riferimento a voci in sensor_inst->fields. Creare gli attributi dei campi prima di esporre l'attributo sysfs enable_sensor, così che enable_sensor non possa essere acceduto prima che lo stato da cui dipende sia stato inizializzato. Alla rimozione, eliminare enable_sensor prima di liberare gli attributi dei campi, così che una scrittura sysfs concorrente non possa dereferenziare memoria liberata tramite power_state o report_state.

Nel kernel Linux, la seguente vulnerabilità è stata risolta: HID: uclogic: correzione dello use-after-free di inrange_timer alla rimozione uclogic_remove() annulla il timer di pen in-range e poi arresta il dispositivo: timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev); timer_delete_sync() garantisce solo che il timer sia inattivo in quell'istante. uclogic_raw_event_pen() continua a consegnare i report della penna finché hid_hw_stop() non arresta il trasporto diverse righe più sotto, e ogni report con pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE ri-arma il timer: mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); Un report che arriva tra la chiamata a timer_delete_sync() e lo smantellamento del trasporto in hid_hw_stop() ri-arma inrange_timer dopo che era stato annullato. uclogic_remove() restituisce quindi il controllo e il drvdata devm viene liberato, mentre hid_hw_stop() ha già liberato il dispositivo di input a cui punta drvdata->pen_input, quindi quando il timer scatta ~100 ms dopo uclogic_inrange_timeout() dereferenzia memoria liberata -- uno use-after-free in contesto timer-softirq. Invertire le due chiamate non è una correzione: arrestare prima il dispositivo libera drvdata->pen_input tramite hidinput_disconnect() mentre il timer potrebbe essere ancora in sospeso, così un timer già armato prima della rimozione scatta sul dispositivo di input liberato nella finestra prima che venga eseguito timer_delete_sync(). Usare invece timer_shutdown_sync() prima di hid_hw_stop(). Annulla il timer, attende un callback in esecuzione mentre pen_input è ancora valido, e impedisce qualsiasi ulteriore riarmo -- un successivo mod_timer() da un report in-flight viene ignorato silenziosamente -- così il timer è dimostrabilmente disattivato prima che hid_hw_stop() liberi gli input. Questo è l'ordinamento che il timer core documenta per questo caso di teardown "timer ri-armato da un altro percorso".