Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

API response cwe.mitre.org

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

6928 vulnerabilities reference this CWE, most recent first.

GHSA-P373-JQFM-J6WR

Vulnerability from github – Published: 2022-10-20 12:00 – Updated: 2022-10-22 01:12
VLAI
Summary
Shinken Solutions Shinken Monitoring vulnerable to Incorrect Access Control
Details

Shinken Solutions Shinken Monitoring Version 2.4.3 affected is vulnerable to Incorrect Access Control. The SafeUnpickler class found in shinken/safepickle.py implements a weak authentication scheme when unserializing objects passed from monitoring nodes to the Shinken monitoring server.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Shinken"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-37298"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-10-20T18:39:15Z",
    "nvd_published_at": "2022-10-20T11:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Shinken Solutions Shinken Monitoring Version 2.4.3 affected is vulnerable to Incorrect Access Control. The `SafeUnpickler` class found in `shinken/safepickle.py` implements a weak authentication scheme when unserializing objects passed from monitoring nodes to the Shinken monitoring server.",
  "id": "GHSA-p373-jqfm-j6wr",
  "modified": "2022-10-22T01:12:42Z",
  "published": "2022-10-20T12:00:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37298"
    },
    {
      "type": "WEB",
      "url": "https://github.com/naparuba/shinken/commit/2dae40fd1e713aec9e1966a0ab7a580b9180cff2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dbyio/cve-2022-37298"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/naparuba/shinken"
    }
  ],
  "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"
    }
  ],
  "summary": "Shinken Solutions Shinken Monitoring vulnerable to Incorrect Access Control"
}

GHSA-P378-JP5R-GPGW

Vulnerability from github – Published: 2026-08-28 20:32 – Updated: 2026-08-28 20:32
VLAI
Summary
arc has unauthenticated cluster node admission when `cluster.shared_secret` is unset
Details

Summary

Arc Enterprise clustering accepts cluster join requests without authentication when cluster.enabled=true but cluster.shared_secret is not configured. The coordinator validates HMAC authentication only if a shared secret is non-empty; otherwise, a network attacker who can reach the coordinator port can send a join request with attacker-controlled node addresses and role. Accepted nodes are marked healthy, registered locally or added as Raft voters, and can be selected by the cluster router for forwarded authenticated requests.

Details

Cluster defaults include an empty shared secret and TLS disabled:

  • internal/config/config.go:943-950 defaults cluster.enabled=false, cluster.cluster_name="arc-cluster", and cluster.coordinator_addr=":9100".
  • internal/config/config.go:1001-1005 defaults cluster.shared_secret="" and cluster.tls_enabled=false.

Startup requires a shared secret only for file replication, not for all clustering/join/routing use:

  • cmd/arc/main.go:1258-1265 hard-fails without cluster.shared_secret only when cluster.replication_enabled is true.

The join request contains attacker-supplied node identity, role, and addresses:

  • internal/cluster/protocol/messages.go:127-142 defines JoinRequest fields including node_id, role, raft_addr, api_addr, coord_addr, plus optional auth fields.

The coordinator validates HMAC only when the configured shared secret is non-empty:

  • internal/cluster/coordinator.go:1066-1081 wraps all HMAC checks in if c.cfg.SharedSecret != "" { ... }.
  • If the secret is empty, the join request proceeds after only the cluster-name check.

An accepted join creates a healthy node from attacker-controlled fields and adds it to cluster trust state:

  • internal/cluster/coordinator.go:1101-1107 creates a node from request fields, sets attacker-provided coordinator/API addresses, and marks it healthy.
  • internal/cluster/coordinator.go:1108-1129 adds the attacker-provided raft_addr as a Raft voter and stores node info when Raft is configured.
  • internal/cluster/coordinator.go:1133-1138 registers the node locally when Raft is not configured.

