Vulnerabilità RCE Qinglong: rivelato bypass Express.js

Scoperto bypass autenticazione RCE in Qinglong: ecco come la differenza di routing in Express.js ha permesso l'attacco e perché il filtro sul payload è ineffic…

Contenuto

Vulnerabilità RCE Qinglong: rivelato bypass Express.js
Vulnerabilità RCE Qinglong: rivelato bypass Express.js

Oltre 19.400 stelle e 3.200 fork su GitHub: questo è l'impatto potenziale delle vulnerabilità RCE (Remote Code Execution) che hanno colpito il progetto Qinglong tra febbraio e marzo 2026. Le falle, classificate come CVE-2026-3965 e CVE-2026-4047, hanno permesso agli attaccanti di bypassare l'autenticazione e prendere il controllo dei pannelli esposti pubblicamente, installando cryptominer sofisticati e compromettendo infrastrutture di monitoraggio più ampie.

Il contesto delle vulnerabilità RCE

Le vulnerabilità di esecuzione di codice remoto (RCE) sono da tempo considerate tra le più pericolose nel panorama della cybersecurity, poiché consentono agli aggressori di eseguire codice malevolo direttamente sulla macchina bersaglio. Storicamente, falle di questo tipo hanno avuto conseguenze devastanti: nel dicembre 2021, le molteplici vulnerabilità RCE in Log4J permisero lo sfruttamento di applicazioni vulnerabili per distribuire cryptojackers e altri malware. Analogamente, nel 2017, il ransomware WannaCry si diffuse su vasta scala sfruttando la vulnerabilità EternalBlue nel protocollo SMB, consentendo l'esecuzione di codice dannoso e la crittografia dei file. Come evidenziato dagli esperti di Cyberment, le RCE sono annoverate tra le tipologie di falle più critiche proprio per il livello di accesso che garantiscono all'attaccante.

Nel caso specifico di Qinglong, le versioni 2.20.1 e precedenti risultavano esposte a un problema logico profondo. L'attacco ha avuto inizio tra il 7 e l'8 febbraio 2026, quando i primi exploit hanno iniziato a colpire i pannelli esposti, ancora prima che le vulnerabilità fossero rese pubbliche. Solo in data 27 febbraio 2026 le falle di bypass dell'autenticazione sono state riportate pubblicamente attraverso le Issue #2933 e #2934 su GitHub, e il 1 marzo 2026 il manutentore del progetto ha confermato la vulnerabilità di sicurezza, esortando gli utenti ad aggiornare tempestivamente i propri sistemi.

La discrepanza nel routing di Express.js

Il cuore tecnico delle vulnerabilità CVE-2026-3965 e CVE-2026-4047 risiede in una mancata corrispondenza logica tra l'autorizzazione gestita dal middleware e il routing del framework Express.js. Come evidenziato dall'analisi di Snyk, "The auth layer assumed certain URL patterns would always be handled one way, while Express.js treated them differently."

Questa divergenza nell'interpretazione dei percorsi URL ha creato una finestra di vulnerabilità che gli attaccanti hanno sfruttato per eludere i controlli di sicurezza e accedere alle funzionalità amministrative senza credenziali valide. Il framework Express.js, elaborando le richieste in modo diverso rispetto alle aspettative del livello di autenticazione, ha lasciato scoperti endpoint che avrebbero dovuto essere protetti, permettendo l'esecuzione di comandi arbitrari sul server.

Perché bloccare il payload è inefficace

Di fronte allo sfruttamento attivo di una vulnerabilità, la reazione istintiva degli sviluppatori è spesso quella di bloccare immediatamente il payload malevolo osservato. Tuttavia, questa strategia si è dimostrata insufficiente nel caso di Qinglong. L'8 febbraio 2026, in risposta agli attacchi in corso, Copilot SWE Agent ha presentato il PR #2924 per affrontare il problema della shell injection nei file di configurazione. Questo tentativo di mitigazione, tuttavia, non è mai stato unito al progetto principale perché si limitava a filtrare il payload specifico senza risolvere la causa alla radice.

