Common Weakness Enumeration

CWE-836

Allowed

Use of Password Hash Instead of Password for Authentication

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product records password hashes in a data store, receives a hash of a password from a client, and compares the supplied hash to the hash obtained from the data store.

30 vulnerabilities reference this CWE, most recent first.

GHSA-F7C5-2GV6-7RWJ

Vulnerability from github – Published: 2026-06-26 00:32 – Updated: 2026-06-26 00:32
VLAI
Details

Setracker2 Android Companion App com.tgelec.setracker versions 3.1.5 and prior only require the password hash when authenticating with backend services from the client. This could allow an attacker, who knows the hash, to authenticate and gain full access.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-9222"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-836"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-26T00:16:55Z",
    "severity": "CRITICAL"
  },
  "details": "Setracker2 Android Companion App com.tgelec.setracker versions 3.1.5 and prior only require the password hash when authenticating with backend services from the client. This could allow an attacker, who knows the hash, to authenticate and gain full access.",
  "id": "GHSA-f7c5-2gv6-7rwj",
  "modified": "2026-06-26T00:32:07Z",
  "published": "2026-06-26T00:32:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9222"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/cisagov/CSAF/refs/heads/develop/csaf_files/VA/white/2026/va-26-176-01.json"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/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"
    }
  ]
}

GHSA-G7M2-HJXW-27H7

Vulnerability from github – Published: 2025-05-28 18:33 – Updated: 2025-05-28 18:33
VLAI
Details

The TeleMessage service through 2025-05-05 relies on the client side (e.g., the TM SGNL app) to do MD5 hashing, and then accepts the hash as the authentication credential, as exploited in the wild in May 2025.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-48925"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-836"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-28T17:15:24Z",
    "severity": "MODERATE"
  },
  "details": "The TeleMessage service through 2025-05-05 relies on the client side (e.g., the TM SGNL app) to do MD5 hashing, and then accepts the hash as the authentication credential, as exploited in the wild in May 2025.",
  "id": "GHSA-g7m2-hjxw-27h7",
  "modified": "2025-05-28T18:33:28Z",
  "published": "2025-05-28T18:33:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48925"
    },
    {
      "type": "WEB",
      "url": "https://www.wired.com/story/how-the-signal-knock-off-app-telemessage-got-hacked-in-20-minutes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GQFQ-R93Q-HJ3Q

Vulnerability from github – Published: 2022-08-23 00:00 – Updated: 2022-08-27 00:00
VLAI
Details

An improper password check exists in the login functionality of WWBN AVideo 11.6 and dev master commit 3f7c0364. An attacker that owns a users' password hash will be able to use it to directly login into the account, leading to increased privileges.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-32282"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-836"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-22T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "An improper password check exists in the login functionality of WWBN AVideo 11.6 and dev master commit 3f7c0364. An attacker that owns a users\u0027 password hash will be able to use it to directly login into the account, leading to increased privileges.",
  "id": "GHSA-gqfq-r93q-hj3q",
  "modified": "2022-08-27T00:00:51Z",
  "published": "2022-08-23T00:00:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32282"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/blob/e04b1cd7062e16564157a82bae389eedd39fa088/updatedb/updateDb.v12.0.sql"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2022-1545"
    }
  ],
  "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"
    }
  ]
}

GHSA-J46V-Q8WW-V3R9

Vulnerability from github – Published: 2023-07-13 03:30 – Updated: 2024-04-04 06:06
VLAI
Details

Use of password hash instead of password for authentication vulnerability in SonicWall GMS and Analytics allows Pass-the-Hash attacks. This issue affects GMS: 9.3.2-SP1 and earlier versions; Analytics: 2.5.0.4-R7 and earlier versions.

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-2023-34132"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-836"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-13T03:15:09Z",
    "severity": "CRITICAL"
  },
  "details": "Use of password hash instead of password for authentication vulnerability in SonicWall GMS and Analytics allows Pass-the-Hash attacks. This issue affects GMS: 9.3.2-SP1 and earlier versions; Analytics: 2.5.0.4-R7 and earlier versions.",
  "id": "GHSA-j46v-q8ww-v3r9",
  "modified": "2024-04-04T06:06:09Z",
  "published": "2023-07-13T03:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34132"
    },
    {
      "type": "WEB",
      "url": "https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2023-0010"
    },
    {
      "type": "WEB",
      "url": "https://www.sonicwall.com/support/notices/230710150218060"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/174571/Sonicwall-GMS-9.9.9320-Remote-Code-Execution.html"
    }
  ],
  "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-QRX5-HC62-QWV6

