s3v3n-jg/cve-2026-76460Laboratorio Flask didattico che simula il bypass di autenticazione CVE-2026-76460, con modalità vulnerabile, sicura e strict, più uno script di exploit PoC e un harness per pentest.
Questo progetto dimostra uno scenario simulato di bypass dell'autenticazione ispirato a CVE-2026-76460. Il laboratorio è intenzionalmente didattico e sicuro: è un'API Flask locale che simula il comportamento vulnerabile e quello corretto senza prendere di mira sistemi reali.
L'applicazione mostra come un'API di gestione privilegiata possa essere esposta senza controlli di autenticazione, e come un'implementazione sicura blocchi l'accesso non autenticato.
flowchart LR
Client[Local client or test harness] --> Entry[app.py]
Entry --> Factory[security_lab.factory]
Factory --> Mode{Lab mode}
Mode -->|vulnerable| Open[Management users endpoint\nallows anonymous access]
Mode -->|secure| Bearer[Bearer token validation]
Mode -->|secure-strict| Admin[Bearer token + admin role]
Bearer --> Result[200 or 401 response]
Admin --> Result2[200, 401, or 403 response]
Open --> Result3[200 response with warning]
Factory --> Audit[Audit logger]
Audit --> Log[audit.log].
├── app.py # entry point for the local lab
├── build.sh # creates the venv, installs dependencies, and runs checks
├── run.sh # starts the vulnerable app locally
├── pyproject.toml # project metadata and tool configuration
├── gunicorn.conf.py # deployment configuration for a production-style server
├── src/
│ └── security_lab/
│ ├── __init__.py
│ ├── config.py # lab settings and valid tokens
│ ├── audit.py # file-based audit logger
│ └── factory.py # Flask routes and auth logic
├── tests/
│ └── test_api.py # regression tests for vulnerable and secure modes
├── exploit.py # proof-of-concept route attack script
├── pentest_harness.py # CLI verification helper
├── BUILD_GUIDE.md # build and OS details
├── WALKTHROUGH.md # step-by-step lab walkthrough
├── SECURITY_REPORT.md # summary of the mock vulnerability and fix
├── CONTRIBUTING.md # contribution workflow
├── LICENSE # MIT license
├── requirements.txt # pinned dependencies
├── .env.example # sample environment configuration
└── .github/workflows/
└── python-tests.yml # CI validation for push and pull requests
chmod +x build.sh run.sh
./build.sh
./run.sh
Poi testala con:
curl -i http://127.0.0.1:5000/api/management/users
$ curl -i http://127.0.0.1:5000/api/management/users
HTTP/1.1 200 OK
Content-Type: application/json
{
"users": [
{"id": 1, "username": "admin", "role": "super-admin"},
{"id": 2, "username": "operator", "role": "operator"}
],
"warning": "unauthenticated access allowed"
}
source .venv/bin/activate
python exploit.py --host 127.0.0.1 --port 5000
source .venv/bin/activate
python pentest_harness.py --mode vulnerable
python pentest_harness.py --mode secure
python pentest_harness.py --mode secure-strict
/api/management/users.403.make lint
make test
Ogni push e pull request verso main esegue Ruff e la suite pytest sulle versioni di Python supportate. Una release viene creata effettuando il push di un tag di versione dopo che questi controlli sono passati:
git tag v0.1.0
git push origin v0.1.0
Il workflow del tag crea una GitHub Release con note di rilascio generate automaticamente. Le release sono destinate al codice sorgente e alla documentazione del laboratorio didattico; non includere materiale di exploit per sistemi reali.
Questo è un ambiente di laboratorio controllato, solo per test, apprendimento e ricerca difensiva. Non deve essere utilizzato contro sistemi reali senza autorizzazione.