The router uses healthy nodes from this registry and forwards authenticated requests to their advertised API addresses:

  • internal/cluster/registry.go:263-270 returns healthy writers/readers.
  • internal/cluster/router.go:154-177 routes writes to healthy writer nodes.
  • internal/cluster/router.go:203-227 routes queries to healthy readers, or writers if no readers exist.
  • internal/cluster/router.go:327-357 builds the forwarding target from node.APIAddress and copies all original request headers to the peer, including Authorization and x-api-key.
  • cmd/arc/main.go:1887-1897 wires the cluster router into MessagePack, line protocol, TLE, and query handlers when the cluster coordinator exists.

A related lower-severity issue is that heartbeat messages are also unauthenticated:

  • internal/cluster/protocol/messages.go:175-180 defines Heartbeat without HMAC fields.
  • internal/cluster/coordinator.go:1220-1232 records heartbeats and updates node state based only on supplied node_id and state.

Proof of concept

Safe local lab reproduction only; do not target external infrastructure.

Prerequisites:

  • Enterprise clustering enabled in a lab deployment.
  • cluster.shared_secret intentionally left empty.
  • Network access to the coordinator TCP port, default 9100.
  • The attacker knows or guesses the cluster name; default is arc-cluster.

Steps:

  1. Start an Arc cluster node with:
[cluster]
enabled = true
cluster_name = "arc-cluster"
coordinator_addr = ":9100"
shared_secret = ""
tls_enabled = false

  1. Start an attacker-controlled HTTP listener that records request method, path, and headers, for example on 127.0.0.1:18080.

  2. Send a framed cluster join request to the victim coordinator. The protocol uses a 4-byte big-endian length prefix, followed by a 1-byte message type (MsgJoinRequest == 1), followed by JSON. The payload should include attacker-controlled node fields and omit auth_nonce, auth_timestamp, and auth_hmac:

{
  "node_id": "evil-reader-1",
  "node_name": "evil-reader",
  "role": "reader",
  "cluster_name": "arc-cluster",
  "raft_addr": "127.0.0.1:19020",
  "api_addr": "127.0.0.1:18080",
  "coord_addr": "127.0.0.1:19010",
  "version": "lab",
  "core_count": 1
}

Expected vulnerable result: the coordinator accepts the join instead of rejecting it for missing authentication.

  1. Trigger a forwarded operation from a node that cannot handle the operation locally. Examples depend on cluster roles:

  2. Join as reader and trigger a query through a node that routes queries to readers.

  3. Join as writer and trigger ingestion through a non-writer node that routes writes to writers.

Expected vulnerable result: the attacker-controlled HTTP listener receives forwarded requests. Because forwardRequest copies all original headers, the listener can observe authentication headers such as bearer tokens or API keys along with request paths and bodies.

  1. In a Raft-enabled lab, observe that the attacker-provided raft_addr is submitted to AddVoter, demonstrating unauthorized membership mutation.

Impact

In affected cluster deployments, an unauthenticated network attacker can become a trusted cluster node. Practical impacts include:

  • Interception of forwarded authenticated HTTP requests, including Authorization and x-api-key headers.
  • Exposure of query bodies, ingestion data, database/measurement names, and operational metadata.
  • Unauthorized cluster membership mutation, including attempted Raft voter addition when Raft is configured.
  • Potential data integrity impact if the rogue node returns forged query/write responses or accepts/diverts writes.
  • Potential availability impact by blackholing or delaying forwarded operations.

This is not reachable in the default standalone configuration because cluster.enabled=false, but it is a critical trust-boundary issue for Enterprise cluster deployments where clustering is enabled without a shared secret. The code already treats cluster.shared_secret as mandatory for replication, which suggests unauthenticated cluster membership should also fail closed.

