Security & IT News

CVSSv3 Score: 5.1 An improper neutralization of special elements used in an SQL command ('SQL injection') vulnerability [CWE-89] in FortiNDR may allow an authenticated attacker to execute arbitrary SQL commands on selected databases and tables via specifically crafted HTTP requests. Revised on 2026-05-12 00:00:00

Apple on Monday officially released iOS 26.5 with support for end-to-end encryption (E2EE) to Rich Communication Services (RCS) in beta as part of a "cross-industry effort" to replace traditional SMS with a more secure alternative. To that end, E2EE RCS messaging is rolling out to iPhone users running iOS 26.5 with supported carriers and Android users on the latest version of Google Messages.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

California Attorney General Rob Bonta announced a proposed $12.75 million settlement agreement with General Motors (GM) over allegations that the company violated the California Consumer Privacy Act (CCPA). [...]

Checkmarx has confirmed that a modified version of the Jenkins AST plugin was published to the Jenkins Marketplace. "If you are using Checkmarx Jenkins AST plugin, you need to ensure that you are using the version 2.0.13-829.vc72453fa_1c16 that was published on December 17, 2025 or previously," the cybersecurity company said in a statement over the weekend. As of writing, Checkmarx has released

A threat actor named Mr_Rot13 has been attributed to the exploitation of a recently disclosed critical cPanel flaw to deploy a backdoor codenamed Filemanager on compromised environments. The attack exploits CVE-2026-41940, a vulnerability impacting cPanel and WebHost Manager (WHM) that could result in an authentication bypass and allow remote attackers to gain elevated control of the control

A few months ago, I implemented Cloudflare's Turnstile CAPTCHA on some pages. The reason for implementing these CAPTCHAs is obvious: Bots make up a large percentage of traffic and affect site performance. So I figured it was a good time to look back and see how effective these CAPTCHA are. The quick number: Out of about 300 requests, only 1 passed the test. Or 99.7% of requests came from bots. And this is after we have been running this for a few months. Some bots may have stopped scanning the page. But what about false positives? One false positive I noted from the login page was people clicking Submit on the login form before the CAPTCHA test was completed. This was easily fixed with a bit of JavaScript, which enabled the button only after a test was completed. Some of the top offenders: 219.117.237.208. - resolves to 219.117.237.208.static.zoot.jp and appears to be some kind of spider 18.229.88.75 - an AWS host, also attempting to download our IP data 164.52.120.0/24 - Cloud provider in HK 2a03:2880:f806::/48 - Facebook Ireland So far, I have received only a few complaints about false positives (aside from the now fixed login page issue). Why I selected Turnstile over other CAPTCHA options: Cloudflare's turnstile implementation appears to have fewer privacy issues than others, like Google Recaptcha They are in my opinion, low impact to the user Implementing them on the site wasn't too difficult We already use Cloudflare as a CDN. They work well enough CAPTCHA can often be bypassed. The right CAPTCHA solution makes it hard enough for an attacker to bypass that the value of the data they would be getting is not worth the effort. -- Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu Twitter | (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

The Rapid7 2026 Global Cybersecurity Summit is just around the corner, and with it, a final opportunity to join the conversations shaping how security teams are adapting to a rapidly changing landscape. Over the past few weeks, we’ve shared a preview of what to expect, from the sessions and speakers to the themes running across the agenda. What has become increasingly clear is how closely these topics are connected. Security teams are being asked to move beyond reacting to incidents and instead understand how attacks begin, how they evolve, and how decisions can be made earlier with greater confidence. What you will gain from attending Across two days, the summit is structured to reflect how security teams actually operate. The first day builds a shared understanding of how the threat landscape has shifted, while the second day offers more focused sessions tailored to both leaders and practitioners. Sessions such as The Reality of Running a SOC in 2026 and Inside the Modern SOC explore how attacks unfold in practice, following signals from initial access through to response. These discussions highlight how analysts interpret activity across identity, cloud, and endpoint environments, and how decisions are made when multiple signals compete for attention. Other sessions, including Beyond the Vulnerability List and From Cloud Exposure to Runtime Attack , focus on how exposure is changing the way teams prioritize risk. The emphasis is on understanding context and how exposed assets actually are to attackers, helping teams determine which issues are most likely to lead to impact and where effort should be focused. Alongside this, sessions like The AI Dilemma: Automating Defense Without Surrendering Judgment examine how AI is being applied within SOC workflows. The discussion moves beyond theory and looks at how teams are balancing automation with human oversight, ensuring that speed does not come at the expense of trust or accountability. What’s changing for security teams right now Security operations are evolving in response to changes in both attacker behavior and organizational complexity. Environments are more distributed, signals are more fragmented, and the time available to respond continues to shrink. As a result, the focus is shifting toward earlier action, better prioritization, and more connected decision-making. This means linking exposure with detection, reducing unnecessary noise, and building workflows that allow teams to act with clarity when it matters most. Across the summit, these ideas are explored from multiple perspectives, but they consistently point toward the same outcome. Teams that can connect context, visibility, and response are better positioned to reduce risk before it becomes an incident. Secure your place With the event approaching, this is the final opportunity to register and take part in these discussions. Whether you are responsible for strategy, operations, or day-to-day detection and response, the summit is des

