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.
1214 vulnerabilities reference this CWE, most recent first.
GHSA-7GVM-32F4-3MV5
Vulnerability from github – Published: 2022-05-13 01:08 – Updated: 2022-05-13 01:08The Help feature in the ES File Explorer File Manager application 4.1.9.7.4 for Android allows session hijacking by a Man-in-the-middle attacker on the local network because HTTPS is not used, and an attacker's web site is displayed in a WebView with no information about the URL.
{
"affected": [],
"aliases": [
"CVE-2019-8345"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-02-15T14:29:00Z",
"severity": "MODERATE"
},
"details": "The Help feature in the ES File Explorer File Manager application 4.1.9.7.4 for Android allows session hijacking by a Man-in-the-middle attacker on the local network because HTTPS is not used, and an attacker\u0027s web site is displayed in a WebView with no information about the URL.",
"id": "GHSA-7gvm-32f4-3mv5",
"modified": "2022-05-13T01:08:16Z",
"published": "2022-05-13T01:08:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8345"
},
{
"type": "WEB",
"url": "https://www.youtube.com/watch?v=BtLUO-ujJ7I"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7J63-969G-R2JP
Vulnerability from github – Published: 2022-10-17 19:00 – Updated: 2022-10-20 19:00The Passster WordPress plugin before 3.5.5.5.2 stores the password inside a cookie named "passster" using base64 encoding method which is easy to decode. This puts the password at risk in case the cookies get leaked.
{
"affected": [],
"aliases": [
"CVE-2022-3206"
],
"database_specific": {
"cwe_ids": [
"CWE-319",
"CWE-326"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-17T12:15:00Z",
"severity": "MODERATE"
},
"details": "The Passster WordPress plugin before 3.5.5.5.2 stores the password inside a cookie named \"passster\" using base64 encoding method which is easy to decode. This puts the password at risk in case the cookies get leaked.",
"id": "GHSA-7j63-969g-r2jp",
"modified": "2022-10-20T19:00:34Z",
"published": "2022-10-17T19:00:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3206"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/a8963750-62bf-403e-a906-94f371ed2a7a"
}
],
"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-7JRG-2597-P2HC
Vulnerability from github – Published: 2024-02-07 00:30 – Updated: 2024-02-07 00:30An attacker with access to the network where the affected devices are located could maliciously actions to obtain, via a sniffer, sensitive information exchanged via TCP communications.
{
"affected": [],
"aliases": [
"CVE-2023-40544"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-06T22:16:13Z",
"severity": "MODERATE"
},
"details": "\n\n\n\n\n\n\n\n\n\n\nAn attacker with access to the network where the affected devices are located could maliciously actions to obtain, via a sniffer, sensitive information exchanged via TCP communications.\n\n\n\n",
"id": "GHSA-7jrg-2597-p2hc",
"modified": "2024-02-07T00:30:25Z",
"published": "2024-02-07T00:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40544"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-24-023-04"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7M3H-X75F-VJ4X
Vulnerability from github – Published: 2025-12-15 21:30 – Updated: 2025-12-15 21:30IBM UCD - IBM DevOps Deploy 8.1 through 8.1.2.3 Deploy transmits data in clear text that could allow an attacker to obtain sensitive information using man in the middle techniques.
{
"affected": [],
"aliases": [
"CVE-2025-13489"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-15T20:15:48Z",
"severity": "MODERATE"
},
"details": "IBM UCD - IBM DevOps Deploy 8.1 through 8.1.2.3 Deploy transmits data in clear text that could allow an attacker to obtain sensitive information using man in the middle techniques.",
"id": "GHSA-7m3h-x75f-vj4x",
"modified": "2025-12-15T21:30:31Z",
"published": "2025-12-15T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13489"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7254662"
}
],
"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-7M58-CRJP-GRQ7
Vulnerability from github – Published: 2024-12-17 18:33 – Updated: 2024-12-17 18:33IBM Security Guardium Key Lifecycle Manager 4.1, 4.1.1, 4.2.0, and 4.2.1 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.
{
"affected": [],
"aliases": [
"CVE-2024-49820"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-17T18:15:24Z",
"severity": "LOW"
},
"details": "IBM Security Guardium Key Lifecycle Manager 4.1, 4.1.1, 4.2.0, and 4.2.1\u00a0could 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.",
"id": "GHSA-7m58-crjp-grq7",
"modified": "2024-12-17T18:33:50Z",
"published": "2024-12-17T18:33:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49820"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7175067"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7MJ9-2MP8-4M2P
Vulnerability from github – Published: 2026-09-08 20:45 – Updated: 2026-09-08 20:45Summary
httpcore2 does not start TLS for wss:// connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure wss scheme.
The transport flaw affects httpcore2 releases before 2.10.0. HTTPX2 exposed this behavior through its public Client.websocket() and AsyncClient.websocket() APIs from 2.6.0 through 2.9.1.
Details
The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is https. The equivalent check does not include wss. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.
For example, an application using HTTPX2 2.6.0 through 2.9.1 may open an authenticated WebSocket through a SOCKS proxy:
import httpx2
with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
with client.websocket(
"wss://service.example/private?token=query-secret",
headers={"Authorization": "Bearer header-secret"},
cookies={"session": "cookie-secret"},
) as websocket:
websocket.send_text("private message")
On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:
GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret
Before HTTPX2 2.6.0, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.
A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged 101 Switching Protocols response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.
RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A wss URI promises confidentiality, integrity, and endpoint authentication through TLS.
Impact
An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.
Only wss:// connections routed through a SOCKS5 proxy are affected. Direct wss:// connections and ordinary https:// requests through SOCKS already start TLS correctly.
Mitigation
Upgrade HTTPX2 and httpcore2 to 2.10.0 or later. Patched versions start TLS for both https and wss origins in the synchronous and asynchronous SOCKS5 connection paths.
If upgrading is not immediately possible, do not route wss:// connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "httpcore2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.10.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "httpx2"
},
"ranges": [
{
"events": [
{
"introduced": "2.6.0"
},
{
"fixed": "2.10.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-84381"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-08T20:45:18Z",
"nvd_published_at": "2026-09-02T19:18:08Z",
"severity": "HIGH"
},
"details": "### Summary\n\nhttpcore2 does not start TLS for `wss://` connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure `wss` scheme.\n\nThe transport flaw affects httpcore2 releases before `2.10.0`. HTTPX2 exposed this behavior through its public `Client.websocket()` and `AsyncClient.websocket()` APIs from `2.6.0` through `2.9.1`.\n\n### Details\n\nThe synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is `https`. The equivalent check does not include `wss`. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.\n\nFor example, an application using HTTPX2 `2.6.0` through `2.9.1` may open an authenticated WebSocket through a SOCKS proxy:\n\n```python\nimport httpx2\n\nwith httpx2.Client(proxy=\"socks5://proxy.example:1080\") as client:\n with client.websocket(\n \"wss://service.example/private?token=query-secret\",\n headers={\"Authorization\": \"Bearer header-secret\"},\n cookies={\"session\": \"cookie-secret\"},\n ) as websocket:\n websocket.send_text(\"private message\")\n```\n\nOn affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:\n\n```text\nGET /private?token=query-secret HTTP/1.1\nHost: service.example\nAuthorization: Bearer header-secret\nCookie: session=cookie-secret\n```\n\nBefore HTTPX2 `2.6.0`, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.\n\nA normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged `101 Switching Protocols` response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.\n\nRFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A `wss` URI promises confidentiality, integrity, and endpoint authentication through TLS.\n\n### Impact\n\nAn attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.\n\nOnly `wss://` connections routed through a SOCKS5 proxy are affected. Direct `wss://` connections and ordinary `https://` requests through SOCKS already start TLS correctly.\n\n### Mitigation\n\nUpgrade HTTPX2 and httpcore2 to `2.10.0` or later. Patched versions start TLS for both `https` and `wss` origins in the synchronous and asynchronous SOCKS5 connection paths.\n\nIf upgrading is not immediately possible, do not route `wss://` connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.",
"id": "GHSA-7mj9-2mp8-4m2p",
"modified": "2026-09-08T20:45:18Z",
"published": "2026-09-08T20:45:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pydantic/httpx2/security/advisories/GHSA-7mj9-2mp8-4m2p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84381"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/httpx2/pull/1104"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/httpx2/commit/fb008dd700b761d955210d9692475c3e2f379453"
},
{
"type": "PACKAGE",
"url": "https://github.com/pydantic/httpx2"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/httpx2/releases/tag/v2.10.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies"
}
GHSA-7MRX-FCMQ-PHM5
Vulnerability from github – Published: 2022-05-24 17:41 – Updated: 2022-05-24 17:41An internal product security audit of Lenovo XClarity Administrator (LXCA) prior to version 3.1.0 discovered the Windows OS credentials provided by the LXCA user to perform driver updates of managed systems may be captured in the First Failure Data Capture (FFDC) service log if the service log is generated while managed endpoints are updating. The service log is only generated when requested by a privileged LXCA user and it is only accessible to the privileged LXCA user that requested the file and is then deleted.
{
"affected": [],
"aliases": [
"CVE-2020-8355"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-10T21:15:00Z",
"severity": "MODERATE"
},
"details": "An internal product security audit of Lenovo XClarity Administrator (LXCA) prior to version 3.1.0 discovered the Windows OS credentials provided by the LXCA user to perform driver updates of managed systems may be captured in the First Failure Data Capture (FFDC) service log if the service log is generated while managed endpoints are updating. The service log is only generated when requested by a privileged LXCA user and it is only accessible to the privileged LXCA user that requested the file and is then deleted.",
"id": "GHSA-7mrx-fcmq-phm5",
"modified": "2022-05-24T17:41:43Z",
"published": "2022-05-24T17:41:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8355"
},
{
"type": "WEB",
"url": "https://support.lenovo.com/us/en/product_security/LEN-50446"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7P73-4949-HJV7
Vulnerability from github – Published: 2022-05-13 01:36 – Updated: 2022-05-13 01:36The client-forwarder in Elastic Cloud Enterprise versions prior to 1.0.2 do not properly encrypt traffic to ZooKeeper. If an attacker is able to man in the middle (MITM) the traffic between the client-forwarder and ZooKeeper they could potentially obtain sensitive data.
{
"affected": [],
"aliases": [
"CVE-2017-8444"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-09-29T01:34:00Z",
"severity": "MODERATE"
},
"details": "The client-forwarder in Elastic Cloud Enterprise versions prior to 1.0.2 do not properly encrypt traffic to ZooKeeper. If an attacker is able to man in the middle (MITM) the traffic between the client-forwarder and ZooKeeper they could potentially obtain sensitive data.",
"id": "GHSA-7p73-4949-hjv7",
"modified": "2022-05-13T01:36:10Z",
"published": "2022-05-13T01:36:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8444"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/elastic-cloud-enterprise-1-0-2-security-update/100247"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7QMQ-34HQ-J5MX
Vulnerability from github – Published: 2024-01-17 09:30 – Updated: 2024-01-20 03:30This vulnerability exist in Skyworth Router CM5100, version 4.1.1.24, due to transmission of authentication credentials in plaintext over the network. A remote attacker could exploit this vulnerability by eavesdropping on the victim’s network traffic to extract username and password from the web interface (Login Page) of the vulnerable targeted system.
{
"affected": [],
"aliases": [
"CVE-2023-51740"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-17T08:15:37Z",
"severity": "HIGH"
},
"details": "This vulnerability exist in Skyworth Router CM5100, version 4.1.1.24, due to transmission of authentication credentials in plaintext over the network. A remote attacker could exploit this vulnerability by eavesdropping on the victim\u2019s network traffic to extract username and password from the web interface (Login Page) of the vulnerable targeted system.",
"id": "GHSA-7qmq-34hq-j5mx",
"modified": "2024-01-20T03:30:29Z",
"published": "2024-01-17T09:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51740"
},
{
"type": "WEB",
"url": "https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES01\u0026VLCODE=CIVN-2024-0013"
}
],
"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"
}
]
}
GHSA-7R65-PJGV-H2H9
Vulnerability from github – Published: 2022-07-01 00:01 – Updated: 2023-10-27 20:00Jenkins OpsGenie Plugin 1.9 and earlier stores API keys unencrypted in its global configuration file com.opsgenie.integration.jenkins.OpsGenieNotifier.xml and in job config.xml files on the Jenkins controller as part of its configuration.
Additionally, they are transmitted in plain text as part of the respective configuration forms.
These API keys can be viewed by users with Item/Extended Read permission (job config.xml only) or access to the Jenkins controller file system (both).
As of publication of this advisory, there is no fix.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:opsgenie"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-34804"
],
"database_specific": {
"cwe_ids": [
"CWE-319"
],
"github_reviewed": true,
"github_reviewed_at": "2022-07-13T15:44:03Z",
"nvd_published_at": "2022-06-30T18:15:00Z",
"severity": "MODERATE"
},
"details": "Jenkins OpsGenie Plugin 1.9 and earlier stores API keys unencrypted in its global configuration file `com.opsgenie.integration.jenkins.OpsGenieNotifier.xml` and in job `config.xml` files on the Jenkins controller as part of its configuration.\n\nAdditionally, they are transmitted in plain text as part of the respective configuration forms.\n\nThese API keys can be viewed by users with Item/Extended Read permission (job `config.xml` only) or access to the Jenkins controller file system (both).\n\nAs of publication of this advisory, there is no fix.",
"id": "GHSA-7r65-pjgv-h2h9",
"modified": "2023-10-27T20:00:57Z",
"published": "2022-07-01T00:01:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34804"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/opsgenie-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2022-06-30/#SECURITY-1877"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Jenkins OpsGenie Plugin vulnerable to Cleartext Transmission of Sensitive Information"
}
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.