Suggested fix

  • Fail startup when cluster.enabled=true and cluster.shared_secret is empty, not only when cluster.replication_enabled=true.
  • Reject all trust-mutating coordinator messages when no cluster authentication is configured, including join, heartbeat/state update, forward apply, and file replication messages.
  • Require HMAC or mutual TLS before processing any join/heartbeat message.
  • Bind authentication to node identity and advertised addresses to reduce replay and address-substitution risks.
  • Do not forward end-user Authorization/x-api-key headers to a peer unless the peer identity has been authenticated and authorized.
  • Add tests proving unauthenticated join and heartbeat requests fail when clustering is enabled.

References / evidence

  • internal/config/config.go:943-950
  • internal/config/config.go:1001-1005
  • cmd/arc/main.go:1258-1265
  • internal/cluster/protocol/messages.go:127-142
  • internal/cluster/coordinator.go:1066-1081
  • internal/cluster/coordinator.go:1101-1138
  • internal/cluster/router.go:154-177
  • internal/cluster/router.go:203-227
  • internal/cluster/router.go:327-357
  • cmd/arc/main.go:1887-1897
Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/basekick-labs/arc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260615160325-38402ad2ebdd"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55678"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-287",
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T20:32:57Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nArc Enterprise clustering accepts cluster join requests without authentication when `cluster.enabled=true` but `cluster.shared_secret` is not configured. The coordinator validates HMAC authentication only if a shared secret is non-empty; otherwise, a network attacker who can reach the coordinator port can send a join request with attacker-controlled node addresses and role. Accepted nodes are marked healthy, registered locally or added as Raft voters, and can be selected by the \ncluster router for forwarded authenticated requests.\n\n## Details\n\nCluster defaults include an empty shared secret and TLS disabled:\n\n- `internal/config/config.go:943-950` defaults `cluster.enabled=false`, `cluster.cluster_name=\"arc-cluster\"`, and `cluster.coordinator_addr=\":9100\"`.\n- `internal/config/config.go:1001-1005` defaults `cluster.shared_secret=\"\"` and `cluster.tls_enabled=false`.\n\nStartup requires a shared secret only for file replication, not for all clustering/join/routing use:\n\n- `cmd/arc/main.go:1258-1265` hard-fails without `cluster.shared_secret` only when `cluster.replication_enabled` is true.\n\nThe join request contains attacker-supplied node identity, role, and addresses:\n\n- `internal/cluster/protocol/messages.go:127-142` defines `JoinRequest` fields including `node_id`, `role`, `raft_addr`, `api_addr`, `coord_addr`, plus optional auth fields.\n\nThe coordinator validates HMAC only when the configured shared secret is non-empty:\n\n- `internal/cluster/coordinator.go:1066-1081` wraps all HMAC checks in `if c.cfg.SharedSecret != \"\" { ... }`.\n- If the secret is empty, the join request proceeds after only the cluster-name check.\n\nAn accepted join creates a healthy node from attacker-controlled fields and adds it to cluster trust state:\n\n- `internal/cluster/coordinator.go:1101-1107` creates a node from request fields, sets attacker-provided coordinator/API addresses, and marks it healthy.\n- `internal/cluster/coordinator.go:1108-1129` adds the attacker-provided `raft_addr` as a Raft voter and stores node info when Raft is configured.\n- `internal/cluster/coordinator.go:1133-1138` registers the node locally when Raft is not configured.\n\nThe router uses healthy nodes from this registry and forwards authenticated requests to their advertised API addresses:\n\n- `internal/cluster/registry.go:263-270` returns healthy writers/readers.\n- `internal/cluster/router.go:154-177` routes writes to healthy writer nodes.\n- `internal/cluster/router.go:203-227` routes queries to healthy readers, or writers if no readers exist.\n- `internal/cluster/router.go:327-357` builds the forwarding target from `node.APIAddress` and copies all original request headers to the peer, including `Authorization` and `x-api-key`.\n- `cmd/arc/main.go:1887-1897` wires the cluster router into MessagePack, line protocol, TLE, and query handlers when the cluster coordinator exists.\n\nA related lower-severity issue is that heartbeat messages are also unauthenticated:\n\n- `internal/cluster/protocol/messages.go:175-180` defines `Heartbeat` without HMAC fields.\n- `internal/cluster/coordinator.go:1220-1232` records heartbeats and updates node state based only on supplied `node_id` and `state`.\n\n## Proof of concept\n\nSafe local lab reproduction only; do not target external infrastructure.\n\nPrerequisites:\n\n- Enterprise clustering enabled in a lab deployment.\n- `cluster.shared_secret` intentionally left empty.\n- Network access to the coordinator TCP port, default `9100`.\n- The attacker knows or guesses the cluster name; default is `arc-cluster`.\n\nSteps:\n\n1. Start an Arc cluster node with:\n\n```toml\n[cluster]\nenabled = true\ncluster_name = \"arc-cluster\"\ncoordinator_addr = \":9100\"\nshared_secret = \"\"\ntls_enabled = false\n```\n\n2. Start an attacker-controlled HTTP listener that records request method, path, and headers, for example on `127.0.0.1:18080`.\n\n3. Send a framed cluster join request to the victim coordinator. The protocol uses a 4-byte big-endian length prefix, followed by a 1-byte message type (`MsgJoinRequest == 1`), followed by JSON. The payload should include attacker-controlled node fields and omit `auth_nonce`, `auth_timestamp`, and `auth_hmac`:\n\n```json\n{\n  \"node_id\": \"evil-reader-1\",\n  \"node_name\": \"evil-reader\",\n  \"role\": \"reader\",\n  \"cluster_name\": \"arc-cluster\",\n  \"raft_addr\": \"127.0.0.1:19020\",\n  \"api_addr\": \"127.0.0.1:18080\",\n  \"coord_addr\": \"127.0.0.1:19010\",\n  \"version\": \"lab\",\n  \"core_count\": 1\n}\n```\n\nExpected vulnerable result: the coordinator accepts the join instead of rejecting it for missing authentication.\n\n4. Trigger a forwarded operation from a node that cannot handle the operation locally. Examples depend on cluster roles:\n\n- Join as `reader` and trigger a query through a node that routes queries to readers.\n- Join as `writer` and trigger ingestion through a non-writer node that routes writes to writers.\n\nExpected vulnerable result: the attacker-controlled HTTP listener receives forwarded requests. Because `forwardRequest` copies all original headers, the listener can observe authentication headers such as bearer tokens or API keys along with request paths and bodies.\n\n5. In a Raft-enabled lab, observe that the attacker-provided `raft_addr` is submitted to `AddVoter`, demonstrating unauthorized membership mutation.\n\n## Impact\n\nIn affected cluster deployments, an unauthenticated network attacker can become a trusted cluster node. Practical impacts include:\n\n- Interception of forwarded authenticated HTTP requests, including `Authorization` and `x-api-key` headers.\n- Exposure of query bodies, ingestion data, database/measurement names, and operational metadata.\n- Unauthorized cluster membership mutation, including attempted Raft voter addition when Raft is configured.\n- Potential data integrity impact if the rogue node returns forged query/write responses or accepts/diverts writes.\n- Potential availability impact by blackholing or delaying forwarded operations.\n\nThis is not reachable in the default standalone configuration because `cluster.enabled=false`, but it is a critical trust-boundary issue for Enterprise cluster deployments where clustering is enabled without a shared secret. The code already treats `cluster.shared_secret` as mandatory for replication, which suggests unauthenticated cluster membership should also fail closed.\n\n\n## Suggested fix\n\n- Fail startup when `cluster.enabled=true` and `cluster.shared_secret` is empty, not only when `cluster.replication_enabled=true`.\n- Reject all trust-mutating coordinator messages when no cluster authentication is configured, including join, heartbeat/state update, forward apply, and file replication messages.\n- Require HMAC or mutual TLS before processing any join/heartbeat message.\n- Bind authentication to node identity and advertised addresses to reduce replay and address-substitution risks.\n- Do not forward end-user `Authorization`/`x-api-key` headers to a peer unless the peer identity has been authenticated and authorized.\n- Add tests proving unauthenticated join and heartbeat requests fail when clustering is enabled.\n\n## References / evidence\n\n- `internal/config/config.go:943-950`\n- `internal/config/config.go:1001-1005`\n- `cmd/arc/main.go:1258-1265`\n- `internal/cluster/protocol/messages.go:127-142`\n- `internal/cluster/coordinator.go:1066-1081`\n- `internal/cluster/coordinator.go:1101-1138`\n- `internal/cluster/router.go:154-177`\n- `internal/cluster/router.go:203-227`\n- `internal/cluster/router.go:327-357`\n- `cmd/arc/main.go:1887-1897`",
  "id": "GHSA-p378-jp5r-gpgw",
  "modified": "2026-08-28T20:32:57Z",
  "published": "2026-08-28T20:32:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Basekick-Labs/arc/security/advisories/GHSA-p378-jp5r-gpgw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Basekick-Labs/arc/pull/505"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Basekick-Labs/arc/commit/38402ad2ebddd32c15bf4a0fc9c22c920e5685df"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Basekick-Labs/arc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Basekick-Labs/arc/releases/tag/v26.06.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "arc has unauthenticated cluster node admission when `cluster.shared_secret` is unset"
}

