s3v3n-jg/cve-2026-76460Lab Flask éducatif simulant un contournement d'authentification CVE-2026-76460, avec des modes vulnérable, sécurisé et strict, ainsi qu'un script d'exploit PoC et un harnais de pentest.
Ce projet illustre un scénario simulé de contournement d'authentification inspiré de CVE-2026-76460. Le laboratoire est volontairement éducatif et sûr : il s'agit d'une API Flask locale qui simule le comportement vulnérable et corrigé sans cibler de systèmes réels.
L'application montre comment une API de gestion privilégiée peut être exposée sans contrôles d'authentification, et comment une implémentation sécurisée bloque les accès non authentifiés.
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
Puis testez-la avec :
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
Chaque push et pull request ciblant main exécute Ruff et la suite pytest sur les versions de Python prises en charge. Une version est créée en poussant un tag de version après la réussite de ces vérifications :
git tag v0.1.0
git push origin v0.1.0
Le workflow de tag crée une GitHub Release avec des notes de version générées. Les versions sont destinées au code source et à la documentation du laboratoire éducatif ; ne pas empaqueter de matériel d'exploitation réel ciblant des systèmes.
Il s'agit d'un environnement de laboratoire contrôlé destiné uniquement aux tests, à l'apprentissage et à la recherche défensive. Il ne doit pas être utilisé contre des systèmes réels sans autorisation.