Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
The endpoint management category is being redefined in real time. Organizations no longer need tools that only inventory devices or enforce configuration policies; they need a platform that connects identity, security, compliance, and AI governance across every endpoint where work happens. Microsoft’s recognition as a Leader in The Forrester Wave™: Endpoint Management Platforms, Q2 2026 report reflects that shift—and the role Microsoft Intune plays in helping organizations manage what’s next.
Figure 1: Forrester Wave showing Microsoft in a Leader position for both strength of offering and strategy
Why Microsoft Intune is a leader in endpoint management
The Forrester Wave™ Endpoint Management Platforms, Q2 2026 report includes eight endpoint management platform providers, assessed across current offering, strategy, and customer feedback. Forrester’s assessment of Microsoft reflects how Intune is built. The vision Forrester describes is one built on Microsoft Entra, Microsoft Defender, Windows, and Windows 365 as a connected system, not a collection of adjacent tools. Customers can enforce conditional access, apply compliance policies, and correlate device health signals from a single admin center. That reach is what the cross-platform, cloud-native architecture is built for.
Microsoft Intune offers a strong platform for Windows environments, as customer feedback in the Forrester report notes, and Intune brings management across Windows, macOS, iOS, and Android together in the same admin console. That leadership extends from information worker devices to the frontline worker endpoints that are increasingly critical to business operations. On macOS specifically, Intune uses declarative device management to apply configuration and compliance policies natively, without requiring a separate tool or an additional management layer. Frontline workers on shared kiosks and handheld scanners, and information workers on corporate laptops, fall under the same policies without requiring parallel toolchains.
Endpoint Privilege Management (EPM) received explicit recognition from Forrester, which noted that AI embedded in Intune powers EPM and device onboarding workflows to help IT analyze device data and troubleshoot issues. Elevating or restricting privileges used to require manual review cycles. With AI in that workflow, admins make faster decisions on which requests to approve, deny, or escalate.
Security Copilot in Intune operates directly within the admin experience, operating on the same data and policy surface IT teams already use. From policy configuration, to identifying vulnerabilities, and recommending remediation, agentic assistance handles investigation and triage so admins focus on decisions that need judgment. The recent public preview of the Vulnerability Remediation Agent extends that further, drawing on Microsoft Defender Vulnerability Management to surface CVEs across Intune-managed Windows devices and apps, with Copilot-assisted impact summaries, suggested actions, and step-by-step remediation guidance, all without leaving the console.
These capabilities do not stand alone. Forrester also recognized a superior partner strategy. Our strategy helps connect endpoint management to the service desk, device procurement, and mobile threat defense tools already in the environment. Endpoint management that stops at the device boundary does not close the loop on risk. Intune, with capabilities such as EPM and AI-assisted remediation, brings its partner ecosystem together to help turn Zero Trust from core principles into daily IT practice: apply least privilege, verify explicitly, and enforce through policy to prevent breach.
On licensing, Forrester’s independent customer feedback pointed to the economic value of Microsoft simplified, bundled pricing. Intune is included in Microsoft 365 E3 and Microsoft 365 E5. Starting this month, advanced management solutions of the Intune Suite, including EPM, join those plans automatically. Full details are in our announcement blog: Microsoft 365 adds advanced Microsoft Intune solutions at scale. We continue to invest in areas such as unattended remote access sign-in for Intune Remote Help and automatic updates of required apps for Intune Enterprise Application Management, both of which will roll out for general availability in July 2026, and Intune now supports Red Hat Enterprise Linux 9 and 10.
Governing AI for the future of work
Every organization putting AI to work in practice needs IT and security teams that can say yes confidently: Yes to new device types, yes to modern workloads, and yes to agents running alongside users. Trust and confidence are requirements for safe AI adoption. Microsoft Agent 365 gives organizations a control plane for agents they can trust, and confidence comes from having a platform where identity, device management, and security policy are already connected. A unified platform does not just reduce complexity. It changes what teams are able to do with their time, and what the organization is able to do with AI.
AI agents are now endpoints, and Intune is the policy layer for Agent 365 that governs how they run. Through Microsoft Execution Containers, Intune gates local agent runtime execution directly on Windows devices, requiring isolation with guardrails like filesystem rules so agents run in controlled environments rather than with unchecked access to host systems. Windows 365 for Agents extends that model to cloud PCs provisioned specifically for agent workloads: Each agent Cloud PC is Entra-joined and Intune-managed, configured with the same security, compliance, and policy controls as user devices, so governance scales without new infrastructure.
For shadow AI, Intune is one of three signals alongside Defender and Entra that surface unmanaged agents. Defender discovers agents and adds inline protection; Intune applies policies to block common execution methods and device-level runtime security policies, giving multiple connected signals and one coordinated posture rather than multiple parallel workflows. That is how AI moves from an isolated pilot into the daily practice of how organizations operate, govern and protect AI, not just enable it.
At Microsoft, we believe Forrester’s assessment reflects where the market is heading, where governance, identity, and security work as one system. Each capability is more effective because it operates on shared signal, not siloed data. Microsoft Intune helps organizations reduce complexity, strengthen security, and make AI adoption practical at scale—governed and protected.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. This report is part of a broader collection of Forrester resources, including interactive models, frameworks, tools, data, and access to analyst guidance. For more information, read about Forrester’s objectivity here .
The EU Cyber Resilience Act (CRA) was officially introduced on December 10th 2024, to protect foundational EU values in the face of rising cyberattack threats. As cyberattacks targeting products with digital elements have grown more frequent and costly, the regulation establishes the first horizontal cybersecurity baseline for all hardware and software products sold in Europe. The urgency is real given that in Omdia’s 2026 software supply chain security report, 77% of organizations reported experiencing a supply chain incident in the last year.
The regulation will take full effect on December 11, 2027, but mandatory vulnerability reporting obligations take effect on September 11, 2026. For teams building and shipping containerized software, the CRA turns practices like SBOM generation, vulnerability disclosure, and image hardening from voluntary best practices into legal requirements.
This guide covers what the EU CRA requires, who it applies to, how its SBOM mandate connects to container build workflows, and what teams need to do before the compliance deadlines arrive.
Key takeaways
The CRA requires all products with digital elements sold in the EU to meet cybersecurity standards by December 2027.
Manufacturers must include a machine-readable SBOM in technical documentation for every product.
Actively exploited vulnerabilities and severe incidents having an impact on the security of a product with digital elements must be reported to authorities within 24 hours starting September 2026.
Container runtimes distributed commercially into the EU qualify as products with digital elements under the CRA.
What is the EU Cyber Resilience Act (CRA)?
Before the CRA, the EU had no single, cross-sector regulation setting cybersecurity baselines for products with digital elements. A smart thermostat, an enterprise database, and a container runtime were all subject to different (or no) cybersecurity obligations. There was no general obligation to patch vulnerabilities, disclose security incidents, or document the software of products with digital elements launched in the EU market. The CRA closes that gap with a horizontal regulation that applies across several industries, placing the primary burden on manufacturers.
The regulation defines a product with digital elements as any software or hardware product, including its remote data processing solutions and any components placed on the market separately. That scope is intentionally broad: it covers everything from consumer IoT devices to enterprise software platforms to container images distributed through registries. Manufacturers must design products securely, handle vulnerabilities throughout the product lifecycle, and provide transparency about software composition.
How the CRA relates to NIS2
The CRA is one part of the broader EU cybersecurity strategy that includes other regulatory frameworks, like NIS2 and DORA. Since the CRA and NIS2 both deal with cybersecurity obligations, they’re easy to conflate, but they target different things. The CRA applies to cybersecurity of products with digital elements, while NIS2 applies to the cybersecurity of essential and important entities.
Recital 12 of CRA even affirms that SaaS, PaaS, or IaaS solutions are subject to NIS2, in principle carving them out of its own scope. However, the line is blurry for products depending on cloud infrastructure.
Would the product lose a core function without it?
Did the manufacturer design, develop, or is control of that remote component under its responsibility?
If the answer to all three is yes, the cloud component is part of the product for CRA purposes. Where that test pulls a cloud component into scope and the component processes personal data, the GDPR applies on top of the CRA rather than in place of it, so you still need to assign controller and processor roles and confirm a lawful basis.
Who the CRA applies to
The CRA assigns obligations based on your role in bringing a product to market.
Role
Obligations
Manufacturers
The heaviest set of obligations.
The manufacturer has assessment obligations before placing the product on the market, in order to ensure compliance with the cybersecurity requirements set out in the CRA.
After this process, the manufacturer can affix the CE marking and attach a declaration of conformity to its products. After placement on the market, the manufacturer is required to handle vulnerabilities in the products throughout their lifetime and to report actively exploited vulnerabilities and severe incidents.
Importers and distributors
Fewer obligations.
Both must ensure that the manufacturer complied with a set of obligations, but also retain documentation and act upon becoming aware of non-conformity of the product with the CRA or a vulnerability.
Open-source software stewards
A new CRA category.
Mainly for micro-enterprises and small and medium-sized enterprises, including start-ups, individuals, non-profit organizations and academic research organizations, that systematically support open-source used in commercial activity.
Scaled-down obligations covering, in particular, putting in place a cybersecurity policy and vulnerability handling, but also cooperation with market surveillance authorities and certain reporting obligations.
Key requirements for the EU CRA
The CRA organizes its requirements into two main areas, both defined in Annex I of the regulation: essential cybersecurity requirements for product properties, and vulnerability handling obligations for the product lifecycle.
Security by design
Products must be designed, developed, and produced to ensure an appropriate level of cybersecurity based on a risk assessment. In practice, this means shipping with secure default configurations, minimizing the attack surface by removing unnecessary components, protecting the confidentiality and integrity of stored and transmitted data, and providing mechanisms for secure updates.
For container images, the security-by-design requirement maps directly to image hardening:
minimal base layers
no unnecessary shells or package managers
secure defaults out of the box.
The essential requirements also include data minimization: a product should process only personal or other data that is adequate, relevant, and limited to what is necessary for its intended purpose.
Vulnerability handling
Manufacturers must maintain processes for identifying, documenting, and remediating vulnerabilities throughout the support period they define for each product. This includes coordinated vulnerability disclosure policies, timely security updates, and public disclosure of fixed vulnerabilities with enough detail for users to assess impact and apply remediation.
Security updates must be provided free of charge for the duration of the support period. Public disclosures should be limited to the technical detail users need and must not expose personal data, such as the identity of a reporter or of affected users, consistent with the CRA’s expectation that disclosures avoid increasing risk and with GDPR limits on publishing personal data.
Transparency and SBOMs
The CRA also requires manufacturers to include a software bill of materials in the technical documentation for every product with digital elements. The SBOM must be in a commonly used, machine-readable format and must include, at minimum, the top-level dependencies of the product. However, the regulation does not mandate a specific format, but in practice that typically means SPDX or CycloneDX. Scope the generated SBOM to package and dependency metadata and keep embedded secrets and personal data out of the artifact.
An important nuance: The CRA does not require manufacturers to publish SBOMs publicly. SBOMs must be included in technical documentation and provided to market surveillance authorities on request. Also, the documentation must be retained for ten years after the product is placed on the market, or for the duration of the support period, whichever is longer.
Incident and vulnerability reporting
Manufacturers must report actively exploited vulnerabilities and severe security incidents to the relevant national Computer Security Incident Response Team (CSIRT) and to ENISA through a single reporting platform. The reporting timelines are:
Reporting timelines: – 24 hours: early warning notification – 72 hours: full notification with technical details – 14 days: final report after a corrective measure is available (for actively exploited vulnerabilities) – 1 month: final report from the 72-hour submission (for severe incidents)
Note for Privacy: These reports can contain personal data, such as a reporter’s identity or affected-user details, so limit each report to the technical information the CSIRT and ENISA actually need and handle any personal data in line with the GDPR. Notifications should also avoid disclosing information that would increase risk to users.
Conformity assessment
Before placing a product on the EU market, manufacturers must complete a conformity assessment to verify compliance with the essential cybersecurity requirements. The type of assessment depends on how the product is classified under the CRA.
Product categories and conformity assessment
The CRA classifies products into three tiers based on their cybersecurity risk, with each tier subject to increasingly rigorous conformity assessment procedures.
If you’re shipping container runtimes, you likely fall into the Important Class II category and will need a third-party assessment. Products that pass their conformity assessment receive the CE marking, which indicates compliance with the CRA and allows them to be sold on the EU market. Products that fail, or that are found to be non-compliant after placement, can be ordered withdrawn or recalled by national market surveillance authorities.
CRA timeline: 3 Deadlines that matter
The CRA entered into force on December 10, 2024, but its obligations phase in over three years. Each milestone introduces a distinct set of requirements.
Date
Milestone
What takes effect
June 11, 2026
Conformity assessment bodies
Member states must designate notifying authorities. Conformity assessment bodies begin formal notification and can start conducting assessments.
September 11, 2026
Reporting obligations
Manufacturers must report actively exploited vulnerabilities and severe security incidents to CSIRTs and ENISA. This retroactively applies to all products already on the EU market, not just new ones.
December 11, 2027
Full enforcement
All essential cybersecurity requirements take effect: security by design, SBOM in technical documentation, vulnerability handling, conformity assessment, CE marking. Non-compliance triggers fines.
The key detail most teams miss: the September 2026 reporting obligation is applicable to products that are already in the market. It retroactively applies to products already on the EU market, not just new releases. If you are selling container images to EU customers today, your 24-hour reporting clock starts in months, not years.
Penalties for non-compliance
Article 64 of the CRA establishes three penalty tiers for non-compliance, with fines set at the member-state level but capped by the regulation:
Up to €15 million or 2.5% of global annual turnover (whichever is higher) for failure to comply with essential cybersecurity requirements and other core obligations (Art. 64 (2))
Up to €10 million or 2% of global annual turnover (whichever is higher) or failure to comply with other CRA obligations (Art. 64 (3))
Up to €5 million or 1% of global annual turnover (whichever is higher) for supplying incorrect, incomplete, or misleading information to authorities (Art. 64 (4))
Beyond fines, market surveillance authorities can order product withdrawals, recalls, or outright bans from the EU market. For organizations selling software products into the EU, losing market access is often a more significant consequence than the fine itself.
Microenterprises and small enterprises are generally exempt from fines for missing the 24-hour early warning deadline on vulnerability and incident reporting. Open-source software stewards are not subject to fines for any CRA infringement.
Open-source software and the CRA
The CRA’s treatment of open source was one of the most debated aspects during the legislative process. The final text draws a clear line based on commercial activity.
Free and open-source software that’s not used in the course of a commercial activity, either directly or through support, is outside the CRA’s scope. Individual developers and volunteer maintainers are not classified as manufacturers under the regulation, as long as they operate outside a commercial activity. And the CRA explicitly does not apply to open-source software supplied for distribution outside the scope of a commercial activity.
However, the regulation introduces a new role: the open-source software steward.
A “steward” is a legal person (a company or foundation, not an individual) that systematically supports the development of open source software intended for commercial activities. The CRA applies a light-touch regime for stewards with limited obligations. They must mainly:
Maintain a cybersecurity policy.
Report actively exploited vulnerabilities.
Cooperate with market surveillance authorities.
Critically, stewards are not subject to financial penalties for CRA infringements.
Organizations that distribute open-source software under a commercial model, whether through paid support or commercial container image registries, are classified as manufacturers, not stewards. The distinction matters because manufacturers carry the full weight of CRA obligations, including conformity assessment and CE marking.
What the CRA means for container teams
Everything above applies to the full universe of digital products. Here’s where it gets specific. Container images and runtimes distributed commercially into the EU qualify as products with digital elements under the CRA. If your organization publishes container images in a registry that EU customers can pull from, and those images are part of a commercial offering, the CRA applies and you may be considered a manufacturer. This is true regardless of where your organization is headquartered.
The practical implications span the entire container lifecycle:
Image composition transparency: Every image needs a machine-readable SBOM that documents at least the top-level dependencies. Image-layer SBOMs generated at build time, which capture OS packages, runtime libraries, and transitive dependencies, go further than the CRA’s minimum.
Vulnerability management: Organizations must have processes to track, remediate, and report vulnerabilities in the components their images contain. Starting September 2026, all vulnerability and incident reporting obligations listed in Article 14 come into effect.
Security by design: Images should ship with minimal attack surfaces, secure default configurations, and no unnecessary components. Hardened base images with shells, package managers, and debug tools removed satisfy this requirement more directly than standard community images.
Provenance and integrity: The CRA’s essential requirements include protecting the integrity of the product and verifying that components have not been tampered with. Cryptographic signatures and provenance attestations address this directly.
Support periods: Manufacturers must define and communicate a support period during which they will handle vulnerabilities. For container images, that means committing to a patch and rebuild cadence for the lifecycle of each supported image tag.
Compliance starts at the image layer
The CRA raises the bar for every organization that ships software into the EU. For container teams, the requirements map directly to practices the industry has been moving toward: hardened images, build-time SBOMs, provenance attestations, vulnerability monitoring, and defined support lifecycles. The difference is that these practices are no longer optional.
Thankfully, Docker Hardened Images ship with the artifacts the CRA demands: complete SBOMs, SLSA Build Level 3 provenance with non-falsifiable attestations, OpenVEX exploitability data, and cryptographic signatures. The images are minimal by default, continuously rebuilt against upstream fixes, and backed by defined support periods. Pair that with continuous vulnerability monitoring against SBOM data limited to package and component metadata and excluding personal data and embedded secrets, and the CRA’s 24-hour reporting clock starts with a known blast radius rather than a manual triage.
Explore vulnerability monitoring with Docker Scout →
Frequently asked questions
Does the CRA apply to container images?
Yes, generally. Container images distributed commercially into the EU qualify as products with digital elements under the CRA. This applies whether the images are distributed as part of a software product, sold as managed services, or published in a commercial registry. The regulation applies based on commercial availability in the EU market, not on where the manufacturer is headquartered.
What SBOM format does the CRA require?
The CRA requires a commonly used, machine-readable format but does not name a specific standard. In practice, that usually means SPDX or CycloneDX. For container workflows, SPDX is the format BuildKit generates natively as an image attestation. Whichever format you use, scope the SBOM to package and dependency metadata and exclude embedded secrets and personal data from the generated artifact.
Do I have to publish my SBOM publicly?
No. The CRA requires SBOMs to be included in technical documentation and provided to market surveillance authorities upon request. There is no obligation to make them publicly available. However, organizations that do publish SBOMs as attestations attached to their images make it easier for downstream consumers to verify compliance and assess risk. If you do publish, scrub the SBOM and attestations of secrets, internal hostnames, and any personal data first, because a published artifact is difficult to retract.
Are open-source projects exempt?
Open-source software is outside the CRA’s scope as far as they are not made available on the market, and therefore supplied for distribution or use in the course of a commercial activity. Individual volunteer maintainers are not classified as manufacturers as far as they operate outside a commercial activity. However, organizations that distribute open-source software commercially (through paid support, managed services, or commercial registries) may be classified as manufacturers and subject to the full set of CRA obligations.
When do the CRA’s SBOM requirements take effect?
The SBOM requirement is part of the essential cybersecurity requirements in Annex I, which take full effect on December 11, 2027. However, the vulnerability reporting obligations that begin on September 11, 2026 are operationally much harder to meet without SBOM data, so the practical imperative to have SBOMs in place arrives well before the formal deadline.
Source
Omdia, Securing the Software Supply Chain: Strategic Approaches to Support Scaling Development with AI Adoption, May 2026.
An unknown threat actor exploited a recently disclosed high-severity security flaw impacting Cisco Catalyst SD-WAN as a zero-day at least two months before it was publicly disclosed, according to new findings from Google-owned Mandiant.
The vulnerability, tracked as CVE-2026-20245 (CVSS score: 7.8), allows an authenticated, local attacker to execute arbitrary commands with elevated privileges by supplying a crafted file to the affected system by taking advantage of the device's insufficient validation of user-supplied input.
Earlier this month, Cisco acknowledged that it became aware of exploitation of this vulnerability, adding that a malicious actor must have netadmin privileges on an affected system to pull off a successful attack.
"Throughout the intrusion, to maintain operational security and avoid detection, the threat actor consistently employed anti-forensic techniques, selectively deleting and restoring system configuration files that were modified during their activities," Mandiant researchers Chester Sng, Pete Boonyakarn, and Logeswaran Nadarajan said.
The incident, the tech giant's incident response and threat intelligence arm added, targeted an unspecified communications service provider to elevate a compromised admin account to full root-level access.
Two distinct periods of unauthorized activity have been detected, one taking place between late 2025 and January 2026 and the other in March 2026. At this stage, it's unclear if these two events are connected and the work of the same threat actor.
During the first wave, the victim is said to have experienced unauthorized peering connections that likely exploited one of two authentication bypass flaws in Cisco Catalyst SD-WAN controllers (CVE-2026-20127 or CVE-2026-20182). It's worth noting that both the security vulnerabilities were undisclosed zero-days at that point.
Then in March 2026, a second wave of rogue peering connections targeted a device running a newer software version that was patched against CVE-2026-20127. Cisco has since confirmed that these connections did not leverage CVE-2026-20182, raising the possibility that the attacker, who may or may not have been behind the previous unauthorized peering connections, relied on stolen certificates from a prior breach of the same device to obtain initial access.
"The attacker then changed default admin credentials before exploiting CVE-2026-20245 as a zero-day via a malicious CSV file upload (evil_tenant.csv)," Mandiant said. "This exploit allowed them to escalate privileges and create a rogue user account (named 'troot') with full root-level shell control."
The attackers have also been found to consistently cover their tracks by deleting files created by them, reversing configuration changes, and running scripts to ensure that no evidence was left behind and limit defenders' ability to assess the full extent of the compromise.
"After changing the default admin password and exfiltrating the SD-WAN fabric configuration, the actor changed the password back to its original value so an administrator logging in would not notice anything was off," Austin Larsen, principal threat analyst at Google Threat Intelligence Group (GTIG), said.
"They escalated to root through a malicious CSV upload, created a hidden "troot" account in /etc/passwd and /etc/shadow, then deleted every file they touched and ran a validation script to confirm their indicators were gone."
Google pointed out that the activity once again highlights the "continuing trend" of bad actors weaponizing zero-days in edge devices like SD-WAN, as they lack the telemetry needed for deep forensic analysis, and a foothold in those systems can facilitate persistent visibility into internal traffic across the fabric.
"Advanced adversaries continue to primarily target and exploit network devices and other systems that don't natively support EDR solutions," Charles Carmakal, chief technology officer of Mandiant Consulting, said in a post on LinkedIn.
from The Hacker News https://ift.tt/tvZG93J
via IFTTT
SUMMARY: What does a Forward-Deployed Engineer actually do? And what about deploying AI Harness? Let’s dig into the real-world with these evolving AI concepts and technologies.
Topic 1 - Welcome to the show, tell us a bit about your background and what you focus on these days.
Topic 2 - Let’s talk about the role of Forward Deployed Engineer, it’s being talked about a lot, but you’re living in that world now. What problems are FDEs usually tasked with trying to solve, or new things to implement?
Topic 3 - We’ve seen other roles (DevOps, PlatformEng, etc.) that evolved from other roles or skills. What type of background lends itself to success in FDE? What skills are needed going forward?
Topic 4 - You’re also working on some AI harness implementations. What can you tell us about those challenges and the technologies behind the harness?
Topic 5 - At what point does an AI harness make sense for a company? What types of AI challenges typically require those next steps?
Topic 6 - Working in the middle of this evolving AI space, what are some perspectives you’ve gained over the last 6-12 months? What do you wish you knew ahead of time?
Cloud security is shifting from visibility to context-aware risk reduction, helping security teams understand which exposures matter most, prioritize what can be exploited, and reduce risk across the application lifecycle. As organizations continue to expand across multicloud environments, Kubernetes, APIs, and AI-powered workloads, security teams are overwhelmed with signals. The challenge is no longer identifying individual risks, but determining which combinations of vulnerabilities, identities, and data exposures are most critical to address at the source.
Frost & Sullivan’s 2026 Frost Radar™ for Cloud-Native Application Protection Platforms (CNAPP) reflects this shift. The report highlights how CNAPP is evolving from a collection of posture and workload capabilities into a unified cloud risk operations platform—one that correlates signals across code, cloud, runtime, and SOC workflows to prioritize and reduce risk continuously. Within this evolving market, Microsoft is positioned among leading CNAPP vendors—reflecting alignment with where the category is heading.
The Frost Radar makes a clear point: CNAPP is no longer about visibility or compliance—it is becoming an operational platform for reducing risk.
Modern environments introduce complexity across:
Multicloud and hybrid infrastructure.
Rapid development and continuous deployment.
Containers, serverless, and APIs.
AI-powered workloads.
This complexity exposes the limits of traditional tools.
Organizations now require platforms that can:
Correlate posture, runtime, identity, and data signals.
Prioritize risk based on exploitability—not severity alone.
Integrate security across development and operations.
Support faster investigation and response.
This is the shift: from detecting issues to operationalizing risk reduction across the application lifecycle.
What distinguishes leading CNAPP platforms
Frost evaluates CNAPP providers based on growth and innovation—but more importantly, on how effectively they help organizations manage risk.
According to the report, five themes define the next generation of platforms:
Platform unification over point solutions.
Code-to-cloud-to-SOC integration.
Risk prioritization based on exploitability.
Correlation across identity, data, and application context.
Expansion into AI-powered workloads.
These capabilities represent a shift from fragmented visibility to connected, contextual risk management.
How Microsoft aligns with CNAPP’s next phase
1. Correlating risk across identity, endpoints, data, and cloud
Most security tools surface findings. Fewer connect them meaningfully. Modern attacks exploit the combination of misconfigurations, excessive permissions, and data exposure—not isolated issues. Microsoft Defender for Cloud correlates posture findings with identity, data, and runtime signals—helping surface risks that are exploitable. A misconfigured storage resource on its own may not appear critical. But when combined with excessive access permissions and the presence of sensitive data, it can create a clear attack path.
What this means: Security teams can prioritize real attack paths instead of individual findings, reducing alert fatigue and improving remediation speed and precision.
2. Extending security from code to cloud to SOC
Security must operate continuously across development, runtime, and operations.
Defender for Cloud connects:
Code and infrastructure-as-code scanning.
Cloud posture and runtime protection.
Security operations and response workflows.
A vulnerability identified in infrastructure-as-code before deployment can be tracked through to runtime—where it is validated against real-world behavior and surfaced in security operations if actively exploitable.
What this means: Organizations move from fragmented workflows to continuous risk validation and response across the lifecycle.
3. Reducing complexity across fragmented security workflows
As environments scale, tool sprawl limits visibility and slows response. Microsoft delivers CNAPP capabilities as part of a connected platform—integrating posture management, workload protection, identity, data, and threat detection across multicloud environments. Instead of switching between separate tools, security teams can investigate a single incident across initial misconfiguration, runtime impact, and identity exposure, enabling a more connected experience.
What this means: Security teams can investigate faster, prioritize risk more consistently, and reduce exposure across fragmented cloud environments.
Where security leaders focus next
The Frost Radar offers a signal for where cloud security is headed: toward platforms that connect context across cloud environments so teams can prioritize the risks most likely to be exploited and reduce exposure faster.
Security leaders should now ask:
Can the platform correlate signals across identity, end points, data, cloud, and runtime?
Does it span the full code-to-cloud lifecycle?
Can it prioritize risk based on exploitability—not just severity?
Does it integrate with SOC workflows for faster response?
Can it scale across multicloud and AI environments?
These are the capabilities that define the next generation of CNAPP.
Bottom line
Frost & Sullivan’s 2026 CNAPP analysis reinforces a clear shift: Cloud security is moving from fragmented visibility to unified, contextual risk management across the entire lifecycle. Microsoft’s position in the Frost Radar reflects this shift—bringing together posture, runtime, identity, end points, and data signals into a connected platform that helps organizations prioritize and reduce risk continuously.
Explore Microsoft cloud security solutions to see how unified posture management, risk prioritization, and protection across the application lifecycle can help reduce cloud risk.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Microsoft Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Tuesday warned of active exploitation of a critical security flaw impacting Lantronix EDS5000 Series devices, urging Federal Civilian Executive Branch (FCEB) agencies to apply the fixes by June 26, 2026.
The vulnerability in question is CVE-2025-67038 (CVSS score: 9.8), a code injection flaw that could result in the execution of arbitrary commands with elevated privileges.
"The HTTP RPC module executes a shell command to write logs when the user's authentication fails," according to the vulnerability's description on CVE.org. "The username is directly concatenated with the command without any sanitization. This allows attackers to inject arbitrary OS commands into the username parameter. Injected commands are executed with root privileges."
The security flaw was disclosed by Forescout Research Vedere Labs in April 2026 as part of a broader set of vulnerabilities collectively codenamed BRIDGE:BREAK that impacted serial-to-IP converters from Lantronix and Silex. There are currently no details on how the vulnerability is being exploited, or who is making the effort.
The disclosure comes as CISA also confirmed active exploitation of three maximum-severity security defects in Ubiquity UniFi OS, days after Defused Cyber said it detected in-the-wild abuse of the remote code execution chain comprising CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910 to deploy commodity malware.
CVE-2026-34908 - An improper input validation vulnerability that could allow a malicious actor with access to the network to conduct command injection
CVE-2026-34909 - A path traversal vulnerability that could allow a malicious actor with access to the network to access files on the underlying system that could be manipulated to access an underlying account.
CVE-2026-34910 - An improper access control vulnerability that could allow a malicious actor with access to the network to make unauthorized changes to the system.
Earlier this month, Bishop Fox detailed a proof-of-concept (PoC) that chains together the three shortcomings to obtain a reverse shell with full root privileges in a single request. Patches for the flaws were released by Ubiquiti late last month.
"The vulnerabilities could allow remote attackers to make unauthorized system changes, access sensitive files, disclose information, or execute arbitrary commands on vulnerable systems, highly impacting the confidentiality, integrity, and availability of targeted devices," Belgium's Centre for Cybersecurity said.
"Given that UniFi OS devices are often centrally integrated into networks, successful compromise could enable lateral movement and broader network compromise."
from The Hacker News https://ift.tt/kN2SYWI
via IFTTT
A coordinated law enforcement operation, in partnership with private sector companies, including Bitdefender, Bitsight, ESET, and Microsoft, has resulted in the takedown of criminal infrastructure powering Amadey and StealC.
"The main common goal was to disrupt the 'assembly lines' cybercriminals use to launch ransomware, financial fraud, and attacks on critical infrastructure," Europol said in a statement.
The development comes days after authorities from the Netherlands, Canada, Germany, and the U.S. disrupted malicious infrastructure associated with SocGholish and cleaned up nearly 15,000 infected WordPress websites.
As part of the two-week-long action, cryptocurrency assets of criminal origin valued at more than $47 million have been identified, flagged, and restricted from use. In addition, as many as 27 million stolen login credentials have been recovered, and the malware distribution network has been hindered by dismantling 326 servers and 142 domains.
"This takedown is a powerful demonstration of what public and private sector collaboration can achieve in dismantling the infrastructure that enables cybercrime at scale," Alex Cosoi, chief security strategist at Bitdefender, said in a statement. "It also sends a clear message to those behind malware ecosystems: no matter how sophisticated the tools or how distributed the network, coordinated international action will find them."
All three malware families are known to be advertised under a malware-as-a-service (MaaS) model, allowing customers to deliver additional payloads or steal sensitive information from compromised hosts.
SocGholish and Amadey function as loaders for introducing next-stage malware, with the malware primarily disseminated using compromised WordPress sites and phishing campaigns, respectively. Amadey has also been propagated via other loaders like Emmenhtal and SmokeLoader.
A C++-based modular backdoor, it's known to be active since October 2018 and advertised by a threat actor known as InCrease. The service is priced at $600 for a single license, with an extra $50 charged per rebuild. The latest version of Amadey is 5.87. Some of the supported commands are listed below -
Fingerprint the machine
Downloads files, DLLs, MSI, or PowerShell scripts
Run commands using "cmd.exe"
Take screenshots
Spawn a SOCKS proxy
Open a VNC or reverse proxy session
Capture clipboard contents and credentials
Enable RDP
According to data published by Mitsui Bussan Secure Directions, the daily number of active Amadey command-and-control (C2 or C&C) servers ranged roughly between two and 18 until around September 2022.
"From January 2023 to early December 2023, however, this figure rose to between 5 and 30, suggesting that Amadey had come into widespread use," the Japanese cybersecurity company said. "In 2024, after a brief dormant period, the daily count gradually declined from a peak of 17 and has continued to fall to the present day."
The number of malware samples distributed via Amadey is said to have scaled a high of 11,635 in 2025, up from 66 in 2019, 260 in 2020, 1,231 in 2021, 3,500 in 2022, 8,360 in 2023, and 7,619 in 2024. Since the start of the year, 1,837 payloads have been distributed through the malware loader.
Daily trend in the number of active Amadey C2 servers
StealC, on the other hand, has leveraged various initial access vectors ranging from malware loaders (including Amadey) and ClickFix lures, and is equipped to extract sensitive information, such as screenshots, credentials, session cookies, autofill entries, credit card data, browsing history, and extension data.
The malware first surfaced in the wild in January 2023 and sold for $300 per month (or $1,000 for six months) by a threat actor using the moniker "plymouth." Like Amadey, StealC has been actively maintained by its operators. As of June 2026, the latest version of the stealer is 2.2.1. The highest infection concentrations have been reported in the U.S., Poland, and Italy.
Besides targeting Chromium browsers, the malware harvests data from desktop applications like Discord, FileZilla, Foxmail, Microsoft Outlook, Steam, and Telegram, as well as files matching certain naming patterns. It also acts as a secondary loader, capable of downloading and executing EXE, MSI, or PowerShell payloads based on commands from an external server.
Written in C++, a notable aspect of the stealer is its ability to query the system's default language and terminate itself if the locale matches countries like Russia, Ukraine, Belarus, Kazakhstan, or Uzbekistan. Amadey also features a similar check to skip certain functionalities like credential stealing and clipboard stealing when running on a Russian, Ukrainian, or Belarusian host.
A representative infostealer to ransomware attack chain
Earlier this January, CyberArk disclosed a cross-site scripting (XSS) vulnerability in the web-based control panel by the StealC operators that made it possible to glean insights into the MaaS operation, including one of its customers named YouTubeTA, who has relied on Google's video sharing platform to distribute the stealer by advertising cracked versions of Adobe Photoshop and Adobe After Effects.
IBM X-Force and Proofpoint also noted that multiple security flaws were identified in the C2 panel, one of which was a directory traversal bug that made it possible to upload a web shell to the StealC C2 server. The issue was patched by StealC developers in February 2026, but not before it was likely exploited by an affiliate to steal data from other affiliates.
"In both ecosystems, affiliates receive a self-hosted administration panel that must be deployed on their own server infrastructure," ESET researchers Jakub Tomanek and Tomáš Procházka said. "Amadey used a pay-per-rebuild model. Affiliates purchased a license and then paid an additional fee each time they needed to generate a new build, for example, when rotating to a new C&C server."
"StealC took a more affiliate-friendly approach, offering unlimited build generation as part of its subscription. This lowered the operational cost of rotating C&C infrastructure and made it easier for affiliates to generate new samples as needed."
A total of 53 unique clusters have been inside the Amadey ecosystem, with the largest botnet cluster distributing payloads like Lumma Stealer, Vidar Stealer, StealC, Rugmi, PureCrypter, Agent Tesla, Rhadmanthys Stealer, RedLine Stealer, SmokeLoader, XWorm, and AsyncRAT.
Microsoft has revealed that not only do Amadey and StealC employ the same infrastructure, but the malware families have been linked to more than 140,000 infected computers globally in the first two weeks of May 2026. The tech giant said it has identified over 18,000 victim computers and severed criminal control of those devices.
In all, the tech giant said it flagged 200 malicious Amadey and StealC C2 domains and IP addresses, all of which have since been shut down using a combination of court orders, domain seizures, registrations, and provider notifications.
Malware dropped by Amadey in 2025 and 2026 and StealC in 2026
"Loaders and stealers are the two halves of the commodity malware pipeline," Bitsight said. "A loader gets the first foothold and rents it out; a stealer leverages that foothold to collect credentials, cookies, and wallets, to then be sold on underground forums (including Telegram)."
The latest effort, which took place between June 15 and 19, 2026, marks the latest chapter of Operation Endgame. It involved judicial authorities and law enforcement from Belgium, Canada, Denmark, France, Germany, the Netherlands, the U.K., and the U.S.
"Operation Endgame targets the initial access malware used to infect devices," Eurojust said. "Cybercriminals use this malware as a gateway to silently infiltrate victims' systems and steal sensitive data. By fighting the initial stage of the attack chain, the operation strikes at the heart of the entire 'cybercrime-as-a-service' ecosystem."
from The Hacker News https://ift.tt/VWGcCIb
via IFTTT
HCP Vault Dedicated is a fully managed secrets management solution that organizations rely on for authentication, dynamic secrets, and encryption workflows. As a core piece of security infrastructure, the cost of downtime is too high to leave recovery to chance. HCP Vault Dedicated already supports regional disaster recovery (DR) to protect against large-scale infrastructure outages, but cluster-specific incidents require a different kind of readiness.
Today, we’re introducing cluster disaster recovery (cluster DR) in public preview, available as a support-enabled feature for HCP Vault Dedicated customers. This capability adds a critical new layer of resilience by enabling cluster-level failover and DR testing, so teams can rehearse incident response before real outages occur.
Extending recovery beyond regional failures
Regional DR protects against failures like cloud provider outages, regional networking disruptions, and large-scale infrastructure incidents. However, it still assumes that the Vault cluster remains healthy. Cluster DR complements that model by focusing on cluster-level continuity and operational recovery drills. This lets teams intentionally test failover behavior for Vault-cluster-specific scenarios and verify runbooks, recovery coordination, and service continuity under controlled conditions.
Cluster DR enables operational resilience
Cluster DR allows teams to fail over an individual Vault cluster even when the primary region remains available. During the public preview, the feature is available for production-tier clusters with DR enabled. Customers can request failover and failback through HashiCorp support. Requests submitted within 16 hours of the incident are routed to the on-call Vault team, which will perform the operation and help validate the recovery workflow.
Support security response workflows
When teams detect a potential compromise, recovery actions often need to happen quickly. Cluster DR enables them to isolate the affected cluster, promote the DR secondary cluster, and restore service continuity in a controlled environment.
This provides a recovery option for cluster-level security events that regional DR alone was not designed to address.
Supporting enterprise hybrid cloud operations
Enterprises that operate across hybrid and multi-cloud environments depend on Vault as a critical control plane for security and application delivery. Vault enables authentication, issues dynamic secrets, and powers encryption services across modern application environments.
When Vault is unavailable, teams don’t just lose access to secrets — they risk halting deployments, breaking service connectivity, and disrupting production workloads.
Cluster DR helps enterprises:
Maintain continuous access to secrets and authentication services
Reduce operational risk during upgrades and configuration changes
Minimize downtime across distributed environments
Strengthen resilience across complex hybrid and multi-cloud systems
In complex hybrid environments, teams must design for both infrastructure-level and service-level failures. Cluster DR ensures they can handle both.
Combining cluster DR with regional DR
Teams achieve the strongest resilience by combining both recovery strategies. Regional DR protects where Vault runs. Cluster DR protects how Vault operates.
Together, these approaches ensure that teams can respond effectively to infrastructure outages and application-level failures without compromising availability.
Prepare for a broader range of failure scenarios
As enterprises scale their use of Vault, they must address the reality that most disruptions originate from software, operational, or security issues, not full regional outages.
Cluster DR empowers teams to respond to these challenges directly, giving them confidence that their secrets platform can withstand failures in both infrastructure and application layers.
Get started with the public preview
Cluster DR is now offered as a public preview feature for HCP Vault Dedicated customers. To ensure a smooth rollout and gather meaningful feedback, we’re making it available as a support-enabled feature.
To request a failover test, submit a support ticket with:
· Cluster details (name, organization ID)
· Failover window (within 16 hours)
The Vault team will support the failover and failback process.
This collaborative rollout ensures teams can adopt cluster DR with confidence while helping us refine the experience.
To join the public preview, contact the support team and start strengthening your HCP Vault Dedicated resilience strategy today.
from HashiCorp Blog https://ift.tt/HsRAIjr
via IFTTT
A few weeks ago, we announced native support for AI agents in HashiCorp Vault through an early access program. We’re now making these capabilities available to all Vault Enterprise customers in public preview.
As organizations deploy AI agents, one of the biggest challenges is controlling what those agents are authorized to do. Traditional identity-based permissions often grant broad access that persists beyond a single task, increasing the risk of over-authorization.
This public preview introduces a secure-by-default approach to agent authorization that evaluates access for each request, helping organizations enforce least privilege for AI agents at scale. It also makes these capabilities easier to operationalize with improved configuration workflows and broader ecosystem support.
Enforcing authorization details by default: establishing a secure baseline
In earlier work, we introduced ephemeral, per-request authorization to tightly scope what agents can do.This public preview builds on that foundation by making the `authorization_details`claim (a part of the OAuth 2.0 Rich Authorization Requests specification) required by default for OAuth-based authentication.
Rich Authorization Requests are a new standard for this kind of per-request permission constrained workflow. They are defined in RFC 9396 and are part of the IETF's OAuth 2.0 specification. They enable authorization to be expressed as structured, fine-grained data within the token itself. The `authorization_details` claim carries this information, allowing access to be scoped to specific actions or resources for each request rather than relying on broad, identity-based permissions.
By requiring `authorization_details` by default, Vault establishes a secure baseline for agent-based workflows. Requests without these fine-grained authorization details are rejected unless configured otherwise. This ensures that authorization is evaluated in the context of each request, significantly reducing the risk of over-authorization.
As a result, customers can:
· Enforce fine-grained, per-request authorization
· Reduce reliance on broad, long-lived permissions
· Establish clear, auditable authorization scope for each agent action
Customers can configure behavior on a per–OAuth resource server or per–agent registration basis, balancing secure-by-default behavior with the flexibility needed to integrate with their current environments.
Managing agent identity and OAuth resource server configuration with the Terraform Vault Provider
Establishing a secure, request-scoped authorization model is only part of the challenge. Organizations also need a consistent way to configure and manage these controls at scale.
This public preview introduces new functionality in the Terraform Vault Provider, enabling teams to manage Vault’s agentic capabilities as code.
Customers can now define and manage both agent identity and OAuth resource server configuration using infrastructure as code. These capabilities are exposed through two new resources:
· vault_agent_registration
· vault_oauth_resource_server_config_profile
Together, they enable a consistent model for defining how agents are registered, how requests are validated, and what access is allowed.
Manage Agent Registry records with Terraform
The vault_agent_registration resource allows customers to manage agent identities through the Vault Agent Registry using Terraform.
With this resource, customers can:
· Register agents declaratively
· Associate each agent with a Vault identity entity
· Define ceiling policies to enforce maximum permission limits
· Optionally disable default ceiling policies
· Import existing registrations by display name or ID
· Manage agent registrations consistently across Vault namespaces
This brings agent governance directly into infrastructure-as-code workflows. By defining agent registrations as code, organizations can ensure that every agent is explicitly registered, tied to a verified identity, and consistently governed by clearly defined permission limits.
Manage OAuth resource server configuration profiles with Terraform
The vault_oauth_resource_server_config_profile resource allows customers to define how Vault validates JWTs used during OAuth-based authentication.
With this resource, customers can:
· Define OAuth resource server profiles declaratively
· Configure expected JWT issuer IDs
· Validate JWTs using either JWKS endpoints or static public keys
· Restrict accepted audiences
· Control supported signing algorithms
· Specify which claim Vault uses for identity
· Configure token validation behavior such as JWT type, clock skew, and enablement
· Manage profiles consistently across Vault namespaces
These profiles configure Vault’s OAuth resource server behavior, defining how OAuth 2.0 JWTs are validated and used to authorize requests to Vault for agentic workflows. They ensure that incoming tokens, including any authorization detail claims, meet expected validation criteria before being used in authorization decisions.
Alongside agent registration, this creates a model where requests are validated, mapped to an identity, and authorized within clearly defined constraints, with `authorization_details` enabling authorization to be scoped to each request . This limits access strictly to what is required for that request.
Validated with identity ecosystems
As organizations integrate Vault into existing identity architectures, interoperability is critical.
Vault’s OAuth 2.0 workflows, including those using OAuth 2.0 Rich Authorization Requests, have been validated with identity platforms to support both human-in-the-loop and autonomous agent use cases . This includes validation with IdPs such as IBM Verify, Auth0, and Microsoft Entra.
These integrations demonstrate how Vault can operate within today’s identity ecosystem while enabling more advanced, agent-centric authorization models. Additional tutorials and implementation guidance will be available soon to help customers integrate Vault with their identity systems and adopt these workflows in practice.
Learn more
We are continuing to expand Vault’s agentic security capabilities and welcome direct feedback. To help shape the roadmap, consider joining the Vault Agentic Security Beta Program. Beta features are available to all customers.
from HashiCorp Blog https://ift.tt/rlQw8Ui
via IFTTT
The U.S. Department of Justice (DoJ) on Tuesday announced the seizure of a cloud computing account put to use by subsidiaries of Cambodia-based corporate conglomerate HuiOne Group, as the Treasury unveiled fresh sanctions against nine individuals and 26 entities linked to Prince Group.
"These subsidiaries are alleged to have assisted individuals and organizations in transferring proceeds of cryptocurrency investment frauds, cyber scams, and other criminal activities on cryptocurrency blockchains and allowing for the conversion of the proceeds of these schemes to the legitimate banking sector undetected," the DoJ said.
The seized account, the Justice Department added, hosted backend infrastructure for the subsidiaries, including HuiOne Guarantee (aka Haowang Guarantee), which operated an illicit Telegram-based marketplace that engaged in transactions with billions of dollars between 2021 and 2025 by peddling a wide range of crimeware tools.
These included personal and financial data, money laundering services, web development services for setting up fraudulent investment platforms and phishing websites, the procurement of individuals for human trafficking schemes, as well as software to facilitate face swapping, voice cloning, and deepfake-powered impersonation during video calls with victims.
"Huione Guarantee also provided escrow services for criminals transacting on its platforms to facilitate transactions, including money launderers laundering cryptocurrency," the DoJ said. "In doing so, Huione Guarantee facilitated the movement of considerable funds stolen by Southeast Asian scam centers."
A July 2024 analysis from Elliptic revealed that merchants on HuiOne also marketed tear gas, electric batons, and electronic shackles for use by scam compound operators to imprison and torture their workers. "The merchants refer to 'preventing escapers' and controlling 'runaway dogs,'" the company noted at the time. "Those working within the scam compounds are commonly referred to as 'dogs' or 'dog pushers.'"
"The HuiOne Group used this cloud computing account as part of a technological backbone that allowed billions in fraud proceeds to be transferred, moved, and concealed – much of it stolen through Southeast Asian scam centers," said Assistant Attorney General A. Tysen Duva of the Justice Department's Criminal Division.
"Seizures of these marketplaces is critical in the fight against fraud that affects so many Americans, and to stop avenues for criminal proceeds to be laundered."
Although HuiOne announced it was ceasing operations in May 2025, a new analysis from Flare has revealed that more than 30 marketplaces have emerged since to fill up the void left by the guarantee platform, with the operators building proprietary messaging platforms to bypass Telegram's bans.
"The wave of enforcement in 2025 was the first coordinated attempt to reach both the financial and physical layers of the ecosystem at the same scale," Flare researcher Chris d'Eon said. "It has produced visible adaptation, including reshuffled channel branding, redistributed flows across successor markets, and accelerated work on alternative venues. However, it has not meaningfully reduced volume across the ecosystem in aggregate."
In tandem, the U.S. Treasury's Financial Crimes Enforcement Network (FinCEN) has assessed H-Pay Service PLC as a primary money laundering concern to guard against "HuiOne Group's attempts to circumvent being cut off from the U.S. financial system." It's worth noting that FinCEN designated HuiOne Group as a "primary money laundering concern" in May 2025.
"Merchants sold money laundering services, stolen personal data, websites and other goods and services necessary to perpetrate so-called 'pig butchering' scams and other online fraud," Elliptic said in a statement. "By the time HuiOne was forced offline, it had received more than $31 billion in cryptoasset transactions, making it the largest illicit online marketplace ever recorded, more than 25 times larger than Silk Road and AlphaBay combined."
The development also comes as the Treasury levied sanctions against Prince Group's leadership, investors in scam compounds, and front companies, a little over eight months after it was classified as a Transnational Criminal Organization (TCO) for its role in furthering a criminal enterprise built on the foundations of scam compounds, fraud, and money laundering. Prince Group's chairman, Chen Zhi has since been arrested, extradited to China, and stripped of his Cambodian citizenship.
"Transnational criminal organizations based in Southeast Asia, like the Prince Group TCO and with support of their enablers like HuiOne Group, continue to target Americans through large-scale cyber-enabled fraud and scam operations," Treasury said.
from The Hacker News https://ift.tt/dT0oxam
via IFTTT
Threat actors have begun to exploit a recently disclosed critical security flaw impacting Cisco Unified Communications Manager (Unified CM) and Unified Communications Manager Session Management Edition (Unified CM SME).
The vulnerability, tracked as CVE-2026-20230 (CVSS score: 8.6), is a case of improper input validation for specific HTTP requests that could allow an unauthenticated, remote attacker to conduct server-side request forgery (SSRF) attacks through an affected device.
"An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected device," Cisco said in an advisory released earlier this month. "A successful exploit could allow the attacker to write files to the underlying operating system that could be used later to elevate to root."
In a post shared on X earlier this week, Defused Cyber said it observed active exploitation of the vulnerability in attacks. "This is currently being exploited from a single source using an unvetted PoC, with genuinely-formatted file:// file-write payloads landing on our decoys," it noted.
However, for successful exploitation to occur, the WebDialer service must be enabled. It's disabled by default. To check if the WebDialer is enabled, users can complete the following steps -
Log in to the Cisco Unified CM Administration interface
From the Navigation menu, choose Cisco Unified Serviceability and click Go
From the Tools menu, choose Control Center - Feature Services
In the CTI Services section of the page, check whether the current status of the Cisco WebDialer Web Service is Started or Not Running
If the status is Started, WebDialer is enabled
The vulnerability has been patched in Unified CM and Unified CM SME versions 14SU6 and 15SU5. If immediate patching is not an option, it's advised to disable the WebDialer service until a fix can be applied.
SSD Secure Disclosure has since published additional technical specifics of CVE-2026-20230, describing it as a flaw that allows unauthenticated attackers to arbitrarily write files in the server by leveraging the Webdialer component to obtain the true hostname of the target and ultimately achieve code execution.
Cisco has yet to update the advisory to reflect the exploitation status. Last week, the network security company released security updates for a medium-severity security flaw in Catalyst SD-WAN Manager (CVE-2026-20262, CVSS score: 6.5) that has come under active exploitation in the wild.
from The Hacker News https://ift.tt/KF4zQR0
via IFTTT
