Common Weakness Enumeration

CWE-303

Allowed

Incorrect Implementation of Authentication Algorithm

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The requirements for the product dictate the use of an established authentication algorithm, but the implementation of the algorithm is incorrect.

153 vulnerabilities reference this CWE, most recent first.

GHSA-P7C9-8XX8-H74F

Vulnerability from github – Published: 2024-12-18 15:33 – Updated: 2025-07-02 18:53
VLAI
Summary
Apache Kafka's SCRAM implementation Incorrectly Implements Authentication Algorithm
Details

Incorrect Implementation of Authentication Algorithm in Apache Kafka's SCRAM implementation.

Issue Summary: Apache Kafka's implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1]. Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message. However, Kafka's SCRAM implementation did not perform this validation.

Impact: This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3]. Deployments using SCRAM with TLS are not affected by this issue.

How to Detect If You Are Impacted: If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted. To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.

Fix Details: The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.

Affected Versions: Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.

Fixed Versions: 3.9.0 3.8.1 3.7.2

Users are advised to upgrade to 3.7.2 or later to mitigate this issue.

Recommendations for Mitigation: Users unable to upgrade to the fixed versions can mitigate the issue by: - Using TLS with SCRAM Authentication: Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception. - Considering Alternative Authentication Mechanisms: Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.kafka:kafka_2.13"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.10.2.0"
            },
            {
              "fixed": "3.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.kafka:kafka_2.13"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.8.0"
            },
            {
              "fixed": "3.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.8.0"
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.kafka:kafka_2.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.10.2.0"
            },
            {
              "fixed": "3.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.kafka:kafka_2.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.8.0"
            },
            {
              "fixed": "3.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.8.0"
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.kafka:kafka_2.11"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.10.2.0"
            },
            {
              "last_affected": "2.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.kafka:kafka_2.10"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.10.2.0"
            },
            {
              "last_affected": "0.10.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-56128"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-303"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-12-18T19:16:18Z",
    "nvd_published_at": "2024-12-18T14:15:23Z",
    "severity": "LOW"
  },
  "details": "Incorrect Implementation of Authentication Algorithm in Apache Kafka\u0027s SCRAM implementation.\n\nIssue Summary:\nApache Kafka\u0027s implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1].\nSpecifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message.\nHowever, Kafka\u0027s SCRAM implementation did not perform this validation.\n\nImpact:\nThis vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3].\nDeployments using SCRAM with TLS are not affected by this issue.\n\nHow to Detect If You Are Impacted:\nIf your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted.\nTo check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.\n\nFix Details:\nThe issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.\n\nAffected Versions:\nApache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.\n\nFixed Versions:\n3.9.0\n3.8.1\n3.7.2\n\nUsers are advised to upgrade to 3.7.2 or later to mitigate this issue.\n\nRecommendations for Mitigation:\nUsers unable to upgrade to the fixed versions can mitigate the issue by:\n- Using TLS with SCRAM Authentication:\nAlways deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.\n- Considering Alternative Authentication Mechanisms:\nEvaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.",
  "id": "GHSA-p7c9-8xx8-h74f",
  "modified": "2025-07-02T18:53:21Z",
  "published": "2024-12-18T15:33:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56128"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/kafka/commit/2cbc5bd3ca22185d9cd357c9db23a2cfb43a0fff"
    },
    {
      "type": "WEB",
      "url": "https://datatracker.ietf.org/doc/html/rfc5802"
    },
    {
      "type": "WEB",
      "url": "https://datatracker.ietf.org/doc/html/rfc5802#section-9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/kafka"
    },
    {
      "type": "WEB",
      "url": "https://kafka.apache.org/documentation/#security_sasl_scram_security"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/84dh4so32lwn7wr6c5s9mwh381vx9wkw"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/12/18/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Kafka\u0027s SCRAM implementation Incorrectly Implements Authentication Algorithm"
}

GHSA-PMJ6-9F8C-8G2M

Vulnerability from github – Published: 2022-05-24 17:43 – Updated: 2025-04-09 20:06
VLAI
Summary
Saltstack Salt Unauthenticated Arbitrary Code Execution
Details

