Common Weakness Enumeration

CWE-200

Weakness Discouraged

Exposure of Sensitive Information to an Unauthorized Actor

Abstraction: Class · Status: Draft

The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

Technical nuance

There are many different kinds of mistakes that introduce information exposures. The severity of the error can range widely, depending on the context in which the product operates, the type of sensitive information that is revealed, and the benefits it may provide to an attacker. Some kinds of sensitive information include:

private, personal information, such as personal messages, financial data, health records, geographic location, or contact details

system status and environment, such as the operating system and installed packages

business secrets and intellectual property

network status and configuration

the product's own code or internal state

metadata, e.g. logging of connections or message headers

indirect information, such as a discrepancy between two internal operations that can be observed by an outsider

Information might be sensitive to different parties, each of which may have their own expectations for whether the information should be protected. These parties include:

the product's own users

people or organizations whose information is created or used by the product, even if they are not direct product users

the product's administrators, including the admins of the system(s) and/or networks on which the product operates

the developer

Information exposures can occur in different ways:

the code explicitly inserts sensitive information into resources or messages that are intentionally made accessible to unauthorized actors, but should not contain the information - i.e., the information should have been "scrubbed" or "sanitized"

a different weakness or mistake indirectly inserts the sensitive information into resources, such as a web script error revealing the full system path of the program.

the code manages resources that intentionally contain sensitive information, but the resources are unintentionally made accessible to unauthorized actors. In this case, the information exposure is resultant - i.e., a different weakness enabled the access to the information in the first place.

Mapping guidance

CWE-200 and its lower-level descendants are intended to cover the mistakes that occur in behaviors that explicitly manage, store, transfer, or cleanse sensitive information. Unfortunately, CWE-200 is commonly misused to represent the loss of confidentiality in a vulnerability. From the CWE perspective, loss of confidentiality is a technical impact, not a root cause error. Loss of confidentiality can arize from many different weaknesses, such as insecure file permissions or out-of-bounds read. As of CWE 4.20, over 400 CWE entries can lead to a loss of confidentiality. Other options are often available. [REF-1287].

If an error or mistake causes information to be disclosed, then use the CWE ID for that error.

Relationships and members
ChildOf: CWE-668 · View CWE-1000
Modes of introduction
Architecture and Design
Implementation
Detection methods

Automated Static Analysis - Binary or Bytecode

According to SOAR [REF-1479], the following detection techniques may be useful:

Cost effective for partial coverage:

Bytecode Weakness Analysis - including disassembler + source code weakness analysis

Inter-application Flow Analysis

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR [REF-1479], the following detection techniques may be useful:

Highly cost effective:

Web Application Scanner

Web Services Scanner

Database Scanners

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

According to SOAR [REF-1479], the following detection techniques may be useful:

Cost effective for partial coverage:

Fuzz Tester

Framework-based Fuzzer

Automated Monitored Execution

Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR [REF-1479], the following detection techniques may be useful:

Highly cost effective:

Manual Source Code Review (not inspections)

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR [REF-1479], the following detection techniques may be useful:

Highly cost effective:

Context-configured Source Code Weakness Analyzer

Cost effective for partial coverage:

Source code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

According to SOAR [REF-1479], the following detection techniques may be useful:

Highly cost effective:

Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

Attack Modeling

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

Content history
Submission: PLOVER · 2006-07-19 · CWE Draft 3
Contribution: Nick Johnston · 2022-07-11 · CWE 4.9

Identified incorrect language tag in demonstrative example.

Modification: Eric Dalci · Cigital · 2008-07-01 · CWE 1.0

updated Time_of_Introduction

Modification: CWE Content Team · MITRE · 2008-09-08 · CWE 1.0

updated Likelihood_of_Exploit, Relationships, Taxonomy_Mappings, Weakness_Ordinalities

Modification: CWE Content Team · MITRE · 2008-10-14 · CWE 1.0.1

updated Description

Modification: CWE Content Team · MITRE · 2009-12-28 · CWE 1.7

updated Alternate_Terms, Description, Name

Modification: CWE Content Team · MITRE · 2010-02-16 · CWE 1.8

updated Taxonomy_Mappings

Modification: CWE Content Team · MITRE · 2010-04-05 · CWE 1.8.1

updated Related_Attack_Patterns

Modification: CWE Content Team · MITRE · 2011-03-29 · CWE 1.12

updated Description, Relationships

Modification: CWE Content Team · MITRE · 2011-06-01 · CWE 1.13

updated Common_Consequences

Modification: CWE Content Team · MITRE · 2012-05-11 · CWE 2.2

updated Related_Attack_Patterns, Relationships

Modification: CWE Content Team · MITRE · 2012-10-30 · CWE 2.3

updated Potential_Mitigations

Modification: CWE Content Team · MITRE · 2013-02-21 · CWE 2.4

updated Alternate_Terms, Applicable_Platforms, References

Modification: CWE Content Team · MITRE · 2014-06-23 · CWE 2.7

updated Related_Attack_Patterns

Modification: CWE Content Team · MITRE · 2014-07-30 · CWE 2.8

updated Detection_Factors, Relationships

Modification: CWE Content Team · MITRE · 2015-12-07 · CWE 2.9

updated Relationships

Modification: CWE Content Team · MITRE · 2017-05-03 · CWE 2.11

updated Related_Attack_Patterns

Modification: CWE Content Team · MITRE · 2017-11-08 · CWE 3.0

updated References

Modification: CWE Content Team · MITRE · 2019-01-03 · CWE 3.2

updated Related_Attack_Patterns

Modification: CWE Content Team · MITRE · 2019-06-20 · CWE 3.3

updated Related_Attack_Patterns, Relationships

Modification: CWE Content Team · MITRE · 2019-09-19 · CWE 3.4

updated Demonstrative_Examples, Observed_Examples, Relationships

Modification: CWE Content Team · MITRE · 2020-02-24 · CWE 4.0

updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Observed_Examples, Related_Attack_Patterns, Relationships, Weakness_Ordinalities

Modification: CWE Content Team · MITRE · 2020-06-25 · CWE 4.1

updated Relationships

Modification: CWE Content Team · MITRE · 2020-08-20 · CWE 4.2

updated Alternate_Terms, Description, Maintenance_Notes, Related_Attack_Patterns, Relationships

Modification: CWE Content Team · MITRE · 2020-12-10 · CWE 4.3

updated Potential_Mitigations

Modification: CWE Content Team · MITRE · 2021-07-20 · CWE 4.5

updated Relationships

Modification: CWE Content Team · MITRE · 2021-10-28 · CWE 4.6

updated Relationships

Modification: CWE Content Team · MITRE · 2022-10-13 · CWE 4.9

updated Demonstrative_Examples, Maintenance_Notes, Observed_Examples, References

Modification: CWE Content Team · MITRE · 2023-04-27 · CWE 4.11

updated References, Relationships

Modification: CWE Content Team · MITRE · 2023-06-29 · CWE 4.12

updated Mapping_Notes

Modification: CWE Content Team · MITRE · 2023-10-26 · CWE 4.13

updated Observed_Examples

Modification: CWE Content Team · MITRE · 2024-11-19 · CWE 4.16

updated Relationships

Modification: CWE Content Team · MITRE · 2025-04-03 · CWE 4.17

updated Relationships

Modification: CWE Content Team · MITRE · 2025-09-09 · CWE 4.18

updated Detection_Factors, References

Modification: CWE Content Team · MITRE · 2025-12-11 · CWE 4.19

updated Applicable_Platforms, Relationships

Modification: CWE Content Team · MITRE · 2026-04-30 · CWE 4.20

updated Maintenance_Notes, Mapping_Notes

Modification: CWE Content Team · MITRE · 2026-10-28 · CWE 5.0

updated Alternate_Terms, Description, Mapping_Notes, Relationships, Technical_Nuance

16439 vulnerabilities reference this CWE, most recent first.

GHSA-MP48-5296-PCMP

Vulnerability from github – Published: 2022-05-17 00:19 – Updated: 2022-05-17 00:19
VLAI
Details

