GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-522

Allowed-with-Review

Insufficiently Protected Credentials

Abstraction: Class · Status: Incomplete

The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.

1941 vulnerabilities reference this CWE, most recent first.

GHSA-G8HH-GFGV-C2M8

Vulnerability from github – Published: 2022-05-24 17:26 – Updated: 2024-02-14 18:30
VLAI
Details

An issue was discovered on Nescomed Multipara Monitor M1000 devices. The physical UART debug port provides a shell, without requiring a password, with complete access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-15483"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-26T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered on Nescomed Multipara Monitor M1000 devices. The physical UART debug port provides a shell, without requiring a password, with complete access.",
  "id": "GHSA-g8hh-gfgv-c2m8",
  "modified": "2024-02-14T18:30:24Z",
  "published": "2022-05-24T17:26:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15483"
    },
    {
      "type": "WEB",
      "url": "https://payatu.com/advisory/unauthenticated-uart-root-shell--in-niscomed-patient-monitor"
    },
    {
      "type": "WEB",
      "url": "https://www.niscomed.com/multipara-monitor.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G8HR-M8MG-WMFP

Vulnerability from github – Published: 2024-11-18 18:30 – Updated: 2024-11-18 18:30
VLAI
Details

A vulnerability in the web-based management interface of Cisco SD-WAN vManage Software could allow an authenticated, remote attacker to read arbitrary files on the underlying filesystem of an affected system. This vulnerability is due to insufficient access control for sensitive information that is written to an affected system. An attacker could exploit this vulnerability by accessing sensitive information that they are not authorized to access on an affected system. A successful exploit could allow the attacker to gain access to devices and other network management systems that they should not have access to.Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-1232"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-18T16:15:08Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the web-based management interface of Cisco\u0026nbsp;SD-WAN vManage Software could allow an authenticated, remote attacker to read arbitrary files on the underlying filesystem of an affected system.\nThis vulnerability is due to insufficient access control for sensitive information that is written to an affected system. An attacker could exploit this vulnerability by accessing sensitive information that they are not authorized to access on an affected system. A successful exploit could allow the attacker to gain access to devices and other network management systems that they should not have access to.Cisco\u0026nbsp;has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.",
  "id": "GHSA-g8hr-m8mg-wmfp",
  "modified": "2024-11-18T18:30:57Z",
  "published": "2024-11-18T18:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1232"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ipphone-rce-dos-U2PsSkz3"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwanvman-infodis1-YuQScHB"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snort-ethernet-dos-HGXgJH8n"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-webex-distupd-N87eB6Z3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G8RX-2JMM-3847

Vulnerability from github – Published: 2026-04-16 15:31 – Updated: 2026-08-21 18:34
VLAI
Details

Insufficiently Protected Credentials in Sparx Systems Pty Ltd. Sparx Enterprise Architect. Client does not verify the receiver of OAuth2 credentials during OpenID authentication

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-15621"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-16T13:16:43Z",
    "severity": "MODERATE"
  },
  "details": "Insufficiently Protected Credentials in Sparx Systems Pty Ltd. Sparx Enterprise Architect. Client does not verify the receiver of OAuth2 credentials during OpenID authentication",
  "id": "GHSA-g8rx-2jmm-3847",
  "modified": "2026-08-21T18:34:46Z",
  "published": "2026-04-16T15:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15621"
    },
    {
      "type": "WEB",
      "url": "https://sparxsystems.com/products/ea/17.1/history.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:P/VC:H/VI:L/VA:N/SC:H/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:P/AU:Y/R:X/V:C/RE:M/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-G99J-VFCP-3VMF

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

OpenStack Identity (Keystone) Folsom, Grizzly 2013.1.3 and earlier, and Havana before havana-3 does not properly revoke user tokens when a tenant is disabled, which allows remote authenticated users to retain access via the token.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2013-4222"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2013-09-30T22:55:00Z",
    "severity": "MODERATE"
  },
  "details": "OpenStack Identity (Keystone) Folsom, Grizzly 2013.1.3 and earlier, and Havana before havana-3 does not properly revoke user tokens when a tenant is disabled, which allows remote authenticated users to retain access via the token.",
  "id": "GHSA-g99j-vfcp-3vmf",
  "modified": "2022-05-13T01:26:09Z",
  "published": "2022-05-13T01:26:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-4222"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2013:1524"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2013-4222"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/ossn/+bug/1179955"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=995598"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2013-September/116489.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2013-1524.html"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-2002-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-G9GR-WPGX-7W72

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

