CVE-2026-76460

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.

Goal

The application shows how a privileged management API can be exposed without authentication controls, and how a secure implementation blocks unauthenticated access.

Project architecture

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

Local setup

chmod +x build.sh run.sh
./build.sh

Run the vulnerable app

./run.sh

Then test it with:

curl -i http://127.0.0.1:5000/api/management/users

Example output

$ 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"
}

Exploit proof of concept

source .venv/bin/activate
python exploit.py --host 127.0.0.1 --port 5000

CLI pentest harness

source .venv/bin/activate
python pentest_harness.py --mode vulnerable
python pentest_harness.py --mode secure
python pentest_harness.py --mode secure-strict

Expected behavior

• Vulnerable mode: unauthenticated requests can access /api/management/users.
• Secure mode: the same endpoint requires a valid bearer token and rejects anonymous access.
• Secure-strict mode: only a valid admin token can access the privileged endpoint; operator tokens are rejected with 403.

Validation and linting

make lint
make test

Releases and checks

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.

Important notice

This is a controlled lab environment for testing, learning, and defensive research only. It must not be used against real systems without authorization.