
Laboratório Flask educacional que simula o bypass de autenticação CVE-2026-76460, com modos vulnerável, seguro e estrito, além de um script de exploit PoC e um harness de pentest.
Este projeto demonstra um cenário simulado de bypass de autenticação inspirado na CVE-2026-76460. O laboratório é intencionalmente educacional e seguro: é uma API Flask local que simula o comportamento vulnerável e corrigido sem atingir sistemas reais.
A aplicação mostra como uma API de gerenciamento privilegiada pode ser exposta sem controles de autenticação, e como uma implementação segura bloqueia o acesso não 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
Em seguida, teste-a com:
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
Todo push e pull request direcionado à branch main executa o Ruff e a suíte pytest nas versões suportadas do Python. Uma release é criada ao enviar uma tag de versão após essas verificações passarem:
git tag v0.1.0
git push origin v0.1.0
O workflow da tag cria uma GitHub Release com notas de release geradas automaticamente. As releases destinam-se ao código-fonte e à documentação do laboratório educacional; não empacote material de exploit para sistemas reais.
Este é um ambiente de laboratório controlado apenas para testes, aprendizado e pesquisa defensiva. Não deve ser usado contra sistemas reais sem autorização.