Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

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

5964 vulnerabilities reference this CWE, most recent first.

GHSA-C2XG-QJQW-2V98

Vulnerability from github – Published: 2026-07-15 16:45 – Updated: 2026-07-15 16:45
VLAI
Summary
MantisBT: SOAP API Authentication Bypass with Privilege Escalation to Administrator
Details

MantisBT 2.28.3 and earlier contains a critical authentication bypass in the SOAP API's mci_check_login() function. Any user knowing any valid cookie_string can authenticate as any other user (knowing their username), including the administrator, without knowing the target's password.

The vulnerability is exploitable with zero prior access on default MantisBT installations because self-registration is enabled by default ($g_allow_signup = ON). A self-registered user can use their own cookie_string (readable from their browser's MANTIS_STRING_COOKIE cookie after login) to impersonate the administrator via the SOAP API.

The REST API is NOT affected. The REST API's AuthMiddleware derives the username server-side from the API token or session cookie, so the username cannot be spoofed.

The Web UI is NOT affected. The Web UI authenticates via PHP session cookies (PHPSESSID) and validates the MANTIS_STRING_COOKIE against the logged-in user through auth_is_cookie_valid(). The username is derived server-side from the cookie, not supplied by the client.

Impact

  • Full administrator access to the SOAP API from zero prior access (with self-registration enabled, which is the default)
  • Read/write all issues including private issues and notes across all projects
  • Full data exfiltration of all bug reports, attachments, user accounts (id, name, email), and non-private configuration values via the 71 SOAP operations available
  • Destructive operations: delete projects, issues, attachments, tags, categories, and versions
  • Data manipulation: create/modify issues, impersonate reporters, manage project structure
  • Chains with other vulnerabilities: the SOAP admin access enables exploitation of SOAP vulnerabilities that require administrator privileges

Patches

  • https://github.com/mantisbt/mantisbt/commit/e3571c319b1721b41b0dc4b5b5203cbdcbe0c2ee

Workarounds

None

Resources

  • https://mantisbt.org/bugs/view.php?id=37121

Credits

MantisBT would like to thank McCaulay Hudson (@_McCaulay) of watchTowr for originally identifying and responsibly reporting the issue.

The vulnerability was subsequently discovered by other researchers, while the team was working on fixing and preparing the release. MantisBT credits them here, in chronological order of their reports: - Keitaro Yamazaki (@tyage) - Harrison Keating (@voraci0us) - Chandler Johnson (@chndlrx) - Bharat Devasani (@bharatdevasani)

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.28.3"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "mantisbt/mantisbt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.28.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47156"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-15T16:45:22Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "MantisBT 2.28.3 and earlier contains a critical authentication bypass in the SOAP API\u0027s mci_check_login() function. Any user knowing any valid cookie_string can authenticate as any other user (knowing their username), including the administrator, without knowing the target\u0027s password.\n\nThe vulnerability is exploitable with zero prior access on default MantisBT installations because self-registration is enabled by default ($g_allow_signup = ON). A self-registered user can use their own cookie_string (readable from their browser\u0027s MANTIS_STRING_COOKIE cookie after login) to impersonate the administrator via the SOAP API.\n\nThe REST API is NOT affected. The REST API\u0027s AuthMiddleware derives the username server-side from the API token or session cookie, so the username cannot be spoofed.\n\nThe Web UI is NOT affected. The Web UI authenticates via PHP session cookies (PHPSESSID) and validates the MANTIS_STRING_COOKIE against the logged-in user through auth_is_cookie_valid(). The username is derived server-side from the cookie, not supplied by the client.\n\n### Impact\n- Full administrator access to the SOAP API from zero prior access (with self-registration enabled, which is the default)\n- Read/write all issues including private issues and notes across all projects\n- Full data exfiltration of all bug reports, attachments, user accounts (id, name, email), and non-private configuration values via the 71 SOAP operations available\n- Destructive operations: delete projects, issues, attachments, tags, categories, and versions\n- Data manipulation: create/modify issues, impersonate reporters, manage project structure\n- Chains with other vulnerabilities: the SOAP admin access enables exploitation of SOAP vulnerabilities that require administrator privileges\n\n### Patches\n- https://github.com/mantisbt/mantisbt/commit/e3571c319b1721b41b0dc4b5b5203cbdcbe0c2ee\n\n### Workarounds\nNone\n\n### Resources\n- https://mantisbt.org/bugs/view.php?id=37121\n\n### Credits\nMantisBT would like to thank McCaulay Hudson ([@_McCaulay](https://x.com/_mccaulay)) of [watchTowr](https://labs.watchtowr.com/) for originally identifying and responsibly reporting the issue.\n\nThe vulnerability  was subsequently discovered by other researchers, while the team was working on fixing and preparing the release. MantisBT credits them here, in chronological order of their reports: \n- Keitaro Yamazaki (@tyage) \n- Harrison Keating (@voraci0us)\n- Chandler Johnson (@chndlrx)\n- Bharat Devasani (@bharatdevasani)",
  "id": "GHSA-c2xg-qjqw-2v98",
  "modified": "2026-07-15T16:45:22Z",
  "published": "2026-07-15T16:45:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mantisbt/mantisbt/security/advisories/GHSA-c2xg-qjqw-2v98"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mantisbt/mantisbt/commit/e3571c319b1721b41b0dc4b5b5203cbdcbe0c2ee"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mantisbt/mantisbt"
    },
    {
      "type": "WEB",
      "url": "https://mantisbt.org/bugs/view.php?id=37121"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MantisBT: SOAP API Authentication Bypass with Privilege Escalation to Administrator"
}

