s3v3n-jg/cve-2026-76460Laboratorio educativo de Flask que simula el bypass de autenticación CVE-2026-76460, con modos vulnerable, seguro y estricto, además de un script de exploit PoC y un harness de pentest.
Este proyecto demuestra un escenario simulado de omisión de autenticación inspirado en CVE-2026-76460. El laboratorio es intencionalmente educativo y seguro: es una API Flask local que simula el comportamiento vulnerable y parcheado sin atacar sistemas reales.
La aplicación muestra cómo una API de gestión privilegiada puede quedar expuesta sin controles de autenticación, y cómo una implementación segura bloquea el acceso no autenticado.
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
Luego pruébala 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
Cada push y pull request dirigido a main ejecuta Ruff y la suite de pytest en las versiones de Python compatibles. Se crea un release al hacer push de una etiqueta de versión después de que esas comprobaciones pasen:
git tag v0.1.0
git push origin v0.1.0
El flujo de trabajo de la etiqueta crea un GitHub Release con notas de versión generadas. Los releases están destinados al código fuente y la documentación del laboratorio educativo; no empaquetes material real de explotación contra sistemas objetivo.
Este es un entorno de laboratorio controlado únicamente para pruebas, aprendizaje e investigación defensiva. No debe usarse contra sistemas reales sin autorización.