Authenticated attackers can exploit the security flaw to trigger a use-after-free and potentially execute arbitrary code.
The post Critical Vulnerability Puts 60,000 Redis Servers at Risk of Exploitation appeared first on SecurityWeek.
Wiz has teamed up with Microsoft, Google and AWS and is inviting cloud security researchers to its Zeroday.Cloud competition.
The post $4.5 Million Offered in New Cloud Hacking Competition appeared first on SecurityWeek.
Intel and AMD say the research is not in scope of their threat model because the attack requires physical access to a device.
The post Battering RAM Attack Breaks Intel and AMD Security Tech With $50 Device appeared first on SecurityWeek.
New framework from the Cloud Security Alliance helps SaaS customers navigate the shared responsibility model with confidence.
The post CSA Unveils SaaS Security Controls Framework to Ease Complexity appeared first on SecurityWeek.
The strength of responsible disclosure is that it can solve problems before they are actioned. The weakness is that it potentially generates a false sense of security in the vendor.
The post All Microsoft Entra Tenants Were Exposed to Silent Compromise via Invisible Actor Tokens: Researcher appeared first on SecurityWeek.
L1TF Reloaded is a vulnerability combining the old L1TF and half-Spectre hardware flaws to bypass deployed software mitigations.
The post Researchers Earn $150,000 for L1TF Exploit Leaking Data From Public Cloud appeared first on SecurityWeek.
Exploiting incomplete speculative execution attack mitigations extended to the branch predictor state, VMScape leaks arbitrary memory.
The post VMScape: Academics Break Cloud Isolation With New Spectre Attack appeared first on SecurityWeek.
Using a seven-year-old vulnerability, researchers said they were able to realistically leak private data from public clouds, suggesting that a “lack of concern” about such supposedly impractical attacks is misguided, according to a presentation delivered Monday.
The anonymous researchers presented their findings at a hacker conference, WHY2025, in the Netherlands, and they leaned on the kind of “transient execution” vulnerabilities that attracted attention in 2018 with high-profile Intel chip flaw revelations, one of which was known as Spectre.
“Given that today’s clouds have large fleets of older CPUs that lack comprehensive, in-silicon fixes to a variety of transient execution vulnerabilities, the question arises whether sufficient software-based defenses have been deployed to stop realistic attacks — especially those using older, supposedly mitigated vulnerabilities,” they wrote. The answer to that question is “no,” they concluded. “We show that the practice of mitigating vulnerabilities in isolation, without removing the root cause, leaves systems vulnerable.”
The findings demonstrate that “more than a theoretical possibility, this is a real-world threat in popular clouds,” they explained, unlike the Spectre vulnerability that hasn’t had much real-world applicability.
“For regular users, these CPU vulnerabilities are likely not that much of a threat,” the researchers said. “However, that is not the case for public cloud providers. Their business model is to provide remote code execution as a service [emphasis theirs], and to rent out shared hardware resources as efficiently as possible.”
The researchers said they worked within dedicated host systems of Google Cloud and Amazon Web Services to avoid any actual harm. AWS was able to restrict leakage to non-sensitive host data. Google paid a more than $150,000 bounty, the highest its cloud vulnerability reward program has ever doled out.
Both companies have patched the exploit and plan future security steps.
“Our conclusion is not that AWS’s and Google’s security was lacking, but that they are actively stimulating security improvements,” the researchers said.
The researchers dubbed the attack “L1TF Reloaded,” after another 2018 Intel chip data-stealing vulnerability.
In a blog post, Amazon — which noted that it sponsored a portion of the work — said the research was “impressive” but that the L1TF Reloaded vulnerability does not impact the guest data of AWS customers running on the AWS Nitro System or Nitro Hypervisor.
A Google spokesperson pointed to a security bulletin the company issued.
“When this vulnerability was initially discovered, Google immediately implemented mitigations to address the known risks. Since then, we have collaborated with security researchers from academia to assess the current state of CPU security mitigations, and new attack techniques,” the spokesperson said. “We applied new fixes to the affected assets, including Google Cloud, to mitigate the issue.”
While such vulnerabilities have previously caused little concern, the researchers wrote that “we question this lack of concern and show not only that practical attacks on modern clouds are possible, but that they are possible with vulnerabilities we considered mitigated 7 years ago.”
The post Researchers determine old vulnerabilities pose real-world threat to sensitive data in public clouds appeared first on CyberScoop.
Cloud adoption has fundamentally reshaped security operations, bringing flexibility and scalability, but also complexity. In this session from the Take Command 2025 Virtual Cybersecurity Summit, Rapid7’s product leaders discussed how today’s SOC and MDR capabilities must evolve to keep up. Hosted by Ellis Fincham, the panel featured Dan Martin and Tyler Terenzoni, who shared real-world insights on what cloud detection and response truly requires, what CNAPP can and can’t solve, and how to bridge the growing gap between alerts and actionable context.
Traditional SOC tooling often struggles to keep up with cloud-native architectures. Dan Martin opened the discussion by highlighting a key shift:
“Detection doesn’t start at the endpoint anymore. It starts with understanding your architecture.”
The panel emphasized that while cloud offers flexibility and scale, it also introduces operational complexity. From short-lived containers to decentralized ownership, cloud environments require a different approach.
Tyler Terenzoni spoke to the importance of understanding what’s running and who owns it:
“There’s always a disconnect between what engineering thinks is in the environment and what security actually sees.”
He noted that cloud visibility isn’t just about logs, but also understanding user behavior, policy changes, and asset configuration in near real-time. Without this, SOC teams are often reacting to alerts without enough context.
This issue was reflected in the post-event survey, where 35% of respondents listed lack of visibility across the environment as a primary challenge in their threat detection efforts.
The panel clarified that Cloud-Native Application Protection Platforms (CNAPPs) are useful, but not a complete solution. According to Dan Martin:
“CNAPP is great for giving you coverage, but it doesn’t give you the operational context your SOC needs.”
Integrating CNAPP data into SIEM, XDR, and MDR platforms enables richer investigations and tighter correlation across sources.
Rather than focusing on the volume of alerts, the speakers urged security leaders to ask: can we act on this alert quickly and with confidence?
Dan Martin shared:
“It’s not about reducing alerts, it’s about giving your analysts the context to know what matters and what to do about it.”
Tyler Terenzoni added that turning alerts into action requires better integrations and unified telemetry. Without that foundation, even advanced detections can lead to noise and inefficiency.
While the session didn’t center on AI, the panel acknowledged its growing role in detection workflows. Dan Martin noted:
“AI helps with triage and correlation, but your success still depends on how well your tools talk to each other.”
The emphasis was on automation that supports analysts, not replaces them, especially in cloud environments where missteps can be costly.
If your team is looking to strengthen cloud detection, improve response times, or better align MDR with cloud operations, this session offers real-world insights and practical guidance.
On March 24, 2025, Kubernetes disclosed 5 new vulnerabilities affecting the Ingress NGINX Controller for Kubernetes. Successful exploitation could allow attackers access to all secrets stored across all namespaces in the Kubernetes cluster, which could result in cluster takeover.
Of the 5 vulnerabilities disclosed, any one of the injection vulnerabilities (CVE-2025-24514, CVE-2025-1097, CVE-2025-1098) may be chained with CVE-2025-1974 to achieve unauthenticated RCE on the Kubernetes pod that is running a vulnerable Ingress NGINX Controller. Achieving RCE could allow an attacker to take over a Kubernetes cluster. As of March 25, 2025, none of the above CVEs is known to be exploited in the wild.
Ingress is a Kubernetes feature to route HTTP(S) traffic into a Kubernetes cluster. An Ingress Controller is an application responsible for performing the routing. While there are many Ingress Controllers available, the vulnerabilities disclosed on March 24 are specific to the Ingress NGINX Controller, which is an Ingress Controller based upon NGINX.
The original finders of all five vulnerabilities, Wiz, noted that 43% of cloud environments are vulnerable to the issues disclosed, and that they have identified 6,500 clusters with publicly exposed Ingress NGINX Controllers.
As of March 25, 2025 (14:00 pm GMT), there is now one known publicly available RCE exploit for CVE-2025-1974 (here). This exploit is unverified, but based on our understanding of the vulnerability, it appears viable.
All 5 vulnerabilities are reported to affect the following versions of Ingress NGINX Controller:
Notably, the Wiz advisory says that CVE-2025-24514 does not affect version 1.12.0, but the vendor indicates that the issue does affect 1.12.0.
Customers who use the Ingress NGINX Controller for Kubernetes are advised to update to the following versions immediately:
With the latest Kubernetes Cluster Scanner (available as of Wednesday, March 26), InsightCloudSec customers can discover Kubernetes workloads that have this vulnerability in their cluster. The discovery will be shown via the insights pack with a new insight called Publicly exposed vulnerable Ingress NGINX Admission. The insight will also include remediation steps.
InsightVM and Nexpose customers can assess their exposure to CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098, and CVE-2025-1974 on Unix-based systems with authenticated checks available in the March 26 content release.
Login