Common Weakness Enumeration

CWE-305

Allowed

Authentication Bypass by Primary Weakness

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error.

322 vulnerabilities reference this CWE, most recent first.

GHSA-3P6C-GVPG-F24W

Vulnerability from github – Published: 2026-08-27 06:31 – Updated: 2026-08-27 06:31
VLAI
Details

A logic vulnerability (fail-open condition) has been identified within the Metasploit Framework's JSON-RPC web service interface. When an exception occurs during the database health check (db.check) and the environment variable MSF_WS_JSON_RPC_API_TOKEN is not explicitly set, the application resets the internal state flag msf.auth_initialized to false. The ApiToken Warden authentication strategy misinterprets this false value as an indicator that authentication is not initialized or required, thereby granting unauthenticated local access to the JSON-RPC request dispatcher.

Severity
5.1 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-16895"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-305"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-27T04:16:41Z",
    "severity": "MODERATE"
  },
  "details": "A logic vulnerability (fail-open condition) has been identified within the Metasploit Framework\u0027s JSON-RPC web service interface. When an exception occurs during the database health check (db.check) and the environment variable MSF_WS_JSON_RPC_API_TOKEN is not explicitly set, the application resets the internal state flag msf.auth_initialized to false. The ApiToken Warden authentication strategy misinterprets this false value as an indicator that authentication is not initialized or required, thereby granting unauthenticated local access to the JSON-RPC request dispatcher.",
  "id": "GHSA-3p6c-gvpg-f24w",
  "modified": "2026-08-27T06:31:33Z",
  "published": "2026-08-27T06:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16895"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rapid7/metasploit-framework/pull/21768"
    },
    {
      "type": "WEB",
      "url": "https://www.rapid7.com/blog/post/pt-metasploit-wrap-up-lot-of-summer-shells-and-fit-http-profiles"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/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-3V48-283X-F2W4

Vulnerability from github – Published: 2025-06-30 17:49 – Updated: 2025-08-04 17:36
VLAI
Summary
File Browser's password protection of links is bypassable
Details

Summary

Files managed by the File Browser can be shared with a link to external persons. While the application allows protecting those links with a password, the implementation is error-prone, making an incidental unprotected sharing of a file possible.

Impact

File owners might rest in the assumption that their shared files are only accessible to persons knowing the defined password, giving them a false sense of security. Meanwhile, attackers gaining access to the unprotected link can use this information alone to download the possibly sensitive file.

Vulnerability Description

When sharing a file, the user is presented with a dialog asking for an optional password to protect the file share. The assumption of the user at this point would be, that the shared file won't be accessible without knowledge of the password. After clicking on SHARE the following dialog opens allowing the file's owner to copy the share-link:

image

In fact, there is not one, but two links offered: A Download Link and an unnamed second one. They have the following format:

  • http://filebrowser.local:8080/share/6Gtw0xAw
  • http://filebrowser.local:8080/api/public/dl/6Gtw0xAw/dummy1.pdf?token=voDK6j[...]

Apparently, the first of the two share links is that one that users are supposed to actually share, while the second one is a direct download link not protected by the password. This behavior is not documented anywhere or explained in the GUI, though.

There are multiple scenarios how an attacker might gain access to the unprotected link and, in consequence, to the shared file:

  • The file owner might incidentally share the second link instead of the first one, making it accessible to anyone having read access to the messaging system used (e.g., a mailserver).
  • After the legitimate receiver of the share has used the password, the unprotected link will get linked in multiple locations like the browser history or the log of a proxy server used.

Proof of Concept

Using the first link results in an authorization error if no password is provided, as expected:

```http hl:9 GET /api/public/share/6Gtw0xAw HTTP/1.1 Host: filebrowser.local:8080 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0 Accept: / Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Referer: http://filebrowser.local:8080/share/6Gtw0xAw X-Auth: X-SHARE-PASSWORD: DNT: 1 Sec-GPC: 1 Connection: keep-alive Priority: u=4

HTTP/1.1 401 Unauthorized Cache-Control: no-cache, no-store, must-revalidate Content-Security-Policy: default-src 'self'; style-src 'unsafe-inline'; Content-Type: text/plain; charset=utf-8 X-Content-Type-Options: nosniff Date: Thu, 27 Mar 2025 10:59:12 GMT Content-Length: 17

401 Unauthorized


Only if the password is provided (via the `X-SHARE-PASSWORD` header), a proper response is given:

```http hl:9
GET /api/public/share/6Gtw0xAw HTTP/1.1
Host: filebrowser.local:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: http://filebrowser.local:8080/share/6Gtw0xAw
X-Auth: 
X-SHARE-PASSWORD: 1234
DNT: 1
Sec-GPC: 1
Connection: keep-alive
Priority: u=0

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Content-Security-Policy: default-src 'self'; style-src 'unsafe-inline';
Content-Type: application/json; charset=utf-8
Date: Thu, 27 Mar 2025 10:59:15 GMT
Content-Length: 301

{"path":"","name":"dummy1.pdf","size":7703,"extension":".pdf","modified":"2025-03-27T15:11:45.101242449Z","mode":420,"isDir":false,"isSymlink":false,"type":"pdf","token":"voDK6j[...]"}

But it does not return the actual file content but rather an access token. This is the very same token that is already part of the second share URL and is used by the web application to recreate the actual download URL. If you are in possession of that one, no further password check is performed, and the content of the file is returned:

GET /api/public/dl/6Gtw0xAw?inline=true&token=voDK6j[...] HTTP/1.1
Host: filebrowser.local:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
DNT: 1
Sec-GPC: 1
Connection: keep-alive
Referer: http://filebrowser.local:8080/share/6Gtw0xAw
Upgrade-Insecure-Requests: 1
Priority: u=0, i

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: private
Content-Disposition: inline
Content-Length: 7703
Content-Security-Policy: default-src 'self'; style-src 'unsafe-inline';
Content-Security-Policy: script-src 'none';
Content-Type: application/pdf
Last-Modified: Mon, 03 Mar 2025 15:11:45 GMT
Date: Thu, 27 Mar 2025 10:59:18 GMT

%PDF-1.4
%Ç쏢
%%Invocation: path/gs -P- -dSAFER -dCompatibilityLevel=1.4 -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=? -sOutputFile=? -P- -dSAFER -dCompatibilityLevel=1.4 -
5 0 obj
[...]

Recommended Countermeasures

A short time solution would be to simple remove the second link from the GUI when a password protected share is created. Doing so will be a proper defense against user errors, but it will still leave unprotected links in various logs. A thorough fix has to eliminate the unprotected links completely, access to the file must only be given to requests containing the share password.

Timeline

  • 2025-03-27 Identified the vulnerability in version 2.32.0
  • 2025-04-11 Contacted the project
  • 2025-04-29 Vulnerability disclosed to the project
  • 2025-06-25 Uploaded advisories to the project's GitHub repository
  • 2025-06-25 CVE ID assigned by GitHub
  • 2025-06-29 Mitigation of user error released in version 2.34.2
  • 2025-06-29 Issue #5239 opened to track a more thorough fix of the feature

References

Credits

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filebrowser/filebrowser/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.42.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filebrowser/filebrowser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-52996"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-305"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-30T17:49:27Z",
    "nvd_published_at": "2025-06-30T20:15:25Z",
    "severity": "LOW"
  },
  "details": "## Summary ##\n\nFiles managed by the *File Browser* can be shared with a link to external persons. While the application allows protecting those links with a password, the implementation is error-prone, making an incidental unprotected sharing of a file possible.\n\n## Impact ##\n\nFile owners might rest in the assumption that their shared files are only accessible to persons knowing the defined password, giving them a false sense of security. Meanwhile, attackers gaining access to the unprotected link can use this information alone to download the possibly sensitive file.\n\n## Vulnerability Description ##\n\nWhen sharing a file, the user is presented with a dialog asking for an optional password to protect the file share. The assumption of the user at this point would be, that the shared file won\u0027t be accessible without knowledge of the password. After clicking on `SHARE` the following dialog opens allowing the file\u0027s owner to copy the share-link:\n\n![image](https://github.com/user-attachments/assets/f3add074-40ac-4367-a538-ede5bb526916)\n\nIn fact, there is not one, but two links offered: A `Download Link` and an unnamed second one. They have the following format:\n\n* http://filebrowser.local:8080/share/6Gtw0xAw\n* http://filebrowser.local:8080/api/public/dl/6Gtw0xAw/dummy1.pdf?token=voDK6j[...]\n\nApparently, the first of the two share links is that one that users are supposed to actually share, while the second one is a direct download link not protected by the password. This behavior is not documented anywhere or explained in the GUI, though.\n\nThere are multiple scenarios how an attacker might gain access to the unprotected link and, in consequence, to the shared file:\n\n* The file owner might incidentally share the second link instead of the first one, making it accessible to anyone having read access to the messaging system used (e.g., a mailserver).\n* After the legitimate receiver of the share has used the password, the unprotected link will get linked in multiple locations like the browser history or the log of a proxy server used.\n\n## Proof of Concept ##\n\nUsing the first link results in an authorization error if no password is provided, as expected:\n\n```http hl:9\nGET /api/public/share/6Gtw0xAw HTTP/1.1\nHost: filebrowser.local:8080\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0\nAccept: */*\nAccept-Language: en-US,en;q=0.5\nAccept-Encoding: gzip, deflate, br\nReferer: http://filebrowser.local:8080/share/6Gtw0xAw\nX-Auth: \nX-SHARE-PASSWORD: \nDNT: 1\nSec-GPC: 1\nConnection: keep-alive\nPriority: u=4\n\nHTTP/1.1 401 Unauthorized\nCache-Control: no-cache, no-store, must-revalidate\nContent-Security-Policy: default-src \u0027self\u0027; style-src \u0027unsafe-inline\u0027;\nContent-Type: text/plain; charset=utf-8\nX-Content-Type-Options: nosniff\nDate: Thu, 27 Mar 2025 10:59:12 GMT\nContent-Length: 17\n\n401 Unauthorized\n```\n\nOnly if the password is provided (via the `X-SHARE-PASSWORD` header), a proper response is given:\n\n```http hl:9\nGET /api/public/share/6Gtw0xAw HTTP/1.1\nHost: filebrowser.local:8080\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0\nAccept: */*\nAccept-Language: en-US,en;q=0.5\nAccept-Encoding: gzip, deflate, br\nReferer: http://filebrowser.local:8080/share/6Gtw0xAw\nX-Auth: \nX-SHARE-PASSWORD: 1234\nDNT: 1\nSec-GPC: 1\nConnection: keep-alive\nPriority: u=0\n\nHTTP/1.1 200 OK\nCache-Control: no-cache, no-store, must-revalidate\nContent-Security-Policy: default-src \u0027self\u0027; style-src \u0027unsafe-inline\u0027;\nContent-Type: application/json; charset=utf-8\nDate: Thu, 27 Mar 2025 10:59:15 GMT\nContent-Length: 301\n\n{\"path\":\"\",\"name\":\"dummy1.pdf\",\"size\":7703,\"extension\":\".pdf\",\"modified\":\"2025-03-27T15:11:45.101242449Z\",\"mode\":420,\"isDir\":false,\"isSymlink\":false,\"type\":\"pdf\",\"token\":\"voDK6j[...]\"}\n```\n\nBut it does not return the actual file content but rather an access token.\nThis is the very same token that is already part of the second share URL and is used by the web application to recreate the actual download URL.\nIf you are in possession of that one, no further password check is performed, and the content of the file is returned:\n\n```http\nGET /api/public/dl/6Gtw0xAw?inline=true\u0026token=voDK6j[...] HTTP/1.1\nHost: filebrowser.local:8080\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\nAccept-Language: en-US,en;q=0.5\nAccept-Encoding: gzip, deflate, br\nDNT: 1\nSec-GPC: 1\nConnection: keep-alive\nReferer: http://filebrowser.local:8080/share/6Gtw0xAw\nUpgrade-Insecure-Requests: 1\nPriority: u=0, i\n\nHTTP/1.1 200 OK\nAccept-Ranges: bytes\nCache-Control: private\nContent-Disposition: inline\nContent-Length: 7703\nContent-Security-Policy: default-src \u0027self\u0027; style-src \u0027unsafe-inline\u0027;\nContent-Security-Policy: script-src \u0027none\u0027;\nContent-Type: application/pdf\nLast-Modified: Mon, 03 Mar 2025 15:11:45 GMT\nDate: Thu, 27 Mar 2025 10:59:18 GMT\n\n%PDF-1.4\n%\u00c7\u00ec\u008f\u00a2\n%%Invocation: path/gs -P- -dSAFER -dCompatibilityLevel=1.4 -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=? -sOutputFile=? -P- -dSAFER -dCompatibilityLevel=1.4 -\n5 0 obj\n[...]\n```\n\n## Recommended Countermeasures ##\n\nA short time solution would be to simple remove the second link from the GUI when a password protected share is created.\nDoing so will be a proper defense against user errors, but it will still leave unprotected links in various logs.\nA thorough fix has to eliminate the unprotected links completely, access to the file must only be given to requests containing the share password.\n\n## Timeline ##\n\n* `2025-03-27` Identified the vulnerability in version 2.32.0\n* `2025-04-11` Contacted the project\n* `2025-04-29` Vulnerability disclosed to the project\n* `2025-06-25` Uploaded advisories to the project\u0027s GitHub repository\n* `2025-06-25` CVE ID assigned by GitHub\n* `2025-06-29` Mitigation of user error released in version 2.34.2\n* `2025-06-29` Issue [#5239](https://github.com/filebrowser/filebrowser/issues/5239) opened to track a more thorough fix of the feature\n\n## References ##\n\n* [CWE-305: Authentication Bypass by Primary Weakness](https://cwe.mitre.org/data/definitions/305.html)\n* [Original Advisory](https://github.com/sbaresearch/advisories/tree/public/2025/SBA-ADV-20250327-02_Filebrowser_Password_Protection_Of_Links_Bypassable)\n\n## Credits ##\n\n* Mathias Tausig ([SBA Research](https://www.sba-research.org/))",
  "id": "GHSA-3v48-283x-f2w4",
  "modified": "2025-08-04T17:36:08Z",
  "published": "2025-06-30T17:49:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-3v48-283x-f2w4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52996"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/issues/5239"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/filebrowser/filebrowser"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sbaresearch/advisories/tree/public/2025/SBA-ADV-20250327-02_Filebrowser_Password_Protection_Of_Links_Bypassable"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3790"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "File Browser\u0027s password protection of links is bypassable"
}

