ErrorSomething went wrong.

F 4/100

Security verdict · Critical Risk

F4/100

adeyosemanputra/pygoat

Serious issues. Don’t ship this one yet.

Code F·Dependencies F

#19d17cc ·just now·1m 21s·191 findings· Code deleted

Every finding carries a weight by severity. They add up, and the total goes through one fixed formula.

Severity	Each	Code	Deps
Critical	×10	36→360	10→100
High	×5	0	63→315
Medium	×2	12→24	57→114
Low	×1	0	13→13
AI review discount: 8 findings judged less likely to be real		−53
Total weight		331	542

score = 100 × 40 ÷ (40 + W)→ code 11 (F)· deps 7 (F)

40 is a fixed constant, identical for every scan. Grades: A is 90+, B 70+, C 50+, D 25+. Together they weigh 873, which is the 4 at the top.

The prompt covers the 25 heaviest: 4 → 6 (F).166 findings left for the round after.

An A takes the 187 heaviest gone.One Critical outranks ten Lows.

Critical

High

Medium

Low

Fix prompt

Your 25 worst first, 166 still to go

claude_code_prompt.md

# Fix 25 security vulnerabilities in this repository

**25 CRITICAL** — exploitable now, fix these first

> 🔑 7 of these are **leaked credentials**. Those need manual steps from you (marked below) — an AI tool cannot rotate keys for you.

## 🔑 Rotate these leaked credentials first — steps only YOU can do

Every finding marked 🔑 below is a leaked credential. Changing the code is NOT enough: the value is already in your git history, so treat it as stolen. An AI tool cannot rotate credentials for you — do the steps for each type, then apply the code changes below.

**Third-party API keys** (`dockerized_labs/sensitive_data_exposure/sensitive_data_lab/settings.py`, `introduction/static/js/a9.js`, `pygoat/settings.py`, `introduction/static/js/a7.js`):
1. Log in to the service that issued it (Stripe, AWS, OpenAI, …) and **revoke the key**.
2. Generate a new one and store it in an environment variable (for example a `.env` file listed in `.gitignore`). Never paste it into source code.

**Hardcoded passwords** (`introduction/playground/A9/api.py`, `introduction/playground/A9/archive.py`, `introduction/views.py`):
No provider is involved — you choose the replacement yourself.
1. Pick a new strong password (a password manager can generate one).
2. Treat the old one as already stolen: if it was reused anywhere else, change it there too.
3. **Where the new password lives is decided by each fix below, not here.** Most fixes replace the hardcoded check with your framework's own login (for example Django's `authenticate()`), which reads the user table — so the new password belongs in a real user account (`User.objects.create_user(...)` hashes it for you), NOT in an environment variable. Only put a hash in an env var if the fix for that specific finding says to. Doing both is what breaks login.

You are running in this repository with file access and a shell. Work through the findings below one at a time, most severe first. After each fix, run the project's tests before moving on.

## 1. [CRITICAL] flask-debug-mode-on
- **File:** `dockerized_labs/broken_auth_lab/app.py` (line 123)
- **Problem:** When Flask debug mode is enabled on a public-facing server, anyone who causes an application error can access an interactive Python console in their browser and run arbitrary code with the privileges of the web server process.
- **Fix:**

Replace the hardcoded `debug=True` with a value read from an environment variable at startup. Change line 123 to:

```python
if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000, debug=os.getenv('FLASK_DEBUG') == 'True')
```

Add `import os` at the top of the file. This way debug mode is off by default in production and only enabled when explicitly set by the deployment environment.

## 2. [CRITICAL] pci-card-number-hardcoded
- **File:** `dockerized_labs/sensitive_data_exposure/dataexposure/views.py` (lines 80, 96, 56)
- **Problem:** A valid Visa card number is stored in plain text in the source code and will be committed to version control, where it becomes readable to anyone with repository access—and if the repo is ever leaked, exposed online, or accessed by an attacker, they can use this card number to make fraudulent charges.
- **Fix:**

Remove the hardcoded card number entirely. If you need to demonstrate payment functionality, use a payment tokenisation service (Stripe, Razorpay, or similar) that never exposes the real card number to your application code, or use a test token provided by your payment processor instead of a raw PAN. Replace line 56 with something like `credit_card='tok_visa'` (a Stripe test token) or `None`, and never store actual card numbers in your database or code.

## 3. [CRITICAL] hardcoded-api-key-python
- **File:** `dockerized_labs/sensitive_data_exposure/sensitive_data_lab/settings.py` (line 8)
- **Problem:** An attacker with access to this source code repository can read the Django secret key directly from the file, then use it to forge session tokens, tamper with signed data, or impersonate any user in the application.
> 🔑 **Leaked credential** — do the rotation steps at the top of this prompt first, then apply this code change:

Replace the hardcoded string on line 8 with a load from an environment variable. Since `os` is already imported, change line 8 to `SECRET_KEY = os.environ['SECRET_KEY']` — using square brackets (not `.get()`) so the application fails loudly at startup if the variable is missing, rather than silently using an empty default that would hide a credential rotation failure. The secret key must then be supplied by the deployment environment (container, CI/CD, or secrets manager) and never committed to version control.

## 4. [CRITICAL] unsafe-yaml-load-python
- **File:** `introduction/lab_code/test.py` (line 23)
- **Problem:** If the YAML file at `/home/fox/test.yaml` is controlled or influenced by an attacker, they can embed malicious Python code in it that will execute on your server the moment line 23 parses it, giving them full control of the application.
- **Fix:**

Replace `yaml.load(stream)` with `yaml.safe_load(stream)` on line 23. The `yaml` module is already imported, so no new imports are needed. `yaml.safe_load()` parses YAML the same way but blocks arbitrary object instantiation and code execution:

```python
data = yaml.safe_load(stream)
```

## 5. [CRITICAL] weak-password-hash-python
- **File:** `introduction/mitre.py` (line 161)
- **Problem:** An attacker who obtains the password database can crack every password in seconds using a GPU, because MD5 is a fast general-purpose hash designed for checksums, not for storing credentials.
- **Fix:**

Replace the MD5 hash with Django's built-in password verification. Change line 161 from `password = md5(password.encode()).hexdigest()` to use `django.contrib.auth.hashers.check_password()` against the stored hash, or refactor to use Django's authenticate() method if this follows standard Django user models. Fast hashes like MD5 are cryptographically broken for password storage; Django's default hasher uses PBKDF2 with a salt and many iterations, making brute-force attacks impractical.

## 6. [CRITICAL] command-injection-python
- **File:** `introduction/mitre.py` (line 218)
- **Problem:** An attacker can submit arbitrary Python code in the `expression` POST parameter, which will be executed on the server with full privileges, allowing them to read files, modify data, or take over the application.
- **Fix:**

Replace `eval(expression)` with a safe expression parser. If you need to evaluate only mathematical expressions, use the `ast` module with a custom visitor that only allows specific operations—for example, parse with `ast.parse(expression, mode='eval')` and walk the tree to reject function calls, imports, and attribute access. If full Python evaluation is required, this endpoint should not exist; if it must, restrict it to a whitelist of safe functions and validate the input against that list before any execution attempt.

## 7. [CRITICAL] password-compared-to-literal-python
- **File:** `introduction/playground/A9/api.py` (line 17)
- **Problem:** An attacker with read access to the repository source code can see the password `"admin"` in plain text on line 17, and anyone who guesses or obtains this literal string can log in; the password cannot be changed without redeploying the application.
> 🔑 **Leaked credential** — do the rotation steps at the top of this prompt first, then apply this code change:

Use Django's built-in authentication system (`django.contrib.auth.authenticate()` and `check_password()`) or store a salted hash of the password in a database or environment variable, then compare the submitted password against that hash using `check_password()` from `django.contrib.auth.hashers`. For example:

```python
from django.contrib.auth.hashers import check_password

if username == "admin" and check_password(password, stored_hash):
    return JsonResponse({"message":"Loged in successfully", "method":"post"},status = 200)
```

This ensures the real password never appears in source code and can be rotated by updating the stored hash without redeployment.

## 8. [CRITICAL] password-compared-to-literal-python
- **File:** `introduction/playground/A9/archive.py` (line 17)
- **Problem:** An attacker with read access to the source code repository can extract the hardcoded password "admin" from line 17, and because the password is stored in plain text rather than as a hash, there is no way to rotate it without deploying new code.
> 🔑 **Leaked credential** — do the rotation steps at the top of this prompt first, then apply this code change:

Use Django's built-in authentication system instead of a hardcoded string comparison. Replace the manual check with `from django.contrib.auth import authenticate` and call `user = authenticate(request, username=username, password=password)` — this verifies credentials against Django's password hasher (which uses salted hashing and constant-time comparison), and allows passwords to be changed through normal user management without code deployment. Store the real admin credentials in Django's user database, not in source code.

## 9. [CRITICAL] jwt
- **File:** `introduction/static/js/a7.js` (line 4)
- **Problem:** This secret is committed to your git history, so anyone who can read the repository — now, or if it is ever shared, forked, or leaked — can use it.
- **Fix:**

Immediately rotate this credential — revoke the exposed key and issue a new one. Deleting it from the current code is not enough; it stays in git history, so the old value must be treated as already compromised.

## 10. [CRITICAL] jwt
- **File:** `introduction/static/js/a9.js` (line 18)
- **Problem:** This secret is committed to your git history, so anyone who can read the repository — now, or if it is ever shared, forked, or leaked — can use it.
- **Fix:**

Immediately rotate this credential — revoke the exposed key and issue a new one. Deleting it from the current code is not enough; it stays in git history, so the old value must be treated as already compromised.

## 11. [CRITICAL] generic-api-key
- **File:** `introduction/static/js/a9.js` (line 21)
- **Problem:** This secret is committed to your git history, so anyone who can read the repository — now, or if it is ever shared, forked, or leaked — can use it.
> 🔑 **Leaked credential** — do the rotation steps at the top of this prompt first, then apply this code change:

Immediately rotate this credential — revoke the exposed key and issue a new one. Deleting it from the current code is not enough; it stays in git history, so the old value must be treated as already compromised.

## 12. [CRITICAL] weak-password-hash-python
- **File:** `introduction/utility.py` (line 59)
- **Problem:** An attacker who obtains the password database can use a graphics card to crack any password in seconds, because SHA-256 is designed to be fast; reversing the hash string does not add security.
- **Fix:**

Replace the `customHash` function with Django's built-in password hasher. Change line 58–59 to:
```python
from django.contrib.auth.hashers import make_password

def customHash(password):
    return make_password(password)
```
Django's `make_password` uses PBKDF2 with salt and thousands of iterations by default, making brute-force attacks impractical. If this function is called during login, use `check_password(submitted_password, stored_hash)` to verify instead of comparing strings directly.

## 13. [CRITICAL] password-compared-to-literal-python
- **File:** `introduction/views.py` (lines 766, 806, 831, 833, 1072)
- **Problem:** An attacker with read access to the repository source code can see the password "jacktheripper" in plain text, and because it is hardcoded there is no way to rotate it without deploying new code.
> 🔑 **Leaked credential** — do the rotation steps at the top of this prompt first, then apply this code change:

Use Django's built-in `authenticate()` function and `check_password()` method instead of string comparison. Store only a salted hash of the password in your database or settings, then call `check_password(password, stored_hash)` at line 766; this performs a constant-time comparison and prevents the real password from ever existing in source code. For example: `if name == 'jack' and check_password(password, stored_hash_for_jack):` where `stored_hash_for_jack` is a bcrypt or Argon2 hash retrieved from configuration or the database.

## 14. [CRITICAL] sql-injection-string-concat-python
- **File:** `introduction/views.py` (lines 158, 864)
- **Problem:** An attacker can inject SQL commands through the `name` or `password` fields — for example, entering `' OR '1'='1` as the name — to bypass the password check, read other users' data, or modify the database.
- **Fix:**

Replace the string concatenation with Django's parameterised query syntax. Change line 158 from:
```python
sql_query = "SELECT * FROM introduction_login WHERE user='"+name+"' AND password='"+password+"'"
val=login.objects.raw(sql_query)
```
to:
```python
val=login.objects.raw("SELECT * FROM introduction_login WHERE user=%s AND password=%s", [name, password])
```
The `%s` placeholders and parameter list ensure user input is treated as data, not executable SQL.

## 15. [CRITICAL] command-injection-python
- **File:** `introduction/views.py` (line 460)
- **Problem:** An attacker can submit arbitrary Python code as the `val` parameter, and `eval()` will execute it with the full privileges of the application, allowing them to read files, modify data, steal secrets, or take control of the server.
- **Fix:**