Rough Monday. Somebody poisoned a trusted download again, somebody else turned cloud servers into public housing, and a few crews are still getting into boxes with bugs that should’ve died years ago — the same old holes, same lazy access paths, same “how the hell is this still open” feeling. One report this week basically reads like a guy tripped over root access by accident and decided to stay

Defending a network at 2 am looks a lot like this: an analyst copy-pasting a hash from a PDF into a SIEM query. A red team script is being rewritten by hand so the blue team can use it. A patch waiting on a change-approval window that's longer than the exploitation window itself. Nobody in that chain is incompetent. Every human is doing their job correctly. The problem is the system, its

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Spring cleanup This week’s Metasploit updates focused on foundational improvements and expanded target reach. Key enhancements were made to the recently released Copy Fail exploit module, which now benefits from payload fixes in linux/x64/exec and linux/armle/exec. These changes expand its capability, enabling the use of the cmd/unix/python/meterpreter/reverse_tcp payload on x64 targets and introducing support for ARMLE Linux. Additionally, the exploit/multi/http/shiro_rememberme_v124_deserialize module has been improved to allow operators to adjust the deserialization chain, enabling exploitation of a broader set of targets. Finally, several critical utility modules, including the FTP anonymous scanner and other FTP modules, received general fixes and updates. New module content (1) Anonymous FTP Access Detection Authors: Matteo Cantoni [email protected] and g0tmi1k Type: Auxiliary Pull request: #21372 contributed by g0tmi1k Path: scanner/ftp/ftp_anonymous AttackerKB reference: CVE-1999-0497 Description: This updates the FTP anonymous scanner module. Key changes include moving the module to align with other generic FTP modules, adding and updating CVE references and documentation notes, and cleaning up the output to be more verbose. Additionally, the module now reports service and vulnerability data to the database and stores proof-of-exploitation info in the loot upon a successful run. Enhanced Modules (2) Modules which have either been enhanced, or renamed: #21410 from inkognitobo - This improves the exploit/multi/http/shiro_rememberme_v124_deserialize module by adding a JAVA_GADGET_CHAIN datastore option that allows the operator to adjust the chain used for deserialization. This enables the module to exploit additional targets. #21404 from zeroSteiner - This extends the support of Copy Fail to ARMLE Linux targets. Enhancements and features (4) #21342 from adfoster-r7 - Defers the loading of some dependencies to improve console boot time. #21372 from g0tmi1k - This updates the FTP anonymous scanner module. Key changes include moving the module to align with other generic FTP modules, adding and updating CVE references and documentation notes, and cleaning up the output to be more verbose. Additionally, the module now reports service and vulnerability data to the database and stores proof-of-exploitation info in the loot upon a successful run. #21380 from g0tmi1k - Updates multiple FTP modules to now register FTP service information in the database when successfully connecting to an FTP service. #21418 from kx7m2qd - This improves the platform-agnostic library used to obtain the OS architecture with support for shell sessions on Linux, BSD and Mac OSX. Bugs fixed (5) #21314 from g0tmi1k - Fixes a crash when running the scanner/http/trace module with the database enabled and a vulnerability was reported. #21411 from zeroSteiner - This fixes a bug in the linux/x64/exec payload that was caused by the CMD datastore option being placed in the assemb

