github.com/Azure/azure-sdk-for-go/sdk/azidentity is a module that provides Microsoft Entra ID (formerly Azure Active Directory) token authentication support across the Azure SDK. It includes a set of TokenCredential implementations, which can be used with Azure SDK clients supporting token authentication.
-
Affected versions of this package are vulnerable to Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') in the authentication process. An attacker can elevate privileges by exploiting race conditions during the token validation steps. This is only exploitable if the application is configured to use multiple threads or processes for handling authentication requests.
Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to inefficient backtracking in the regular expressions used in URL forms.
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:
-
An attacker who successfully exploited the vulnerability could elevate privileges and read any file on the file system with SYSTEM access permissions;
-
-
An attacker who successfully exploits this vulnerability can only obtain read access to the system files by exploiting this vulnerability. The attacker cannot perform write or delete operations on the files;
-
-
The vulnerability exists in the following credential types: DefaultAzureCredential and ManagedIdentityCredential;
-
-
The vulnerability exists in the following credential types:
-
+
CCC
+
CC+C
+
C+CC
+
C+C+C.
-
ManagedIdentityApplication (.NET)
-
ManagedIdentityApplication (Java)
-
ManagedIdentityApplication (Node.js)
+
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 github.com/Azure/azure-sdk-for-go/sdk/azidentity to version 1.6.0 or higher.
Note:Versions mentioned in the description apply only to the upstream curl package and not the curl package as distributed by Ubuntu.
+ See How to fix? for Ubuntu:24.04 relevant fixed versions and status.
+
When curl is asked to use HSTS, the expiry time for a subdomain might
+ overwrite a parent domain's cache entry, making it end sooner or later than
+ otherwise intended.
+
This affects curl using applications that enable HSTS and use URLs with the
+ insecure HTTP:// scheme and perform transfers with hosts like
+ x.example.com as well as example.com where the first host is a subdomain
+ of the second host.
+
(The HSTS cache either needs to have been populated manually or there needs to
+ have been previous HTTPS accesses done as the cache needs to have entries for
+ the domains involved to trigger this problem.)
+
When x.example.com responds with Strict-Transport-Security: headers, this
+ bug can make the subdomain's expiry timeout bleed over and get set for the
+ parent domain example.com in curl's HSTS cache.
+
The result of a triggered bug is that HTTP accesses to example.com get
+ converted to HTTPS for a different period of time than what was asked for by
+ the origin server. If example.com for example stops supporting HTTPS at its
+ expiry time, curl might then fail to access http://example.com until the
+ (wrongly set) timeout expires. This bug can also expire the parent's entry
+ earlier, thus making curl inadvertently switch back to insecure HTTP earlier
+ than otherwise intended.
Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to inefficient backtracking in the regular expressions used in URL forms.
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:
+
+
CCC
+
CC+C
+
C+CC
+
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.
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
Upgrade github.com/golang-jwt/jwt/v4 to version 4.5.1 or higher.
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
A fix was pushed into the master branch but not yet published.
Affected versions of this package are vulnerable to Path Traversal due to a lack of path normalization, when using URL paths in L7 traffic intentions. An attacker could bypass HTTP request path-based access rules, using URL-encoded paths and/or multiple slashes.
+
Remediation
+
Upgrade github.com/hashicorp/consul/api to version 1.20.1 or higher.
Affected versions of this package are vulnerable to Access Control Bypass due to a lack of header normalization while using Headers in L7 traffic intentions. By exploiting this, an attacker could bypass HTTP header based access rules.
+
Remediation
+
Upgrade github.com/hashicorp/consul/api to version 1.20.1 or higher.
Scanned the following path:
diff --git a/docs/snyk/v2.10.18/quay.io_argoproj_argocd_v2.10.18.html b/docs/snyk/v2.10.18/quay.io_argoproj_argocd_v2.10.18.html
index be5563568dc76..e839cadc32ca2 100644
--- a/docs/snyk/v2.10.18/quay.io_argoproj_argocd_v2.10.18.html
+++ b/docs/snyk/v2.10.18/quay.io_argoproj_argocd_v2.10.18.html
@@ -7,7 +7,7 @@
Snyk test report
-
+
@@ -456,7 +456,7 @@
Snyk test report
-
October 27th 2024, 12:29:29 am (UTC+00:00)
+
November 10th 2024, 12:29:10 am (UTC+00:00)
Scanned the following paths:
@@ -470,8 +470,8 @@
Snyk test report
-
30known vulnerabilities
-
176 vulnerable dependency paths
+
33known vulnerabilities
+
179 vulnerable dependency paths
2278dependencies
@@ -2920,7 +2920,7 @@
Detailed paths
NVD Description
Note:Versions mentioned in the description apply only to the upstream ncurses package and not the ncurses package as distributed by Ubuntu.See How to fix? for Ubuntu:22.04 relevant fixed versions and status.
-
ncurses 6.4-20230610 has a NULL pointer dereference in tgetstr in tinfo/lib_termcap.c.
+
ncurses 6.4-20230610 has a NULL pointer dereference in tgetstr in tinfo/lib_termcap.c. NOTE: Multiple third parties have disputed this indicating upstream does not regard it as a security issue.
Remediation
There is no fixed version for Ubuntu:22.04ncurses.
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
Upgrade github.com/golang-jwt/jwt/v4 to version 4.5.1 or higher.
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
A fix was pushed into the master branch but not yet published.
Note:Versions mentioned in the description apply only to the upstream curl package and not the curl package as distributed by Ubuntu.
+ See How to fix? for Ubuntu:22.04 relevant fixed versions and status.
+
When curl is asked to use HSTS, the expiry time for a subdomain might
+ overwrite a parent domain's cache entry, making it end sooner or later than
+ otherwise intended.
+
This affects curl using applications that enable HSTS and use URLs with the
+ insecure HTTP:// scheme and perform transfers with hosts like
+ x.example.com as well as example.com where the first host is a subdomain
+ of the second host.
+
(The HSTS cache either needs to have been populated manually or there needs to
+ have been previous HTTPS accesses done as the cache needs to have entries for
+ the domains involved to trigger this problem.)
+
When x.example.com responds with Strict-Transport-Security: headers, this
+ bug can make the subdomain's expiry timeout bleed over and get set for the
+ parent domain example.com in curl's HSTS cache.
+
The result of a triggered bug is that HTTP accesses to example.com get
+ converted to HTTPS for a different period of time than what was asked for by
+ the origin server. If example.com for example stops supporting HTTPS at its
+ expiry time, curl might then fail to access http://example.com until the
+ (wrongly set) timeout expires. This bug can also expire the parent's entry
+ earlier, thus making curl inadvertently switch back to insecure HTTP earlier
+ than otherwise intended.
Scanned the following paths:
diff --git a/docs/snyk/v2.12.6/argocd-iac-install.html b/docs/snyk/v2.11.12/argocd-iac-install.html
similarity index 98%
rename from docs/snyk/v2.12.6/argocd-iac-install.html
rename to docs/snyk/v2.11.12/argocd-iac-install.html
index eb957b23a1020..e318052d5f6fe 100644
--- a/docs/snyk/v2.12.6/argocd-iac-install.html
+++ b/docs/snyk/v2.11.12/argocd-iac-install.html
@@ -456,7 +456,7 @@
Snyk test report
-
October 27th 2024, 12:26:17 am (UTC+00:00)
+
November 10th 2024, 12:28:15 am (UTC+00:00)
Scanned the following path:
@@ -507,7 +507,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 21107
+ Line number: 21069
@@ -553,7 +553,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 20788
+ Line number: 20754
@@ -599,7 +599,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 20875
+ Line number: 20839
@@ -645,7 +645,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 20903
+ Line number: 20867
@@ -691,7 +691,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 20933
+ Line number: 20897
@@ -737,7 +737,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 20951
+ Line number: 20915
@@ -783,7 +783,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 20969
+ Line number: 20933
@@ -829,7 +829,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 20991
+ Line number: 20955
@@ -881,7 +881,7 @@
Container could be running with outdated image
- Line number: 22039
+ Line number: 22001
@@ -933,7 +933,7 @@
Container could be running with outdated image
- Line number: 22338
+ Line number: 22288
@@ -991,7 +991,7 @@
Container has no CPU limit
- Line number: 21600
+ Line number: 21562
@@ -1049,7 +1049,7 @@
Container has no CPU limit
- Line number: 21851
+ Line number: 21813
@@ -1107,7 +1107,7 @@
Container has no CPU limit
- Line number: 21817
+ Line number: 21779
@@ -1165,7 +1165,7 @@
Container has no CPU limit
- Line number: 21911
+ Line number: 21873
@@ -1223,7 +1223,7 @@
Container has no CPU limit
- Line number: 22010
+ Line number: 21972
@@ -1281,7 +1281,7 @@
Container has no CPU limit
- Line number: 22034
+ Line number: 21996
@@ -1339,7 +1339,7 @@
Container has no CPU limit
- Line number: 22338
+ Line number: 22288
@@ -1397,7 +1397,7 @@
Container has no CPU limit
- Line number: 22091
+ Line number: 22053
@@ -1455,7 +1455,7 @@
Container has no CPU limit
- Line number: 22423
+ Line number: 22373
@@ -1513,7 +1513,7 @@
Container has no CPU limit
- Line number: 22774
+ Line number: 22724
@@ -1565,7 +1565,7 @@
Container is running with multiple open ports
- Line number: 21831
+ Line number: 21793
@@ -1617,7 +1617,7 @@
Container is running without liveness probe
- Line number: 21600
+ Line number: 21562
@@ -1669,7 +1669,7 @@
Container is running without liveness probe
- Line number: 21817
+ Line number: 21779
@@ -1721,7 +1721,7 @@
Container is running without liveness probe
- Line number: 22010
+ Line number: 21972
@@ -1779,7 +1779,7 @@
Container is running without memory limit
- Line number: 21600
+ Line number: 21562
@@ -1837,7 +1837,7 @@
Container is running without memory limit
- Line number: 21817
+ Line number: 21779
@@ -1895,7 +1895,7 @@
Container is running without memory limit
- Line number: 21851
+ Line number: 21813
@@ -1953,7 +1953,7 @@
Container is running without memory limit
- Line number: 21911
+ Line number: 21873
@@ -2011,7 +2011,7 @@
Container is running without memory limit
- Line number: 22010
+ Line number: 21972
@@ -2069,7 +2069,7 @@
Container is running without memory limit
- Line number: 22034
+ Line number: 21996
@@ -2127,7 +2127,7 @@
Container is running without memory limit
- Line number: 22338
+ Line number: 22288
@@ -2185,7 +2185,7 @@
Container is running without memory limit
- Line number: 22091
+ Line number: 22053
@@ -2243,7 +2243,7 @@
Container is running without memory limit
- Line number: 22423
+ Line number: 22373
@@ -2301,7 +2301,7 @@
Container is running without memory limit
- Line number: 22774
+ Line number: 22724
@@ -2357,7 +2357,7 @@
Container's or Pod's UID could clash with hos
- Line number: 21741
+ Line number: 21703
@@ -2413,7 +2413,7 @@
Container's or Pod's UID could clash with hos
- Line number: 21859
+ Line number: 21821
@@ -2469,7 +2469,7 @@
Container's or Pod's UID could clash with hos
- Line number: 21834
+ Line number: 21796
@@ -2525,7 +2525,7 @@
Container's or Pod's UID could clash with hos
- Line number: 21944
+ Line number: 21906
@@ -2581,7 +2581,7 @@
Container's or Pod's UID could clash with hos
- Line number: 22027
+ Line number: 21989
@@ -2637,7 +2637,7 @@
Container's or Pod's UID could clash with hos
- Line number: 22041
+ Line number: 22003
@@ -2693,7 +2693,7 @@
Container's or Pod's UID could clash with hos
- Line number: 22345
+ Line number: 22295
@@ -2749,7 +2749,7 @@
Container's or Pod's UID could clash with hos
- Line number: 22311
+ Line number: 22261
@@ -2805,7 +2805,7 @@
Container's or Pod's UID could clash with hos
- Line number: 22684
+ Line number: 22634
@@ -2861,7 +2861,7 @@
Container's or Pod's UID could clash with hos
- Line number: 22975
+ Line number: 22943
diff --git a/docs/snyk/v2.11.11/argocd-iac-namespace-install.html b/docs/snyk/v2.11.12/argocd-iac-namespace-install.html
similarity index 99%
rename from docs/snyk/v2.11.11/argocd-iac-namespace-install.html
rename to docs/snyk/v2.11.12/argocd-iac-namespace-install.html
index 5c2d4683d3f45..3516aaed20090 100644
--- a/docs/snyk/v2.11.11/argocd-iac-namespace-install.html
+++ b/docs/snyk/v2.11.12/argocd-iac-namespace-install.html
@@ -456,7 +456,7 @@
Snyk test report
-
October 27th 2024, 12:28:45 am (UTC+00:00)
+
November 10th 2024, 12:28:25 am (UTC+00:00)
Scanned the following path:
@@ -2815,7 +2815,7 @@
Container's or Pod's UID could clash with hos
- Line number: 2036
+ Line number: 2054
diff --git a/docs/snyk/v2.11.11/argocd-test.html b/docs/snyk/v2.11.12/argocd-test.html
similarity index 91%
rename from docs/snyk/v2.11.11/argocd-test.html
rename to docs/snyk/v2.11.12/argocd-test.html
index 7956765bd03e6..945ecf06e400d 100644
--- a/docs/snyk/v2.11.11/argocd-test.html
+++ b/docs/snyk/v2.11.12/argocd-test.html
@@ -7,7 +7,7 @@
Snyk test report
-
+
@@ -456,7 +456,7 @@
Snyk test report
-
October 27th 2024, 12:26:42 am (UTC+00:00)
+
November 10th 2024, 12:26:12 am (UTC+00:00)
Scanned the following paths:
@@ -467,8 +467,8 @@
Snyk test report
-
10known vulnerabilities
-
177 vulnerable dependency paths
+
13known vulnerabilities
+
188 vulnerable dependency paths
2041dependencies
@@ -4198,6 +4198,400 @@
References
+
+
Regular Expression Denial of Service (ReDoS)
+
+
+
+ medium severity
+
+
+
+
+
+
+ Manifest file: /argo-cd › ui/yarn.lock
+
+
+ Package Manager: npm
+
+
+ Vulnerable module:
+
+ foundation-sites
+
+
+
Introduced through:
+
+ argo-cd-ui@1.0.0 and foundation-sites@6.7.5
+
+
Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to inefficient backtracking in the regular expressions used in URL forms.
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:
+
+
CCC
+
CC+C
+
C+CC
+
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.
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
Upgrade github.com/golang-jwt/jwt/v4 to version 4.5.1 or higher.
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
A fix was pushed into the master branch but not yet published.
Affected versions of this package are vulnerable to Path Traversal due to a lack of path normalization, when using URL paths in L7 traffic intentions. An attacker could bypass HTTP request path-based access rules, using URL-encoded paths and/or multiple slashes.
+
Remediation
+
Upgrade github.com/hashicorp/consul/api to version 1.20.1 or higher.
Affected versions of this package are vulnerable to Access Control Bypass due to a lack of header normalization while using Headers in L7 traffic intentions. By exploiting this, an attacker could bypass HTTP header based access rules.
+
Remediation
+
Upgrade github.com/hashicorp/consul/api to version 1.20.1 or higher.
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and libgcrypt20@1.9.4-3ubuntu3
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and libgcrypt20@1.9.4-3ubuntu3
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and krb5/libk5crypto3@1.19.2-2ubuntu0.4
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and krb5/libk5crypto3@1.19.2-2ubuntu0.4
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and gcc-12/libstdc++6@12.3.0-1ubuntu1~22.04
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and gcc-12/libstdc++6@12.3.0-1ubuntu1~22.04
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and systemd/libsystemd0@249.11-0ubuntu3.12
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and systemd/libsystemd0@249.11-0ubuntu3.12
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and shadow/passwd@1:4.8.1-2ubuntu2.2
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and shadow/passwd@1:4.8.1-2ubuntu2.2
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and pcre3/libpcre3@2:8.39-13ubuntu0.22.04.1
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and pcre3/libpcre3@2:8.39-13ubuntu0.22.04.1
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and pcre2/libpcre2-8-0@10.39-3ubuntu0.1
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and pcre2/libpcre2-8-0@10.39-3ubuntu0.1
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and patch@2.7.6-7build2
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and patch@2.7.6-7build2
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and patch@2.7.6-7build2
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and patch@2.7.6-7build2
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and openssl/libssl3@3.0.2-0ubuntu1.18
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and openssl/libssl3@3.0.2-0ubuntu1.18
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and ncurses/libtinfo6@6.3-2ubuntu0.1
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and ncurses/libtinfo6@6.3-2ubuntu0.1
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and ncurses/libtinfo6@6.3-2ubuntu0.1
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and ncurses/libtinfo6@6.3-2ubuntu0.1
Note:Versions mentioned in the description apply only to the upstream ncurses package and not the ncurses package as distributed by Ubuntu.See How to fix? for Ubuntu:22.04 relevant fixed versions and status.
-
ncurses 6.4-20230610 has a NULL pointer dereference in tgetstr in tinfo/lib_termcap.c.
+
ncurses 6.4-20230610 has a NULL pointer dereference in tgetstr in tinfo/lib_termcap.c. NOTE: Multiple third parties have disputed this indicating upstream does not regard it as a security issue.
Remediation
There is no fixed version for Ubuntu:22.04ncurses.
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and libzstd/libzstd1@1.4.8+dfsg-3build1
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and libzstd/libzstd1@1.4.8+dfsg-3build1
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and krb5/libk5crypto3@1.19.2-2ubuntu0.4
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and krb5/libk5crypto3@1.19.2-2ubuntu0.4
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and krb5/libk5crypto3@1.19.2-2ubuntu0.4
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and krb5/libk5crypto3@1.19.2-2ubuntu0.4
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and krb5/libk5crypto3@1.19.2-2ubuntu0.4
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and krb5/libk5crypto3@1.19.2-2ubuntu0.4
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and gnupg2/gpgv@2.2.27-3ubuntu2.1
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and gnupg2/gpgv@2.2.27-3ubuntu2.1
Allocation of Resources Without Limits or Throttling
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and glibc/libc-bin@2.35-0ubuntu3.8
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and glibc/libc-bin@2.35-0ubuntu3.8
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
Upgrade github.com/golang-jwt/jwt/v4 to version 4.5.1 or higher.
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
A fix was pushed into the master branch but not yet published.
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and gcc-12/libstdc++6@12.3.0-1ubuntu1~22.04
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and gcc-12/libstdc++6@12.3.0-1ubuntu1~22.04
Note:Versions mentioned in the description apply only to the upstream curl package and not the curl package as distributed by Ubuntu.
+ See How to fix? for Ubuntu:22.04 relevant fixed versions and status.
+
When curl is asked to use HSTS, the expiry time for a subdomain might
+ overwrite a parent domain's cache entry, making it end sooner or later than
+ otherwise intended.
+
This affects curl using applications that enable HSTS and use URLs with the
+ insecure HTTP:// scheme and perform transfers with hosts like
+ x.example.com as well as example.com where the first host is a subdomain
+ of the second host.
+
(The HSTS cache either needs to have been populated manually or there needs to
+ have been previous HTTPS accesses done as the cache needs to have entries for
+ the domains involved to trigger this problem.)
+
When x.example.com responds with Strict-Transport-Security: headers, this
+ bug can make the subdomain's expiry timeout bleed over and get set for the
+ parent domain example.com in curl's HSTS cache.
+
The result of a triggered bug is that HTTP accesses to example.com get
+ converted to HTTPS for a different period of time than what was asked for by
+ the origin server. If example.com for example stops supporting HTTPS at its
+ expiry time, curl might then fail to access http://example.com until the
+ (wrongly set) timeout expires. This bug can also expire the parent's entry
+ earlier, thus making curl inadvertently switch back to insecure HTTP earlier
+ than otherwise intended.
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11 and coreutils@8.32-4.1ubuntu1.2
+ docker-image|quay.io/argoproj/argocd@v2.11.12 and coreutils@8.32-4.1ubuntu1.2
@@ -4454,7 +4686,7 @@
Detailed paths
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.11.11
+ docker-image|quay.io/argoproj/argocd@v2.11.12
›
coreutils@8.32-4.1ubuntu1.2
diff --git a/docs/snyk/v2.11.11/redis_7.0.15-alpine.html b/docs/snyk/v2.11.12/redis_7.0.15-alpine.html
similarity index 99%
rename from docs/snyk/v2.11.11/redis_7.0.15-alpine.html
rename to docs/snyk/v2.11.12/redis_7.0.15-alpine.html
index 2fada676f9022..20cb4c1eb9299 100644
--- a/docs/snyk/v2.11.11/redis_7.0.15-alpine.html
+++ b/docs/snyk/v2.11.12/redis_7.0.15-alpine.html
@@ -456,7 +456,7 @@
Snyk test report
-
October 27th 2024, 12:27:16 am (UTC+00:00)
+
November 10th 2024, 12:26:52 am (UTC+00:00)
Scanned the following paths:
diff --git a/docs/snyk/v2.11.11/argocd-iac-install.html b/docs/snyk/v2.12.7/argocd-iac-install.html
similarity index 98%
rename from docs/snyk/v2.11.11/argocd-iac-install.html
rename to docs/snyk/v2.12.7/argocd-iac-install.html
index 761f07388bc9f..b3389f9086828 100644
--- a/docs/snyk/v2.11.11/argocd-iac-install.html
+++ b/docs/snyk/v2.12.7/argocd-iac-install.html
@@ -456,7 +456,7 @@
Snyk test report
-
October 27th 2024, 12:28:36 am (UTC+00:00)
+
November 10th 2024, 12:25:49 am (UTC+00:00)
Scanned the following path:
@@ -507,7 +507,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 21059
+ Line number: 21117
@@ -553,7 +553,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 20744
+ Line number: 20798
@@ -599,7 +599,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 20829
+ Line number: 20885
@@ -645,7 +645,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 20857
+ Line number: 20913
@@ -691,7 +691,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 20887
+ Line number: 20943
@@ -737,7 +737,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 20905
+ Line number: 20961
@@ -783,7 +783,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 20923
+ Line number: 20979
@@ -829,7 +829,7 @@
Role or ClusterRole with dangerous permissions
- Line number: 20945
+ Line number: 21001
@@ -881,7 +881,7 @@
Container could be running with outdated image
- Line number: 21991
+ Line number: 22049
@@ -933,7 +933,7 @@
Container could be running with outdated image
- Line number: 22278
+ Line number: 22348
@@ -991,7 +991,7 @@
Container has no CPU limit
- Line number: 21552
+ Line number: 21610
@@ -1049,7 +1049,7 @@
Container has no CPU limit
- Line number: 21803
+ Line number: 21861
@@ -1107,7 +1107,7 @@
Container has no CPU limit
- Line number: 21769
+ Line number: 21827
@@ -1165,7 +1165,7 @@
Container has no CPU limit
- Line number: 21863
+ Line number: 21921
@@ -1223,7 +1223,7 @@
Container has no CPU limit
- Line number: 21962
+ Line number: 22020
@@ -1281,7 +1281,7 @@
Container has no CPU limit
- Line number: 21986
+ Line number: 22044
@@ -1339,7 +1339,7 @@
Container has no CPU limit
- Line number: 22278
+ Line number: 22348
@@ -1397,7 +1397,7 @@
Container has no CPU limit
- Line number: 22043
+ Line number: 22101
@@ -1455,7 +1455,7 @@
Container has no CPU limit
- Line number: 22363
+ Line number: 22433
@@ -1513,7 +1513,7 @@
Container has no CPU limit
- Line number: 22714
+ Line number: 22784
@@ -1565,7 +1565,7 @@
Container is running with multiple open ports
- Line number: 21783
+ Line number: 21841
@@ -1617,7 +1617,7 @@
Container is running without liveness probe
- Line number: 21552
+ Line number: 21610
@@ -1669,7 +1669,7 @@
Container is running without liveness probe
- Line number: 21769
+ Line number: 21827
@@ -1721,7 +1721,7 @@
Container is running without liveness probe
- Line number: 21962
+ Line number: 22020
@@ -1779,7 +1779,7 @@
Container is running without memory limit
- Line number: 21552
+ Line number: 21610
@@ -1837,7 +1837,7 @@
Container is running without memory limit
- Line number: 21769
+ Line number: 21827
@@ -1895,7 +1895,7 @@
Container is running without memory limit
- Line number: 21803
+ Line number: 21861
@@ -1953,7 +1953,7 @@
Container is running without memory limit
- Line number: 21863
+ Line number: 21921
@@ -2011,7 +2011,7 @@
Container is running without memory limit
- Line number: 21962
+ Line number: 22020
@@ -2069,7 +2069,7 @@
Container is running without memory limit
- Line number: 21986
+ Line number: 22044
@@ -2127,7 +2127,7 @@
Container is running without memory limit
- Line number: 22278
+ Line number: 22348
@@ -2185,7 +2185,7 @@
Container is running without memory limit
- Line number: 22043
+ Line number: 22101
@@ -2243,7 +2243,7 @@
Container is running without memory limit
- Line number: 22363
+ Line number: 22433
@@ -2301,7 +2301,7 @@
Container is running without memory limit
- Line number: 22714
+ Line number: 22784
@@ -2357,7 +2357,7 @@
Container's or Pod's UID could clash with hos
- Line number: 21693
+ Line number: 21751
@@ -2413,7 +2413,7 @@
Container's or Pod's UID could clash with hos
- Line number: 21811
+ Line number: 21869
@@ -2469,7 +2469,7 @@
Container's or Pod's UID could clash with hos
- Line number: 21786
+ Line number: 21844
@@ -2525,7 +2525,7 @@
Container's or Pod's UID could clash with hos
- Line number: 21896
+ Line number: 21954
@@ -2581,7 +2581,7 @@
Container's or Pod's UID could clash with hos
- Line number: 21979
+ Line number: 22037
@@ -2637,7 +2637,7 @@
Container's or Pod's UID could clash with hos
- Line number: 21993
+ Line number: 22051
@@ -2693,7 +2693,7 @@
Container's or Pod's UID could clash with hos
- Line number: 22285
+ Line number: 22355
@@ -2749,7 +2749,7 @@
Container's or Pod's UID could clash with hos
- Line number: 22251
+ Line number: 22321
@@ -2805,7 +2805,7 @@
Container's or Pod's UID could clash with hos
- Line number: 22624
+ Line number: 22694
@@ -2861,7 +2861,7 @@
Container's or Pod's UID could clash with hos
- Line number: 22915
+ Line number: 23003
diff --git a/docs/snyk/v2.12.6/argocd-iac-namespace-install.html b/docs/snyk/v2.12.7/argocd-iac-namespace-install.html
similarity index 99%
rename from docs/snyk/v2.12.6/argocd-iac-namespace-install.html
rename to docs/snyk/v2.12.7/argocd-iac-namespace-install.html
index f15128bb32236..ca9f51bba0de9 100644
--- a/docs/snyk/v2.12.6/argocd-iac-namespace-install.html
+++ b/docs/snyk/v2.12.7/argocd-iac-namespace-install.html
@@ -456,7 +456,7 @@
Snyk test report
-
October 27th 2024, 12:26:26 am (UTC+00:00)
+
November 10th 2024, 12:25:59 am (UTC+00:00)
Scanned the following path:
@@ -2815,7 +2815,7 @@
Container's or Pod's UID could clash with hos
- Line number: 2050
+ Line number: 2068
diff --git a/docs/snyk/v2.12.6/argocd-test.html b/docs/snyk/v2.12.7/argocd-test.html
similarity index 70%
rename from docs/snyk/v2.12.6/argocd-test.html
rename to docs/snyk/v2.12.7/argocd-test.html
index 0ee95d39cd998..9d42ca920526a 100644
--- a/docs/snyk/v2.12.6/argocd-test.html
+++ b/docs/snyk/v2.12.7/argocd-test.html
@@ -7,7 +7,7 @@
Snyk test report
-
+
@@ -456,7 +456,7 @@
Snyk test report
-
October 27th 2024, 12:24:18 am (UTC+00:00)
+
November 10th 2024, 12:23:49 am (UTC+00:00)
Scanned the following paths:
@@ -467,8 +467,8 @@
Snyk test report
-
8known vulnerabilities
-
26 vulnerable dependency paths
+
11known vulnerabilities
+
37 vulnerable dependency paths
2061dependencies
@@ -1312,6 +1312,400 @@
References
+
+
Regular Expression Denial of Service (ReDoS)
+
+
+
+ medium severity
+
+
+
+
+
+
+ Manifest file: /argo-cd › ui/yarn.lock
+
+
+ Package Manager: npm
+
+
+ Vulnerable module:
+
+ foundation-sites
+
+
+
Introduced through:
+
+ argo-cd-ui@1.0.0 and foundation-sites@6.8.1
+
+
Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to inefficient backtracking in the regular expressions used in URL forms.
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:
+
+
CCC
+
CC+C
+
C+CC
+
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.
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
Upgrade github.com/golang-jwt/jwt/v4 to version 4.5.1 or higher.
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
A fix was pushed into the master branch but not yet published.
Affected versions of this package are vulnerable to Path Traversal due to a lack of path normalization, when using URL paths in L7 traffic intentions. An attacker could bypass HTTP request path-based access rules, using URL-encoded paths and/or multiple slashes.
+
Remediation
+
Upgrade github.com/hashicorp/consul/api to version 1.20.1 or higher.
Affected versions of this package are vulnerable to Access Control Bypass due to a lack of header normalization while using Headers in L7 traffic intentions. By exploiting this, an attacker could bypass HTTP header based access rules.
+
Remediation
+
Upgrade github.com/hashicorp/consul/api to version 1.20.1 or higher.
diff --git a/docs/snyk/v2.12.6/public.ecr.aws_docker_library_haproxy_2.6.17-alpine.html b/docs/snyk/v2.12.7/public.ecr.aws_docker_library_haproxy_2.6.17-alpine.html
similarity index 99%
rename from docs/snyk/v2.12.6/public.ecr.aws_docker_library_haproxy_2.6.17-alpine.html
rename to docs/snyk/v2.12.7/public.ecr.aws_docker_library_haproxy_2.6.17-alpine.html
index 366c490dc4ac2..4fb2ae7f6fa77 100644
--- a/docs/snyk/v2.12.6/public.ecr.aws_docker_library_haproxy_2.6.17-alpine.html
+++ b/docs/snyk/v2.12.7/public.ecr.aws_docker_library_haproxy_2.6.17-alpine.html
@@ -456,7 +456,7 @@
Snyk test report
-
October 27th 2024, 12:24:30 am (UTC+00:00)
+
November 10th 2024, 12:24:02 am (UTC+00:00)
Scanned the following path:
diff --git a/docs/snyk/v2.12.6/public.ecr.aws_docker_library_redis_7.0.15-alpine.html b/docs/snyk/v2.12.7/public.ecr.aws_docker_library_redis_7.0.15-alpine.html
similarity index 99%
rename from docs/snyk/v2.12.6/public.ecr.aws_docker_library_redis_7.0.15-alpine.html
rename to docs/snyk/v2.12.7/public.ecr.aws_docker_library_redis_7.0.15-alpine.html
index c64e552eae6d7..60cbd58479369 100644
--- a/docs/snyk/v2.12.6/public.ecr.aws_docker_library_redis_7.0.15-alpine.html
+++ b/docs/snyk/v2.12.7/public.ecr.aws_docker_library_redis_7.0.15-alpine.html
@@ -456,7 +456,7 @@
Snyk test report
-
October 27th 2024, 12:24:35 am (UTC+00:00)
+
November 10th 2024, 12:24:06 am (UTC+00:00)
Scanned the following paths:
diff --git a/docs/snyk/v2.12.6/quay.io_argoproj_argocd_v2.12.6.html b/docs/snyk/v2.12.7/quay.io_argoproj_argocd_v2.12.7.html
similarity index 88%
rename from docs/snyk/v2.12.6/quay.io_argoproj_argocd_v2.12.6.html
rename to docs/snyk/v2.12.7/quay.io_argoproj_argocd_v2.12.7.html
index 4f943f6f1aa00..ecff525d1fe42 100644
--- a/docs/snyk/v2.12.6/quay.io_argoproj_argocd_v2.12.6.html
+++ b/docs/snyk/v2.12.7/quay.io_argoproj_argocd_v2.12.7.html
@@ -7,7 +7,7 @@
Snyk test report
-
+
@@ -456,22 +456,22 @@
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.12.6 and libgcrypt20@1.10.3-2build1
+ docker-image|quay.io/argoproj/argocd@v2.12.7 and libgcrypt20@1.10.3-2build1
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.12.6 and patch@2.7.6-7build3
+ docker-image|quay.io/argoproj/argocd@v2.12.7 and patch@2.7.6-7build3
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.12.6 and patch@2.7.6-7build3
+ docker-image|quay.io/argoproj/argocd@v2.12.7 and patch@2.7.6-7build3
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.12.6 and openssl/libssl3t64@3.0.13-0ubuntu3.4
+ docker-image|quay.io/argoproj/argocd@v2.12.7 and openssl/libssl3t64@3.0.13-0ubuntu3.4
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.12.6 and gnupg2/gpgv@2.4.4-2ubuntu17
+ docker-image|quay.io/argoproj/argocd@v2.12.7 and gnupg2/gpgv@2.4.4-2ubuntu17
Allocation of Resources Without Limits or Throttling
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.12.6 and glibc/libc-bin@2.39-0ubuntu8.3
+ docker-image|quay.io/argoproj/argocd@v2.12.7 and glibc/libc-bin@2.39-0ubuntu8.3
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
Upgrade github.com/golang-jwt/jwt/v4 to version 4.5.1 or higher.
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
A fix was pushed into the master branch but not yet published.
Note:Versions mentioned in the description apply only to the upstream curl package and not the curl package as distributed by Ubuntu.
+ See How to fix? for Ubuntu:24.04 relevant fixed versions and status.
+
When curl is asked to use HSTS, the expiry time for a subdomain might
+ overwrite a parent domain's cache entry, making it end sooner or later than
+ otherwise intended.
+
This affects curl using applications that enable HSTS and use URLs with the
+ insecure HTTP:// scheme and perform transfers with hosts like
+ x.example.com as well as example.com where the first host is a subdomain
+ of the second host.
+
(The HSTS cache either needs to have been populated manually or there needs to
+ have been previous HTTPS accesses done as the cache needs to have entries for
+ the domains involved to trigger this problem.)
+
When x.example.com responds with Strict-Transport-Security: headers, this
+ bug can make the subdomain's expiry timeout bleed over and get set for the
+ parent domain example.com in curl's HSTS cache.
+
The result of a triggered bug is that HTTP accesses to example.com get
+ converted to HTTPS for a different period of time than what was asked for by
+ the origin server. If example.com for example stops supporting HTTPS at its
+ expiry time, curl might then fail to access http://example.com until the
+ (wrongly set) timeout expires. This bug can also expire the parent's entry
+ earlier, thus making curl inadvertently switch back to insecure HTTP earlier
+ than otherwise intended.
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.12.6 and coreutils@9.4-3ubuntu6
+ docker-image|quay.io/argoproj/argocd@v2.12.7 and coreutils@9.4-3ubuntu6
@@ -2498,7 +2729,7 @@
Detailed paths
Introduced through:
- docker-image|quay.io/argoproj/argocd@v2.12.6
+ docker-image|quay.io/argoproj/argocd@v2.12.7
›
coreutils@9.4-3ubuntu6
diff --git a/docs/snyk/v2.12.6/redis_7.0.15-alpine.html b/docs/snyk/v2.12.7/redis_7.0.15-alpine.html
similarity index 99%
rename from docs/snyk/v2.12.6/redis_7.0.15-alpine.html
rename to docs/snyk/v2.12.7/redis_7.0.15-alpine.html
index aad2c7d0a4f20..16349703e7ecc 100644
--- a/docs/snyk/v2.12.6/redis_7.0.15-alpine.html
+++ b/docs/snyk/v2.12.7/redis_7.0.15-alpine.html
@@ -456,7 +456,7 @@
Snyk test report
-
October 27th 2024, 12:24:56 am (UTC+00:00)
+
November 10th 2024, 12:24:27 am (UTC+00:00)
Scanned the following paths:
diff --git a/docs/snyk/v2.13.0-rc5/argocd-iac-install.html b/docs/snyk/v2.13.0-rc5/argocd-iac-install.html
index 36538b9879297..bbaeb7181f9ef 100644
--- a/docs/snyk/v2.13.0-rc5/argocd-iac-install.html
+++ b/docs/snyk/v2.13.0-rc5/argocd-iac-install.html
@@ -456,7 +456,7 @@
Snyk test report
-
October 27th 2024, 12:23:51 am (UTC+00:00)
+
November 10th 2024, 12:23:21 am (UTC+00:00)
Scanned the following path:
diff --git a/docs/snyk/v2.13.0-rc5/argocd-iac-namespace-install.html b/docs/snyk/v2.13.0-rc5/argocd-iac-namespace-install.html
index ea4c42c063507..456e14e052b13 100644
--- a/docs/snyk/v2.13.0-rc5/argocd-iac-namespace-install.html
+++ b/docs/snyk/v2.13.0-rc5/argocd-iac-namespace-install.html
@@ -456,7 +456,7 @@
Snyk test report
-
October 27th 2024, 12:24:01 am (UTC+00:00)
+
November 10th 2024, 12:23:31 am (UTC+00:00)
Scanned the following path:
diff --git a/docs/snyk/v2.13.0-rc5/argocd-test.html b/docs/snyk/v2.13.0-rc5/argocd-test.html
index e51a7755420f0..8c4e7426644e4 100644
--- a/docs/snyk/v2.13.0-rc5/argocd-test.html
+++ b/docs/snyk/v2.13.0-rc5/argocd-test.html
@@ -7,7 +7,7 @@
Snyk test report
-
+
@@ -456,7 +456,7 @@
Snyk test report
-
October 27th 2024, 12:21:47 am (UTC+00:00)
+
November 10th 2024, 12:21:16 am (UTC+00:00)
Scanned the following paths:
@@ -467,8 +467,8 @@
Snyk test report
-
7known vulnerabilities
-
25 vulnerable dependency paths
+
10known vulnerabilities
+
36 vulnerable dependency paths
2132dependencies
@@ -1200,6 +1200,400 @@
References
+
+
Regular Expression Denial of Service (ReDoS)
+
+
+
+ medium severity
+
+
+
+
+
+
+ Manifest file: /argo-cd › ui/yarn.lock
+
+
+ Package Manager: npm
+
+
+ Vulnerable module:
+
+ foundation-sites
+
+
+
Introduced through:
+
+ argo-cd-ui@1.0.0 and foundation-sites@6.8.1
+
+
Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to inefficient backtracking in the regular expressions used in URL forms.
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:
+
+
CCC
+
CC+C
+
C+CC
+
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.
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
Upgrade github.com/golang-jwt/jwt/v4 to version 4.5.1 or higher.
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
A fix was pushed into the master branch but not yet published.
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
Upgrade github.com/golang-jwt/jwt/v4 to version 4.5.1 or higher.
Affected versions of this package are vulnerable to Insufficient Documentation of Error Handling Techniques in the ParseWithClaims function. An attacker can exploit this to accept invalid tokens by only checking for specific errors and ignoring others.
+
Workaround
+
Users who are not able to upgrade to the fixed version should make sure that they are properly checking for all errors, see example_test.go
+
Remediation
+
A fix was pushed into the master branch but not yet published.
Note:Versions mentioned in the description apply only to the upstream curl package and not the curl package as distributed by Ubuntu.
+ See How to fix? for Ubuntu:24.04 relevant fixed versions and status.
+
When curl is asked to use HSTS, the expiry time for a subdomain might
+ overwrite a parent domain's cache entry, making it end sooner or later than
+ otherwise intended.
+
This affects curl using applications that enable HSTS and use URLs with the
+ insecure HTTP:// scheme and perform transfers with hosts like
+ x.example.com as well as example.com where the first host is a subdomain
+ of the second host.
+
(The HSTS cache either needs to have been populated manually or there needs to
+ have been previous HTTPS accesses done as the cache needs to have entries for
+ the domains involved to trigger this problem.)
+
When x.example.com responds with Strict-Transport-Security: headers, this
+ bug can make the subdomain's expiry timeout bleed over and get set for the
+ parent domain example.com in curl's HSTS cache.
+
The result of a triggered bug is that HTTP accesses to example.com get
+ converted to HTTPS for a different period of time than what was asked for by
+ the origin server. If example.com for example stops supporting HTTPS at its
+ expiry time, curl might then fail to access http://example.com until the
+ (wrongly set) timeout expires. This bug can also expire the parent's entry
+ earlier, thus making curl inadvertently switch back to insecure HTTP earlier
+ than otherwise intended.