A Incorrect Implementation of Authentication Algorithm vulnerability in of SUSE SUSE Linux Enterprise Server 15 SP 3; openSUSE Tumbleweed allows local attackers to execute arbitrary code via salt without the need to specify valid credentials. This issue affects: SUSE SUSE Linux Enterprise Server 15 SP 3 salt versions prior to 3002.2-3. openSUSE Tumbleweed salt version 3002.2-2.1 and prior versions.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "salt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3002.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-25315"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-303"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-22T22:26:04Z",
    "nvd_published_at": "2021-03-03T10:15:00Z",
    "severity": "HIGH"
  },
  "details": "A Incorrect Implementation of Authentication Algorithm vulnerability in of SUSE SUSE Linux Enterprise Server 15 SP 3; openSUSE Tumbleweed allows local attackers to execute arbitrary code via salt without the need to specify valid credentials. This issue affects: SUSE SUSE Linux Enterprise Server 15 SP 3 salt versions prior to 3002.2-3. openSUSE Tumbleweed salt version 3002.2-2.1 and prior versions.",
  "id": "GHSA-pmj6-9f8c-8g2m",
  "modified": "2025-04-09T20:06:23Z",
  "published": "2022-05-24T17:43:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25315"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=1182382"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/salt/PYSEC-2021-891.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/saltstack/salt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Saltstack Salt Unauthenticated Arbitrary Code Execution"
}

GHSA-Q2WQ-F7JQ-885V

Vulnerability from github – Published: 2026-02-21 00:31 – Updated: 2026-02-21 00:31
VLAI
Details