In this article Why Dirty Frag matters Technical overview Exploitation scenarios Mitigation guidance Post-mitigation integrity verification References A newly disclosed Linux local privilege escalation vulnerability known as “Dirty Frag” enables escalation from an unprivileged user to root through vulnerable kernel networking and memory-fragment handling components, including esp4, esp6 (CVE-2026-43284), and rxrpc (CVE-2026-43500). Public reporting and proof-of-concept activity indicate the exploit is designed to provide more reliable privilege escalation than traditional race-condition-dependent Linux local privilege escalation techniques. Dirty Frag may be leveraged after initial compromise through SSH access, web-shell execution, container escape, or compromise of a low-privileged account. Affected environments may include Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE, and OpenShift deployments. Microsoft Defender is actively monitoring related activity and investigating additional detections and protections. This article details an ongoing investigation into active campaign. We will update this report as new details emerge. Why Dirty Frag matters Local privilege escalation vulnerabilities are frequently used by threat actors after initial access to expand control over a compromised environment. Once root access is obtained, attackers can disable security tooling, access sensitive credentials, tamper with logs, pivot laterally, and establish persistent access. Dirty Frag is notable because it introduces multiple kernel attack paths involving rxrpc and esp/xfrm networking components to improve exploitation reliability. Rather than relying on narrow timing windows or unstable corruption conditions often associated with Linux local privilege escalation exploits, Dirty Frag appears designed to increase consistency across vulnerable environments. This increases operational risk in environments where threat actors already possess limited local execution capability through compromised accounts, vulnerable applications, containers, or exposed administrative interfaces. Technical overview Dirty Frag abuses Linux kernel networking and memory-fragment handling behavior involving esp4, esp6, and rxrpc components. Similar to the previously disclosed CopyFail vulnerability (CVE-2026-31431), the exploit attempts to manipulate Linux page cache behavior to achieve privilege escalation. However, Dirty Frag introduces additional attack paths that expand exploitation opportunities and improve reliability. The vulnerability affects systems where vulnerable modules are present and accessible. In many enterprise environments, these components may already be enabled to support IPsec, VPN functionality, or other networking workloads. Exploitation scenarios Threat actors may leverage Dirty Frag after obtaining local code execution through several common intrusion paths, including: Compromised SSH accounts Web-shell access on internet-facing applications Cont