Replace `eval(val)` with a safe expression parser. If the intent is to evaluate only arithmetic expressions, use `ast.literal_eval()` for literals only, or import and use a library like `numexpr` or `simpleeval` that safely evaluates mathematical expressions without executing arbitrary code. For example:

```python
from simpleeval import simple_eval
try:
    output = simple_eval(val)
except Exception:
    output = "Something went wrong"
```

This prevents code injection while still allowing legitimate calculation inputs.

## 16. [CRITICAL] unsafe-yaml-load-python
- **File:** `introduction/views.py` (line 560)
- **Problem:** An attacker can upload a malicious YAML file that runs arbitrary Python code on the server when the file is parsed, because `yaml.Loader` deserializes Python objects without restriction.
- **Fix:**

Replace `yaml.load(file, yaml.Loader)` with `yaml.safe_load(file)` on line 560. `yaml.safe_load()` parses YAML syntax safely without instantiating arbitrary Python objects, preventing code execution while still returning the data the application needs. Note that `yaml` is not currently imported in the shown imports — add `import yaml` at the top of the file if it is not already present elsewhere in the file.

## 17. [CRITICAL] path-traversal-user-path-python
- **File:** `introduction/views.py` (lines 926, 927)
- **Problem:** An attacker can supply a file path like `../../.env` in the POST parameter `blog`, and because the code joins it directly to the directory without validation, they can read any file on the server outside the intended directory — including environment files with credentials, configuration, or source code.
- **Fix:**

Import `secure_filename` from `werkzeug.utils` (add to imports: `from werkzeug.utils import secure_filename`), then on line 926 replace `filename = os.path.join(dirname, file)` with `filename = os.path.join(dirname, secure_filename(file))`. This strips path traversal sequences like `../` and only allows safe filename characters, ensuring the user input cannot escape the base directory.

## 18. [CRITICAL] ssrf-user-url-python
- **File:** `introduction/views.py` (line 963)
- **Problem:** An attacker can submit any URL — including internal services like `http://localhost:8000/admin`, `http://169.254.169.254/` (AWS metadata), or internal IP ranges — and the code will fetch it and return the response content to them, leaking sensitive data from inside your network that they couldn't reach directly.
- **Fix:**

Before calling `requests.get(url)` on line 963, parse the URL and validate that its hostname is in an allowlist of permitted external domains. For example:

```python
from urllib.parse import urlparse

url = request.POST["url"]
try:
    parsed = urlparse(url)
    allowed_hosts = {"example.com", "api.example.com"}  # Set your permitted hosts
    if parsed.hostname not in allowed_hosts:
        return render(request, "Lab/ssrf/ssrf_lab2.html", {"error": "Host not allowed"})
    response = requests.get(url)
    return render(request, "Lab/ssrf/ssrf_lab2.html", {"response": response.content.decode()})
except requests.RequestException:
    return render(request, "Lab/ssrf/ssrf_lab2.html", {"error": "Invalid URL"})
```

This ensures only URLs pointing to hosts you explicitly trust are fetched.

## 19. [CRITICAL] weak-password-hash-python
- **File:** `introduction/views.py` (lines 1026, 1194)
- **Problem:** An attacker who obtains the password database can run billions of MD5 guesses per second on a GPU, cracking user passwords in minutes or hours instead of the months or years that a proper password hash would require.
- **Fix:**

Replace the MD5 hash with Django's built-in `check_password()` function, which uses a slow, salted algorithm resistant to GPU attacks. Change line 1026 from `password = md5(password.encode()).hexdigest()` to use Django's authentication: import `from django.contrib.auth.hashers import check_password` at the top of the file, then query the user first and validate with `check_password(request.POST["password"], user.password)` instead of hashing the input to match a stored hash.

## 20. [CRITICAL] hardcoded-api-key-python
- **File:** `pygoat/settings.py` (line 25)
- **Problem:** An attacker who gains access to this source code repository—or anyone reading it on GitHub, in a backup, or in version history—obtains the Django SECRET_KEY used to sign sessions, tokens, and other security-critical data, allowing them to forge sessions, reset passwords, or bypass CSRF protections.
> 🔑 **Leaked credential** — do the rotation steps at the top of this prompt first, then apply this code change:

Load `SECRET_KEY` from an environment variable at runtime instead of hardcoding it. Replace line 25 with `SECRET_KEY = os.environ['SECRET_KEY']` (using `[]` not `.get()` so the application fails loudly if the variable is missing). The `os` module is already imported at the top of the file; set the environment variable in your deployment platform (Heroku config vars, Docker secrets, `.env` for local development with `python-dotenv`) before the application starts.

## 21. [CRITICAL] generic-api-key
- **File:** `introduction/static/js/a7.js` (line 7)
- **Problem:** This secret is committed to your git history, so anyone who can read the repository — now, or if it is ever shared, forked, or leaked — can use it.
> 🔑 **Leaked credential** — do the rotation steps at the top of this prompt first, then apply this code change:

Immediately rotate this credential — revoke the exposed key and issue a new one. Deleting it from the current code is not enough; it stays in git history, so the old value must be treated as already compromised.

## Dependency upgrades — 4 packages to update

- **[CRITICAL]** `requirements.txt` — **pillow** 9.4.0 is vulnerable (CVE-2023-50447, CVE-2026-59197, CVE-2026-59204, CVE-2024-28219, CVE-2026-55379, CVE-2026-54060, CVE-2026-54058, CVE-2026-59199, CVE-2026-54059, CVE-2026-59205, CVE-2026-59200, CVE-2026-55380, PYSEC-2023-175, CVE-2026-55798, CVE-2026-59198); no patched version was resolved automatically — check the advisory for the fixed release: https://osv.dev/vulnerability/CVE-2023-50447
- **[CRITICAL]** `requirements.txt` — **django** 4.2 is vulnerable (CVE-2025-59681, CVE-2026-4277, CVE-2025-64460, CVE-2025-14550, CVE-2026-1285, CVE-2025-13473); no patched version was resolved automatically — check the advisory for the fixed release: https://osv.dev/vulnerability/CVE-2025-59681
- **[CRITICAL]** `requirements.txt` — **Django** 4.2 → 4.2.30 or later (fixes CVE-2023-31047, CVE-2025-64459, CVE-2024-53908, CVE-2024-42005, CVE-2023-36053, CVE-2023-46695, CVE-2025-57833, CVE-2025-64458, CVE-2024-53907, CVE-2026-25673, CVE-2026-33034, CVE-2024-39330, CVE-2024-39614, CVE-2026-1287, CVE-2026-3902, CVE-2026-1207, CVE-2024-38875, CVE-2023-41164, CVE-2024-27351, CVE-2025-48432, CVE-2024-45230, CVE-2026-33033, CVE-2026-1312, CVE-2024-41990, CVE-2025-32873, CVE-2024-41989, CVE-2025-26699, CVE-2024-56374, CVE-2024-41991, CVE-2025-13372, CVE-2024-39329)
- **[CRITICAL]** `requirements.txt` — **PyYAML** 5.1 → 5.4 or later (fixes CVE-2019-20477, CVE-2020-1747, CVE-2020-14343)

`requirements.txt` is a plain text file — edit it directly. Change each package's line to the fixed version: `Django==4.2.30`, `PyYAML==5.4`. Then install the updated versions:

```bash
pip install -r requirements.txt
```

**Do not install these yet:** `django` 4.2 (in `requirements.txt`), `pillow` 9.4.0 (in `requirements.txt`). No patched version was resolved for them, so installing without a version pin would either reinstall the vulnerable release or upgrade across a major version. Open the advisory link on each bullet above, find the fixed release, and tell me the version before changing anything.

Re-run the tests and confirm the app still builds, then re-run the security scan.

**What each of these costs, worst case.** The upgrades in the command block stay on the version line you are already on, so they are patch or minor bumps: low risk, but a package can still change behaviour in a minor release, which is why the tests come first. Pinning through `overrides`/`resolutions` forces a version onto a dependency that did not ask for it, so the worst case is a resolution conflict or a parent package running against a version it never tested with. A major upgrade can remove or rename APIs and break every caller, which is why those are listed as decisions rather than commands. Doing nothing is also a choice with a cost: the advisory stays exploitable in whatever way the finding describes. If any upgrade fails its tests, stop and report it rather than working around it.

If a fix needs a major-version upgrade, or no patched version exists (the vulnerable package belongs to an end-of-life toolchain, like Babel 6), do not force it — flag it as a decision for me, explained in plain language.

## Ground rules (do not skip)
- Work on one finding at a time. After each fix, run the project's test suite; if it fails, fix the regression before moving to the next finding.
- After each fix, re-read your own diff against these rules and the finding — confirm it changes only what that finding required — before moving on.
- If a fix needs a decision from me (for example a major-version upgrade, removing a feature, or a trade-off between two approaches), stop and ask instead of guessing.
- Change only the lines needed for each fix — do not refactor, rename, or restructure unrelated code.
- Preserve every function signature, import, error handler, log line, and existing test.
- Never weaken or remove an existing security measure (authentication, input validation, sanitisation, rate limiting) while applying a fix.
- If a finding points at a generated file (a schema dump, a lockfile, a build artifact, anything under dist/ or vendor/), do not edit that file — it is output and your edit will be overwritten. Fix the source that produces it (the migration, the manifest, the template) and say which file you changed.
- If a fix needs a new import or dependency, add only that — change nothing else. Do not add new third-party packages unless a fix explicitly requires one.
- Work through the fixes one at a time, most severe first: apply a fix, then check it (run the tests if you can) before moving to the next. Don't pause for my approval between routine fixes — but do stop and tell me if a fix fails its test, conflicts with another, or needs a decision only I can make. Put anything that needs my input in your final summary.
- Never claim you did something only I can do — you cannot reset a leaked key, change a provider or dashboard setting, or click through the running app. List those as steps for me; do not report them as done.
- If the code at a referenced line number does not match the finding, search that file for the code shown in the fix and apply the change there. If you cannot find it, say so in your final summary instead of guessing.
- If you cannot fully fix a finding — because it needs a change in an account or provider dashboard, a rotated key, or a decision only I can make — do not skip it silently. Tell me, and walk me through it in small numbered steps I can do myself. Assume I am not a developer: name exactly what to open and what to click, and say how I'll know it worked.

## Prevent these from coming back
Add these rules to your `CLAUDE.md` so your AI assistant never writes these bugs again:
- Never enable debug mode or expose stack traces in production.
- Never write API keys, passwords, or tokens in source files — read them from environment variables.
- Always use parameterised queries / your ORM — never build SQL by string concatenation.
- Always validate and resolve user-supplied file paths against an allowed base directory.

## After every fix is applied
- Run the full test suite and show me the output.
- List every file you changed with a one-line summary of each change.
- Tell me which findings you could NOT fix and why — and for each one, give me small numbered steps I can do myself, written for someone who is not a developer.

Then for you, the developer:
- [ ] Confirm the old keys listed above are revoked at the provider and the new ones live only in environment variables.
- [ ] Re-run the security scan to verify these findings are gone and no new ones appeared.

> ⚠️ This prompt shows the **top 25 of 149** fix items, ranked most severe first — the remaining 124 are in your full report. Apply these, verify, then re-run the scan and grab the next batch.

> ⚪ 6 further findings from this scan were left out of this prompt: our AI review read the surrounding code and rated them likely false positives. They are still listed in your full report so you can judge them yourself.


---
Findings by Sentrint · https://sentrint.com

Findings

191 total

jk moveenter openesc clear

CRITICAL46 findings

CRITICAL

flask-debug-mode-onAI-reviewed

dockerized_labs/broken_auth_lab/app.py:123

Flask is started with debug=True. In production this serves the Werkzeug interactive debugger on every error page, which lets anyone who triggers an error run Python code on your server. Turn debug off here and control it with an environment variable instead of hardcoding it.

Why this isn’t a false positive

debug=True is hardcoded with no environment variable check, exposing the Werkzeug debugger and RCE risk if deployed as-is.

AI fix suggestion

WHY: When Flask debug mode is enabled on a public-facing server, anyone who causes an application error can access an interactive Python console in their browser and run arbitrary code with the privileges of the web server process.

FIX: Replace the hardcoded `debug=True` with a value read from an environment variable at startup. Change line 123 to:

```python
if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000, debug=os.getenv('FLASK_DEBUG') == 'True')
```

Add `import os` at the top of the file. This way debug mode is off by default in production and only enabled when explicitly set by the deployment environment.

CRITICAL