An issue was discovered on Siemens SICAM RTUs SM-2556 COM Modules with the firmware variants ENOS00, ERAC00, ETA2, ETLS00, MODi00, and DNPi00. The integrated web server (port 80/tcp) of the affected devices could allow unauthenticated remote attackers to obtain sensitive device information over the network.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-12737"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-11-15T08:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered on Siemens SICAM RTUs SM-2556 COM Modules with the firmware variants ENOS00, ERAC00, ETA2, ETLS00, MODi00, and DNPi00. The integrated web server (port 80/tcp) of the affected devices could allow unauthenticated remote attackers to obtain sensitive device information over the network.",
  "id": "GHSA-mp48-5296-pcmp",
  "modified": "2022-05-17T00:19:36Z",
  "published": "2022-05-17T00:19:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12737"
    },
    {
      "type": "WEB",
      "url": "https://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-164516.pdf"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/101884"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MP4F-C4M3-GXR6

Vulnerability from github – Published: 2026-05-06 15:32 – Updated: 2026-05-07 18:30
VLAI
Details

HCL BigFix Service Management (SM) is affected by an Information Disclosure – Server Banner issue was identified. Exposed server banners may reveal software versions and system details, potentially aiding attackers in targeting known vulnerabilities.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-31975"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-06T15:16:05Z",
    "severity": "LOW"
  },
  "details": "HCL BigFix Service Management (SM) is affected by an Information Disclosure \u2013 Server Banner issue was identified. Exposed server banners may reveal software versions and system details, potentially aiding attackers in targeting known vulnerabilities.",
  "id": "GHSA-mp4f-c4m3-gxr6",
  "modified": "2026-05-07T18:30:37Z",
  "published": "2026-05-06T15:32:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31975"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0128144"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MP53-W922-JJFF

Vulnerability from github – Published: 2022-05-14 01:42 – Updated: 2022-05-14 01:42
VLAI
Details

imcat 4.4 allows remote attackers to read phpinfo output via the root/tools/adbug/binfo.php?phpinfo1 URI.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-20608"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-12-30T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "imcat 4.4 allows remote attackers to read phpinfo output via the root/tools/adbug/binfo.php?phpinfo1 URI.",
  "id": "GHSA-mp53-w922-jjff",
  "modified": "2022-05-14T01:42:01Z",
  "published": "2022-05-14T01:42:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-20608"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AvaterXXX/CVEs/blob/master/imcat.md#information-disclosure"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MP59-VRH9-V8W9

Vulnerability from github – Published: 2022-05-17 00:24 – Updated: 2022-05-17 00:24
VLAI
Details

Mahara 15.04 before 15.04.13 and 16.04 before 16.04.7 and 16.10 before 16.10.4 and 17.04 before 17.04.2 are vulnerable to recording plain text passwords in the event_log table during the user creation process if full event logging was turned on.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-1000157"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-11-03T18:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Mahara 15.04 before 15.04.13 and 16.04 before 16.04.7 and 16.10 before 16.10.4 and 17.04 before 17.04.2 are vulnerable to recording plain text passwords in the event_log table during the user creation process if full event logging was turned on.",
  "id": "GHSA-mp59-vrh9-v8w9",
  "modified": "2022-05-17T00:24:42Z",
  "published": "2022-05-17T00:24:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1000157"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/mahara/+bug/1692749"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MP62-WJ23-FC7F

Vulnerability from github – Published: 2026-09-16 06:31 – Updated: 2026-09-17 15:31
VLAI
Details

The Subscriptions for WooCommerce WordPress plugin before 2.0.3 does not correctly validate the shared secret protecting one of its REST endpoints, allowing unauthenticated users to retrieve the store's full list of subscriptions, including customer usernames, product names, recurring amounts and payment dates.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-87854"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-16T06:16:35Z",
    "severity": "MODERATE"
  },
  "details": "The Subscriptions for WooCommerce WordPress plugin before 2.0.3 does not correctly validate the shared secret protecting one of its REST endpoints, allowing unauthenticated users to retrieve the store\u0027s full list of subscriptions, including customer usernames, product names, recurring amounts and payment dates.",
  "id": "GHSA-mp62-wj23-fc7f",
  "modified": "2026-09-17T15:31:55Z",
  "published": "2026-09-16T06:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87854"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/a47ee557-3036-485a-91ad-af7b84209294"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MP66-8WW2-PCWM

Vulnerability from github – Published: 2026-10-28 21:05 – Updated: 2026-10-28 21:05
VLAI
Summary
GraphQL Tools: Shared legacy executor routes one subscription's results to a different caller
Details

Cross-tenant subscription data leak in @graphql-tools/executor-legacy-ws: a shared websocket.onmessage is replaced on every subscribe(), and DATA frames are delivered without checking the protocol operation id

Report metadata

Field Value
Package @graphql-tools/executor-legacy-ws (npm, pkg:npm/%40graphql-tools/executor-legacy-ws)
Repository https://github.com/ardatan/graphql-tools
Component buildWSLegacyExecutor → the returned executor's subscribe(observer) / websocket.onmessage handler
Vulnerability class Cross-tenant data leak (subscription results delivered to the wrong caller)
Verified against Source at b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1 (package version 1.1.33); published npm tarball 1.1.33 with matching source at d304214db06e8a4ce9cb41138f199e3bc6ed36f2; the same behaviour also reproduces on the current release 1.1.35
API surface Public documented API (buildWSLegacyExecutor)
Affected in default configuration Yes — ensureWebsocket() reuses an already-OPEN socket (index.ts:35-42), and the socket has a single mutable onmessage property (index.ts:113). No single-operation-only restriction is documented, and the return type is the general reusable DisposableExecutor (packages/utils/src/executor.ts:34-57)

Affected version range: the range recorded for this finding is <= 1.1.33, but that is understated — the same proof of concept reproduces on 1.1.35, and a byte diff of the built CJS output between 1.1.33 and 1.1.35 shows only one unrelated change (rejectUnauthorized).

Summary

buildWSLegacyExecutor keeps one WebSocket in closure state and installs the message handler by assigning to the socket's single websocket.onmessage property inside subscribe(). Every new subscription therefore overwrites the previous subscriber's handler, and the handler's case LEGACY_WS.DATA branch calls observer.next(data.payload) without ever comparing data.id to the operation id that this subscription created at line 103 and sent with START at line 123. When one executor instance is reused for overlapping subscriptions, the most recent caller receives payloads belonging to the earlier caller, and the earlier caller receives nothing.

In a consuming application, the tainted input is an ordinary, correctly-tagged DATA frame emitted by the legitimate downstream server for the victim's operation. The attacker does not need to control or compromise that server; they only need to be able to start their own subscription through the same shared executor while the victim's subscription is active — the natural shape of a gateway, stitched schema, or any service that builds a remote executor once and reuses it per request.

The surrounding code shows the inconsistency:

  • packages/loaders/url/src/index.ts:262-295 (in-repo UrlLoader wrapper) → constructs a fresh legacy executor inside each request, so that caller avoids the shared state.
  • buildWSLegacyExecutor's returned executor, reused across callers → unsafe: shared onmessage overwritten at line 113, DATA dispatched without an id check at lines 145-147.
  • packages/loaders/url/src/index.ts:172-182 → also a production caller of the legacy executor; safe only insofar as the wrapper above rebuilds the executor per request, not because of any check in the executor itself.

Impact

A user of a service that shares one legacy executor receives another user's private GraphQL subscription payloads verbatim, with the victim's authorization context, without ever having been authorized for that operation. The victim is simultaneously starved: their own iterator stops receiving the events they subscribed to, because their handler has been detached.

Without this bug, the attacker's observer would receive only results for their own operation — and in this implementation, no result at all, since their operation is never STARTed after CONNECTION_ACK has already fired. The new capability is therefore reading data the attacker could not otherwise obtain by any request they are permitted to make, plus a denial of the victim's subscription stream.

Scoring note: no CVSS vector was computed for this finding, because exploitability depends on the consuming application's data flow — specifically whether one executor instance is shared across mutually untrusted callers. Consumers that construct a new executor per operation (as the in-repo UrlLoader wrapper does at packages/loaders/url/src/index.ts:262-295) are not affected by the cross-caller leak. The set of affected downstream consumers has not been enumerated: unknown.

Preconditions

  1. One executor value returned by buildWSLegacyExecutor is reused rather than constructing a new executor per operation. This is the normal use of an Executor: the contract is invoked once per ExecutionRequest, the code explicitly reuses an OPEN socket, and the returned value holds Symbol.dispose.
  2. Two subscription iterators overlap on an already-OPEN socket. The deciding default is in ensureWebsocket() (packages/executors/legacy-ws/src/index.ts:35-42), which does not create a second socket when one is open, combined with the single mutable websocket.onmessage assignment at line 113.
  3. The attacker can cause their own subscription request to be made through that shared executor while the victim's subscription is active and acknowledged. They do not need any control over the downstream server.
  4. Downstream subscription results differ by user or authorization context, so a misrouted payload is actually a disclosure.

This does not require non-standard usage, monkey-patching, or unusual configuration. packages/executors/legacy-ws/src/index.ts documents no single-operation-only restriction, the return type is the general reusable DisposableExecutor (packages/utils/src/executor.ts:34-57), and the behaviour is not documented as a caller responsibility.