Vulnerability from github – Published: 2023-05-15 12:30 – Updated: 2026-06-01 15:30
VLAI
Details

Use of Password Hash Instead of Password for Authentication in SICK FTMg AIR FLOW SENSOR with Partnumbers 1100214, 1100215, 1100216, 1120114, 1120116, 1122524, 1122526 allows an unprivileged remote attacker to use a password hash instead of an actual password to login to a valid user account via the REST interface.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-23450"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-836"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-15T11:15:09Z",
    "severity": "CRITICAL"
  },
  "details": "Use of Password Hash Instead of Password for Authentication in SICK FTMg AIR\nFLOW SENSOR with Partnumbers 1100214, 1100215, 1100216, 1120114, 1120116, 1122524, 1122526\nallows an unprivileged remote attacker to use a password hash instead of an actual password to login\nto a valid user account via the REST interface.",
  "id": "GHSA-qrx5-hc62-qwv6",
  "modified": "2026-06-01T15:30:31Z",
  "published": "2023-05-15T12:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23450"
    },
    {
      "type": "WEB",
      "url": "https://sick.com/.well-known/csaf/white/2023/sca-2023-0004.json"
    },
    {
      "type": "WEB",
      "url": "https://sick.com/.well-known/csaf/white/2023/sca-2023-0004.pdf"
    },
    {
      "type": "WEB",
      "url": "https://sick.com/psirt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R3CW-C95M-WFH9

Vulnerability from github – Published: 2026-06-22 20:59 – Updated: 2026-06-22 20:59
VLAI
Summary
motionEye: Authentication possible via password hash
Details

Summary

An authentication bypass vulnerability exists due to improper trust in client-controlled cookies. The application accepts user-supplied cookie values containing a username and password-hash-derived value as sufficient authentication material. These cookies can be set or modified prior to login, allowing an unauthenticated attacker to impersonate arbitrary users without knowledge of the plaintext password. This issue stems from the absence of server-side validation of authentication state and reliance on attacker-controlled cookie data

Details

The vulnerability arises because the application accepts the client-supplied cookies named meye_password_hash and meye_username as sufficient authentication material. The server does not validate these values against a server-side session or enforce proper authentication checks before establishing an authenticated state. As a result, an unauthenticated attacker can set or modify these cookies to impersonate another user if the target username and corresponding hash are known.

These cookies normally appear after using the "switch user" functionality; however, they can be added manually prior to authentication using standard browser tools (e.g., developer tools or cookie editors) or dynamically loaded by submitting blank credentials. When supplied, the server accepts them and authenticates the attacker as the specified user bypassing the intended authentication flow

Additionally, the password-hash value and username for the admin account used by the application is stored in /etc/motioneye/motion.conf which is globally readable by default on the local system. This means any local user with shell access can obtain a valid hash and values and use them to impersonate the admin via the cookie manipulation described above. While local access is required to retrieve the hash, this significantly lowers the barrier to exploitation in multi-user environments.

PoC

Starting state unauthenticated with no cookies: start state

After manually adding or submitting blank credentials to get the cookies loaded: empty cookies

Adding the credentials and refreshing the page gives us a valid session: admin login with hash

version information and session interaction validation verison

Impact

Authentication bypass

Who is impacted?

Any MotionEye deployment where attackers have access to a username and hash, and/or the /etc/motioneye/motion.conf file with the admin username and hash.

Potential consequences:

  • Account lockouts
  • Attacker persistence by changing the password
  • Enumeration of data
  • Destruction of data
  • Exfiltration of data
Severity
9.1 (Critical)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "motioneye"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.44.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46488"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-256",
      "CWE-287",
      "CWE-328",
      "CWE-836"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-22T20:59:31Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\nAn authentication bypass vulnerability exists due to improper trust in client-controlled cookies. The application accepts user-supplied cookie values containing a username and password-hash-derived value as sufficient authentication material. These cookies can be set or modified prior to login, allowing an unauthenticated attacker to impersonate arbitrary users without knowledge of the plaintext password. This issue stems from the absence of server-side validation of authentication state and reliance on attacker-controlled cookie data\n\n### Details\nThe vulnerability arises because the application accepts the client-supplied cookies named `meye_password_hash` and `meye_username` as sufficient authentication material. The server does not validate these values against a server-side session or enforce proper authentication checks before establishing an authenticated state. As a result, an unauthenticated attacker can set or modify these cookies to impersonate another user if the target username and corresponding hash are known.\n\nThese cookies normally appear after using the \"switch user\" functionality; however, they can be added manually prior to authentication using standard browser tools (e.g., developer tools or cookie editors) or dynamically loaded by submitting blank credentials. When supplied, the server accepts them and authenticates the attacker as the specified user bypassing the intended authentication flow\n\nAdditionally, the password-hash value and username for the admin account used by the application is stored in `/etc/motioneye/motion.conf` which is globally readable by default on the local system. This means any local user with shell access can obtain a valid hash and values and use them to impersonate the admin via the cookie manipulation described above. While local access is required to retrieve the hash, this significantly lowers the barrier to exploitation in multi-user environments. \n\n### PoC\nStarting state unauthenticated with no cookies:\n\u003cimg width=\"644\" height=\"475\" alt=\"start state\" src=\"https://github.com/user-attachments/assets/cf4aff78-65f7-4f67-99e2-9134c8f04277\" /\u003e\n\nAfter manually adding or submitting blank credentials to get the cookies loaded:\n\u003cimg width=\"643\" height=\"470\" alt=\"empty cookies\" src=\"https://github.com/user-attachments/assets/223878eb-f085-4ac5-a92a-2ac21831c594\" /\u003e\n\n\nAdding the credentials and refreshing the page gives us a valid session:\n\u003cimg width=\"641\" height=\"466\" alt=\"admin login with hash\" src=\"https://github.com/user-attachments/assets/94b350ef-dd32-4cae-8bd8-e48841873f79\" /\u003e\n\n\nversion information and session interaction validation\n\u003cimg width=\"643\" height=\"468\" alt=\"verison\" src=\"https://github.com/user-attachments/assets/94290ad6-4e82-4026-8e27-5374e2f3a631\" /\u003e\n\n\n### Impact\nAuthentication bypass\n\n### Who is impacted?\n\nAny MotionEye deployment where attackers have access to a username and hash, and/or the `/etc/motioneye/motion.conf` file with the admin username and hash.\n\nPotential consequences:\n\n- Account lockouts \n- Attacker persistence by changing the password\n- Enumeration of data\n- Destruction of data\n- Exfiltration of data",
  "id": "GHSA-r3cw-c95m-wfh9",
  "modified": "2026-06-22T20:59:31Z",
  "published": "2026-06-22T20:59:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/motioneye-project/motioneye/security/advisories/GHSA-r3cw-c95m-wfh9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/motioneye-project/motioneye"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "motionEye: Authentication possible via password hash"
}