In TestLink 1.9.20, a crafted login.php viewer parameter exposes cleartext credentials.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-12273"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-27T13:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In TestLink 1.9.20, a crafted login.php viewer parameter exposes cleartext credentials.",
  "id": "GHSA-g9gr-wpgx-7w72",
  "modified": "2022-05-24T17:16:36Z",
  "published": "2022-05-24T17:16:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12273"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TestLinkOpenSourceTRMS/testlink-code/commit/72271ef057e6e4a95c6128973902ea646f7b5462"
    },
    {
      "type": "WEB",
      "url": "http://mantis.testlink.org/view.php?id=8895"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-G9JJ-CGMH-9F38

Vulnerability from github – Published: 2026-08-28 22:41 – Updated: 2026-08-28 22:41
VLAI
Summary
MariaDB has cleartext password disclosure to a MITM on the initial-handshake
Details

Summary

When a Java application connects with sslMode=verify-full (or verify-ca) and a password but does not pin a server certificate, Connector/J deliberately accepts an untrusted/self-signed certificate at the TLS layer (the "MITM-proof without a CA" feature) and proves the server's identity afterwards by binding the certificate fingerprint into the authentication exchange. That fingerprint enforcement is applied to the OK-packet and auth-switch paths but not to the initial-handshake path. An active man-in-the-middle that presents a self-signed certificate, claims to be MariaDB, and names the initial authentication plugin mysql_clear_password receives the victim's database password in cleartext, before any fingerprint/identity check runs. The connection is torn down a moment later, but the credential is already gone.

Details

For sslMode=verify-full/verify-ca with a password and no serverSslCert/trustStore, the connector falls back to an ephemeral trust manager (default fallbackToSystemTrustStore=true) that accepts any non-expired certificate at the TLS layer and records its fingerprint. Identity is then meant to be enforced via that fingerprint.

The enforcement guard is present on two of the three paths, the OK-packet fingerprint check and the auth-switch handler (where the clear-password plugin is only allowed when the fingerprint is already verified). It is absent on the initial-handshake send: HandshakeResponse.encode() builds the mysql_clear_password response after checking only that SSL is enabled, never consulting the recorded fingerprint, sslMode, or whether the plugin is MITM-proof. By that point the connector already knows the certificate was self-signed. The clear-password plugin does not declare itself MITM-proof (it inherits the safe default), which confirms it is meant to be refused on an unverified certificate; the initial-handshake path simply never consults that flag. The initial path also bypasses restrictedAuth.

Impact

An active man-in-the-middle steals the full cleartext database password of any Java application using Connector/J with sslMode=verify-full/verify-ca plus a password and no pinned certificate, the configuration documented as the easy, secure default. With the captured credentials the attacker can take over the database account and read or modify all data that account is authorized for. The victim takes no unusual action; the developer explicitly enabled TLS verification expecting exactly this protection.

Patches

Fixed in 2.7.14, 3.3.5, 3.4.3, and 3.5.9. Upgrade to the patched release on your branch (3.5.x → 3.5.9, 3.4.x → 3.4.3, 3.0/3.1/3.2/3.3.x → 3.3.5, 2.x → 2.7.14). The fix applies the same certFingerprint != null && !isMitMProof() guard to the initial-handshake path before writing the auth response, refusing to send a mysql_clear_password (or any non-MITM-proof) response on an as-yet-unverified certificate, matching the auth-switch path.

Workarounds

If you cannot upgrade immediately, pin the server certificate (serverSslCert= the real CA / server cert). With a pinned certificate the self-signed certificate of a man-in-the-middle is rejected at the TLS layer before any password is transmitted.

Credit

Reported by haaahaaahiihiiii

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.mariadb.jdbc:mariadb-java-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.7.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.mariadb.jdbc:mariadb-java-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.3.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.mariadb.jdbc:mariadb-java-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.4.0"
            },
            {
              "fixed": "3.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.mariadb.jdbc:mariadb-java-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.5.0"
            },
            {
              "fixed": "3.5.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55856"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T22:41:56Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nWhen a Java application connects with sslMode=verify-full (or verify-ca) and a password but does not pin a server certificate, Connector/J deliberately accepts an untrusted/self-signed certificate at the TLS layer (the \"MITM-proof without a CA\" feature) and proves the server\u0027s identity afterwards by binding the certificate fingerprint into the authentication exchange. That fingerprint enforcement is applied to the OK-packet and auth-switch paths but not to the initial-handshake path. An active man-in-the-middle that presents a self-signed certificate, claims to be MariaDB, and names the initial authentication plugin mysql_clear_password receives the victim\u0027s database password in cleartext, before any fingerprint/identity check runs. The connection is torn down a moment later, but the credential is already gone.\n\n### Details\n\nFor sslMode=verify-full/verify-ca with a password and no serverSslCert/trustStore, the connector falls back to an ephemeral trust manager (default fallbackToSystemTrustStore=true) that accepts any non-expired certificate at the TLS layer and records its fingerprint. Identity is then meant to be enforced via that fingerprint.\n\nThe enforcement guard is present on two of the three paths, the OK-packet fingerprint check and the auth-switch handler (where the clear-password plugin is only allowed when the fingerprint is already verified). It is absent on the initial-handshake send: HandshakeResponse.encode() builds the mysql_clear_password response after checking only that SSL is enabled, never consulting the recorded fingerprint, sslMode, or whether the plugin is MITM-proof. By that point the connector already knows the certificate was self-signed. The clear-password plugin does not declare itself MITM-proof (it inherits the safe default), which confirms it is meant to be refused on an unverified certificate; the initial-handshake path simply never consults that flag. The initial path also bypasses restrictedAuth.\n\n### Impact\n\nAn active man-in-the-middle steals the full cleartext database password of any Java application using Connector/J with sslMode=verify-full/verify-ca plus a password and no pinned certificate, the configuration documented as the easy, secure default. With the captured credentials the attacker can take over the database account and read or modify all data that account is authorized for. The victim takes no unusual action; the developer explicitly enabled TLS verification expecting exactly this protection.\n\n### Patches\n\nFixed in 2.7.14, 3.3.5, 3.4.3, and 3.5.9. Upgrade to the patched release on your branch (3.5.x \u2192 3.5.9, 3.4.x \u2192 3.4.3, 3.0/3.1/3.2/3.3.x \u2192 3.3.5, 2.x \u2192 2.7.14). The fix applies the same certFingerprint != null \u0026\u0026 !isMitMProof() guard to the initial-handshake path before writing the auth response, refusing to send a mysql_clear_password (or any non-MITM-proof) response on an as-yet-unverified certificate, matching the auth-switch path.\n\n### Workarounds\n\nIf you cannot upgrade immediately, pin the server certificate (serverSslCert= the real CA / server cert). With a pinned certificate the self-signed certificate of a man-in-the-middle is rejected at the TLS layer before any password is transmitted.\n\nCredit\n\nReported by haaahaaahiihiiii",
  "id": "GHSA-g9jj-cgmh-9f38",
  "modified": "2026-08-28T22:41:56Z",
  "published": "2026-08-28T22:41:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j/security/advisories/GHSA-g9jj-cgmh-9f38"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j/commit/149ec6a626376214966c01f42d48be1b80d06056"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j/commit/d90b9872322c76b05a48219be66bff1d33102f8a"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/3777370"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j/releases/tag/3.4.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mariadb-corporation/mariadb-connector-j/releases/tag/3.5.9"
    },
    {
      "type": "WEB",
      "url": "https://jira.mariadb.org/browse/CONJ-1325"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MariaDB has cleartext password disclosure to a MITM on the initial-handshake"
}

GHSA-G9QV-25H9-WCVW

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

The Web server in 1C:Enterprise 8 before 8.3.17.1851 sends base64 encoded credentials in the creds URL parameter.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-3131"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-13T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "The Web server in 1C:Enterprise 8 before 8.3.17.1851 sends base64 encoded credentials in the creds URL parameter.",
  "id": "GHSA-g9qv-25h9-wcvw",
  "modified": "2022-07-13T00:01:24Z",
  "published": "2022-05-24T17:39:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3131"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jet-pentest/CVE-2021-3131"
    }
  ],
  "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-GCW9-J843-4VFX