Data flow

  1. Source — a legitimate DATA message emitted by the downstream server for another operation on the shared WebSocket. The victim invokes the returned executor, and subscribe() installs a closure over the victim's observer and request as websocket.onmessage (packages/executors/legacy-ws/src/index.ts:90-113).
  2. Propagation — the server's CONNECTION_ACK starts the victim's operation with id, created at line 103 and sent with START at line 123 (packages/executors/legacy-ws/src/index.ts:116-135).
  3. Sink — the attacker invokes the same executor while websocket.readyState is OPEN; ensureWebsocket() does not create a new socket and subscribe() replaces the sole websocket.onmessage with the attacker's closure (index.ts:35-42, index.ts:109-113). The server's DATA frame for the victim carries the victim's operation id per the legacy protocol, but the handler ignores data.id and calls observer.next(data.payload) on the attacker's observer (index.ts:114-147).
  4. Reachability — the sink sits in the only subscribe path of the executor produced by the directly exported buildWSLegacyExecutor (index.ts:27-31). packages/loaders/url/src/index.ts:172-182 is a production caller in this repository; direct library consumers reach it by building a remote executor once and reusing it.

Vulnerable code

packages/executors/legacy-ws/src/index.ts, lines 103-167 at b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1:

const id = Date.now().toString();
return observableToAsyncIterable({
  subscribe(observer) {
    ensureWebsocket();
    ...
    websocket.onmessage = event => {           // sole handler: overwritten by every new subscribe()
      const data = JSON.parse(event.data.toString('utf-8'));
      switch (data.type) {
        ...
        case LEGACY_WS.DATA: {
          observer.next(data.payload);         // SINK: data.id is never compared with id
          break;
        }
      }
    };
  },
});

Two independent defects are visible here: the single mutable onmessage assignment (which detaches the earlier subscriber), and the missing data.id === id check in the DATA branch (which misroutes the payload). The operation id itself is also derived from Date.now(), so it is not collision-resistant.

Reproduction

Verified dynamically against the real published package @graphql-tools/executor-legacy-ws@1.1.33 (npm tarball with matching source at d304214db06e8a4ce9cb41138f199e3bc6ed36f2). The harness was a protocol-correct legacy graphql-ws server (ws v8) that tags every DATA frame with the operation id of the operation that produced it, plus two callers sharing one executor instance.

  • Scenario A (control, single subscription): the subscriber received its own payload, confirming the harness is sound.
  • Scenario B (the claim): caller 1 ("victim") subscribed; the server ACKed and the client sent start id=1790247741390. Caller 2 ("attacker") then invoked the same executor while readyState was OPEN. The server observed only one socket (ensureWebsocket reused it) and only one started operation — the attacker's operation was never started, because CONNECTION_ACK had already fired. The server then emitted a correctly-tagged DATA frame for the victim's id. The attacker's iterator received {"data":{"victimSecret":"VICTIM-PRIVATE-DATA-a1b2c3"}} and the victim's iterator received nothing.
  • Scenario C: a DATA frame tagged with the id "id-that-was-never-started" was still delivered to the subscriber, proving the protocol operation id is never validated.
  • Realistic wiring: with the executor wired into wrapSchema() the way a stitching gateway does, two concurrent users subscribing to the same field produced a verbatim cross-tenant leak — User B received {"data":{"accountBalance":"USER-A-PRIVATE-BALANCE-$91402.11"}} while User A received nothing. When the two users select different fields, the wrap layer's result transform masks the foreign field (B saw weather:null), but the misrouting still occurs and the victim is still starved; at the raw executor API the payload leaks verbatim regardless.
  • Causality control: patching only the DATA branch to check data.id === id eliminated the leak (the attacker received nothing, and the foreign-id frame was rejected), pinning the leak to the missing id check. Under that patch the victim still received nothing, confirming the second, independent defect: the single shared websocket.onmessage is overwritten on each subscribe(), detaching the earlier subscriber's handler entirely.
  • Scope caveat: the identical proof of concept also reproduces on the current latest release 1.1.35.

Minimal client-side shape:

import WebSocket from 'isomorphic-ws';
import { parse } from 'graphql';
import { buildWSLegacyExecutor } from '@graphql-tools/executor-legacy-ws';

const exec = buildWSLegacyExecutor('ws://localhost:8081/graphql', WebSocket);

const victim = exec({ document: parse('subscription { privateEvent { secret } }') });
const victimPending = victim.next(); // causes connection + START; wait until the server has ACKed
await new Promise(r => setTimeout(r, 100));

const attacker = exec({ document: parse('subscription { publicEvent { id } }') });
const attackerPending = attacker.next(); // overwrites socket.onmessage

// When the server now emits DATA for the victim's id, this prints the victim's secret.
console.log(await attackerPending);

Steps:

  1. Start a normal legacy subscriptions-transport-ws server with a private event subscription.
  2. Build one executor and call victimIterator.next() so the socket receives connection_ack and START for the victim.
  3. While that socket is OPEN, call attackerIterator.next() using the same executor.
  4. Emit one victim event from the server.

  5. Expected: a DATA frame is delivered only to the observer registered for data.id; the attacker's pending next() must never resolve with the victim's payload, and the victim keeps receiving their own events.

  6. Actual: the attacker's next() resolves with the victim's payload, and the victim's iterator receives nothing.

Suggested remediation

Dispatch protocol frames by operation id to the observer that started that operation, instead of routing every frame to whichever subscriber most recently overwrote the socket's sole onmessage handler.

// 1. Stop the misrouting: ignore frames that belong to another operation.
case LEGACY_WS.DATA: {
  if (data.id !== id) {
    break;
  }
  observer.next(data.payload);
  break;
}
// 2. Stop the handler overwrite: keep a registry of observers keyed by operation id
//    and install exactly one shared message listener for the socket.
const observers = new Map<string, Observer<any>>();

function ensureMessageHandler() {
  if (messageHandlerInstalled) return;
  messageHandlerInstalled = true;
  websocket.onmessage = event => {
    const data = JSON.parse(event.data.toString('utf-8'));
    const target = data.id != null ? observers.get(data.id) : undefined;
    // ... dispatch DATA / ERROR / COMPLETE to `target` only, and remove it on COMPLETE
  };
}

An alternative that keeps the current structure is to create a separate socket (and therefore a separate listener) per execution, as the in-repo UrlLoader wrapper effectively does today.

Notes:

  • The same id check is needed on the ERROR and COMPLETE branches, not just DATA; otherwise one operation's termination still tears down another's iterator.
  • The operation id is generated as Date.now().toString() (line 103), which is not collision-resistant — two subscriptions created in the same millisecond would share an id even after the dispatch fix. Use a counter or a random component.
  • The missing id check and the overwritten onmessage are two independent defects; fixing only the id check stops the leak but leaves the earlier subscriber permanently starved, as the causality control above showed.
  • packages/loaders/url/src/index.ts:262-295 already builds a fresh legacy executor inside each request, so that caller needs no change; the fix belongs in the executor itself, because the exported buildWSLegacyExecutor returns a general reusable DisposableExecutor.
  • No upstream advisory (CVE/GHSA), fix commit, or fixed version is known for this issue: unknown / not verified. The set of affected downstream consumers has likewise not been enumerated.

Suggested regression test alongside the existing packages/executors/legacy-ws test suite: with one executor shared by two overlapping subscriptions on an OPEN socket, assert that a DATA frame tagged with subscription A's operation id resolves only A's iterator and never B's, and that a DATA frame tagged with an id that was never started is dropped rather than delivered to the most recent subscriber.

Resolution