GHSA-R764-C6VG-R345

Vulnerability from github – Published: 2025-10-01 18:30 – Updated: 2025-10-01 18:30
VLAI
Details

E3 Site Supervisor Control (firmware version < 2.31F01) application services (MGW and RCI) uses client side hashing for authentication. An attacker can authenticate by obtaining only the password hash.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-52543"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-836"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-02T12:15:36Z",
    "severity": "MODERATE"
  },
  "details": "E3 Site Supervisor Control (firmware version \u003c 2.31F01) application services (MGW and RCI) uses client side hashing for authentication. An attacker can authenticate by obtaining only the password hash.",
  "id": "GHSA-r764-c6vg-r345",
  "modified": "2025-10-01T18:30:38Z",
  "published": "2025-10-01T18:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52543"
    },
    {
      "type": "WEB",
      "url": "https://www.armis.com/research/frostbyte10"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:L/SA:L/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-RR29-MPMG-47MC

Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2025-12-09 18:30
VLAI
Details

A use of password hash instead of password for authentication vulnerability [CWE-836] vulnerability in Fortinet FortiWeb 8.0.0 through 8.0.1, FortiWeb 7.6.0 through 7.6.4, FortiWeb 7.4.0 through 7.4.10, FortiWeb 7.2.0 through 7.2.11, FortiWeb 7.0.0 through 7.0.11 may allow an unauthenticated attacker to use the hash in place of the password to authenticate via crafted HTTP/HTTPS requests

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-64471"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-836"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-09T18:16:05Z",
    "severity": "MODERATE"
  },
  "details": "A use of password hash instead of password for authentication vulnerability [CWE-836] vulnerability in Fortinet FortiWeb 8.0.0 through 8.0.1, FortiWeb 7.6.0 through 7.6.4, FortiWeb 7.4.0 through 7.4.10, FortiWeb 7.2.0 through 7.2.11, FortiWeb 7.0.0 through 7.0.11 may allow an unauthenticated attacker to use the hash in place of the password to authenticate via crafted HTTP/HTTPS requests",
  "id": "GHSA-rr29-mpmg-47mc",
  "modified": "2025-12-09T18:30:47Z",
  "published": "2025-12-09T18:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64471"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-25-984"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V479-VF79-MG83

