s3v3n-jg/cve-2026-76460Bildungslabor auf Flask-Basis zur Simulation der Authentifizierungsumgehung CVE-2026-76460, mit verwundbaren, sicheren und strikten Modi sowie einem PoC-Exploit-Skript und einem Pentest-Harness.
Dieses Projekt demonstriert ein simuliertes Authentication-Bypass-Szenario, inspiriert von CVE-2026-76460. Das Lab ist bewusst lehrreich und sicher: Es handelt sich um eine lokale Flask-API, die das verwundbare und das gepatchte Verhalten simuliert, ohne echte Systeme anzugreifen.
Die Anwendung zeigt, wie eine privilegierte Management-API ohne Authentifizierungskontrollen exponiert werden kann und wie eine sichere Implementierung unauthentifizierten Zugriff blockiert.
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
Anschließend testen mit:
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 zugreifen.403 abgelehnt.make lint
make test
Jeder Push und jeder Pull Request, der auf main abzielt, führt Ruff und die pytest-Suite auf den unterstützten Python-Versionen aus. Ein Release wird erstellt, indem nach erfolgreichem Abschluss dieser Checks ein Versions-Tag gepusht wird:
git tag v0.1.0
git push origin v0.1.0
Der Tag-Workflow erstellt ein GitHub-Release mit generierten Release-Notes. Releases sind für den Quellcode und die Dokumentation des Lehr-Labs gedacht; verpacken Sie kein echtes Exploit-Material für Zielsysteme.
Dies ist eine kontrollierte Lab-Umgebung ausschließlich für Tests, Lernen und defensive Forschung. Sie darf nicht ohne Autorisierung gegen echte Systeme eingesetzt werden.