CVE-2026-28496-Lab — Lab basato su Docker per riprodurre e validare CVE-2026-28496, una vulnerabilità Server-Side Template Injection nel rendering Twig di FOSSBilling, con target di confronto vulnerabili e patchati. | Kitploit

Questo laboratorio convalida il comportamento HTTP della versione vulnerabile rispetto a quella corretta utilizzando FOSSBilling 0.7.2 e FOSSBilling 0.8.0.

Il laboratorio è intenzionalmente limitato ai servizi Docker locali. Non ha come bersaglio sistemi esterni e non include web shell, malware, persistenza, callback esterni, dumping di database o payload distruttivi.

## Fatti verificati

| Affermazione                                                                               | Prova                                                                                                           | Come verificare in questo laboratorio                                                              |
| ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- |
| CVE-2026-28496 colpisce le versioni di FOSSBilling precedenti alla 0.8.0.                         | Il CVE pubblico e i metadati degli advisory identificano FOSSBilling precedente alla 0.8.0 come colpito da Twig SSTI.                     | Rivedere la sezione Riferimenti e confrontare le versioni vulnerabile e corretta del target.  |
| FOSSBilling 0.7.2 è utilizzato come target vulnerabile di confronto.                      | Il servizio vulnerabile è costruito dall'immagine Docker ufficiale `fossbilling/fossbilling:0.7.2`.                    | Ispezionare `vuln/Dockerfile` ed eseguire `docker compose ps -a`.                              |
| FOSSBilling 0.8.0 è utilizzato come target corretto di confronto.                         | Il servizio corretto è costruito dall'immagine Docker ufficiale `fossbilling/fossbilling:0.8.0`.                       | Ispezionare `patched/Dockerfile` ed eseguire `docker compose ps -a`.                           |
| Il percorso HTTP vulnerabile è `/api/system/system/string_render`.                     | Il target vulnerabile restituisce JSON con `result: "49"` per `_tpl={{ 7*7 }}`.                                       | Eseguire `python3 poc/poc.py --url http://localhost:8081`.                                  |
| Il target corretto non espone lo stesso comportamento HTTP.                          | Il target corretto restituisce `Unknown API call system/system/string_render`.                                         | Eseguire `python3 poc/poc.py --url http://localhost:8082`.                                  |
| Il PoC è solo HTTP.                                                               | `poc/poc.py` invia richieste HTTP POST e non chiama Docker, Docker Compose, comandi shell o API dei container. | Ispezionare `poc/poc.py`.                                                                  |
| Il laboratorio installa automaticamente entrambi i target FOSSBilling all'avvio di Docker Compose.       | I container sidecar installer one-shot completano la configurazione ed escono con stato 0.                                   | Eseguire `docker compose ps -a` e `docker compose logs installer-vuln installer-patched`. |
| Il target vulnerabile renderizza l'espressione Twig innocua.                         | La risposta HTTP dalla porta 8081 è `{"result":"49","error":null}`.                                                | Eseguire il comando PoC vulnerabile.                                                        |
| Il target corretto non renderizza la stessa espressione attraverso il percorso API testato. | La risposta HTTP dalla porta 8082 è un errore API JSON con codice `879`.                                              | Eseguire il comando PoC corretto.                                                           |

## Ipotesi e incognite

Questo laboratorio utilizza FOSSBilling 0.7.2 come target vulnerabile di confronto perché la ricerca pubblica sulle vulnerabilità identifica le versioni di FOSSBilling precedenti alla 0.8.0 come colpite, e la 0.7.2 è l'ultima release vulnerabile utilizzata nella catena testata.

Questo laboratorio utilizza FOSSBilling 0.8.0 come target corretto di confronto perché i metadati degli advisory pubblici identificano la 0.8.0 come la versione corretta.