Fixed in @graphql-tools/executor-legacy-ws@1.1.36, which is published on npm. Each execution has its own socket, and data, error, and complete frames are delivered only when the protocol operation id matches. Upgrade to >=1.1.36.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.1.35"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@graphql-tools/executor-legacy-ws"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.36"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-118666"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-28T21:05:07Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "# Cross-tenant subscription data leak in `@graphql-tools/executor-legacy-ws`: a shared `websocket.onmessage` is replaced on every `subscribe()`, and `DATA` frames are delivered without checking the protocol operation id\n\n## Report metadata\n\n| Field | Value |\n| --- | --- |\n| Package | `@graphql-tools/executor-legacy-ws` (npm, `pkg:npm/%40graphql-tools/executor-legacy-ws`) |\n| Repository | https://github.com/ardatan/graphql-tools |\n| Component | `buildWSLegacyExecutor` \u2192 the returned executor\u0027s `subscribe(observer)` / `websocket.onmessage` handler |\n| Vulnerability class | Cross-tenant data leak (subscription results delivered to the wrong caller) |\n| Verified against | Source at `b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1` (package version 1.1.33); published npm tarball `1.1.33` with matching source at `d304214db06e8a4ce9cb41138f199e3bc6ed36f2`; the same behaviour also reproduces on the current release `1.1.35` |\n| API surface | Public documented API (`buildWSLegacyExecutor`) |\n| Affected in default configuration | Yes \u2014 `ensureWebsocket()` reuses an already-`OPEN` socket (`index.ts:35-42`), and the socket has a single mutable `onmessage` property (`index.ts:113`). No single-operation-only restriction is documented, and the return type is the general reusable `DisposableExecutor` (`packages/utils/src/executor.ts:34-57`) |\n\nAffected version range: the range recorded for this finding is `\u003c= 1.1.33`, but that is understated \u2014 the same proof of concept reproduces on `1.1.35`, and a byte diff of the built CJS output between `1.1.33` and `1.1.35` shows only one unrelated change (`rejectUnauthorized`).\n\n## Summary\n\n`buildWSLegacyExecutor` keeps one WebSocket in closure state and installs the message handler by assigning to the socket\u0027s single `websocket.onmessage` property inside `subscribe()`. Every new subscription therefore overwrites the previous subscriber\u0027s handler, and the handler\u0027s `case LEGACY_WS.DATA` branch calls `observer.next(data.payload)` without ever comparing `data.id` to the operation id that this subscription created at line 103 and sent with `START` at line 123. When one executor instance is reused for overlapping subscriptions, the most recent caller receives payloads belonging to the earlier caller, and the earlier caller receives nothing.\n\nIn a consuming application, the tainted input is an ordinary, correctly-tagged `DATA` frame emitted by the legitimate downstream server for the victim\u0027s operation. The attacker does not need to control or compromise that server; they only need to be able to start their own subscription through the same shared executor while the victim\u0027s subscription is active \u2014 the natural shape of a gateway, stitched schema, or any service that builds a remote executor once and reuses it per request.\n\nThe surrounding code shows the inconsistency:\n\n- `packages/loaders/url/src/index.ts:262-295` (in-repo `UrlLoader` wrapper) \u2192 constructs a fresh legacy executor inside each request, so that caller avoids the shared state.\n- `buildWSLegacyExecutor`\u0027s returned executor, reused across callers \u2192 **unsafe: shared `onmessage` overwritten at line 113, `DATA` dispatched without an id check at lines 145-147**.\n- `packages/loaders/url/src/index.ts:172-182` \u2192 also a production caller of the legacy executor; safe only insofar as the wrapper above rebuilds the executor per request, not because of any check in the executor itself.\n\n## Impact\n\nA user of a service that shares one legacy executor receives another user\u0027s private GraphQL subscription payloads verbatim, with the victim\u0027s authorization context, without ever having been authorized for that operation. The victim is simultaneously starved: their own iterator stops receiving the events they subscribed to, because their handler has been detached.\n\nWithout this bug, the attacker\u0027s observer would receive only results for their own operation \u2014 and in this implementation, no result at all, since their operation is never `START`ed after `CONNECTION_ACK` has already fired. The new capability is therefore reading data the attacker could not otherwise obtain by any request they are permitted to make, plus a denial of the victim\u0027s subscription stream.\n\nScoring note: no CVSS vector was computed for this finding, because exploitability depends on the consuming application\u0027s data flow \u2014 specifically whether one executor instance is shared across mutually untrusted callers. Consumers that construct a new executor per operation (as the in-repo `UrlLoader` wrapper does at `packages/loaders/url/src/index.ts:262-295`) are not affected by the cross-caller leak. The set of affected downstream consumers has not been enumerated: **unknown**.\n\n## Preconditions\n\n1. One executor value returned by `buildWSLegacyExecutor` is reused rather than constructing a new executor per operation. This is the normal use of an `Executor`: the contract is invoked once per `ExecutionRequest`, the code explicitly reuses an `OPEN` socket, and the returned value holds `Symbol.dispose`.\n2. Two subscription iterators overlap on an already-`OPEN` socket. The deciding default is in `ensureWebsocket()` (`packages/executors/legacy-ws/src/index.ts:35-42`), which does not create a second socket when one is open, combined with the single mutable `websocket.onmessage` assignment at line 113.\n3. The attacker can cause their own subscription request to be made through that shared executor while the victim\u0027s subscription is active and acknowledged. They do not need any control over the downstream server.\n4. Downstream subscription results differ by user or authorization context, so a misrouted payload is actually a disclosure.\n\nThis does **not** require non-standard usage, monkey-patching, or unusual configuration. `packages/executors/legacy-ws/src/index.ts` documents no single-operation-only restriction, the return type is the general reusable `DisposableExecutor` (`packages/utils/src/executor.ts:34-57`), and the behaviour is not documented as a caller responsibility.\n\n## Data flow\n\n1. **Source** \u2014 a legitimate `DATA` message emitted by the downstream server for *another* operation on the shared WebSocket. The victim invokes the returned executor, and `subscribe()` installs a closure over the victim\u0027s observer and request as `websocket.onmessage` ([`packages/executors/legacy-ws/src/index.ts:90-113`](https://github.com/ardatan/graphql-tools/blob/b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1/packages/executors/legacy-ws/src/index.ts#L90-L113)).\n2. **Propagation** \u2014 the server\u0027s `CONNECTION_ACK` starts the victim\u0027s operation with `id`, created at line 103 and sent with `START` at line 123 ([`packages/executors/legacy-ws/src/index.ts:116-135`](https://github.com/ardatan/graphql-tools/blob/b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1/packages/executors/legacy-ws/src/index.ts#L116-L135)).\n3. **Sink** \u2014 the attacker invokes the same executor while `websocket.readyState` is `OPEN`; `ensureWebsocket()` does not create a new socket and `subscribe()` replaces the sole `websocket.onmessage` with the attacker\u0027s closure ([`index.ts:35-42`](https://github.com/ardatan/graphql-tools/blob/b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1/packages/executors/legacy-ws/src/index.ts#L35-L42), [`index.ts:109-113`](https://github.com/ardatan/graphql-tools/blob/b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1/packages/executors/legacy-ws/src/index.ts#L109-L113)). The server\u0027s `DATA` frame for the victim carries the victim\u0027s operation id per the legacy protocol, but the handler ignores `data.id` and calls `observer.next(data.payload)` on the attacker\u0027s observer ([`index.ts:114-147`](https://github.com/ardatan/graphql-tools/blob/b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1/packages/executors/legacy-ws/src/index.ts#L114-L147)).\n4. **Reachability** \u2014 the sink sits in the only `subscribe` path of the executor produced by the directly exported `buildWSLegacyExecutor` ([`index.ts:27-31`](https://github.com/ardatan/graphql-tools/blob/b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1/packages/executors/legacy-ws/src/index.ts#L27-L31)). `packages/loaders/url/src/index.ts:172-182` is a production caller in this repository; direct library consumers reach it by building a remote executor once and reusing it.\n\n## Vulnerable code\n\n`packages/executors/legacy-ws/src/index.ts`, lines 103-167 at `b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1`:\n\n```ts\nconst id = Date.now().toString();\nreturn observableToAsyncIterable({\n  subscribe(observer) {\n    ensureWebsocket();\n    ...\n    websocket.onmessage = event =\u003e {           // sole handler: overwritten by every new subscribe()\n      const data = JSON.parse(event.data.toString(\u0027utf-8\u0027));\n      switch (data.type) {\n        ...\n        case LEGACY_WS.DATA: {\n          observer.next(data.payload);         // SINK: data.id is never compared with id\n          break;\n        }\n      }\n    };\n  },\n});\n```\n\nTwo independent defects are visible here: the single mutable `onmessage` assignment (which detaches the earlier subscriber), and the missing `data.id === id` check in the `DATA` branch (which misroutes the payload). The operation id itself is also derived from `Date.now()`, so it is not collision-resistant.\n\n## Reproduction\n\nVerified dynamically against the real published package `@graphql-tools/executor-legacy-ws@1.1.33` (npm tarball with matching source at `d304214db06e8a4ce9cb41138f199e3bc6ed36f2`). The harness was a protocol-correct legacy `graphql-ws` server (ws v8) that tags every `DATA` frame with the operation id of the operation that produced it, plus two callers sharing one executor instance.\n\n- **Scenario A (control, single subscription):** the subscriber received its own payload, confirming the harness is sound.\n- **Scenario B (the claim):** caller 1 (\"victim\") subscribed; the server ACKed and the client sent `start id=1790247741390`. Caller 2 (\"attacker\") then invoked the **same** executor while `readyState` was `OPEN`. The server observed only one socket (`ensureWebsocket` reused it) and only one started operation \u2014 the attacker\u0027s operation was never started, because `CONNECTION_ACK` had already fired. The server then emitted a correctly-tagged `DATA` frame for the victim\u0027s id. The attacker\u0027s iterator received `{\"data\":{\"victimSecret\":\"VICTIM-PRIVATE-DATA-a1b2c3\"}}` and the victim\u0027s iterator received nothing.\n- **Scenario C:** a `DATA` frame tagged with the id `\"id-that-was-never-started\"` was still delivered to the subscriber, proving the protocol operation id is never validated.\n- **Realistic wiring:** with the executor wired into `wrapSchema()` the way a stitching gateway does, two concurrent users subscribing to the same field produced a verbatim cross-tenant leak \u2014 User B received `{\"data\":{\"accountBalance\":\"USER-A-PRIVATE-BALANCE-$91402.11\"}}` while User A received nothing. When the two users select different fields, the wrap layer\u0027s result transform masks the foreign field (B saw `weather:null`), but the misrouting still occurs and the victim is still starved; at the raw executor API the payload leaks verbatim regardless.\n- **Causality control:** patching only the `DATA` branch to check `data.id === id` eliminated the leak (the attacker received nothing, and the foreign-id frame was rejected), pinning the leak to the missing id check. Under that patch the victim still received nothing, confirming the second, independent defect: the single shared `websocket.onmessage` is overwritten on each `subscribe()`, detaching the earlier subscriber\u0027s handler entirely.\n- **Scope caveat:** the identical proof of concept also reproduces on the current latest release `1.1.35`.\n\nMinimal client-side shape:\n\n```ts\nimport WebSocket from \u0027isomorphic-ws\u0027;\nimport { parse } from \u0027graphql\u0027;\nimport { buildWSLegacyExecutor } from \u0027@graphql-tools/executor-legacy-ws\u0027;\n\nconst exec = buildWSLegacyExecutor(\u0027ws://localhost:8081/graphql\u0027, WebSocket);\n\nconst victim = exec({ document: parse(\u0027subscription { privateEvent { secret } }\u0027) });\nconst victimPending = victim.next(); // causes connection + START; wait until the server has ACKed\nawait new Promise(r =\u003e setTimeout(r, 100));\n\nconst attacker = exec({ document: parse(\u0027subscription { publicEvent { id } }\u0027) });\nconst attackerPending = attacker.next(); // overwrites socket.onmessage\n\n// When the server now emits DATA for the victim\u0027s id, this prints the victim\u0027s secret.\nconsole.log(await attackerPending);\n```\n\nSteps:\n\n1. Start a normal legacy `subscriptions-transport-ws` server with a private event subscription.\n2. Build one executor and call `victimIterator.next()` so the socket receives `connection_ack` and `START` for the victim.\n3. While that socket is `OPEN`, call `attackerIterator.next()` using the same executor.\n4. Emit one victim event from the server.\n\n- **Expected:** a `DATA` frame is delivered only to the observer registered for `data.id`; the attacker\u0027s pending `next()` must never resolve with the victim\u0027s payload, and the victim keeps receiving their own events.\n- **Actual:** the attacker\u0027s `next()` resolves with the victim\u0027s payload, and the victim\u0027s iterator receives nothing.\n\n## Suggested remediation\n\nDispatch protocol frames by operation id to the observer that started that operation, instead of routing every frame to whichever subscriber most recently overwrote the socket\u0027s sole `onmessage` handler.\n\n```ts\n// 1. Stop the misrouting: ignore frames that belong to another operation.\ncase LEGACY_WS.DATA: {\n  if (data.id !== id) {\n    break;\n  }\n  observer.next(data.payload);\n  break;\n}\n```\n\n```ts\n// 2. Stop the handler overwrite: keep a registry of observers keyed by operation id\n//    and install exactly one shared message listener for the socket.\nconst observers = new Map\u003cstring, Observer\u003cany\u003e\u003e();\n\nfunction ensureMessageHandler() {\n  if (messageHandlerInstalled) return;\n  messageHandlerInstalled = true;\n  websocket.onmessage = event =\u003e {\n    const data = JSON.parse(event.data.toString(\u0027utf-8\u0027));\n    const target = data.id != null ? observers.get(data.id) : undefined;\n    // ... dispatch DATA / ERROR / COMPLETE to `target` only, and remove it on COMPLETE\n  };\n}\n```\n\nAn alternative that keeps the current structure is to create a separate socket (and therefore a separate listener) per execution, as the in-repo `UrlLoader` wrapper effectively does today.\n\nNotes:\n\n- The same id check is needed on the `ERROR` and `COMPLETE` branches, not just `DATA`; otherwise one operation\u0027s termination still tears down another\u0027s iterator.\n- The operation id is generated as `Date.now().toString()` (line 103), which is not collision-resistant \u2014 two subscriptions created in the same millisecond would share an id even after the dispatch fix. Use a counter or a random component.\n- The missing id check and the overwritten `onmessage` are two independent defects; fixing only the id check stops the leak but leaves the earlier subscriber permanently starved, as the causality control above showed.\n- `packages/loaders/url/src/index.ts:262-295` already builds a fresh legacy executor inside each request, so that caller needs no change; the fix belongs in the executor itself, because the exported `buildWSLegacyExecutor` returns a general reusable `DisposableExecutor`.\n- No upstream advisory (CVE/GHSA), fix commit, or fixed version is known for this issue: **unknown / not verified**. The set of affected downstream consumers has likewise not been enumerated.\n\nSuggested regression test alongside the existing `packages/executors/legacy-ws` test suite: with one executor shared by two overlapping subscriptions on an `OPEN` socket, assert that a `DATA` frame tagged with subscription A\u0027s operation id resolves only A\u0027s iterator and never B\u0027s, and that a `DATA` frame tagged with an id that was never started is dropped rather than delivered to the most recent subscriber.\n\n## Resolution\n\nFixed in `@graphql-tools/executor-legacy-ws@1.1.36`, which is published on npm. Each execution has its own socket, and `data`, `error`, and `complete` frames are delivered only when the protocol operation id matches. Upgrade to `\u003e=1.1.36`.",
  "id": "GHSA-mp66-8ww2-pcwm",
  "modified": "2026-10-28T21:05:08Z",
  "published": "2026-10-28T21:05:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ardatan/graphql-tools/security/advisories/GHSA-mp66-8ww2-pcwm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ardatan/graphql-tools/pull/8480"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ardatan/graphql-tools/commit/c2f226e6f68236be9e4a577f29faeaa92547458b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ardatan/graphql-tools"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ardatan/graphql-tools/releases/tag/@graphql-tools/executor-legacy-ws@1.1.36"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "GraphQL Tools: Shared legacy executor routes one subscription\u0027s results to a different caller"
}