Every engineering team in your organization ships code through a pipeline. They branch, test, review, and deploy. If something breaks, they roll back. If someone asks "what changed?", the answer is in the commit history. This isn't heroic discipline to process; it's just how software gets built. Now think about how your detection engineering team works. Rules get written in a UI. Maybe copied and pasted from a wiki. There's no peer review; someone clicks "save," and it's live. No test cases validate the logic before deployment. No rollback if something breaks. When an alert suddenly floods your SOC, good luck figuring out what changed and when. When a detection stops firing, you might not notice for weeks. This is, by definition, a process gap . And it's one that the rest of engineering solved years ago. The gap becomes manageable through the five custom rules, listed below. As your detections grow, you need the same discipline that every other engineering team already has. Process Stage How it works in software engineering How it works in detection engineering Storage Git / Version Control UI / Wiki / "Tribal Knowledge" Validation Automated CI/CD Tests "Wait and see if it fires" Review Peer-reviewed Pull Requests Single-user "Save" button Rollback One-click git revert Manual query deletion How does this help my security team? Detection as Code gives your team a structured, repeatable way to build and manage detections with confidence. Instead of relying on manual updates and guesswork, every change is tested, reviewed, and tracked before it reaches production. Before we get into the how , here's why Detection as Code changes the way your team works: A more reliable process. Every change goes through version control and peer review before it goes live. When something goes wrong, you know exactly what changed, when it changed, and who approved it. Roll back in seconds if needed. A safety net of tests. Inline test cases validate detection logic before deployment. Positive tests prove it catches the threat; negative tests prove it doesn't fire on legitimate activity. Confidence in what's deployed. terraform plan previews every change before anything touches production. Terraform state is the authoritative record of your detection estate, not some spreadsheet. The result is a detection workflow your team can trust. Changes are predictable, validated, and fully traceable, so security teams don’t get caught up in troubleshooting and can focus on improving coverage and overall posture. The anatomy of a detection Here is what a detection rule looks like using Rapid7’s Terraform provider . It offers a practical view of how detection engineering teams can use Detection as Code in practice: resource "rapid7_siem_detection_rule" "encoded_powershell" { name = "Encoded PowerShell Command Execution" description = "Detects PowerShell launched with base64-encoded commands" techniques = ["T1059.001"] action = "CREATES_ALERTS" priority = "HIGH" logic = { leql = -LE

p CISA has added nbsp;one nbsp;new vulnerability nbsp;to its nbsp; a href="https://www.cisa.gov/known-exploited-vulnerabilities-catalog" Known Exploited Vulnerabilities (KEV) Catalog /a , based on evidence of active exploitation. /p ul type="disc" li a href="https://www.cve.org/CVERecord?id=CVE-2026-42208" target="_blank" CVE-2026-42208 /a nbsp;BerriAI nbsp;LiteLLM nbsp;SQL Injection Vulnerability /li /ul p This nbsp;type nbsp;of vulnerability is a nbsp;frequent attack vector nbsp;for malicious cyber actors and poses nbsp;significant risks to the federal enterprise. /p p a href="https://www.cisa.gov/binding-operational-directive-22-01" Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities /a nbsp;established the KEV Catalog as a living list of known Common Vulnerabilities and Exposures (CVEs) that carry significant risk to the federal enterprise. BOD 22-01 requires Federal Civilian Executive Branch (FCEB) agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See the nbsp; a href="https://www.cisa.gov/sites/default/files/publications/Reducing_the_Significant_Risk_of_Known_Exploited_Vulnerabilities_211103.pdf" BOD 22-01 Fact Sheet /a nbsp;for more information. /p p Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing nbsp;timely nbsp;remediation of nbsp; a href="https://www.cisa.gov/known-exploited-vulnerabilities-catalog" KEV Catalog vulnerabilities /a nbsp;as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the catalog that meet the nbsp; a href="https://www.cisa.gov/known-exploited-vulnerabilities" specified criteria /a . nbsp; /p

In this article A representative case study: Semantic Kernel CVE-2026-26030: In-Memory Vector Store CVE-2026-25592: Arbitrary file write through SessionsPythonPlugin The vulnerability Attack chain overview Defending the agentic edge Not bugs, but developed by design CTF challenge: Attack your own agent Learn more AI agents have fundamentally changed the threat model of AI model-based applications. By equipping these models with plugins (also called tools), your agents no longer just generate text; they now read files, search connected databases, run scripts, and perform other tasks to actively operate on your network. Because of this, vulnerabilities in the AI layer are no longer just a content issue and are an execution risk. If an attacker can control the parameters passed into these plugins via prompt injection, the agent may be driven to perform actions beyond its intended use. The AI model itself isn’t the issue as it’s behaving exactly as designed by parsing language into tool schemas. The vulnerability lies in how the framework and tools trust the parsed data. To build powerful applications, developers rely heavily on frameworks like Semantic Kernel, LangChain, and CrewAI. These frameworks act as the operating system for AI agents, abstracting away complex model orchestration. But this convenience comes with a hidden cost: because these frameworks act as a ubiquitous foundational layer, a single vulnerability in how they map AI model outputs to system tools carries systemic risk. As part of our mission to make AI systems more secure and eliminate new class of vulnerabilities, we’re launching a research series focused on identifying vulnerabilities in popular AI agent frameworks. Through responsible disclosure, we work with maintainers to ensure issues are addressed before sharing our findings with the community. In this post, we share details on the vulnerabilities we discovered in Microsoft’s Semantic Kernel, along with the steps we took to address them and interactive way to try it yourself. Stay tuned for upcoming blogs where we’ll dive into similar vulnerabilities found in frameworks beyond the Microsoft ecosystem. Background We discovered a vulnerable path in Microsoft Semantic Kernel that could turn prompt injection into host-level remote code execution (RCE). A single prompt was enough to launch calc.exe on the device running our AI agent, with no browser exploit, malicious attachment, or memory corruption bug needed. The agent simply did what it was designed to do: interpret natural language, choose a tool, and pass parameters into code. Figure 1. Illustration of CVE-2026-26030 exploitation using a local model. This scenario is the real security story behind modern AI agents. Once an AI model is wired to tools, prompt injection draws a thin line between being just a content security problem and becoming a code execution primitive. In this post in our research series on AI agent framework security, we show how two vulnerabilities in

Wade Woolwine is Senior Director, Product Security at Rapid7. Announcing OpenAI's Trusted Access for Cyber program CIOs and CISOs are telling us the same thing in different ways: Advances in frontier AI are accelerating the threat environment and putting pressure on security operating models built for a different pace. Vulnerabilities can be discovered faster, exploitation windows are shrinking, and attackers are increasingly using automation to move with greater speed and scale. For defenders, this changes the value equation. The premium is no longer only on detecting threats faster after they emerge, but on moving earlier: Reducing exposure, validating risk, strengthening detection, and remediating at scale before attackers can take advantage. This is why Rapid7 is excited to be included in OpenAI’s Trusted Access for Cyber program and their announcement today. OpenAI’s approach recognizes that advanced AI can help verified security teams move faster on legitimate defensive work, from triage and detection to validation, patching, malware analysis, and detection engineering. It also recognizes that some specialized cyber workflows require stronger verification, monitoring, and feedback loops. As Corey Thomas, CEO of Rapid7, shared: “Security leaders are under pressure from every direction: More vulnerabilities, faster exploitation, and increasing business pressure. Through OpenAI’s Trusted Access for Cyber program, Rapid7 is exploring more ways to accelerate the shift from reactive to preemptive security. To stay ahead of attackers, defenders must proactively reduce exploitability and detect with machine-scale speed and precision. We’re working with OpenAI to equip security teams with advanced capabilities that will meaningfully improve their cyber resilience.” AI in security: Not just faster discovery For Rapid7, this moment is about more than faster vulnerability discovery. AI is creating new pressure across the entire security lifecycle, from vulnerability validation, prioritization, disclosure, and remediation to threat and exploitation detection. Security infrastructure built for human-speed discovery now needs to operate in a machine-speed world, with enough context, governance, and accountability to help defenders act with confidence. Finding risk is only the beginning. Security teams need to understand which vulnerabilities and misconfigurations are truly exploitable, which systems and business services are affected, what compensating controls are in place, how remediation should be prioritized, and where detection coverage is needed. CISOs also need confidence that advanced AI is being applied responsibly, with clear guardrails, measurable outcomes, and accountability. Our work with OpenAI will help us explore how frontier AI can strengthen three critical areas. First, it can support the identification of vulnerabilities in our own products and code earlier in the development lifecycle. By accelerating secure code review, surfacing risk

Let's be honest, the patching window just shrank to something no practitioner or organization can keep up with. Organizations now need to operate in an environment that must assume breach, which means fundamentals like attack surface management, micro-segmentation, identity management, and attack path validation – aka a few core pillars of CTEM – just became the most important initiatives within the cybersecurity department. Rapid7 is the only vendor that provides a truly unified platform to master Continuous Threat Exposure Management (CTEM) . How Rapid7 satisfies all 5 steps of the CTEM Framework Steps 1 and 2: Scoping and Discovery Achieving full visibility Rapid7 eliminates "unknown unknowns" by providing line-of-sight into 100% of your hybrid attack surface. Surface Command (CAASM): We establish a single source of truth by unifying asset and identity inventory from over 200 third-party vendors and native sources. Vulnerability Management: Our full-stack active scanning discovers shadow IT hidden within your enterprise network. External Attack Surface Management (EASM): We scan the entire IPv4 space of the internet to automatically track changes to registered domains and public networks so you can map your external kingdom. Unified CNAPP (Cloud Security): Our platform provides real-time, agentless visibility into every resource running across your multi-cloud environment (AWS, Azure, GCP, and Kubernetes). Through Event-Driven Harvesting (EDH) , we identify infrastructure changes in under 60 seconds. This allows us to map not just the assets, but the complex identities and permissions that define your cloud risk. Step 3: Prioritization Moving beyond static scores We replace generic risk scores with Active Risk and Threat-Aware Context . Our platform automatically prioritizes vulnerabilities based on real-world exploitability data from Rapid7 Labs and the Exploit Prediction Scoring System (EPSS). We are also able to incorporate your own organization’s tagging infrastructure to properly contextualize your enterprise so you focus on what matters most. Step 4: Validation Continuous human-led red teaming This is where Rapid7 truly stands apart from automated-only vendors or point-in-time pen tests. Vector Command provides the expert human logic needed to bypass compensating controls like WAFs that stop automated tools cold. This gives Rapid7 the ability to answer the question: “How would an attacker get in?” We fully map the attack chain from the external to the internal so you have insight into where your controls are weakest. Ed Montgomery at Rapid7 has written extensively about the power of Vector Command – you can find his blogs here . Here’s a sampling of a couple of those stories: The Telerik UI Example: While a scanner flags an old version of Telerik, our operators discovered they could bypass a WAF by splitting a malicious payload into 118 individual, "harmless" fragments. We bypassed the WAF and this achieved full remote code execution tha

p CISA has added one new vulnerability to its nbsp; a href="https://www.cisa.gov/known-exploited-vulnerabilities-catalog" Known Exploited Vulnerabilities (KEV) Catalog /a , based on evidence of active exploitation. /p ul type="disc" li a href="https://www.cve.org/CVERecord?id=CVE-2026-6973" target="_blank" CVE-2026-6973 /a nbsp;Ivanti Endpoint Manager Mobile (EPMM) Improper Input Validation Vulnerability nbsp; /li /ul p This type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks to the federal enterprise. /p p a href="https://www.cisa.gov/binding-operational-directive-22-01" Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities /a nbsp;established the KEV Catalog as a living list of known Common Vulnerabilities and Exposures (CVEs) that carry significant risk to the federal enterprise. BOD 22-01 requires Federal Civilian Executive Branch (FCEB) agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See the nbsp; a href="https://www.cisa.gov/sites/default/files/publications/Reducing_the_Significant_Risk_of_Known_Exploited_Vulnerabilities_211103.pdf" BOD 22-01 Fact Sheet /a nbsp;for more information. /p p Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing nbsp;timely nbsp;remediation of nbsp; a href="https://www.cisa.gov/known-exploited-vulnerabilities-catalog" KEV Catalog vulnerabilities /a nbsp;as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the catalog that meet the nbsp; a href="https://www.cisa.gov/known-exploited-vulnerabilities" specified criteria /a . nbsp; /p

p a href="https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-127-01.json" strong View CSAF /strong /a /p h2 Summary /h2 p strong Successful exploitation of this vulnerability may enable an attacker to access tenant email addresses and associated information in cleartext or cause a denial-of-service condition. /strong /p p The following versions of MAXHUB Pivot client application are affected: /p ul li MAXHUB Pivot client application /li /ul div class="csaf-table" table class="tablesaw tablesaw-stack" data-tablesaw-mode="stack" data-tablesaw-minimap thead tr th role="columnheader" data-tablesaw-priority="persist" CVSS /th th role="columnheader" Vendor /th th role="columnheader" Equipment /th th role="columnheader" Vulnerabilities /th /tr /thead tbody tr td v3 7.3 /td td MAXHUB /td td MAXHUB Pivot client application /td td Use of a Broken or Risky Cryptographic Algorithm /td /tr /tbody /table /div h3 Background /h3 ul li strong Critical Infrastructure Sectors: /strong Information Technology /li li strong Countries/Areas Deployed: /strong Worldwide /li li strong Company Headquarters Location: /strong United States /li /ul hr h2 Vulnerabilities /h2 div class="csaf-accordion" p a class="csaf-accordion-toggle-all" href="#" Expand All + /a /p div class="csaf-accordion-item" h3 a class="csaf-accordion-toggle" href="#" CVE-2026-6411 /a /h3 div class="csaf-accordion-content" p This vulnerability, in the MAXHUB Pivot client application versions prior to v1.36.2, may allow an attacker to obtain encrypted tenant email addresses and related metadata from any tenant. Due to the presence of a hardcoded AES key within the application, the encrypted data can be decrypted, enabling access to tenant email addresses and associated information in cleartext. Furthermore, an attacker may be able to cause a denial-of-service condition by enrolling multiple unauthorized devices into a tenant via MQTT, potentially disrupting tenant operations. /p p a href="https://www.cve.org/CVERecord?id=CVE-2026-6411" View CVE Details /a /p hr h4 Affected Products /h4 h5 MAXHUB Pivot client application /h5 div class="ics-vendor-version-status" div class="ics-vendor" strong Vendor: /strong br MAXHUB /div div class="ics-version" strong Product Version: /strong br MAXHUB MAXHUB Pivot client application: lt;v1.36.2 /div div class="ics-status" strong Product Status: /strong br known_affected /div /div div class="ics-remediations" h6 Remediations /h6 p strong Mitigation /strong br MAXHUB recommends users upgrade the Pivot client application to v1.36.2 or newer. The remediation has been made available through an OTA update. Users running v1.36.2 or later are not affected and need only ensure they continue to maintain the latest version. At this time, MAXHUB is not aware of any public exploitation of this issue. For more information, see the MAXHUB support page. br a href="https://www.maxhub.com/en/support/" https://www.maxhub.com/en/support/ /a /p /div p strong Releva