Questo laboratorio si concentra sul comportamento HTTP osservabile di:```text
POST /api/system/system/string_render

Il laboratorio dimostra che FOSSBilling 0.7.2 renderizza l'espressione Twig fornita attraverso il percorso API HTTP, mentre FOSSBilling 0.8.0 non espone la stessa chiamata API.

Questo laboratorio non sostiene di testare tutte le funzionalità di rendering dei template di FOSSBilling. CVE-2026-28496 riguarda anche altri contesti di rendering Twig, come le funzionalità di rendering dei template disponibili all'interno dell'applicazione.

Questo laboratorio non dimostra l'intera catena di esecuzione remota di codice non autenticata. Valida il comportamento HTTP non autenticato osservato nel target locale FOSSBilling 0.7.2 e lo confronta con FOSSBilling 0.8.0. L'intera catena pubblica coinvolge comportamenti aggiuntivi di autorizzazione API oltre alla validazione sicura dell'espressione Twig mostrata qui.

Il laboratorio non dimostra:

* esecuzione remota di comandi,
* estrazione di credenziali,
* dump del database,
* installazione di estensioni,
* scrittura arbitraria di file,
* persistenza,
* upload di web shell,
* callback esterni,
* attacchi contro sistemi non di laboratorio,
* o attività di post-exploitazione.

## Root Cause Summary

La causa principale di CVE-2026-28496 è il rendering non sicuro dei template Twig.

FOSSBilling utilizza Twig per renderizzare template dinamici. Nelle versioni vulnerabili, una stringa di template fornita può essere passata nella logica di rendering di Twig senza sufficienti restrizioni di sandbox.

Il comportamento vulnerabile può essere riassunto come:```text
Input template string
→ FOSSBilling API receives _tpl
→ System\Api\Admin::string_render() reads _tpl
→ System\Service::renderString() receives the template string
→ Twig creates a template from the supplied string
→ Twig evaluates the expression
→ rendered output is returned in the HTTP response

Il design corretto in FOSSBilling 0.8.0 rafforza il comportamento vulnerabile. In questo laboratorio, il target corretto non espone più la chiamata API testata:```json
{"result":null,"error":{"message":"Unknown API call system/system/string_render","code":879}}

## Analisi del Codice Sorgente

Il comportamento HTTP vulnerabile è supportato dal percorso del codice sorgente in FOSSBilling 0.7.2.

Il metodo API riceve `_tpl` dai dati della richiesta e lo passa al renderer del servizio di sistema.

Punto di ingresso vulnerabile rilevante:```php
public function string_render($data)
{
    if (!isset($data['_tpl'])) {
        error_log('_tpl parameter not passed');
        return '';
    }

    $tpl = $data['_tpl'];
    $try_render = $data['_try'] ?? false;

    $vars = $data;
    unset($vars['_tpl'], $vars['_try']);

    return $this->getService()->renderString($tpl, $try_render, $vars);
}

In FOSSBilling 0.7.2, `renderString()` tenta di caricare il valore fornito come nome di un template. Se fallisce, tratta il valore fornito come una stringa di template e lo passa a `createTemplateFromString()`. Flusso vulnerabile semplificato:```php
public function renderString($tpl, $try_render, $vars)
{
    $twig = $this->di['twig'];

    try {
        $template = $twig->load($tpl);
        $parsed = $template->render($vars);
    } catch (\Exception) {
        // $twig->load throws an exception when $tpl is a raw template string
        $parsed = $this->createTemplateFromString($tpl, $try_render, $vars);
    }

    return $parsed;
}

Tuttavia, la causa principale è più critica per la sicurezza rispetto alla valutazione di espressioni aritmetiche. Nei contesti di rendering vulnerabili, i template Twig possono interagire con oggetti dell'applicazione presenti nell'ambiente del template. Ricerche pubbliche descrivono catene di impatto maggiore in cui gli oggetti di contesto API possono esporre l'accesso a componenti interni dell'applicazione, come il contenitore per l'iniezione delle dipendenze.

Un controllo di regressione a livello di codice sorgente ha confermato il comportamento più profondo:```text
FOSSBilling 0.7.2:
  {{ guest.getDi() }}
  → DI_VISIBLE

FOSSBilling 0.8.0:
  {{ guest.getDi() }}
  → blocked by Twig sandbox policy

Il renderer sandboxed crea e renderizza un template, ma cattura le violazioni del sandbox di Twig e le converte in un errore controllato dell'applicazione:```php
final class SandboxedStringRenderer
{
    public static function render(
        Environment $twig,
        string $content,
        array $context = [],
        string $name = 'template'
    ): string {
        try {
            return $twig->createTemplate($content)->render($context);
        } catch (SecurityError $e) {
            throw new InformationException(
                '%name% contains disallowed Twig syntax: %error%',
                [
                    '%name%' => $name,
                    '%error%' => $e->getMessage(),
                ]
            );
        }
    }
}

Il cambiamento rilevante per la sicurezza è:```text
Before:
  request-controlled template string
  → Twig createTemplate()
  → render without the patched sandbox boundary

After:
  template string rendering
  → SandboxedStringRenderer
  → Twig sandbox policy
  → method/property access denied by default

Questo fornisce due utili livelli di validazione:```text
HTTP behavior validation:
  0.7.2 renders {{ 7*7 }} through /api/system/system/string_render.
  0.8.0 does not expose the same API behavior.