Vulnerability from github – Published: 2026-04-10 15:36 – Updated: 2026-04-24 20:49
VLAI
Summary
Vikunja: Scoped API tokens with projects.background permission can delete project backgrounds
Details

Summary

Vikunja's scoped API token enforcement for custom project background routes is method-confused. A token with only projects.background can successfully delete a project background, while a token with only projects.background_delete is rejected.

This is a scoped-token authorization bypass.

Details

I verified this locally on commit c5450fb55f5192508638cbb3a6956438452a712e.

Relevant code paths: * pkg/models/api_routes.go * pkg/routes/routes.go * pkg/modules/background/handler/background.go

Route registration exposes separate permissions for the same path: * GET /api/v1/projects/:project/background -> projects.background * DELETE /api/v1/projects/:project/background -> projects.background_delete

At enforcement time, CanDoAPIRoute() falls back to the parent group and reconstructs the child permission from the path segments only. For the DELETE request, that becomes background, so the matcher accepts any token containing projects.background without re-checking the HTTP method or matching the stored route detail.

This matters because RemoveProjectBackground() is a real destructive operation: * It checks project update rights. * It deletes the background file if present. * It clears the project's BackgroundFileID.

PoC

  1. Log in as a user who can update a project that already has a background.
  2. Create an API token with only: {"projects":["background"]}
  3. Send: DELETE /api/v1/projects/<project_id>/background Authorization: Bearer <token>
  4. Observe that the request succeeds and the project background is removed.

For comparison: 1. Create an API token with only: {"projects":["background_delete"]} 2. Repeat the same DELETE request. 3. Observe that the request is rejected with 401 Unauthorized.

I confirmed this locally with three validations: 1. /api/v1/routes advertises both background and background_delete. 2. The matcher unit test proves CanDoAPIRoute() accepts DELETE for background. 3. The webtest proves a real API token with only background successfully deletes the background.

Impact

Scoped API tokens can exceed their intended capability. A token intended for project background access can delete project backgrounds, which weakens the trust model for automation and third-party integrations that rely on narrowly scoped tokens.