GHSA-MP6J-74MQ-2VWH

Vulnerability from github – Published: 2022-05-17 02:35 – Updated: 2022-05-17 02:35
VLAI
Details

A vulnerability in the filesystem of the Cisco Prime Collaboration Provisioning tool could allow an authenticated, local attacker to acquire sensitive information. More Information: CSCvc82973. Known Affected Releases: 12.1.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-6705"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-07-04T00:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the filesystem of the Cisco Prime Collaboration Provisioning tool could allow an authenticated, local attacker to acquire sensitive information. More Information: CSCvc82973. Known Affected Releases: 12.1.",
  "id": "GHSA-mp6j-74mq-2vwh",
  "modified": "2022-05-17T02:35:46Z",
  "published": "2022-05-17T02:35:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6705"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170621-pcp3"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/99206"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1038744"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MP6X-6C2R-XCXV

Vulnerability from github – Published: 2026-10-19 12:32 – Updated: 2026-10-19 12:32
VLAI
Details

MISP contains a vulnerability in its server settings lookup mechanism that allows an authenticated user to retrieve sensitive configuration data that should have been redacted.

The settings lookup function resolves a dotted setting name to a node in the configuration tree. When a branch name (such as Security, MISP, or Plugin) is supplied instead of a specific leaf setting, the function returns the entire sub-tree. Because a branch node does not carry a redaction flag, the redaction check in the settings retrieval endpoint is bypassed, and the full branch contents are returned to the caller. This exposes sensitive values including the security salt, Redis connection passwords, and plugin API keys.

A second endpoint that edits server settings similarly reads the entire configuration store when a branch name is resolved, returning all settings to the caller.

The impact is disclosure of sensitive server configuration secrets to any user who can access the server settings endpoints.