pci-card-number-hardcodedAI-reviewed

dockerized_labs/sensitive_data_exposure/dataexposure/views.py:80

Credit or debit card Primary Account Number (PAN) detected in source code. PCI-DSS Requirement 3.3 strictly prohibits storing or logging full card numbers. Remove immediately — use a payment tokenisation service (Stripe, Razorpay) so your code never sees the raw PAN.

Why this isn’t a false positive

Hardcoded PAN is stored via ORM and later exposed via profile/API views as plaintext, violating PCI-DSS regardless of test-card intent.

AI fix suggestion

WHY: A valid Visa card number is stored in plain text in the source code and will be committed to version control, where it becomes readable to anyone with repository access—and if the repo is ever leaked, exposed online, or accessed by an attacker, they can use this card number to make fraudulent charges.

FIX: Remove the hardcoded card number entirely. If you need to demonstrate payment functionality, use a payment tokenisation service (Stripe, Razorpay, or similar) that never exposes the real card number to your application code, or use a test token provided by your payment processor instead of a raw PAN. Replace line 56 with something like `credit_card='tok_visa'` (a Stripe test token) or `None`, and never store actual card numbers in your database or code.

CRITICAL

pci-card-number-hardcodedAI-reviewed

dockerized_labs/sensitive_data_exposure/dataexposure/views.py:96

Why this isn’t a false positive

Hardcoded PAN (test Visa number) is stored in DB and this file also exposes credit_card in plaintext JSON to any user, a real PCI/data exposure issue.

AI fix suggestion

WHY: A valid Visa card number is stored in plain text in the source code and will be committed to version control, where it becomes readable to anyone with repository access—and if the repo is ever leaked, exposed online, or accessed by an attacker, they can use this card number to make fraudulent charges.

FIX: Remove the hardcoded card number entirely. If you need to demonstrate payment functionality, use a payment tokenisation service (Stripe, Razorpay, or similar) that never exposes the real card number to your application code, or use a test token provided by your payment processor instead of a raw PAN. Replace line 56 with something like `credit_card='tok_visa'` (a Stripe test token) or `None`, and never store actual card numbers in your database or code.

CRITICAL

hardcoded-api-key-pythonAI-reviewed

dockerized_labs/sensitive_data_exposure/sensitive_data_lab/settings.py:8

Hardcoded secret or API key in Python source code. Move credentials to environment variables and load them with os.environ.get() or python-dotenv.

Why this isn’t a false positive

Django SECRET_KEY is hardcoded in source with DEBUG=True and ALLOWED_HOSTS=['*'], enabling session/CSRF forgery if deployed as-is.

AI fix suggestion

WHY: An attacker with access to this source code repository can read the Django secret key directly from the file, then use it to forge session tokens, tamper with signed data, or impersonate any user in the application.

FIX: Replace the hardcoded string on line 8 with a load from an environment variable. Since `os` is already imported, change line 8 to `SECRET_KEY = os.environ['SECRET_KEY']` — using square brackets (not `.get()`) so the application fails loudly at startup if the variable is missing, rather than silently using an empty default that would hide a credential rotation failure. The secret key must then be supplied by the deployment environment (container, CI/CD, or secrets manager) and never committed to version control.

CRITICAL

unsafe-yaml-load-pythonAI-reviewed

introduction/lab_code/test.py:23

yaml.load() without SafeLoader can build arbitrary Python objects while parsing. If the YAML ever comes from a user, an attacker can craft a document that runs code on your server the moment it is parsed. Use yaml.safe_load() — it parses the same data without the code-execution capability.

Why this isn’t a false positive

yaml.load() without SafeLoader is called on file contents with no explicit Loader argument, enabling arbitrary code execution if the file is attacker-controlled.

AI fix suggestion

WHY: If the YAML file at `/home/fox/test.yaml` is controlled or influenced by an attacker, they can embed malicious Python code in it that will execute on your server the moment line 23 parses it, giving them full control of the application.

FIX: Replace `yaml.load(stream)` with `yaml.safe_load(stream)` on line 23. The `yaml` module is already imported, so no new imports are needed. `yaml.safe_load()` parses YAML the same way but blocks arbitrary object instantiation and code execution:

```python
data = yaml.safe_load(stream)
```

CRITICAL

weak-password-hash-pythonAI-reviewed

introduction/mitre.py:161

A password is hashed with a single pass of a fast hash (MD5, SHA-1, SHA-256/512). These are all wrong for this job — even SHA-256 — because they are built for speed: an attacker who steals your database can try billions of guesses per second on one GPU. Use your framework's password hasher (Django's make_password/check_password) or a slow KDF like bcrypt or argon2. Fast hashes are fine for file checksums, never for credentials.

Why this isn’t a false positive

Password is hashed with raw unsalted MD5 and directly compared for authentication, enabling fast offline cracking/rainbow tables.

AI fix suggestion

WHY: An attacker who obtains the password database can crack every password in seconds using a GPU, because MD5 is a fast general-purpose hash designed for checksums, not for storing credentials.

FIX: Replace the MD5 hash with Django's built-in password verification. Change line 161 from `password = md5(password.encode()).hexdigest()` to use `django.contrib.auth.hashers.check_password()` against the stored hash, or refactor to use Django's authenticate() method if this follows standard Django user models. Fast hashes like MD5 are cryptographically broken for password storage; Django's default hasher uses PBKDF2 with a salt and many iterations, making brute-force attacks impractical.

CRITICAL

command-injection-pythonAI-reviewed

introduction/mitre.py:218

User input is interpolated into a shell command string. An attacker can inject arbitrary OS commands. Use subprocess with a list argument (shell=False) and validate or sanitise all inputs before passing them to system calls.

Why this isn’t a false positive

User-supplied `ip` is concatenated into a shell string with shell=True in command_out, enabling OS command injection.

AI fix suggestion

WHY: An attacker can submit arbitrary Python code in the `expression` POST parameter, which will be executed on the server with full privileges, allowing them to read files, modify data, or take over the application.

FIX: Replace `eval(expression)` with a safe expression parser. If you need to evaluate only mathematical expressions, use the `ast` module with a custom visitor that only allows specific operations—for example, parse with `ast.parse(expression, mode='eval')` and walk the tree to reject function calls, imports, and attribute access. If full Python evaluation is required, this endpoint should not exist; if it must, restrict it to a whitelist of safe functions and validate the input against that list before any execution attempt.

CRITICAL

password-compared-to-literal-pythonAI-reviewed

introduction/playground/A9/api.py:17

This code checks a password by comparing it to a hardcoded string. The real password sits in plain text in your source for anyone with repo access to read, and it can never be rotated without a deploy. Store a salted hash and compare with a constant-time check instead, e.g. hmac.compare_digest or your framework's password hasher.

Why this isn’t a false positive

Hardcoded "admin"/"admin" credentials with non-constant-time comparison plus logging the plaintext password is a real, critical authentication vulnerability.

AI fix suggestion

WHY: An attacker with read access to the repository source code can see the password `"admin"` in plain text on line 17, and anyone who guesses or obtains this literal string can log in; the password cannot be changed without redeploying the application.

FIX: Use Django's built-in authentication system (`django.contrib.auth.authenticate()` and `check_password()`) or store a salted hash of the password in a database or environment variable, then compare the submitted password against that hash using `check_password()` from `django.contrib.auth.hashers`. For example:

```python
from django.contrib.auth.hashers import check_password

if username == "admin" and check_password(password, stored_hash):
    return JsonResponse({"message":"Loged in successfully", "method":"post"},status = 200)
```

This ensures the real password never appears in source code and can be rotated by updating the stored hash without redeployment.

CRITICAL

password-compared-to-literal-pythonAI-reviewed

introduction/playground/A9/archive.py:17

Why this isn’t a false positive

Hardcoded admin/admin credentials with plain == comparison and logged plaintext password constitute a real, severe authentication vulnerability.

AI fix suggestion

WHY: An attacker with read access to the source code repository can extract the hardcoded password "admin" from line 17, and because the password is stored in plain text rather than as a hash, there is no way to rotate it without deploying new code.

FIX: Use Django's built-in authentication system instead of a hardcoded string comparison. Replace the manual check with `from django.contrib.auth import authenticate` and call `user = authenticate(request, username=username, password=password)` — this verifies credentials against Django's password hasher (which uses salted hashing and constant-time comparison), and allows passwords to be changed through normal user management without code deployment. Store the real admin credentials in Django's user database, not in source code.

CRITICAL

jwtAI-reviewed

introduction/static/js/a7.js:4

jwt has detected secret for file introduction/static/js/a7.js at commit e810cb9141eebdd514415008e97459c84cba499a.

Why this isn’t a false positive

A real JWT and CSRF token are hardcoded in source control, valid until their expiry regardless of comment-out status.

AI fix suggestion

WHY: This secret is committed to your git history, so anyone who can read the repository — now, or if it is ever shared, forked, or leaked — can use it.
FIX: Immediately rotate this credential — revoke the exposed key and issue a new one. Deleting it from the current code is not enough; it stays in git history, so the old value must be treated as already compromised.

CRITICAL

jwtAI-reviewed

introduction/static/js/a9.js:18

jwt has detected secret for file introduction/static/js/a9.js at commit e810cb9141eebdd514415008e97459c84cba499a.

Why this isn’t a false positive

Hardcoded CSRF token and JWT session cookie are committed in plaintext, exposing valid credentials for session hijacking.

AI fix suggestion

WHY: This secret is committed to your git history, so anyone who can read the repository — now, or if it is ever shared, forked, or leaked — can use it.
FIX: Immediately rotate this credential — revoke the exposed key and issue a new one. Deleting it from the current code is not enough; it stays in git history, so the old value must be treated as already compromised.

CRITICAL

generic-api-keyAI-reviewed

introduction/static/js/a9.js:21

generic-api-key has detected secret for file introduction/static/js/a9.js at commit e810cb9141eebdd514415008e97459c84cba499a.

Why this isn’t a false positive

Hardcoded CSRF token plus a live JWT session cookie are embedded in client-side JS, exposing valid session credentials.

AI fix suggestion

WHY: This secret is committed to your git history, so anyone who can read the repository — now, or if it is ever shared, forked, or leaked — can use it.
FIX: Immediately rotate this credential — revoke the exposed key and issue a new one. Deleting it from the current code is not enough; it stays in git history, so the old value must be treated as already compromised.

CRITICAL

password-compared-to-literal-pythonAI-reviewed

introduction/views.py:766

Why this isn’t a false positive

Hardcoded plaintext credentials compared with `==` (not constant-time) for a deliberately vulnerable-looking lab endpoint, confirming a real weak-auth issue.

AI fix suggestion

WHY: An attacker with read access to the repository source code can see the password "jacktheripper" in plain text, and because it is hardcoded there is no way to rotate it without deploying new code.

FIX: Use Django's built-in `authenticate()` function and `check_password()` method instead of string comparison. Store only a salted hash of the password in your database or settings, then call `check_password(password, stored_hash)` at line 766; this performs a constant-time comparison and prevents the real password from ever existing in source code. For example: `if name == 'jack' and check_password(password, stored_hash_for_jack):` where `stored_hash_for_jack` is a bcrypt or Argon2 hash retrieved from configuration or the database.

CRITICAL

weak-password-hash-pythonAI-reviewed

introduction/utility.py:59

Why this isn’t a false positive

customHash uses a single fast unsalted SHA-256 pass reversed, offering no protection against brute-force or GPU cracking of stolen hashes.

AI fix suggestion

WHY: An attacker who obtains the password database can use a graphics card to crack any password in seconds, because SHA-256 is designed to be fast; reversing the hash string does not add security.

FIX: Replace the `customHash` function with Django's built-in password hasher. Change line 58–59 to:
```python
from django.contrib.auth.hashers import make_password

def customHash(password):
    return make_password(password)
```
Django's `make_password` uses PBKDF2 with salt and thousands of iterations by default, making brute-force attacks impractical. If this function is called during login, use `check_password(submitted_password, stored_hash)` to verify instead of comparing strings directly.

CRITICAL

sql-injection-string-concat-pythonAI-reviewed

introduction/views.py:158

User input is concatenated directly into a SQL query. This allows an attacker to modify the query and read or delete any data in the database. Use parameterised queries or an ORM instead.

Why this isn’t a false positive

Raw string concatenation of user-controlled `name`/`password` into SQL executed via `.raw()` is classic, directly exploitable SQL injection.

AI fix suggestion

WHY: An attacker can inject SQL commands through the `name` or `password` fields — for example, entering `' OR '1'='1` as the name — to bypass the password check, read other users' data, or modify the database.

