China has more than 5,000 cybersecurity companies and all the top 20 firms are working with the government.
The post Cybersecurity Firms React to China’s Reported Software Ban appeared first on SecurityWeek.
The life of a modern head of information security (also known as CISO – Chief Information Security Officer) is not just about fighting hackers. It’s also an endless quest that goes by the name of “compliance”. Regulators keep tightening the screws, standards pop up like mushrooms, and headaches only get worse; but wait… – there’s more: CISOs are responsible not only for their own perimeter, but what goes on outside it too: for their entire supply chain, all their contractors, and the whole hodge-podge of software their business processes run on. Though the logic here is solid, it’s also unfortunately ruthless: if a hole is found at your supplier, but the problems hit you, in the end it’s you who’s held accountable. This logic applies to security software too.
Back in the day, companies rarely thought about what was actually inside the security solutions and products they used. Now, however, businesses – especially large ones – want to know everything: what’s really inside the box? Who wrote the code? Is it going to break some critical function or could it even bring everything down? (We’ve seen such precedents; example: the Crowdstrike 2024 update incident.) Where and how is data processed? And these are the right questions to ask.
The problem lies in the fact that almost all customers trust their vendors to answer accurately when asked such questions – very often because they have no other choice. A more mature approach in today’s cyber-reality is to verify.
In corporate-speak this is called supply-chain trust, and trying to solve this puzzle on your own is a serious headache. You need help from vendors. A responsible vendor is ready to show what’s under the hood of its solutions, to open up the source code to partners and customers for review, and, in general, to earn trust not with nice slides but with solid, practical steps.
So who’s already doing this, and who’s still stuck in the past? A fresh, in-depth study from our colleagues in Europe has the answer. It was conducted by the respected testing lab AV-Comparatives, the Tyrol Chamber of Commerce (WKO), the MCI Entrepreneurial School, and the law firm Studio Legale Tremolada.
The main conclusion of the study is that the era of “black boxes” in cybersecurity is over. RIP. Amen. The future belongs to those who don’t hide their source code and vulnerability reports, and who give customers maximum choice when configuring their products. And the report clearly states who doesn’t just promise but actually delivers. Guess who!…
What a great guess! Yes – it’s us!
We give our customers something that is still, unfortunately, a rare and endangered species in the industry: transparency centers, source code reviews of our products, a detailed software bill of materials (SBOM), and the ability to check update history and control rollouts. And of course we provide everything that’s already become the industry standard. You can study all the details in the full “Transparency and Accountability in Cybersecurity” (TRACS) report, or in our summary. Below, I’ll walk through some of the most interesting bits.
TRACS reviewed 14 popular vendors and their EPP/EDR products – from Bitdefender and CrowdStrike to our EDR Optimum and WithSecure. The objective was to understand which vendors don’t just say “trust us”, but actually let you verify their claims. The study covered 60 criteria: from GDPR (General Data Protection Regulation – it’s a European study after all) compliance and ISO 27001 audits, to the ability to process all telemetry locally and access a product’s source code. But the authors decided not to give points for each category or form a single overall ranking.
Why? Because everyone has different threat models and risks. What is a feature for one may be a bug and a disaster for another. Take fast, fully automatic installation of updates. For a small business or a retail company with thousands of tiny independent branches, this is a blessing: they’d never have enough IT staff to manage all of that manually. But for a factory where a computer controls the conveyor it would be totally unacceptable. A defective update can bring a production line to a standstill, which in terms of business impact could be fatal (or at least worse than the recent Jaguar Land Rover cyberattack); here, every update needs to be tested first. It’s the same story with telemetry. A PR agency sends data from its computers to the vendor’s cloud to participate in detecting cyberthreats and get protection instantly. Perfect. A company that processes patients’ medical records or highly classified technical designs on its computers? Its telemetry settings would need to be reconsidered.
Ideally, each company should assign “weights” to every criterion, and calculate its own “compatibility rating” with EDR/EPP vendors. But one thing is obvious: whoever gives customers choices, wins.
Take file reputation analysis of suspicious files. It can work in two ways: through the vendor’s common cloud, or through a private micro-cloud within a single organization. Plus there’s the option to disable this analysis altogether and work completely offline. Very few vendors give customers all three options. For example, “on-premise” reputation analysis is available from only eight vendors in the test. It goes without saying we’re one of them.
In every category of the test the situation is roughly the same as with the reputation service. Going carefully through all 45 pages of the report, we’re either ahead of our competitors or among the leaders. And we can proudly say that in roughly a third of the comparative categories we offer significantly better capabilities than most of our peers. See for yourself:
Visiting a transparency center and reviewing the source code? Verifying that the product binaries are built from this source code? Only three vendors in the test provide these things. And for one of them – it’s only for government customers. Our transparency centers are the most numerous and geographically spread out, and offer customers the widest range of options.
The opening of our first transparency center back in 2018
Downloading database updates and rechecking them? Only six players – including us – provide this.
Configuring multi-stage rollout of updates? This isn’t exactly rare, but it’s not widespread either – only seven vendors besides us support it.
Reading the results of an external security audit of the company? Only we and six other vendors are ready to share this with customers.
Breaking down a supply chain into separate links using an SBOM? This is rare too: you can request an SBOM from only three vendors. One of them is the green-colored company that happens to bear my name.
Of course, there are categories where everyone does well: all of them have successfully passed an ISO/IEC 27001 audit, comply with GDPR, follow secure development practices, and accept vulnerability reports.
Finally, there’s the matter of technical indicators. All products that work online send certain technical data about protected computers, and information about infected files. For many businesses this isn’t a problem, and they’re glad it improves effectiveness of protection. But for those seriously focused on minimizing data flows, AV-Comparatives measures those too – and we just so happen to collect the least amounts of telemetry compared to other vendors.
Thanks to the Austrian experts, CISOs and their teams now have a much simpler task ahead when checking their security vendors. And not just the 14 that were tested. The same framework can be applied to other security solution vendors and to software in general. But there are strategic conclusions too…
Transparency makes risk management easier. If you’re responsible for keeping a business running, you don’t want to guess whether your protection tool will become your weak point. You need predictability and accountability. The WKO and AV-Comparatives study confirms that our model reduces these risks and makes them manageable.
Evidence instead of slogans. In this business, it’s not enough to be able write “we are secure” on your website. You need audit mechanisms. The customer has to be able to drop by and verify things for themselves. We provide that. Others are still catching up.
Transparency and maturity go hand in hand. Vendors that are transparent for their customers usually also have more mature processes for product development, incident response, and vulnerability handling. Their products and services are more reliable.
Our approach to transparency (GTI) works. When we announced our initiative several years ago and opened Transparency Centers around the world, we heard all kinds of things from critics – like that it was a waste of money and that nobody needed it. Now independent European experts are saying that this is how a vendor should operate in 2025 and beyond.
It was a real pleasure reading this report. Not just because it praises us, but because the industry is finally turning in the right direction – toward transparency and accountability.
We started this trend, we’re leading it, and we’re going to keep pioneering within it. So, dear readers and users, don’t forget: trust is one thing; being able to fully verify is another.
AI will assist companies in finding their external attack surface, but it will also assist bad actors in locating and attacking the weak points.
The post Cyber Insights 2026: External Attack Surface Management appeared first on SecurityWeek.
Continuous Threat Exposure Management (CTEM) is a continuous program and operational framework, not a single pre-boxed platform. Flashpoint believes that effective CTEM must be intelligence-led, using curated threat intelligence as the operational core to prioritize risk and turn exposure data into defensible decisions.
Table Of ContentsSince Gartner’s introduction of CTEM as a framework in 2022, cybersecurity vendors have engaged in a rapid “productization” race. This has led to inconsistent market definitions, with a variety of vendors from vulnerability scanners to Attack Surface Management (ASM) providers now claiming to be an “exposure management” solution.
The current approach to productizing CTEM is flawed. There is no such thing as a single “exposure management platform.” The enterprise reality is that most enterprises buy three or more products just to approximate what CTEM promises in theory. Even with these technologies, organizations still require heavy lifting with people, process, and custom integrations to actually make it work.
A functional CTEM approach typically requires multiple platforms or tools, including:
In some cases, organizations may also use an ASM vendor for shadow IT discovery, a CMDB for asset context, and ticketing integrations to drive remediation. This multi-platform model is the rule, not the exception. And that raises a hard truth: if you need three or more products, plus a dedicated team to implement CTEM, you need an intelligence-led CTEM program.
The narrative that CTEM can be packaged into a single product breaks down for three critical reasons:
You cannot buy a capability that requires full-stack asset visibility, contextualized threat actor data, real-world validation, and remediation orchestration from one tool. Each component spans a different domain of expertise and data. A vulnerability scanner, alone, cannot validate exploitability, a pentest service has a tough time scaling to daily monitoring, and generic threat intelligence feeds cannot provide critical business context.
However, CTEM requires orchestration of all these components in one operational loop. No single product delivers this comprehensively out of the box; this is why CTEM must be viewed as a continuous program, not a one-size-fits-all product.
Vendors often advertise automation, however, key intelligence functions are still powered by and reliant on human analysis. Even with best-in-class AI tools in place, security teams are depending on human insights for:
In other words, exposure management today still relies on human insights and expertise. So while vendors advertise “automation and intelligence,” what they’re really delivering is a starting point. Ultimately, AI is a force multiplier for threat analysts, not a replacement.
Most platforms treat exposure like a math problem. But real risk isn’t just CVSS (Common Vulnerability Scoring System) scores or asset counts, it requires answering critical, intelligence-based questions:
These answers require intelligence, not just data. Best-in-class intelligence provides security teams with confirmed exploit activity in the wild, context around attacker usage in APT (Advanced Persistent Threat) campaigns, and detailed metadata for prioritization where CVSS fails. That is why Flashpoint intelligence is leveraged by over 800 organizations as the operational core of exposure management, turning exposure data into defensible decisions.
If your risk strategy requires continuous penetration and exploit testing, vulnerability management, threat intelligence, and manual prioritization and validation, you’re not buying CTEM; you’re building it. At Flashpoint, we’re helping organizations build CTEM the right way: driven by intelligence, and powered by integrations and AI.
Flashpoint treats CTEM for what it really is, as a program that must be constructed intelligently, iteratively, and contextually.
That means:
Using Flashpoint’s intelligence collections, organizations can achieve intelligence-led exposure management, with threat and vulnerability intelligence working together to provide context and actionable insights in a continuous, prioritized loop. This empowers security teams to build and scale their own CTEM programs, which is the only realistic approach in a cybersecurity landscape where no single platform can do it all.
If you’re evaluating exposure management tools, ask yourself:
The answers may surprise you. At Flashpoint, we’re helping organizations build CTEM the right way, driven by intelligence, powered by integration, and grounded in reality. Request a demo today and see how best-in-class intelligence is the key to achieving an effective CTEM program.
The post Why Effective CTEM Must be an Intelligence-Led Program appeared first on Flashpoint.
Anticipate, contextualize, and prioritize vulnerabilities to effectively address threats to your organization.
Table Of ContentsFlashpoint’s VulnDB documents over 400,000 vulnerabilities and has over 6,000 entries in Flashpoint’s KEV database, making it a critical resource as vulnerability exploitation rises. However, if your organization is relying solely on CVE data, you may be missing critical vulnerability metadata and insights that hinder timely remediation. That’s why we created this weekly series—where we surface and analyze the most high priority vulnerabilities security teams need to know about.
Of the vulnerabilities Flashpoint published this week, there are 34 that you can take immediate action on. They each have a solution, a public exploit exists, and are remotely exploitable. As such, these vulnerabilities are a great place to begin your prioritization efforts.
Of the vulnerabilities Flashpoint published last week, four are highlighted in this week’s Vulnerability Insights and Prioritization Report because they contain one or more of the following criteria:
In addition, all of these vulnerabilities are easily discoverable and therefore should be investigated and fixed immediately.
To proactively address these vulnerabilities and ensure comprehensive coverage beyond publicly available sources on an ongoing basis, organizations can leverage Flashpoint Vulnerability Intelligence. Flashpoint provides comprehensive coverage encompassing IT, OT, IoT, CoTs, and open-source libraries and dependencies. It catalogs over 100,000 vulnerabilities that are not included in the NVD or lack a CVE ID, ensuring thorough coverage beyond publicly available sources. The vulnerabilities that are not covered by the NVD do not yet have CVE ID assigned and will be noted with a VulnDB ID.
| CVE ID | Title | CVSS Scores (v2, v3, v4) | Exploit Status | Exploit Consequence | Ransomware Likelihood Score | Social Risk Score | Solution Availability |
| CVE-2025-33222 | NVIDIA Isaac Launchable Unspecified Hardcoded Credentials | 5.0 9.8 9.3 | Private | Credential Disclosure | High | Low | Yes |
| CVE-2025-33223 | NVIDIA Isaac Launchable Unspecified Improper Execution Privileges Remote Code Execution | 10.0 9.8 9.3 | Private | Remote Code Execution | High | Low | Yes |
| CVE-2025-68613 | n8n Package for Node.js packages/workflow/src/expression-evaluator-proxy.ts Workflow Expression Evaluation Remote Code Execution | 9.0 9.9 9.4 | Public | Remote Code Execution | High | High | Yes |
| CVE-2025-14847 | MongoDB transport/message_compressor_zlib.cpp ZlibMessageCompressor::decompressData() Function Zlib Compressed Protocol Header Handling Remote Uninitialized Memory Disclosure (Mongobleed) | 10.0 9.8 9.3 | Public | Uninitialized Memory Disclosure | High | High | Yes |
Flashpoint Ignite lays all of these components out. Below is an example of what this vulnerability record for CVE-2025-33223 looks like.
Below, Flashpoint analysts describe the five vulnerabilities highlighted above as vulnerabilities that should be of focus for remediation if your organization is exposed.
NVIDIA Isaac Launchable contains a flaw that is triggered by the use of unspecified hardcoded credentials. This may allow a remote attacker to trivially gain privileged access to the program.
NVIDIA Isaac Launchable contains an unspecified flaw that is triggered as certain activities are executed with unnecessary privileges. This may allow a remote attacker to potentially execute arbitrary code.
n8n Package for Node.js contains a flaw in packages/workflow/src/expression-evaluator-proxy.ts that is triggered as workflow expressions are evaluated in an improperly isolated execution context. This may allow an authenticated, remote attacker to execute arbitrary code with the privileges of the n8n process.
MongoDB contains a flaw in the ZlibMessageCompressor::decompressData() function in mongo/transport/message_compressor_zlib.cpp that is triggered when handling mismatched length fields in Zlib compressed protocol headers. This may allow a remote attacker to disclose uninitialized memory contents on the heap.
| CVE/VulnDB ID | Flashpoint Published Date |
| CVE-2025-21218 | Week of January 15, 2025 |
| CVE-2024-57811 | Week of January 15, 2025 |
| CVE-2024-55591 | Week of January 15, 2025 |
| CVE-2025-23006 | Week of January 22, 2025 |
| CVE-2025-20156 | Week of January 22, 2025 |
| CVE-2024-50664 | Week of January 22, 2025 |
| CVE-2025-24085 | Week of January 29, 2025 |
| CVE-2024-40890 | Week of January 29, 2025 |
| CVE-2024-40891 | Week of January 29, 2025 |
| VulnDB ID: 389414 | Week of January 29, 2025 |
| CVE-2025-25181 | Week of February 5, 2025 |
| CVE-2024-40890 | Week of February 5, 2025 |
| CVE-2024-40891 | Week of February 5, 2025 |
| CVE-2024-8266 | Week of February 12, 2025 |
| CVE-2025-0108 | Week of February 12, 2025 |
| CVE-2025-24472 | Week of February 12, 2025 |
| CVE-2025-21355 | Week of February 24, 2025 |
| CVE-2025-26613 | Week of February 24, 2025 |
| CVE-2024-13789 | Week of February 24, 2025 |
| CVE-2025-1539 | Week of February 24, 2025 |
| CVE-2025-27364 | Week of March 3, 2025 |
| CVE-2025-27140 | Week of March 3, 2025 |
| CVE-2025-27135 | Week of March 3, 2025 |
| CVE-2024-8420 | Week of March 3, 2025 |
| CVE-2024-56196 | Week of March 10, 2025 |
| CVE-2025-27554 | Week of March 10, 2025 |
| CVE-2025-22224 | Week of March 10, 2025 |
| CVE-2025-1393 | Week of March 10, 2025 |
| CVE-2025-24201 | Week of March 17, 2025 |
| CVE-2025-27363 | Week of March 17, 2025 |
| CVE-2025-2000 | Week of March 17, 2025 |
| CVE-2025-27636 CVE-2025-29891 | Week of March 17, 2025 |
| CVE-2025-1496 | Week of March 24, 2025 |
| CVE-2025-27781 | Week of March 24, 2025 |
| CVE-2025-29913 | Week of March 24, 2025 |
| CVE-2025-2746 | Week of March 24, 2025 |
| CVE-2025-29927 | Week of March 24, 2025 |
| CVE-2025-1974 CVE-2025-2787 | Week of March 31, 2025 |
| CVE-2025-30259 | Week of March 31, 2025 |
| CVE-2025-2783 | Week of March 31, 2025 |
| CVE-2025-30216 | Week of March 31, 2025 |
| CVE-2025-22457 | Week of April 2, 2025 |
| CVE-2025-2071 | Week of April 2, 2025 |
| CVE-2025-30356 | Week of April 2, 2025 |
| CVE-2025-3015 | Week of April 2, 2025 |
| CVE-2025-31129 | Week of April 2, 2025 |
| CVE-2025-3248 | Week of April 7, 2025 |
| CVE-2025-27797 | Week of April 7, 2025 |
| CVE-2025-27690 | Week of April 7, 2025 |
| CVE-2025-32375 | Week of April 7, 2025 |
| VulnDB ID: 398725 | Week of April 7, 2025 |
| CVE-2025-32433 | Week of April 12, 2025 |
| CVE-2025-1980 | Week of April 12, 2025 |
| CVE-2025-32068 | Week of April 12, 2025 |
| CVE-2025-31201 | Week of April 12, 2025 |
| CVE-2025-3495 | Week of April 12, 2025 |
| CVE-2025-31324 | Week of April 17, 2025 |
| CVE-2025-42599 | Week of April 17, 2025 |
| CVE-2025-32445 | Week of April 17, 2025 |
| VulnDB ID: 400516 | Week of April 17, 2025 |
| CVE-2025-22372 | Week of April 17, 2025 |
| CVE-2025-32432 | Week of April 29, 2025 |
| CVE-2025-24522 | Week of April 29, 2025 |
| CVE-2025-46348 | Week of April 29, 2025 |
| CVE-2025-43858 | Week of April 29, 2025 |
| CVE-2025-32444 | Week of April 29, 2025 |
| CVE-2025-20188 | Week of May 3, 2025 |
| CVE-2025-29972 | Week of May 3, 2025 |
| CVE-2025-32819 | Week of May 3, 2025 |
| CVE-2025-27007 | Week of May 3, 2025 |
| VulnDB ID: 402907 | Week of May 3, 2025 |
| VulnDB ID: 405228 | Week of May 17, 2025 |
| CVE-2025-47277 | Week of May 17, 2025 |
| CVE-2025-34027 | Week of May 17, 2025 |
| CVE-2025-47646 | Week of May 17, 2025 |
| VulnDB ID: 405269 | Week of May 17, 2025 |
| VulnDB ID: 406046 | Week of May 19, 2025 |
| CVE-2025-48926 | Week of May 19, 2025 |
| CVE-2025-47282 | Week of May 19, 2025 |
| CVE-2025-48054 | Week of May 19, 2025 |
| CVE-2025-41651 | Week of May 19, 2025 |
| CVE-2025-20289 | Week of June 3, 2025 |
| CVE-2025-5597 | Week of June 3, 2025 |
| CVE-2025-20674 | Week of June 3, 2025 |
| CVE-2025-5622 | Week of June 3, 2025 |
| CVE-2025-5419 | Week of June 3, 2025 |
| CVE-2025-33053 | Week of June 7, 2025 |
| CVE-2025-5353 | Week of June 7, 2025 |
| CVE-2025-22455 | Week of June 7, 2025 |
| CVE-2025-43200 | Week of June 7, 2025 |
| CVE-2025-27819 | Week of June 7, 2025 |
| CVE-2025-49132 | Week of June 13, 2025 |
| CVE-2025-49136 | Week of June 13, 2025 |
| CVE-2025-50201 | Week of June 13, 2025 |
| CVE-2025-49125 | Week of June 13, 2025 |
| CVE-2025-24288 | Week of June 13, 2025 |
| CVE-2025-6543 | Week of June 21, 2025 |
| CVE-2025-3699 | Week of June 21, 2025 |
| CVE-2025-34046 | Week of June 21, 2025 |
| CVE-2025-34036 | Week of June 21, 2025 |
| CVE-2025-34044 | Week of June 21, 2025 |
| CVE-2025-7503 | Week of July 12, 2025 |
| CVE-2025-6558 | Week of July 12, 2025 |
| VulnDB ID: 411705 | Week of July 12, 2025 |
| VulnDB ID: 411704 | Week of July 12, 2025 |
| CVE-2025-6222 | Week of July 12, 2025 |
| CVE-2025-54309 | Week of July 18, 2025 |
| CVE-2025-53771 | Week of July 18, 2025 |
| CVE-2025-53770 | Week of July 18, 2025 |
| CVE-2025-54122 | Week of July 18, 2025 |
| CVE-2025-52166 | Week of July 18, 2025 |
| CVE-2025-53942 | Week of July 25, 2025 |
| CVE-2025-46811 | Week of July 25, 2025 |
| CVE-2025-52452 | Week of July 25, 2025 |
| CVE-2025-41680 | Week of July 25, 2025 |
| CVE-2025-34143 | Week of July 25, 2025 |
| CVE-2025-50454 | Week of August 1, 2025 |
| CVE-2025-8875 | Week of August 1, 2025 |
| CVE-2025-8876 | Week of August 1, 2025 |
| CVE-2025-55150 | Week of August 1, 2025 |
| CVE-2025-25256 | Week of August 1, 2025 |
| CVE-2025-43300 | Week of August 16, 2025 |
| CVE-2025-34153 | Week of August 16, 2025 |
| CVE-2025-48148 | Week of August 16, 2025 |
| VulnDB ID: 416058 | Week of August 16, 2025 |
| CVE-2025-32992 | Week of August 16, 2025 |
| CVE-2025-7775 | Week of August 24, 2025 |
| CVE-2025-8424 | Week of August 24, 2025 |
| CVE-2025-34159 | Week of August 24, 2025 |
| CVE-2025-57819 | Week of August 24, 2025 |
| CVE-2025-7426 | Week of August 24, 2025 |
| CVE-2025-58367 | Week of September 1, 2025 |
| CVE-2025-58159 | Week of September 1, 2025 |
| CVE-2025-58048 | Week of September 1, 2025 |
| CVE-2025-39247 | Week of September 1, 2025 |
| CVE-2025-8857 | Week of September 1, 2025 |
| CVE-2025-58321 | Week of September 8, 2025 |
| CVE-2025-58366 | Week of September 8, 2025 |
| CVE-2025-58371 | Week of September 8, 2025 |
| CVE-2025-55728 | Week of September 8, 2025 |
| CVE-2025-55190 | Week of September 8, 2025 |
| VulnDB ID: 419253 | Week of September 13, 2025 |
| CVE-2025-10035 | Week of September 13, 2025 |
| CVE-2025-59346 | Week of September 13, 2025 |
| CVE-2025-55727 | Week of September 13, 2025 |
| CVE-2025-10159 | Week of September 13, 2025 |
| CVE-2025-20363 | Week of September 20, 2025 |
| CVE-2025-20333 | Week of September 20, 2025 |
| CVE-2022-4980 | Week of September 20, 2025 |
| VulnDB ID: 420451 | Week of September 20, 2025 |
| CVE-2025-9900 | Week of September 20, 2025 |
| CVE-2025-52906 | Week of September 27, 2025 |
| CVE-2025-51495 | Week of September 27, 2025 |
| CVE-2025-27224 | Week of September 27, 2025 |
| CVE-2025-27223 | Week of September 27, 2025 |
| CVE-2025-54875 | Week of September 27, 2025 |
| CVE-2025-41244 | Week of September 27, 2025 |
| CVE-2025-61928 | Week of October 6, 2025 |
| CVE-2025-61882 | Week of October 6, 2025 |
| CVE-2025-49844 | Week of October 6 2025 |
| CVE-2025-57870 | Week of October 6, 2025 |
| CVE-2025-34224 | Week of October 6, 2025 |
| CVE-2025-34222 | Week of October 6, 2025 |
| CVE-2025-40765 | Week of October 11, 2025 |
| CVE-2025-59230 | Week of October 11, 2025 |
| CVE-2025-24990 | Week of October 11, 2025 |
| CVE-2025-61884 | Week of October 11, 2025 |
| CVE-2025-41430 | Week of October 11, 2025 |
| VulnDB ID: 424051 | Week of October 18, 2025 |
| CVE-2025-62645 | Week of October 18, 2025 |
| CVE-2025-61932 | Week of October 18, 2025 |
| CVE-2025-59503 | Week of October 18, 2025 |
| CVE-2025-43995 | Week of October 18, 2025 |
| CVE-2025-62168 | Week of October 18, 2025 |
| VulnDB ID: 425182 | Week of October 25, 2025 |
| CVE-2025-62713 | Week of October 25, 2025 |
| CVE-2025-54964 | Week of October 25, 2025 |
| CVE-2024-58274 | Week of October 25, 2025 |
| CVE-2025-41723 | Week of October 25, 2025 |
| CVE-2025-20354 | Week of November 1, 2025 |
| CVE-2025-11953 | Week of November 1, 2025 |
| CVE-2025-60854 | Week of November 1, 2025 |
| CVE-2025-64095 | Week of November 1, 2025 |
| CVE-2025-11833 | Week of November 1, 2025 |
| CVE-2025-64446 | Week of November 8, 2025 |
| CVE-2025-36250 | Week of November 8, 2025 |
| CVE-2025-64400 | Week of November 8, 2025 |
| CVE-2025-12686 | Week of November 8, 2025 |
| CVE-2025-59118 | Week of November 8, 2025 |
| VulnDB ID: 426231 | Week of November 8, 2025 |
| VulnDB ID: 427979 | Week of November 22, 2025 |
| CVE-2025-55796 | Week of November 22, 2025 |
| CVE-2025-64428 | Week of November 22, 2025 |
| CVE-2025-62703 | Week of November 22, 2025 |
| VulnDB ID: 428193 | Week of November 22, 2025 |
| CVE-2025-65018 | Week of November 22, 2025 |
| CVE-2025-54347 | Week of November 22, 2025 |
| CVE-2025-55182 | Week of November 29, 2025 |
| CVE-2024-14007 | Week of November 29, 2025 |
| CVE-2025-66399 | Week of November 29, 2025 |
| CVE-2022-35420 | Week of November 29, 2025 |
| CVE-2025-66516 | Week of November 29, 2025 |
| CVE-2025-59366 | Week of November 29, 2025 |
| CVE-2025-14174 | Week of December 6, 2026 |
| CVE-2025-43529 | Week of December 6, 2026 |
| CVE-2025-8110 | Week of December 6, 2026 |
| CVE-2025-59719 | Week of December 6, 2026 |
| CVE-2025-59718 | Week of December 6, 2026 |
| CVE-2025-14087 | Week of December 6, 2026 |
| CVE-2025-62221 | Week of December 6, 2026 |
Request a demo today to see how Flashpoint can transform your vulnerability intelligence, vulnerability management, and exposure identification program.
CVE-2025-55182 (VulnDB ID: 428930), is a severe, unauthenticated RCE impacting a major component of React and its ecosystem, putting global applications at immediate, high-fidelity risk.
Table Of ContentsThe React team disclosed a critical vulnerability impacting three products in the React Server Components (RSC) that allows for unauthenticated remote code execution.
Flashpoint’s vulnerability research team assesses significant enterprise and supply chain risk given React’s ubiquity: the impacted JavaScript library underpins modern UIs, with 168,640 dependents and more than 51 million weekly downloads.
CVE-2025-55182 (VulnDB ID: 428930) impacts all React versions since 19.0.0, meaning that this issue has been potentially exploitable since November 14, 2024. This vulnerability stems from how React handles payloads sent to React Server Function endpoints and deserializes them.
Depending on the implementation of this library, a remote, unauthenticated threat actor could send a crafted payload that would be deserialized in a way that causes remote code execution. This would lead to a total compromise of the system hosting the application, allowing for malware such as infostealers, ransomware, or cryptojackers (cryptocurrency mining) to be downloaded.
A working exploit for CVE-2025-55182 has already been published that is effective against some installations. In addition, Amazon has reported that two threat actors, attributed to Chinese Advanced Persistent Threat Groups (APTs), have begun to exploit this vulnerability. Those groups are:
It is critical that security teams fully understand the potential downstream scope and impact so that they can fully focus on mitigation, rather than time-consuming research. While the vendor has provided a full disclosure, there are several important caveats to understand about CVE-2025-55182:
Additionally, several React frameworks and bundlers have been discovered to leverage vulnerable React packages in various ways. The following frameworks and bundlers are known to be affected:
NPMJS.com currently shows that the react-dom package, which is effectively part of React, has 168,640 dependents. This means that an incredible number of enterprise applications are likely to be affected. Nearly every commercial application is built on hundreds, sometimes thousands of components and dependencies. Furthermore, applications coded via Vibe and similar technology are also likely to leverage React: potentially amplifying the downstream risk this vulnerability poses.
For mitigation, the React library has released versions 19.0.1, 19.1.2, and 19.2.1 that resolve the issue. Flashpoint advises organizations to upgrade their respective libraries urgently. Security teams leveraging dynamic SBOMs (Software Bill of Materials) can drastically increase risk mapping and triage for deployed React versions.
CloudFlare has upgraded their web-application firewall (WAF) to protect against CVE-2025-55182. It is available for both free and paid plans but requires that React application traffic is proxied through the CloudFlare WAF.
To avoid confusion, security teams should ignore CVE-2025-66478. It has been rejected for being a duplicate of the preferred CVE-2025-55182.
Flashpoint strongly recommends security teams treat this vulnerability with utmost urgency. Our vulnerability research team will continue to monitor this vulnerability and its downstream impacts. All updates will be provided via Flashpoint’s VulnDB.
Request a demo today and gain access to quality vulnerability intelligence that helps address critical threats in a timely manner.
The post Digital Supply Chain Risk: Critical Vulnerability Affecting React Allows for Unauthorized Remote Code Execution appeared first on Flashpoint.
Flashpoint’s forward-looking threat insights for security and executive teams, provides the strategic foresight needed to prepare for the convergence of AI, identity, and physical security threats in 2026.
Table Of ContentsAs the global threat landscape accelerates its transformation, 2026 marks an inflection point requiring defensive strategies to fundamentally shift. The volatility observed in 2025 has paved the way for an era soon to be defined by AI-weaponized autonomy, information-stealing malware, systemic instability of public vulnerability systems, and the complete convergence of digital and physical risk.
Flashpoint offers a unique window into these complexities, providing organizations with the foresight needed to navigate what lies ahead. Drawing from Flashpoint’s leading intelligence and primary source collections, we highlight five key trends shaping the 2026 threat landscape. These insights aim to help organizations not only understand what’s next but also build the resilience needed to withstand and adapt to emerging challenges.
2026 will see continued evolution of AI threats, with future attacks centering on autonomy and integration. Across the deep and dark web, Flashpoint is observing threat actors move past experimentation and into operational use of illegal AI.
As attackers train custom fraud-tuned LLMs (Large Language Models) and multilingual phishing tools directly on illicit data, these AI models will become more capable. The criminal intent shaping their misuse will also become more sophisticated. Additionally, 2026 will see a greater marketplace for paid jailbreaking communities and synthetic media kits for KYC (Know Your Customer) bypass.
These advancements are enabling criminals to move beyond simple tools and engage in scaled, autonomous fraud operations, leading to two major shifts:
“The ubiquity of automation has dramatically increased attack tempo, leaving many security teams behind the curve. While automation can replace repetitive tasks across the enterprise, organizations must not make the critical mistake of substituting human judgement for AI at the intelligence level.
Josh Lefkowitz, CEO at Flashpoint
This is paramount because a critical threat in 2026 is Agentic AI autonomy weaponized against soft targets—API integrations and identity systems. The only winning defense will be human-led and AI-scaled, prioritizing purposeful use to keep organizations ahead of this exponential risk.”
These evolving AI threats will force a fundamental shift in defensive strategies. Defenders will have to shift to deploying systems around AI rather than trust them on their own.
Infostealers will become the entry point, the data broker, the reconnaissance layer, and the fuel for everything that comes after a cyberattack. This shift is already in motion and is accelerating rapidly: in just the first half of 2025, infostealers were responsible for 1.8 billion stolen credentials, an 800% spike from the start of the year. However, 2026 will redefine the malware’s role, making its most valuable output being access, rather than disruption.
Infostealers will become the upstream event that powers the rest of the attack chain. Identity and session data will be increasingly targeted, since it gives attackers immediate access into victim environments. Ransomware, fraud, data theft, and extortion will simply be downstream ways to monetize.
This upstream approach defines the new reality of the attack chain, which is already operational. Nearly every major stealer strain Flashpoint observes now exfiltrates the following:
An organization’s attack surface is no longer just composed of their own networks. It is the entire digital identity of their employees and partners. This new reality requires security teams to take a new approach. Instead of attempting to block attacks, they must proactively detect compromised credentials before they are weaponized. This will be the difference between reacting to a data breach and preventing one.
“The infostealer economy has fully industrialized the attack chain, making initial compromise a low-cost commodity. Multiple security incidents in 2025 tie back to credentials found in infostealer logs. This reality has underscored the critical importance of digital trust—specifically, verifying who can access what resources. For 2026, identity is the perimeter to watch, and security teams must proactively hunt for compromised credentials before they’re weaponized.”
Ian Gray, Vice President of Intelligence at Flashpoint
The temporary funding crisis at CVE in April 2025 and the subsequent CISA stopgap extension through March 2026 exposed the systemic fragility of a centralized vulnerability intelligence model. With the future of the CVE/NVD system hanging in the balance, 2026 will be defined by the urgent need for redundancy and diversification in vulnerability intelligence.
In today’s vulnerability intelligence ecosystem, nearly every organization’s vulnerability management framework relies on CVE and NVD—including its “alternatives” such as the EUVD (European Union Vulnerability Database). The CVE system has grown into a critical global cybersecurity utility, relied upon by nearly all vulnerability scanners, SIEM platforms, patch management tools, threat intelligence feeds, and compliance reports. A complete shutdown of CVE would result in a widespread loss of institutional infrastructure.
The next generation of security needs to be built on practices that are resilient, diversified, and intelligence-driven. It should be focused on providing insights that can be used to take action such as threat actor behavior, likelihood of exploitation in the wild, relevance to ransomware campaigns, and business context. Security teams will need to leverage a comprehensive source of vulnerability intelligence such as Flashpoint’s VulnDB that provides full coverage for CVE, while also cataloging more than 100,000 vulnerabilities missed by CVE and NVD.
The continued blurring of lines between cyber, physical, and geopolitical threats will elevate the risk to organizational leadership, turning executive protection into a holistic intelligence function in 2026. The rise of information warfare combined with physical world convergence means the threat to key personnel is no longer purely digital.
In the aftermath of the tragic December 2024 assassination of United Healthcare’s CEO, Flashpoint has seen the continued circulation and glorification of “wanted-style posters” of executives in extremist communities. Additionally, Flashpoint has seen nation-state actors participate, using espionage and influence to target high-value individuals.
Organizations must adopt an integrated approach that connects insights from threat actor chatter and a wealth of other OSINT sources. This fusion of intelligence is essential for applying frameworks to ensure the safety of leadership and key personnel.
2025 was marked by several large-scale extortion campaigns, demonstrating how the threat landscape is rapidly evolving. Ransomware operations have shifted into a straight extortion play. Flashpoint has observed a surge in new entrants to the ransomware market, accompanied by a decline in the quality and decorum of ransomware groups.
Furthermore, vishing campaigns attributed to “Scattered Spider” have highlighted weaknesses in identity, trust, and verification. Campaigns from “Scattered LAPSUS$ Hunters” have also exposed vulnerabilities in third-party integrations. These attacks culminated in extortion, showcasing that modern attacks will target trusted users and trusted applications for initial access, and will forgo ransomware in place of data access.
As this shift continues into 2026, threat actors will increasingly focus their efforts on exploiting human behavior and identity systems. Instead of attempting to spend resources on breaking network perimeters, attackers will instead socially engineer employees to gain access to corporate systems at scale. This change in TTPs will undoubtedly greatly increase supply chain risk, especially for third parties.
These five predictions highlight the transformative trends shaping the future of cybersecurity and threat intelligence. Staying ahead of these challenges demands more than just reactive measures—it requires actionable intelligence, strategic foresight, and cross-sector collaboration. By embracing these principles and investing in proactive security strategies, organizations can not only mitigate risks but also seize opportunities to enhance their resilience.
As the threat landscape continues to rapidly evolve, staying informed and prepared are critical components of risk mitigation. With the right tools, insights, and partnerships, security teams can navigate the complexities ahead and safeguard what matters most.
The post Flashpoint’s Top 5 Predictions for the 2026 Threat Landscape appeared first on Flashpoint.
Key takeaways: ITDR solutions monitor identity-based threats that traditional security tools miss, like hackers logging in with stolen credentials Effective ITDR requires integration with privileged access management and automated responses tailored to your specific environment Consolidating threat detection into a single dashboard dramatically improves response times and reduces the cost of managing multiple security tools […]
The post ITDR Best Practices: How to Detect, Prevent, and Contain Critical Identity Threats appeared first on Heimdal Security Blog.
In this post, we introduce the AWS provider for the Secrets Store CSI Driver, a new AWS Secrets Manager add-on for Amazon Elastic Kubernetes Service (Amazon EKS) that you can use to fetch secrets from Secrets Manager and parameters from AWS Systems Manager Parameter Store and mount them as files in Kubernetes pods. The add-on is straightforward to install and configure, works on Amazon Elastic Compute Cloud (Amazon EC2) instances and hybrid nodes, and includes the latest security updates and bugfixes. It provides a secure and reliable way to retrieve your secrets in Kubernetes workloads.
The AWS provider for the Secrets Store CSI Driver is an open source Kubernetes DaemonSet.
Amazon EKS add-ons provide installation and management of a curated set of add-ons for EKS clusters. You can use these add-ons to help ensure that your EKS clusters are secure and stable and reduce the number of steps required to install, configure, and update add-ons.
Secrets Manager helps you manage, retrieve, and rotate database credentials, application credentials, OAuth tokens, API keys, and other secrets throughout their lifecycles. By using Secrets Manager to store credentials, you can avoid using hard-coded credentials in application source code, helping to avoid unintended or inadvertent access.
We recommend installing the provider as an Amazon EKS add-on instead of the legacy installation methods (Helm, kubectl) to reduce the amount of time it takes to install and configure the provider. The add-on can be installed in several ways: using eksctl—which you will use in this post—the AWS Management Console, the Amazon EKS API, AWS CloudFormation, or the AWS Command Line Interface (AWS CLI).
The open-source Secrets Store CSI Driver maintained by the Kubernetes community enables mounting secrets as files in Kubernetes clusters. The AWS provider relies on the CSI driver and mounts secrets as file in your EKS clusters. Security best practice recommends caching secrets in memory where possible. If you prefer to adopt the native Kubernetes experience, please follow the steps in this blog post. If you prefer to cache secrets in memory, we recommend using the AWS Secrets Manager Agent.
IAM principals require Secrets Manager permissions to get and describe secrets. If using Systems Manager Parameter Store, principals also require Parameter Store permissions to get parameters. Resource policies on secrets serve as another access control mechanism, and AWS principals must be explicitly granted permissions to access individual secrets if they’re accessing secrets from a different AWS account (see Access AWS Secrets Manager secrets from a different account). The Amazon EKS add-on provides security features including support for using FIPS endpoints. AWS provides a managed IAM policy, AWSSecretsManagerClientReadOnlyAccess, which we recommend using with the EKS add-on.
In the following sections, you’ll create an EKS cluster, create a test secret in Secrets Manager, install the Amazon EKS add-on, and use it to retrieve the test secret and mount it as a file in your cluster.
Loginaws configure set default.region <preferred_region>
kubectl and eksctl command-line toolsWith the prerequisites in place, you’re ready to run the commands in the following steps in your terminal:
CLUSTER_NAME="my-test-cluster”
eksctl create cluster $CLUSTER_NAME
eksctl will automatically use a recent version of Kubernetes and create the resources needed for the cluster to function. This command typically takes about 15 minutes to finish setting up the cluster.
Create a secret named addon_secret in Secrets Manager:
aws secretsmanager create-secret \
--name addon_secret \
--secret-string "super secret!"
Install the Amazon EKS add-on:
eksctl create addon \
--cluster $CLUSTER_NAME \
--name aws-secrets-store-csi-driver-provider
Create an AWS Identity and Access Management (IAM) role that the EKS Pod Identity service principal can assume and save it in a shell variable (replace <region> with the AWS Region configured in your environment):
ROLE_ARN=$(aws --region <region> --query Role.Arn --output text iam create-role --role-name nginx-deployment-role --assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}')
Note: AWS provides a managed policy for client-side consumption of secrets through Secrets Manager: AWSSecretsManagerClientReadOnlyAccess. This policy grants access to get and describe secrets for the secrets in your account. If you want to further follow the principle of least privilege, create a custom policy scoped down to only the secrets you want to retrieve.
Attach the managed policy to the IAM role that you just created:
aws iam attach-role-policy \
--role-name nginx-deployment-role \
--policy-arn arn:aws:iam::aws:policy/AWSSecretsManagerClientReadOnlyAccess
Note: The add-on provides two methods of authentication: IAM roles for service accounts (IRSA) and EKS Pod Identity. In this solution, you’ll use EKS Pod Identity.
eksctl create addon \
--cluster $CLUSTER_NAME \
--name eks-pod-identity-agent
eksctl create podidentityassociation \
--cluster $CLUSTER_NAME \
--namespace default \
--region <region> \
--service-account-name nginx-pod-identity-deployment-sa \
--role-arn $ROLE_ARN \
--create-service-account true
The SecretProviderClass is a YAML file that defines which secrets and parameters to mount as files in your cluster.
SecretProviderClass called spc.yaml for the test secret with the following content:
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: nginx-pod-identity-deployment-aws-secrets
spec:
provider: aws
parameters:
objects: |
- objectName: "addon_secret"
objectType: "secretsmanager"
usePodIdentity: "true"
SecretProviderClass (make sure you’re in the same directory as the spc.yaml you just created):
kubectl apply -f spc.yaml
To learn more about the SecretProviderClass, see the GitHub readme for the provider.
For brevity, we’ve omitted the content of the Kubernetes deployment file. The following is an example deployment file for Pod Identity in the GitHub repository for the provider—use this file to deploy your pod:
kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/examples/ExampleDeployment-PodIdentity.yaml
This will mount addon_secret at /mnt/secrets-store in your cluster.
addon_secret to confirm that the secret was mounted successfully:
kubectl exec -it $(kubectl get pods | awk '/nginx-pod-identity-deployment/{print $1}' | head -1) -- cat /mnt/secrets-store/addon_secret
super secret!
You’ve successfully fetched your test secret from Secrets Manager using the new Amazon EKS add-on and mounted it as a file in your Kubernetes cluster.
Run the following commands to clean up the resources that you created in this tutorial:
aws secretsmanager delete-secret \
--secret-id addon_secret \
--force-delete-without-recovery
aws iam delete-role --role-name nginx-deployment-role
eksctl delete cluster $CLUSTER_NAME
In this post, you learned how to use the new Amazon EKS add-on for the AWS Secrets Store CSI Driver provider to securely retrieve your secrets and parameters and mount them as files in your Kubernetes clusters. The new EKS add-on provides benefits such as the latest security patches and bug fixes, tighter integration with Amazon EKS, and reduces the time it takes to install and configure the AWS Secrets Store CSI Driver provider. The add-on is validated by EKS to work with EC2 instances and hybrid nodes.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
Key takeaways: MITDR explained: Managed ITDR combines identity threat detection with expert-led response. Why it matters: Get better protection and lower costs without building a full in-house team. What to look for: Prioritize behavioral monitoring, real-time response, and expert oversight You’ve got the ITDR solution. That’s a good step towards effective account and identity-based threat […]
The post What is Managed ITDR? Key Definitions, Features, and Benefits appeared first on Heimdal Security Blog.
Engaging with the C-suite is not just about addressing security concerns or defending budget requests. It's about establishing and maintaining an ongoing discussion that aims to align security objectives with the interests of the business.
The post Communicating Security to the C-Suite: A Strategic Approach appeared first on Black Hills Information Security, Inc..
Risk is real. To better understand cybersecurity risk, let’s compare cyber risks to risks in the natural world from hurricanes. We can learn lessons from hurricanes and unnamed storms in […]
The post Cyber Risk Lessons We Can Learn From Hurricane Preparedness appeared first on Black Hills Information Security, Inc..
Patterson Cake // In PART 1 of “Wrangling the M365 UAL,” we talked about the value of the Unified Audit Log (UAL), some of the challenges associated with acquisition, parsing, […]
The post Wrangling the M365 UAL with SOF-ELK on EC2 (Part 2 of 3) appeared first on Black Hills Information Security, Inc..
