You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A critical authentication bypass vulnerability exists in Ollama platform's API endpoints in versions prior to and including v0.12.3. The platform exposes multiple API endpoints without requiring authentication, enabling remote attackers to perform unauthorized model management operations.
Affected range
>=0
Fixed version
Not Fixed
EPSS Score
0.444%
EPSS Percentile
63rd percentile
Description
Ollama Divide By Zero vulnerability in github.com/ollama/ollama
Affected range
>=0
Fixed version
Not Fixed
EPSS Score
0.252%
EPSS Percentile
49th percentile
Description
Ollama Allocation of Resources Without Limits or Throttling vulnerability in github.com/ollama/ollama
Affected range
>=0
Fixed version
Not Fixed
EPSS Score
0.233%
EPSS Percentile
46th percentile
Description
Ollama Denial of Service (DoS) via Null Pointer Dereference in github.com/ollama/ollama
Affected range
>=0
Fixed version
Not Fixed
EPSS Score
0.262%
EPSS Percentile
50th percentile
Description
Ollama Divide by Zero Vulnerability in github.com/ollama/ollama
Affected range
>=0
Fixed version
Not Fixed
EPSS Score
0.187%
EPSS Percentile
40th percentile
Description
Ollama Vulnerable to Denial of Service (DoS) via Crafted GZIP in github.com/ollama/ollama
Affected range
>=0
Fixed version
Not Fixed
EPSS Score
0.232%
EPSS Percentile
46th percentile
Description
Ollama Allows Out-of-Bounds Read in github.com/ollama/ollama
Affected range
>=0
Fixed version
Not Fixed
EPSS Score
0.025%
EPSS Percentile
7th percentile
Description
Ollama vulnerable to Cross-Domain Token Exposure in github.com/ollama/ollama
stdlib1.24.13 (golang)
pkg:golang/stdlib@1.24.13
Affected range
<1.25.9
Fixed version
1.25.9
EPSS Score
0.017%
EPSS Percentile
4th percentile
Description
If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled consumption of resources. This can lead to a denial of service.
This only affects TLS 1.3.
Affected range
<1.25.9
Fixed version
1.25.9
EPSS Score
0.018%
EPSS Percentile
5th percentile
Description
Validating certificate chains which use policies is unexpectedly inefficient when certificates in the chain contain a very large number of policy mappings, possibly causing denial of service.
This only affects validation of otherwise trusted certificate chains, issued by a root CA in the VerifyOptions.Roots CertPool, or in the system certificate pool.
Affected range
<1.25.9
Fixed version
1.25.9
EPSS Score
0.017%
EPSS Percentile
4th percentile
Description
During chain building, the amount of work that is done is not correctly limited when a large number of intermediate certificates are passed in VerifyOptions.Intermediates, which can lead to a denial of service. This affects both direct users of crypto/x509 and users of crypto/tls.
Affected range
<1.25.8
Fixed version
1.25.8
EPSS Score
0.051%
EPSS Percentile
16th percentile
Description
url.Parse insufficiently validated the host/authority component and accepted some invalid URLs.
Affected range
<1.25.9
Fixed version
1.25.9
EPSS Score
0.008%
EPSS Percentile
1st percentile
Description
On Linux, if the target of Root.Chmod is replaced with a symlink while the chmod operation is in progress, Chmod can operate on the target of the symlink, even when the target lies outside the root.
The Linux fchmodat syscall silently ignores the AT_SYMLINK_NOFOLLOW flag, which Root.Chmod uses to avoid symlink traversal. Root.Chmod checks its target before acting and returns an error if the target is a symlink lying outside the root, so the impact is limited to cases where the target is replaced with a symlink between the check and operation.
Affected range
<1.25.9
Fixed version
1.25.9
EPSS Score
0.010%
EPSS Percentile
1st percentile
Description
Context was not properly tracked across template branches for JS template literals, leading to possibly incorrect escaping of content when branches were used. Additionally template actions within JS template literals did not properly track the brace depth, leading to incorrect escaping being applied.
These issues could cause actions within JS template literals to be incorrectly or improperly escaped, leading to XSS vulnerabilities.
Affected range
<1.25.8
Fixed version
1.25.8
EPSS Score
0.015%
EPSS Percentile
3rd percentile
Description
Actions which insert URLs into the content attribute of HTML meta tags are not escaped. This can allow XSS if the meta tag also has an http-equiv attribute with the value "refresh".
A new GODEBUG setting has been added, htmlmetacontenturlescape, which can be used to disable escaping URLs in actions in the meta content attribute which follow "url=" by setting htmlmetacontenturlescape=0.
Affected range
<1.25.9
Fixed version
1.25.9
EPSS Score
0.004%
EPSS Percentile
0th percentile
Description
tar.Reader can allocate an unbounded amount of memory when reading a maliciously-crafted archive containing a large number of sparse regions encoded in the "old GNU sparse map" format.
Affected range
<1.25.8
Fixed version
1.25.8
EPSS Score
0.008%
EPSS Percentile
1st percentile
Description
On Unix platforms, when listing the contents of a directory using File.ReadDir or File.Readdir the returned FileInfo could reference a file outside of the Root in which the File was opened.
The impact of this escape is limited to reading metadata provided by lstat from arbitrary locations on the filesystem without permitting reading or writing files outside the root.
The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin ioreg command to use an absolute path but left the BSD kenv command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.
The execCommand helper at sdk/resource/host_id_exec.go uses exec.Command(name, arg...) which searches $PATH when the command name contains no path separator.
Affected platforms (per build tag in host_id_bsd.go:4): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris.
The kenv path is reached when /etc/hostid does not exist (line 38-40), which is common on FreeBSD systems.
Attack
Attacker has local access to a system running a Go application that imports go.opentelemetry.io/otel/sdk
Attacker places a malicious kenv binary earlier in $PATH
Application initializes OpenTelemetry resource detection at startup
hostIDReaderBSD.read() calls exec.Command("kenv", ...) which resolves to the malicious binary
Arbitrary code executes in the context of the application
The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application.
Patches
This has been patched in d45961b, which was released with v1.40.0.
Helm vulnerable to Code Injection through malicious chart.yaml content in helm.sh/helm
Allocation of Resources Without Limits or Throttling
Affected range
<3.18.5
Fixed version
3.18.5
CVSS Score
6.5
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score
0.014%
EPSS Percentile
3rd percentile
Description
A Helm contributor discovered that it was possible to craft a JSON Schema file in a manner which could cause Helm to use all available memory and have an out of memory (OOM) termination.
Impact
A malicious chart can point $ref in values.schema.json to a device (e.g. /dev/*) or other problem file which could cause Helm to use all available memory and have an out of memory (OOM) termination.
Patches
This issue has been resolved in Helm v3.18.5.
Workarounds
Make sure that all Helm charts that are being loaded into Helm doesn't have any reference of $ref pointing to /dev/zero.
References
Helm's security policy is spelled out in detail in our SECURITY document.
Credits
Disclosed by Jakub Ciolek at AlphaSense.
Use of Uninitialized Resource
Affected range
<3.18.5
Fixed version
3.18.5
CVSS Score
6.5
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score
0.017%
EPSS Percentile
4th percentile
Description
A Helm contributor discovered an improper validation of type error when parsing Chart.yaml and index.yaml files that can lead to a panic.
Impact
There are two areas of YAML validation that were impacted. First, when a Chart.yaml file had a null maintainer or the child or parent of a dependencies import-values could be parsed as something other than a string, helm lint would panic. Second, when an index.yaml had an empty entry in the list of chart versions Helm would panic on interactions with that repository.
Patches
This issue has been resolved in Helm v3.18.5.
Workarounds
Ensure YAML files are formatted as Helm expects prior to processing them with Helm.
References
Helm's security policy is spelled out in detail in our SECURITY document.
Credits
Disclosed by Jakub Ciolek at AlphaSense.
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Helm is a package manager for Charts for Kubernetes. In Helm versions <=3.20.1 and <=4.1.3, a specially crafted Chart will cause helm pull --untar [chart URL | repo/chartname] to write the Chart's contents to the immediate output directory (as defaulted to the current working directory; or as given by the --destination and --untardir flags), rather than the expected output directory suffixed by the chart's name.
Impact
The bug enables writing the Chart's contents (unpackaged/untar'ed) to the output directory <output dir>/, instead of the expected <output dir>/<chart name>/, potentially overwriting the contents of the targeted directory.
Note: a chart name containing POSIX dot-dot, or dot-dot and slashes (as if to refer to parent directories) do not resolve beyond the output directory as designed.
Patches
This issue has been resolved in Helm v3.20.2 and v4.1.3
A Chart with an unexpected name (those specified to be "." or ".."), or a Chart name which results in a non-unique directory will be rejected.
Workarounds
Ensure the the name of the Chart does not comprise/contain POSIX pathname special directory references ie. dot-dot ("..") or dot ("."). In addition, ensuring that the pull --untar flag (or equivalent SDK option) refers to a unique/empty output directory prevents chart extraction from inadvertently overwriting existing files within the specified directory.
Authentication Bypass Using an Alternate Path or Channel
Affected range
<29.3.1
Fixed version
Not Fixed
CVSS Score
8.8
CVSS Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
EPSS Score
0.008%
EPSS Percentile
1st percentile
Description
Summary
A security vulnerability has been detected that allows attackers to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low.
If you don't use AuthZ plugins, you are not affected.
Using a specially-crafted API request, an attacker could make the Docker daemon forward the request to an authorization plugin without the body. The authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.
Anyone who depends on authorization plugins that introspect the request body to make access control decisions is potentially impacted.
Workarounds
If unable to update immediately:
Avoid using AuthZ plugins that rely on request body inspection for security decisions.
Restrict access to the Docker API to trusted parties, following the principle of least privilege.
A security vulnerability has been detected that allows plugins privilege validation to be bypassed during docker plugin install. Due to an error in the daemon's privilege comparison logic, the daemon may incorrectly accept a privilege set that differs from the one approved by the user.
Plugins that request exactly one privilege are also affected, because no comparison is performed at all.
Impact
If plugins are not in use, there is no impact.
When a plugin is installed, the daemon computes the privileges required by the plugin's configuration and compares them with the privileges approved during installation. A malicious plugin can exploit this bug so that the daemon accepts privileges that differ from what was intended to be approved.
Anyone who depends on the plugin installation approval flow as a meaningful security boundary is potentially impacted.
Depending on the privilege set involved, this may include highly sensitive plugin permissions such as broad device access.
For consideration: exploitation still requires a plugin to be installed from a malicious source, and Docker plugins are relatively uncommon. Docker Desktop also does not support plugins.
Workarounds
If unable to update immediately:
Do not install plugins from untrusted sources
Carefully review all privileges requested during docker plugin install
Restrict access to the Docker daemon to trusted parties, following the principle of least privilege
Avoid relying on plugin privilege approval as the only control boundary for sensitive environments
Credits
Reported by Cody (c@wormhole.guru, PGP 0x9FA5B73E)
An Arbitrary File Read vulnerability has been identified in KEDA, potentially affecting any KEDA resource that uses TriggerAuthentication to configure HashiCorp Vault authentication.
The vulnerability stems from an incorrect or insufficient path validation when loading the Service Account Token specified in spec.hashiCorpVault.credential.serviceAccount.
An attacker with permissions to create or modify a TriggerAuthentication resource can exfiltrate the content of any file from the node's filesystem (where the KEDA pod resides) by directing the file's content to a server under their control, as part of the Vault authentication request.
The potential impact includes the exfiltration of sensitive system information, such as secrets, keys, or the content of files like /etc/passwd.
Patches
The problem has been patched in v2.17.3 and 2.18.3 as well as in main branch.
Workarounds
The only effective workaround is the strict restriction of permissions for creating and modifying TriggerAuthentication resources within the Kubernetes cluster.
Only trusted and authorized users should have create or update permissions on the TriggerAuthentication resource.
This limits an attacker's ability to configure a malicious TriggerAuthentication with an arbitrary path.
Is my project affected?
If it execute s
kubectl get deploy keda-operator -n keda -o jsonpath="{.spec.template.spec.containers[0].image}"
and the version is not 2.17.3, 2.18.3 or >= 2.19.0, that version is affected.
Docker CLI for Windows searches for plugin binaries in C:\ProgramData\Docker\cli-plugins, a directory that does not exist by default. A low-privileged attacker can create this directory and place malicious CLI plugin binaries (docker-compose.exe, docker-buildx.exe, etc.) that are executed when a victim user opens Docker Desktop or invokes Docker CLI plugin features, and allow privilege-escalation if the docker CLI is executed as a privileged user.
This issue affects Docker CLI through v29.1.5 (fixed in v29.2.0). It impacts Windows binaries acting as a CLI plugin manager via the [github.com/docker/cli/cli-plugins/manager](https://pkg.go.dev/github.com/docker/cli@v29.1.5+incompatible/cli-plugins/manager) package, which is consumed by downstream projects such as Docker Compose.
Docker Compose became affected starting in v2.31.0, when it incorporated the relevant CLI plugin manager code (see docker/compose#12300), and is fixed in v5.1.0.
This issue does not impact non-Windows binaries or projects that do not use the plugin manager code.
Patches
Fixed version starts with 29.2.0
This issue was fixed in docker/cli@1375933 (docker/cli#6713), which removed %PROGRAMDATA%\Docker\cli-plugins from the list of paths used for plugin-discovery on Windows.
The Delete function fails to properly validate offsets when processing malformed JSON input. This can lead to a negative slice index and a runtime panic, allowing a denial of service attack.
The SPDY/3 frame parser in spdystream does not validate
attacker-controlled counts and lengths before allocating memory. A
remote peer that can send SPDY frames to a service using spdystream can
cause the process to allocate gigabytes of memory with a small number of
malformed control frames, leading to an out-of-memory crash.
Three allocation paths in the receive side are affected:
SETTINGS entry count -- The SETTINGS frame reader reads a 32-bit numSettings from the payload and allocates a slice of that size
without checking it against the declared frame length. An attacker
can set numSettings to a value far exceeding the actual payload,
triggering a large allocation before any setting data is read.
Header count -- parseHeaderValueBlock reads a 32-bit numHeaders from the decompressed header block and allocates an http.Header map of that size with no upper bound.
Header field size -- Individual header name and value lengths are
read as 32-bit integers and used directly as allocation sizes with
no validation.
Because SPDY header blocks are zlib-compressed, a small on-the-wire
payload can decompress into attacker-controlled bytes that the parser
interprets as 32-bit counts and lengths. A single crafted frame is
enough to exhaust process memory.
Impact
Any program that accepts SPDY connections using spdystream -- directly
or through a dependent library -- is affected. A remote peer that can
send SPDY frames to the service can crash the process with a single
crafted SPDY control frame, causing denial of service.
v0.5.1 addresses the receive-side allocation bugs and adds related
hardening:
Core fixes:
SETTINGS entry-count validation -- The SETTINGS frame reader now
checks that numSettings is consistent with the declared frame
length (numSettings <= (length-4)/8) before allocating.
Header count limit -- parseHeaderValueBlock enforces a maximum
number of headers per frame (default: 1000).
Header field size limit -- Individual header name and value
lengths are checked against a per-field size limit (default: 1 MiB)
before allocation.
Connection closure on protocol error -- The connection read loop
now closes the underlying net.Conn when it encounters an InvalidControlFrame error, preventing further exploitation on the
same connection.
Additional hardening:
Write-side bounds checks -- All frame write methods now verify
that payloads fit within the 24-bit length field, preventing the
library from producing invalid frames.
Configurable limits:
Callers can adjust the defaults using NewConnectionWithOptions or
the lower-level spdy.NewFramerWithOptions with functional options: WithMaxControlFramePayloadSize, WithMaxHeaderFieldSize, and WithMaxHeaderCount.
Decrypting a JSON Web Encryption (JWE) object will panic if the alg field indicates a key wrapping algorithm (one ending in KW, with the exception of A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty. The panic happens when cipher.KeyUnwrap() in key_wrap.go attempts to allocate a slice with a zero or negative length based on the length of the encrypted_key.
This code path is reachable from ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() followed by Decrypt() on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected.
This panic is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter less than 16 bytes long, but calling this function directly is less common.
Panics can lead to denial of service.
Fixed In
4.1.4 and v3.0.5
Workarounds
If the list of keyAlgorithms passed to ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() does not include key wrapping algorithms (those ending in KW), your application is unaffected.
If your application uses key wrapping, you can prevalidate to the JWE objects to ensure the encrypted_key field is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second .).
Thanks
Thanks to Datadog's Security team for finding this issue.
A padding oracle vulnerability exists in the AWS S3 Crypto SDK for GoLang versions prior to V2. The SDK allows users to encrypt files with AES-CBC without computing a Message Authentication Code (MAC), which then allows an attacker who has write access to the target's S3 bucket and can observe whether or not an endpoint with access to the key can decrypt a file, they can reconstruct the plaintext with (on average) 128*length (plaintext) queries to the endpoint, by exploiting CBC's ability to manipulate the bytes of the next block and PKCS5 padding errors. It is recommended to update your SDK to V2 or later, and re-encrypt your files.
Affected range
>=0
Fixed version
Not Fixed
EPSS Score
0.145%
EPSS Percentile
35th percentile
Description
A vulnerability in the in-band key negotiation exists in the AWS S3 Crypto SDK for GoLang versions prior to V2. An attacker with write access to the targeted bucket can change the encryption algorithm of an object in the bucket, which can then allow them to change AES-GCM to AES-CTR. Using this in combination with a decryption oracle can reveal the authentication key used by AES-GCM as decrypting the GMAC tag leaves the authentication key recoverable as an algebraic equation. It is recommended to update your SDK to V2 or later, and re-encrypt your files.
Stored cross-site scripting (XSS) via crafted metric names in the Prometheus web UI:
Old React UI + New Mantine UI: When a user hovers over a chart tooltip on the Graph page, metric names containing HTML/JavaScript are injected into innerHTML without escaping, causing arbitrary script execution in the user's browser.
Old React UI only: When a user opens the Metric Explorer (globe icon next to the PromQL expression input field), and a metric name containing HTML/JavaScript is rendered in the fuzzy search results, it is injected into innerHTML without escaping, causing arbitrary script execution in the user's browser.
Old React UI only: When a user views a heatmap chart and hovers over a cell, the le label values of the underlying histogram buckets are interpolated into innerHTML without escaping. While le is conventionally a numeric bucket boundary, Prometheus does not enforce this — arbitrary UTF-8 strings are accepted as label values, allowing script injection via a crafted scrape target or remote write.
With Prometheus v3.x defaulting to UTF-8 metric and label name validation, characters like <, >, and " are now valid in metric names and labels, making this exploitable.
An attacker who can inject metrics (via a compromised scrape target, remote write, or OTLP receiver endpoint) can execute JavaScript in the browser of any Prometheus user who views the metric in the Graph UI. From the XSS context, an attacker could for example:
Read /api/v1/status/config to extract sensitive configuration (although credentials / secrets are redacted by the server)
Call /-/quit to shut down Prometheus (only if --web.enable-lifecycle is set)
Call /api/v1/admin/tsdb/delete_series to delete data (only if --web.enable-admin-api is set)
Exfiltrate metric data to an external server
Both the new Mantine UI and the old React UI are affected. The vulnerable code paths are:
web/ui/mantine-ui/src/pages/query/uPlotChartHelpers.ts — tooltip innerHTML with unescaped labels.__name__
web/ui/react-app/src/pages/graph/GraphHelpers.ts — tooltip content with unescaped labels.__name__
web/ui/react-app/src/pages/graph/MetricsExplorer.tsx — fuzzy search results rendered via dangerouslySetInnerHTML without sanitization
web/ui/react-app/src/vendor/flot/jquery.flot.heatmap.js — heatmap tooltip with unescaped label values
Patches
A patch has been published in Prometheus 3.5.2 LTS and Prometheus 3.11.2. The fix applies escapeHTML() to all user-controlled values (metric names and label values) before inserting them into innerHTML. This advisory will be updated with the patched version once released.
Workarounds
If using the remote write receiver (--web.enable-remote-write-receiver), ensure it is not exposed to untrusted sources.
If using the OTLP receiver (--web.enable-otlp-receiver), ensure it is not exposed to untrusted sources.
Ensure scrape targets are trusted and not under attacker control.
Do not enable admin / mutating API endpoints (e.g. --web.enable-admin-api or web.enable-lifecycle) in cases where you cannot prevent untrusted data from being ingested.
Users should avoid clicking untrusted links, especially those containing functions such as label_replace, as they may generate poisoned label names and values.
Acknowledgements
Thanks to @gladiator9797 (Duc Anh Nguyen from TinyxLab) for reporting this.
An issue exists in the the EventStream header decoder in AWS SDK for Go v2 in versions predating 2026-03-23. An actor can send a malformed EventStream response frame containing a crafted header value type byte outside the valid range, which can cause the host process to terminate.
This issue has been addressed in versions 2026-03-23 and above. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.
Workarounds
Not Applicable
References
If you have any questions or comments about this advisory, we ask that you contact [AWS/Amazon] Security via our vulnerability reporting page or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.
An issue exists in the the EventStream header decoder in AWS SDK for Go v2 in versions predating 2026-03-23. An actor can send a malformed EventStream response frame containing a crafted header value type byte outside the valid range, which can cause the host process to terminate.
This issue has been addressed in versions 2026-03-23 and above. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.
Workarounds
Not Applicable
References
If you have any questions or comments about this advisory, we ask that you contact [AWS/Amazon] Security via our vulnerability reporting page or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.
An issue exists in the the EventStream header decoder in AWS SDK for Go v2 in versions predating 2026-03-23. An actor can send a malformed EventStream response frame containing a crafted header value type byte outside the valid range, which can cause the host process to terminate.
This issue has been addressed in versions 2026-03-23 and above. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.
Workarounds
Not Applicable
References
If you have any questions or comments about this advisory, we ask that you contact [AWS/Amazon] Security via our vulnerability reporting page or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.
An issue exists in the the EventStream header decoder in AWS SDK for Go v2 in versions predating 2026-03-23. An actor can send a malformed EventStream response frame containing a crafted header value type byte outside the valid range, which can cause the host process to terminate.
This issue has been addressed in versions 2026-03-23 and above. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.
Workarounds
Not Applicable
References
If you have any questions or comments about this advisory, we ask that you contact [AWS/Amazon] Security via our vulnerability reporting page or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
nicholasdille-bot
left a comment
This PR contains the following updates:
0.4.31→0.4.32Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Release Notes
k8sgpt-ai/k8sgpt (k8sgpt)
v0.4.32Compare Source
Features
Bug Fixes
Configuration
📅 Schedule: (in timezone Europe/Berlin)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Renovate Bot.