GHSA-C32J-VQHX-RX3X

Vulnerability from github – Published: 2026-05-18 17:24 – Updated: 2026-06-02 22:12
VLAI
Summary
ruby-jwt: Empty-key HMAC bypass; cross-language sibling of CVE-2026-44351
Details

JWT.decode(token, '', true, algorithm: 'HS256') accepts an attacker-forged token. OpenSSL::HMAC.digest('SHA256', '', payload) returns a valid digest under an empty key, and no raise InvalidKeyError if key.empty? precondition exists in the HMAC algorithm.

JWT.decode(token, "", true, algorithm: 'HS256')
  -> JWA::Hmac.verify(verification_key: "", ...)
  -> OpenSSL::HMAC.digest('SHA256', "", signing_input) == signature

The same path is reached when a keyfinder block or key_finder: argument returns "", nil, or an array containing nil for an unknown key. JWT::Decode#find_key only rejects literal nil and empty arrays, and JWT::JWA::Hmac silently coerces nil to "" (signing_key ||= '') before signing.

JWT.decode(token, nil, true, algorithms: ['HS256']) { |_h| "" }
  -> find_key returns ""               # "" && !Array("").empty? == true
  -> JWA::Hmac.verify(verification_key: "", ...)
  -> verifies

Common application patterns that produce the unsafe value: redis.get("kid:#{kid}").to_s, ORM string columns with default: '', ENV['SECRET'] || '', Hash.new('') lookups, [primary, fallback] where fallback may be nil. Applications passing a non-empty static key:, or whose keyfinder returns nil / raises on miss, are not affected.

The existing enforce_hmac_key_length option would block this but defaults to false. On OpenSSL ≥ 3.5 the empty-key HMAC.digest call no longer raises, so the OpenSSL-3.0 rescue in JWA::Hmac#sign does not fire.