La lezione di sicurezza qui è centrale: risolvere il sintomo anziché la malattia apre la porta a evasioni future. Come ha sottolineato Snyk, "When an application is being actively exploited, the instinct is to block the observed payload. But if the root cause is an auth bypass, payload-level filtering is insufficient — attackers will simply pivot to a different payload."

La soluzione efficace è arrivata con il PR #2941, che ha corretto il bypass dell'autenticazione risolvendo effettivamente la discrepanza nel routing alla radice, invece di applicare una semplice toppa ai payload osservati. Questo intervento ha eliminato la superficie di attacco, rendendo inutile qualsiasi variante del payload originario.

Il cryptominer .fullgc e l'occultamento dei processi

Oltre alla vulnerabilità stessa, l'attacco a Qinglong si è distinto per le tecniche sofisticate di persistenza e occultamento del malware. Una volta ottenuto l'accesso tramite bypass, gli attaccanti hanno modificato il file config.sh per scaricare binary per cryptomining dal dominio file.551911.xyz. I malware, compatibili con Linux x86_64, ARM64 e persino varianti macOS, sono stati salvati nel percorso /ql/data/db/.fullgc.

Per mascherare l'infezione e ritardare le indagini degli amministratori di sistema, il processo miner è stato denominato '.fullgc'. Questa scelta non è casuale: il nome imita un innocuo processo Java/JVM noto come 'Full Garbage Collection', un evento di routine che giustifica i picchi di utilizzo della CPU. E proprio questo è stato l'impatto principale sulle macchine compromesse, con gli amministratori che hanno riportato un utilizzo della CPU compreso tra l'85 e il 100%. La possibilità di far passare un carico computazionale anomalo per un normale ciclo di pulizia della memoria ha permesso al cryptominer di operare indisturbato per un periodo più lungo.

La compromissione del monitoraggio Nezha

Le conseguenze dell'exploit RCE non si sono limitate alla singola macchina ospitante Qinglong. Almeno un utente ha riportato che gli attaccanti hanno sfruttato l'accesso ottenuto per compromettere il proprio pannello di monitoraggio Nezha. Questa ulteriore breccia ha garantito agli aggressori visibilità su centinaia di macchine aggiuntive collegate all'infrastruttura di monitoraggio, amplificando drasticamente il raggio d'azione dell'attacco.

L'uso di software di gestione e monitoraggio come punto di ingresso per estendere la compromissione è una tattica nota. In altri contesti, come riportato da Matrice Digitale, attaccanti hanno sfruttato vulnerabilità in ASP.NET e Outlook per iniettare codice malevolo tramite ViewState modificato, impiegando trojan post-sfruttamento come Godzilla per mantenere l'accesso e distribuire comandi sui server IIS bersaglio. L'obiettivo di sfruttare l'accesso iniziale per muoversi lateralmente ed esfiltrare dati o installare ransomware è una costante nelle minacce RCE avanzate.

Domande frequenti

Che cos'è l'esecuzione di codice remoto (RCE)?
Una vulnerabilità RCE consente a un aggressore di eseguire codice arbitrario su un sistema remoto. Queste falle sono particolarmente critiche perché permettono il pieno controllo della macchina vittima, aprendo la strada all'installazione di malware, come ransomware o spyware, e alla compromissione di ulteriori infrastrutture interne.
In che modo il bypass in Qinglong eludeva l'autenticazione?
Il bypass sfruttava una divergenza logica tra l'autorizzazione del middleware e il routing di Express.js. Il livello di autenticazione dava per scontato che alcuni percorsi URL venissero gestiti in un determinato modo, mentre il framework Express.js li interpretava diversamente, lasciando scoperti endpoint sensibili che avrebbero dovuto richiedere credenziali.
Perché il processo malevolo si chiamava .fullgc?
Gli attaccanti hanno rinominato il processo del cryptominer in '.fullgc' per imitare il 'Full Garbage Collection' della macchina virtuale Java. Questa denominazione serviva a giustificare i picchi di utilizzo della CPU (fino al 100%) agli occhi degli amministratori di sistema, ritardando l'individuazione dell'anomalia.

Questo articolo è una sintesi basata esclusivamente sulle fonti elencate.

Fonti

Link utili

Apri l'articolo su DeafNews