CWE-290
AllowedAuthentication Bypass by Spoofing
Abstraction: Base · Status: Incomplete
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
925 vulnerabilities reference this CWE, most recent first.
GHSA-W252-645G-87MP
Vulnerability from github – Published: 2025-09-16 01:54 – Updated: 2025-09-16 01:54Summary
Identity spoofing in X.509 client certificate authentication in Openfire allows internal attackers to impersonate other users via crafted certificate subject attributes, due to regex-based extraction of CN from an unescaped, provider-dependent DN string.
Analysis
Openfire’s SASL EXTERNAL mechanism for client TLS authentication contains a vulnerability in how it extracts user identities from X.509 certificates. Instead of parsing the structured ASN.1 data, the code calls X509Certificate.getSubjectDN().getName() and applies a regex to look for CN=. This method produces a provider-dependent string that does not escape special characters. In SunJSSE (sun.security.x509.X500Name), for example, commas and equals signs inside attribute values are not escaped.
As a result, a malicious certificate can embed CN= inside another attribute value (e.g. OU="CN=admin,"). The regex will incorrectly interpret this as a legitimate Common Name and extract admin. If SASL EXTERNAL is enabled and configured to map CNs to user accounts, this allows the attacker to impersonate another user.
Impact
When there is no explicit configuration override, Openfire defaults to using certificate attributes as follows:
- Server-to-server certificates: first the Subject Alternative Name (SAN), and if that is not available, the Common Name (CN).
- Client-to-server certificates: only the Common Name (CN).
Use of CN for identity mapping was phased out by the CA/Browser Forum. CAB Forum-compliant CAs no longer allow arbitrary Subject RDNs and always include SANs. As a result, certificates issued by public CAs for use on the open Internet are unlikely to be exploitable, though older certificates still within their validity period could theoretically be abused.
The primary risks exist in private CA environments and client certificate authentication, where identity mapping may rely solely on the CN. Both of these are niche deployment scenarios.
Patches
The path has been prepared by replacing the use of getSubjectDN().getName() with standards-compliant LdapName parsing of the RFC2253 representation of X500Principal. This avoids unescaped provider-dependent strings and prevents regex from matching malicious substrings.
The fix is included in Openfire 5.0.2 and 5.1.0. Users should upgrade to this version as soon as it becomes available.
Starting in Openfire 5.0.2, Openfire will by default prefer a Subject Alternative Name-based identity over a Common Name based one for client-to-server authentication (issue OF-3123). For server-to-server authentication, this already is the case.
In Openfire 5.1.0, Openfire will no longer, by default, use Common Name based identities, although this functionality can be restored through configuration changes (issue OF-3122).
Workarounds
The vulnerability is fixed in the upcoming release, but there are operational mitigations you can apply today.
Full workaround (drop-in replacement JAR using the fixed mapper)
This is a complete workaround:
1. Take the fixed mapper implementation (the code that uses LdapName / RFC2253 parsing) from the patched Openfire source.
2. Create a new Java class in your proprietary namespace (for example com.acme.openfire.SafeCNCertificateIdentityMapping) that implements the same Openfire certificate-identity mapping interface and contains the fixed parsing logic. Ensure the logic exactly mirrors the patched behavior (use X500Principal.getName() with RFC2253 and javax.naming.ldap.LdapName to parse RDNs, do not rely on getSubjectDN().getName() or provider-dependent strings).
3. Package the class into a JAR file.
4. Place the JAR into Openfire’s lib/ directory (e.g. $OPENFIRE_HOME/lib/your-fixed-mapper.jar).
5. Configure Openfire to use your class for mapping by setting the following properties (in the admin console / system properties). Note that it remains advisable to configure Openfire to keep preferring SAN-based identities:
# For server-to-server identity mapping
provider.serverCertIdentityMap.classList=org.jivesoftware.util.cert.SANCertificateIdentityMapping,com.acme.openfire.SafeCNCertificateIdentityMapping
# For client-to-server identity mapping
provider.clientCertIdentityMap.classList=org.jivesoftware.util.cert.SANCertificateIdentityMapping,com.acme.openfire.SafeCNCertificateIdentityMapping
Both properties accept a comma-separated list of fully-qualified class names; listing only your safe mapper forces Openfire to use your implementation instead of the vulnerable built-in mapper. After placing the JAR and updating properties, restart Openfire.
Notes & caveats for the full workaround
- This is effectively a complete mitigation for the vulnerable CN-extraction behavior without deploying a new official release.
- Maintain the JAR: you are responsible for keeping the custom class updated if you upgrade Openfire to newer major versions.
- Ensure your custom mapper truly implements the patched parsing (do not copy the vulnerable
getSubjectDN().getName()+ regex approach). UseX500Principal→getName(RFC2253)→new LdapName(...)→ iterate RDNs in a robust way. - Because this runs in the Openfire JVM, follow your organization’s binary-signing and review policies before deploying.
Other, lesser workarounds
Use SAN-only mapping
Configure the mapper list to only include Openfire’s SAN mapper: org.jivesoftware.util.cert.SANCertificateIdentityMapping. This prevents CN parsing-based spoofing but breaks authentication for certificates that contain only a CN and no SAN.
Disable certificate-based authentication:
- For server-to-server, disabling certificate auth leaves only Server Dialback, which is less secure; depending on your environment, this may be a worse trade-off.
- For client-to-server, disable “mutual authentication” in the admin console to stop client cert authentication altogether.
References
- Openfire issue tracker: OF-3124: Potential identity spoofing via unsafe CN parsing
- Affected code: CNCertificateIdentityMapping.java#L43
- Openfire issue tracker: OF-3122: Stop by default using Common Name based identities
- Openfire issue tracker: OF-3123: For client mutual authentication, prefer Subject Alternative Name for identities
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.igniterealtime.openfire:xmppserver"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-59154"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-16T01:54:24Z",
"nvd_published_at": "2025-09-15T20:15:39Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nIdentity spoofing in X.509 client certificate authentication in Openfire allows internal attackers to impersonate other users via crafted certificate subject attributes, due to regex-based extraction of CN from an unescaped, provider-dependent DN string.\n\n## Analysis\n\nOpenfire\u2019s SASL EXTERNAL mechanism for client TLS authentication contains a vulnerability in how it extracts user identities from X.509 certificates. Instead of parsing the structured ASN.1 data, the code calls `X509Certificate.getSubjectDN().getName()` and applies a regex to look for `CN=`. This method produces a provider-dependent string that does not escape special characters. In SunJSSE (`sun.security.x509.X500Name`), for example, commas and equals signs inside attribute values are not escaped.\n\nAs a result, a malicious certificate can embed `CN=` inside another attribute value (e.g. `OU=\"CN=admin,\"`). The regex will incorrectly interpret this as a legitimate Common Name and extract admin. If SASL EXTERNAL is enabled and configured to map CNs to user accounts, this allows the attacker to impersonate another user.\n\n## Impact\n\nWhen there is no explicit configuration override, Openfire defaults to using certificate attributes as follows:\n\n- Server-to-server certificates: first the Subject Alternative Name (SAN), and if that is not available, the Common Name (CN).\n- Client-to-server certificates: only the Common Name (CN).\n\nUse of CN for identity mapping was phased out by the CA/Browser Forum. CAB Forum-compliant CAs no longer allow arbitrary Subject RDNs and always include SANs. As a result, certificates issued by public CAs for use on the open Internet are unlikely to be exploitable, though older certificates still within their validity period could theoretically be abused.\n\nThe primary risks exist in private CA environments and client certificate authentication, where identity mapping may rely solely on the CN. Both of these are niche deployment scenarios.\n\n## Patches\n\nThe path has been prepared by replacing the use of `getSubjectDN().getName()` with standards-compliant `LdapName` parsing of the RFC2253 representation of `X500Principal`. This avoids unescaped provider-dependent strings and prevents regex from matching malicious substrings. \n\nThe fix is included in Openfire 5.0.2 and 5.1.0. Users should upgrade to this version as soon as it becomes available. \n\nStarting in Openfire 5.0.2, Openfire will by default prefer a Subject Alternative Name-based identity over a Common Name based one for client-to-server authentication (issue OF-3123). For server-to-server authentication, this already is the case.\n\nIn Openfire 5.1.0, Openfire will no longer, by default, use Common Name based identities, although this functionality can be restored through configuration changes (issue OF-3122).\n \n## Workarounds\n\nThe vulnerability is fixed in the upcoming release, but there are operational mitigations you can apply today.\n\n### Full workaround (drop-in replacement JAR using the fixed mapper)\n _This is a complete workaround:_\n1. Take the fixed mapper implementation (the code that uses LdapName / RFC2253 parsing) from the patched Openfire source.\n2. Create a new Java class in your proprietary namespace (for example `com.acme.openfire.SafeCNCertificateIdentityMapping`) that implements the same Openfire certificate-identity mapping interface and contains the fixed parsing logic. Ensure the logic exactly mirrors the patched behavior (use `X500Principal.getName()` with RFC2253 and `javax.naming.ldap.LdapName` to parse RDNs, do not rely on `getSubjectDN().getName()` or provider-dependent strings).\n3. Package the class into a JAR file.\n4. Place the JAR into Openfire\u2019s lib/ directory (e.g. `$OPENFIRE_HOME/lib/your-fixed-mapper.jar`).\n5. Configure Openfire to use your class for mapping by setting the following properties (in the admin console / system properties). Note that it remains advisable to configure Openfire to keep preferring SAN-based identities:\n```\n# For server-to-server identity mapping\nprovider.serverCertIdentityMap.classList=org.jivesoftware.util.cert.SANCertificateIdentityMapping,com.acme.openfire.SafeCNCertificateIdentityMapping\n\n# For client-to-server identity mapping\nprovider.clientCertIdentityMap.classList=org.jivesoftware.util.cert.SANCertificateIdentityMapping,com.acme.openfire.SafeCNCertificateIdentityMapping\n```\nBoth properties accept a comma-separated list of fully-qualified class names; listing only your safe mapper forces Openfire to use your implementation instead of the vulnerable built-in mapper. After placing the JAR and updating properties, *restart Openfire*.\n\n**Notes \u0026 caveats for the full workaround**\n\n- This is effectively a complete mitigation for the vulnerable CN-extraction behavior without deploying a new official release.\n- Maintain the JAR: you are responsible for keeping the custom class updated if you upgrade Openfire to newer major versions.\n- Ensure your custom mapper truly implements the patched parsing (do not copy the vulnerable `getSubjectDN().getName()` + regex approach). Use `X500Principal` \u2192 `getName(RFC2253)` \u2192 `new LdapName(...)` \u2192 iterate RDNs in a robust way.\n- Because this runs in the Openfire JVM, follow your organization\u2019s binary-signing and review policies before deploying.\n\n### Other, lesser workarounds\n\n#### Use SAN-only mapping\nConfigure the mapper list to only include Openfire\u2019s SAN mapper: `org.jivesoftware.util.cert.SANCertificateIdentityMapping`. This prevents CN parsing-based spoofing but breaks authentication for certificates that contain only a CN and no SAN.\n\n#### Disable certificate-based authentication:\n- For server-to-server, disabling certificate auth leaves only Server Dialback, which is less secure; depending on your environment, this may be a worse trade-off.\n- For client-to-server, disable \u201cmutual authentication\u201d in the admin console to stop client cert authentication altogether.\n\n## References\n\n- Openfire issue tracker: [OF-3124: Potential identity spoofing via unsafe CN parsing](https://igniterealtime.atlassian.net/browse/OF-3124)\n- Affected code: [CNCertificateIdentityMapping.java#L43](https://github.com/igniterealtime/Openfire/blob/8d073dda36905da0fdee7cb623c025a01a5cbf6b/xmppserver/src/main/java/org/jivesoftware/util/cert/CNCertificateIdentityMapping.java#L43) \n- Openfire issue tracker: [OF-3122: Stop by default using Common Name based identities](https://igniterealtime.atlassian.net/browse/OF-3122)\n- Openfire issue tracker: [OF-3123: For client mutual authentication, prefer Subject Alternative Name for identities](https://igniterealtime.atlassian.net/browse/OF-3123)",
"id": "GHSA-w252-645g-87mp",
"modified": "2025-09-16T01:54:24Z",
"published": "2025-09-16T01:54:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/igniterealtime/Openfire/security/advisories/GHSA-w252-645g-87mp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59154"
},
{
"type": "PACKAGE",
"url": "https://github.com/igniterealtime/Openfire"
},
{
"type": "WEB",
"url": "https://github.com/igniterealtime/Openfire/blob/8d073dda36905da0fdee7cb623c025a01a5cbf6b/xmppserver/src/main/java/org/jivesoftware/util/cert/CNCertificateIdentityMapping.java#L43"
},
{
"type": "WEB",
"url": "https://igniterealtime.atlassian.net/browse/OF-3122"
},
{
"type": "WEB",
"url": "https://igniterealtime.atlassian.net/browse/OF-3123"
},
{
"type": "WEB",
"url": "https://igniterealtime.atlassian.net/browse/OF-3124"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Openfire has potential identity spoofing issue via unsafe CN parsing"
}
GHSA-W3H5-P6V5-5VJM
Vulnerability from github – Published: 2024-07-03 18:48 – Updated: 2024-07-03 18:48Security check loophole in HAProxy release (in combination with routing release) in Cloud Foundry prior to v40.17.0 potentially allows bypass of mTLS authentication to applications hosted on Cloud Foundry.
{
"affected": [],
"aliases": [
"CVE-2024-37082"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-03T06:15:03Z",
"severity": "CRITICAL"
},
"details": "Security check loophole in HAProxy release (in combination with routing release) in Cloud Foundry prior to v40.17.0 potentially allows bypass of mTLS authentication to applications hosted on Cloud Foundry.",
"id": "GHSA-w3h5-p6v5-5vjm",
"modified": "2024-07-03T18:48:04Z",
"published": "2024-07-03T18:48:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37082"
},
{
"type": "WEB",
"url": "https://www.cloudfoundry.org/blog/cve-2024-37082-mtls-bypass"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W3JX-33QH-77F8
Vulnerability from github – Published: 2024-01-12 03:30 – Updated: 2024-01-12 03:30ELAN Match-on-Chip FPR solution has design fault about potential risk of valid SID leakage and enumeration with spoof sensor. This fault leads to that Windows Hello recognition would be bypass with cloning SID to cause broken account identity. Version which is lower than 3.0.12011.08009(Legacy)/3.3.12011.08103(ESS) would suffer this risk on DELL Inspiron platform.
{
"affected": [],
"aliases": [
"CVE-2024-0454"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-12T02:15:44Z",
"severity": "MODERATE"
},
"details": "ELAN Match-on-Chip FPR solution has design fault about potential risk of valid SID leakage and enumeration with spoof sensor.\nThis fault leads to that Windows Hello recognition would be bypass with cloning SID to cause broken account identity.\nVersion which is lower than 3.0.12011.08009(Legacy)/3.3.12011.08103(ESS) would suffer this risk on DELL Inspiron platform.",
"id": "GHSA-w3jx-33qh-77f8",
"modified": "2024-01-12T03:30:49Z",
"published": "2024-01-12T03:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0454"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-w3jx-33qh-77f8"
},
{
"type": "WEB",
"url": "https://www.emc.com.tw/emc/tw/vulnerability-disclosure-policy"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-W3MG-G64H-4H34
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2023-08-02 00:30Microsoft Exchange Server Remote Code Execution Vulnerability This CVE ID is unique from CVE-2021-31198.
{
"affected": [],
"aliases": [
"CVE-2021-31195"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-11T19:15:00Z",
"severity": "HIGH"
},
"details": "Microsoft Exchange Server Remote Code Execution Vulnerability This CVE ID is unique from CVE-2021-31198.",
"id": "GHSA-w3mg-g64h-4h34",
"modified": "2023-08-02T00:30:32Z",
"published": "2022-05-24T19:02:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31195"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-31195"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W3VW-MGPX-6MJP
Vulnerability from github – Published: 2022-05-13 01:20 – Updated: 2022-05-13 01:20A spoofing vulnerability exists in Microsoft Exchange Server when Outlook Web Access (OWA) fails to properly handle web requests, aka "Microsoft Exchange Spoofing Vulnerability." This affects Microsoft Exchange Server.
{
"affected": [],
"aliases": [
"CVE-2018-8153"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-05-09T19:29:00Z",
"severity": "MODERATE"
},
"details": "A spoofing vulnerability exists in Microsoft Exchange Server when Outlook Web Access (OWA) fails to properly handle web requests, aka \"Microsoft Exchange Spoofing Vulnerability.\" This affects Microsoft Exchange Server.",
"id": "GHSA-w3vw-mgpx-6mjp",
"modified": "2022-05-13T01:20:41Z",
"published": "2022-05-13T01:20:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-8153"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8153"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/104045"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1040850"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W3WF-CFX3-6GCX
Vulnerability from github – Published: 2022-02-11 23:59 – Updated: 2022-02-11 23:59Impact
Due to issues in Go's standard library XML parsing, a valid SAML response may be mutated by an attacker to modify the trusted document. This can result in allowing unverified logins from a SAML IdP.
Users that configure Fleet with SSO login may be vulnerable to this issue.
Patches
This issue is patched in 3.5.1 using https://github.com/mattermost/xml-roundtrip-validator.
Workarounds
If upgrade to 3.5.1 is not possible, users should disable SSO authentication in Fleet.
References
See https://mattermost.com/blog/coordinated-disclosure-go-xml-vulnerabilities/ for more information about the underlying vulnerabilities.
For more information
If you have any questions or comments about this advisory: * Email us at security@fleetdm.com * Join #fleet in osquery Slack
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/fleetdm/fleet/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-26276"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-21T20:46:21Z",
"nvd_published_at": "2020-12-17T20:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\nDue to issues in Go\u0027s standard library XML parsing, a valid SAML response may be mutated by an attacker to modify the trusted document. This can result in allowing unverified logins from a SAML IdP.\n\nUsers that configure Fleet with SSO login may be vulnerable to this issue.\n\n### Patches\nThis issue is patched in 3.5.1 using https://github.com/mattermost/xml-roundtrip-validator.\n\n### Workarounds\nIf upgrade to 3.5.1 is not possible, users should disable SSO authentication in Fleet.\n\n### References\nSee https://mattermost.com/blog/coordinated-disclosure-go-xml-vulnerabilities/ for more information about the underlying vulnerabilities.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [security@fleetdm.com](mailto:security@fleetdm.com)\n* Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)",
"id": "GHSA-w3wf-cfx3-6gcx",
"modified": "2022-02-11T23:59:14Z",
"published": "2022-02-11T23:59:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fleetdm/fleet/security/advisories/GHSA-w3wf-cfx3-6gcx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26276"
},
{
"type": "WEB",
"url": "https://github.com/fleetdm/fleet/commit/57812a532e5f749c8e18c6f6a652eca65c083607"
},
{
"type": "WEB",
"url": "https://github.com/fleetdm/fleet/blob/master/CHANGELOG.md#fleet-351-dec-14-2020"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/xml-roundtrip-validator"
},
{
"type": "WEB",
"url": "https://mattermost.com/blog/coordinated-disclosure-go-xml-vulnerabilities"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "SAML authentication vulnerability due to stdlib XML parsing"
}
GHSA-W4QR-7HMF-8W6R
Vulnerability from github – Published: 2025-10-14 18:30 – Updated: 2025-10-14 18:30A Secure Boot Bypass Vulnerability exists in affected Access Points that allows an adversary to bypass the hardware root of trust verification in place to ensure only vendor-signed firmware can execute on the device. An adversary can exploit this vulnerability to run modified or custom firmware on affected Access Points.
{
"affected": [],
"aliases": [
"CVE-2025-37147"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-14T17:15:41Z",
"severity": "HIGH"
},
"details": "A Secure Boot Bypass Vulnerability exists in affected Access Points that allows an adversary to bypass the hardware root of trust verification in place to ensure only vendor-signed firmware can execute on the device. An adversary can exploit this vulnerability to run modified or custom firmware on affected Access Points.",
"id": "GHSA-w4qr-7hmf-8w6r",
"modified": "2025-10-14T18:30:29Z",
"published": "2025-10-14T18:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37147"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04958en_us\u0026docLocale=en_US"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W4W5-G48Q-278G
Vulnerability from github – Published: 2025-12-21 06:31 – Updated: 2025-12-21 06:31Yealink RPS before 2025-06-27 allows unauthorized access to information, including AutoP URL addresses. This was fixed by deploying an enhanced authentication mechanism through a security update to all cloud instances.
{
"affected": [],
"aliases": [
"CVE-2025-68644"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-21T04:16:05Z",
"severity": "HIGH"
},
"details": "Yealink RPS before 2025-06-27 allows unauthorized access to information, including AutoP URL addresses. This was fixed by deploying an enhanced authentication mechanism through a security update to all cloud instances.",
"id": "GHSA-w4w5-g48q-278g",
"modified": "2025-12-21T06:31:11Z",
"published": "2025-12-21T06:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68644"
},
{
"type": "WEB",
"url": "https://www.yealink.com/en/trust-center/security-bulletins/yealink-unauthorized-access-to-rps-vulnerability"
},
{
"type": "WEB",
"url": "https://www.yealink.com/website-service/download/Yealink_RPS_Security_Remediation_Verification_Report.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W56W-W5XR-Q52M
Vulnerability from github – Published: 2025-03-10 21:31 – Updated: 2025-03-11 21:30Certain crafted MIME email messages that claimed to contain an encrypted OpenPGP message, which instead contained an OpenPGP signed message, were wrongly shown as being encrypted. This vulnerability affects Thunderbird < 136 and Thunderbird < 128.8.
{
"affected": [],
"aliases": [
"CVE-2025-26696"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-10T19:15:40Z",
"severity": "HIGH"
},
"details": "Certain crafted MIME email messages that claimed to contain an encrypted OpenPGP message, which instead contained an OpenPGP signed message, were wrongly shown as being encrypted. This vulnerability affects Thunderbird \u003c 136 and Thunderbird \u003c 128.8.",
"id": "GHSA-w56w-w5xr-q52m",
"modified": "2025-03-11T21:30:34Z",
"published": "2025-03-10T21:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26696"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1864205"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2025-17"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2025-18"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-W59W-35Q3-VCG7
Vulnerability from github – Published: 2024-04-04 09:30 – Updated: 2025-01-24 18:31By default the CloudStack management server honours the x-forwarded-for HTTP header and logs it as the source IP of an API request. This could lead to authentication bypass and other operational problems should an attacker decide to spoof their IP address this way. Users are recommended to upgrade to CloudStack version 4.18.1.1 or 4.19.0.1, which fixes this issue.
{
"affected": [],
"aliases": [
"CVE-2024-29006"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-04T08:15:06Z",
"severity": "CRITICAL"
},
"details": "By default the CloudStack management server honours the x-forwarded-for HTTP header and logs it as the source IP of an API request. This could lead to authentication bypass and other operational problems should an attacker decide to spoof their IP address this way. Users are recommended to upgrade to CloudStack version 4.18.1.1 or 4.19.0.1, which fixes this issue.\n\n",
"id": "GHSA-w59w-35q3-vcg7",
"modified": "2025-01-24T18:31:08Z",
"published": "2024-04-04T09:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29006"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/82f46pv7mvh95ybto5hn8wlo6g8jhjvp"
}
],
"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"
}
]
}
No mitigation information available for this CWE.
CAPEC-21: Exploitation of Trusted Identifiers
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.
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-459: Creating a Rogue Certification Authority Certificate
An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.
CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness
An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.
CAPEC-473: Signature Spoof
An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.
CAPEC-476: Signature Spoofing by Misrepresentation
An attacker exploits a weakness in the parsing or display code of the recipient software to generate a data blob containing a supposedly valid signature, but the signer's identity is falsely represented, which can lead to the attacker manipulating the recipient software or its victim user to perform compromising actions.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-667: Bluetooth Impersonation AttackS (BIAS)
An adversary disguises the MAC address of their Bluetooth enabled device to one for which there exists an active and trusted connection and authenticates successfully. The adversary can then perform malicious actions on the target Bluetooth device depending on the target’s capabilities.
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.