FIX: Replace the string concatenation with Django's parameterised query syntax. Change line 158 from:
```python
sql_query = "SELECT * FROM introduction_login WHERE user='"+name+"' AND password='"+password+"'"
val=login.objects.raw(sql_query)
```
to:
```python
val=login.objects.raw("SELECT * FROM introduction_login WHERE user=%s AND password=%s", [name, password])
```
The `%s` placeholders and parameter list ensure user input is treated as data, not executable SQL.

CRITICAL

command-injection-pythonAI-reviewed

introduction/views.py:460

Why this isn’t a false positive

Line 460 uses eval() directly on raw POST input with no sanitisation, enabling arbitrary Python/OS code execution (worse than the flagged shell issue).

AI fix suggestion

WHY: An attacker can submit arbitrary Python code as the `val` parameter, and `eval()` will execute it with the full privileges of the application, allowing them to read files, modify data, steal secrets, or take control of the server.

FIX: Replace `eval(val)` with a safe expression parser. If the intent is to evaluate only arithmetic expressions, use `ast.literal_eval()` for literals only, or import and use a library like `numexpr` or `simpleeval` that safely evaluates mathematical expressions without executing arbitrary code. For example:

```python
from simpleeval import simple_eval
try:
    output = simple_eval(val)
except Exception:
    output = "Something went wrong"
```

This prevents code injection while still allowing legitimate calculation inputs.

CRITICAL

unsafe-yaml-load-pythonAI-reviewed

introduction/views.py:560

Why this isn’t a false positive

yaml.load with unsafe Loader on user-uploaded file allows arbitrary object deserialization/code execution; this is even an intentional vulnerable lab endpoint.

AI fix suggestion

WHY: An attacker can upload a malicious YAML file that runs arbitrary Python code on the server when the file is parsed, because `yaml.Loader` deserializes Python objects without restriction.

FIX: Replace `yaml.load(file, yaml.Loader)` with `yaml.safe_load(file)` on line 560. `yaml.safe_load()` parses YAML syntax safely without instantiating arbitrary Python objects, preventing code execution while still returning the data the application needs. Note that `yaml` is not currently imported in the shown imports — add `import yaml` at the top of the file if it is not already present elsewhere in the file.

CRITICAL

password-compared-to-literal-pythonAI-reviewed

introduction/views.py:806

Why this isn’t a false positive

Hardcoded credentials ('jack'/'jacktheripper') with non-constant-time comparison are a genuine, exploitable authentication weakness regardless of context.

AI fix suggestion

WHY: An attacker with read access to the repository source code can see the password "jacktheripper" in plain text, and because it is hardcoded there is no way to rotate it without deploying new code.

FIX: Use Django's built-in `authenticate()` function and `check_password()` method instead of string comparison. Store only a salted hash of the password in your database or settings, then call `check_password(password, stored_hash)` at line 766; this performs a constant-time comparison and prevents the real password from ever existing in source code. For example: `if name == 'jack' and check_password(password, stored_hash_for_jack):` where `stored_hash_for_jack` is a bcrypt or Argon2 hash retrieved from configuration or the database.

CRITICAL

password-compared-to-literal-pythonAI-reviewed

introduction/views.py:831

Why this isn’t a false positive

Hardcoded plaintext credentials with non-constant-time `==` comparison directly grant admin access, a genuine deploy-time secret exposure.

AI fix suggestion

WHY: An attacker with read access to the repository source code can see the password "jacktheripper" in plain text, and because it is hardcoded there is no way to rotate it without deploying new code.

FIX: Use Django's built-in `authenticate()` function and `check_password()` method instead of string comparison. Store only a salted hash of the password in your database or settings, then call `check_password(password, stored_hash)` at line 766; this performs a constant-time comparison and prevents the real password from ever existing in source code. For example: `if name == 'jack' and check_password(password, stored_hash_for_jack):` where `stored_hash_for_jack` is a bcrypt or Argon2 hash retrieved from configuration or the database.

CRITICAL

password-compared-to-literal-pythonAI-reviewed

introduction/views.py:833

Why this isn’t a false positive

Hardcoded admin credentials ('admin'/'admin_pass') grant admin=True access, plainly visible in source, no hashing or constant-time comparison.

AI fix suggestion

WHY: An attacker with read access to the repository source code can see the password "jacktheripper" in plain text, and because it is hardcoded there is no way to rotate it without deploying new code.

FIX: Use Django's built-in `authenticate()` function and `check_password()` method instead of string comparison. Store only a salted hash of the password in your database or settings, then call `check_password(password, stored_hash)` at line 766; this performs a constant-time comparison and prevents the real password from ever existing in source code. For example: `if name == 'jack' and check_password(password, stored_hash_for_jack):` where `stored_hash_for_jack` is a bcrypt or Argon2 hash retrieved from configuration or the database.

CRITICAL

sql-injection-string-concat-pythonAI-reviewed

introduction/views.py:864

User input is concatenated directly into a SQL query. This allows an attacker to modify the query and read or delete any data in the database. Use parameterised queries or an ORM instead.

Why this isn’t a false positive

Raw user input `name`/`password` is directly concatenated into SQL and executed via `.raw()`, a textbook injection with no sanitisation visible.

AI fix suggestion

WHY: An attacker can inject SQL commands through the `name` or `password` fields — for example, entering `' OR '1'='1` as the name — to bypass the password check, read other users' data, or modify the database.

FIX: Replace the string concatenation with Django's parameterised query syntax. Change line 158 from:
```python
sql_query = "SELECT * FROM introduction_login WHERE user='"+name+"' AND password='"+password+"'"
val=login.objects.raw(sql_query)
```
to:
```python
val=login.objects.raw("SELECT * FROM introduction_login WHERE user=%s AND password=%s", [name, password])
```
The `%s` placeholders and parameter list ensure user input is treated as data, not executable SQL.

CRITICAL

path-traversal-user-path-pythonAI-reviewed

introduction/views.py:926