Sricam DeviceViewer 3.12.0.1 contains a password change security bypass vulnerability that allows authenticated users to change passwords without proper validation of the old password field. Attackers can inject a large payload into the old password parameter during the change password process to bypass validation and set an arbitrary new password.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-25436"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-303"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-20T23:16:00Z",
    "severity": "MODERATE"
  },
  "details": "Sricam DeviceViewer 3.12.0.1 contains a password change security bypass vulnerability that allows authenticated users to change passwords without proper validation of the old password field. Attackers can inject a large payload into the old password parameter during the change password process to bypass validation and set an arbitrary new password.",
  "id": "GHSA-q2wq-f7jq-885v",
  "modified": "2026-02-21T00:31:42Z",
  "published": "2026-02-21T00:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25436"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/47476"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/sricam-deviceviewer-password-change-security-bypass"
    },
    {
      "type": "WEB",
      "url": "http://www.sricam.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:A/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-Q7CF-MX43-6QM5

Vulnerability from github – Published: 2023-03-14 12:30 – Updated: 2023-03-14 12:30
VLAI
Details

A vulnerability has been identified in Mendix SAML (Mendix 7 compatible) (All Versions >= 1.16.4 < 1.17.2), Mendix SAML (Mendix 8 compatible) (All versions >= 2.2.0 < 2.2.3), Mendix SAML (Mendix 9 compatible, New Track) (All versions >= 3.1.9 < 3.2.5), Mendix SAML (Mendix 9 compatible, Upgrade Track) (All versions >= 3.1.9 < 3.2.5). The affected versions of the module insufficiently verifies the SAML assertions. This could allow unauthenticated remote attackers to bypass authentication and get access to the application.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-25957"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-303"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-14T10:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability has been identified in Mendix SAML (Mendix 7 compatible) (All Versions \u003e= 1.16.4 \u003c 1.17.2), Mendix SAML (Mendix 8 compatible) (All versions \u003e= 2.2.0 \u003c 2.2.3), Mendix SAML (Mendix 9 compatible, New Track) (All versions \u003e= 3.1.9 \u003c 3.2.5), Mendix SAML (Mendix 9 compatible, Upgrade Track) (All versions \u003e= 3.1.9 \u003c 3.2.5). The affected versions of the module insufficiently verifies the SAML assertions. This could allow unauthenticated remote attackers to bypass authentication and get access to the application.",
  "id": "GHSA-q7cf-mx43-6qm5",
  "modified": "2023-03-14T12:30:46Z",
  "published": "2023-03-14T12:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25957"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-851884.pdf"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QHMP-Q7XH-99RH

Vulnerability from github – Published: 2026-04-28 22:46 – Updated: 2026-05-08 15:28
VLAI
Summary
CoreDNS has TSIG authentication bypass on DoT, DoH, DoH3, DoQ, and gRPC
Details

Summary

CoreDNS' tsig plugin can be bypassed on non-plain-DNS transports because it trusts the transport writer's TsigStatus() instead of performing verification itself. In the attached PoC, plain DNS/TCP correctly rejects an invalid TSIG (NOTAUTH), while the same invalid-TSIG request is accepted over DoT (tls://) and DoH (https://), allowing a client without the shared secret to satisfy require all. The same bug class affects DoH3, DoQ, and gRPC.

Details

The tsig plugin decides whether an incoming TSIG was valid by consulting w.TsigStatus(): tsigStatus := w.TsigStatus(); if tsigStatus != nil { ... NOTAUTH ... } (plugin/tsig/tsig.go)

Two affected transports are shown directly in the PoC: - DoH: DoHWriter.TsigStatus() always returns nil (core/dnsserver/https.go), and the HTTP server passes unpacked DNS messages directly into the plugin chain. - DoT: the TLS server builds a dns.Server without setting TsigSecret (core/dnsserver/server_tls.go), unlike plain DNS/TCP/UDP which sets TsigSecret: s.tsigSecret (core/dnsserver/server.go).

The same transport-family bug pattern also appears on other transports: - DoH3 reuses the DoH writer path (core/dnsserver/server_https3.go -> core/dnsserver/https.go), so it inherits the same TsigStatus() == nil behavior. - DoQ uses DoQWriter.TsigStatus() error { return nil } (core/dnsserver/quic.go). - gRPC uses gRPCresponse.TsigStatus() error { return nil } (core/dnsserver/server_grpc.go).

The attached PoC was kept deliberately small (baseline TCP+DoT+DoH only) for convenience.

PoC

  1. Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well)
  2. Run python3 ./tsig-repro.py
  3. Expected output: *** Start CoreDNS *** Corefile: /tmp/vh-f001-tsig-doh-dot-bypass/Corefile Log: /tmp/vh-f001-tsig-doh-dot-bypass/coredns.log

*** Baseline (plain TCP) *** no_tsig rcode=5 (expected REFUSED=5) invalid_tsig rcode=9 (expected NOTAUTH=9)

*** Candidate (DoT) *** no_tsig rcode=5 (expected REFUSED=5) invalid_tsig rcode=0 ancount=1 (expected NOERROR=0 and ancount>0)

*** Candidate (DoH) *** no_tsig http=200 rcode=5 (expected REFUSED=5) invalid_tsig http=200 rcode=0 ancount=1 (expected NOERROR=0 and ancount>0)

*** OK *** TSIG bypass reproduced: plain TCP rejects invalid TSIG, while DoT and DoH accept it. Results: /tmp/vh-f001-tsig-doh-dot-bypass/results.json

Impact

Unauthenticated remote clients can bypass TSIG-based authentication/authorization on first-class encrypted transports, enabling access to whatever the deployment intended to restrict behind tsig { require all } (e.g., zone data/privileged queries, etc.).

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": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coredns/coredns"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.14.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33190"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-303"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-28T22:46:15Z",
    "nvd_published_at": "2026-05-05T20:16:36Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nCoreDNS\u0027 tsig plugin can be bypassed on non-plain-DNS transports because it trusts the transport writer\u0027s TsigStatus() instead of performing verification itself. In the attached PoC, plain DNS/TCP correctly rejects an invalid TSIG (NOTAUTH), while the same invalid-TSIG request is accepted over DoT (tls://) and DoH (https://), allowing a client without the shared secret to satisfy require all. The same bug class affects DoH3, DoQ, and gRPC.\n\n### Details\nThe tsig plugin decides whether an incoming TSIG was valid by consulting w.TsigStatus(): tsigStatus := w.TsigStatus(); if tsigStatus != nil { ... NOTAUTH ... } (plugin/tsig/tsig.go)\n\nTwo affected transports are shown directly in the PoC:\n- DoH: DoHWriter.TsigStatus() always returns nil (core/dnsserver/https.go), and the HTTP server passes unpacked DNS messages directly into the plugin chain.\n- DoT: the TLS server builds a dns.Server without setting TsigSecret (core/dnsserver/server_tls.go), unlike plain DNS/TCP/UDP which sets TsigSecret: s.tsigSecret (core/dnsserver/server.go).\n\nThe same transport-family bug pattern also appears on other transports:\n- DoH3 reuses the DoH writer path (core/dnsserver/server_https3.go -\u003e core/dnsserver/https.go), so it inherits the same TsigStatus() == nil behavior.\n- DoQ uses DoQWriter.TsigStatus() error { return nil } (core/dnsserver/quic.go).\n- gRPC uses gRPCresponse.TsigStatus() error { return nil } (core/dnsserver/server_grpc.go).\n\nThe attached PoC was kept deliberately small (baseline TCP+DoT+DoH only) for convenience.\n\n### PoC\n1. Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well)\n2. Run python3 ./tsig-repro.py\n3. Expected output:\n*** Start CoreDNS ***\nCorefile: /tmp/vh-f001-tsig-doh-dot-bypass/Corefile\nLog: /tmp/vh-f001-tsig-doh-dot-bypass/coredns.log\n\n*** Baseline (plain TCP) ***\nno_tsig rcode=5 (expected REFUSED=5)\ninvalid_tsig rcode=9 (expected NOTAUTH=9)\n\n*** Candidate (DoT) ***\nno_tsig rcode=5 (expected REFUSED=5)\ninvalid_tsig rcode=0 ancount=1 (expected NOERROR=0 and ancount\u003e0)\n\n*** Candidate (DoH) ***\nno_tsig http=200 rcode=5 (expected REFUSED=5)\ninvalid_tsig http=200 rcode=0 ancount=1 (expected NOERROR=0 and ancount\u003e0)\n\n*** OK ***\nTSIG bypass reproduced: plain TCP rejects invalid TSIG, while DoT and DoH accept it.\nResults: /tmp/vh-f001-tsig-doh-dot-bypass/results.json\n\n\n### Impact\nUnauthenticated remote clients can bypass TSIG-based authentication/authorization on first-class encrypted transports, enabling access to whatever the deployment intended to restrict behind tsig { require all } (e.g., zone data/privileged queries, etc.).",
  "id": "GHSA-qhmp-q7xh-99rh",
  "modified": "2026-05-08T15:28:24Z",
  "published": "2026-04-28T22:46:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/coredns/coredns/security/advisories/GHSA-qhmp-q7xh-99rh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33190"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/coredns/coredns"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coredns/coredns/releases/tag/v1.14.3"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "CoreDNS has TSIG authentication bypass on DoT, DoH, DoH3, DoQ, and gRPC"
}

