CWE-287
DiscouragedImproper Authentication
Abstraction: Class · Status: Draft
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
6877 vulnerabilities reference this CWE, most recent first.
GHSA-FPM2-M4QQ-WGHR
Vulnerability from github – Published: 2026-08-24 18:31 – Updated: 2026-08-28 21:56Improper Authentication vulnerability in Apache Camel Platform HTTP Main component.
This issue affects Apache Camel: from 4.8.0 before 4.22.0.
The camel-main embedded HTTP server can protect its endpoints with JWT authentication, configured through authenticationEnabled together with the JWT keystore properties. JWTAuthenticationConfigurer.buildJwtOptions returned null when neither jwtIssuer nor jwtAudience was configured, and the caller then skipped the JWTAuthOptions.setJWTOptions call entirely, so the Vert.x JWTAuth instance was built from the keystore alone. The result was that inbound tokens were checked only for signature and expiry: the iss and aud claims were not validated at all. Nothing signalled this - the server started normally and reported no warning - so a deployment configured the documented way silently enforced less than the operator believed it had enabled, and the component documentation itself presented signature and expiry checking as the default with issuer and audience as an optional extra. Both the application server and the management server were affected, because the omission was in each of the two configureAuthentication paths. Any unexpired token signed by any key the configured keystore trusts was therefore accepted, regardless of which issuer minted it or which audience it was intended for. How far that reaches depends on the trust set of the keystore: where the signing key belongs to a shared or multi-tenant identity provider, a token legitimately issued for an entirely different audience is accepted, while a keystore holding a dedicated signer narrows it to reuse of tokens minted for other services within the same trust domain. The jwtIssuer and jwtAudience options did not exist before 4.21.0, so on earlier releases there was no supported way to have these claims enforced at all.
Users are recommended to upgrade to version 4.22.0, which fixes the issue. From 4.22.0 the server refuses to start when a JWT keystore is configured but neither jwtIssuer nor jwtAudience is set, naming the properties involved, and a deployment that genuinely wants signature and expiry validation only must say so explicitly with the new jwtAllowMissingIssuerAndAudience option, which defaults to false. This behaviour is fixed only on 4.22.0. The 4.14.9 and 4.18.4 releases do not change the default: they add the jwtIssuer and jwtAudience options so that operators on those maintenance lines can enforce the claims by configuration, and an installation that upgrades to 4.14.9 or 4.18.4 without also setting at least one of those two properties is still accepting any unexpired token signed by a trusted key. Users on 4.14.x or 4.18.x should therefore upgrade to 4.14.9 or 4.18.4 and then set jwtIssuer, jwtAudience, or both. Releases from 4.8.0 up to and including 4.21.x offer no way to enforce these claims and should be moved to a version that does. Independently of version, restrict the JWT keystore to the smallest possible trust set - ideally a signer dedicated to this service rather than a shared identity-provider key - and where a gateway already validates issuer and audience in front of the server, ensure it cannot be bypassed.
Notes:
The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24281 refers to the various commits that resolved the issue, and has more details.
The fail-closed guard could not be backported. The jwtIssuer and jwtAudience options were themselves only introduced in 4.21.0 by CAMEL-23525, so on camel-4.18.x and camel-4.14.x there was nothing an operator could set to satisfy the requirement and the guard would have broken every JWT deployment on those branches with no remedy available.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-platform-http-main"
},
"ranges": [
{
"events": [
{
"introduced": "4.8.0"
},
{
"fixed": "4.22.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-66908"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T21:56:58Z",
"nvd_published_at": "2026-08-24T17:18:06Z",
"severity": "HIGH"
},
"details": "Improper Authentication vulnerability in Apache Camel Platform HTTP Main component.\n\nThis issue affects Apache Camel: from 4.8.0 before 4.22.0.\n\nThe camel-main embedded HTTP server can protect its endpoints with JWT authentication, configured through authenticationEnabled together with the JWT keystore properties. JWTAuthenticationConfigurer.buildJwtOptions returned null when neither jwtIssuer nor jwtAudience was configured, and the caller then skipped the JWTAuthOptions.setJWTOptions call entirely, so the Vert.x JWTAuth instance was built from the keystore alone. The result was that inbound tokens were checked only for signature and expiry: the iss and aud claims were not validated at all. Nothing signalled this - the server started normally and reported no warning - so a deployment configured the documented way silently enforced less than the operator believed it had enabled, and the component documentation itself presented signature and expiry checking as the default with issuer and audience as an optional extra. Both the application server and the management server were affected, because the omission was in each of the two configureAuthentication paths. Any unexpired token signed by any key the configured keystore trusts was therefore accepted, regardless of which issuer minted it or which audience it was intended for. How far that reaches depends on the trust set of the keystore: where the signing key belongs to a shared or multi-tenant identity provider, a token legitimately issued for an entirely different audience is accepted, while a keystore holding a dedicated signer narrows it to reuse of tokens minted for other services within the same trust domain. The jwtIssuer and jwtAudience options did not exist before 4.21.0, so on earlier releases there was no supported way to have these claims enforced at all.\n\nUsers are recommended to upgrade to version 4.22.0, which fixes the issue. From 4.22.0 the server refuses to start when a JWT keystore is configured but neither jwtIssuer nor jwtAudience is set, naming the properties involved, and a deployment that genuinely wants signature and expiry validation only must say so explicitly with the new jwtAllowMissingIssuerAndAudience option, which defaults to false. This behaviour is fixed only on 4.22.0. The 4.14.9 and 4.18.4 releases do not change the default: they add the jwtIssuer and jwtAudience options so that operators on those maintenance lines can enforce the claims by configuration, and an installation that upgrades to 4.14.9 or 4.18.4 without also setting at least one of those two properties is still accepting any unexpired token signed by a trusted key. Users on 4.14.x or 4.18.x should therefore upgrade to 4.14.9 or 4.18.4 and then set jwtIssuer, jwtAudience, or both. Releases from 4.8.0 up to and including 4.21.x offer no way to enforce these claims and should be moved to a version that does. Independently of version, restrict the JWT keystore to the smallest possible trust set - ideally a signer dedicated to this service rather than a shared identity-provider key - and where a gateway already validates issuer and audience in front of the server, ensure it cannot be bypassed.\n\nNotes:\n\nThe JIRA ticket:\u00a0 https://issues.apache.org/jira/browse/CAMEL-24281 \u00a0refers to the various commits that resolved the issue, and has more details.\n\nThe fail-closed guard could not be backported. The jwtIssuer and jwtAudience options were themselves only introduced in 4.21.0 by CAMEL-23525, so on camel-4.18.x and camel-4.14.x there was nothing an operator could set to satisfy the requirement and the guard would have broken every JWT deployment on those branches with no remedy available.",
"id": "GHSA-fpm2-m4qq-wghr",
"modified": "2026-08-28T21:56:58Z",
"published": "2026-08-24T18:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66908"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/25187"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/25195"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/25196"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/23c6bbf0e026277f03732481f780b9f18044792b"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/4dbb9387102c102ab207e61c8307a3eaaeec7fcf"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/a69ff2b4504f9f10d6af6c6837142da6f076bdeb"
},
{
"type": "WEB",
"url": "https://camel.apache.org/security/CVE-2026-66908.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/camel"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/releases/tag/camel-4.22.0"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/CAMEL-24281"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/24/12"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Apache Camel-platform-http-main: when JWT authentication was configured with a keystore but no issuer or audience, the iss and aud claims were never validated, so any unexpired token signed by a trusted key was accepted"
}
GHSA-FPM5-5F53-975W
Vulnerability from github – Published: 2022-01-25 00:01 – Updated: 2023-08-08 15:31An issue was discovered in Saviynt Enterprise Identity Cloud (EIC) 5.5 SP2.x. An authentication bypass in ECM/maintenance/forgotpasswordstep1 allows an unauthenticated user to reset passwords and login as any local account.
{
"affected": [],
"aliases": [
"CVE-2022-23855"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-24T02:15:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in Saviynt Enterprise Identity Cloud (EIC) 5.5 SP2.x. An authentication bypass in ECM/maintenance/forgotpasswordstep1 allows an unauthenticated user to reset passwords and login as any local account.",
"id": "GHSA-fpm5-5f53-975w",
"modified": "2023-08-08T15:31:37Z",
"published": "2022-01-25T00:01:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23855"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/692873"
}
],
"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-FPP6-XW3R-CJJX
Vulnerability from github – Published: 2022-05-13 01:31 – Updated: 2022-05-13 01:31In ATI Systems Emergency Mass Notification Systems (HPSS16, HPSS32, MHPSS, and ALERT4000) devices, an improper authentication vulnerability caused by specially crafted malicious radio transmissions may allow an attacker to remotely trigger false alarms.
{
"affected": [],
"aliases": [
"CVE-2018-8862"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-05-25T16:29:00Z",
"severity": "LOW"
},
"details": "In ATI Systems Emergency Mass Notification Systems (HPSS16, HPSS32, MHPSS, and ALERT4000) devices, an improper authentication vulnerability caused by specially crafted malicious radio transmissions may allow an attacker to remotely trigger false alarms.",
"id": "GHSA-fpp6-xw3r-cjjx",
"modified": "2022-05-13T01:31:44Z",
"published": "2022-05-13T01:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-8862"
},
{
"type": "WEB",
"url": "https://ics-cert.us-cert.gov/advisories/ICSA-18-100-01"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/103721"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FPPR-HP57-7WWW
Vulnerability from github – Published: 2022-05-24 17:43 – Updated: 2022-05-24 17:43An issue was discovered in channels/chan_sip.c in Sangoma Asterisk through 13.29.1, through 16.6.1, and through 17.0.0; and Certified Asterisk through 13.21-cert4. A SIP request can be sent to Asterisk that can change a SIP peer's IP address. A REGISTER does not need to occur, and calls can be hijacked as a result. The only thing that needs to be known is the peer's name; authentication details such as passwords do not need to be known. This vulnerability is only exploitable when the nat option is set to the default, or auto_force_rport.
{
"affected": [],
"aliases": [
"CVE-2019-18351"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-05T02:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in channels/chan_sip.c in Sangoma Asterisk through 13.29.1, through 16.6.1, and through 17.0.0; and Certified Asterisk through 13.21-cert4. A SIP request can be sent to Asterisk that can change a SIP peer\u0027s IP address. A REGISTER does not need to occur, and calls can be hijacked as a result. The only thing that needs to be known is the peer\u0027s name; authentication details such as passwords do not need to be known. This vulnerability is only exploitable when the nat option is set to the default, or auto_force_rport.",
"id": "GHSA-fppr-hp57-7www",
"modified": "2022-05-24T17:43:43Z",
"published": "2022-05-24T17:43:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18351"
},
{
"type": "WEB",
"url": "https://www.asterisk.org/downloads/security-advisories"
},
{
"type": "WEB",
"url": "http://downloads.asterisk.org/pub/security/AST-2019-006.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FPQ3-C96F-26MV
Vulnerability from github – Published: 2025-03-18 15:30 – Updated: 2025-03-21 18:31An issue was discovered on the Forvia Hella HELLA Driving Recorder DR 820. Bypassing of Device Pairing can occur. The pairing mechanism relies solely on the connecting device's MAC address. By obtaining the MAC address through network scanning and spoofing it, an attacker can bypass the authentication process and gain full access to the dashcam's features without proper authorization.
{
"affected": [],
"aliases": [
"CVE-2025-30114"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-18T15:16:02Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered on the Forvia Hella HELLA Driving Recorder DR 820. Bypassing of Device Pairing can occur. The pairing mechanism relies solely on the connecting device\u0027s MAC address. By obtaining the MAC address through network scanning and spoofing it, an attacker can bypass the authentication process and gain full access to the dashcam\u0027s features without proper authorization.",
"id": "GHSA-fpq3-c96f-26mv",
"modified": "2025-03-21T18:31:34Z",
"published": "2025-03-18T15:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30114"
},
{
"type": "WEB",
"url": "https://github.com/geo-chen/Hella"
},
{
"type": "WEB",
"url": "https://medium.com/@geochen/cve-draft-hella-driving-recorder-dr-820-ff8c4e2cca26"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FPQ6-PGWP-7MR7
Vulnerability from github – Published: 2022-06-16 00:00 – Updated: 2022-06-25 00:00AriaNg v0.1.0~v1.2.2 is affected by an incorrect access control vulnerability through not authenticating visitors' access rights.
{
"affected": [],
"aliases": [
"CVE-2021-41418"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-15T20:15:00Z",
"severity": "CRITICAL"
},
"details": "AriaNg v0.1.0~v1.2.2 is affected by an incorrect access control vulnerability through not authenticating visitors\u0027 access rights.",
"id": "GHSA-fpq6-pgwp-7mr7",
"modified": "2022-06-25T00:00:54Z",
"published": "2022-06-16T00:00:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41418"
},
{
"type": "WEB",
"url": "https://github.com/Amozing/Am0zang/issues/1"
}
],
"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-FPR5-99X5-V6HH
Vulnerability from github – Published: 2022-05-24 17:46 – Updated: 2022-05-24 17:46Learnsite 1.2.5.0 contains a remote privilege escalation vulnerability in /Manager/index.aspx through the JudgIsAdmin() function. By modifying the initial letter of the key of a user cookie, the key of the administrator cookie can be obtained.
{
"affected": [],
"aliases": [
"CVE-2021-27522"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-08T16:15:00Z",
"severity": "HIGH"
},
"details": "Learnsite 1.2.5.0 contains a remote privilege escalation vulnerability in /Manager/index.aspx through the JudgIsAdmin() function. By modifying the initial letter of the key of a user cookie, the key of the administrator cookie can be obtained.",
"id": "GHSA-fpr5-99x5-v6hh",
"modified": "2022-05-24T17:46:53Z",
"published": "2022-05-24T17:46:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27522"
},
{
"type": "WEB",
"url": "https://github.com/WaterCountry/Learnsite/issues/1"
}
],
"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-FPRH-9V79-9PWF
Vulnerability from github – Published: 2022-05-13 00:00 – Updated: 2022-05-22 00:00Improper access control in the Intel(R) In-Band Manageability software before version 2.13.0 may allow a privileged user to potentially enable escalation of privilege via network access.
{
"affected": [],
"aliases": [
"CVE-2021-0194"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-12T17:15:00Z",
"severity": "HIGH"
},
"details": "Improper access control in the Intel(R) In-Band Manageability software before version 2.13.0 may allow a privileged user to potentially enable escalation of privilege via network access.",
"id": "GHSA-fprh-9v79-9pwf",
"modified": "2022-05-22T00:00:35Z",
"published": "2022-05-13T00:00:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0194"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00549.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FPVW-6M5V-HQFP
Vulnerability from github – Published: 2023-11-24 16:53 – Updated: 2023-11-27 22:07The privilege escalation is based on a missing check if the user is authenticated based on the TokenReview result.
All the clusters running with the anonymous-auth Kubernetes API Server setting disable (set to false) are affected since it would be possible to bypass the token review mechanism, interacting with the upper Kubernetes API Server.
PoC
Start a KinD cluster with the anonymous-auth value to false.
If it is true, it uses anonymous permissions which are very limited by default
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
kubeadmConfigPatches:
- |
kind: ClusterConfiguration
apiServer:
extraArgs:
anonymous-auth: "false"
Install capsule and capsule-proxy
k port-forward svc/capsule-proxy 9001
Forwarding from 127.0.0.1:9001 -> 9001
Forwarding from [::1]:9001 -> 9001
Handling connection for 9001
Then query the proxy
curl -g -k -H 'Authorization: Bearer f' -X 'GET' 'https://localhost:9001/api/v1/namespaces'
Impact
The whole cluster is exposed to unauthorised users.
This privilege escalation cannot be exploited if you're relying only on client certificates (SSL/TLS).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.4.5"
},
"package": {
"ecosystem": "Go",
"name": "github.com/projectcapsule/capsule-proxy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.4.5"
},
"package": {
"ecosystem": "Go",
"name": "github.com/clastix/capsule-proxy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-48312"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-24T16:53:25Z",
"nvd_published_at": "2023-11-24T18:15:07Z",
"severity": "CRITICAL"
},
"details": "The privilege escalation is based on a missing check if the user is authenticated based on the `TokenReview` result.\n\nAll the clusters running with the `anonymous-auth` Kubernetes API Server setting disable (set to `false`) are affected since it would be possible to bypass the token review mechanism, interacting with the upper Kubernetes API Server.\n\n# PoC\n\nStart a KinD cluster with the `anonymous-auth` value to `false`. \nIf it is true, it uses anonymous permissions which are very limited by default\n\n```yaml\nkind: Cluster\napiVersion: kind.x-k8s.io/v1alpha4\nnodes:\n- role: control-plane\n kubeadmConfigPatches:\n - |\n kind: ClusterConfiguration\n apiServer:\n extraArgs:\n anonymous-auth: \"false\"\n```\n\nInstall `capsule` and `capsule-proxy`\n\n```\nk port-forward svc/capsule-proxy 9001 \nForwarding from 127.0.0.1:9001 -\u003e 9001\nForwarding from [::1]:9001 -\u003e 9001\nHandling connection for 9001\n```\n\nThen query the proxy\n```\ncurl -g -k -H \u0027Authorization: Bearer f\u0027 -X \u0027GET\u0027 \u0027https://localhost:9001/api/v1/namespaces\u0027\n```\n\n# Impact\n\nThe whole cluster is exposed to unauthorised users.\n\nThis privilege escalation cannot be exploited if you\u0027re relying only on client certificates (SSL/TLS).",
"id": "GHSA-fpvw-6m5v-hqfp",
"modified": "2023-11-27T22:07:37Z",
"published": "2023-11-24T16:53:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/projectcapsule/capsule-proxy/security/advisories/GHSA-fpvw-6m5v-hqfp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48312"
},
{
"type": "WEB",
"url": "https://github.com/projectcapsule/capsule-proxy/commit/472404f7006a4152e4eec76dee07324dd1e6e823"
},
{
"type": "PACKAGE",
"url": "https://github.com/projectcapsule/capsule-proxy"
}
],
"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": "Capsule Proxy Authentication bypass using an empty token"
}
GHSA-FPX3-PCR2-8RVR
Vulnerability from github – Published: 2022-05-24 17:46 – Updated: 2022-05-24 17:46The Plus Addons for Elementor Page Builder WordPress plugin before 4.1.7 was being actively exploited to by malicious actors to bypass authentication, allowing unauthenticated users to log in as any user (including admin) by just providing the related username, as well as create accounts with arbitrary roles, such as admin. These issues can be exploited even if registration is disabled, and the Login widget is not active.
{
"affected": [],
"aliases": [
"CVE-2021-24175"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-05T19:15:00Z",
"severity": "CRITICAL"
},
"details": "The Plus Addons for Elementor Page Builder WordPress plugin before 4.1.7 was being actively exploited to by malicious actors to bypass authentication, allowing unauthenticated users to log in as any user (including admin) by just providing the related username, as well as create accounts with arbitrary roles, such as admin. These issues can be exploited even if registration is disabled, and the Login widget is not active.",
"id": "GHSA-fpx3-pcr2-8rvr",
"modified": "2022-05-24T17:46:32Z",
"published": "2022-05-24T17:46:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-24175"
},
{
"type": "WEB",
"url": "https://posimyth.ticksy.com/ticket/2713734"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/c311feef-7041-4c21-9525-132b9bd32f89"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/blog/2021/03/critical-0-day-in-the-plus-addons-for-elementor-allows-site-takeover"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
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.