GHSA-P38J-G4G4-FM3G

Vulnerability from github – Published: 2026-10-10 09:30 – Updated: 2026-10-10 09:30
VLAI
Details

The WPO365 | SEAMLESS WORDPRESS + MICROSOFT INTEGRATION (WPO365 | LOGIN) plugin for WordPress is vulnerable to Authentication Bypass via OIDC Nonce Replay in all versions up to, and including, 44.1 This is due to Id_Token_Service_Deprecated::process_openidconnect_token() using the incompatible WordPress core wp_verify_nonce() function to validate a nonce produced by Nonce_Service::create_nonce() — a 64-character hex value that wp_verify_nonce() can never successfully verify — causing the nonce check to silently fail without terminating authentication, so execution continues into authenticate_oidc_user() with the attacker-supplied id_token. This makes it possible for unauthenticated attackers who have obtained a previously-issued, valid id_token for a target account to replay that token and authenticate as any WordPress user, including administrators, resulting in full site takeover. This vulnerability is only exploitable when the use_id_token_parser_v2 plugin option is enabled, as this is the configuration that routes token processing through the deprecated parser containing the broken nonce check.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-104759"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-10T08:17:04Z",
    "severity": "HIGH"
  },
  "details": "The WPO365 | SEAMLESS WORDPRESS + MICROSOFT INTEGRATION (WPO365 | LOGIN) plugin for WordPress is vulnerable to Authentication Bypass via OIDC Nonce Replay in all versions up to, and including, 44.1 This is due to `Id_Token_Service_Deprecated::process_openidconnect_token()` using the incompatible WordPress core `wp_verify_nonce()` function to validate a nonce produced by `Nonce_Service::create_nonce()` \u2014 a 64-character hex value that `wp_verify_nonce()` can never successfully verify \u2014 causing the nonce check to silently fail without terminating authentication, so execution continues into `authenticate_oidc_user()` with the attacker-supplied `id_token`. This makes it possible for unauthenticated attackers who have obtained a previously-issued, valid `id_token` for a target account to replay that token and authenticate as any WordPress user, including administrators, resulting in full site takeover. This vulnerability is only exploitable when the `use_id_token_parser_v2` plugin option is enabled, as this is the configuration that routes token processing through the deprecated parser containing the broken nonce check.",
  "id": "GHSA-p38j-g4g4-fm3g",
  "modified": "2026-10-10T09:30:28Z",
  "published": "2026-10-10T09:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104759"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wpo365-login/tags/44.1/Services/Id_Token_Service.php#L107"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wpo365-login/tags/44.1/Services/Id_Token_Service_Deprecated.php#L110"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wpo365-login/tags/44.1/Services/Nonce_Service.php#L72"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wpo365-login/tags/44.1/Services/Router_Service.php#L275"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3727410/wpo365-login"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?reponame=\u0026new=3727410%40wpo365-login%2Ftags%2F45.0\u0026old=3682496%40wpo365-login%2Ftags%2F44.1"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/aad7ddac-ed12-4263-8e68-64b1fca8dfad?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P3G2-F65Q-G6RX

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