GHSA-QJ8F-GV99-RCHC

Vulnerability from github – Published: 2025-10-07 21:31 – Updated: 2025-10-07 21:31
VLAI
Details

Dell PowerProtect Data Domain with Data Domain Operating System (DD OS) of Feature Release versions 7.7.1.0 through 8.1.0.10, LTS2024 release Versions 7.13.1.0 through 7.13.1.25, LTS 2023 release versions 7.10.1.0 through 7.10.1.50, contain an incorrect Implementation of Authentication Algorithm vulnerability in the RestAPI. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Unauthorized access.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-43727"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-303"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-07T20:15:34Z",
    "severity": "HIGH"
  },
  "details": "Dell PowerProtect Data Domain with Data Domain Operating System (DD OS) of Feature Release versions 7.7.1.0 through 8.1.0.10, LTS2024 release Versions 7.13.1.0 through 7.13.1.25, LTS 2023 release versions 7.10.1.0 through 7.10.1.50, contain an incorrect Implementation of Authentication Algorithm vulnerability in the RestAPI. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Unauthorized access.",
  "id": "GHSA-qj8f-gv99-rchc",
  "modified": "2025-10-07T21:31:07Z",
  "published": "2025-10-07T21:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43727"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000348708/dsa-2025-159-security-update-for-dell-powerprotect-data-domain-multiple-vulnerabilities"
    }
  ],
  "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"
    }
  ]
}

GHSA-QJFM-3PC3-MMJ2

Vulnerability from github – Published: 2024-05-03 03:30 – Updated: 2024-05-03 03:30
VLAI
Details

D-Link DIR-2640 HNAP PrivateLogin Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of D-Link DIR-2640 routers. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the web management interface, which listens on TCP port 80 by default. A crafted XML element in the login request can cause authentication to succeed without providing proper credentials. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-19545.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-32148"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-303"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-03T02:15:18Z",
    "severity": "MODERATE"
  },
  "details": "D-Link DIR-2640 HNAP PrivateLogin Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of D-Link DIR-2640 routers. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the web management interface, which listens on TCP port 80 by default. A crafted XML element in the login request can cause authentication to succeed without providing proper credentials. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-19545.",
  "id": "GHSA-qjfm-3pc3-mmj2",
  "modified": "2024-05-03T03:30:50Z",
  "published": "2024-05-03T03:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32148"
    },
    {
      "type": "WEB",
      "url": "https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10323"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-23-540"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QRRF-WPVQ-7P64

Vulnerability from github – Published: 2024-05-03 03:30 – Updated: 2024-05-03 03:30
VLAI
Details

D-Link DIR-2150 LoginPassword Incorrect Implementation of Authentication Algorithm Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of D-Link DIR-2150 routers. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the SOAP API interface, which listens on TCP port 80 by default. A crafted login request can cause authentication to succeed without providing proper credentials. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-20552.

Severity
8.8 (High)
CVSS:3.0/AV:A/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-34274"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-303"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-03T02:15:26Z",
    "severity": "HIGH"
  },
  "details": "D-Link DIR-2150 LoginPassword Incorrect Implementation of Authentication Algorithm Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of D-Link DIR-2150 routers. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the SOAP API interface, which listens on TCP port 80 by default. A crafted login request can cause authentication to succeed without providing proper credentials. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-20552.",
  "id": "GHSA-qrrf-wpvq-7p64",
  "modified": "2024-05-03T03:30:51Z",
  "published": "2024-05-03T03:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34274"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-23-627"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QVMC-92VG-6R35

