Snyk test report
- quay.io/argoproj/argocd:v3.3.14/argoproj/argocd/Dockerfile (deb)
- quay.io/argoproj/argocd:v3.3.14/argoproj/argo-cd/v3//usr/local/bin/argocd (gomodules)
- quay.io/argoproj/argocd:v3.3.14//usr/local/bin/kustomize (gomodules)
- quay.io/argoproj/argocd:v3.3.14/helm/v3//usr/local/bin/helm (gomodules)
- quay.io/argoproj/argocd:v3.3.14/git-lfs/git-lfs//usr/bin/git-lfs (gomodules)
Improper Authentication
Detailed paths
Overview
Affected versions of this package are vulnerable to Improper Authentication via the ToASCII and ToUnicode functions. An attacker can bypass hostname validation by submitting Punycode-encoded labels that decode to ASCII-only labels, potentially leading to privilege escalation in applications that rely on these functions for security checks.
Note: The fix depends on the Go toolchain in use having Unicode version 16 or later, which is planned for the 1.27 release.
Remediation
Upgrade golang.org/x/net/idna to version 0.54.0 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the HTTP/2 DATA frame receive buffer handling, where each received fragment incurs per-fragment tracking and queue allocation overhead even while staying within the configured flow-control windows. An attacker can drive the process to an OutOfMemory condition or a runtime panic by opening gRPC streams and fragmenting payloads into millions of tiny HTTP/2 DATA frames, such as 1 byte each, across many concurrent multiplexed streams. This requires only the ability to establish gRPC stream connections to the server.
Remediation
Upgrade google.golang.org/grpc/mem to version 1.83.1 or higher.
References
Incorrect Authorization
Detailed paths
Overview
Affected versions of this package are vulnerable to Incorrect Authorization in the processing of xDS RBAC policies and HTTP/2 transport handling. An attacker can gain unauthorized access to protected services or cause denial of service by exploiting improper handling of unsupported fields in policy matchers, bypassing rapid reset mitigations, or triggering server panics through crafted policy updates.
Note: This advisory refers to several vulnerabilities as aggregated by the maintainer. For an exact breakdown and affected code, see the Maintainer's referenced advisory and commit.
Workaround
This vulnerability can be mitigated by ensuring xDS management servers do not push RBAC policies with unsupported fields or NOT rules wrapping unhandled fields, and by configuring upstream reverse proxies or load balancers with strict HTTP/2 max_concurrent_streams limits and active rate limiting on RST_STREAM frequency per connection.
Remediation
Upgrade google.golang.org/grpc/internal/transport to version 1.82.1 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the HTTP/2 DATA frame receive buffer handling, where each received fragment incurs per-fragment tracking and queue allocation overhead even while staying within the configured flow-control windows. An attacker can drive the process to an OutOfMemory condition or a runtime panic by opening gRPC streams and fragmenting payloads into millions of tiny HTTP/2 DATA frames, such as 1 byte each, across many concurrent multiplexed streams. This requires only the ability to establish gRPC stream connections to the server.
Remediation
Upgrade google.golang.org/grpc/internal/transport to version 1.83.1 or higher.
References
Uncaught Exception
Detailed paths
Overview
Affected versions of this package are vulnerable to Uncaught Exception through the HTTP/2 header processing path in internal/transport/http2_server.go and internal/xds/server/routing.go. An attacker can crash the server by sending a gRPC request that omits both the :authority and Host headers. In xds.NewGRPCServer() deployments, that malformed request reaches the xDS routing interceptor, which expects an authority value and then indexes into an empty header slice. The resulting panic terminates the server process, causing a complete outage for clients connected to that gRPC server.
Remediation
Upgrade google.golang.org/grpc/internal/transport to version 1.82.2, 1.83.2 or higher.
References
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Issue
- GitHub PR
- GitHub PR
- GitHub PR
- Maintainer's Advisory
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the HTTP/2 DATA frame receive buffer handling, where each received fragment incurs per-fragment tracking and queue allocation overhead even while staying within the configured flow-control windows. An attacker can drive the process to an OutOfMemory condition or a runtime panic by opening gRPC streams and fragmenting payloads into millions of tiny HTTP/2 DATA frames, such as 1 byte each, across many concurrent multiplexed streams. This requires only the ability to establish gRPC stream connections to the server.
Remediation
Upgrade google.golang.org/grpc/internal/envconfig to version 1.83.1 or higher.
References
Infinite loop
Detailed paths
Overview
golang.org/x/net/http2 is a work-in-progress HTTP/2 implementation for Go.
Affected versions of this package are vulnerable to Infinite loop.
Go Vulnerability Report:
When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0.
Remediation
Upgrade golang.org/x/net/http2 to version 0.53.0 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
golang.org/x/crypto/ssh is a SSH client and server
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in its connection multiplexing, reached through Dial, NewClientConn, NewControlClientConn, and NewServerConn, which buffers unhandled messages that fall outside the RFC 4254 channel and global-request handling instead of treating them as protocol errors. A malicious peer can deadlock the entire SSH connection by sending unexpected messages once a channel has been established. This requires a completed handshake and an open SSH channel with the attacker as the peer.
Remediation
Upgrade golang.org/x/crypto/ssh to version 0.56.0 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
golang.org/x/crypto/ssh is a SSH client and server
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the connection multiplexer's channel handling (the mux chanList), reached through Dial, NewClientConn, NewControlClientConn, and NewServerConn, where a channel that is registered but not yet established has its incomingRequests queue flooded without bound. A malicious peer can deadlock the entire SSH connection by flooding channel request packets for a channel before it becomes established. This requires the attacker to participate in an SSH connection with the victim over the library.
Remediation
Upgrade golang.org/x/crypto/ssh to version 0.56.0 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling due to the lack of validation on attacker-controlled counts and lengths in the SPDY/3 frame parser. An attacker can exhaust process memory and cause an out-of-memory crash by sending a single crafted control frame with compressed header blocks that decompress into large allocation sizes.
Remediation
Upgrade github.com/moby/spdystream/spdy to version 0.5.1 or higher.
References
Integer Overflow
Detailed paths
Overview
Affected versions of this package are vulnerable to Integer Overflow leading to an out-of-bounds write in the s2.NewDict() function in s2/dict.go, which reads a uvarint and converts it to int without checking whether it exceeds MaxInt64. An attacker can crash the process with a segmentation fault by supplying S2 dictionary data whose repeat-index uvarint exceeds MaxInt64, which becomes a negative int that bypasses the index validation and drives out-of-bounds arithmetic through unsafe.Pointer in Dict.Encode(). Exploitation requires the application to build an S2 dictionary from attacker-controlled data with s2.NewDict() and then call Dict.Encode() on input of at least 32 bytes.
Remediation
Upgrade github.com/klauspost/compress/s2 to version 1.18.7 or higher.
References
Directory Traversal
Detailed paths
Overview
Affected versions of this package are vulnerable to Directory Traversal via the processing of reference names in dotgit. An attacker can modify or overwrite files outside the intended reference storage by supplying specially crafted reference names containing path traversal sequences. This is only exploitable if the application uses filesystem-backed storage and interacts with a malicious Git server or processes attacker-controlled reference names.
Workaround
This vulnerability can be mitigated by exclusively using in-memory storage or by validating reference names at the application level before passing them to filesystem-backed storage.
Details
A Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.
Directory Traversal vulnerabilities can be generally divided into two types:
- Information Disclosure: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.
st is a module for serving static files on web pages, and contains a vulnerability of this type. In our example, we will serve files from the public route.
If an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.
curl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa
Note %2e is the URL encoded version of . (dot).
- Writing arbitrary files: Allows the attacker to create or replace existing files. This type of vulnerability is also known as
Zip-Slip.
One way to achieve this is by using a malicious zip archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.
The following is an example of a zip archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in /root/.ssh/ overwriting the authorized_keys file:
2018-04-15 22:04:29 ..... 19 19 good.txt
2018-04-15 22:04:42 ..... 20 20 ../../../../../../root/.ssh/authorized_keys
Remediation
Upgrade github.com/go-git/go-git/v5/storage/filesystem/dotgit to version 5.19.2 or higher.
References
Insufficiently Protected Credentials
Detailed paths
Overview
Affected versions of this package are vulnerable to Insufficiently Protected Credentials in the advertisedReferences() function. The headers - including Authorization headers - from an initial /info/refs request are forwarded to redirect targets. An attacker can obtain authentication credentials by controlling a redirect target, and those credentials may be reused on other endpoints or attempted against other repositories owned by the victim. This is only exploitable if the client interacts with untrusted or misconfigured remote servers, or uses HTTP (not HTTPS) connections.
Remediation
Upgrade github.com/go-git/go-git/v5/plumbing/transport/http to version 5.18.0 or higher.
References
Incorrect Behavior Order: Validate Before Canonicalize
Detailed paths
Overview
Affected versions of this package are vulnerable to Incorrect Behavior Order: Validate Before Canonicalize in the parsing of Git objects with malformed or ambiguous commit or tag objects. An attacker can cause inconsistent interpretation of object metadata or signature validation by introducing specially crafted objects that are parsed differently than by upstream Git, potentially leading to the acceptance of commits with misleading or unintended metadata.
Remediation
Upgrade github.com/go-git/go-git/v5/plumbing/object to version 5.19.0 or higher.
References
Directory Traversal
Detailed paths
Overview
github.com/go-git/go-git/v5/plumbing is a highly extensible git implementation library written in pure Go.
Affected versions of this package are vulnerable to Directory Traversal via the processing of reference names in dotgit. An attacker can modify or overwrite files outside the intended reference storage by supplying specially crafted reference names containing path traversal sequences. This is only exploitable if the application uses filesystem-backed storage and interacts with a malicious Git server or processes attacker-controlled reference names.
Workaround
This vulnerability can be mitigated by exclusively using in-memory storage or by validating reference names at the application level before passing them to filesystem-backed storage.
Details
A Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.
Directory Traversal vulnerabilities can be generally divided into two types:
- Information Disclosure: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.
st is a module for serving static files on web pages, and contains a vulnerability of this type. In our example, we will serve files from the public route.
If an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.
curl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa
Note %2e is the URL encoded version of . (dot).
- Writing arbitrary files: Allows the attacker to create or replace existing files. This type of vulnerability is also known as
Zip-Slip.
One way to achieve this is by using a malicious zip archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.
The following is an example of a zip archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in /root/.ssh/ overwriting the authorized_keys file:
2018-04-15 22:04:29 ..... 19 19 good.txt
2018-04-15 22:04:42 ..... 20 20 ../../../../../../root/.ssh/authorized_keys
Remediation
Upgrade github.com/go-git/go-git/v5/plumbing to version 5.19.2 or higher.
References
Symlink Attack
Detailed paths
Overview
Affected versions of this package are vulnerable to Symlink Attack in worktree_fs.go and worktree.go are vulnerable to symlink traversal in filesystem-backed worktrees. An attacker can modify or overwrite files outside the intended worktree by placing a symlink in the tree and then triggering a worktree operation, such as checkout, create, rename, or remove, against a path that resolves through that link. This can redirect writes into the repository’s .git metadata or another external target, leading to arbitrary file write and corruption of repository state, which can break subsequent Git operations and expose or alter files the application did not intend to touch.
Remediation
Upgrade github.com/go-git/go-git/v5 to version 5.19.2 or higher.
References
CVE-2026-35344
Detailed paths
NVD Description
Note: Versions mentioned in the description apply only to the upstream rust-coreutils package and not the rust-coreutils package as distributed by Ubuntu.
See How to fix? for Ubuntu:25.10 relevant fixed versions and status.
The dd utility in uutils coreutils suppresses errors during file truncation operations by unconditionally calling Result::ok() on truncation attempts. While intended to mimic GNU behavior for special files like /dev/null, the uutils implementation also hides failures on regular files and directories caused by full disks or read-only file systems. This can lead to silent data corruption in backup or migration scripts, as the utility may report a successful operation even when the destination file contains old or garbage data.
Remediation
There is no fixed version for Ubuntu:25.10 rust-coreutils.
References
- http://people.ubuntu.com/~ubuntu-security/cve/CVE-2026-35344
- https://github.com/uutils/coreutils/issues/9745
CVE-2026-35375
Detailed paths
NVD Description
Note: Versions mentioned in the description apply only to the upstream rust-coreutils package and not the rust-coreutils package as distributed by Ubuntu.
See How to fix? for Ubuntu:25.10 relevant fixed versions and status.
A logic error in the split utility of uutils coreutils causes the corruption of output filenames when provided with non-UTF-8 prefix or suffix inputs. The implementation utilizes to_string_lossy() when constructing chunk filenames, which automatically rewrites invalid byte sequences into the UTF-8 replacement character (U+FFFD). This behavior diverges from GNU split, which preserves raw pathname bytes intact. In environments utilizing non-UTF-8 encodings, this vulnerability leads to the creation of files with incorrect names, potentially causing filename collisions, broken automation, or the misdirection of output data.
Remediation
There is no fixed version for Ubuntu:25.10 rust-coreutils.
References
- http://people.ubuntu.com/~ubuntu-security/cve/CVE-2026-35375
- https://github.com/uutils/coreutils/pull/11397
- https://github.com/uutils/coreutils/releases/tag/0.8.0
Cross-site Scripting (XSS)
Detailed paths
Overview
golang.org/x/net/html is a package that implements an HTML5-compliant tokenizer and parser.
Affected versions of this package are vulnerable to Cross-site Scripting (XSS) in the inBodyEndTagOther() function, when rendering sanitized HTML. An attacker can cause the execution of scripts in the context of the affected application by providing malicious HTML input containing unmatched tags.
Details
Cross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.
This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.
Injecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.
Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as < and > can be coded as > in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.
The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.
Types of attacks
There are a few methods by which XSS can be manipulated:
| Type | Origin | Description |
|---|---|---|
| Stored | Server | The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link. |
| Reflected | Server | The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser. |
| DOM-based | Client | The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data. |
| Mutated | The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters. |
Affected environments
The following environments are susceptible to an XSS attack:
- Web servers
- Application servers
- Web application environments
How to prevent
This section describes the top best practices designed to specifically protect your code:
- Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
- Convert special characters such as
?,&,/,<,>and spaces to their respective HTML or URL encoded equivalents. - Give users the option to disable client-side scripts.
- Redirect invalid requests.
- Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
- Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
- Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.
Remediation
Upgrade golang.org/x/net/html to version 0.55.0 or higher.
References
Cross-site Scripting (XSS)
Detailed paths
Overview
golang.org/x/net/html is a package that implements an HTML5-compliant tokenizer and parser.
Affected versions of this package are vulnerable to Cross-site Scripting (XSS) via the readStartTag() function in the Tokenizer. An attacker can cause the execution of scripts in the context of the affected application by supplying malicious HTML with duplicate attributes.
Details
Cross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.
This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.
Injecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.
Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as < and > can be coded as > in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.
The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.
Types of attacks
There are a few methods by which XSS can be manipulated:
| Type | Origin | Description |
|---|---|---|
| Stored | Server | The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link. |
| Reflected | Server | The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser. |
| DOM-based | Client | The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data. |
| Mutated | The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters. |
Affected environments
The following environments are susceptible to an XSS attack:
- Web servers
- Application servers
- Web application environments
How to prevent
This section describes the top best practices designed to specifically protect your code:
- Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
- Convert special characters such as
?,&,/,<,>and spaces to their respective HTML or URL encoded equivalents. - Give users the option to disable client-side scripts.
- Redirect invalid requests.
- Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
- Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
- Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.
Remediation
Upgrade golang.org/x/net/html to version 0.55.0 or higher.
References
Cross-site Scripting (XSS)
Detailed paths
Overview
golang.org/x/net/html is a package that implements an HTML5-compliant tokenizer and parser.
Affected versions of this package are vulnerable to Cross-site Scripting (XSS) via the childTextNodesAreLiteral() function in `render.go. An attacker can cause the execution of scripts in the context of the affected application by providing malicious HTML input containing fostered elements that are outside their parent namespace.
Details
Cross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.
This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.
Injecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.
Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as < and > can be coded as > in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.
The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.
Types of attacks
There are a few methods by which XSS can be manipulated:
| Type | Origin | Description |
|---|---|---|
| Stored | Server | The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link. |
| Reflected | Server | The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser. |
| DOM-based | Client | The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data. |
| Mutated | The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters. |
Affected environments
The following environments are susceptible to an XSS attack:
- Web servers
- Application servers
- Web application environments
How to prevent
This section describes the top best practices designed to specifically protect your code:
- Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
- Convert special characters such as
?,&,/,<,>and spaces to their respective HTML or URL encoded equivalents. - Give users the option to disable client-side scripts.
- Redirect invalid requests.
- Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
- Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
- Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.
Remediation
Upgrade golang.org/x/net/html to version 0.55.0 or higher.
References
Cross-site Scripting (XSS)
Detailed paths
Overview
golang.org/x/net/html is a package that implements an HTML5-compliant tokenizer and parser.
Affected versions of this package are vulnerable to Cross-site Scripting (XSS) via the writeQuoted() function, which does not properly handle > characters in DOCTYPE data. An attacker can cause the execution of scripts in the context of the affected application by providing malicious HTML input that contains unescaped >s.
Details
Cross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.
This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.
Injecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.
Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as < and > can be coded as > in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.
The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.
Types of attacks
There are a few methods by which XSS can be manipulated:
| Type | Origin | Description |
|---|---|---|
| Stored | Server | The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link. |
| Reflected | Server | The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser. |
| DOM-based | Client | The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data. |
| Mutated | The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters. |
Affected environments
The following environments are susceptible to an XSS attack:
- Web servers
- Application servers
- Web application environments
How to prevent
This section describes the top best practices designed to specifically protect your code:
- Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
- Convert special characters such as
?,&,/,<,>and spaces to their respective HTML or URL encoded equivalents. - Give users the option to disable client-side scripts.
- Redirect invalid requests.
- Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
- Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
- Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.
Remediation
Upgrade golang.org/x/net/html to version 0.55.0 or higher.
References
Inefficient Algorithmic Complexity
Detailed paths
Overview
golang.org/x/net/html is a package that implements an HTML5-compliant tokenizer and parser.
Affected versions of this package are vulnerable to Inefficient Algorithmic Complexity in parse.go, when checking attributes iteratively. An attacker can cause excessive CPU consumption by providing malicious HTML input.
Remediation
Upgrade golang.org/x/net/html to version 0.55.0 or higher.
References
Incorrect Authorization
Detailed paths
Overview
golang.org/x/crypto/ssh is a SSH client and server
Affected versions of this package are vulnerable to Incorrect Authorization in NewServerConn, which applied the critical option from the Permissions returned by an authentication callback only on the PublicKeyCallback and VerifiedPublicKeyCallback paths and silently ignored it for PasswordCallback, KeyboardInteractiveCallback, NoClientAuthCallback, and GSSAPIWithMICConfig.AllowLogin. An attacker can connect from an address the restriction was meant to exclude by authenticating through one of those unenforced callback paths. This affects only servers that set a source-address restriction from a password, keyboard-interactive, no-client-auth, or GSSAPI authentication callback and rely on it being enforced.
Note: This is a bypass of the fix for the vulnerability described in CVE-2026-46595.
Remediation
Upgrade golang.org/x/crypto/ssh to version 0.55.0 or higher.
References
Memory Allocation with Excessive Size Value
Detailed paths
Overview
Affected versions of this package are vulnerable to Memory Allocation with Excessive Size Value via the Parse function. An attacker can exhaust CPU resources and generate excessive log output by sending oversized or malformed headers that are processed without length checks.
Remediation
Upgrade go.opentelemetry.io/otel/propagation to version 1.44.0 or higher.
References
Improper Validation of Specified Type of Input
Detailed paths
Overview
Affected versions of this package are vulnerable to Improper Validation of Specified Type of Input in the calls plugin when handling websocket messages containing malformed msgpack frames. An attacker can cause the server to consume excessive memory and crash by sending specially crafted websocket requests.
Remediation
There is no fixed version for github.com/vmihailenco/msgpack/v5.
References
Incorrect Authorization
Detailed paths
Overview
Affected versions of this package are vulnerable to Incorrect Authorization in the ServeHTTP method of ServeMux (runtime/mux.go), which rewrites r.Method from the client-supplied X-HTTP-Method-Override header on form-urlencoded POST requests without restricting the allowed methods. An attacker can reach handlers for restricted verbs such as DELETE, PUT, or PATCH, bypassing method-based access controls enforced at an upstream proxy or WAF, by sending a POST request with Content-Type: application/x-www-form-urlencoded and the override header set to the target method. This requires a deployment where a perimeter proxy or WAF filters on the wire method while trusting the gateway downstream, and a handler must exist for the overridden method.
Note: The WithDisablePathLengthFallback is added in version 2.29.0 but it is disabled by default.
Workaround
This vulnerability can be avoided by stripping the X-HTTP-Method-Override header at the perimeter proxy or WAF, so the enforced wire method is the one the gateway routes on.
Remediation
There is no fixed version for github.com/grpc-ecosystem/grpc-gateway/v2/runtime.
References
Incorrect Authorization
Detailed paths
Overview
Affected versions of this package are vulnerable to Incorrect Authorization in the ServeHTTP method of ServeMux (runtime/mux.go), which rewrites r.Method from the client-supplied X-HTTP-Method-Override header on form-urlencoded POST requests without restricting the allowed methods. An attacker can reach handlers for restricted verbs such as DELETE, PUT, or PATCH, bypassing method-based access controls enforced at an upstream proxy or WAF, by sending a POST request with Content-Type: application/x-www-form-urlencoded and the override header set to the target method. This requires a deployment where a perimeter proxy or WAF filters on the wire method while trusting the gateway downstream, and a handler must exist for the overridden method.
Note: The WithDisablePathLengthFallback is added in version 2.29.0 but it is disabled by default.
Workaround
This vulnerability can be avoided by stripping the X-HTTP-Method-Override header at the perimeter proxy or WAF, so the enforced wire method is the one the gateway routes on.
Remediation
There is no fixed version for github.com/grpc-ecosystem/grpc-gateway/runtime.
References
Directory Traversal
Detailed paths
Overview
Affected versions of this package are vulnerable to Directory Traversal due to improper path validation in the repository checkout process. An attacker can modify files outside the intended target directory, including .git directories, by supplying a maliciously crafted repository payload. This is only exploitable if the repository is cloned or checked out from untrusted sources and the .git directory is stored within the same filesystem as the worktree, particularly when submodules are present.
Details
A Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.
Directory Traversal vulnerabilities can be generally divided into two types:
- Information Disclosure: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.
st is a module for serving static files on web pages, and contains a vulnerability of this type. In our example, we will serve files from the public route.
If an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.
curl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa
Note %2e is the URL encoded version of . (dot).
- Writing arbitrary files: Allows the attacker to create or replace existing files. This type of vulnerability is also known as
Zip-Slip.
One way to achieve this is by using a malicious zip archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.
The following is an example of a zip archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in /root/.ssh/ overwriting the authorized_keys file:
2018-04-15 22:04:29 ..... 19 19 good.txt
2018-04-15 22:04:42 ..... 20 20 ../../../../../../root/.ssh/authorized_keys
Remediation
Upgrade github.com/go-git/go-git/v5/storage/filesystem/dotgit to version 5.19.1, 6.0.0-alpha.4 or higher.
References
Improper Validation of Integrity Check Value
Detailed paths
Overview
Affected versions of this package are vulnerable to Improper Validation of Integrity Check Value for .idx and .pack files. An attacker can cause the application to consume corrupted files, leading to unexpected errors, due to checksums not being checked in the loadIdxFile() function.
Workaround
This vulnerability can be mitigated by running 'git fsck' from the git CLI to check for data corruption on a given repository.
Remediation
Upgrade github.com/go-git/go-git/v5/storage/filesystem to version 5.16.5 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling through the parsing of maliciously crafted Git repository data, such as .pack, .idx, or loose objects. An attacker can cause the application to panic by providing a payload that exceeds the declared size of a slice for isCopyFromDelta(), or consume excessive resources by sending an unlimited stream of calls to isCopyFromDelta() or a stream of calls with excessively large targetSz values (i.e. amplification).
Note: This is only exploitable if the attacker can alter read-only files in the local repository's .git/objects/pack/ directory or if the user interacts with a malicious remote server.
Remediation
Upgrade github.com/go-git/go-git/v5/plumbing/format/packfile to version 5.19.1 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling through the handling of .idx files. An attacker with write access to the local repository's .git directory can exhaust system memory by introducing a maliciously crafted .idx file into the .git directory.
Remediation
Upgrade github.com/go-git/go-git/v5/plumbing/format/index to version 5.17.1 or higher.
References
Improper Validation of Array Index
Detailed paths
Overview
Affected versions of this package are vulnerable to Improper Validation of Array Index through improper validation in the index decoding for version 4 files. An attacker with write access to the .git directory to modify or inject the index file can cause a panic and terminate the process by supplying a maliciously crafted .git/index file that triggers an out-of-bounds slice operation during index parsing.
Remediation
Upgrade github.com/go-git/go-git/v5/plumbing/format/index to version 5.17.1 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling through the parsing of maliciously crafted Git repository data, such as .pack, .idx, or loose objects. An attacker can cause the application to panic by providing a payload that exceeds the declared size of a slice for isCopyFromDelta(), or consume excessive resources by sending an unlimited stream of calls to isCopyFromDelta() or a stream of calls with excessively large targetSz values (i.e. amplification).
Note: This is only exploitable if the attacker can alter read-only files in the local repository's .git/objects/pack/ directory or if the user interacts with a malicious remote server.
Remediation
Upgrade github.com/go-git/go-git/v5/plumbing/format/idxfile to version 5.19.1 or higher.
References
Improper Encoding or Escaping of Output
Detailed paths
Overview
Affected versions of this package are vulnerable to Improper Encoding or Escaping of Output due to improper escaping of single quotes in the SSH transport command construction process. An attacker can inject arbitrary shell tokens by including single quotes in the repository path, potentially leading to unintended command execution on SSH servers that evaluate the exec command through a shell.
Remediation
Upgrade github.com/go-git/go-git/v5/plumbing/transport/ssh to version 5.19.1, 6.0.0-alpha.4 or higher.
References
Improper Input Validation
Detailed paths
NVD Description
Note: Versions mentioned in the description apply only to the upstream coreutils package and not the coreutils package as distributed by Ubuntu.
See How to fix? for Ubuntu:25.10 relevant fixed versions and status.
chroot in GNU coreutils, when used with --userspec, allows local users to escape to the parent session via a crafted TIOCSTI ioctl call, which pushes characters to the terminal's input buffer.
Remediation
There is no fixed version for Ubuntu:25.10 coreutils.
References
- http://people.ubuntu.com/~ubuntu-security/cve/CVE-2016-2781
- https://security-tracker.debian.org/tracker/CVE-2016-2781
- https://lists.apache.org/thread.html/rf9fa47ab66495c78bb4120b0754dd9531ca2ff0430f6685ac9b07772@%3Cdev.mina.apache.org%3E
- http://www.openwall.com/lists/oss-security/2016/02/28/2
- http://www.openwall.com/lists/oss-security/2016/02/28/3
- https://lists.apache.org/thread.html/rf9fa47ab66495c78bb4120b0754dd9531ca2ff0430f6685ac9b07772%40%3Cdev.mina.apache.org%3E