A vulnerability in the web-based GUI of Cisco Mobility Express 1800 Series Access Points could allow an unauthenticated, remote attacker to bypass authentication. The attacker could be granted full administrator privileges. The vulnerability is due to improper implementation of authentication for accessing certain web pages using the GUI interface. An attacker could exploit this vulnerability by sending a crafted HTTP request to the web interface of the affected system. A successful exploit could allow the attacker to bypass authentication and perform unauthorized configuration changes or issue control commands to the affected device. This vulnerability affects Cisco Mobility Express 1800 Series Access Points running a software version prior to 8.2.110.0. Cisco Bug IDs: CSCuy68219.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-3831"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-03-15T20:59:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability in the web-based GUI of Cisco Mobility Express 1800 Series Access Points could allow an unauthenticated, remote attacker to bypass authentication. The attacker could be granted full administrator privileges. The vulnerability is due to improper implementation of authentication for accessing certain web pages using the GUI interface. An attacker could exploit this vulnerability by sending a crafted HTTP request to the web interface of the affected system. A successful exploit could allow the attacker to bypass authentication and perform unauthorized configuration changes or issue control commands to the affected device. This vulnerability affects Cisco Mobility Express 1800 Series Access Points running a software version prior to 8.2.110.0. Cisco Bug IDs: CSCuy68219.",
  "id": "GHSA-p3g2-f65q-g6rx",
  "modified": "2022-05-13T01:36:42Z",
  "published": "2022-05-13T01:36:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-3831"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170315-ap1800"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/96909"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P3G3-MX33-CM6Q