Affected versions: <2.5.48.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-112188"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-19T10:16:47Z",
    "severity": "HIGH"
  },
  "details": "MISP contains a vulnerability in its server settings lookup mechanism that allows an authenticated user to retrieve sensitive configuration data that should have been redacted.\n\nThe settings lookup function resolves a dotted setting name to a node in the configuration tree. When a branch name (such as Security, MISP, or Plugin) is supplied instead of a specific leaf setting, the function returns the entire sub-tree. Because a branch node does not carry a redaction flag, the redaction check in the settings retrieval endpoint is bypassed, and the full branch contents are returned to the caller. This exposes sensitive values including the security salt, Redis connection passwords, and plugin API keys.\n\nA second endpoint that edits server settings similarly reads the entire configuration store when a branch name is resolved, returning all settings to the caller.\n\nThe impact is disclosure of sensitive server configuration secrets to any user who can access the server settings endpoints.\n\nAffected versions: \u003c2.5.48.",
  "id": "GHSA-mp6x-6c2r-xcxv",
  "modified": "2026-10-19T12:32:47Z",
  "published": "2026-10-19T12:32:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-112188"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/30b849102"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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-MP73-47R4-JRXH

Vulnerability from github – Published: 2022-05-24 17:06 – Updated: 2023-02-01 18:30
VLAI
Details

Ricoh SP C250DN 1.06 devices have Incorrect Access Control (issue 1 of 2).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-14301"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-01-10T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Ricoh SP C250DN 1.06 devices have Incorrect Access Control (issue 1 of 2).",
  "id": "GHSA-mp73-47r4-jrxh",
  "modified": "2023-02-01T18:30:24Z",
  "published": "2022-05-24T17:06:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14301"
    },
    {
      "type": "WEB",
      "url": "https://www.ricoh.com/info/2019/0823_1"
    },
    {
      "type": "WEB",
      "url": "http://jvn.jp/en/jp/JVN52962201/index.html"
    }
  ],
  "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-MP7G-3R25-FQ9V

Vulnerability from github – Published: 2023-09-01 12:30 – Updated: 2024-04-04 07:21
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions starting from 11.8 before 16.1.5, all versions starting from 16.2 before 16.2.5, all versions starting from 16.3 before 16.3.1. A malicious Maintainer can, under specific circumstances, leak the sentry token by changing the configured URL in the Sentry error tracking settings page. This was as a result of an incomplete fix for CVE-2022-4365.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-4378"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-201"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-01T11:15:43Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 11.8 before 16.1.5, all versions starting from 16.2 before 16.2.5, all versions starting from 16.3 before 16.3.1. A malicious Maintainer can, under specific circumstances, leak the sentry token by changing the configured URL in the Sentry error tracking settings page. This was as a result of an incomplete fix for CVE-2022-4365.",
  "id": "GHSA-mp7g-3r25-fq9v",
  "modified": "2024-04-04T07:21:31Z",
  "published": "2023-09-01T12:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4378"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2104591"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/422134"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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-116: Excavation

An adversary actively probes the target in a manner that is designed to solicit information that could be leveraged for malicious purposes.

CAPEC-13: Subverting Environment Variable Values

The adversary directly or indirectly modifies environment variables used by or controlling the target software. The adversary's goal is to cause the target software to deviate from its expected operation in a manner that benefits the adversary.

CAPEC-169: Footprinting

An adversary engages in probing and exploration activities to identify constituents and properties of the target.

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-224: Fingerprinting

An adversary compares output from a target system to known indicators that uniquely identify specific details about the target. Most commonly, fingerprinting is done to determine operating system and application versions. Fingerprinting can be done passively as well as actively. Fingerprinting by itself is not usually detrimental to the target. However, the information gathered through fingerprinting often enables an adversary to discover existing weaknesses in the target.

CAPEC-285: ICMP Echo Request Ping

An adversary sends out an ICMP Type 8 Echo Request, commonly known as a 'Ping', in order to determine if a target system is responsive. If the request is not blocked by a firewall or ACL, the target host will respond with an ICMP Type 0 Echo Reply datagram. This type of exchange is usually referred to as a 'Ping' due to the Ping utility present in almost all operating systems. Ping, as commonly implemented, allows a user to test for alive hosts, measure round-trip time, and measure the percentage of packet loss.

CAPEC-287: TCP SYN Scan

An adversary uses a SYN scan to determine the status of ports on the remote target. SYN scanning is the most common type of port scanning that is used because of its many advantages and few drawbacks. As a result, novice attackers tend to overly rely on the SYN scan while performing system reconnaissance. As a scanning method, the primary advantages of SYN scanning are its universality and speed.

CAPEC-290: Enumerate Mail Exchange (MX) Records

An adversary enumerates the MX records for a given via a DNS query. This type of information gathering returns the names of mail servers on the network. Mail servers are often not exposed to the Internet but are located within the DMZ of a network protected by a firewall. A side effect of this configuration is that enumerating the MX records for an organization my reveal the IP address of the firewall or possibly other internal systems. Attackers often resort to MX record enumeration when a DNS Zone Transfer is not possible.

CAPEC-291: DNS Zone Transfers

An attacker exploits a DNS misconfiguration that permits a ZONE transfer. Some external DNS servers will return a list of IP address and valid hostnames. Under certain conditions, it may even be possible to obtain Zone data about the organization's internal network. When successful the attacker learns valuable information about the topology of the target organization, including information about particular servers, their role within the IT structure, and possibly information about the operating systems running upon the network. This is configuration dependent behavior so it may also be required to search out multiple DNS servers while attempting to find one with ZONE transfers allowed.

CAPEC-292: Host Discovery

An adversary sends a probe to an IP address to determine if the host is alive. Host discovery is one of the earliest phases of network reconnaissance. The adversary usually starts with a range of IP addresses belonging to a target network and uses various methods to determine if a host is present at that IP address. Host discovery is usually referred to as 'Ping' scanning using a sonar analogy. The goal is to send a packet through to the IP address and solicit a response from the host. As such, a 'ping' can be virtually any crafted packet whatsoever, provided the adversary can identify a functional host based on its response. An attack of this nature is usually carried out with a 'ping sweep,' where a particular kind of ping is sent to a range of IP addresses.

CAPEC-293: Traceroute Route Enumeration

An adversary uses a traceroute utility to map out the route which data flows through the network in route to a target destination. Tracerouting can allow the adversary to construct a working topology of systems and routers by listing the systems through which data passes through on their way to the targeted machine. This attack can return varied results depending upon the type of traceroute that is performed. Traceroute works by sending packets to a target while incrementing the Time-to-Live field in the packet header. As the packet traverses each hop along its way to the destination, its TTL expires generating an ICMP diagnostic message that identifies where the packet expired. Traditional techniques for tracerouting involved the use of ICMP and UDP, but as more firewalls began to filter ingress ICMP, methods of traceroute using TCP were developed.

CAPEC-294: ICMP Address Mask Request

An adversary sends an ICMP Type 17 Address Mask Request to gather information about a target's networking configuration. ICMP Address Mask Requests are defined by RFC-950, "Internet Standard Subnetting Procedure." An Address Mask Request is an ICMP type 17 message that triggers a remote system to respond with a list of its related subnets, as well as its default gateway and broadcast address via an ICMP type 18 Address Mask Reply datagram. Gathering this type of information helps the adversary plan router-based attacks as well as denial-of-service attacks against the broadcast address.

CAPEC-295: Timestamp Request

This pattern of attack leverages standard requests to learn the exact time associated with a target system. An adversary may be able to use the timestamp returned from the target to attack time-based security algorithms, such as random number generators, or time-based authentication mechanisms.

CAPEC-296: ICMP Information Request

An adversary sends an ICMP Information Request to a host to determine if it will respond to this deprecated mechanism. ICMP Information Requests are a deprecated message type. Information Requests were originally used for diskless machines to automatically obtain their network configuration, but this message type has been superseded by more robust protocol implementations like DHCP.

CAPEC-297: TCP ACK Ping

An adversary sends a TCP segment with the ACK flag set to a remote host for the purpose of determining if the host is alive. This is one of several TCP 'ping' types. The RFC 793 expected behavior for a service is to respond with a RST 'reset' packet to any unsolicited ACK segment that is not part of an existing connection. So by sending an ACK segment to a port, the adversary can identify that the host is alive by looking for a RST packet. Typically, a remote server will respond with a RST regardless of whether a port is open or closed. In this way, TCP ACK pings cannot discover the state of a remote port because the behavior is the same in either case. The firewall will look up the ACK packet in its state-table and discard the segment because it does not correspond to any active connection. A TCP ACK Ping can be used to discover if a host is alive via RST response packets sent from the host.

CAPEC-298: UDP Ping

An adversary sends a UDP datagram to the remote host to determine if the host is alive. If a UDP datagram is sent to an open UDP port there is very often no response, so a typical strategy for using a UDP ping is to send the datagram to a random high port on the target. The goal is to solicit an 'ICMP port unreachable' message from the target, indicating that the host is alive. UDP pings are useful because some firewalls are not configured to block UDP datagrams sent to strange or typically unused ports, like ports in the 65K range. Additionally, while some firewalls may filter incoming ICMP, weaknesses in firewall rule-sets may allow certain types of ICMP (host unreachable, port unreachable) which are useful for UDP ping attempts.