GHSA-3WHV-8QG8-4FFW

Vulnerability from github – Published: 2026-01-21 18:30 – Updated: 2026-01-21 18:30
VLAI
Details

Authentication Bypass by Primary Weakness vulnerability in Jamf Jamf Pro allows unspecified impact.This issue affects Jamf Pro: from 11.20 through 11.24.

Severity
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-1290"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-305"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-21T16:16:08Z",
    "severity": "MODERATE"
  },
  "details": "Authentication Bypass by Primary Weakness vulnerability in Jamf Jamf Pro allows unspecified impact.This issue affects Jamf Pro: from 11.20 through 11.24.",
  "id": "GHSA-3whv-8qg8-4ffw",
  "modified": "2026-01-21T18:30:30Z",
  "published": "2026-01-21T18:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1290"
    },
    {
      "type": "WEB",
      "url": "https://learn.jamf.com/en-US/bundle/jamf-pro-release-notes-11.24.0/page/Resolved_Issues.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/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-3X3J-PMX9-J3R7

Vulnerability from github – Published: 2025-02-24 15:30 – Updated: 2025-02-24 18:32
VLAI
Details

WorkOS Hosted AuthKit before 2025-01-07 allows a password authentication MFA bypass (by enrolling a new authentication factor) when the attacker knows the user's password. No exploitation occurred.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-23017"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-305"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-24T15:15:13Z",
    "severity": "MODERATE"
  },
  "details": "WorkOS Hosted AuthKit before 2025-01-07 allows a password authentication MFA bypass (by enrolling a new authentication factor) when the attacker knows the user\u0027s password. No exploitation occurred.",
  "id": "GHSA-3x3j-pmx9-j3r7",
  "modified": "2025-02-24T18:32:41Z",
  "published": "2025-02-24T15:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23017"
    },
    {
      "type": "WEB",
      "url": "https://workos.com/security/advisories"
    },
    {
      "type": "WEB",
      "url": "https://www.authkit.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-42FF-P8FR-H5JR

Vulnerability from github – Published: 2026-07-13 09:31 – Updated: 2026-07-13 09:31
VLAI
Details

Mattermost versions 11.7.x <= 11.7.2, 11.6.x <= 11.6.4 fail to verify whether a guest account is deactivated before creating a session in the magic-link token login path, which allows a deactivated guest user to obtain a fully functional session via a magic-link token issued prior to deactivation.. Mattermost Advisory ID: MMSA-2026-00681

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-9597"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-305"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-13T09:16:25Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost versions 11.7.x \u003c= 11.7.2, 11.6.x \u003c= 11.6.4 fail to verify whether a guest account is deactivated before creating a session in the magic-link token login path, which allows a deactivated guest user to obtain a fully functional session via a magic-link token issued prior to deactivation.. Mattermost Advisory ID: MMSA-2026-00681",
  "id": "GHSA-42ff-p8fr-h5jr",
  "modified": "2026-07-13T09:31:43Z",
  "published": "2026-07-13T09:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9597"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-44WC-J6F2-7FJR

Vulnerability from github – Published: 2026-08-28 18:31 – Updated: 2026-08-31 21:31
VLAI
Details

An improper access control vulnerability exists in the web management interface of PaperCut MF and PaperCut NG. Under specific conditions, unauthenticated remote requests targeting administrative functions can trigger backend actions prior to the completion of access validation checks. This allows an unauthenticated remote attacker to modify certain system configurations.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-81578"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-305"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-28T16:18:29Z",
    "severity": "HIGH"
  },
  "details": "An improper access control vulnerability exists in the web management interface of PaperCut MF and PaperCut NG. Under specific\u00a0conditions, unauthenticated remote requests targeting administrative functions can trigger backend actions prior to the  completion of access validation checks. This allows an unauthenticated remote attacker to modify certain system configurations.",
  "id": "GHSA-44wc-j6f2-7fjr",
  "modified": "2026-08-31T21:31:55Z",
  "published": "2026-08-28T18:31:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81578"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rapid7/metasploit-framework/pull/21842"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-81578"
    },
    {
      "type": "WEB",
      "url": "https://www.papercut.com/kb/Main/security-bulletin-27-aug-2026-urgent-security-advisory"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:L/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-45GV-9WJV-XH7P

Vulnerability from github – Published: 2026-10-09 17:08 – Updated: 2026-10-09 17:08
VLAI
Summary
Nginx UI: Authentication bypass: password login does not enforce a passkey-only second factor (2FA bypass)
Details

Summary

nginx-ui supports two second-factor methods — TOTP (OTP) and WebAuthn passkeys — and reports an account as 2FA-enabled when either is configured. However, the password login endpoint (POST /api/login) only enforces a second factor when a TOTP secret is present. An account that has registered a passkey but no TOTP is logged in after password verification alone — the passkey is never requested. This silently downgrades a passkey-protected account to single-factor (password-only) authentication.

Details

The account's 2FA policy treats passkeys as a valid factor (model/user.go):

func (u *User) EnabledOTP() bool     { return len(u.OTPSecret) != 0 }
func (u *User) EnabledPasskey() bool { /* true if a passkey row exists */ }
func (u *User) Enabled2FA() bool     { return u.EnabledOTP() || u.EnabledPasskey() }

func (u *User) AfterFind(_ *gorm.DB) error {
    u.EnabledTwoFA = u.Enabled2FA() // exposed to the UI as `enabled_2fa`
    return nil
}

But the login handler only checks EnabledOTP() (api/user/auth.go, Login):

u, err := user.Login(json.Name, json.Password)
...
if u.EnabledOTP() {                       // <-- only TOTP is enforced
    if json.OTP == "" && json.RecoveryCode == "" {
        c.JSON(http.StatusOK, LoginResponse{Message: "The user has enabled 2FA", Code: Enabled2FA}) // 199
        user.BanIP(clientIP)
        return
    }
    if _, err = user.VerifyOTP(u, json.OTP, json.RecoveryCode); err != nil { /* ... */ }
    secureSessionID = user.SetSecureSessionID(u.ID)
}

// Passkey-only accounts fall through to here and receive a full session token:
accessToken, err := user.GenerateJWT(u)

No branch requires a WebAuthn assertion during password login when EnabledPasskey() is true. The root cause is the mismatch between the policy definition (Enabled2FA() = OTP or passkey) and the enforcement check (EnabledOTP() only).

The same EnabledOTP()-only gating in RequireSecureSession() (internal/middleware/secure_session.go) means passkey-only users are also exempted from step-up on sensitive actions.

Proof of Concept

Tested against nginx-ui built from source (go build -tags unembed) on 127.0.0.1:9000, with WebAuthn configured and a victim account that has a registered passkey and no TOTP. The vulnerable code is identical on the production main branch (api/user/auth.go Login gates on u.EnabledOTP() only; verified at commit 6c86e5a, 2026-05-17).

Account state advertised by GET /api/2fa_status:

{"enabled":true,"otp_status":false,"passkey_status":true, ...}

Attacker logs in with password only (POST /api/login, encrypted params as the client normally sends):

HTTP 200
{"message":"ok","code":200,"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...."}

code: 200 + a valid JWT = an authenticated session, with the passkey never used. For comparison, the identical account with a TOTP secret instead correctly returns the second-factor challenge:

HTTP 200
{"message":"The user has enabled 2FA","code":199}
Account state POST /api/login (password only)
Passkey registered, no TOTP code 200 + JWT — 2FA NOT enforced
TOTP registered code 199 — 2FA challenge enforced

This isolates the defect: the login path enforces OTP but ignores passkeys.

Impact

  • Any account protected only by a passkey is reduced to password-only authentication. An attacker who obtains the password (phishing, reuse, leak) gains full access despite the registered security key.
  • In nginx-ui all authenticated users are effectively administrators and the terminal feature grants a host shell, so account takeover leads to full control of the managed nginx instance / host.
  • Users are given a false sense of security: the UI shows the account as 2FA-enabled while the second factor is not enforced at login.

Remediation

  • Gate the second-factor decision on u.Enabled2FA() (not u.EnabledOTP()) in Login, in both SSO callbacks, and in RequireSecureSession().
  • For a passkey-only user logging in with a password, return a "passkey assertion required" challenge and complete login only after a successful WebAuthn assertion (the begin_passkey_login / finish_passkey_login flow already exists and should be required as the second step).
  • Centralize session-token issuance so no login entry point can skip the 2FA decision.

Affected components

  • api/user/auth.go — Login
  • model/user.go — EnabledOTP, EnabledPasskey, Enabled2FA, AfterFind
  • api/user/2fa.go — get2FAStatus
  • internal/middleware/secure_session.go — RequireSecureSession
Severity
8.1 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/0xJacky/Nginx-UI"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.9.10-0.20250517140552-daee3ac7ade1"
            },
            {
              "fixed": "1.9.10-0.20260728074558-95cd21b70814"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107808"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-305",
      "CWE-308"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-09T17:08:15Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nnginx-ui supports two second-factor methods \u2014 TOTP (OTP) and WebAuthn passkeys \u2014\nand reports an account as 2FA-enabled when **either** is configured. However, the\npassword login endpoint (`POST /api/login`) only enforces a second factor when a\n**TOTP secret** is present. An account that has registered a **passkey but no\nTOTP** is logged in after password verification alone \u2014 the passkey is never\nrequested. This silently downgrades a passkey-protected account to single-factor\n(password-only) authentication.\n\n## Details\n\nThe account\u0027s 2FA policy treats passkeys as a valid factor (`model/user.go`):\n\n```go\nfunc (u *User) EnabledOTP() bool     { return len(u.OTPSecret) != 0 }\nfunc (u *User) EnabledPasskey() bool { /* true if a passkey row exists */ }\nfunc (u *User) Enabled2FA() bool     { return u.EnabledOTP() || u.EnabledPasskey() }\n\nfunc (u *User) AfterFind(_ *gorm.DB) error {\n    u.EnabledTwoFA = u.Enabled2FA() // exposed to the UI as `enabled_2fa`\n    return nil\n}\n```\n\nBut the login handler only checks `EnabledOTP()` (`api/user/auth.go`, `Login`):\n\n```go\nu, err := user.Login(json.Name, json.Password)\n...\nif u.EnabledOTP() {                       // \u003c-- only TOTP is enforced\n    if json.OTP == \"\" \u0026\u0026 json.RecoveryCode == \"\" {\n        c.JSON(http.StatusOK, LoginResponse{Message: \"The user has enabled 2FA\", Code: Enabled2FA}) // 199\n        user.BanIP(clientIP)\n        return\n    }\n    if _, err = user.VerifyOTP(u, json.OTP, json.RecoveryCode); err != nil { /* ... */ }\n    secureSessionID = user.SetSecureSessionID(u.ID)\n}\n\n// Passkey-only accounts fall through to here and receive a full session token:\naccessToken, err := user.GenerateJWT(u)\n```\n\nNo branch requires a WebAuthn assertion during password login when\n`EnabledPasskey()` is true. The root cause is the mismatch between the\n**policy definition** (`Enabled2FA()` = OTP **or** passkey) and the\n**enforcement check** (`EnabledOTP()` only).\n\nThe same `EnabledOTP()`-only gating in `RequireSecureSession()`\n(`internal/middleware/secure_session.go`) means passkey-only users are also\nexempted from step-up on sensitive actions.\n\n## Proof of Concept\n\nTested against nginx-ui built from source (`go build -tags unembed`) on\n`127.0.0.1:9000`, with WebAuthn configured and a victim account that has a\nregistered passkey and **no** TOTP. The vulnerable code is identical on the\nproduction `main` branch (`api/user/auth.go` `Login` gates on `u.EnabledOTP()`\nonly; verified at commit `6c86e5a`, 2026-05-17).\n\nAccount state advertised by `GET /api/2fa_status`:\n\n```json\n{\"enabled\":true,\"otp_status\":false,\"passkey_status\":true, ...}\n```\n\nAttacker logs in with **password only** (`POST /api/login`, encrypted params as\nthe client normally sends):\n\n```\nHTTP 200\n{\"message\":\"ok\",\"code\":200,\"token\":\"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....\"}\n```\n\n`code: 200` + a valid JWT = an authenticated session, with the passkey never\nused. For comparison, the identical account with a TOTP secret instead correctly\nreturns the second-factor challenge:\n\n```\nHTTP 200\n{\"message\":\"The user has enabled 2FA\",\"code\":199}\n```\n\n| Account state | `POST /api/login` (password only) |\n|---|---|\n| Passkey registered, no TOTP | `code 200` + JWT \u2014 **2FA NOT enforced** |\n| TOTP registered | `code 199` \u2014 2FA challenge enforced |\n\nThis isolates the defect: the login path enforces OTP but ignores passkeys.\n\n## Impact\n\n- Any account protected **only** by a passkey is reduced to password-only\n  authentication. An attacker who obtains the password (phishing, reuse, leak)\n  gains full access despite the registered security key.\n- In nginx-ui all authenticated users are effectively administrators and the\n  terminal feature grants a host shell, so account takeover leads to full\n  control of the managed nginx instance / host.\n- Users are given a false sense of security: the UI shows the account as\n  2FA-enabled while the second factor is not enforced at login.\n\n## Remediation\n\n- Gate the second-factor decision on `u.Enabled2FA()` (not `u.EnabledOTP()`) in\n  `Login`, in both SSO callbacks, and in `RequireSecureSession()`.\n- For a passkey-only user logging in with a password, return a\n  \"passkey assertion required\" challenge and complete login only after a\n  successful WebAuthn assertion (the `begin_passkey_login` / `finish_passkey_login`\n  flow already exists and should be required as the second step).\n- Centralize session-token issuance so no login entry point can skip the 2FA\n  decision.\n\n## Affected components\n\n- `api/user/auth.go` \u2014 `Login`\n- `model/user.go` \u2014 `EnabledOTP`, `EnabledPasskey`, `Enabled2FA`, `AfterFind`\n- `api/user/2fa.go` \u2014 `get2FAStatus`\n- `internal/middleware/secure_session.go` \u2014 `RequireSecureSession`",
  "id": "GHSA-45gv-9wjv-xh7p",
  "modified": "2026-10-09T17:08:15Z",
  "published": "2026-10-09T17:08:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-45gv-9wjv-xh7p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0xJacky/nginx-ui/commit/95cd21b70814e5d9a48a359aa238aeea1ac97429"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/0xJacky/nginx-ui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0xJacky/nginx-ui/releases/tag/v2.5.0"
    }
  ],
  "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"
    }
  ],
  "summary": "Nginx UI: Authentication bypass: password login does not enforce a passkey-only second factor (2FA bypass)"
}