Vulnerability from github – Published: 2022-04-29 01:28 – Updated: 2022-04-29 01:28
VLAI
Details

The server in IBM Tivoli Storage Manager (TSM) 5.1.x, 5.2.x before 5.2.1.2, and 6.x before 6.1 does not require credentials to observe the server console in some circumstances, which allows remote authenticated administrators to monitor server operations by establishing a console mode session, related to "session exposure."

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2003-1570"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-03-31T18:24:00Z",
    "severity": "LOW"
  },
  "details": "The server in IBM Tivoli Storage Manager (TSM) 5.1.x, 5.2.x before 5.2.1.2, and 6.x before 6.1 does not require credentials to observe the server console in some circumstances, which allows remote authenticated administrators to monitor server operations by establishing a console mode session, related to \"session exposure.\"",
  "id": "GHSA-p3g3-mx33-cm6q",
  "modified": "2022-04-29T01:28:18Z",
  "published": "2022-04-29T01:28:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2003-1570"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/49536"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/34498"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1021947"
    },
    {
      "type": "WEB",
      "url": "http://www-01.ibm.com/support/docview.wss?uid=swg21375360"
    },
    {
      "type": "WEB",
      "url": "http://www-1.ibm.com/support/docview.wss?uid=swg1IC37554"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/34285"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2009/0881"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-P3G6-PG7F-CH24

Vulnerability from github – Published: 2022-08-17 00:00 – Updated: 2022-08-19 00:00
VLAI
Details

Sequi PortBloque S has a improper authentication issues which may allow an attacker to bypass the authentication process and gain user-level access to the device.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-2662"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-16T21:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Sequi PortBloque S has a improper authentication issues which may allow an attacker to bypass the authentication process and gain user-level access to the device.",
  "id": "GHSA-p3g6-pg7f-ch24",
  "modified": "2022-08-19T00:00:21Z",
  "published": "2022-08-17T00:00:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2662"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-228-07"
    }
  ],
  "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-P3GX-G437-GW6C

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