Affects HS256/HS384/HS512 via both JWT.decode (positional key and block keyfinder) and JWT::EncodedToken#verify_signature!(key_finder:)

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45363"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1391",
      "CWE-287",
      "CWE-326"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T17:24:55Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "`JWT.decode(token, \u0027\u0027, true, algorithm: \u0027HS256\u0027)` accepts an attacker-forged token.\n`OpenSSL::HMAC.digest(\u0027SHA256\u0027, \u0027\u0027, payload)` returns a valid digest under an empty key, and no `raise\n  InvalidKeyError if key.empty?` precondition exists in the HMAC algorithm.\n\n```\nJWT.decode(token, \"\", true, algorithm: \u0027HS256\u0027)\n  -\u003e JWA::Hmac.verify(verification_key: \"\", ...)\n  -\u003e OpenSSL::HMAC.digest(\u0027SHA256\u0027, \"\", signing_input) == signature\n```\n\nThe same path is reached when a keyfinder block or key_finder: argument returns \"\", nil, or an\narray containing nil for an unknown key. JWT::Decode#find_key only rejects literal nil and empty\narrays, and JWT::JWA::Hmac silently coerces nil to \"\" (signing_key ||= \u0027\u0027) before signing.\n\n```\nJWT.decode(token, nil, true, algorithms: [\u0027HS256\u0027]) { |_h| \"\" }\n  -\u003e find_key returns \"\"               # \"\" \u0026\u0026 !Array(\"\").empty? == true\n  -\u003e JWA::Hmac.verify(verification_key: \"\", ...)\n  -\u003e verifies\n```\nCommon application patterns that produce the unsafe value: `redis.get(\"kid:#{kid}\").to_s`, ORM string columns with `default: \u0027\u0027`, `ENV[\u0027SECRET\u0027] || \u0027\u0027, Hash.new(\u0027\u0027)` lookups, [primary, fallback] where fallback may be nil. Applications passing a non-empty static key:, or whose keyfinder returns nil / raises on miss, are not affected.\n\nThe existing `enforce_hmac_key_length` option would block this but defaults to false. On OpenSSL \u2265 3.5 the empty-key HMAC.digest call no longer raises, so the OpenSSL-3.0 rescue in JWA::Hmac#sign does not fire.\n\nAffects HS256/HS384/HS512 via both JWT.decode (positional key and block keyfinder) and\n`JWT::EncodedToken#verify_signature!(key_finder:)`",
  "id": "GHSA-c32j-vqhx-rx3x",
  "modified": "2026-06-02T22:12:50Z",
  "published": "2026-05-18T17:24:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jwt/ruby-jwt/security/advisories/GHSA-c32j-vqhx-rx3x"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jwt/ruby-jwt/issues/724"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jwt/ruby-jwt/commit/db560b769a07bd9724e77ff505011ac01872106f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jwt/ruby-jwt"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jwt/ruby-jwt/releases/tag/v2.10.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jwt/ruby-jwt/releases/tag/v3.2.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/jwt/CVE-2026-45363.yml"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-45363"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ruby-jwt: Empty-key HMAC bypass; cross-language sibling of CVE-2026-44351"
}

GHSA-C32R-W7R9-9W44

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

spacewalk-backend in Red Hat Network Satellite 5.4 on Red Hat Enterprise Linux 6 does not properly authorize or authenticate uploads to the NULL organization when mod_wsgi is used, which allows remote attackers to cause a denial of service (/var partition disk consumption and failed updates) via a large number of package uploads.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2012-1145"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2012-06-16T00:55:00Z",
    "severity": "MODERATE"
  },
  "details": "spacewalk-backend in Red Hat Network Satellite 5.4 on Red Hat Enterprise Linux 6 does not properly authorize or authenticate uploads to the NULL organization when mod_wsgi is used, which allows remote attackers to cause a denial of service (/var partition disk consumption and failed updates) via a large number of package uploads.",
  "id": "GHSA-c32r-w7r9-9w44",
  "modified": "2022-05-13T01:03:59Z",
  "published": "2022-05-13T01:03:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-1145"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/74498"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2012-0436.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/48664"
    },
    {
      "type": "WEB",
      "url": "http://www.osvdb.org/81481"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/52832"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1026873"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-C337-RR2J-G4H6

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

The pam_sm_authenticate function in pam_sshauth.c in libpam-sshauth might allow context-dependent attackers to bypass authentication or gain privileges via a system user account.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2016-4422"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2016-05-06T17:59:00Z",
    "severity": "CRITICAL"
  },
  "details": "The pam_sm_authenticate function in pam_sshauth.c in libpam-sshauth might allow context-dependent attackers to bypass authentication or gain privileges via a system user account.",
  "id": "GHSA-c337-rr2j-g4h6",
  "modified": "2022-05-13T01:11:15Z",
  "published": "2022-05-13T01:11:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-4422"
    },
    {
      "type": "WEB",
      "url": "https://bazaar.launchpad.net/~ltsp-upstream/ltsp/libpam-sshauth/revision/114#src/pam_sshauth.c"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2016/dsa-3567"
    }
  ],
  "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-C346-QQ93-PFRW

Vulnerability from github – Published: 2025-03-06 15:34 – Updated: 2025-03-07 18:31
VLAI
Details