CAPEC-299: TCP SYN Ping

An adversary uses TCP SYN packets as a means towards host discovery. Typical RFC 793 behavior specifies that when a TCP port is open, a host must respond to an incoming SYN "synchronize" packet by completing stage two of the 'three-way handshake' - by sending an SYN/ACK in response. When a port is closed, RFC 793 behavior is to respond with a RST "reset" packet. This behavior can be used to 'ping' a target to see if it is alive by sending a TCP SYN packet to a port and then looking for a RST or an ACK packet in response.

CAPEC-300: Port Scanning

An adversary uses a combination of techniques to determine the state of the ports on a remote target. Any service or application available for TCP or UDP networking will have a port open for communications over the network.

CAPEC-301: TCP Connect Scan

An adversary uses full TCP connection attempts to determine if a port is open on the target system. The scanning process involves completing a 'three-way handshake' with a remote port, and reports the port as closed if the full handshake cannot be established. An advantage of TCP connect scanning is that it works against any TCP/IP stack.

CAPEC-302: TCP FIN Scan

An adversary uses a TCP FIN scan to determine if ports are closed on the target machine. This scan type is accomplished by sending TCP segments with the FIN bit set in the packet header. The RFC 793 expected behavior is that any TCP segment with an out-of-state Flag sent to an open port is discarded, whereas segments with out-of-state flags sent to closed ports should be handled with a RST in response. This behavior should allow the adversary to scan for closed ports by sending certain types of rule-breaking packets (out of sync or disallowed by the TCB) and detect closed ports via RST packets.

CAPEC-303: TCP Xmas Scan

An adversary uses a TCP XMAS scan to determine if ports are closed on the target machine. This scan type is accomplished by sending TCP segments with all possible flags set in the packet header, generating packets that are illegal based on RFC 793. The RFC 793 expected behavior is that any TCP segment with an out-of-state Flag sent to an open port is discarded, whereas segments with out-of-state flags sent to closed ports should be handled with a RST in response. This behavior should allow an attacker to scan for closed ports by sending certain types of rule-breaking packets (out of sync or disallowed by the TCB) and detect closed ports via RST packets.

CAPEC-304: TCP Null Scan

An adversary uses a TCP NULL scan to determine if ports are closed on the target machine. This scan type is accomplished by sending TCP segments with no flags in the packet header, generating packets that are illegal based on RFC 793. The RFC 793 expected behavior is that any TCP segment with an out-of-state Flag sent to an open port is discarded, whereas segments with out-of-state flags sent to closed ports should be handled with a RST in response. This behavior should allow an attacker to scan for closed ports by sending certain types of rule-breaking packets (out of sync or disallowed by the TCB) and detect closed ports via RST packets.

CAPEC-305: TCP ACK Scan

An adversary uses TCP ACK segments to gather information about firewall or ACL configuration. The purpose of this type of scan is to discover information about filter configurations rather than port state. This type of scanning is rarely useful alone, but when combined with SYN scanning, gives a more complete picture of the type of firewall rules that are present.

CAPEC-306: TCP Window Scan

An adversary engages in TCP Window scanning to analyze port status and operating system type. TCP Window scanning uses the ACK scanning method but examine the TCP Window Size field of response RST packets to make certain inferences. While TCP Window Scans are fast and relatively stealthy, they work against fewer TCP stack implementations than any other type of scan. Some operating systems return a positive TCP window size when a RST packet is sent from an open port, and a negative value when the RST originates from a closed port. TCP Window scanning is one of the most complex scan types, and its results are difficult to interpret. Window scanning alone rarely yields useful information, but when combined with other types of scanning is more useful. It is a generally more reliable means of making inference about operating system versions than port status.

CAPEC-307: TCP RPC Scan

An adversary scans for RPC services listing on a Unix/Linux host.

CAPEC-308: UDP Scan

An adversary engages in UDP scanning to gather information about UDP port status on the target system. UDP scanning methods involve sending a UDP datagram to the target port and looking for evidence that the port is closed. Open UDP ports usually do not respond to UDP datagrams as there is no stateful mechanism within the protocol that requires building or establishing a session. Responses to UDP datagrams are therefore application specific and cannot be relied upon as a method of detecting an open port. UDP scanning relies heavily upon ICMP diagnostic messages in order to determine the status of a remote port.

CAPEC-309: Network Topology Mapping

An adversary engages in scanning activities to map network nodes, hosts, devices, and routes. Adversaries usually perform this type of network reconnaissance during the early stages of attack against an external network. Many types of scanning utilities are typically employed, including ICMP tools, network mappers, port scanners, and route testing utilities such as traceroute.

CAPEC-310: Scanning for Vulnerable Software

An attacker engages in scanning activity to find vulnerable software versions or types, such as operating system versions or network services. Vulnerable or exploitable network configurations, such as improperly firewalled systems, or misconfigured systems in the DMZ or external network, provide windows of opportunity for an attacker. Common types of vulnerable software include unpatched operating systems or services (e.g FTP, Telnet, SMTP, SNMP) running on open ports that the attacker has identified. Attackers usually begin probing for vulnerable software once the external network has been port scanned and potential targets have been revealed.

CAPEC-312: Active OS Fingerprinting

An adversary engages in activity to detect the operating system or firmware version of a remote target by interrogating a device, server, or platform with a probe designed to solicit behavior that will reveal information about the operating systems or firmware in the environment. Operating System detection is possible because implementations of common protocols (Such as IP or TCP) differ in distinct ways. While the implementation differences are not sufficient to 'break' compatibility with the protocol the differences are detectable because the target will respond in unique ways to specific probing activity that breaks the semantic or logical rules of packet construction for a protocol. Different operating systems will have a unique response to the anomalous input, providing the basis to fingerprint the OS behavior. This type of OS fingerprinting can distinguish between operating system types and versions.

CAPEC-313: Passive OS Fingerprinting

An adversary engages in activity to detect the version or type of OS software in a an environment by passively monitoring communication between devices, nodes, or applications. Passive techniques for operating system detection send no actual probes to a target, but monitor network or client-server communication between nodes in order to identify operating systems based on observed behavior as compared to a database of known signatures or values. While passive OS fingerprinting is not usually as reliable as active methods, it is generally better able to evade detection.

CAPEC-317: IP ID Sequencing Probe

This OS fingerprinting probe analyzes the IP 'ID' field sequence number generation algorithm of a remote host. Operating systems generate IP 'ID' numbers differently, allowing an attacker to identify the operating system of the host by examining how is assigns ID numbers when generating response packets. RFC 791 does not specify how ID numbers are chosen or their ranges, so ID sequence generation differs from implementation to implementation. There are two kinds of IP 'ID' sequence number analysis - IP 'ID' Sequencing: analyzing the IP 'ID' sequence generation algorithm for one protocol used by a host and Shared IP 'ID' Sequencing: analyzing the packet ordering via IP 'ID' values spanning multiple protocols, such as between ICMP and TCP.

CAPEC-318: IP 'ID' Echoed Byte-Order Probe

This OS fingerprinting probe tests to determine if the remote host echoes back the IP 'ID' value from the probe packet. An attacker sends a UDP datagram with an arbitrary IP 'ID' value to a closed port on the remote host to observe the manner in which this bit is echoed back in the ICMP error message. The identification field (ID) is typically utilized for reassembling a fragmented packet. Some operating systems or router firmware reverse the bit order of the ID field when echoing the IP Header portion of the original datagram within an ICMP error message.

CAPEC-319: IP (DF) 'Don't Fragment Bit' Echoing Probe

