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.
6783 vulnerabilities reference this CWE, most recent first.
GHSA-FPGF-PJJV-2QGM
Vulnerability from github – Published: 2022-09-30 04:37 – Updated: 2022-09-30 04:37Impact
An attacker cooperating with a malicious homeserver can construct messages that legitimately appear to have come from another person, without any indication such as a grey shield.
Additionally, a sophisticated attacker cooperating with a malicious homeserver could employ this vulnerability to perform a targeted attack in order to send fake to-device messages appearing to originate from another user. This can allow, for example, to inject the key backup secret during a self-verification, to make a targeted device start using a malicious key backup spoofed by the homeserver. matrix-android-sdk2 would then additionally sign such a key backup with its device key, spilling trust over to other devices trusting the matrix-android-sdk2 device.
These attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm.
Patches
matrix-android-sdk2 has been modified to only accept Olm-encrypted to-device messages and to stop signing backups on a successful decryption.
Out of caution, several other checks have been audited or added:
- Cleartext m.room_key, m.forwarded_room_key and m.secret.send to_device messages are discarded.
- Secrets received from untrusted devices are discarded.
- Key backups are only usable if they have a valid signature from a trusted device (no more local trust, or trust-on-decrypt).
- The origin of a to-device message should only be determined by observing the Olm session which managed to decrypt the message, and not by using claimed sender_key, user_id, or any other fields controllable by the homeserver.
Workarounds
As this attack requires coordination between a malicious home server and an attacker, if you trust your home server no particular workaround is needed. Notice that the backup spoofing attack is a particularly sophisticated targeted attack.
We are not aware of this attack being used in the wild, though specifying a false positive-free way of noticing malicious key backups key is challenging.
As an abundance of caution, to avoid malicious backup attacks, you should not verify your new logins using emoji/QR verifications methods until patched. Prefer using verify with passphrase.
References
Blog post: https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients
For more information
If you have any questions or comments about this advisory, e-mail us at security@matrix.org.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.4.36"
},
"package": {
"ecosystem": "Maven",
"name": "org.matrix.android:matrix-android-sdk2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-39248"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-322"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-30T04:37:39Z",
"nvd_published_at": "2022-09-28T20:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\nAn attacker cooperating with a malicious homeserver can construct messages that legitimately appear to have come from another person, without any indication such as a grey shield. \n\nAdditionally, a sophisticated attacker cooperating with a malicious homeserver could employ this vulnerability to perform a targeted attack in order to send fake to-device messages appearing to originate from another user. This can allow, for example, to inject the key backup secret during a self-verification, to make a targeted device start using a malicious key backup spoofed by the homeserver. matrix-android-sdk2 would then additionally sign such a key backup with its device key, spilling trust over to other devices trusting the matrix-android-sdk2 device.\n\nThese attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm.\n\n### Patches\n\nmatrix-android-sdk2 has been modified to only accept Olm-encrypted to-device messages and to stop signing backups on a successful decryption.\n\nOut of caution, several other checks have been audited or added:\n- Cleartext `m.room_key`, `m.forwarded_room_key` and `m.secret.send` to_device messages are discarded.\n- Secrets received from untrusted devices are discarded.\n- Key backups are only usable if they have a valid signature from a trusted device (no more local trust, or trust-on-decrypt).\n- The origin of a to-device message should only be determined by observing the Olm session which managed to decrypt the message, and not by using claimed sender_key, user_id, or any other fields controllable by the homeserver.\n\n\n### Workarounds\n\nAs this attack requires coordination between a malicious home server and an attacker, if you trust your home server no particular workaround is needed. Notice that the backup spoofing attack is a particularly sophisticated targeted attack.\n\nWe are not aware of this attack being used in the wild, though specifying a false positive-free way of noticing malicious key backups key is challenging.\n\nAs an abundance of caution, to avoid malicious backup attacks, you should not verify your new logins using emoji/QR verifications methods until patched. Prefer using verify with passphrase.\n\n\n### References\nBlog post: https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients\n\n### For more information\nIf you have any questions or comments about this advisory, e-mail us at [security@matrix.org](mailto:security@matrix.org).\n",
"id": "GHSA-fpgf-pjjv-2qgm",
"modified": "2022-09-30T04:37:39Z",
"published": "2022-09-30T04:37:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-android-sdk2/security/advisories/GHSA-fpgf-pjjv-2qgm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39248"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-android-sdk2/commit/77df720a238d17308deab83ecaa37f7a4740a17e"
},
{
"type": "PACKAGE",
"url": "https://github.com/matrix-org/matrix-android-sdk2"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-android-sdk2/releases/tag/v1.5.1"
},
{
"type": "WEB",
"url": "https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "matrix-android-sdk2 vulnerable to Olm/Megolm protocol confusion"
}
GHSA-FPGP-7GXR-QX3Q
Vulnerability from github – Published: 2026-07-30 06:32 – Updated: 2026-07-30 15:31The Customer Switching WordPress plugin before 2.1.3 does not securely bind an active user-switching session to the operator who initiated it, allowing a lower-privileged account that an operator is currently switched into to be resolved as that operator and to switch into any permitted account, including an administrator, resulting in full account takeover.
{
"affected": [],
"aliases": [
"CVE-2026-15240"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-30T06:25:01Z",
"severity": "HIGH"
},
"details": "The Customer Switching WordPress plugin before 2.1.3 does not securely bind an active user-switching session to the operator who initiated it, allowing a lower-privileged account that an operator is currently switched into to be resolved as that operator and to switch into any permitted account, including an administrator, resulting in full account takeover.",
"id": "GHSA-fpgp-7gxr-qx3q",
"modified": "2026-07-30T15:31:47Z",
"published": "2026-07-30T06:32:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15240"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/4e5b9e2a-c8e0-41db-a989-1b44bc76c9d8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FPGQ-QV2C-6787
Vulnerability from github – Published: 2022-05-24 16:52 – Updated: 2023-02-02 21:33A vulnerability exists in the garbage collection mechanism of atomic-openshift. An attacker able spoof the UUID of a valid object from another namespace is able to delete children of those objects. Versions 3.6, 3.7, 3.8, 3.9, 3.10, 3.11 and 4.1 are affected.
{
"affected": [],
"aliases": [
"CVE-2019-3884"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-01T14:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability exists in the garbage collection mechanism of atomic-openshift. An attacker able spoof the UUID of a valid object from another namespace is able to delete children of those objects. Versions 3.6, 3.7, 3.8, 3.9, 3.10, 3.11 and 4.1 are affected.",
"id": "GHSA-fpgq-qv2c-6787",
"modified": "2023-02-02T21:33:43Z",
"published": "2022-05-24T16:52:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3884"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:5634"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2019-3884"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1693905"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3884"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-FPJM-RP2G-3R4C
Vulnerability from github – Published: 2020-06-05 16:09 – Updated: 2024-09-20 17:05An issue was discovered in drf-jwt 1.15.x before 1.15.1. It allows attackers with access to a notionally invalidated token to obtain a new, working token via the refresh endpoint, because the blacklist protection mechanism is incompatible with the token-refresh feature. NOTE: drf-jwt is a fork of jpadilla/django-rest-framework-jwt, which is unmaintained.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "drf-jwt"
},
"ranges": [
{
"events": [
{
"introduced": "1.15.0"
},
{
"fixed": "1.15.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-10594"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-04T18:38:20Z",
"nvd_published_at": "2020-03-15T22:15:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in drf-jwt 1.15.x before 1.15.1. It allows attackers with access to a notionally invalidated token to obtain a new, working token via the refresh endpoint, because the blacklist protection mechanism is incompatible with the token-refresh feature. NOTE: drf-jwt is a fork of jpadilla/django-rest-framework-jwt, which is unmaintained.",
"id": "GHSA-fpjm-rp2g-3r4c",
"modified": "2024-09-20T17:05:27Z",
"published": "2020-06-05T16:09:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10594"
},
{
"type": "WEB",
"url": "https://github.com/Styria-Digital/django-rest-framework-jwt/issues/36"
},
{
"type": "WEB",
"url": "https://github.com/jpadilla/django-rest-framework-jwt/issues/484"
},
{
"type": "WEB",
"url": "https://github.com/Styria-Digital/django-rest-framework-jwt/commit/868b5c22ddad59772b447080183e7c7101bb18e0"
},
{
"type": "PACKAGE",
"url": "https://github.com/Styria-Digital/django-rest-framework-jwt"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-fpjm-rp2g-3r4c"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/drf-jwt/PYSEC-2020-40.yaml"
},
{
"type": "WEB",
"url": "https://pypi.org/project/drf-jwt/1.15.1/#history"
}
],
"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"
},
{
"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": "Django Rest Framework jwt allows obtaining new token from notionally invalidated token"
}
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"
}
]
}
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.