An issue in TAAGSOLUTIONS GmbH MyTaag v.2024-11-24 and before allows a remote attacker to escalate privileges via the deactivation of the activated second factor to the /session endpoint

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-25450"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-06T15:15:17Z",
    "severity": "MODERATE"
  },
  "details": "An issue in TAAGSOLUTIONS GmbH MyTaag v.2024-11-24 and before allows a remote attacker to escalate privileges via the deactivation of the activated second factor to the /session endpoint",
  "id": "GHSA-c346-qq93-pfrw",
  "modified": "2025-03-07T18:31:03Z",
  "published": "2025-03-06T15:34:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25450"
    },
    {
      "type": "WEB",
      "url": "https://piuswalter.de/blog/2fa-bypass-and-deactivation-attack-in-mytaag"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C375-QWV9-RX4W

Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2022-05-24 17:40
VLAI
Details

Improper Authentication vulnerability in the cookie parameter of ZIV AUTOMATION 4CCT-EA6-334126BF allows a local attacker to perform modifications in several parameters of the affected device as an authenticated user.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-25910"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-29T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper Authentication vulnerability in the cookie parameter of ZIV AUTOMATION 4CCT-EA6-334126BF allows a local attacker to perform modifications in several parameters of the affected device as an authenticated user.",
  "id": "GHSA-c375-qwv9-rx4w",
  "modified": "2022-05-24T17:40:37Z",
  "published": "2022-05-24T17:40:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25910"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe-cert.es/en/early-warning/ics-advisories/4cct-vulnerable-improper-authentication"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-C38M-V4M2-524V

Vulnerability from github – Published: 2022-05-14 01:17 – Updated: 2024-02-21 22:10
VLAI
Summary
Apache Tomcat Allows Remote Attackers to Spoof AJP Requests
Details

Certain AJP protocol connector implementations in Apache Tomcat 7.0.0 through 7.0.20, 6.0.0 through 6.0.33, 5.5.0 through 5.5.33, and possibly other versions allow remote attackers to spoof AJP requests, bypass authentication, and obtain sensitive information by causing the connector to interpret a request body as a new request.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.0.20"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.33"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.0.34"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.5.33"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.5.34"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2011-3190"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-17T22:19:29Z",
    "nvd_published_at": "2011-08-31T23:55:00Z",
    "severity": "HIGH"
  },
  "details": "Certain AJP protocol connector implementations in Apache Tomcat 7.0.0 through 7.0.20, 6.0.0 through 6.0.33, 5.5.0 through 5.5.33, and possibly other versions allow remote attackers to spoof AJP requests, bypass authentication, and obtain sensitive information by causing the connector to interpret a request body as a new request.",
  "id": "GHSA-c38m-v4m2-524v",
  "modified": "2024-02-21T22:10:43Z",
  "published": "2022-05-14T01:17:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-3190"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/a2538ce78f83b7376c48d12d8247600079d789b1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat55/commit/be3eb28f82250a5c81a1c42216570ebf892aefac"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/69472"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/tomcat"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/bugzilla/show_bug.cgi?id=51698"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/06cfb634bc7bf37af7d8f760f118018746ad8efbd519c4b789ac9c2e@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/8dcaf7c3894d66cb717646ea1504ea6e300021c85bb4e677dc16b1aa@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r3aacc40356defc3f248aa504b1e48e819dd0471a0a83349080c6bcbf@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r584a714f141eff7b1c358d4679288177bd4ca4558e9999d15867d4b5@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A14933"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A19465"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20130121232525/http://www.securityfocus.com/archive/1/519466/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20130314002148/http://www.securityfocus.com/bid/49353"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20131214094052/http://www.securitytracker.com/id?1025993"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=132215163318824\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=133469267822771\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=136485229118404\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=139344343412337\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://securityreason.com/securityalert/8362"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2012/dsa-2401"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2011:156"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Apache Tomcat Allows Remote Attackers to Spoof AJP Requests"
}

GHSA-C3M2-JQMQ-PVP3

Vulnerability from github – Published: 2026-05-29 20:25 – Updated: 2026-06-09 11:00
VLAI
Summary
authentik's XML Signature Wrapping in SAML Source ACS allows authentication as arbitrary federated user
Details

