CWE-306
AllowedMissing Authentication for Critical Function
Abstraction: Base · Status: Draft
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
4560 vulnerabilities reference this CWE, most recent first.
GHSA-RRXG-G2PF-6HH4
Vulnerability from github – Published: 2026-09-14 18:08 – Updated: 2026-09-14 18:08Summary
The dashboard reads its authentication credentials from $ESPHOME_USERNAME and $ESPHOME_PASSWORD. Earlier versions, and the legacy esphome dashboard, read the bare $USERNAME and $PASSWORD instead. When the env vars were renamed the bare names were dropped with no fallback, so an operator who had protected their dashboard with USERNAME / PASSWORD (as the older getting started guide documented) loses authentication on upgrade and the dashboard starts open to anyone who can reach its port.
Details
Credentials are resolved in DashboardSettings.parse_args. The fallback originally read os.getenv("USERNAME") and os.getenv("PASSWORD"). The env var rename (#265) replaced those with ESPHOME_USERNAME / ESPHOME_PASSWORD and intentionally removed the bare names, because $USERNAME collides with the OS login user on Linux and Windows and reading it on its own would silently promote the shell user to the dashboard username.
The rename closed that footgun but introduced a backward compatibility break: a deployment that set only the bare names now resolves to no credentials, using_password is false, and the REST auth middleware and the WebSocket login gate are both disabled. The process logs a WITHOUT AUTHENTICATION banner at startup, but a container started detached (docker run -d) never surfaces it, so the exposure is silent in practice.
This reaches users because the dashboard subcommand of the ghcr.io/esphome/esphome container runs this package: the container pins esphome-device-builder and execs it for dashboard, inheriting whatever env the operator passed. The standalone Docker path runs without --ha-addon, so it is the affected path. Home Assistant add on installs are not affected; they pass --ha-addon and authenticate through the supervisor ingress proxy, and do not use these env vars.
The rename was tagged as a breaking change but was not surfaced in the 2026.6.0 changelog, so operators had no signal to migrate before upgrading.
Impact
An unauthenticated client with network access to the dashboard port can manage devices, including editing configurations and flashing firmware. Only deployments that relied on the bare $USERNAME / $PASSWORD env vars for authentication are affected; deployments using --username / --password, the new $ESPHOME_* env vars, or HA add on ingress are not.
Severity rationale
An unauthenticated network client crosses the dashboard's only security boundary, and a client past that boundary has host equivalent capability. ESPHome's threat model documents that an authenticated dashboard caller can run arbitrary code at compile time and read or write files in the config and data directories, so confidentiality, integrity, and availability are all High, with no credentials, no user interaction, and low attack complexity.
The base score is rated for the worst case, an internet reachable dashboard. That worst case is the right anchor here, because this issue only affects operators who had deliberately configured a dashboard password, and setting a password is the control an operator uses precisely when the dashboard is reachable by parties they do not fully trust, including a deployment exposed to the internet or a network segment shared with untrusted devices. For the affected population a trusted network cannot be assumed, so authentication should be restored as urgent.
Operational risk is lower for the subset of affected installations that run on a single trusted home or business network behind a firewall, since reaching the dashboard there requires an attacker who is already inside that network. ESPHome is designed for deployment on trusted networks with the network perimeter as the primary defense, so that deployment context reduces real world exposure; it does not lower the base severity, and operators on shared, guest, or internet reachable networks remain at full risk.
Patches
Fixed in 1.0.12. The bare $USERNAME / $PASSWORD are accepted again as a deprecated fallback so previously protected instances stay protected across the upgrade without operator intervention, with a loud deprecation warning at startup directing operators to rename them to $ESPHOME_USERNAME / $ESPHOME_PASSWORD. The fallback is gated on $PASSWORD being set and is only adopted as a pair, so the OS provided $USERNAME is never read on its own and the original collision footgun stays closed. A lone bare $PASSWORD with no username still fails loud as a credential mismatch rather than starting unauthenticated.
This restores compatibility rather than failing closed on the legacy names, because the priority is that an instance which was protected before the upgrade stays protected without the operator having to act; the deprecation warning plus a future removal handles the migration. Operators should migrate to the $ESPHOME_* names.
The esphome container delivers the fix in the 2026.6.2 release, which bumps its pinned esphome-device-builder version to 1.0.12.
Workarounds
Without upgrading, restore authentication immediately by setting the new env vars to the same values, on any affected version:
ESPHOME_USERNAME=<your-username>
ESPHOME_PASSWORD=<your-password>
Alternatively, do not expose the dashboard port to untrusted networks, and check the startup logs for the WITHOUT AUTHENTICATION banner to confirm whether a given instance is currently open.
References
- Original report against the esphome container: GHSA-446m-c8jp-v37m
- Env var rename that introduced the regression: esphome/device-builder#265
- 2026.6.0 changelog (breaking change was not documented): https://esphome.io/changelog/2026.6.0
- Old setup documentation that used the bare names: https://esphome.io/guides/getting_started_command_line
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "esphome-device-builder"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59178"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-14T18:08:57Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Summary\n\nThe dashboard reads its authentication credentials from `$ESPHOME_USERNAME` and `$ESPHOME_PASSWORD`. Earlier versions, and the legacy `esphome` dashboard, read the bare `$USERNAME` and `$PASSWORD` instead. When the env vars were renamed the bare names were dropped with no fallback, so an operator who had protected their dashboard with `USERNAME` / `PASSWORD` (as the older getting started guide documented) loses authentication on upgrade and the dashboard starts open to anyone who can reach its port.\n\n## Details\n\nCredentials are resolved in `DashboardSettings.parse_args`. The fallback originally read `os.getenv(\"USERNAME\")` and `os.getenv(\"PASSWORD\")`. The env var rename (#265) replaced those with `ESPHOME_USERNAME` / `ESPHOME_PASSWORD` and intentionally removed the bare names, because `$USERNAME` collides with the OS login user on Linux and Windows and reading it on its own would silently promote the shell user to the dashboard username.\n\nThe rename closed that footgun but introduced a backward compatibility break: a deployment that set only the bare names now resolves to no credentials, `using_password` is false, and the REST auth middleware and the WebSocket login gate are both disabled. The process logs a `WITHOUT AUTHENTICATION` banner at startup, but a container started detached (`docker run -d`) never surfaces it, so the exposure is silent in practice.\n\nThis reaches users because the `dashboard` subcommand of the `ghcr.io/esphome/esphome` container runs this package: the container pins `esphome-device-builder` and execs it for `dashboard`, inheriting whatever env the operator passed. The standalone Docker path runs without `--ha-addon`, so it is the affected path. Home Assistant add on installs are not affected; they pass `--ha-addon` and authenticate through the supervisor ingress proxy, and do not use these env vars.\n\nThe rename was tagged as a breaking change but was not surfaced in the 2026.6.0 changelog, so operators had no signal to migrate before upgrading.\n\n## Impact\n\nAn unauthenticated client with network access to the dashboard port can manage devices, including editing configurations and flashing firmware. Only deployments that relied on the bare `$USERNAME` / `$PASSWORD` env vars for authentication are affected; deployments using `--username` / `--password`, the new `$ESPHOME_*` env vars, or HA add on ingress are not.\n\n## Severity rationale\n\nAn unauthenticated network client crosses the dashboard\u0027s only security boundary, and a client past that boundary has host equivalent capability. ESPHome\u0027s [threat model](https://github.com/esphome/device-builder/blob/main/docs/THREAT_MODEL.md) documents that an authenticated dashboard caller can run arbitrary code at compile time and read or write files in the config and data directories, so confidentiality, integrity, and availability are all High, with no credentials, no user interaction, and low attack complexity.\n\nThe base score is rated for the worst case, an internet reachable dashboard. That worst case is the right anchor here, because this issue only affects operators who had deliberately configured a dashboard password, and setting a password is the control an operator uses precisely when the dashboard is reachable by parties they do not fully trust, including a deployment exposed to the internet or a network segment shared with untrusted devices. For the affected population a trusted network cannot be assumed, so authentication should be restored as urgent.\n\nOperational risk is lower for the subset of affected installations that run on a single trusted home or business network behind a firewall, since reaching the dashboard there requires an attacker who is already inside that network. ESPHome is [designed for deployment on trusted networks](https://esphome.io/guides/security_best_practices/) with the network perimeter as the primary defense, so that deployment context reduces real world exposure; it does not lower the base severity, and operators on shared, guest, or internet reachable networks remain at full risk.\n\n## Patches\n\nFixed in 1.0.12. The bare `$USERNAME` / `$PASSWORD` are accepted again as a deprecated fallback so previously protected instances stay protected across the upgrade without operator intervention, with a loud deprecation warning at startup directing operators to rename them to `$ESPHOME_USERNAME` / `$ESPHOME_PASSWORD`. The fallback is gated on `$PASSWORD` being set and is only adopted as a pair, so the OS provided `$USERNAME` is never read on its own and the original collision footgun stays closed. A lone bare `$PASSWORD` with no username still fails loud as a credential mismatch rather than starting unauthenticated.\n\nThis restores compatibility rather than failing closed on the legacy names, because the priority is that an instance which was protected before the upgrade stays protected without the operator having to act; the deprecation warning plus a future removal handles the migration. Operators should migrate to the `$ESPHOME_*` names.\n\nThe esphome container delivers the fix in the 2026.6.2 release, which bumps its pinned `esphome-device-builder` version to 1.0.12.\n\n## Workarounds\n\nWithout upgrading, restore authentication immediately by setting the new env vars to the same values, on any affected version:\n\n```\nESPHOME_USERNAME=\u003cyour-username\u003e\nESPHOME_PASSWORD=\u003cyour-password\u003e\n```\n\nAlternatively, do not expose the dashboard port to untrusted networks, and check the startup logs for the `WITHOUT AUTHENTICATION` banner to confirm whether a given instance is currently open.\n\n## References\n\n- Original report against the esphome container: GHSA-446m-c8jp-v37m\n- Env var rename that introduced the regression: esphome/device-builder#265\n- 2026.6.0 changelog (breaking change was not documented): https://esphome.io/changelog/2026.6.0\n- Old setup documentation that used the bare names: https://esphome.io/guides/getting_started_command_line",
"id": "GHSA-rrxg-g2pf-6hh4",
"modified": "2026-09-14T18:08:57Z",
"published": "2026-09-14T18:08:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/esphome/device-builder/security/advisories/GHSA-rrxg-g2pf-6hh4"
},
{
"type": "WEB",
"url": "https://github.com/esphome/device-builder/pull/1625"
},
{
"type": "WEB",
"url": "https://github.com/esphome/device-builder/commit/9e294f729c3eb7334bb57b9fc49b75b728052f52"
},
{
"type": "PACKAGE",
"url": "https://github.com/esphome/device-builder"
},
{
"type": "WEB",
"url": "https://github.com/esphome/device-builder/releases/tag/1.0.12"
}
],
"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": "ESPHome Device Builder: Renamed auth env vars silently disable dashboard authentication on upgrade"
}
GHSA-RV39-79C4-7459
Vulnerability from github – Published: 2026-02-17 16:37 – Updated: 2026-03-10 18:37Summary
The gateway WebSocket connect handshake could allow skipping device identity checks when auth.token was present but not yet validated.
Details
In src/gateway/server/ws-connection/message-handler.ts, the device-identity requirement could be bypassed based on the presence of a non-empty connectParams.auth.token rather than a validated shared-secret authentication result.
Impact
In deployments where the gateway WebSocket is reachable and connections can be authorized via Tailscale without validating the shared secret, a client could connect without providing device identity/pairing. Depending on version and configuration, this could result in operator access.
Deployment Guidance
Per OpenClaw security guidance, the gateway should only be reachable from a trusted network and by trusted users (for example, restrict Tailnet users/ACLs when using Tailscale Serve).
If the gateway WebSocket is only reachable by trusted users, there is typically no untrusted party with network access to exploit this issue.
Affected Packages / Versions
- Package:
openclaw(npm) - Affected:
<= 2026.2.1 - Fixed:
>= 2026.2.2
Fix
Device-identity skipping now requires validated shared-secret authentication (token/password). Tailscale-authenticated connections without validated shared secret require device identity.
Fix Commit(s)
- fe81b1d7125a014b8280da461f34efbf5f761575
Thanks @simecek for reporting.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.2.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-28472"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-17T16:37:04Z",
"nvd_published_at": "2026-03-05T22:16:21Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nThe gateway WebSocket `connect` handshake could allow skipping device identity checks when `auth.token` was present but not yet validated.\n\n### Details\n\nIn `src/gateway/server/ws-connection/message-handler.ts`, the device-identity requirement could be bypassed based on the *presence* of a non-empty `connectParams.auth.token` rather than a *validated* shared-secret authentication result.\n\n### Impact\n\nIn deployments where the gateway WebSocket is reachable and connections can be authorized via Tailscale without validating the shared secret, a client could connect without providing device identity/pairing. Depending on version and configuration, this could result in operator access.\n\n### Deployment Guidance\n\nPer OpenClaw security guidance, the gateway should only be reachable from a trusted network and by trusted users (for example, restrict Tailnet users/ACLs when using Tailscale Serve).\n\nIf the gateway WebSocket is only reachable by trusted users, there is typically no untrusted party with network access to exploit this issue.\n\n### Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected: `\u003c= 2026.2.1`\n- Fixed: `\u003e= 2026.2.2`\n\n### Fix\n\nDevice-identity skipping now requires *validated* shared-secret authentication (token/password). Tailscale-authenticated connections without validated shared secret require device identity.\n\n### Fix Commit(s)\n\n- fe81b1d7125a014b8280da461f34efbf5f761575\n\nThanks @simecek for reporting.",
"id": "GHSA-rv39-79c4-7459",
"modified": "2026-03-10T18:37:22Z",
"published": "2026-02-17T16:37:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-rv39-79c4-7459"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28472"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/fe81b1d7125a014b8280da461f34efbf5f761575"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/releases/tag/v2026.2.2"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-device-identity-check-bypass-in-gateway-websocket-connect-handshake"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw\u0027s gateway connect could skip device identity checks when auth.token was present but not yet validated"
}
GHSA-RV65-QG4J-MCMV
Vulnerability from github – Published: 2026-06-22 18:34 – Updated: 2026-06-28 00:30Lack of authentication when using the "snapshot diff" functions in qSnapper before version 1.3.3 allowed a local attacker to see otherwise read protected information.
{
"affected": [],
"aliases": [
"CVE-2026-41047"
],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-22T16:16:35Z",
"severity": "MODERATE"
},
"details": "Lack of authentication when using the \"snapshot diff\" functions in qSnapper before version 1.3.3 allowed a local attacker to see otherwise read protected information.",
"id": "GHSA-rv65-qg4j-mcmv",
"modified": "2026-06-28T00:30:56Z",
"published": "2026-06-22T18:34:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41047"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=1261890"
},
{
"type": "WEB",
"url": "https://github.com/presire/qSnapper/releases/tag/v1.3.3"
},
{
"type": "WEB",
"url": "https://security.opensuse.org/2026/05/26/qsnapper-dbus-issues.html#issue-info-leak"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/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-RVF2-2R2V-X27P
Vulnerability from github – Published: 2026-02-27 00:31 – Updated: 2026-03-05 21:30WebSocket endpoints lack proper authentication mechanisms, enabling attackers to perform unauthorized station impersonation and manipulate data sent to the backend. An unauthenticated attacker can connect to the OCPP WebSocket endpoint using a known or discovered charging station identifier, then issue or receive OCPP commands as a legitimate charger. Given that no authentication is required, this can lead to privilege escalation, unauthorized control of charging infrastructure, and corruption of charging network data reported to the backend.
{
"affected": [],
"aliases": [
"CVE-2026-27767"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-27T00:16:58Z",
"severity": "CRITICAL"
},
"details": "WebSocket endpoints lack proper authentication mechanisms, enabling \nattackers to perform unauthorized station impersonation and manipulate \ndata sent to the backend. An unauthenticated attacker can connect to the\n OCPP WebSocket endpoint using a known or discovered charging station \nidentifier, then issue or receive OCPP commands as a legitimate charger.\n Given that no authentication is required, this can lead to privilege \nescalation, unauthorized control of charging infrastructure, and \ncorruption of charging network data reported to the backend.",
"id": "GHSA-rvf2-2r2v-x27p",
"modified": "2026-03-05T21:30:27Z",
"published": "2026-02-27T00:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27767"
},
{
"type": "WEB",
"url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-057-06.json"
},
{
"type": "WEB",
"url": "https://swtchenergy.com/contact"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-057-06"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-RVFP-J42C-8VRC
Vulnerability from github – Published: 2023-07-04 00:31 – Updated: 2024-04-04 05:21Hero Qubo HCD01_02_V1.38_20220125 devices allow TELNET access with root privileges by default, without a password.
{
"affected": [],
"aliases": [
"CVE-2023-22906"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-04T00:15:09Z",
"severity": "HIGH"
},
"details": "Hero Qubo HCD01_02_V1.38_20220125 devices allow TELNET access with root privileges by default, without a password.",
"id": "GHSA-rvfp-j42c-8vrc",
"modified": "2024-04-04T05:21:04Z",
"published": "2023-07-04T00:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22906"
},
{
"type": "WEB",
"url": "https://github.com/nonamecoder/CVE-2023-22906"
},
{
"type": "WEB",
"url": "https://twitter.com/ayyappan162010/status/1610764707753000960"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RVFV-GFCW-5592
Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2022-05-24 16:45An exploitable improper access control vulnerability exists in the bluetooth low energy functionality of Winco Fireworks FireFly FW-1007 V2.0. An attacker can connect to the device to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2019-5014"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-08T17:29:00Z",
"severity": "MODERATE"
},
"details": "An exploitable improper access control vulnerability exists in the bluetooth low energy functionality of Winco Fireworks FireFly FW-1007 V2.0. An attacker can connect to the device to trigger this vulnerability.",
"id": "GHSA-rvfv-gfcw-5592",
"modified": "2022-05-24T16:45:22Z",
"published": "2022-05-24T16:45:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5014"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2019-0772"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RVGX-9F8H-XPR7
Vulnerability from github – Published: 2026-07-14 18:32 – Updated: 2026-07-14 18:32Missing authentication for critical function in Windows Server Update Service allows an authorized attacker to elevate privileges over a network.
{
"affected": [],
"aliases": [
"CVE-2026-50444"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T18:17:48Z",
"severity": "HIGH"
},
"details": "Missing authentication for critical function in Windows Server Update Service allows an authorized attacker to elevate privileges over a network.",
"id": "GHSA-rvgx-9f8h-xpr7",
"modified": "2026-07-14T18:32:24Z",
"published": "2026-07-14T18:32:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50444"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50444"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RVP9-HFHR-8GGG
Vulnerability from github – Published: 2025-06-20 15:30 – Updated: 2025-07-08 15:31An issue was discovered on COROS PACE 3 devices through 3.0808.0. The BLE implementation of the COROS smartwatch does not support LE Secure Connections and instead enforces BLE Legacy Pairing. In BLE Legacy Pairing, the Short-Term Key (STK) can be easily guessed. This requires knowledge of the Temporary Key (TK), which, in the case of the COROS Pace 3, is set to 0 due to the Just Works pairing method. An attacker within Bluetooth range can therefore perform sniffing attacks, allowing eavesdropping on the communication.
{
"affected": [],
"aliases": [
"CVE-2025-32876"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-20T14:15:27Z",
"severity": "MODERATE"
},
"details": "An issue was discovered on COROS PACE 3 devices through 3.0808.0. The BLE implementation of the COROS smartwatch does not support LE Secure Connections and instead enforces BLE Legacy Pairing. In BLE Legacy Pairing, the Short-Term Key (STK) can be easily guessed. This requires knowledge of the Temporary Key (TK), which, in the case of the COROS Pace 3, is set to 0 due to the Just Works pairing method. An attacker within Bluetooth range can therefore perform sniffing attacks, allowing eavesdropping on the communication.",
"id": "GHSA-rvp9-hfhr-8ggg",
"modified": "2025-07-08T15:31:45Z",
"published": "2025-06-20T15:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32876"
},
{
"type": "WEB",
"url": "https://support.coros.com/hc/en-us/articles/20087694119828-COROS-PACE-3-Release-Notes"
},
{
"type": "WEB",
"url": "https://syss.de"
},
{
"type": "WEB",
"url": "https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2025-023.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RW3Q-FV8Q-C2XF
Vulnerability from github – Published: 2023-07-06 21:15 – Updated: 2024-04-04 05:48Missing Authentication for Critical Function vulnerability in Honeywell OneWireless allows Authentication Bypass. This issue affects OneWireless version 322.1
{
"affected": [],
"aliases": [
"CVE-2022-4240"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-30T17:15:09Z",
"severity": "HIGH"
},
"details": "Missing Authentication for Critical Function vulnerability in Honeywell OneWireless allows Authentication Bypass.\u00a0This issue affects OneWireless version 322.1",
"id": "GHSA-rw3q-fv8q-c2xf",
"modified": "2024-04-04T05:48:13Z",
"published": "2023-07-06T21:15:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4240"
},
{
"type": "WEB",
"url": "https://process.honeywell.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-RW77-76P7-66X5
Vulnerability from github – Published: 2025-09-25 15:30 – Updated: 2026-01-30 06:30A missing authentication for critical function vulnerability in SUNNET Corporate Training Management System before 10.11 allows remote attackers to access deployment functionality without prior authentication.
{
"affected": [],
"aliases": [
"CVE-2025-54942"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-30T04:15:49Z",
"severity": "CRITICAL"
},
"details": "A missing authentication for critical function vulnerability in SUNNET Corporate Training Management System before 10.11 allows remote attackers to access deployment functionality without prior authentication.",
"id": "GHSA-rw77-76p7-66x5",
"modified": "2026-01-30T06:30:15Z",
"published": "2025-09-25T15:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54942"
},
{
"type": "WEB",
"url": "https://zuso.ai/advisory"
},
{
"type": "WEB",
"url": "https://zuso.ai/advisory/za-2025-10"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/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"
}
]
}
Mitigation
- Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.
- Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.
- In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation
- Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks.
- In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
Mitigation MIT-4.5
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
Mitigation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].
CAPEC-12: Choosing Message Identifier
This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.
CAPEC-166: Force the System to Reset Values
An attacker forces the target into a previous state in order to leverage potential weaknesses in the target dependent upon a prior configuration or state-dependent factors. Even in cases where an attacker may not be able to directly control the configuration of the targeted application, they may be able to reset the configuration to a prior state since many applications implement reset functions.
CAPEC-216: Communication Channel Manipulation
An adversary manipulates a setting or parameter on communications channel in order to compromise its security. This can result in information exposure, insertion/removal of information from the communications stream, and/or potentially system compromise.
CAPEC-36: Using Unpublished Interfaces or Functionality
An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.
CAPEC-62: Cross Site Request Forgery
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.