Vulnerability from github – Published: 2025-11-14 00:30 – Updated: 2025-11-14 00:30
VLAI
Details

IBM AIX 7.2, and 7.3 and IBM VIOS 3.1, and 4.1 stores NIM private keys used in NIM environments in an insecure way which is susceptible to unauthorized access by an attacker using man in the middle techniques.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-36096"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-13T22:15:50Z",
    "severity": "CRITICAL"
  },
  "details": "IBM AIX 7.2, and 7.3 and IBM VIOS 3.1, and 4.1 stores NIM private keys used in NIM environments in an insecure way which is susceptible to unauthorized access by an attacker using man in the middle techniques.",
  "id": "GHSA-gcw9-j843-4vfx",
  "modified": "2025-11-14T00:30:27Z",
  "published": "2025-11-14T00:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36096"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7251173"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GF9H-XGQF-WJRR

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

The Voatz application 2020-01-01 for Android allows only 100 million different PINs, which makes it easier for attackers (after using root access to make a copy of the local database) to discover login credentials and voting history via an offline brute-force approach.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-8988"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-02-13T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Voatz application 2020-01-01 for Android allows only 100 million different PINs, which makes it easier for attackers (after using root access to make a copy of the local database) to discover login credentials and voting history via an offline brute-force approach.",
  "id": "GHSA-gf9h-xgqf-wjrr",
  "modified": "2022-05-24T17:09:01Z",
  "published": "2022-05-24T17:09:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8988"
    },
    {
      "type": "WEB",
      "url": "https://blog.voatz.com/?p=1209"
    },
    {
      "type": "WEB",
      "url": "https://internetpolicy.mit.edu/wp-content/uploads/2020/02/SecurityAnalysisOfVoatz_Public.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GFCR-CX84-GGPW

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

An issue was discovered in D-Link mydlink+ 3.8.5 build 259 for DCS-933L 1.05.04 and DCS-934L 1.05.04 devices. The mydlink+ app sends the username and password for connected D-Link cameras (such as DCS-933L and DCS-934L) unencrypted from the app to the camera, allowing attackers to obtain these credentials and gain control of the camera including the ability to view the camera's stream and make changes without the user's knowledge.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-7698"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-03-05T19:29:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in D-Link mydlink+ 3.8.5 build 259 for DCS-933L 1.05.04 and DCS-934L 1.05.04 devices. The mydlink+ app sends the username and password for connected D-Link cameras (such as DCS-933L and DCS-934L) unencrypted from the app to the camera, allowing attackers to obtain these credentials and gain control of the camera including the ability to view the camera\u0027s stream and make changes without the user\u0027s knowledge.",
  "id": "GHSA-gfcr-cx84-ggpw",
  "modified": "2022-05-13T01:53:24Z",
  "published": "2022-05-13T01:53:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7698"
    },
    {
      "type": "WEB",
      "url": "https://blog.nickleghorn.com/2019/06/16/d-link-security-cameras-using-mydlink-app-leak-passwords"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

Use an appropriate security mechanism to protect the credentials.

Mitigation
Architecture and Design

Make appropriate use of cryptography to protect the credentials.

Mitigation
Implementation

Use industry standards to protect the credentials (e.g. LDAP, keystore, etc.).

CAPEC-102: Session Sidejacking

Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.

CAPEC-474: Signature Spoofing by Key Theft

An attacker obtains an authoritative or reputable signer's private signature key by theft and then uses this key to forge signatures from the original signer to mislead a victim into performing actions that benefit the attacker.

CAPEC-50: Password Recovery Exploitation

An attacker may take advantage of the application feature to help users recover their forgotten passwords in order to gain access into the system with the same privileges as the original user. Generally password recovery schemes tend to be weak and insecure.

CAPEC-509: Kerberoasting

Through the exploitation of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs), the adversary obtains and subsequently cracks the hashed credentials of a service account target to exploit its privileges. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. As an authenticated user, the adversary may request Active Directory and obtain a service ticket with portions encrypted via RC4 with the private key of the authenticated account. By extracting the local ticket and saving it disk, the adversary can brute force the hashed value to reveal the target account credentials.

