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.
3489 vulnerabilities reference this CWE, most recent first.
GHSA-37VR-RQXP-V3J3
Vulnerability from github – Published: 2026-02-07 00:30 – Updated: 2026-02-07 00:30DBPower C300 HD Camera contains a configuration disclosure vulnerability that allows unauthenticated attackers to retrieve sensitive credentials through an unprotected configuration backup endpoint. Attackers can download the configuration file and extract hardcoded username and password by accessing the /tmpfs/config_backup.bin resource.
{
"affected": [],
"aliases": [
"CVE-2020-37157"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-07T00:15:55Z",
"severity": "HIGH"
},
"details": "DBPower C300 HD Camera contains a configuration disclosure vulnerability that allows unauthenticated attackers to retrieve sensitive credentials through an unprotected configuration backup endpoint. Attackers can download the configuration file and extract hardcoded username and password by accessing the /tmpfs/config_backup.bin resource.",
"id": "GHSA-37vr-rqxp-v3j3",
"modified": "2026-02-07T00:30:28Z",
"published": "2026-02-07T00:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-37157"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20200620110617/https://donev.eu/blog/dbpower-c300-multiple-vulnerabilities"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/48095"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/dbpower-c-hd-camera-remote-configuration-disclosure"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/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-3836-54FG-7R66
Vulnerability from github – Published: 2023-11-30 00:30 – Updated: 2023-11-30 00:30NETGEAR ProSAFE Network Management System has Java Debug Wire Protocol (JDWP) listening on port 11611 and it is remotely accessible by unauthenticated users, allowing attackers to execute arbitrary code.
{
"affected": [],
"aliases": [
"CVE-2023-49693"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-29T23:15:20Z",
"severity": "CRITICAL"
},
"details": "\nNETGEAR ProSAFE Network Management System has Java Debug Wire Protocol (JDWP) listening on port 11611 and it is remotely accessible by unauthenticated users, allowing attackers to execute arbitrary code.\n\n",
"id": "GHSA-3836-54fg-7r66",
"modified": "2023-11-30T00:30:18Z",
"published": "2023-11-30T00:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49693"
},
{
"type": "WEB",
"url": "https://kb.netgear.com/000065886/Security-Advisory-for-Sensitive-Information-Disclosure-on-the-NMS300-PSV-2023-0126"
},
{
"type": "WEB",
"url": "https://www.tenable.com/security/research/tra-2023-39"
}
],
"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-383H-W6H6-RXM5
Vulnerability from github – Published: 2023-01-26 21:30 – Updated: 2023-02-01 18:30The force offline MFA prompt setting is not respected when switching to offline mode in Devolutions Remote Desktop Manager 2022.3.29 to 2022.3.30 allows a user to save sensitive data on disk.
{
"affected": [],
"aliases": [
"CVE-2023-0463"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-26T21:18:00Z",
"severity": "LOW"
},
"details": "The force offline MFA prompt setting is not respected when switching to offline mode in Devolutions Remote Desktop Manager 2022.3.29 to 2022.3.30 allows a user to save sensitive data on disk.",
"id": "GHSA-383h-w6h6-rxm5",
"modified": "2023-02-01T18:30:30Z",
"published": "2023-01-26T21:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0463"
},
{
"type": "WEB",
"url": "https://devolutions.net/security/advisories/DEVO-2023-0001"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-389X-22J4-JR37
Vulnerability from github – Published: 2022-05-24 19:01 – Updated: 2022-05-24 19:01A vulnerability in the web-based management interface of Cisco HyperFlex HX Data Platform could allow an unauthenticated, remote attacker to upload files to an affected device. This vulnerability is due to missing authentication for the upload function. An attacker could exploit this vulnerability by sending a specific HTTP request to an affected device. A successful exploit could allow the attacker to upload files to the affected device with the permissions of the tomcat8 user.
{
"affected": [],
"aliases": [
"CVE-2021-1499"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-06T13:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the web-based management interface of Cisco HyperFlex HX Data Platform could allow an unauthenticated, remote attacker to upload files to an affected device. This vulnerability is due to missing authentication for the upload function. An attacker could exploit this vulnerability by sending a specific HTTP request to an affected device. A successful exploit could allow the attacker to upload files to the affected device with the permissions of the tomcat8 user.",
"id": "GHSA-389x-22j4-jr37",
"modified": "2022-05-24T19:01:35Z",
"published": "2022-05-24T19:01:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1499"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-hyperflex-upload-KtCK8Ugz"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/163203/Cisco-HyperFlex-HX-Data-Platform-File-Upload-Remote-Code-Execution.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-38JH-8H67-M7MJ
Vulnerability from github – Published: 2024-08-27 18:40 – Updated: 2024-08-27 18:40Summary
The Chisel server doesn't ever read the documented AUTH environment variable used to set credentials, which allows any unauthenticated user to connect, even if credentials were set. This advisory is a formalization of a report sent to the maintainer via email.
Details
In the help page for the chisel server subcommand, it mentions an AUTH environment variable that can be set in order to provide credentials that the server should authenticate connections against: https://github.com/jpillora/chisel/blob/3de177432cd23db58e57f376b62ad497cc10840f/main.go#L138.
The issue is that the server entrypoint doesn't ever read the AUTH environment variable. The only place that this happens is in the client entrypoint: https://github.com/jpillora/chisel/blob/3de177432cd23db58e57f376b62ad497cc10840f/main.go#L452
This subverts the expectations set by the documentation, allowing unauthenticated users to connect to a Chisel server, even if auth is attempted to be set up in this manner.
PoC
Run chisel server, first specifying credentials with the AUTH environment variable, then with the --auth argument. In the first case, the server allows connections without authentication, while in the second, the correct behavior is exhibited.
Impact
Anyone who is running the Chisel server, and that is using the AUTH environment variable to specify credentials to authenticate against. Chisel is often used to provide an entrypoint to a private network, which means services that are gated by Chisel may be affected. Additionally, Chisel is often used for exposing services to the internet. An attacker could MITM requests by connecting to a Chisel server and requesting to forward traffic from a remote port.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/jpillora/chisel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.10.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-43798"
],
"database_specific": {
"cwe_ids": [
"CWE-1068",
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2024-08-27T18:40:29Z",
"nvd_published_at": "2024-08-26T23:15:04Z",
"severity": "HIGH"
},
"details": "### Summary\nThe Chisel server doesn\u0027t ever read the documented `AUTH` environment variable used to set credentials, which allows any unauthenticated user to connect, even if credentials were set. This advisory is a formalization of a report sent to the maintainer via email.\n\n### Details\nIn the help page for the `chisel server` subcommand, it mentions an `AUTH` environment variable that can be set in order to provide credentials that the server should authenticate connections against: https://github.com/jpillora/chisel/blob/3de177432cd23db58e57f376b62ad497cc10840f/main.go#L138.\n\nThe issue is that the server entrypoint doesn\u0027t ever read the `AUTH` environment variable. The only place that this happens is in the client entrypoint: https://github.com/jpillora/chisel/blob/3de177432cd23db58e57f376b62ad497cc10840f/main.go#L452\n\nThis subverts the expectations set by the documentation, allowing unauthenticated users to connect to a Chisel server, even if auth is attempted to be set up in this manner.\n\n### PoC\nRun `chisel server`, first specifying credentials with the `AUTH` environment variable, then with the `--auth` argument. In the first case, the server allows connections without authentication, while in the second, the correct behavior is exhibited.\n\n### Impact\nAnyone who is running the Chisel server, and that is using the `AUTH` environment variable to specify credentials to authenticate against. Chisel is often used to provide an entrypoint to a private network, which means services that are gated by Chisel may be affected. Additionally, Chisel is often used for exposing services to the internet. An attacker could MITM requests by connecting to a Chisel server and requesting to forward traffic from a remote port. ",
"id": "GHSA-38jh-8h67-m7mj",
"modified": "2024-08-27T18:40:29Z",
"published": "2024-08-27T18:40:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jpillora/chisel/security/advisories/GHSA-38jh-8h67-m7mj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43798"
},
{
"type": "PACKAGE",
"url": "https://github.com/jpillora/chisel"
},
{
"type": "WEB",
"url": "https://github.com/jpillora/chisel/blob/3de177432cd23db58e57f376b62ad497cc10840f/main.go#L138"
},
{
"type": "WEB",
"url": "https://github.com/jpillora/chisel/blob/3de177432cd23db58e57f376b62ad497cc10840f/main.go#L452"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Chisel\u0027s AUTH environment variable not respected in server entrypoint"
}
GHSA-38MV-4MRH-VPWC
Vulnerability from github – Published: 2025-12-20 03:31 – Updated: 2026-04-04 00:31The HTTPS service on Tapo C200 V3 exposes a connectAP interface without proper authentication. An unauthenticated attacker on the same local network segment can exploit this to modify the device’s Wi-Fi configuration, resulting in loss of connectivity and denial-of-service (DoS).
{
"affected": [],
"aliases": [
"CVE-2025-14300"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-20T01:16:03Z",
"severity": "HIGH"
},
"details": "The HTTPS service on Tapo C200 V3 exposes a connectAP interface without proper authentication. An unauthenticated attacker on the same local network segment can exploit this to modify the device\u2019s Wi-Fi configuration, resulting in loss of connectivity and denial-of-service (DoS).",
"id": "GHSA-38mv-4mrh-vpwc",
"modified": "2026-04-04T00:31:26Z",
"published": "2025-12-20T03:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14300"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/en/support/download/tapo-c100/v5/#Firmware-Release-Notes"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/en/support/download/tapo-c200/v3/#Firmware-Release-Notes"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/us/support/download/tapo-c100/v5/#Firmware-Release-Notes"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/us/support/download/tapo-c200/v3/#Firmware-Release-Notes"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/us/support/faq/4849"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/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"
}
]
}
GHSA-3935-R7M3-H32J
Vulnerability from github – Published: 2022-05-13 01:37 – Updated: 2022-05-13 01:37A Missing Authentication for Critical Function issue was discovered in OPW Fuel Management Systems SiteSentinel Integra 100, SiteSentinel Integra 500, and SiteSentinel iSite ATG consoles with the following software versions: older than V175, V175-V189, V191-V195, and V16Q3.1. An attacker may create an application user account to gain administrative privileges.
{
"affected": [],
"aliases": [
"CVE-2017-12733"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-09-09T01:29:00Z",
"severity": "CRITICAL"
},
"details": "A Missing Authentication for Critical Function issue was discovered in OPW Fuel Management Systems SiteSentinel Integra 100, SiteSentinel Integra 500, and SiteSentinel iSite ATG consoles with the following software versions: older than V175, V175-V189, V191-V195, and V16Q3.1. An attacker may create an application user account to gain administrative privileges.",
"id": "GHSA-3935-r7m3-h32j",
"modified": "2022-05-13T01:37:44Z",
"published": "2022-05-13T01:37:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12733"
},
{
"type": "WEB",
"url": "https://ics-cert.us-cert.gov/advisories/ICSA-17-243-04"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/100563"
}
],
"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-393J-8XCQ-H729
Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36Version 1.0.0 of the Instana Dynamic APM Docker image contains a blank password for the root user. Systems deployed using affected versions of the Instana Dynamic APM container may allow a remote attacker to achieve root access with a blank password.
{
"affected": [],
"aliases": [
"CVE-2020-35463"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-15T23:15:00Z",
"severity": "CRITICAL"
},
"details": "Version 1.0.0 of the Instana Dynamic APM Docker image contains a blank password for the root user. Systems deployed using affected versions of the Instana Dynamic APM container may allow a remote attacker to achieve root access with a blank password.",
"id": "GHSA-393j-8xcq-h729",
"modified": "2022-05-24T17:36:42Z",
"published": "2022-05-24T17:36:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35463"
},
{
"type": "WEB",
"url": "https://github.com/donghyunlee00/CVE/blob/main/CVE-2020-35463"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-396R-WG2M-QXG7
Vulnerability from github – Published: 2026-04-06 00:30 – Updated: 2026-04-06 00:30Missing Authentication for Critical Function vulnerability in Honeywell Handheld Scanners allows Authentication Abuse.This issue affects Handheld Scanners: from C1 Base(Ingenic x1000) before GK000432BAA, from D1 Base(Ingenic x1600) before HE000085BAA, from A1/B1 Base(IMX25) before BK000763BAA_BK000765BAA_CU000101BAA.
This vulnerability could allow a remote attacker within Bluetooth range of the scanner's base station has the capability to remotely execute system commands on the host connected to the base station without authentication. This issue has been assigned CVE-2026-4272 https://nvd.nist.gov/vuln/detail/CVE-2026-4272 and rated with a severity of High. Honeywell strongly recommends that users upgrade to the latest version identified to resolve the vulnerability.
{
"affected": [],
"aliases": [
"CVE-2026-4272"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-05T22:16:01Z",
"severity": "HIGH"
},
"details": "Missing Authentication for Critical Function vulnerability in Honeywell Handheld Scanners allows Authentication Abuse.This issue affects Handheld Scanners: from C1 Base(Ingenic x1000) before GK000432BAA, from D1 Base(Ingenic x1600) before HE000085BAA, from A1/B1 Base(IMX25) before BK000763BAA_BK000765BAA_CU000101BAA.\n\nThis vulnerability could allow a remote attacker within Bluetooth range of the scanner\u0027s base station has the capability to remotely execute system commands on the host connected to the base station without authentication. This issue has been assigned\u00a0 CVE-2026-4272 https://nvd.nist.gov/vuln/detail/CVE-2026-4272 and rated with a severity of High. Honeywell strongly recommends that users upgrade to the latest version identified to resolve the vulnerability.",
"id": "GHSA-396r-wg2m-qxg7",
"modified": "2026-04-06T00:30:24Z",
"published": "2026-04-06T00:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4272"
},
{
"type": "ADVISORY",
"url": "https://https://nvd.nist.gov/vuln/detail/CVE-2026-4272"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3988-Q8Q7-P787
Vulnerability from github – Published: 2025-04-14 23:00 – Updated: 2025-04-16 00:40Impact
The confirmation flow for account creation currently uses a GET request triggered by clicking a link sent via email. Some email clients and security tools (e.g., Outlook, virus scanners, and email previewers) may automatically follow these links, unintentionally confirming the account. This allows an attacker to register an account using another user’s email and potentially have it auto-confirmed by the victim’s email client.
This does not allow attackers to take over or access existing accounts or private data. It is limited to account confirmation of new accounts only.
Patches
A mitigation has been released in version 4.7.0. You will also need to upgrade to 2.6.0 or later of ash_authentication_phoenix to take advantage of the autogenerated views for confirmation. The fix updates the confirmation flow to require explicit user interaction (such as clicking a button on the confirmation page) rather than performing the confirmation via a GET request. This ensures that automatic link prefetching or scanning by email clients does not unintentionally confirm accounts.
To mitigate, follow these steps:
- Upgrade
ash_authentication>=4.7.0 - Upgrade
ash_authentication_phoenix>=2.6.0(if usingash_authentication_phoenix) - Set
require_interaction? truein your confirmation strategy. - Add
confirm_routeto your router, if usingash_authentication_phoenixaboveauth_routes.
Setting require_interaction? true
modify your confirmation strategy like so:
confirmation <strategy_name> do
...
require_interaction? true
end
Adding the confirm_route to your router
In order to use this new confirmation flow, you will need to add this to your router to get the desired behavior. It will add a new route to the new confirmation page LiveView. Note the path and token_as_route_param? options, required for keeping backwards compatibility with current defaults. You may need to adjust if you have changed those routes in some way.
IMPORTANT - above auth_routes
Make sure this goes above auth_routes if you are using the path option, and it begins with /auth,
or whatever your configured auth_routes_prefix is. auth_routes greedily handles all routes at the
configured path.
confirm_route(
MyApp.Accounts.User,
<confirmation_strategy_name>,
auth_routes_prefix: "/auth",
overrides: [MyAppWeb.AuthOverrides, AshAuthentication.Phoenix.Overrides.Default],
# use these options to keep your currently issued confirmation emails compatible
# without the options below, the route will default to `/<the_strategy_name>/:token`
path: "/auth/user/<confirmation_strategy_name>",
token_as_route_param?: false
)
Users should upgrade to version 4.7.0 as soon as possible, and set require_interaction? to true in their confirmation strategy. This will change the GET request generated for confirming to a POST request.
If you upgrade to this version and do not set require_interaction? to true, compilation will be fail with a message linking to this advisory. This error can be bypassed if, for example, you are confident that you are not affected.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
You can disable the confirmation routes and create your own live view. We highly advised that you upgrade and take advantage of the builtin views if possible. If you are not using the provided views, you will need to add a confirmation LiveView, that does a POST to the old confirmation url instead of a GET. You would do this by taking the token a parameter out of the link, and adding it as a hidden field to a form. That form would have no inputs, only a button that posts to the confirmation URL. If you are using Liveview, this would be done with phx-trigger-action and phx-action.
{
"affected": [
{
"package": {
"ecosystem": "Hex",
"name": "ash_authentication"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.7.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-32782"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-14T23:00:39Z",
"nvd_published_at": "2025-04-15T22:15:28Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nThe confirmation flow for account creation currently uses a GET request triggered by clicking a link sent via email. Some email clients and security tools (e.g., Outlook, virus scanners, and email previewers) may automatically follow these links, unintentionally confirming the account. This allows an attacker to register an account using another user\u2019s email and potentially have it auto-confirmed by the victim\u2019s email client.\n\nThis does not allow attackers to take over or access existing accounts or private data. It is limited to account confirmation of new accounts only.\n\n### Patches\nA mitigation has been released in version `4.7.0`. You will also need to upgrade to `2.6.0` or later of `ash_authentication_phoenix` to take advantage of the autogenerated views for confirmation. The fix updates the confirmation flow to require explicit user interaction (such as clicking a button on the confirmation page) rather than performing the confirmation via a GET request. This ensures that automatic link prefetching or scanning by email clients does not unintentionally confirm accounts.\n\nTo mitigate, follow these steps:\n\n1. Upgrade `ash_authentication` \u003e= `4.7.0`\n2. Upgrade `ash_authentication_phoenix` \u003e= `2.6.0` (if using `ash_authentication_phoenix`)\n3. Set `require_interaction? true` in your confirmation strategy.\n4. Add `confirm_route` to your router, if using `ash_authentication_phoenix` *above* `auth_routes`.\n\n#### Setting `require_interaction? true`\n\nmodify your `confirmation` strategy like so:\n\n```elixir\nconfirmation \u003cstrategy_name\u003e do\n ...\n require_interaction? true\nend\n```\n\n#### Adding the `confirm_route` to your router\n\nIn order to use this new confirmation flow, you will need to add this to your router to get the desired behavior. It will add a new route to the new confirmation page LiveView. Note the `path` and `token_as_route_param?` options, required for keeping backwards compatibility with current defaults. You may need to adjust if you have changed those routes in some way.\n\n##### IMPORTANT - above `auth_routes`\n\nMake sure this goes *above* `auth_routes` if you are using the `path` option, and it begins with `/auth`,\nor whatever your configured `auth_routes_prefix` is. `auth_routes` greedily handles all routes at the\nconfigured path.\n\n```elixir\nconfirm_route(\n MyApp.Accounts.User,\n \u003cconfirmation_strategy_name\u003e,\n auth_routes_prefix: \"/auth\",\n overrides: [MyAppWeb.AuthOverrides, AshAuthentication.Phoenix.Overrides.Default],\n # use these options to keep your currently issued confirmation emails compatible\n # without the options below, the route will default to `/\u003cthe_strategy_name\u003e/:token`\n path: \"/auth/user/\u003cconfirmation_strategy_name\u003e\",\n token_as_route_param?: false\n)\n```\n\nUsers should upgrade to version `4.7.0` as soon as possible, and set `require_interaction?` to `true` in their confirmation strategy. This will change the `GET` request generated for confirming to a `POST` request. \n\nIf you upgrade to this version and do not set `require_interaction?` to `true`, compilation will be fail with a message linking to this advisory. This error can be bypassed if, for example, you are confident that you are not affected.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\nYou can disable the confirmation routes and create your own live view. We highly advised that you upgrade and take advantage of the builtin views if possible. If you are not using the provided views, you will need to *add* a confirmation LiveView, that does a `POST` to the old confirmation url instead of a `GET`. You would do this by taking the token a parameter out of the link, and adding it as a hidden field to a form. That form would have no inputs, only a button that posts to the confirmation URL. If you are using Liveview, this would be done with `phx-trigger-action` and `phx-action`.",
"id": "GHSA-3988-q8q7-p787",
"modified": "2025-04-16T00:40:51Z",
"published": "2025-04-14T23:00:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-3988-q8q7-p787"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32782"
},
{
"type": "WEB",
"url": "https://github.com/team-alembic/ash_authentication/commit/99ea38977fd4f421d2aaae0c2fb29f8e5f8f707d"
},
{
"type": "PACKAGE",
"url": "https://github.com/team-alembic/ash_authentication"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "ash_authentication has email link auto-click account confirmation vulnerability"
}
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.