A file is opened or served using a path taken from user input. An attacker can send a value like ../../.env and read any file on your server — environment files, credentials, source code. Resolve the value with a safe helper (werkzeug's safe_join / secure_filename) against a fixed base directory before touching the filesystem.

Why this isn’t a false positive

User-controlled POST "blog" is directly joined to a base path and opened with no sanitization, allowing ../ traversal to read arbitrary files.

AI fix suggestion

WHY: An attacker can supply a file path like `../../.env` in the POST parameter `blog`, and because the code joins it directly to the directory without validation, they can read any file on the server outside the intended directory — including environment files with credentials, configuration, or source code.

FIX: Import `secure_filename` from `werkzeug.utils` (add to imports: `from werkzeug.utils import secure_filename`), then on line 926 replace `filename = os.path.join(dirname, file)` with `filename = os.path.join(dirname, secure_filename(file))`. This strips path traversal sequences like `../` and only allows safe filename characters, ensuring the user input cannot escape the base directory.

CRITICAL

path-traversal-user-path-pythonAI-reviewed

introduction/views.py:927

Why this isn’t a false positive

User-controlled POST "blog" is joined to a base dir with no sanitization, allowing ../ traversal to read arbitrary files.

AI fix suggestion

WHY: An attacker can supply a file path like `../../.env` in the POST parameter `blog`, and because the code joins it directly to the directory without validation, they can read any file on the server outside the intended directory — including environment files with credentials, configuration, or source code.

FIX: Import `secure_filename` from `werkzeug.utils` (add to imports: `from werkzeug.utils import secure_filename`), then on line 926 replace `filename = os.path.join(dirname, file)` with `filename = os.path.join(dirname, secure_filename(file))`. This strips path traversal sequences like `../` and only allows safe filename characters, ensuring the user input cannot escape the base directory.

CRITICAL

ssrf-user-url-pythonAI-reviewed

introduction/views.py:963

The server makes an HTTP request to a URL taken from user input. An attacker can point it at your cloud metadata service, internal admin panels, or localhost services and read the responses — from inside your network. Validate the URL against an allowlist of hosts you intend to reach before fetching it.

Why this isn’t a false positive

User-supplied URL passed directly to requests.get with no allowlist/host validation visible, enabling SSRF to internal services.

AI fix suggestion

WHY: An attacker can submit any URL — including internal services like `http://localhost:8000/admin`, `http://169.254.169.254/` (AWS metadata), or internal IP ranges — and the code will fetch it and return the response content to them, leaking sensitive data from inside your network that they couldn't reach directly.

FIX: Before calling `requests.get(url)` on line 963, parse the URL and validate that its hostname is in an allowlist of permitted external domains. For example:

```python
from urllib.parse import urlparse

url = request.POST["url"]
try:
    parsed = urlparse(url)
    allowed_hosts = {"example.com", "api.example.com"}  # Set your permitted hosts
    if parsed.hostname not in allowed_hosts:
        return render(request, "Lab/ssrf/ssrf_lab2.html", {"error": "Host not allowed"})
    response = requests.get(url)
    return render(request, "Lab/ssrf/ssrf_lab2.html", {"response": response.content.decode()})
except requests.RequestException:
    return render(request, "Lab/ssrf/ssrf_lab2.html", {"error": "Invalid URL"})
```

This ensures only URLs pointing to hosts you explicitly trust are fetched.

CRITICAL

weak-password-hash-pythonAI-reviewed

introduction/views.py:1026

Why this isn’t a false positive

MD5 with no salt is used to verify credentials against stored hashes, making offline brute-force trivial if the DB leaks.

AI fix suggestion

WHY: An attacker who obtains the password database can run billions of MD5 guesses per second on a GPU, cracking user passwords in minutes or hours instead of the months or years that a proper password hash would require.

FIX: Replace the MD5 hash with Django's built-in `check_password()` function, which uses a slow, salted algorithm resistant to GPU attacks. Change line 1026 from `password = md5(password.encode()).hexdigest()` to use Django's authentication: import `from django.contrib.auth.hashers import check_password` at the top of the file, then query the user first and validate with `check_password(request.POST["password"], user.password)` instead of hashing the input to match a stored hash.

CRITICAL

password-compared-to-literal-pythonAI-reviewed

introduction/views.py:1072

Why this isn’t a false positive

Hardcoded plaintext credentials ("User"/"P@$$w0rd") in source, plus non-constant-time equality comparison, both confirmed exploitable within this window.

AI fix suggestion

WHY: An attacker with read access to the repository source code can see the password "jacktheripper" in plain text, and because it is hardcoded there is no way to rotate it without deploying new code.

FIX: Use Django's built-in `authenticate()` function and `check_password()` method instead of string comparison. Store only a salted hash of the password in your database or settings, then call `check_password(password, stored_hash)` at line 766; this performs a constant-time comparison and prevents the real password from ever existing in source code. For example: `if name == 'jack' and check_password(password, stored_hash_for_jack):` where `stored_hash_for_jack` is a bcrypt or Argon2 hash retrieved from configuration or the database.

CRITICAL

weak-password-hash-pythonAI-reviewed

introduction/views.py:1194

Why this isn’t a false positive

Password is hashed with unsalted single-pass SHA-256 and compared against a stored hash, allowing fast offline brute-force/rainbow-table attacks.

AI fix suggestion

WHY: An attacker who obtains the password database can run billions of MD5 guesses per second on a GPU, cracking user passwords in minutes or hours instead of the months or years that a proper password hash would require.

FIX: Replace the MD5 hash with Django's built-in `check_password()` function, which uses a slow, salted algorithm resistant to GPU attacks. Change line 1026 from `password = md5(password.encode()).hexdigest()` to use Django's authentication: import `from django.contrib.auth.hashers import check_password` at the top of the file, then query the user first and validate with `check_password(request.POST["password"], user.password)` instead of hashing the input to match a stored hash.

CRITICAL

hardcoded-api-key-pythonAI-reviewed

pygoat/settings.py:25

Hardcoded secret or API key in Python source code. Move credentials to environment variables and load them with os.environ.get() or python-dotenv.

Why this isn’t a false positive

SECRET_KEY is hardcoded in plaintext source, exposing Django's cryptographic signing key if the repo is shared or public.

AI fix suggestion

WHY: An attacker who gains access to this source code repository—or anyone reading it on GitHub, in a backup, or in version history—obtains the Django SECRET_KEY used to sign sessions, tokens, and other security-critical data, allowing them to forge sessions, reset passwords, or bypass CSRF protections.

FIX: Load `SECRET_KEY` from an environment variable at runtime instead of hardcoding it. Replace line 25 with `SECRET_KEY = os.environ['SECRET_KEY']` (using `[]` not `.get()` so the application fails loudly if the variable is missing). The `os` module is already imported at the top of the file; set the environment variable in your deployment platform (Heroku config vars, Docker secrets, `.env` for local development with `python-dotenv`) before the application starts.

CRITICAL

pci-card-number-hardcodedAI · worth verifying

dockerized_labs/sensitive_data_exposure/dataexposure/views.py:56

AI reviewIt's a well-known test Visa PAN used as dummy demo data, not a real cardholder number, but storing PANs unencrypted in a model is still poor PCI practice.

AI fix suggestion

WHY: A valid Visa card number is stored in plain text in the source code and will be committed to version control, where it becomes readable to anyone with repository access—and if the repo is ever leaked, exposed online, or accessed by an attacker, they can use this card number to make fraudulent charges.

FIX: Remove the hardcoded card number entirely. If you need to demonstrate payment functionality, use a payment tokenisation service (Stripe, Razorpay, or similar) that never exposes the real card number to your application code, or use a test token provided by your payment processor instead of a raw PAN. Replace line 56 with something like `credit_card='tok_visa'` (a Stripe test token) or `None`, and never store actual card numbers in your database or code.

CRITICAL

generic-api-keyAI · worth verifying

introduction/static/js/a7.js:7

generic-api-key has detected secret for file introduction/static/js/a7.js at commit e810cb9141eebdd514415008e97459c84cba499a.

AI reviewCommented-out lines contain a real JWT and CSRF token committed to history, but they're inactive code, not currently exploitable.

AI fix suggestion

WHY: This secret is committed to your git history, so anyone who can read the repository — now, or if it is ever shared, forked, or leaked — can use it.
FIX: Immediately rotate this credential — revoke the exposed key and issue a new one. Deleting it from the current code is not enough; it stays in git history, so the old value must be treated as already compromised.

CRITICAL

CVE-2023-50447

requirements.txt:1

Package 'pillow@9.4.0' is vulnerable to 'CVE-2023-50447' (also known as 'BIT-pillow-2023-50447', 'PYSEC-2026-457', 'GHSA-3f63-hfp8-52jq').

AI fix suggestion

WHY: The Pillow library version 9.4.0 contains a buffer overflow vulnerability that could allow an attacker to execute arbitrary code by crafting a malicious image file.

FIX: Update `pillow` to version 10.1.0 or later, which patches CVE-2023-50447. Since line 1 shown is `argon2-cffi==21.3.0` (not pillow), and you indicated pillow is not visible in the excerpt provided, add or update the pillow requirement to a patched version—for example, change any existing `pillow==9.4.0` to `pillow>=10.1.0` or pin it to a specific patched release after 9.5.0.

CRITICAL

CVE-2025-59681

requirements.txt:1

Package 'django@4.2' is vulnerable to 'CVE-2025-59681' (also known as 'BIT-django-2025-59681', 'PYSEC-2025-106', 'GHSA-hpr9-3m2g-3j9p').

AI fix suggestion

WHY: Django 4.2 contains a vulnerability that allows attackers to exploit a flaw in the framework, potentially compromising application security or enabling unauthorized actions depending on the specific attack vector in CVE-2025-59681.

FIX: Upgrade Django to a patched version that addresses CVE-2025-59681. Change line 11 from `Django==4.2` to `Django>=4.2.x` (where x is the first patched minor/patch version released for this CVE). Check the Django security advisory for the exact minimum safe version, then update requirements.txt to pin to that version or later.

CRITICAL

CVE-2026-4277

requirements.txt:1

Package 'django@4.2' is vulnerable to 'CVE-2026-4277' (also known as 'BIT-django-2026-4277', 'PYSEC-2026-52', 'GHSA-pwjp-ccjc-ghwg').

AI fix suggestion

WHY: Django 4.2 contains a vulnerability that allows attackers to exploit a security weakness in the framework, potentially leading to unauthorized access, data exposure, or remote code execution depending on the specific flaw in that version.

FIX: Upgrade Django to a patched version that addresses CVE-2026-4277. Change line 11 from `Django==4.2` to `Django==4.2.x` (where x is the first patched minor version after 4.2) or to a newer stable release series that includes the security fix. Check the Django security releases page or your package index for the exact version number that resolves this CVE.

CRITICAL

CVE-2023-31047

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2023-31047 Severity: CRITICAL Fixed Version: 3.2.19, 4.1.9, 4.2.1 Link: [CVE-2023-31047](https://avd.aquasec.com/nvd/cve-2023-31047)

CRITICAL

CVE-2025-64459

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2025-64459 Severity: CRITICAL Fixed Version: 5.2.8, 5.1.14, 4.2.26 Link: [CVE-2025-64459](https://avd.aquasec.com/nvd/cve-2025-64459)

CRITICAL

CVE-2024-53908

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2024-53908 Severity: HIGH Fixed Version: 5.0.10, 5.1.4, 4.2.17 Link: [CVE-2024-53908](https://avd.aquasec.com/nvd/cve-2024-53908)

CRITICAL

CVE-2024-42005

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2024-42005 Severity: CRITICAL Fixed Version: 5.0.8, 4.2.15 Link: [CVE-2024-42005](https://avd.aquasec.com/nvd/cve-2024-42005)

CRITICAL

CVE-2019-20477

requirements.txt:27

Package: PyYAML Installed Version: 5.1 Vulnerability CVE-2019-20477 Severity: CRITICAL Fixed Version: 5.2 Link: [CVE-2019-20477](https://avd.aquasec.com/nvd/cve-2019-20477)

CRITICAL

CVE-2020-1747

requirements.txt:27

Package: PyYAML Installed Version: 5.1 Vulnerability CVE-2020-1747 Severity: CRITICAL Fixed Version: 5.3.1 Link: [CVE-2020-1747](https://avd.aquasec.com/nvd/cve-2020-1747)

CRITICAL

CVE-2020-14343

requirements.txt:27

Package: PyYAML Installed Version: 5.1 Vulnerability CVE-2020-14343 Severity: CRITICAL Fixed Version: 5.4 Link: [CVE-2020-14343](https://avd.aquasec.com/nvd/cve-2020-14343)

CRITICAL

generic-api-keyAI · likely false positive

introduction/views.py:863

generic-api-key has detected secret for file introduction/views.py at commit 80c7370f068483a9d9472cfa30a9f474922888e8.

AI reviewThis is a deliberate SQL injection lab (intentional vulnerability), not a hardcoded API key; scanner misclassified the finding type.

AI fix suggestion

WHY: This secret is committed to your git history, so anyone who can read the repository — now, or if it is ever shared, forked, or leaked — can use it.
FIX: Immediately rotate this credential — revoke the exposed key and issue a new one. Deleting it from the current code is not enough; it stays in git history, so the old value must be treated as already compromised.

CRITICAL

generic-api-keyAI · likely false positive

introduction/views.py:865

generic-api-key has detected secret for file introduction/views.py at commit 80c7370f068483a9d9472cfa30a9f474922888e8.

AI reviewThese are intentionally hardcoded demo credentials for a SQL injection lab exercise, not a real leaked API key.

AI fix suggestion

WHY: This secret is committed to your git history, so anyone who can read the repository — now, or if it is ever shared, forked, or leaked — can use it.
FIX: Immediately rotate this credential — revoke the exposed key and issue a new one. Deleting it from the current code is not enough; it stays in git history, so the old value must be treated as already compromised.

CRITICAL

generic-api-keyAI · likely false positive

introduction/views.py:1157

generic-api-key has detected secret for file introduction/views.py at commit 80c7370f068483a9d9472cfa30a9f474922888e8.

AI reviewFlagged line is just a render() call with no secret; nearby hardcoded values are hashed password digests, not API keys.

AI fix suggestion

WHY: This secret is committed to your git history, so anyone who can read the repository — now, or if it is ever shared, forked, or leaked — can use it.
FIX: Immediately rotate this credential — revoke the exposed key and issue a new one. Deleting it from the current code is not enough; it stays in git history, so the old value must be treated as already compromised.

CRITICAL

generic-api-keyAI · likely false positive

introduction/views.py:1158

generic-api-key has detected secret for file introduction/views.py at commit 80c7370f068483a9d9472cfa30a9f474922888e8.

AI reviewThese are hardcoded hash values in a demo user table, not a live API key or credential enabling access.

AI fix suggestion

WHY: This secret is committed to your git history, so anyone who can read the repository — now, or if it is ever shared, forked, or leaked — can use it.
FIX: Immediately rotate this credential — revoke the exposed key and issue a new one. Deleting it from the current code is not enough; it stays in git history, so the old value must be treated as already compromised.

CRITICAL

generic-api-keyAI · likely false positive

introduction/views.py:1159

generic-api-key has detected secret for file introduction/views.py at commit 80c7370f068483a9d9472cfa30a9f474922888e8.

AI reviewFlagged line is just `print(e)`; the actual hardcoded values are password hashes in a demo user table, not an API key.

AI fix suggestion

WHY: This secret is committed to your git history, so anyone who can read the repository — now, or if it is ever shared, forked, or leaked — can use it.
FIX: Immediately rotate this credential — revoke the exposed key and issue a new one. Deleting it from the current code is not enough; it stays in git history, so the old value must be treated as already compromised.

CRITICAL

generic-api-keyAI · likely false positive

introduction/views.py:1160

generic-api-key has detected secret for file introduction/views.py at commit 80c7370f068483a9d9472cfa30a9f474922888e8.

AI reviewFlagged line is a render() error-handler with no secret; nearby hardcoded values are hashed passwords for a deliberate demo lab, not live API keys.

AI fix suggestion

WHY: This secret is committed to your git history, so anyone who can read the repository — now, or if it is ever shared, forked, or leaked — can use it.
FIX: Immediately rotate this credential — revoke the exposed key and issue a new one. Deleting it from the current code is not enough; it stays in git history, so the old value must be treated as already compromised.

HIGH63 findings

HIGH

DS-0002AI-reviewed

dockerized_labs/insec_des_lab/Dockerfile:1

Artifact: dockerized_labs/insec_des_lab/Dockerfile Type: dockerfile Vulnerability DS-0002 Severity: HIGH Message: Specify at least 1 USER command in Dockerfile with non-root user as argument Link: [DS-0002](https://avd.aquasec.com/misconfig/ds-0002)

Why this isn’t a false positive

No USER instruction is present, so the container runs as root by default, increasing impact of any compromise.

HIGH

DS-0002AI-reviewed

Dockerfile:1

Artifact: Dockerfile Type: dockerfile Vulnerability DS-0002 Severity: HIGH Message: Specify at least 1 USER command in Dockerfile with non-root user as argument Link: [DS-0002](https://avd.aquasec.com/misconfig/ds-0002)

Why this isn’t a false positive

No USER instruction present in the entire file, so the container will run as root by default.

HIGH

DS-0002AI-reviewed

dockerized_labs/broken_auth_lab/Dockerfile:1

Artifact: dockerized_labs/broken_auth_lab/Dockerfile Type: dockerfile Vulnerability DS-0002 Severity: HIGH Message: Specify at least 1 USER command in Dockerfile with non-root user as argument Link: [DS-0002](https://avd.aquasec.com/misconfig/ds-0002)

Why this isn’t a false positive

No USER instruction is present, so the container runs as root by default, increasing impact of any compromise.

HIGH

DS-0002AI-reviewed

dockerized_labs/sensitive_data_exposure/Dockerfile:1

Artifact: dockerized_labs/sensitive_data_exposure/Dockerfile Type: dockerfile Vulnerability DS-0002 Severity: HIGH Message: Specify at least 1 USER command in Dockerfile with non-root user as argument Link: [DS-0002](https://avd.aquasec.com/misconfig/ds-0002)

Why this isn’t a false positive

No USER instruction is present, so the container runs as root by default, increasing impact of any compromise.

HIGH

CVE-2025-64460

requirements.txt:1

Package 'django@4.2' is vulnerable to 'CVE-2025-64460' (also known as 'BIT-django-2025-64460', 'PYSEC-2025-109', 'GHSA-vrcr-9hj9-jcg6').

HIGH

CVE-2026-48526

requirements.txt:1

Package 'pyjwt@2.4.0' is vulnerable to 'CVE-2026-48526' (also known as 'PYSEC-2026-179', 'GHSA-xgmm-8j9v-c9wx').

HIGH

CVE-2026-59197

requirements.txt:1

Package 'pillow@9.4.0' is vulnerable to 'CVE-2026-59197' (also known as 'BIT-pillow-2026-59197', 'PYSEC-2026-3454', 'GHSA-xj96-63gp-2gmr').

HIGH

CVE-2025-45768

requirements.txt:1

Package 'pyjwt@2.4.0' is vulnerable to 'CVE-2025-45768' (also known as 'PYSEC-2025-183').

HIGH

CVE-2023-46136

dockerized_labs/broken_auth_lab/requirements.txt:1

Package 'werkzeug@2.3.7' is vulnerable to 'CVE-2023-46136' (also known as 'PYSEC-2023-221', 'GHSA-hrfv-mqp8-q5rw').

HIGH

CVE-2026-7246

dockerized_labs/broken_auth_lab/requirements.txt:1

Package 'click@8.1.7' is vulnerable to 'CVE-2026-7246' (also known as 'PYSEC-2026-2132', 'GHSA-47fr-3ffg-hgmw').

HIGH

CVE-2024-34069

dockerized_labs/broken_auth_lab/requirements.txt:2

Package: Werkzeug Installed Version: 2.3.7 Vulnerability CVE-2024-34069 Severity: HIGH Fixed Version: 3.0.3 Link: [CVE-2024-34069](https://avd.aquasec.com/nvd/cve-2024-34069)

HIGH

CVE-2024-49767

dockerized_labs/broken_auth_lab/requirements.txt:2

Package: Werkzeug Installed Version: 2.3.7 Vulnerability CVE-2024-49767 Severity: MEDIUM Fixed Version: 3.0.6 Link: [CVE-2024-49767](https://avd.aquasec.com/nvd/cve-2024-49767)

HIGH

CVE-2024-56201

dockerized_labs/broken_auth_lab/requirements.txt:6

Package: Jinja2 Installed Version: 3.1.2 Vulnerability CVE-2024-56201 Severity: MEDIUM Fixed Version: 3.1.5 Link: [CVE-2024-56201](https://avd.aquasec.com/nvd/cve-2024-56201)

HIGH

CVE-2024-56326

dockerized_labs/broken_auth_lab/requirements.txt:6

Package: Jinja2 Installed Version: 3.1.2 Vulnerability CVE-2024-56326 Severity: MEDIUM Fixed Version: 3.1.5 Link: [CVE-2024-56326](https://avd.aquasec.com/nvd/cve-2024-56326)

HIGH

CVE-2026-54284

requirements.txt:1

Package 'sqlparse@0.3.1' is vulnerable to 'CVE-2026-54284' (also known as 'PYSEC-2026-3699', 'GHSA-pwgv-4x5q-6m9f').

HIGH

CVE-2026-59204

requirements.txt:1

Package 'pillow@9.4.0' is vulnerable to 'CVE-2026-59204' (also known as 'BIT-pillow-2026-59204', 'PYSEC-2026-3496', 'GHSA-vjc4-5qp5-m44j').

HIGH

CVE-2023-43665

dockerized_labs/sensitive_data_exposure/requirements.txt:1

Package 'django@3.2.18' is vulnerable to 'CVE-2023-43665' (also known as 'BIT-django-2023-43665', 'PYSEC-2023-226', 'GHSA-h8gc-pgj2-vjm3').

HIGH

CVE-2024-24680

dockerized_labs/sensitive_data_exposure/requirements.txt:1

Package 'django@3.2.18' is vulnerable to 'CVE-2024-24680' (also known as 'BIT-django-2024-24680', 'PYSEC-2024-28', 'GHSA-xxj9-f6rv-m3x4').

HIGH

CVE-2026-44431

dockerized_labs/sensitive_data_exposure/requirements.txt:1

Package 'urllib3@1.26.9' is vulnerable to 'CVE-2026-44431' (also known as 'PYSEC-2026-141', 'GHSA-qccp-gfcp-xxvc').

HIGH

CVE-2023-43804

dockerized_labs/sensitive_data_exposure/requirements.txt:1

Package 'urllib3@1.26.9' is vulnerable to 'CVE-2023-43804' (also known as 'PYSEC-2023-192', 'GHSA-v845-jxx5-vc9f').

HIGH

CVE-2024-39689

requirements.txt:1

Package 'certifi@2022.12.7' is vulnerable to 'CVE-2024-39689' (also known as 'PYSEC-2024-230', 'GHSA-248v-346w-9cwc').

HIGH

CVE-2025-14550

requirements.txt:1

Package 'django@4.2' is vulnerable to 'CVE-2025-14550' (also known as 'BIT-django-2025-14550', 'PYSEC-2026-43', 'GHSA-33mw-q7rj-mjwj').

HIGH

CVE-2024-28219

requirements.txt:1

Package 'pillow@9.4.0' is vulnerable to 'CVE-2024-28219' (also known as 'BIT-pillow-2024-28219', 'PYSEC-2026-1793', 'GHSA-44wm-f244-xhp3').

HIGH

CVE-2026-55379

requirements.txt:1

Package 'pillow@9.4.0' is vulnerable to 'CVE-2026-55379' (also known as 'BIT-pillow-2026-55379', 'PYSEC-2026-2255', 'GHSA-45hq-cxwh-f6vc').

HIGH

CVE-2026-1285

requirements.txt:1

Package 'django@4.2' is vulnerable to 'CVE-2026-1285' (also known as 'BIT-django-2026-1285', 'PYSEC-2026-45', 'GHSA-4rrr-2h4v-f3j9').

HIGH

GHSA-537c-gmf6-5ccf

requirements.txt:1

Package 'cryptography@39.0.1' is vulnerable to 'GHSA-537c-gmf6-5ccf'.

HIGH

CVE-2026-54060

requirements.txt:1

Package 'pillow@9.4.0' is vulnerable to 'CVE-2026-54060' (also known as 'BIT-pillow-2026-54060', 'PYSEC-2026-2254', 'GHSA-5x94-69rx-g8h2').

HIGH

CVE-2026-54058

requirements.txt:1

Package 'pillow@9.4.0' is vulnerable to 'CVE-2026-54058' (also known as 'BIT-pillow-2026-54058', 'PYSEC-2026-3493', 'GHSA-62p4-gmf7-7g93').

HIGH

CVE-2026-59199

requirements.txt:1

Package 'pillow@9.4.0' is vulnerable to 'CVE-2026-59199' (also known as 'BIT-pillow-2026-59199', 'PYSEC-2026-3451', 'GHSA-6r8x-57c9-28j4').

HIGH

CVE-2026-54059

requirements.txt:1

Package 'pillow@9.4.0' is vulnerable to 'CVE-2026-54059' (also known as 'BIT-pillow-2026-54059', 'PYSEC-2026-2253', 'GHSA-8v84-f9pq-wr9x').

HIGH

CVE-2026-59205

requirements.txt:1

Package 'pillow@9.4.0' is vulnerable to 'CVE-2026-59205' (also known as 'BIT-pillow-2026-59205', 'PYSEC-2026-3453', 'GHSA-9hw9-ch79-4vh6').

HIGH

CVE-2026-71491

requirements.txt:1

Package 'sqlparse@0.3.1' is vulnerable to 'CVE-2026-71491' (also known as 'PYSEC-2026-3697', 'GHSA-f2ff-p2ww-7p4p').

HIGH

CVE-2023-49083

requirements.txt:1

Package 'cryptography@39.0.1' is vulnerable to 'CVE-2023-49083' (also known as 'PYSEC-2023-254', 'GHSA-jfhm-5ghh-2f97').

HIGH

CVE-2024-3651

requirements.txt:1

Package 'idna@3.4.0' is vulnerable to 'CVE-2024-3651' (also known as 'PYSEC-2024-60', 'GHSA-jjg7-2v4v-x38h').

HIGH

CVE-2026-59200

requirements.txt:1

Package 'pillow@9.4.0' is vulnerable to 'CVE-2026-59200' (also known as 'BIT-pillow-2026-59200', 'PYSEC-2026-3495', 'GHSA-jjj6-mw9f-p565').

HIGH

CVE-2026-69249

requirements.txt:1

Package 'cryptography@39.0.1' is vulnerable to 'CVE-2026-69249' (also known as 'PYSEC-2026-3553', 'GHSA-jwv3-5hgf-82ww').

HIGH

CVE-2026-55380

requirements.txt:1

Package 'pillow@9.4.0' is vulnerable to 'CVE-2026-55380' (also known as 'BIT-pillow-2026-55380', 'PYSEC-2026-2256', 'GHSA-phj9-mv4w-65pm').

HIGH

CVE-2026-59893

requirements.txt:1

Package 'sqlparse@0.3.1' is vulnerable to 'CVE-2026-59893' (also known as 'PYSEC-2026-3698', 'GHSA-prg7-hcfm-mfcr').

HIGH

CVE-2023-37920

requirements.txt:4

Package: certifi Installed Version: 2022.12.7 Vulnerability CVE-2023-37920 Severity: HIGH Fixed Version: 2023.7.22 Link: [CVE-2023-37920](https://avd.aquasec.com/nvd/cve-2023-37920)

HIGH

CVE-2023-50782

requirements.txt:7

Package: cryptography Installed Version: 39.0.1 Vulnerability CVE-2023-50782 Severity: HIGH Fixed Version: 42.0.0 Link: [CVE-2023-50782](https://avd.aquasec.com/nvd/cve-2023-50782)

HIGH

CVE-2024-26130

requirements.txt:7

Package: cryptography Installed Version: 39.0.1 Vulnerability CVE-2024-26130 Severity: HIGH Fixed Version: 42.0.4 Link: [CVE-2024-26130](https://avd.aquasec.com/nvd/cve-2024-26130)

HIGH

CVE-2026-26007

requirements.txt:7

Package: cryptography Installed Version: 39.0.1 Vulnerability CVE-2026-26007 Severity: HIGH Fixed Version: 46.0.5 Link: [CVE-2026-26007](https://avd.aquasec.com/nvd/cve-2026-26007)

HIGH

CVE-2023-36053

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2023-36053 Severity: HIGH Fixed Version: 3.2.20, 4.1.10, 4.2.3 Link: [CVE-2023-36053](https://avd.aquasec.com/nvd/cve-2023-36053)

HIGH

CVE-2023-46695

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2023-46695 Severity: HIGH Fixed Version: 3.2.23, 4.1.13, 4.2.7 Link: [CVE-2023-46695](https://avd.aquasec.com/nvd/cve-2023-46695)

HIGH

CVE-2025-57833

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2025-57833 Severity: HIGH Fixed Version: 4.2.24, 5.1.12, 5.2.6 Link: [CVE-2025-57833](https://avd.aquasec.com/nvd/cve-2025-57833)

HIGH

CVE-2025-64458

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2025-64458 Severity: HIGH Fixed Version: 5.2.8, 5.1.14, 4.2.26 Link: [CVE-2025-64458](https://avd.aquasec.com/nvd/cve-2025-64458)

HIGH

CVE-2024-53907

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2024-53907 Severity: MEDIUM Fixed Version: 5.1.4, 4.2.17, 5.0.10 Link: [CVE-2024-53907](https://avd.aquasec.com/nvd/cve-2024-53907)

HIGH

CVE-2026-25673

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2026-25673 Severity: HIGH Fixed Version: 6.0.3, 5.2.12, 4.2.29 Link: [CVE-2026-25673](https://avd.aquasec.com/nvd/cve-2026-25673)

HIGH

CVE-2026-33034

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2026-33034 Severity: HIGH Fixed Version: 6.0.4, 5.2.13, 4.2.30 Link: [CVE-2026-33034](https://avd.aquasec.com/nvd/cve-2026-33034)

HIGH

CVE-2024-39330

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2024-39330 Severity: HIGH Fixed Version: 5.0.7, 4.2.14 Link: [CVE-2024-39330](https://avd.aquasec.com/nvd/cve-2024-39330)

HIGH

CVE-2024-39614

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2024-39614 Severity: HIGH Fixed Version: 5.0.7, 4.2.14 Link: [CVE-2024-39614](https://avd.aquasec.com/nvd/cve-2024-39614)

HIGH

CVE-2026-1287

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2026-1287 Severity: HIGH Fixed Version: 6.0.2, 5.2.11, 4.2.28 Link: [CVE-2026-1287](https://avd.aquasec.com/nvd/cve-2026-1287)

HIGH

CVE-2026-3902

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2026-3902 Severity: HIGH Fixed Version: 6.0.4, 5.2.13, 4.2.30 Link: [CVE-2026-3902](https://avd.aquasec.com/nvd/cve-2026-3902)

HIGH

CVE-2026-1207

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2026-1207 Severity: HIGH Fixed Version: 6.0.2, 5.2.11, 4.2.28 Link: [CVE-2026-1207](https://avd.aquasec.com/nvd/cve-2026-1207)

HIGH

CVE-2024-38875

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2024-38875 Severity: HIGH Fixed Version: 4.2.14, 5.0.7 Link: [CVE-2024-38875](https://avd.aquasec.com/nvd/cve-2024-38875)

HIGH

CVE-2023-44271

requirements.txt:19

Package: Pillow Installed Version: 9.4.0 Vulnerability CVE-2023-44271 Severity: HIGH Fixed Version: 10.0.0 Link: [CVE-2023-44271](https://avd.aquasec.com/nvd/cve-2023-44271)

HIGH

CVE-2023-4863

requirements.txt:19

Package: Pillow Installed Version: 9.4.0 Vulnerability CVE-2023-4863 Severity: HIGH Fixed Version: 10.0.1 Link: [CVE-2023-4863](https://avd.aquasec.com/nvd/cve-2023-4863)

HIGH

CVE-2026-32597

requirements.txt:24

Package: PyJWT Installed Version: 2.4.0 Vulnerability CVE-2026-32597 Severity: HIGH Fixed Version: 2.12.0 Link: [CVE-2026-32597](https://avd.aquasec.com/nvd/cve-2026-32597)

HIGH

CVE-2024-4340

requirements.txt:30

Package: sqlparse Installed Version: 0.3.1 Vulnerability CVE-2024-4340 Severity: HIGH Fixed Version: 0.5.0 Link: [CVE-2024-4340](https://avd.aquasec.com/nvd/cve-2024-4340)

HIGH

CVE-2025-66471

requirements.txt:31

Package: urllib3 Installed Version: 1.26.9 Vulnerability CVE-2025-66471 Severity: HIGH Fixed Version: 2.6.0 Link: [CVE-2025-66471](https://avd.aquasec.com/nvd/cve-2025-66471)

HIGH

CVE-2026-21441

requirements.txt:31

Package: urllib3 Installed Version: 1.26.9 Vulnerability CVE-2026-21441 Severity: HIGH Fixed Version: 2.6.3 Link: [CVE-2026-21441](https://avd.aquasec.com/nvd/cve-2026-21441)

HIGH

CVE-2025-66418

requirements.txt:31

Package: urllib3 Installed Version: 1.26.9 Vulnerability CVE-2025-66418 Severity: HIGH Fixed Version: 2.6.0 Link: [CVE-2025-66418](https://avd.aquasec.com/nvd/cve-2025-66418)

HIGH

CVE-2023-25577

requirements.txt:32

Package: Werkzeug Installed Version: 2.1.2 Vulnerability CVE-2023-25577 Severity: HIGH Fixed Version: 2.2.3 Link: [CVE-2023-25577](https://avd.aquasec.com/nvd/cve-2023-25577)

MEDIUM69 findings

MEDIUM

missing-flask-route-auth

dockerized_labs/broken_auth_lab/app.py:37

This Flask route reads the request body or queries the database without checking authentication. An unauthenticated caller can reach this endpoint. Add @login_required, verify the session, or check current_user before processing the request.

MEDIUM

missing-flask-route-auth

dockerized_labs/broken_auth_lab/app.py:38

MEDIUM

missing-flask-route-auth

dockerized_labs/broken_auth_lab/app.py:39

MEDIUM

missing-flask-route-auth

dockerized_labs/broken_auth_lab/app.py:60

MEDIUM

missing-flask-route-auth

dockerized_labs/broken_auth_lab/app.py:61

MEDIUM

missing-flask-route-auth

dockerized_labs/broken_auth_lab/app.py:62

MEDIUM

missing-flask-route-auth

dockerized_labs/broken_auth_lab/app.py:80

MEDIUM

CVE-2026-27205

dockerized_labs/broken_auth_lab/requirements.txt:1

Package 'flask@2.3.3' is vulnerable to 'CVE-2026-27205' (also known as 'PYSEC-2026-2151', 'GHSA-68rp-wp8r-4726').

MEDIUM

CVE-2026-27199

dockerized_labs/broken_auth_lab/requirements.txt:2

Package: Werkzeug Installed Version: 2.3.7 Vulnerability CVE-2026-27199 Severity: MEDIUM Fixed Version: 3.1.6 Link: [CVE-2026-27199](https://avd.aquasec.com/nvd/cve-2026-27199)

MEDIUM

CVE-2026-21860

dockerized_labs/broken_auth_lab/requirements.txt:2

Package: Werkzeug Installed Version: 2.3.7 Vulnerability CVE-2026-21860 Severity: MEDIUM Fixed Version: 3.1.5 Link: [CVE-2026-21860](https://avd.aquasec.com/nvd/cve-2026-21860)

MEDIUM

CVE-2024-49766

dockerized_labs/broken_auth_lab/requirements.txt:2

Package: Werkzeug Installed Version: 2.3.7 Vulnerability CVE-2024-49766 Severity: MEDIUM Fixed Version: 3.0.6 Link: [CVE-2024-49766](https://avd.aquasec.com/nvd/cve-2024-49766)

MEDIUM

CVE-2025-66221

dockerized_labs/broken_auth_lab/requirements.txt:2

Package: Werkzeug Installed Version: 2.3.7 Vulnerability CVE-2025-66221 Severity: MEDIUM Fixed Version: 3.1.4 Link: [CVE-2025-66221](https://avd.aquasec.com/nvd/cve-2025-66221)

MEDIUM

CVE-2025-27516

dockerized_labs/broken_auth_lab/requirements.txt:6

Package: Jinja2 Installed Version: 3.1.2 Vulnerability CVE-2025-27516 Severity: MEDIUM Fixed Version: 3.1.6 Link: [CVE-2025-27516](https://avd.aquasec.com/nvd/cve-2025-27516)

MEDIUM

CVE-2024-22195

dockerized_labs/broken_auth_lab/requirements.txt:6

Package: Jinja2 Installed Version: 3.1.2 Vulnerability CVE-2024-22195 Severity: MEDIUM Fixed Version: 3.1.3 Link: [CVE-2024-22195](https://avd.aquasec.com/nvd/cve-2024-22195)

MEDIUM

CVE-2024-34064

dockerized_labs/broken_auth_lab/requirements.txt:6

Package: Jinja2 Installed Version: 3.1.2 Vulnerability CVE-2024-34064 Severity: MEDIUM Fixed Version: 3.1.4 Link: [CVE-2024-34064](https://avd.aquasec.com/nvd/cve-2024-34064)

MEDIUM

missing-flask-route-auth

dockerized_labs/insec_des_lab/main.py:23

MEDIUM

missing-flask-route-auth

dockerized_labs/insec_des_lab/main.py:33

MEDIUM

pci-pan-column-unencrypted

dockerized_labs/sensitive_data_exposure/dataexposure/models.py:6

Database column named after raw card data with no encryption suffix. PCI-DSS Requirement 3.4 requires PAN to be rendered unreadable wherever stored. Rename to card_number_encrypted, use a tokenisation service, or store a Fernet/AES-encrypted value with the key in a KMS.

MEDIUM

CVE-2024-45231

dockerized_labs/sensitive_data_exposure/requirements.txt:1

Package 'django@3.2.18' is vulnerable to 'CVE-2024-45231' (also known as 'BIT-django-2024-45231', 'PYSEC-2026-1297', 'GHSA-rrqc-c2jx-6jgv').

MEDIUM

CVE-2026-53878

dockerized_labs/sensitive_data_exposure/requirements.txt:1

Package 'django@3.2.18' is vulnerable to 'CVE-2026-53878' (also known as 'BIT-django-2026-53878', 'PYSEC-2026-2092', 'GHSA-8qcx-xf44-272x').

MEDIUM

CVE-2026-53877

dockerized_labs/sensitive_data_exposure/requirements.txt:1

Package 'django@3.2.18' is vulnerable to 'CVE-2026-53877' (also known as 'BIT-django-2026-53877', 'PYSEC-2026-2091', 'GHSA-crhf-3pfg-w68w').

MEDIUM

CVE-2026-15830

dockerized_labs/sensitive_data_exposure/requirements.txt:1

Package 'django@3.2.18' is vulnerable to 'CVE-2026-15830' (also known as 'BIT-django-2026-15830', 'PYSEC-2026-3717').

MEDIUM

CVE-2024-47081

dockerized_labs/sensitive_data_exposure/requirements.txt:4

Package: requests Installed Version: 2.28.1 Vulnerability CVE-2024-47081 Severity: MEDIUM Fixed Version: 2.32.4 Link: [CVE-2024-47081](https://avd.aquasec.com/nvd/cve-2024-47081)

MEDIUM

CVE-2024-35195

dockerized_labs/sensitive_data_exposure/requirements.txt:4

Package: requests Installed Version: 2.28.1 Vulnerability CVE-2024-35195 Severity: MEDIUM Fixed Version: 2.32.0 Link: [CVE-2024-35195](https://avd.aquasec.com/nvd/cve-2024-35195)

MEDIUM

CVE-2026-25645

dockerized_labs/sensitive_data_exposure/requirements.txt:4

Package: requests Installed Version: 2.28.1 Vulnerability CVE-2026-25645 Severity: MEDIUM Fixed Version: 2.33.0 Link: [CVE-2026-25645](https://avd.aquasec.com/nvd/cve-2026-25645)

MEDIUM

CVE-2023-32681

dockerized_labs/sensitive_data_exposure/requirements.txt:4

Package: requests Installed Version: 2.28.1 Vulnerability CVE-2023-32681 Severity: MEDIUM Fixed Version: 2.31.0 Link: [CVE-2023-32681](https://avd.aquasec.com/nvd/cve-2023-32681)

MEDIUM

django-debug-true-in-settings

dockerized_labs/sensitive_data_exposure/sensitive_data_lab/settings.py:11

DEBUG = True in a Django settings file. If this ships to production, every error page leaks stack traces, settings and environment details to whoever triggered it. Set DEBUG = False for production and read the flag from an environment variable.

MEDIUM

jwt-token

introduction/static/js/a7.js:4

Artifact: introduction/static/js/a7.js Type: Secret JWT token Severity: MEDIUM Match: xhAAKOUWMxqMnWm8BUomv0Yd; jwt=*****************************************************************************************************************************************");

MEDIUM

jwt-token

introduction/static/js/a9.js:18

Artifact: introduction/static/js/a9.js Type: Secret JWT token Severity: MEDIUM Match: xhAAKOUWMxqMnWm8BUomv0Yd; jwt=*****************************************************************************************************************************************");

MEDIUM

django-debug-true-in-settings

pygoat/settings.py:30

MEDIUM

PYSEC-2023-175

requirements.txt:1

Package 'pillow@9.4.0' is vulnerable to 'PYSEC-2023-175'.

MEDIUM

CVE-2025-13473

requirements.txt:1

Package 'django@4.2' is vulnerable to 'CVE-2025-13473' (also known as 'BIT-django-2025-13473', 'PYSEC-2026-42', 'GHSA-2mcm-79hx-8fxw').

MEDIUM

CVE-2026-59894

requirements.txt:1

Package 'sqlparse@0.3.1' is vulnerable to 'CVE-2026-59894' (also known as 'PYSEC-2026-3696', 'GHSA-3496-9g83-7v6x').

MEDIUM

CVE-2026-55798

requirements.txt:1

Package 'pillow@9.4.0' is vulnerable to 'CVE-2026-55798' (also known as 'BIT-pillow-2026-55798', 'PYSEC-2026-2257', 'GHSA-4x4j-2g7c-83w6').

MEDIUM

GHSA-5cpq-8wj7-hf2v

requirements.txt:1

Package 'cryptography@39.0.1' is vulnerable to 'GHSA-5cpq-8wj7-hf2v'.

MEDIUM

CVE-2026-48522

requirements.txt:1

Package 'pyjwt@2.4.0' is vulnerable to 'CVE-2026-48522' (also known as 'PYSEC-2026-175', 'GHSA-993g-76c3-p5m4').

MEDIUM

CVE-2026-59198

requirements.txt:1

Package 'pillow@9.4.0' is vulnerable to 'CVE-2026-59198' (also known as 'BIT-pillow-2026-59198', 'PYSEC-2026-3494', 'GHSA-fj7v-r99m-22gq').

MEDIUM

GHSA-jm77-qphf-c4w8

requirements.txt:1

Package 'cryptography@39.0.1' is vulnerable to 'GHSA-jm77-qphf-c4w8'.

MEDIUM

CVE-2026-69248

requirements.txt:1

Package 'cryptography@39.0.1' is vulnerable to 'CVE-2026-69248' (also known as 'PYSEC-2026-3554', 'GHSA-m2h6-j472-rp4c').

MEDIUM

GHSA-v8gr-m533-ghj9

requirements.txt:1

Package 'cryptography@39.0.1' is vulnerable to 'GHSA-v8gr-m533-ghj9'.

MEDIUM

CVE-2024-0727

requirements.txt:7

Package: cryptography Installed Version: 39.0.1 Vulnerability CVE-2024-0727 Severity: MEDIUM Fixed Version: 42.0.2 Link: [CVE-2024-0727](https://avd.aquasec.com/nvd/cve-2024-0727)

MEDIUM

GHSA-h4gh-qq45-vh27

requirements.txt:7

Package: cryptography Installed Version: 39.0.1 Vulnerability GHSA-h4gh-qq45-vh27 Severity: MEDIUM Fixed Version: 43.0.1 Link: [GHSA-h4gh-qq45-vh27](https://github.com/advisories/GHSA-h4gh-qq45-vh27)

MEDIUM

CVE-2026-34073

requirements.txt:7

Package: cryptography Installed Version: 39.0.1 Vulnerability CVE-2026-34073 Severity: LOW Fixed Version: 46.0.6 Link: [CVE-2026-34073](https://avd.aquasec.com/nvd/cve-2026-34073)

MEDIUM

CVE-2023-41164

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2023-41164 Severity: MEDIUM Fixed Version: 3.2.21, 4.1.11, 4.2.5 Link: [CVE-2023-41164](https://avd.aquasec.com/nvd/cve-2023-41164)

MEDIUM

CVE-2024-27351

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2024-27351 Severity: MEDIUM Fixed Version: 3.2.25, 4.2.11, 5.0.3 Link: [CVE-2024-27351](https://avd.aquasec.com/nvd/cve-2024-27351)

MEDIUM

CVE-2025-48432

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2025-48432 Severity: MEDIUM Fixed Version: 5.2.2, 5.1.10, 4.2.22 Link: [CVE-2025-48432](https://avd.aquasec.com/nvd/cve-2025-48432)

MEDIUM

CVE-2024-45230

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2024-45230 Severity: MEDIUM Fixed Version: 5.1.1, 5.0.9, 4.2.16 Link: [CVE-2024-45230](https://avd.aquasec.com/nvd/cve-2024-45230)

MEDIUM

CVE-2026-33033

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2026-33033 Severity: MEDIUM Fixed Version: 6.0.4, 5.2.13, 4.2.30 Link: [CVE-2026-33033](https://avd.aquasec.com/nvd/cve-2026-33033)

MEDIUM

CVE-2026-1312

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2026-1312 Severity: MEDIUM Fixed Version: 6.0.2, 5.2.11, 4.2.28 Link: [CVE-2026-1312](https://avd.aquasec.com/nvd/cve-2026-1312)

MEDIUM

CVE-2024-41990

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2024-41990 Severity: MEDIUM Fixed Version: 5.0.8, 4.2.15 Link: [CVE-2024-41990](https://avd.aquasec.com/nvd/cve-2024-41990)

MEDIUM

CVE-2025-32873

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2025-32873 Severity: MEDIUM Fixed Version: 4.2.21, 5.1.9, 5.2.1 Link: [CVE-2025-32873](https://avd.aquasec.com/nvd/cve-2025-32873)

MEDIUM

CVE-2024-41989

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2024-41989 Severity: MEDIUM Fixed Version: 5.0.8, 4.2.15 Link: [CVE-2024-41989](https://avd.aquasec.com/nvd/cve-2024-41989)

MEDIUM

CVE-2025-26699

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2025-26699 Severity: MEDIUM Fixed Version: 4.2.20, 5.0.13, 5.1.7 Link: [CVE-2025-26699](https://avd.aquasec.com/nvd/cve-2025-26699)

MEDIUM

CVE-2024-56374

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2024-56374 Severity: MEDIUM Fixed Version: 5.1.5, 5.0.11, 4.2.18 Link: [CVE-2024-56374](https://avd.aquasec.com/nvd/cve-2024-56374)

MEDIUM

CVE-2024-41991

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2024-41991 Severity: MEDIUM Fixed Version: 5.0.8, 4.2.15 Link: [CVE-2024-41991](https://avd.aquasec.com/nvd/cve-2024-41991)

MEDIUM

CVE-2025-13372

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2025-13372 Severity: MEDIUM Fixed Version: 5.2.9, 5.1.15, 4.2.27 Link: [CVE-2025-13372](https://avd.aquasec.com/nvd/cve-2025-13372)

MEDIUM

CVE-2024-39329

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2024-39329 Severity: MEDIUM Fixed Version: 5.0.7, 4.2.14 Link: [CVE-2024-39329](https://avd.aquasec.com/nvd/cve-2024-39329)

MEDIUM

CVE-2026-27982

requirements.txt:12

Package: django-allauth Installed Version: 0.52.0 Vulnerability CVE-2026-27982 Severity: MEDIUM Fixed Version: 65.14.1 Link: [CVE-2026-27982](https://avd.aquasec.com/nvd/cve-2026-27982)

MEDIUM

CVE-2025-65431

requirements.txt:12

Package: django-allauth Installed Version: 0.52.0 Vulnerability CVE-2025-65431 Severity: MEDIUM Fixed Version: 65.13.0 Link: [CVE-2025-65431](https://avd.aquasec.com/nvd/cve-2025-65431)

MEDIUM

CVE-2025-65430

requirements.txt:12

Package: django-allauth Installed Version: 0.52.0 Vulnerability CVE-2025-65430 Severity: MEDIUM Fixed Version: 65.13.0 Link: [CVE-2025-65430](https://avd.aquasec.com/nvd/cve-2025-65430)

MEDIUM

CVE-2026-45409

requirements.txt:16

Package: idna Installed Version: 3.4 Vulnerability CVE-2026-45409 Severity: MEDIUM Fixed Version: 3.15 Link: [CVE-2026-45409](https://avd.aquasec.com/nvd/cve-2026-45409)

MEDIUM

CVE-2026-42310

requirements.txt:19

Package: Pillow Installed Version: 9.4.0 Vulnerability CVE-2026-42310 Severity: MEDIUM Fixed Version: 12.2.0 Link: [CVE-2026-42310](https://avd.aquasec.com/nvd/cve-2026-42310)

MEDIUM

CVE-2026-42308

requirements.txt:19

Package: Pillow Installed Version: 9.4.0 Vulnerability CVE-2026-42308 Severity: MEDIUM Fixed Version: 12.2.0 Link: [CVE-2026-42308](https://avd.aquasec.com/nvd/cve-2026-42308)

MEDIUM

GHSA-27jp-wm6q-gp25

requirements.txt:30

Package: sqlparse Installed Version: 0.3.1 Vulnerability GHSA-27jp-wm6q-gp25 Severity: MEDIUM Fixed Version: 0.5.4 Link: [GHSA-27jp-wm6q-gp25](https://github.com/advisories/GHSA-27jp-wm6q-gp25)

MEDIUM

CVE-2023-30608

requirements.txt:30

Package: sqlparse Installed Version: 0.3.1 Vulnerability CVE-2023-30608 Severity: MEDIUM Fixed Version: 0.4.4 Link: [CVE-2023-30608](https://avd.aquasec.com/nvd/cve-2023-30608)

MEDIUM

CVE-2024-37891

requirements.txt:31

Package: urllib3 Installed Version: 1.26.9 Vulnerability CVE-2024-37891 Severity: MEDIUM Fixed Version: 1.26.19, 2.2.2 Link: [CVE-2024-37891](https://avd.aquasec.com/nvd/cve-2024-37891)

MEDIUM

CVE-2023-45803

requirements.txt:31

Package: urllib3 Installed Version: 1.26.9 Vulnerability CVE-2023-45803 Severity: MEDIUM Fixed Version: 2.0.7, 1.26.18 Link: [CVE-2023-45803](https://avd.aquasec.com/nvd/cve-2023-45803)

MEDIUM

CVE-2025-50181

requirements.txt:31

Package: urllib3 Installed Version: 1.26.9 Vulnerability CVE-2025-50181 Severity: MEDIUM Fixed Version: 2.5.0 Link: [CVE-2025-50181](https://avd.aquasec.com/nvd/cve-2025-50181)

MEDIUM

CVE-2024-5569

requirements.txt:34

Package: zipp Installed Version: 3.8.0 Vulnerability CVE-2024-5569 Severity: MEDIUM Fixed Version: 3.19.1 Link: [CVE-2024-5569](https://avd.aquasec.com/nvd/cve-2024-5569)

LOW13 findings

LOW

DS-0026

Dockerfile:1

Artifact: Dockerfile Type: dockerfile Vulnerability DS-0026 Severity: LOW Message: Add HEALTHCHECK instruction in your Dockerfile Link: [DS-0026](https://avd.aquasec.com/misconfig/ds-0026)

LOW

DS-0026

dockerized_labs/broken_auth_lab/Dockerfile:1

Artifact: dockerized_labs/broken_auth_lab/Dockerfile Type: dockerfile Vulnerability DS-0026 Severity: LOW Message: Add HEALTHCHECK instruction in your Dockerfile Link: [DS-0026](https://avd.aquasec.com/misconfig/ds-0026)

LOW

DS-0026

dockerized_labs/insec_des_lab/Dockerfile:1

Artifact: dockerized_labs/insec_des_lab/Dockerfile Type: dockerfile Vulnerability DS-0026 Severity: LOW Message: Add HEALTHCHECK instruction in your Dockerfile Link: [DS-0026](https://avd.aquasec.com/misconfig/ds-0026)

LOW

DS-0026

dockerized_labs/sensitive_data_exposure/Dockerfile:1

Artifact: dockerized_labs/sensitive_data_exposure/Dockerfile Type: dockerfile Vulnerability DS-0026 Severity: LOW Message: Add HEALTHCHECK instruction in your Dockerfile Link: [DS-0026](https://avd.aquasec.com/misconfig/ds-0026)

LOW

CVE-2026-48588

dockerized_labs/sensitive_data_exposure/requirements.txt:1

Package 'django@3.2.18' is vulnerable to 'CVE-2026-48588' (also known as 'BIT-django-2026-48588', 'PYSEC-2026-2090', 'GHSA-3h9f-r86x-qvjx').

LOW

CVE-2026-8404

dockerized_labs/sensitive_data_exposure/requirements.txt:1

Package 'django@3.2.18' is vulnerable to 'CVE-2026-8404' (also known as 'BIT-django-2026-8404', 'PYSEC-2026-201', 'GHSA-8cjm-8mp7-r2xf').

LOW

CVE-2026-48587

dockerized_labs/sensitive_data_exposure/requirements.txt:1

Package 'django@3.2.18' is vulnerable to 'CVE-2026-48587' (also known as 'BIT-django-2026-48587', 'PYSEC-2026-198', 'GHSA-923m-gv2p-w5qp').

LOW

CVE-2026-6873

dockerized_labs/sensitive_data_exposure/requirements.txt:1

Package 'django@3.2.18' is vulnerable to 'CVE-2026-6873' (also known as 'BIT-django-2026-6873', 'PYSEC-2026-199', 'GHSA-h7pc-vwp9-298g').

LOW

CVE-2026-48524

requirements.txt:1

Package 'pyjwt@2.4.0' is vulnerable to 'CVE-2026-48524' (also known as 'PYSEC-2026-177', 'GHSA-fhv5-28vv-h8m8').

LOW

CVE-2026-25674

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2026-25674 Severity: LOW Fixed Version: 6.0.3, 5.2.12, 4.2.29 Link: [CVE-2026-25674](https://avd.aquasec.com/nvd/cve-2026-25674)

LOW

CVE-2026-4292

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2026-4292 Severity: LOW Fixed Version: 6.0.4, 5.2.13, 4.2.30 Link: [CVE-2026-4292](https://avd.aquasec.com/nvd/cve-2026-4292)

LOW

CVE-2025-59682

requirements.txt:11

Package: Django Installed Version: 4.2 Vulnerability CVE-2025-59682 Severity: LOW Fixed Version: 4.2.25, 5.1.13, 5.2.7 Link: [CVE-2025-59682](https://avd.aquasec.com/nvd/cve-2025-59682)

LOW

CVE-2023-23934

requirements.txt:32

Package: Werkzeug Installed Version: 2.1.2 Vulnerability CVE-2023-23934 Severity: LOW Fixed Version: 2.2.3 Link: [CVE-2023-23934](https://avd.aquasec.com/nvd/cve-2023-23934)

Copied 191 findingsClaude Code.