The 'crowd-application' plugin module (notably used by the Google Apps plugin) in Atlassian Crowd from version 1.5.0 before version 3.1.2 allowed an attacker to impersonate a Crowd user in REST requests by being able to authenticate to a directory bound to an application using the feature. Given the following situation: the Crowd application is bound to directory 1 and has a user called admin and the Google Apps application is bound to directory 2, which also has a user called admin, it was possible to authenticate REST requests using the credentials of the user coming from directory 2 and impersonate the user from directory 1.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-16858"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-01-31T14:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The \u0027crowd-application\u0027 plugin module (notably used by the Google Apps plugin) in Atlassian Crowd from version 1.5.0 before version 3.1.2 allowed an attacker to impersonate a Crowd user in REST requests by being able to authenticate to a directory bound to an application using the feature. Given the following situation: the Crowd application is bound to directory 1 and has a user called admin and the Google Apps application is bound to directory 2, which also has a user called admin, it was possible to authenticate REST requests using the credentials of the user coming from directory 2 and impersonate the user from directory 1.",
  "id": "GHSA-p3gx-g437-gw6c",
  "modified": "2022-05-13T01:37:18Z",
  "published": "2022-05-13T01:37:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-16858"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/CWD-5009"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P3RJ-H8C5-JHPV

Vulnerability from github – Published: 2023-02-27 18:32 – Updated: 2023-03-07 21:30
VLAI
Details

There is an identity authentication bypass vulnerability in Huawei Children Smart Watch (Simba-AL00) 1.1.1.274. Successful exploitation of this vulnerability may cause the access control function of specific applications to fail.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-48305"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-27T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "There is an identity authentication bypass vulnerability in Huawei Children Smart Watch (Simba-AL00) 1.1.1.274. Successful exploitation of this vulnerability may cause the access control function of specific applications to fail.",
  "id": "GHSA-p3rj-h8c5-jhpv",
  "modified": "2023-03-07T21:30:18Z",
  "published": "2023-02-27T18:32:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48305"
    },
    {
      "type": "WEB",
      "url": "https://www.huawei.com/en/psirt/security-advisories/2023/huawei-sa-iabvithcswsa-c385b2dc-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P3RX-9GW8-X632

Vulnerability from github – Published: 2022-02-10 00:00 – Updated: 2022-04-20 00:01
VLAI
Details

A denial of service vulnerability exists in the Modbus configuration functionality of Sealevel Systems, Inc. SeaConnect 370W v1.3.34. Specially-crafted network packets can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-21964"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-04T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "A denial of service vulnerability exists in the Modbus configuration functionality of Sealevel Systems, Inc. SeaConnect 370W v1.3.34. Specially-crafted network packets can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.",
  "id": "GHSA-p3rx-9gw8-x632",
  "modified": "2022-04-20T00:01:32Z",
  "published": "2022-02-10T00:00:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21964"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2021-1392"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P3VV-Q24C-WG3V

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

Broken Authentication vulnerability in yotuwp Video Gallery plugin <= 1.3.4.5 at WordPress.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-35726"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-23T16:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Broken Authentication vulnerability in yotuwp Video Gallery plugin \u003c= 1.3.4.5 at WordPress.",
  "id": "GHSA-p3vv-q24c-wg3v",
  "modified": "2022-08-27T00:00:56Z",
  "published": "2022-08-24T00:00:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35726"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/yotuwp-easy-youtube-embed/wordpress-video-gallery-plugin-1-3-4-5-broken-authentication"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/yotuwp-easy-youtube-embed/#developers"
    }
  ],
  "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"
    }
  ]
}
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.

← Back to the CWE list