The attacker needs a valid API token created by a user who has update rights on the target project, but the token itself only needs the weaker projects.background permission.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40103"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-836",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T15:36:47Z",
    "nvd_published_at": "2026-04-10T17:17:13Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nVikunja\u0027s scoped API token enforcement for custom project background routes is method-confused. A token with only `projects.background` can successfully delete a project background, while a token with only `projects.background_delete` is rejected.\n\nThis is a scoped-token authorization bypass.\n\n### Details\n\nI verified this locally on commit `c5450fb55f5192508638cbb3a6956438452a712e`.\n\nRelevant code paths:\n* `pkg/models/api_routes.go`\n* `pkg/routes/routes.go`\n* `pkg/modules/background/handler/background.go`\n\nRoute registration exposes separate permissions for the same path:\n* `GET /api/v1/projects/:project/background` -\u003e `projects.background`\n* `DELETE /api/v1/projects/:project/background` -\u003e `projects.background_delete`\n\nAt enforcement time, `CanDoAPIRoute()` falls back to the parent group and reconstructs the child permission from the path segments only. For the DELETE request, that becomes `background`, so the matcher accepts any token containing `projects.background` without re-checking the HTTP method or matching the stored route detail.\n\nThis matters because `RemoveProjectBackground()` is a real destructive operation:\n* It checks project update rights.\n* It deletes the background file if present.\n* It clears the project\u0027s `BackgroundFileID`.\n\n### PoC\n\n1. Log in as a user who can update a project that already has a background.\n2. Create an API token with only:\n   `{\"projects\":[\"background\"]}`\n3. Send:\n   `DELETE /api/v1/projects/\u003cproject_id\u003e/background`\n   `Authorization: Bearer \u003ctoken\u003e`\n4. Observe that the request succeeds and the project background is removed.\n\n**For comparison:**\n1. Create an API token with only:\n   `{\"projects\":[\"background_delete\"]}`\n2. Repeat the same DELETE request.\n3. Observe that the request is rejected with `401 Unauthorized`.\n\nI confirmed this locally with three validations:\n1. `/api/v1/routes` advertises both `background` and `background_delete`.\n2. The matcher unit test proves `CanDoAPIRoute()` accepts DELETE for `background`.\n3. The webtest proves a real API token with only `background` successfully deletes the background.\n\n### Impact\n\nScoped API tokens can exceed their intended capability. A token intended for project background access can delete project backgrounds, which weakens the trust model for automation and third-party integrations that rely on narrowly scoped tokens.\n\nThe attacker needs a valid API token created by a user who has update rights on the target project, but the token itself only needs the weaker `projects.background` permission.",
  "id": "GHSA-v479-vf79-mg83",
  "modified": "2026-04-24T20:49:21Z",
  "published": "2026-04-10T15:36:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-v479-vf79-mg83"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40103"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/pull/2584"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/6a0f39b252a81fa4b19dc56dc889183acc9225ae"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.3.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vikunja: Scoped API tokens with projects.background permission can delete project backgrounds"
}

GHSA-W87C-589X-QQC3

Vulnerability from github – Published: 2026-03-21 15:33 – Updated: 2026-03-21 15:33
VLAI
Details

CEWE PHOTO SHOW 6.4.3 contains a denial of service vulnerability that allows attackers to crash the application by submitting an excessively long buffer to the password field. Attackers can paste a large string of repeated characters into the password input during the upload process to trigger an application crash.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-25552"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-836"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-21T13:16:17Z",
    "severity": "HIGH"
  },
  "details": "CEWE PHOTO SHOW 6.4.3 contains a denial of service vulnerability that allows attackers to crash the application by submitting an excessively long buffer to the password field. Attackers can paste a large string of repeated characters into the password input during the upload process to trigger an application crash.",
  "id": "GHSA-w87c-589x-qqc3",
  "modified": "2026-03-21T15:33:23Z",
  "published": "2026-03-21T15:33:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25552"
    },
    {
      "type": "WEB",
      "url": "https://cewe-photoworld.com"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/46861"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/cewe-photo-show-denial-of-service-via-password-field"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/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"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-644: Use of Captured Hashes (Pass The Hash)

An adversary obtains (i.e. steals or purchases) legitimate Windows domain credential hash values to access systems within the domain that leverage the Lan Man (LM) and/or NT Lan Man (NTLM) authentication protocols.

CAPEC-652: Use of Known Kerberos Credentials

An adversary obtains (i.e. steals or purchases) legitimate Kerberos credentials (e.g. Kerberos service account userID/password or Kerberos Tickets) with the goal of achieving authenticated access to additional systems, applications, or services within the domain.

← Back to the CWE list