GHSA-45J5-GMRP-65WR

Vulnerability from github – Published: 2022-03-31 00:00 – Updated: 2026-05-18 15:30
VLAI
Details

A vulnerability in MEPSAN's USC+ before version 3.0 has a weakness in login function which lets attackers to generate high privileged accounts passwords.

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-2021-45031"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-305"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-30T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability in MEPSAN\u0027s USC+ before version 3.0 has a weakness in login function which lets attackers to generate high privileged accounts passwords.",
  "id": "GHSA-45j5-gmrp-65wr",
  "modified": "2026-05-18T15:30:31Z",
  "published": "2022-03-31T00:00:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45031"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-22-0269"
    },
    {
      "type": "WEB",
      "url": "https://www.usom.gov.tr/bildirim/tr-22-0269"
    }
  ],
  "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-485M-923F-95WX

Vulnerability from github – Published: 2024-06-25 15:31 – Updated: 2025-10-22 00:33
VLAI
Details

VMware ESXi contains an authentication bypass vulnerability. A malicious actor with sufficient Active Directory (AD) permissions can gain full access to an ESXi host that was previously configured to use AD for user management https://blogs.vmware.com/vsphere/2012/09/joining-vsphere-hosts-to-active-directory.html by re-creating the configured AD group ('ESXi Admins' by default) after it was deleted from AD.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-37085"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-305"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-25T15:15:12Z",
    "severity": "MODERATE"
  },
  "details": "VMware ESXi contains an authentication bypass vulnerability.\u00a0A malicious actor with sufficient Active Directory (AD) permissions can gain full access to an ESXi host that was previously  configured to use AD for user management https://blogs.vmware.com/vsphere/2012/09/joining-vsphere-hosts-to-active-directory.html  by re-creating the configured AD group (\u0027ESXi Admins\u0027 by default) after it was deleted from AD.",
  "id": "GHSA-485m-923f-95wx",
  "modified": "2025-10-22T00:33:03Z",
  "published": "2024-06-25T15:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37085"
    },
    {
      "type": "WEB",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/24505"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-37085"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4979-4XQF-M5VX

Vulnerability from github – Published: 2025-01-02 12:32 – Updated: 2026-04-28 21:35
VLAI
Details

Authentication Bypass by Primary Weakness vulnerability in yourownprogrammer YOP Poll allows Authentication Bypass.This issue affects YOP Poll: from n/a through 6.5.28.

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-46611"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-305"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-02T12:15:12Z",
    "severity": "MODERATE"
  },
  "details": "Authentication Bypass by Primary Weakness vulnerability in yourownprogrammer YOP Poll allows Authentication Bypass.This issue affects YOP Poll: from n/a through 6.5.28.",
  "id": "GHSA-4979-4xqf-m5vx",
  "modified": "2026-04-28T21:35:29Z",
  "published": "2025-01-02T12:32:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46611"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/yop-poll/vulnerability/wordpress-yop-poll-plugin-6-5-28-vote-manipulation-due-to-broken-captcha-control-vulnerability?_s_id=cve"
    }
  ],
  "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"
    }
  ]
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list