Summary

authentik's SAML Source ACS endpoint is vulnerable to XML Signature Wrapping when validating upstream SAML responses. An attacker with any account at the upstream IdP can reuse a valid signed assertion to authenticate as another federated user.

### Patches

authentik 2026.5.1, 2026.2.4 and 2025.12.6 fix this issue.

### Impact

Affected: authentik deployments using a SAML Source for upstream SAML federation with signed assertions, or signed responses without signed assertions. Not affected: deployments that do not use SAML Source for upstream SAML federation.

The SAML Source trusts that the verified XML signature belongs to the assertion or response that authentik later consumes. A crafted SAML response can make signature verification succeed against the attacker's original signed assertion while authentik reads identity data from a different forged assertion.

An attacker first completes a legitimate login to the upstream IdP and captures the signed SAML response sent through their browser. They then submit a modified response to the ACS endpoint where the valid signature still verifies, but the consumed assertion contains a victim identifier or attacker-chosen attributes.

The attacker can authenticate as a victim who has previously used the SAML Source, or as a local user matched by forged email or username when those matching modes are enabled.

### Workarounds

Disable affected SAML Sources, or block access to their ACS endpoints.

### For more information

If there are any questions or comments about this advisory:

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "goauthentik.io"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260528144335-a370d76d23c7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47201"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-287",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T20:25:48Z",
    "nvd_published_at": "2026-06-02T21:16:27Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n \n authentik\u0027s SAML Source ACS endpoint is vulnerable to XML Signature Wrapping when validating upstream SAML responses. An attacker with any account at the upstream IdP can reuse a valid signed assertion to authenticate as another federated user.\n \n ### Patches\n \n authentik 2026.5.1, 2026.2.4 and 2025.12.6 fix this issue.\n \n ### Impact\n \n Affected: authentik deployments using a SAML Source for upstream SAML federation with signed assertions, or signed responses without signed assertions. Not affected: deployments that do not use SAML Source for upstream SAML federation.\n \n The SAML Source trusts that the verified XML signature belongs to the assertion or response that authentik later consumes. A crafted SAML response can make signature verification succeed against the attacker\u0027s original signed assertion while authentik reads identity data from a different forged assertion.\n \n An attacker first completes a legitimate login to the upstream IdP and captures the signed SAML response sent through their browser. They then submit a modified response to the ACS endpoint where the valid signature still verifies, but the consumed assertion contains a victim identifier or attacker-chosen attributes.\n \n The attacker can authenticate as a victim who has previously used the SAML Source, or as a local user matched by forged email or username when those matching modes are enabled.\n \n ### Workarounds\n \n Disable affected SAML Sources, or block access to their ACS endpoints.\n \n ### For more information\n \nIf there are any questions or comments about this advisory:\n \n - Send an email to [security@goauthentik.io](mailto:security@goauthentik.io)",
  "id": "GHSA-c3m2-jqmq-pvp3",
  "modified": "2026-06-09T11:00:16Z",
  "published": "2026-05-29T20:25:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/goauthentik/authentik/security/advisories/GHSA-c3m2-jqmq-pvp3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47201"
    },
    {
      "type": "WEB",
      "url": "https://github.com/goauthentik/authentik/commit/a370d76d23c7de0fceed064ca322e33e6ebf0119"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/goauthentik/authentik"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "authentik\u0027s XML Signature Wrapping in SAML Source ACS allows authentication as arbitrary federated user"
}

GHSA-C3MM-5X36-486P

Vulnerability from github – Published: 2022-05-24 19:19 – Updated: 2022-07-13 00:01
VLAI
Details

Phone Shop Sales Managements System using PHP with Source Code 1.0 is vulnerable to authentication bypass which leads to account takeover of the admin.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-36560"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-02T10:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Phone Shop Sales Managements System using PHP with Source Code 1.0 is vulnerable to authentication bypass which leads to account takeover of the admin.",
  "id": "GHSA-c3mm-5x36-486p",
  "modified": "2022-07-13T00:01:30Z",
  "published": "2022-05-24T19:19:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36560"
    },
    {
      "type": "WEB",
      "url": "https://pratikkhalane91.medium.com/cve-2021-35559-bb62022dd08a"
    },
    {
      "type": "WEB",
      "url": "https://www.sourcecodester.com"
    }
  ],
  "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-C3P4-VM8F-386P

