#kubernetes

Threat actors tied to North Korea have been observed targeting the Web3 and blockchain sectors as part of twin campaigns tracked as GhostCall and GhostHire. According to Kaspersky, the campaigns are part of a broader operation called SnatchCrypto that has been underway since at least 2017. The activity is attributed to a Lazarus Group sub-cluster called BlueNoroff, which is also known as APT38,

### Impact **Note: The exploitation of this issue requires that the malicious user have access to Rancher’s audit log storage.** A vulnerability has been identified in Rancher Manager, where sensitive information, including secret data, cluster import URLs, and registration tokens, is exposed to any entity with access to Rancher audit logs. This happens in two different ways: 1. Secret Annotation Leakage: When creating Kubernetes Secrets using the `stringData` field, the cleartext value is embedded in the `kubectl.kubernetes.io/last-applied-configuration` annotation. This annotation is included in Rancher audit logs within both the request and response bodies, exposing secret material that should be redacted. 2. Cluster Registration Token Leakage: During the import or creation of downstream clusters (Custom, Imported, or Harvester), Rancher audit logs record full cluster registration manifests and tokens, including: a. Non-expiring import URLs such as `/v3/import/<token>_c-m-xxxx.yam...

### Impact This is an authentication bypass vulnerability in the Karmada Dashboard API. The backend API endpoints (e.g., /api/v1/secret, /api/v1/service) did not enforce authentication, allowing unauthenticated users to access sensitive cluster information such as Secrets and Services directly. Although the web UI required a valid JWT for access, the API itself remained exposed to direct requests without any authentication checks. Any user or entity with network access to the Karmada Dashboard service could exploit this vulnerability to retrieve sensitive data. ### Patches The issue has been fixed in Karmada Dashboard v0.2.0. This release enforces authentication for all API endpoints. Users are strongly advised to upgrade to version v0.2.0 or later as soon as possible. ### Workarounds If upgrading is not immediately feasible, users can mitigate the risk by: - Restricting network access to the Karmada Dashboard service using Kubernetes Network Policies, firewall rules, or ingress con...

### Impact NeuVector used a hard-coded cryptographic key embedded in the source code. At compilation time, the key value was replaced with the secret key value and used to encrypt sensitive configurations when NeuVector stores the data. In the patched version, NeuVector leverages the Kubernetes secret `neuvector-store-secret` in `neuvector` namespace to dynamically generate cryptographically secure random keys. This approach removes the reliance on static key values and ensures that encryption keys are managed securely within Kubernetes. During rolling upgrade or restoring from persistent storage, the NeuVector controller checks each encrypted configured field. If a sensitive field in the configuration is found to be encrypted by the default encryption key, it’s decrypted with the default encryption key and then re-encrypted with the new dynamic encryption key. If the NeuVector controller does not have the correct RBAC for accessing the new secret, it writes this error log : `Requ...

An investigation into the compromise of an Amazon Web Services (AWS)-hosted infrastructure has led to the discovery of a new GNU/Linux rootkit dubbed LinkPro, according to findings from Synacktiv. "This backdoor features functionalities relying on the installation of two eBPF [extended Berkeley Packet Filter] modules, on the one hand to conceal itself, and on the other hand to be remotely

U.S. cybersecurity company F5 on Wednesday disclosed that unidentified threat actors broke into its systems and stole files containing some of BIG-IP's source code and information related to undisclosed vulnerabilities in the product. It attributed the activity to a "highly sophisticated nation-state threat actor," adding the adversary maintained long-term, persistent access to its network. The

Menlo Park, USA, 10th October 2025, CyberNewsWire

Tel Aviv, Israel, 8th October 2025, CyberNewsWire

### Summary A race condition in the repository credentials handler can cause the Argo CD server to panic and crash when concurrent operations are performed on the same repository URL. ### Details The vulnerability is located in numerous repository related handlers in the `util/db/repository_secrets.go` file. For example, in the `secretToRepoCred` function. The issue manifests as a concurrent map access panic: ``` concurrent map read and map write ... goroutine 1104 [running]: github.com/argoproj/argo-cd/v2/util/db.(*secretsRepositoryBackend).secretToRepoCred(0xc000e50ea8?, 0xc000c65540) /go/src/github.com/argoproj/argo-cd/util/db/repository_secrets.go:404 +0x31e ``` The race condition occurs due to: 1. Concurrent repository credential operations (create/update/delete) accessing the same map 2. Kubernetes informer re-syncs happening simultaneously 3. Background watchers updating the same secret data 4. No mutex protection for map access A valid API token with `repositories`...

## Overview Omni and each Talos machine establish a peer-to-peer (P2P) SideroLink connection using WireGuard to mutually authenticate and authorize access. In this setup, Omni assigns a random IPv6 address to each Talos machine from a `/64` network block. Omni itself uses the fixed `::1` address within that same block. From Omni's perspective, this is a WireGuard interface with multiple peers, where each peer corresponds to a Talos machine. The WireGuard interface on Omni is configured to ensure that the **source IP address** of an incoming packet matches the IPv6 address assigned to the Talos peer. However, it **performs no validation on the packet's destination address**. The Talos end of the SideroLink connection cannot be considered a trusted environment. Workloads running on Kubernetes, especially those configured with host networking, could gain direct access to this link. Therefore, a malicious workload could theoretically send arbitrary packets over the SideroLink interface...