Source/root-cause validation:
  0.7.2 allows unsafe Twig rendering behavior.
  0.8.0 introduces sandboxed string rendering and blocks method/property access.

## Architettura del laboratorio

Il laboratorio esegue due installazioni isolate di FOSSBilling tramite Docker Compose.```text
.
├── docker-compose.yml
├── vuln/
│   └── Dockerfile
├── patched/
│   └── Dockerfile
├── poc/
│   └── poc.py
├── scripts/
│   └── auto-install.sh
├── README.md
└── .gitignore

Service	Component	Version / Role
vuln	FOSSBilling	applicazione target vulnerabile
patched	FOSSBilling	applicazione target patchata
vuln-db	MariaDB	database per target vulnerabile
patched-db	MariaDB	database per target patchato
installer-vuln	curl sidecar	installa automaticamente target vulnerabile
installer-patched	curl sidecar	installa automaticamente target patchato

Il laboratorio utilizza versioni fissate di FOSSBilling:

| Obiettivo                | Versione FOSSBilling | Comportamento previsto                                   |
| --------------------- | ------------------: | --------------------------------------------------- |
| http://localhost:8081 |               0.7.2 | rende `{{ 7*7 }}` attraverso il percorso API vulnerabile |
| http://localhost:8082 |               0.8.0 | non espone lo stesso comportamento API vulnerabile    |

I sidecar di installazione vengono eseguiti automaticamente durante `docker compose up`. Inizializzano entrambi i target FOSSBilling con credenziali di database locali usa-e-getta e poi escono.

Il laboratorio non crea né modifica il percorso API vulnerabile.

Il percorso `/api/system/system/string_render` è fornito dall'applicazione FOSSBilling nel target vulnerabile 0.7.2 dopo l'installazione. Il laboratorio Docker installa solo l'applicazione tramite il suo normale flusso di installazione e poi invia una richiesta HTTP all'endpoint esistente dell'applicazione.

Il target corretto 0.8.0 restituisce `Unknown API call system/system/string_render`, il che conferma che il comportamento del percorso testato proviene dalla versione dell'applicazione stessa e non da un percorso creato dal laboratorio.

## Requisiti

* Docker Desktop o Docker Engine
* Docker Compose v2
* Python 3
* Accesso a Internet durante il primo pull dell'immagine Docker

Nessun pacchetto Python di terze parti è richiesto. Il PoC utilizza solo moduli della libreria standard di Python.

## Avvio Rapido

Avvia il laboratorio da uno stato pulito:```bash
docker compose down -v --remove-orphans
docker compose up -d --build

Il PoC è solo HTTP. Non chiama Docker, Docker Compose, comandi shell, WP-CLI o API del contenitore.

## Risultati attesi

### Target vulnerabile

Comando:```bash
python3 poc/poc.py --url http://localhost:8081

La differenza importante è:```text
FOSSBilling 0.7.2
→ renders {{ 7*7 }}
→ returns 49

FOSSBilling 0.8.0
→ does not render the supplied template through this API path
→ returns an API error

Per una validazione più approfondita della causa principale a livello di codice sorgente, l'accesso al metodo è una prova più forte del problema sottostante. Tuttavia, il PoC pubblico in questo repository utilizza l'espressione aritmetica più sicura per evitare di dimostrare una catena ad alto impatto.

## Riproduzione manuale HTTP con curl

Probe vulnerabile:```bash
curl -i -X POST \
  'http://127.0.0.1:8081/api/system/system/string_render' \
  -H 'Content-Type: application/json' \
  --data '{"_tpl":"{{ 7*7 }}"}'

## Impact

L'Iniezione di Template Lato Server (Server-Side Template Injection) in una piattaforma di fatturazione e gestione clienti è sensibile dal punto di vista della sicurezza perché l'applicazione può memorizzare record dei clienti, dati di fatturazione, credenziali del server, configurazione dei pagamenti e logica di automazione controllata dall'amministratore.

Il payload di laboratorio dimostrato è innocuo e valuta soltanto:```twig
{{ 7*7 }}

Azioni di monitoraggio raccomandate:

* Esaminare i log di accesso del server web per `/api/system/system/string_render`.
* Esaminare le richieste contenenti `_tpl` nei corpi delle richieste JSON.
* Esaminare le richieste contenenti sintassi Twig come `{{` e `}}`.
* Esaminare le risposte API riuscite che contengono output di template renderizzato.
* Esaminare le risposte API fallite per tentativi sospetti di rendering di template.
* Esaminare l'attività degli amministratori se si sospetta uno sfruttamento.
* Esaminare le modifiche alla configurazione di template, email, mailer di massa e adattatori di pagamento.
* Esaminare i log dell'applicazione per errori di rendering di template o chiamate API inaspettate.

