s3v3n-jg/cve-2026-76460Educational Flask lab simulating CVE-2026-76460 authentication bypass, with vulnerable, secure, and strict modes plus a PoC exploit script and pentest harness.
This project demonstrates a mock authentication-bypass scenario inspired by CVE-2026-76460. The lab is intentionally educational and safe: it is a local Flask API that simulates the vulnerable and patched behavior without targeting real systems.
The application shows how a privileged management API can be exposed without authentication controls, and how a secure implementation blocks unauthenticated access.
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
Then test it with:
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
Every push and pull request targeting main runs Ruff and the pytest suite on the supported Python versions. A release is created by pushing a version tag after those checks pass:
git tag v0.1.0
git push origin v0.1.0
The tag workflow creates a GitHub Release with generated release notes. Releases are intended for the educational lab source and documentation; do not package real target-system exploit material.
This is a controlled lab environment for testing, learning, and defensive research only. It must not be used against real systems without authorization.