CAPEC-551: Modify Existing Service

When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.

CAPEC-555: Remote Services with Stolen Credentials

This pattern of attack involves an adversary that uses stolen credentials to leverage remote services such as RDP, telnet, SSH, and VNC to log into a system. Once access is gained, any number of malicious activities could be performed.

CAPEC-560: Use of Known Domain Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate credentials (e.g. userID/password) to achieve authentication and to perform authorized actions under the guise of an authenticated user or service.

CAPEC-561: Windows Admin Shares with Stolen Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate Windows administrator credentials (e.g. userID/password) to access Windows Admin Shares on a local machine or within a Windows domain.

CAPEC-600: Credential Stuffing

An adversary tries known username/password combinations against different systems, applications, or services to gain additional authenticated access. Credential Stuffing attacks rely upon the fact that many users leverage the same username/password combination for multiple systems, applications, and services.

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

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

CAPEC-645: Use of Captured Tickets (Pass The Ticket)

An adversary uses stolen Kerberos tickets to access systems/resources that leverage the Kerberos authentication protocol. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. An adversary can obtain any one of these tickets (e.g. Service Ticket, Ticket Granting Ticket, Silver Ticket, or Golden Ticket) to authenticate to a system/resource without needing the account's credentials. Depending on the ticket obtained, the adversary may be able to access a particular resource or generate TGTs for any account within an Active Directory Domain.

CAPEC-652: Use of Known Kerberos Credentials

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

CAPEC-653: Use of Known Operating System Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate operating system credentials (e.g. userID/password) to achieve authentication and to perform authorized actions on the system, under the guise of an authenticated user or service. This applies to any Operating System.