Idea di rilevamento ad alta segnaletica:```text
POST request to /api/system/system/string_render
AND request body contains "_tpl"
AND request body contains "{{"

## Mitigazione e note sulla patch

Aggiorna FOSSBilling alla versione 0.8.0 o successiva.

Per gli ambienti di produzione, aggiorna all'ultima versione disponibile, non limitarti alla versione di confronto del laboratorio.

Passaggi di mitigazione consigliati:

* Aggiorna FOSSBilling a 0.8.0 o successiva.
* Verifica che la versione installata non sia nell'intervallo interessato.
* Limita l'accesso pubblico ai percorsi API amministrativi ove possibile.
* Esamina i log di accesso web per richieste a `/api/system/system/string_render`.
* Controlla template, template email, mailing di massa e adattatori di pagamento personalizzati per sintassi Twig sospetta.
* Ruota i segreti se si sospetta uno sfruttamento.
* Esamina i record di clienti, fatturazione, pagamenti e gestione server per accessi non autorizzati.
* Tratta le regole WAF o i blocchi del proxy inverso come controlli temporanei, non come sostituti dell'aggiornamento.

Lezioni di ingegneria della sicurezza:

* Non eseguire il rendering di stringhe di template non attendibili in un contesto applicativo privilegiato.
* Non esporre i contenitori dei servizi applicativi ai contesti dei template.
* Utilizza il rendering di template in sandbox per funzionalità template controllate dall'utente o dall'amministratore.
* Nega l'accesso a metodi e proprietà a meno che non sia esplicitamente richiesto.
* Mantieni gli errori di autorizzazione API espliciti e fallisci in modo chiuso.
* Tratta le funzionalità di rendering dei template come superfici adiacenti all'esecuzione del codice.

## Comandi di verifica utili

Controlla lo stato del contenitore:```bash
docker compose ps -a

Richiesta di patch manuale:```bash
curl -i -X POST \
  'http://127.0.0.1:8082/api/system/system/string_render' \
  -H 'Content-Type: application/json' \
  --data '{"_tpl":"{{ 7*7 }}"}'

Ispeziona il renderer sandbox patchato dall'albero sorgente estratto:```bash
git checkout 0.8.0

grep -R "SandboxedStringRenderer" -n src/modules src/library | head -30
grep -R "\$methods = \[\]\|\$properties = \[\]" -n src/library/FOSSBilling/Twig

Verifica le intestazioni della risposta di FOSSBilling:```bash
curl -i http://127.0.0.1:8081 | grep -i 'x-fossbilling-version'
curl -i http://127.0.0.1:8082 | grep -i 'x-fossbilling-version'

## Limiti di Sicurezza

Questo laboratorio è destinato esclusivamente a ricerca di sicurezza locale e dimostrazioni controllate.

Non eseguire il PoC o richieste curl manuali contro sistemi che non possiedi o per cui non hai esplicita autorizzazione al test.

Non utilizzare credenziali reali di produzione, dati dei clienti, dati di pagamento, chiavi API o segreti di produzione in questo laboratorio.

L'ambito previsto è limitato a servizi Docker locali come:```text
http://localhost:8081
http://localhost:8082
http://127.0.0.1:8081
http://127.0.0.1:8082

## Riferimenti

* Record CVE: CVE-2026-28496
  https://www.cve.org/CVERecord?id=CVE-2026-28496

* Avviso GitHub: GHSA-57mv-jm88-66jc
  https://github.com/FOSSBilling/FOSSBilling/security/advisories/GHSA-57mv-jm88-66jc

* VulnCheck: FOSSBilling Auth Bypass and Twig SSTI to Unauthenticated RCE
  https://www.vulncheck.com/blog/fossbilling-auth-bypass-ssti-rce

* Documentazione Docker di FOSSBilling
  https://docs.fossbilling.org/getting-started/docker/

* Repository GitHub di FOSSBilling
  https://github.com/FOSSBilling/FOSSBilling

* Immagine Docker di FOSSBilling
  https://hub.docker.com/r/fossbilling/fossbilling

* Documentazione Twig: Estensione Sandbox
  https://twig.symfony.com/doc/3.x/sandbox.html

CVE-2026-28496-Lab

Più Popolari

Riepilogo della Patch di Origine

Come funziona la validazione

Rilevamento e Monitoraggio

Pulizia

vuln	0.7.2	Target di confronto vulnerabile	http://localhost:8081
patched	0.8.0	Target di confronto corretto	http://localhost:8082