IBM Fusion 2.2.0 through 2.10.1, IBM Fusion HCI 2.2.0 through 2.10.0, and IBM Fusion HCI for watsonx 2.8.2 through 2.10.0 uses insecure default configurations that could expose AMQStreams without client authentication that could allow an attacker to perform unauthorized actions.
A Helm contributor discovered that a specially crafted chart archive file can cause Helm to use all available memory and have an out of memory (OOM) termination.
Impact A chart archive file can be crafted in a manner where it expands to be significantly larger uncompressed than compressed (e.g., >800x difference). When Helm loads this specially crafted chart, memory can be exhausted causing the application to terminate.
Patches This issue has been resolved in Helm v3.17.3.
Workarounds Ensure that any chart archive files being loaded by Helm do not contain files that are large enough to cause the Helm Client or SDK to use up available memory leading to a termination.
For more information Helm's security policy is spelled out in detail in our SECURITY document.
Credits Disclosed by Jakub Ciolek at AlphaSense.
A Helm contributor discovered that a specially crafted JSON Schema within a chart can lead to a stack overflow.
Impact A JSON Schema file within a chart can be crafted with a deeply nested chain of references, leading to parser recursion that can exceed the stack size limit and trigger a stack overflow.
Patches This issue has been resolved in Helm v3.17.3.
Workarounds Ensure that the JSON Schema within any charts loaded by Helm does not have a large number of nested references. These JSON Schema files are larger than 10 MiB.
For more information Helm's security policy is spelled out in detail in our SECURITY document.
Credits Disclosed by Jakub Ciolek at AlphaSense.
IBM Fusion and IBM Fusion HCI 2.3.0 through 2.8.2 is vulnerable to insecure network connection by allowing an attacker who gains access to a Fusion container to establish an external network connection.
Files or Directories Accessible to External Parties, Improper Privilege Management vulnerability in Apache Kafka Clients.
Apache Kafka Clients accept configuration data for customizing behavior, and includes ConfigProvider plugins in order to manipulate these configurations. Apache Kafka also provides FileConfigProvider, DirectoryConfigProvider, and EnvVarConfigProvider implementations which include the ability to read from disk or environment variables. In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use these ConfigProviders to read arbitrary contents of the disk and environment variables.
In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment access, which may be undesirable in certain environments, including SaaS products. This issue affects Apache Kafka Clients: from 2.3.0 through 3.5.2, 3.6.2, 3.7.0.
Users with affected applications are recommended to upgrade kafka-clients to version >=3.8.0, and set the JVM system property "org.apache.kafka.automatic.config.providers=none". Users of Kafka Connect with one of the listed ConfigProvider implementations specified in their worker config are also recommended to add appropriate "allowlist.pattern" and "allowed.paths" to restrict their operation to appropriate bounds.
For users of Kafka Clients or Kafka Connect in environments that trust users with disk and environment variable access, it is not recommended to set the system property. For users of the Kafka Broker, Kafka MirrorMaker 2.0, Kafka Streams, and Kafka command-line tools, it is not recommended to set the system property.
[Improperly verified POST keys]
IBM Storage Fusion HCI 2.1.0 through 2.6.1 contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data. IBM X-Force ID: 275671.
A race condition in go-resty can result in HTTP request body disclosure across requests.
This condition can be triggered by calling sync.Pool.Put with the same bytes.Buffer more than once, when request retries are enabled and a retry occurs. The call to sync.Pool.Get will then return a bytes.Buffer that hasn't had bytes.Buffer.Reset called on it. This dirty buffer will contain the HTTP request body from an unrelated request, and go-resty will append the current HTTP request body to it, sending two bodies in one request.
The sync.Pool in question is defined at package level scope, so a completely unrelated server could receive the request body.