This OS fingerprinting probe tests to determine if the remote host echoes back the IP 'DF' (Don't Fragment) bit in a response packet. An attacker sends a UDP datagram with the DF bit set to a closed port on the remote host to observe whether the 'DF' bit is set in the response packet. Some operating systems will echo the bit in the ICMP error message while others will zero out the bit in the response packet.

CAPEC-320: TCP Timestamp Probe

This OS fingerprinting probe examines the remote server's implementation of TCP timestamps. Not all operating systems implement timestamps within the TCP header, but when timestamps are used then this provides the attacker with a means to guess the operating system of the target. The attacker begins by probing any active TCP service in order to get response which contains a TCP timestamp. Different Operating systems update the timestamp value using different intervals. This type of analysis is most accurate when multiple timestamp responses are received and then analyzed. TCP timestamps can be found in the TCP Options field of the TCP header.

CAPEC-321: TCP Sequence Number Probe

This OS fingerprinting probe tests the target system's assignment of TCP sequence numbers. One common way to test TCP Sequence Number generation is to send a probe packet to an open port on the target and then compare the how the Sequence Number generated by the target relates to the Acknowledgement Number in the probe packet. Different operating systems assign Sequence Numbers differently, so a fingerprint of the operating system can be obtained by categorizing the relationship between the acknowledgement number and sequence number as follows: 1) the Sequence Number generated by the target is Zero, 2) the Sequence Number generated by the target is the same as the acknowledgement number in the probe, 3) the Sequence Number generated by the target is the acknowledgement number plus one, or 4) the Sequence Number is any other non-zero number.

CAPEC-322: TCP (ISN) Greatest Common Divisor Probe

This OS fingerprinting probe sends a number of TCP SYN packets to an open port of a remote machine. The Initial Sequence Number (ISN) in each of the SYN/ACK response packets is analyzed to determine the smallest number that the target host uses when incrementing sequence numbers. This information can be useful for identifying an operating system because particular operating systems and versions increment sequence numbers using different values. The result of the analysis is then compared against a database of OS behaviors to determine the OS type and/or version.

CAPEC-323: TCP (ISN) Counter Rate Probe

This OS detection probe measures the average rate of initial sequence number increments during a period of time. Sequence numbers are incremented using a time-based algorithm and are susceptible to a timing analysis that can determine the number of increments per unit time. The result of this analysis is then compared against a database of operating systems and versions to determine likely operation system matches.

CAPEC-324: TCP (ISN) Sequence Predictability Probe

This type of operating system probe attempts to determine an estimate for how predictable the sequence number generation algorithm is for a remote host. Statistical techniques, such as standard deviation, can be used to determine how predictable the sequence number generation is for a system. This result can then be compared to a database of operating system behaviors to determine a likely match for operating system and version.

CAPEC-325: TCP Congestion Control Flag (ECN) Probe

This OS fingerprinting probe checks to see if the remote host supports explicit congestion notification (ECN) messaging. ECN messaging was designed to allow routers to notify a remote host when signal congestion problems are occurring. Explicit Congestion Notification messaging is defined by RFC 3168. Different operating systems and versions may or may not implement ECN notifications, or may respond uniquely to particular ECN flag types.

CAPEC-326: TCP Initial Window Size Probe

This OS fingerprinting probe checks the initial TCP Window size. TCP stacks limit the range of sequence numbers allowable within a session to maintain the "connected" state within TCP protocol logic. The initial window size specifies a range of acceptable sequence numbers that will qualify as a response to an ACK packet within a session. Various operating systems use different Initial window sizes. The initial window size can be sampled by establishing an ordinary TCP connection.

CAPEC-327: TCP Options Probe

This OS fingerprinting probe analyzes the type and order of any TCP header options present within a response segment. Most operating systems use unique ordering and different option sets when options are present. RFC 793 does not specify a required order when options are present, so different implementations use unique ways of ordering or structuring TCP options. TCP options can be generated by ordinary TCP traffic.

CAPEC-328: TCP 'RST' Flag Checksum Probe

This OS fingerprinting probe performs a checksum on any ASCII data contained within the data portion or a RST packet. Some operating systems will report a human-readable text message in the payload of a 'RST' (reset) packet when specific types of connection errors occur. RFC 1122 allows text payloads within reset packets but not all operating systems or routers implement this functionality.

CAPEC-329: ICMP Error Message Quoting Probe

An adversary uses a technique to generate an ICMP Error message (Port Unreachable, Destination Unreachable, Redirect, Source Quench, Time Exceeded, Parameter Problem) from a target and then analyze the amount of data returned or "Quoted" from the originating request that generated the ICMP error message.

CAPEC-330: ICMP Error Message Echoing Integrity Probe

An adversary uses a technique to generate an ICMP Error message (Port Unreachable, Destination Unreachable, Redirect, Source Quench, Time Exceeded, Parameter Problem) from a target and then analyze the integrity of data returned or "Quoted" from the originating request that generated the error message.

CAPEC-472: Browser Fingerprinting

An attacker carefully crafts small snippets of Java Script to efficiently detect the type of browser the potential victim is using. Many web-based attacks need prior knowledge of the web browser including the version of browser to ensure successful exploitation of a vulnerability. Having this knowledge allows an attacker to target the victim with attacks that specifically exploit known or zero day weaknesses in the type and version of the browser used by the victim. Automating this process via Java Script as a part of the same delivery system used to exploit the browser is considered more efficient as the attacker can supply a browser fingerprinting method and integrate it with exploit code, all contained in Java Script and in response to the same web page request by the browser.

CAPEC-497: File Discovery

An adversary engages in probing and exploration activities to determine if common key files exists. Such files often contain configuration and security parameters of the targeted application, system or network. Using this knowledge may often pave the way for more damaging attacks.

CAPEC-508: Shoulder Surfing

In a shoulder surfing attack, an adversary observes an unaware individual's keystrokes, screen content, or conversations with the goal of obtaining sensitive information. One motive for this attack is to obtain sensitive information about the target for financial, personal, political, or other gains. From an insider threat perspective, an additional motive could be to obtain system/application credentials or cryptographic keys. Shoulder surfing attacks are accomplished by observing the content "over the victim's shoulder", as implied by the name of this attack.

CAPEC-573: Process Footprinting

An adversary exploits functionality meant to identify information about the currently running processes on the target system to an authorized user. By knowing what processes are running on the target system, the adversary can learn about the target environment as a means towards further malicious behavior.

CAPEC-574: Services Footprinting

An adversary exploits functionality meant to identify information about the services on the target system to an authorized user. By knowing what services are registered on the target system, the adversary can learn about the target environment as a means towards further malicious behavior. Depending on the operating system, commands that can obtain services information include "sc" and "tasklist/svc" using Tasklist, and "net start" using Net.

CAPEC-575: Account Footprinting

An adversary exploits functionality meant to identify information about the domain accounts and their permissions on the target system to an authorized user. By knowing what accounts are registered on the target system, the adversary can inform further and more targeted malicious behavior. Example Windows commands which can acquire this information are: "net user" and "dsquery".

CAPEC-576: Group Permission Footprinting

An adversary exploits functionality meant to identify information about user groups and their permissions on the target system to an authorized user. By knowing what users/permissions are registered on the target system, the adversary can inform further and more targeted malicious behavior. An example Windows command which can list local groups is "net localgroup".

CAPEC-577: Owner Footprinting

An adversary exploits functionality meant to identify information about the primary users on the target system to an authorized user. They may do this, for example, by reviewing logins or file modification times. By knowing what owners use the target system, the adversary can inform further and more targeted malicious behavior. An example Windows command that may accomplish this is "dir /A ntuser.dat". Which will display the last modified time of a user's ntuser.dat file when run within the root folder of a user. This time is synonymous with the last time that user was logged in.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-60: Reusing Session IDs (aka Session Replay)

This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.

CAPEC-616: Establish Rogue Location

An adversary provides a malicious version of a resource at a location that is similar to the expected location of a legitimate resource. After establishing the rogue location, the adversary waits for a victim to visit the location and access the malicious resource.

CAPEC-643: Identify Shared Files/Directories on System

An adversary discovers connections between systems by exploiting the target system's standard practice of revealing them in searchable, common areas. Through the identification of shared folders/drives between systems, the adversary may further their goals of locating and collecting sensitive information/files, or map potential routes for lateral movement within the network.

CAPEC-646: Peripheral Footprinting

Adversaries may attempt to obtain information about attached peripheral devices and components connected to a computer system. Examples may include discovering the presence of iOS devices by searching for backups, analyzing the Windows registry to determine what USB devices have been connected, or infecting a victim system with malware to report when a USB device has been connected. This may allow the adversary to gain additional insight about the system or network environment, which may be useful in constructing further attacks.

CAPEC-651: Eavesdropping

An adversary intercepts a form of communication (e.g. text, audio, video) by way of software (e.g., microphone and audio recording application), hardware (e.g., recording equipment), or physical means (e.g., physical proximity). The goal of eavesdropping is typically to gain unauthorized access to sensitive information about the target for financial, personal, political, or other gains. Eavesdropping is different from a sniffing attack as it does not take place on a network-based communication channel (e.g., IP traffic). Instead, it entails listening in on the raw audio source of a conversation between two or more parties.

CAPEC-79: Using Slashes in Alternate Encoding

This attack targets the encoding of the Slash characters. An adversary would try to exploit common filtering problems related to the use of the slashes characters to gain access to resources on the target host. Directory-driven systems, such as file systems and databases, typically use the slash character to indicate traversal between directories or other container components. For murky historical reasons, PCs (and, as a result, Microsoft OSs) choose to use a backslash, whereas the UNIX world typically makes use of the forward slash. The schizophrenic result is that many MS-based systems are required to understand both forms of the slash. This gives the adversary many opportunities to discover and abuse a number of common filtering problems. The goal of this pattern is to discover server software that only applies filters to one version, but not the other.