Vulnerability from github – Published: 2025-02-25 17:49 – Updated: 2025-02-25 17:49
VLAI
Summary
Navidrome allows an authentication bypass in Subsonic API with non-existent username
Details

Summary

In certain Subsonic API endpoints, authentication can be bypassed by using a non-existent username combined with an empty (salted) password hash. This allows read-only access to the server’s resources, though attempts at write operations fail with a “permission denied” error.

Details

A flaw in the authentication check process allows an attacker to specify any arbitrary username that does not exist on the system, along with a salted hash of an empty password. Under these conditions, Navidrome treats the request as authenticated, granting access to various Subsonic endpoints without requiring valid credentials.

Proof of Concept (PoC)

  1. Generate a random salt:

javascript // e.g., salt = "x1vbudn1m6d" Math.random().toString(36).substring(2, 15)

  1. Calculate the MD5 hash of an empty password plus the salt:

shell # Using the example salt above echo -n "x1vbudn1m6d" | md5sum 81f0c0fb5d202ab0d012e6eaeb722d79 -

  1. Send a request specifying a fake user, with the hash and salt values:

GET https://[host]/rest/getPlaylists?u=FakeUser&t=81f0c0fb5d202ab0d012e6eaeb722d79&s=x1vbudn1m6d&v=1.16.1&c=castafiore&f=json

Impact

An attacker can use any non-existent username to bypass the authentication system and gain access to various read-only data in Navidrome, such as user playlists. However, any attempt to modify data fails due to insufficient permissions, limiting the impact to unauthorized viewing of information.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/navidrome/navidrome"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.52.0"
            },
            {
              "fixed": "0.54.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27112"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-25T17:49:07Z",
    "nvd_published_at": "2025-02-24T19:15:14Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nIn certain Subsonic API endpoints, authentication can be bypassed by using a non-existent username combined with an empty (salted) password hash. This allows read-only access to the server\u2019s resources, though attempts at write operations fail with a \u201cpermission denied\u201d error.\n\n### Details\n\nA flaw in the authentication check process allows an attacker to specify any arbitrary username that does not exist on the system, along with a salted hash of an empty password. Under these conditions, Navidrome treats the request as authenticated, granting access to various Subsonic endpoints without requiring valid credentials.\n\n### Proof of Concept (PoC)\n\n1. Generate a random salt:\n\n   ```javascript\n   // e.g., salt = \"x1vbudn1m6d\"\n   Math.random().toString(36).substring(2, 15)\n   ```\n\n2. Calculate the MD5 hash of an empty password plus the salt:\n\n   ```shell\n   # Using the example salt above\n   echo -n \"x1vbudn1m6d\" | md5sum\n   81f0c0fb5d202ab0d012e6eaeb722d79  -\n   ```\n\n3. Send a request specifying a fake user, with the hash and salt values:\n\n   ```\n   GET https://[host]/rest/getPlaylists?u=FakeUser\u0026t=81f0c0fb5d202ab0d012e6eaeb722d79\u0026s=x1vbudn1m6d\u0026v=1.16.1\u0026c=castafiore\u0026f=json\n   ```\n\n### Impact\n\nAn attacker can use any non-existent username to bypass the authentication system and gain access to various read-only data in Navidrome, such as user playlists. However, any attempt to modify data fails due to insufficient permissions, limiting the impact to unauthorized viewing of information.",
  "id": "GHSA-c3p4-vm8f-386p",
  "modified": "2025-02-25T17:49:07Z",
  "published": "2025-02-25T17:49:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/navidrome/navidrome/security/advisories/GHSA-c3p4-vm8f-386p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27112"
    },
    {
      "type": "WEB",
      "url": "https://github.com/navidrome/navidrome/commit/09ae41a2da66264c60ef307882362d2e2d8d8b89"
    },
    {
      "type": "WEB",
      "url": "https://github.com/navidrome/navidrome/commit/287079a9e409fb6b9708ca384d7daa7b5185c1a0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/navidrome/navidrome"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Navidrome allows an authentication bypass in Subsonic API with non-existent username"
}

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.