PaperCut CVE-2026-82078: un RCE pre-auth che riapre la porta al ransomware
Due falle concatenate danno RCE non autenticato su PaperCut NG/MF. Sfruttate come zero-day dal 26 agosto, con la prima patch già aggirata — la remediation e la caccia.
PaperCut gestisce la coda di stampa di università, ospedali, studi legali e pubbliche amministrazioni: silenzioso, fidato, e quasi mai nel threat model di un team di sicurezza. Il 27 agosto 2026 è cambiato tutto. PaperCut ha divulgato due zero-day concatenati, CVE-2026-82078 (CVSS 9.4) e CVE-2026-81578 (CVSS 8.8), che insieme permettono a un attaccante non autenticato di eseguire codice Java arbitrario sull'Application Server. Huntress ha osservato lo sfruttamento in-the-wild dal 26 agosto — un giorno prima dell'advisory — per poi vedere la prima patch d'emergenza venire aggirata. Se la sequenza suona familiare, è giusto così: stesso prodotto, e quasi stesso meccanismo, che nel 2023 hanno portato Cl0p e Bl00dy dentro le reti.
Cosa fa davvero la catena PaperCut CVE-2026-82078
Nessuno dei due bug è esotico. Ed è proprio il punto: sono classi vecchie reimportate in un'appliance fidata.
CVE-2026-81578 è un difetto di controllo degli accessi nell'interfaccia di gestione web. Secondo l'analisi di Rapid7, abusa del formato di richiesta "complex direct" di Apache Tapestry: il framework renderizza una pagina pubblica mentre attiva silenziosamente un componente amministrativo, così il controllo di validazione dell'accesso viene eseguito dopo che l'azione privilegiata è già partita. Questo dà a un chiamante remoto non autenticato accesso in scrittura al ConfigEditor.
CVE-2026-82078 è dove la scrittura in configurazione diventa esecuzione di codice. PaperCut carica le classi dei driver di database per nome dalla configurazione, senza verificarle contro una allowlist. Raggiunto il ConfigEditor con la prima falla, l'attaccante ripunta quattro impostazioni di user-lookup verso un driver JDBC Derby con una URL JDBC in stile H2 che porta uno statement INIT inline. Una ricerca UserList attiva poi un trigger di database basato su JavaScript che carica ed esegue bytecode Java fornito dall'attaccante. Il gadget jdbc:h2:...;INIT=... è una primitiva di RCE Java vecchia di dieci anni; qui è raggiungibile senza autenticazione.
| CVE | CVSS | Classe | Ruolo nella catena |
|---|---|---|---|
| CVE-2026-81578 | 8.8 | Controllo accessi improprio | Scrittura non autenticata su ConfigEditor via Tapestry "complex direct" |
| CVE-2026-82078 | 9.4 | Caricamento dinamico di classi non sicuro | Scrittura config → trigger INIT Derby/H2 → bytecode Java arbitrario |
Concatenate, le due producono RCE non autenticato come l'account che esegue pc-app.exe — sui deployment Windows, spesso SYSTEM.
Perché un PaperCut esposto è una porta per il ransomware
Non è un'ipotesi. Nel 2023, CVE-2023-27350 — un altro bypass di autenticazione PaperCut che portava a RCE — è diventato un vettore di accesso iniziale di massa. Come ha riportato BleepingComputer, Microsoft ha legato quello sfruttamento all'operazione ransomware Cl0p, la gang Bl00dy ha colpito il settore education, e attori allineati allo stato iraniano si sono aggiunti. Tre falle PaperCut precedenti sono già nel catalogo CISA KEV, due sfruttate in attacchi ransomware.
Un print server è un punto d'appoggio ideale esattamente per le ragioni che lo tengono fuori dal threat model:
- Gira come service account ad alto privilegio, spesso
SYSTEM, su un host Windows in dominio. - Deve parlare con ogni workstation e stampante, quindi il fan-out laterale da esso sembra operatività normale.
- Custodisce credenziali di lookup su directory e dati utente/tessera — utili per il salto successivo.
- Nessuno lo guarda. La copertura EDR sulle appliance di utilità è scarsa, e la retention dei log spesso è di giorni, non mesi.
I numeri dell'esposizione non consolano. SecurityWeek, citando Shadowserver, stima circa 1.000 istanze PaperCut direttamente su internet, per lo più in Nord America ed Europa. Huntress nota separatamente che circa il 47% delle installazioni che monitora è su v23 o precedenti — versioni che queste patch non le hanno mai ricevute perché fuori supporto.
La patch PaperCut che non bastava
Ecco il dettaglio che trasforma tutto da "patcha e vai avanti" in un esercizio di hunting. La prima patch d'emergenza di PaperCut è uscita, e poi watchTowr Labs ha trovato il modo di aggirarla. PaperCut ha pubblicato l'Emergency Patch Release 2 il 28 agosto e — secondo BleepingComputer — ora dice a ogni cliente di installare la Release 2 anche se ha già applicato la prima patch.
È la trappola che quasi tutti gli articoli saltano:
"Abbiamo patchato il 27." "Quale patch?" "Quella d'emergenza." "Erano due. La prima era aggirabile. E lo sfruttamento è iniziato il 26 — prima di entrambe. Cosa avete fatto per verificare se è entrato qualcosa nella finestra?"
Una patch ferma il prossimo attaccante. Non fa nulla contro un impianto già rilasciato attraverso il trigger H2. Dato che il primo sfruttamento precede l'advisory, "abbiamo patchato" e "siamo puliti" sono due affermazioni diverse, e solo una delle due è verificabile.
Remediation
Tratta ogni server PaperCut NG/MF esposto su internet come potenzialmente toccato tra il 26 agosto e il momento in cui hai applicato la Release 2. Lavora la lista dall'alto verso il basso.
1. Sono interessato?
Tutte le versioni NG e MF sono in scope fino all'Emergency Patch Release 2. Verifica versione ed esposizione:
- Versione:
Help → Aboutnella console admin, oppure controlla i metadati di build di[install-path]/server/lib/pc-app.jar. Lo sfruttamento è confermato su build recenti come v24.1.5.71847 e v25.0.10.75465 (Huntress). - Esposizione: da fuori la tua rete, verifica se le porte TCP 9191 (HTTP) o 9192 (HTTPS) rispondono. Qualsiasi cosa raggiungibile da internet va considerata colpita.
2. Patch — il target corretto
Aggiorna a Emergency Patch Release 2 sulla tua linea principale — PaperCut NG/MF versione 24, 25 o 26, Release 2 (Windows, Linux, macOS). La Release 1 non è sufficiente: è stata aggirata. Le versioni 23 e precedenti non ricevono fix e vanno migrate a una linea supportata. È testuale dall'advisory PaperCut e dal bollettino AV26-858 del Canadian Centre for Cyber Security.
3. Non puoi patchare subito? Controlli compensativi
- Limita l'interfaccia web a IP fidati. È la raccomandazione primaria di PaperCut: metti una ACL di firewall davanti alle porte 9191/9192 così che solo le tue subnet di print-management e i jumphost admin le raggiungano. Blocca del tutto il percorso d'ingresso non autenticato.
- Togli l'Application Server da internet pubblico. Non c'è ragione legittima perché l'interfaccia admin sia esposta al mondo.
- Applica il filtraggio in uscita dall'host del print server — non dovrebbe iniziare sessioni verso destinazioni internet arbitrarie.
4. Caccia alla compromissione (IOC → ATT&CK)
L'exploit lascia artefatti distintivi e verificabili. Dai dati d'incidente di Huntress:
- File
.classinattesi in[install]/server/lib/con nomi casuali di cinque caratteri, es.Udydn.class,Moo97.class(i nomi variano per incidente). PaperCut legittima non distribuisce file simili. - File
.cmd/.outche compaiono sotto[install]/server/data/content/. - Firme nel
server.log:DB URL: jdbc:derby:memory:pwn, una voce di boot tipomemory:...\server\data\internal\pwn, bytecode Java in esadecimale, o le stringhe d'erroreNo suitable driver found for jdbc:no:xeDatabaseUtils - Database error looking up cardID: VALUES CAST. Unserver.logtroncato, mancante o cancellato di fresco è di per sé un indicatore (T1070.004). - Telemetria di processo:
pc-app.exeche genera una command shell,charmap.exeo altre utility di discovery in esecuzione come SYSTEM sottopc-app.exe. - Comandi di recon in Base64 nei log —
d2hvYW1pICYgdmVy(whoami & ver) ed2hvYW1pICYgdmVyICYgdGFza2xpc3Q=(whoami & ver & tasklist), mappati aT1082/T1057.
Percorso ATT&CK: T1190 (sfruttamento app esposta) → T1059 (esecuzione comandi via la classe caricata) → discovery (T1082, T1057) → T1070.004 (cancellazione log).
5. Bonifica + verifica
Patchare è il passo due su cinque, non tutto il lavoro:
- Elimina gli artefatti
.classe.cmd/.outmalevoli confermati, poi ricostruisci invece di fidarti di qualsiasi server che mostri firme d'impianto — un class loader Java che è girato una volta può aver seminato una persistenza che a occhio non trovi. - Ruota ogni credenziale che il server poteva raggiungere: la password admin PaperCut, l'account di connessione al database, il service account che esegue
pc-app.exe, e ogni credenziale di lookup/bind su directory salvata in configurazione. - Rivedi i log di autenticazione di dominio per il service account che fa connessioni laterali mai fatte prima.
- Solo dopo aver applicato la Release 2 e ruotato le credenziali, conferma che il server sia pulito e che nessun nuovo impianto ricompaia al riavvio.
Intercettarlo sul filo quando il print server cambia comportamento
Ogni passo qui sopra presuppone che tu sappia già che il server è stato colpito. Il caso scomodo è quello in cui il log è troncato, il file .class si è auto-cancellato e la patch è andata a buon fine — così la console dice verde mentre un operatore siede dentro con SYSTEM su un host in dominio. È esattamente il divario per cui è stata costruita l'AI Traffic Analysis di Zero Hunt.
Un print server ha una delle baseline di traffico più prevedibili del parco: ingerisce job di stampa e parla con i directory service su una manciata di porte. Nel momento in cui inizia a fare altro — una sessione TLS in uscita verso un ASN mai visto, una cadenza di beacon, un burst di scritture SMB che si dirama verso i file share, un picco improvviso di DNS-over-HTTPS — il comportamento diverge da dieci mesi di normalità appresa. Il modello deep-learning di Zero Hunt gira quattro head di inferenza (traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo) su PCAP live a 2,7+ Gbit/s sulla GPU dell'appliance, interamente on-prem. Segnala il callback dell'RCE e lo staging del ransomware mentre accadono — non nel digest SIEM di domattina, e senza dipendere da un server.log che l'attaccante ha già cancellato. Per la kill chain canonica PaperCut-verso-ransomware, la detection in corso sulla rete è lo strato che non mente sull'essere puliti.
La domanda complementare — siamo davvero esposti, e la fix ha davvero attecchito? — è dove il pentest generativo a 10 agenti chiude il cerchio. Una campagna change-triggered parte quando un nuovo server PaperCut compare sul perimetro, e lo swarm scrive un tentativo di sfruttamento per-target contro l'host reale invece di rigiocare una firma. Poiché la prima patch era aggirabile, "validato non sfruttabile contro la Release 2" è un'affermazione più forte di "abbiamo installato l'update", e ogni tentativo è firmato ECDSA al momento della scrittura così che l'evidenza regga in una revisione d'incidente o in una richiesta assicurativa. Patcha, poi dimostra la patch — su una porta così consumata, la prova è la parte che conta.