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.
5964 vulnerabilities reference this CWE, most recent first.
GHSA-VMQF-73MX-MCW4
Vulnerability from github – Published: 2022-03-24 00:00 – Updated: 2022-03-30 00:01A lack of password change protection vulnerability in a depreciated API of McAfee Enterprise ePolicy Orchestrator (ePO) prior to 5.10 Update 13 allows a remote attacker to change the password of a compromised session without knowing the existing user's password. This functionality was removed from the User Interface in ePO 10 and the API has now been disabled. Other protection is in place to reduce the likelihood of this being successful through sending a link to a logged in user.
{
"affected": [],
"aliases": [
"CVE-2022-0862"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-23T15:15:00Z",
"severity": "MODERATE"
},
"details": "A lack of password change protection vulnerability in a depreciated API of McAfee Enterprise ePolicy Orchestrator (ePO) prior to 5.10 Update 13 allows a remote attacker to change the password of a compromised session without knowing the existing user\u0027s password. This functionality was removed from the User Interface in ePO 10 and the API has now been disabled. Other protection is in place to reduce the likelihood of this being successful through sending a link to a logged in user.",
"id": "GHSA-vmqf-73mx-mcw4",
"modified": "2022-03-30T00:01:09Z",
"published": "2022-03-24T00:00:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0862"
},
{
"type": "WEB",
"url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10379"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VMVM-JJVW-QWPW
Vulnerability from github – Published: 2024-07-03 18:48 – Updated: 2024-07-03 18:48Mattermost versions 9.8.x <= 9.8.0, 9.7.x <= 9.7.4, 9.6.x <= 9.6.2 and 9.5.x <= 9.5.5, when shared channels are enabled, fail to use constant time comparison for remote cluster tokens which allows an attacker to retrieve the remote cluster token via a timing attack during remote cluster token comparison.
{
"affected": [],
"aliases": [
"CVE-2024-39830"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-03T09:15:07Z",
"severity": "HIGH"
},
"details": "Mattermost versions 9.8.x \u003c= 9.8.0, 9.7.x \u003c= 9.7.4, 9.6.x \u003c= 9.6.2 and 9.5.x \u003c= 9.5.5, when shared channels are enabled, fail to use constant time comparison for remote cluster tokens which allows an attacker to retrieve the remote cluster token via a timing attack during remote cluster token comparison.",
"id": "GHSA-vmvm-jjvw-qwpw",
"modified": "2024-07-03T18:48:12Z",
"published": "2024-07-03T18:48:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39830"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-VMW7-J325-RFFG
Vulnerability from github – Published: 2023-07-17 09:30 – Updated: 2024-04-04 06:09A hidden API exists in TapHome's core platform before version 2023.2 that allows an authenticated, low privileged user to change passwords of other users without any prior knowledge. The attacker may gain full access to the device by using this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2023-2759"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-17T07:15:08Z",
"severity": "HIGH"
},
"details": "A hidden API exists in TapHome\u0027s core platform before version 2023.2 that allows an authenticated, low privileged user to change passwords of other users without any prior knowledge. The attacker may gain full access to the device by using this vulnerability.",
"id": "GHSA-vmw7-j325-rffg",
"modified": "2024-04-04T06:09:29Z",
"published": "2023-07-17T09:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2759"
},
{
"type": "WEB",
"url": "https://claroty.com/team82/disclosure-dashboard/cve-2023-2759"
}
],
"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-VMXH-MP6W-252X
Vulnerability from github – Published: 2022-05-24 17:32 – Updated: 2022-05-24 17:32Single Sign-On for Vmware Tanzu all versions prior to 1.11.3 ,1.12.x versions prior to 1.12.4 and 1.13.x prior to 1.13.1 are vulnerable to user impersonation attack.If two users are logged in to the SSO operator dashboard at the same time, with the same username, from two different identity providers, one can acquire the token of the other and thus operate with their permissions.
Note: Foundation may be vulnerable only if: 1) The system zone is set up to use a SAML identity provider 2) There are internal users that have the same username as users in the external SAML provider 3) Those duplicate-named users have the scope to access the SSO operator dashboard 4) The vulnerability doesn't appear with LDAP because of chained authentication.
{
"affected": [],
"aliases": [
"CVE-2020-5425"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-31T22:15:00Z",
"severity": "HIGH"
},
"details": "Single Sign-On for Vmware Tanzu all versions prior to 1.11.3 ,1.12.x versions prior to 1.12.4 and 1.13.x prior to 1.13.1 are vulnerable to user impersonation attack.If two users are logged in to the SSO operator dashboard at the same time, with the same username, from two different identity providers, one can acquire the token of the other and thus operate with their permissions.\n\nNote: Foundation may be vulnerable only if:\n1) The system zone is set up to use a SAML identity provider\n2) There are internal users that have the same username as users in the external SAML provider\n3) Those duplicate-named users have the scope to access the SSO operator dashboard\n4) The vulnerability doesn\u0027t appear with LDAP because of chained authentication.",
"id": "GHSA-vmxh-mp6w-252x",
"modified": "2022-05-24T17:32:47Z",
"published": "2022-05-24T17:32:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5425"
},
{
"type": "WEB",
"url": "https://tanzu.vmware.com/security/cve-2020-5425"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-VP29-5652-4FW9
Vulnerability from github – Published: 2026-04-28 22:54 – Updated: 2026-05-08 15:30Summary
The gRPC, QUIC, DoH, and DoH3 transports in CoreDNS incorrectly handle TSIG authentication.
For gRPC and QUIC, CoreDNS checks whether the TSIG key name exists in the config, but does not actually verify the TSIG HMAC. If the key name matches, tsigStatus remains nil and the tsig plugin treats the request as "verified".
For DoH and DoH3, the issue is worse: TSIG is not verified at all. The DoH response writer has TsigStatus() hardcoded to return nil, so any request containing a TSIG record is treated as authenticated, even if the key name is invalid and the MAC is garbage.
As a result, attackers may bypass TSIG authentication on affected transports and access TSIG-protected functionality such as AXFR/IXFR zone transfers, dynamic updates, or other TSIG-gated plugin behavior.
Details
In server_grpc.go and server_quic.go, the TSIG handling checks whether the TSIG key name exists, but does not call dns.TsigVerify().
Relevant code before fix:
if tsig := msg.IsTsig(); tsig != nil {
if s.tsigSecret == nil {
w.tsigStatus = dns.ErrSecret
} else if _, ok := s.tsigSecret[tsig.Hdr.Name]; !ok {
w.tsigStatus = dns.ErrSecret
}
// key found -> nothing happens -> tsigStatus stays nil -> "verified"
}
This means that for gRPC and QUIC, a request with a known TSIG key name but an invalid MAC is accepted as authenticated.
PRs #7943 and #7947 partially addressed this area by adding key name checks for gRPC and QUIC, but did not add HMAC verification.
The DoH and DoH3 paths have an even weaker failure mode. In https.go, DoHWriter.TsigStatus() returned nil unconditionally:
func (d *DoHWriter) TsigStatus() error {
return nil
}
In server_https.go, the incoming DNS message is unpacked from the HTTP request and passed directly into ServeDNS() without checking msg.IsTsig(), without looking up the TSIG key name, and without calling dns.TsigVerify().
The same pattern exists in the DoH3 path in server_https3.go.
The effective DoH/DoH3 flow before the fix was:
- HTTP or HTTP/3 request arrives.
- DNS message is unpacked from the request.
- A
DoHWriteris created. - The message is passed to
ServeDNS(). - The tsig plugin checks
w.TsigStatus(). TsigStatus()returns nil.- nil is interpreted as successful TSIG verification.
This means that for DoH and DoH3, CoreDNS did not even require a valid TSIG key name. Any TSIG record was enough to satisfy the tsig plugin, regardless of key name or MAC contents.
PoC
Setup: built CoreDNS from master at commit 12d9457 and also verified against the v1.14.2 release binary. Configured a single test zone with 9 records and tsig { require all }.
Listeners used the same TSIG configuration and key:
- TCP on port 1053, using the normal
dns.Serverpath where TSIG HMAC verification works correctly - gRPC on port 1443, using manual TSIG handling
- DoH on port 8443
- DoH3 with the same TSIG configuration
gRPC / QUIC behavior
A test client sent AXFR requests over gRPC with a valid TSIG key name but forged MAC values. The same requests were sent over TCP for comparison.
| MAC used | gRPC | TCP |
|---|---|---|
| 32 zero bytes | BYPASS, 9 records returned | BADSIG |
| 32 random bytes | BYPASS, 9 records returned | BADSIG |
| HMAC computed with wrong secret | BYPASS, 9 records returned | BADSIG |
| truncated to 16 bytes | BYPASS, 9 records returned | BADSIG |
single byte 0x41 |
BYPASS, 9 records returned | BADSIG |
| empty MAC | BYPASS, 9 records returned | BADSIG |
| wrong key name + zero MAC | REJECTED, NOTAUTH/BADKEY | REJECTED, NOTAUTH/BADKEY |
6 out of 7 forged TSIG requests bypassed authentication over gRPC and returned a full zone transfer. The only rejected case was the wrong key name, because the gRPC path checked whether the key name existed.
The same class applied to QUIC.
DoH / DoH3 behavior
For DoH, a test client sent DNS queries over HTTPS POST to /dns-query with forged TSIG records. These requests were also compared against TCP.
| TSIG variant | DoH result | TCP result |
|---|---|---|
| 32 zero bytes | BYPASS, NOERROR | BADSIG |
| 32 random bytes | BYPASS, NOERROR | BADSIG |
| HMAC computed with wrong secret | BYPASS, NOERROR | BADSIG |
| truncated to 16 bytes | BYPASS, NOERROR | BADSIG |
single byte 0x41 |
BYPASS, NOERROR | BADSIG |
| empty MAC | BYPASS, NOERROR | BADSIG |
| bad key name | BYPASS, NOERROR | NOTAUTH/BADKEY |
| no TSIG record | REJECTED, REFUSED | REJECTED, REFUSED |
7 out of 8 cases bypassed authentication over DoH. Every request containing a TSIG record was accepted, including requests with an invalid key name.
An AXFR request over DoH with a forged TSIG record using a zero-byte MAC returned the full test zone.
The same pattern applies to DoH3 because it used the same DoHWriter TSIG behavior and did not verify TSIG before passing the message into the plugin chain.
To confirm that the tsig plugin itself was enforcing policy, requests with no TSIG record were rejected with REFUSED. The bypass happens because the transport layer reports successful TSIG verification when verification either did not happen or only checked the key name.
Impact
An unauthenticated network attacker may bypass TSIG authentication on affected CoreDNS transports.
Depending on configuration, this may allow an attacker to:
- perform AXFR or IXFR zone transfers over affected transports
- dump TSIG-protected zone data
- submit dynamic DNS updates if enabled
- bypass other TSIG-gated plugin behavior
- authenticate over DoH or DoH3 without knowing a valid TSIG key name
The DoH and DoH3 variants have a lower exploitation bar than gRPC and QUIC because the attacker does not need to know a configured TSIG key name. Any TSIG record is treated as valid.
Affected transports
- gRPC
- QUIC
- DoH
- DoH3
Workarounds
If upgrading is not immediately possible:
- Disable gRPC, QUIC, DoH, and DoH3 listeners where TSIG authentication is required.
- Restrict network-level access to affected transport ports to trusted sources only.
- Avoid exposing TSIG-protected functionality such as AXFR, IXFR, or dynamic updates over affected transports.
Fix
Affected transports must verify TSIG before passing the DNS message into the plugin chain.
For requests containing a TSIG record, the transport should:
- check whether TSIG secrets are configured
- verify that the TSIG key name exists
- call
dns.TsigVerify()against the original wire-format message - store the resulting status in the response writer
- return that status from
TsigStatus()
A successful key name lookup alone is not sufficient. A nil TSIG status must only be returned after successful HMAC verification.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/coredns/coredns"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.14.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35579"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-28T22:54:32Z",
"nvd_published_at": "2026-05-05T21:16:22Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe gRPC, QUIC, DoH, and DoH3 transports in CoreDNS incorrectly handle TSIG authentication.\n\nFor gRPC and QUIC, CoreDNS checks whether the TSIG key name exists in the config, but does not actually verify the TSIG HMAC. If the key name matches, `tsigStatus` remains nil and the tsig plugin treats the request as \"verified\".\n\nFor DoH and DoH3, the issue is worse: TSIG is not verified at all. The DoH response writer has `TsigStatus()` hardcoded to return nil, so any request containing a TSIG record is treated as authenticated, even if the key name is invalid and the MAC is garbage.\n\nAs a result, attackers may bypass TSIG authentication on affected transports and access TSIG-protected functionality such as AXFR/IXFR zone transfers, dynamic updates, or other TSIG-gated plugin behavior.\n\n### Details\n\nIn `server_grpc.go` and `server_quic.go`, the TSIG handling checks whether the TSIG key name exists, but does not call `dns.TsigVerify()`.\n\nRelevant code before fix:\n\n```go\nif tsig := msg.IsTsig(); tsig != nil {\n if s.tsigSecret == nil {\n w.tsigStatus = dns.ErrSecret\n } else if _, ok := s.tsigSecret[tsig.Hdr.Name]; !ok {\n w.tsigStatus = dns.ErrSecret\n }\n // key found -\u003e nothing happens -\u003e tsigStatus stays nil -\u003e \"verified\"\n}\n```\n\nThis means that for gRPC and QUIC, a request with a known TSIG key name but an invalid MAC is accepted as authenticated.\n\nPRs #7943 and #7947 partially addressed this area by adding key name checks for gRPC and QUIC, but did not add HMAC verification.\n\nThe DoH and DoH3 paths have an even weaker failure mode. In `https.go`, `DoHWriter.TsigStatus()` returned nil unconditionally:\n\n```go\nfunc (d *DoHWriter) TsigStatus() error {\n return nil\n}\n```\n\nIn `server_https.go`, the incoming DNS message is unpacked from the HTTP request and passed directly into `ServeDNS()` without checking `msg.IsTsig()`, without looking up the TSIG key name, and without calling `dns.TsigVerify()`.\n\nThe same pattern exists in the DoH3 path in `server_https3.go`.\n\nThe effective DoH/DoH3 flow before the fix was:\n\n1. HTTP or HTTP/3 request arrives.\n2. DNS message is unpacked from the request.\n3. A `DoHWriter` is created.\n4. The message is passed to `ServeDNS()`.\n5. The tsig plugin checks `w.TsigStatus()`.\n6. `TsigStatus()` returns nil.\n7. nil is interpreted as successful TSIG verification.\n\nThis means that for DoH and DoH3, CoreDNS did not even require a valid TSIG key name. Any TSIG record was enough to satisfy the tsig plugin, regardless of key name or MAC contents.\n\n### PoC\n\nSetup: built CoreDNS from master at commit `12d9457` and also verified against the v1.14.2 release binary. Configured a single test zone with 9 records and `tsig { require all }`.\n\nListeners used the same TSIG configuration and key:\n\n- TCP on port 1053, using the normal `dns.Server` path where TSIG HMAC verification works correctly\n- gRPC on port 1443, using manual TSIG handling\n- DoH on port 8443\n- DoH3 with the same TSIG configuration\n\n#### gRPC / QUIC behavior\n\nA test client sent AXFR requests over gRPC with a valid TSIG key name but forged MAC values. The same requests were sent over TCP for comparison.\n\n| MAC used | gRPC | TCP |\n|----------|------|-----|\n| 32 zero bytes | BYPASS, 9 records returned | BADSIG |\n| 32 random bytes | BYPASS, 9 records returned | BADSIG |\n| HMAC computed with wrong secret | BYPASS, 9 records returned | BADSIG |\n| truncated to 16 bytes | BYPASS, 9 records returned | BADSIG |\n| single byte `0x41` | BYPASS, 9 records returned | BADSIG |\n| empty MAC | BYPASS, 9 records returned | BADSIG |\n| wrong key name + zero MAC | REJECTED, NOTAUTH/BADKEY | REJECTED, NOTAUTH/BADKEY |\n\n6 out of 7 forged TSIG requests bypassed authentication over gRPC and returned a full zone transfer. The only rejected case was the wrong key name, because the gRPC path checked whether the key name existed.\n\nThe same class applied to QUIC.\n\n#### DoH / DoH3 behavior\n\nFor DoH, a test client sent DNS queries over HTTPS POST to `/dns-query` with forged TSIG records. These requests were also compared against TCP.\n\n| TSIG variant | DoH result | TCP result |\n|-------------|------------|------------|\n| 32 zero bytes | BYPASS, NOERROR | BADSIG |\n| 32 random bytes | BYPASS, NOERROR | BADSIG |\n| HMAC computed with wrong secret | BYPASS, NOERROR | BADSIG |\n| truncated to 16 bytes | BYPASS, NOERROR | BADSIG |\n| single byte `0x41` | BYPASS, NOERROR | BADSIG |\n| empty MAC | BYPASS, NOERROR | BADSIG |\n| bad key name | BYPASS, NOERROR | NOTAUTH/BADKEY |\n| no TSIG record | REJECTED, REFUSED | REJECTED, REFUSED |\n\n7 out of 8 cases bypassed authentication over DoH. Every request containing a TSIG record was accepted, including requests with an invalid key name.\n\nAn AXFR request over DoH with a forged TSIG record using a zero-byte MAC returned the full test zone.\n\nThe same pattern applies to DoH3 because it used the same `DoHWriter` TSIG behavior and did not verify TSIG before passing the message into the plugin chain.\n\nTo confirm that the tsig plugin itself was enforcing policy, requests with no TSIG record were rejected with `REFUSED`. The bypass happens because the transport layer reports successful TSIG verification when verification either did not happen or only checked the key name.\n\n### Impact\n\nAn unauthenticated network attacker may bypass TSIG authentication on affected CoreDNS transports.\n\nDepending on configuration, this may allow an attacker to:\n\n- perform AXFR or IXFR zone transfers over affected transports\n- dump TSIG-protected zone data\n- submit dynamic DNS updates if enabled\n- bypass other TSIG-gated plugin behavior\n- authenticate over DoH or DoH3 without knowing a valid TSIG key name\n\nThe DoH and DoH3 variants have a lower exploitation bar than gRPC and QUIC because the attacker does not need to know a configured TSIG key name. Any TSIG record is treated as valid.\n\n### Affected transports\n\n- gRPC\n- QUIC\n- DoH\n- DoH3\n\n### Workarounds\n\nIf upgrading is not immediately possible:\n\n- Disable gRPC, QUIC, DoH, and DoH3 listeners where TSIG authentication is required.\n- Restrict network-level access to affected transport ports to trusted sources only.\n- Avoid exposing TSIG-protected functionality such as AXFR, IXFR, or dynamic updates over affected transports.\n\n### Fix\n\nAffected transports must verify TSIG before passing the DNS message into the plugin chain.\n\nFor requests containing a TSIG record, the transport should:\n\n1. check whether TSIG secrets are configured\n2. verify that the TSIG key name exists\n3. call `dns.TsigVerify()` against the original wire-format message\n4. store the resulting status in the response writer\n5. return that status from `TsigStatus()`\n\nA successful key name lookup alone is not sufficient. A nil TSIG status must only be returned after successful HMAC verification.",
"id": "GHSA-vp29-5652-4fw9",
"modified": "2026-05-08T15:30:59Z",
"published": "2026-04-28T22:54:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/coredns/coredns/security/advisories/GHSA-vp29-5652-4fw9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35579"
},
{
"type": "PACKAGE",
"url": "https://github.com/coredns/coredns"
},
{
"type": "WEB",
"url": "https://github.com/coredns/coredns/releases/tag/v1.14.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "CoreDNS has TSIG authentication bypass on gRPC and QUIC transports"
}
GHSA-VP68-2WRM-69QM
Vulnerability from github – Published: 2022-09-30 22:51 – Updated: 2022-09-30 22:51Impact
When matrix-rust-sdk before 0.6 requests a room key from our devices, it correctly accepts key forwards only if they are a response to a previous request. However, it doesn't check that the device that responded matches the device the key was requested from.
This allows a malicious homeserver to insert room keys of questionable validity into the key store in some situations, potentially assisting in an impersonation attack. Note that even if key injection succeeds in this way, all forwarded keys have the imported flag set, which is used as an indicator that such keys have lesser authentication properties (and should be marked as such in clients, e.g. with a grey shield besides the message).
For more information
If you have any questions or comments about this advisory, e-mail us at security@matrix.org.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "matrix-sdk-crypto"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-39252"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-30T22:51:57Z",
"nvd_published_at": "2022-09-29T15:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nWhen matrix-rust-sdk before 0.6 requests a room key from our devices, it correctly accepts key forwards only if they are a response to a previous request. However, it doesn\u0027t check that the device that responded matches the device the key was requested from.\n\nThis allows a malicious homeserver to insert room keys of questionable validity into the key store in some situations, potentially assisting in an impersonation attack. Note that even if key injection succeeds in this way, all forwarded keys have the `imported` flag set, which is used as an indicator that such keys have lesser authentication properties (and should be marked as such in clients, e.g. with a grey shield besides the message).\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).",
"id": "GHSA-vp68-2wrm-69qm",
"modified": "2022-09-30T22:51:57Z",
"published": "2022-09-30T22:51:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-rust-sdk/security/advisories/GHSA-vp68-2wrm-69qm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39252"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-rust-sdk/commit/093fb5d0aa21c0b5eaea6ec96b477f1075271cbb"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-rust-sdk/commit/41449d2cc360e347f5d4e1c154ec1e3185f11acd"
},
{
"type": "PACKAGE",
"url": "https://github.com/matrix-org/matrix-rust-sdk"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-rust-sdk/releases/tag/matrix-sdk-0.6.0"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2022-0085.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "matrix-sdk-crypto contains potential impersonation via room key forward responses"
}
GHSA-VP6F-H27F-4858
Vulnerability from github – Published: 2022-05-01 18:32 – Updated: 2022-05-01 18:32Unspecified vulnerability in HP Select Identity 4.01 through 4.01.010 and 4.10 through 4.13.001 allows remote attackers to obtain unspecified access via unknown vectors.
{
"affected": [],
"aliases": [
"CVE-2007-5391"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-10-12T10:17:00Z",
"severity": "HIGH"
},
"details": "Unspecified vulnerability in HP Select Identity 4.01 through 4.01.010 and 4.10 through 4.13.001 allows remote attackers to obtain unspecified access via unknown vectors.",
"id": "GHSA-vp6f-h27f-4858",
"modified": "2022-05-01T18:32:47Z",
"published": "2022-05-01T18:32:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-5391"
},
{
"type": "WEB",
"url": "http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c01081130"
},
{
"type": "WEB",
"url": "http://osvdb.org/41728"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/27211"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/26023"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id?1018813"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2007/3491"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-VP7J-9CHR-3QW6
Vulnerability from github – Published: 2022-05-17 05:34 – Updated: 2022-05-17 05:34The TELNET daemon in Siemens WinCC flexible 2004, 2005, 2007, and 2008; WinCC V11 (aka TIA portal); the TP, OP, MP, Comfort Panels, and Mobile Panels SIMATIC HMI panels; WinCC V11 Runtime Advanced; and WinCC flexible Runtime does not perform authentication, which makes it easier for remote attackers to obtain access via a TCP session.
{
"affected": [],
"aliases": [
"CVE-2011-4514"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2012-02-03T20:55:00Z",
"severity": "HIGH"
},
"details": "The TELNET daemon in Siemens WinCC flexible 2004, 2005, 2007, and 2008; WinCC V11 (aka TIA portal); the TP, OP, MP, Comfort Panels, and Mobile Panels SIMATIC HMI panels; WinCC V11 Runtime Advanced; and WinCC flexible Runtime does not perform authentication, which makes it easier for remote attackers to obtain access via a TCP session.",
"id": "GHSA-vp7j-9chr-3qw6",
"modified": "2022-05-17T05:34:43Z",
"published": "2022-05-17T05:34:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-4514"
},
{
"type": "WEB",
"url": "http://www.siemens.com/corporate-technology/pool/de/forschungsfelder/siemens_security_advisory_ssa-345442.pdf"
},
{
"type": "WEB",
"url": "http://www.us-cert.gov/control_systems/pdf/ICSA-12-030-01.pdf"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-VP9W-CXRW-6J78
Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2024-04-04 00:49The Sitecore Rocks plugin before 2.1.149 for Sitecore allows an unauthenticated threat actor to inject malicious commands and code via the Sitecore Rocks Hard Rocks Service.
{
"affected": [],
"aliases": [
"CVE-2019-12440"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-29T16:29:00Z",
"severity": "CRITICAL"
},
"details": "The Sitecore Rocks plugin before 2.1.149 for Sitecore allows an unauthenticated threat actor to inject malicious commands and code via the Sitecore Rocks Hard Rocks Service.",
"id": "GHSA-vp9w-cxrw-6j78",
"modified": "2024-04-04T00:49:28Z",
"published": "2022-05-24T16:46:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12440"
},
{
"type": "WEB",
"url": "https://github.com/Sitecore/Sitecore.Rocks/compare/be79dcc...bd9ba6a"
},
{
"type": "WEB",
"url": "https://github.com/Sitecore/Sitecore.Rocks/releases/tag/2.1.149"
},
{
"type": "WEB",
"url": "https://kb.sitecore.net/articles/842902"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-VPF6-VX2H-WMGQ
Vulnerability from github – Published: 2022-05-02 03:27 – Updated: 2022-05-02 03:27ajaxterm.js in AjaxTerm 0.10 and earlier generates session IDs with predictable random numbers based on certain JavaScript functions, which makes it easier for remote attackers to (1) hijack a session or (2) cause a denial of service (session ID exhaustion) via a brute-force attack.
{
"affected": [],
"aliases": [
"CVE-2009-1629"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-05-14T17:30:00Z",
"severity": "MODERATE"
},
"details": "ajaxterm.js in AjaxTerm 0.10 and earlier generates session IDs with predictable random numbers based on certain JavaScript functions, which makes it easier for remote attackers to (1) hijack a session or (2) cause a denial of service (session ID exhaustion) via a brute-force attack.",
"id": "GHSA-vpf6-vx2h-wmgq",
"modified": "2022-05-02T03:27:01Z",
"published": "2022-05-02T03:27:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-1629"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/50464"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2010-December/052655.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/42784"
},
{
"type": "WEB",
"url": "http://www.ocert.org/advisories/ocert-2009-004.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2009/05/11/1"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/503421/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/34903"
}
],
"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.