Vulnerability from github – Published: 2025-12-22 12:30 – Updated: 2026-01-02 15:34
VLAI
Summary
Mattermost with Jira plugin enabled has Incorrect Implementation of Authentication Algorithm
Details

Mattermost versions 11.1.x <= 11.1.0, 11.0.x <= 11.0.5, 10.12.x <= 10.12.3, 10.11.x <= 10.11.7 with the Jira plugin enabled and Mattermost Jira plugin versions <=4.4.0 fail to enforce authentication and issue-key path restrictions in the Jira plugin, which allows an unauthenticated attacker who knows a valid user ID to issue authenticated GET and POST requests to the Jira server via crafted plugin payloads that spoof the user ID and inject arbitrary issue key paths. Mattermost Advisory ID: MMSA-2025-00555

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0-20251121122154-b57c297c6d7a"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-plugin-jira"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-14273"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-303"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-02T15:34:07Z",
    "nvd_published_at": "2025-12-22T12:16:19Z",
    "severity": "HIGH"
  },
  "details": "Mattermost versions 11.1.x \u003c= 11.1.0, 11.0.x \u003c= 11.0.5, 10.12.x \u003c= 10.12.3, 10.11.x \u003c= 10.11.7 with the Jira plugin enabled and Mattermost Jira plugin versions \u003c=4.4.0 fail to enforce authentication and issue-key path restrictions in the Jira plugin, which allows an unauthenticated attacker who knows a valid user ID to issue authenticated GET and POST requests to the Jira server via crafted plugin payloads that spoof the user ID and inject arbitrary issue key paths. Mattermost Advisory ID: MMSA-2025-00555",
  "id": "GHSA-qvmc-92vg-6r35",
  "modified": "2026-01-02T15:34:07Z",
  "published": "2025-12-22T12:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14273"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost-plugin-jira/commit/bf9a1b7e81eb83304056b397c6abab3b062e14a2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/317025c411ec8c34381fdd4f137a17c63895a4f2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/463e0d0d3930782d3c975da26c991dcbfccd751c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/7c36acb68ce3c69defaea540623f794c84ecba93"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/92b1e705225d97ce54d9f720f2e7aa66dc2a086b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/b57c297c6d7ae6812d85e32a625806ac9555deee"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mattermost with Jira plugin enabled has Incorrect Implementation of Authentication Algorithm"
}

GHSA-QX2W-WX28-8MHV

Vulnerability from github – Published: 2022-12-30 15:30 – Updated: 2026-02-23 09:31
VLAI
Details

Incorrect implementation in authentication protocol in M-Files Client before 22.5.11356.0 allows high privileged user to get other users tokens to another resource.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-4861"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-303"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-30T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect implementation in authentication protocol in M-Files Client before 22.5.11356.0 allows high privileged user to get other users tokens to another resource.",
  "id": "GHSA-qx2w-wx28-8mhv",
  "modified": "2026-02-23T09:31:17Z",
  "published": "2022-12-30T15:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4861"
    },
    {
      "type": "WEB",
      "url": "https://empower.m-files.com/security-advisories/CVE-2022-4861"
    },
    {
      "type": "WEB",
      "url": "https://product.m-files.com/security-advisories/cve-2022-4861"
    },
    {
      "type": "WEB",
      "url": "https://www.m-files.com/about/trust-center/security-advisories/cve-2022-4861"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-90: Reflection Attack in Authentication Protocol

An adversary can abuse an authentication protocol susceptible to reflection attack in order to defeat it. Doing so allows the adversary illegitimate access to the target system, without possessing the requisite credentials. Reflection attacks are of great concern to authentication protocols that rely on a challenge-handshake or similar mechanism. An adversary can impersonate a legitimate user and can gain illegitimate access to the system by successfully mounting a reflection attack during authentication.

← Back to the CWE list