CWE-319
AllowedCleartext Transmission of Sensitive Information
Abstraction: Base · Status: Draft
The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
1272 vulnerabilities reference this CWE, most recent first.
GHSA-JM96-WX9P-8WM4
Vulnerability from github – Published: 2024-02-13 18:38 – Updated: 2024-02-13 18:38Windows Printing Service Spoofing Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-21406"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-13T18:15:59Z",
"severity": "HIGH"
},
"details": "Windows Printing Service Spoofing Vulnerability",
"id": "GHSA-jm96-wx9p-8wm4",
"modified": "2024-02-13T18:38:24Z",
"published": "2024-02-13T18:38:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21406"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21406"
}
],
"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"
}
]
}
GHSA-JMFC-HFJQ-PXCP
Vulnerability from github – Published: 2026-05-29 22:16 – Updated: 2026-05-29 22:16Impact
Stigmem nodes with federation enabled could be configured to run without mTLS outside loopback-only local development. In affected deployments, federation traffic may traverse the network without the intended transport protection. Impacted users are operators who enabled federation and explicitly disabled mTLS while binding the node to a non-loopback URL.
Patches
Patched in 0.9.0a2. The node now refuses this configuration unless insecure federation is limited to loopback-only local development.
Workarounds
Before upgrading, operators should enable mTLS for federation or ensure federation endpoints are bound only to loopback/private test environments and are not reachable by untrusted networks.
Upgrade
Upgrade to the patched release:
pip install --upgrade --pre stigmem-node
If developers install through the Stigmem meta-package instead, they should use the matching extra for deployments, for example:
pip install --upgrade --pre 'stigmem[node]'
Resources
- Release: https://github.com/eidetic-labs/stigmem/releases/tag/v0.9.0a2
- Changelog: https://github.com/eidetic-labs/stigmem/blob/v0.9.0a2/CHANGELOG.md#L14-L35
- Security policy and posture: https://github.com/eidetic-labs/stigmem/blob/v0.9.0a2/SECURITY.md
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "stigmem-node"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.0a2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-319",
"CWE-489"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T22:16:27Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Impact\nStigmem nodes with federation enabled could be configured to run without mTLS outside loopback-only local development. In affected deployments, federation traffic may traverse the network without the intended transport protection. Impacted users are operators who enabled federation and explicitly disabled mTLS while binding the node to a non-loopback URL.\n\n### Patches\nPatched in 0.9.0a2. The node now refuses this configuration unless insecure federation is limited to loopback-only local development.\n\n### Workarounds\nBefore upgrading, operators should enable mTLS for federation or ensure federation endpoints are bound only to loopback/private test environments and are not reachable by untrusted networks.\n\n### Upgrade\nUpgrade to the patched release:\n\n```bash\npip install --upgrade --pre stigmem-node\n```\n\nIf developers install through the Stigmem meta-package instead, they should use the matching extra for deployments, for example:\n\n```bash\npip install --upgrade --pre \u0027stigmem[node]\u0027\n```\n\n### Resources\n- Release: https://github.com/eidetic-labs/stigmem/releases/tag/v0.9.0a2\n- Changelog: https://github.com/eidetic-labs/stigmem/blob/v0.9.0a2/CHANGELOG.md#L14-L35\n- Security policy and posture: https://github.com/eidetic-labs/stigmem/blob/v0.9.0a2/SECURITY.md",
"id": "GHSA-jmfc-hfjq-pxcp",
"modified": "2026-05-29T22:16:27Z",
"published": "2026-05-29T22:16:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/eidetic-labs/stigmem/security/advisories/GHSA-jmfc-hfjq-pxcp"
},
{
"type": "PACKAGE",
"url": "https://github.com/eidetic-labs/stigmem"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "stigmem-node\u0027s federation insecure transport settings may allow non-loopback cleartext federation"
}
GHSA-JMQQ-X5G9-9P2W
Vulnerability from github – Published: 2026-10-08 16:30 – Updated: 2026-10-08 16:30Impact
When a request is replayed onto a different host, the client updates only the current request and leaves the target request pointing at the original host. Four consumers read that stale value, and each one sends the first host's request, credentials, or both to the second host.
A replay happens through documented, ordinary features: a ResponseFilter that returns a different request, which is the supported failover pattern, and the IOException retry path. The attacker does not need to induce the replay; an application that uses failover produces it by design.
- The socket to host B is filed in the connection pool under host A's key. A later request the application addresses to A is served over the connection to B, and A's
Authorizationheader goes to B. - Over a CONNECT tunnel, the client tunnels to B and negotiates TLS with B correctly, then writes A's request into that tunnel. B receives A's path, A's
Host, and A'sAuthorization. TLS does not protect against this, because the handshake really is with B, so no certificate mismatch occurs. - The replay reuses the original realm, so A's credentials are regenerated onto a replay request that carries no realm of its own. The cross-origin redirect path strips realms for exactly this reason; the replay path never did.
- The stale value also decides whether TLS is used at all. When the original request was
http://and the replay ishttps://, no SSL handler is installed and the replayed request, credentials included, is written in cleartext.
Affected versions
- 3.x: up to and including 3.0.12
- 2.x: up to and including 2.16.0
Both lines are affected identically. This is long-standing behaviour, not a recent regression.
Patches
Fixed in 3.0.13 on the 3.x line and in 2.16.1 on the 2.x line. The target request now moves when a request is replayed, and the proxy moves with it: the proxy is part of the connection pool key, so correcting only the host would convert a harmless pool miss into a hit and route a proxied connection to a direct request.
Workarounds
Do not use a ResponseFilter that replays to a different host, and disable request retries, if the client is configured with credentials or used through a proxy. Replaying to the same host is not affected.
Details
NettyRequestSender.newNettyRequestAndResponseFuture calls setCurrentRequest without setTargetRequest, and replayRequest does not move the target either. The stale target is then read by the pool key derivation in NettyResponseFuture, by ConnectSuccessInterceptor when it writes the tunnelled request, by the realm selection in NettyRequestSender, and by NettyConnectListener when it decides whether to install an SSL handler.
Existing replay tests do not cover this, because all of them replay to the same host.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.12"
},
"package": {
"ecosystem": "Maven",
"name": "org.asynchttpclient:async-http-client"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.16.0"
},
"package": {
"ecosystem": "Maven",
"name": "org.asynchttpclient:async-http-client"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.16.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107282"
],
"database_specific": {
"cwe_ids": [
"CWE-319",
"CWE-441",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T16:30:46Z",
"nvd_published_at": "2026-10-07T22:17:04Z",
"severity": "CRITICAL"
},
"details": "### Impact\nWhen a request is replayed onto a different host, the client updates only the current request and leaves the target request pointing at the original host. Four consumers read that stale value, and each one sends the first host\u0027s request, credentials, or both to the second host.\n\nA replay happens through documented, ordinary features: a `ResponseFilter` that returns a different request, which is the supported failover pattern, and the IOException retry path. The attacker does not need to induce the replay; an application that uses failover produces it by design.\n\n* The socket to host B is filed in the connection pool under host A\u0027s key. A later request the application addresses to A is served over the connection to B, and A\u0027s `Authorization` header goes to B.\n* Over a CONNECT tunnel, the client tunnels to B and negotiates TLS with B correctly, then writes A\u0027s request into that tunnel. B receives A\u0027s path, A\u0027s `Host`, and A\u0027s `Authorization`. TLS does not protect against this, because the handshake really is with B, so no certificate mismatch occurs.\n* The replay reuses the original realm, so A\u0027s credentials are regenerated onto a replay request that carries no realm of its own. The cross-origin redirect path strips realms for exactly this reason; the replay path never did.\n* The stale value also decides whether TLS is used at all. When the original request was `http://` and the replay is `https://`, no SSL handler is installed and the replayed request, credentials included, is written in cleartext.\n\n### Affected versions\n* 3.x: up to and including 3.0.12\n* 2.x: up to and including 2.16.0\n\nBoth lines are affected identically. This is long-standing behaviour, not a recent regression.\n\n### Patches\nFixed in 3.0.13 on the 3.x line and in 2.16.1 on the 2.x line. The target request now moves when a request is replayed, and the proxy moves with it: the proxy is part of the connection pool key, so correcting only the host would convert a harmless pool miss into a hit and route a proxied connection to a direct request.\n\n### Workarounds\nDo not use a `ResponseFilter` that replays to a different host, and disable request retries, if the client is configured with credentials or used through a proxy. Replaying to the same host is not affected.\n\n### Details\n`NettyRequestSender.newNettyRequestAndResponseFuture` calls `setCurrentRequest` without `setTargetRequest`, and `replayRequest` does not move the target either. The stale target is then read by the pool key derivation in `NettyResponseFuture`, by `ConnectSuccessInterceptor` when it writes the tunnelled request, by the realm selection in `NettyRequestSender`, and by `NettyConnectListener` when it decides whether to install an SSL handler.\n\nExisting replay tests do not cover this, because all of them replay to the same host.",
"id": "GHSA-jmqq-x5g9-9p2w",
"modified": "2026-10-08T16:30:46Z",
"published": "2026-10-08T16:30:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/security/advisories/GHSA-jmqq-x5g9-9p2w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-107282"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/commit/15b254514a411623e5f1d8c99ea79c0f82f8a466"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/commit/bbc31aed3b044f9f7a126cf689a8c8d7ad2ae1cb"
},
{
"type": "PACKAGE",
"url": "https://github.com/AsyncHttpClient/async-http-client"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/releases/tag/async-http-client-project-2.16.1"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/releases/tag/async-http-client-project-3.0.13"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "AsyncHttpClient: Replay to a different host sends the original host request and credentials to the new host"
}
GHSA-JP8P-FQ38-V738
Vulnerability from github – Published: 2026-06-10 00:31 – Updated: 2026-06-10 00:31A bug in query analysis processing of the $vectorSearch aggregation stage for Queryable Encryption (QE) or Client-Side Field Level Encryption (CSFLE) results in literal values for encrypted fields within the $vectorSearch stage filter expressions to be sent to the server as plaintext instead of ciphertext.
{
"affected": [],
"aliases": [
"CVE-2026-9741"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T23:17:03Z",
"severity": "HIGH"
},
"details": "A bug in query analysis processing of the $vectorSearch aggregation stage for Queryable Encryption (QE) or Client-Side Field Level Encryption (CSFLE) results in literal values for encrypted fields within the $vectorSearch stage filter expressions to be sent to the server as plaintext instead of ciphertext.",
"id": "GHSA-jp8p-fq38-v738",
"modified": "2026-06-10T00:31:50Z",
"published": "2026-06-10T00:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9741"
},
{
"type": "WEB",
"url": "https://jira.mongodb.org/browse/SERVER-123507"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-JQFF-8G2V-642H
Vulnerability from github – Published: 2024-05-21 21:30 – Updated: 2024-07-05 20:58An issue in the Pickle Python library of NASA AIT-Core v2.5.2 allows attackers to execute arbitrary commands.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "ait-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.5.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-35059"
],
"database_specific": {
"cwe_ids": [
"CWE-319",
"CWE-74"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-22T14:17:42Z",
"nvd_published_at": "2024-05-21T19:15:10Z",
"severity": "CRITICAL"
},
"details": "An issue in the Pickle Python library of NASA AIT-Core v2.5.2 allows attackers to execute arbitrary commands.",
"id": "GHSA-jqff-8g2v-642h",
"modified": "2024-07-05T20:58:15Z",
"published": "2024-05-21T21:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35059"
},
{
"type": "PACKAGE",
"url": "https://github.com/NASA-AMMOS/AIT-Core"
},
{
"type": "WEB",
"url": "https://www.linkedin.com/pulse/remote-code-execution-via-man-in-the-middle-more-ujkze"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "NASA AIT-Core vulnerable to remote code execution"
}
GHSA-JRH8-929C-JGCV
Vulnerability from github – Published: 2022-05-24 17:37 – Updated: 2022-05-24 17:37A cleartext transmission of sensitive information vulnerability has been reported to affect certain QTS devices. If exploited, this vulnerability allows a remote attacker to gain access to sensitive information. QNAP have already fixed this vulnerability in the following versions: QTS 4.4.3.1354 build 20200702 (and later)
{
"affected": [],
"aliases": [
"CVE-2018-19944"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-31T17:15:00Z",
"severity": "HIGH"
},
"details": "A cleartext transmission of sensitive information vulnerability has been reported to affect certain QTS devices. If exploited, this vulnerability allows a remote attacker to gain access to sensitive information. QNAP have already fixed this vulnerability in the following versions: QTS 4.4.3.1354 build 20200702 (and later)",
"id": "GHSA-jrh8-929c-jgcv",
"modified": "2022-05-24T17:37:33Z",
"published": "2022-05-24T17:37:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19944"
},
{
"type": "WEB",
"url": "https://www.qnap.com/zh-tw/security-advisory/qsa-20-22"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-JRHH-56W3-2FJH
Vulnerability from github – Published: 2024-02-29 03:33 – Updated: 2024-02-29 03:33IBM Cloud Pak for Security (CP4S) 1.10.0.0 through 1.10.6.0 could allow a remote attacker to obtain sensitive information, caused by the failure to properly enable HTTP Strict Transport Security. An attacker could exploit this vulnerability to obtain sensitive information using man in the middle techniques. IBM X-Force ID: 216388.
{
"affected": [],
"aliases": [
"CVE-2021-39090"
],
"database_specific": {
"cwe_ids": [
"CWE-311",
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-29T03:15:06Z",
"severity": "MODERATE"
},
"details": "IBM Cloud Pak for Security (CP4S) 1.10.0.0 through 1.10.6.0 could allow a remote attacker to obtain sensitive information, caused by the failure to properly enable HTTP Strict Transport Security. An attacker could exploit this vulnerability to obtain sensitive information using man in the middle techniques. IBM X-Force ID: 216388.",
"id": "GHSA-jrhh-56w3-2fjh",
"modified": "2024-02-29T03:33:18Z",
"published": "2024-02-29T03:33:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39090"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/216388"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/6856407"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-JRMF-XHR6-3428
Vulnerability from github – Published: 2022-05-24 16:57 – Updated: 2022-12-06 21:07Jenkins SourceGear Vault Plugin transmits configured credentials in plain text as part of job configuration forms, potentially resulting in their exposure. As of the publication of the advisory, there are no patches and the plugin is unmaintained.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:vault-scm-plugin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-10435"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-06T21:07:51Z",
"nvd_published_at": "2019-10-01T14:15:00Z",
"severity": "HIGH"
},
"details": "Jenkins SourceGear Vault Plugin transmits configured credentials in plain text as part of job configuration forms, potentially resulting in their exposure. As of the publication of the advisory, there are no patches and the plugin is unmaintained.",
"id": "GHSA-jrmf-xhr6-3428",
"modified": "2022-12-06T21:07:51Z",
"published": "2022-05-24T16:57:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10435"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/vault-scm-plugin"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2019-10-01/#SECURITY-1524"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/10/01/2"
}
],
"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"
}
],
"summary": "Jenkins SourceGear Vault plugin transmits credentials in plain text"
}
GHSA-JRVG-VW6C-RP59
Vulnerability from github – Published: 2026-10-11 15:31 – Updated: 2026-10-11 15:31mcp-remote 0.8.0 through 0.14.3 contains a cleartext transmission vulnerability in authorizeWithDeviceCode that sends client secrets and receives tokens without enforcing HTTPS endpoints. When discovered device authorization and token endpoints are non-loopback http URLs, on-path network attackers can capture the client secret plus issued access and refresh tokens.
{
"affected": [],
"aliases": [
"CVE-2026-108716"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-11T13:17:14Z",
"severity": "MODERATE"
},
"details": "mcp-remote 0.8.0 through 0.14.3 contains a cleartext transmission vulnerability in authorizeWithDeviceCode that sends client secrets and receives tokens without enforcing HTTPS endpoints. When discovered device authorization and token endpoints are non-loopback http URLs, on-path network attackers can capture the client secret plus issued access and refresh tokens.",
"id": "GHSA-jrvg-vw6c-rp59",
"modified": "2026-10-11T15:31:03Z",
"published": "2026-10-11T15:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-108716"
},
{
"type": "WEB",
"url": "https://github.com/punkpeye/mcp-remote"
},
{
"type": "WEB",
"url": "https://github.com/punkpeye/mcp-remote/blob/v0.14.3/src/lib/client-credentials.ts#L37-L47"
},
{
"type": "WEB",
"url": "https://github.com/punkpeye/mcp-remote/blob/v0.14.3/src/lib/device-authorization.ts#L64-L170"
},
{
"type": "WEB",
"url": "https://hackmd.io/@haind03/punkpeye-mcp-remote-device-code-cleartext-oauth-transport"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/mcp-remote-0.8.0-through-0.14.3-cleartext-credential-transmission-via-device-code-oauth-grant"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-JV2F-HVVH-4HW3
Vulnerability from github – Published: 2022-05-13 01:06 – Updated: 2022-05-13 01:06Trend Micro ServerProtect for Linux 3.0 before CP 1531 allows attackers to eavesdrop and tamper with updates by leveraging unencrypted communications with update servers.
{
"affected": [],
"aliases": [
"CVE-2017-9035"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-05-26T01:29:00Z",
"severity": "HIGH"
},
"details": "Trend Micro ServerProtect for Linux 3.0 before CP 1531 allows attackers to eavesdrop and tamper with updates by leveraging unencrypted communications with update servers.",
"id": "GHSA-jv2f-hvvh-4hw3",
"modified": "2022-05-13T01:06:07Z",
"published": "2022-05-13T01:06:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9035"
},
{
"type": "WEB",
"url": "https://success.trendmicro.com/solution/1117411"
},
{
"type": "WEB",
"url": "https://www.coresecurity.com/advisories/trend-micro-serverprotect-multiple-vulnerabilities"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/142645/Trend-Micro-ServerProtect-Disclosure-CSRF-XSS.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2017/May/91"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1038548"
}
],
"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"
}
]
}
Mitigation
Before transmitting, encrypt the data using reliable, confidentiality-protecting cryptographic protocols.
Mitigation
When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.
Mitigation
When designing hardware platforms, ensure that approved encryption algorithms (such as those recommended by NIST) protect paths from security critical data to trusted user applications.
Mitigation
Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.
Mitigation
Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.
CAPEC-102: Session Sidejacking
Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.
CAPEC-117: Interception
An adversary monitors data streams to or from the target for information gathering purposes. This attack may be undertaken to solely gather sensitive information or to support a further attack against the target. This attack pattern can involve sniffing network traffic as well as other types of data streams (e.g. radio). The adversary can attempt to initiate the establishment of a data stream or passively observe the communications as they unfold. In all variants of this attack, the adversary is not the intended recipient of the data stream. In contrast to other means of gathering information (e.g., targeting data leaks), the adversary must actively position themself so as to observe explicit data channels (e.g. network traffic) and read the content. However, this attack differs from a Adversary-In-the-Middle (CAPEC-94) attack, as the adversary does not alter the content of the communications nor forward data to the intended recipient.
CAPEC-383: Harvesting Information via API Event Monitoring
An adversary hosts an event within an application framework and then monitors the data exchanged during the course of the event for the purpose of harvesting any important data leaked during the transactions. One example could be harvesting lists of usernames or userIDs for the purpose of sending spam messages to those users. One example of this type of attack involves the adversary creating an event within the sub-application. Assume the adversary hosts a "virtual sale" of rare items. As other users enter the event, the attacker records via AiTM (CAPEC-94) proxy the user_ids and usernames of everyone who attends. The adversary would then be able to spam those users within the application using an automated script.
CAPEC-477: Signature Spoofing by Mixing Signed and Unsigned Content
An attacker exploits the underlying complexity of a data structure that allows for both signed and unsigned content, to cause unsigned data to be processed as though it were signed data.
CAPEC-65: Sniff Application Code
An adversary passively sniffs network communications and captures application code bound for an authorized client. Once obtained, they can use it as-is, or through reverse-engineering glean sensitive information or exploit the trust relationship between the client and server. Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.