The vulnerabilities were disclosed on August 11, 2026, with an update for CVE-2026-62913 published the following day.

Microsoft Exchange Server Security Flaws

The most serious issue is CVE-2026-62913, a remote code execution vulnerability with a CVSS score of 8.8. It is caused by a heap-based buffer overflow.

An attacker with low-level privileges could exploit the flaw remotely without requiring any action from the victim. Successful exploitation could allow the attacker to execute malicious code on an affected Exchange Server.

Another important vulnerability is CVE-2026-62911, an elevation-of-privilege flaw rated Critical by Microsoft, with a CVSS score of 8.0.

The vulnerability is related to an authentication bypass technique. An attacker with low privileges could potentially use it to gain additional permissions, although exploitation requires user interaction.

Because Exchange Server handles corporate email, communications, attachments, and other sensitive information, vulnerabilities in the platform can present a significant risk to organizations.

Affected Vulnerabilities

• CVE-2026-62910 – Elevation of Privilege. An Important-rated resource injection flaw with a CVSS score of 7.2. Exploitation requires high privileges.
• CVE-2026-62911 – Elevation of Privilege. A Critical authentication bypass vulnerability with a CVSS score of 8.0. Low privileges and user interaction are required.
• CVE-2026-62912 – Denial of Service. An Important deserialization vulnerability with a CVSS score of 6.5 that could disrupt Exchange services.
• CVE-2026-62913 – Remote Code Execution. A heap-based buffer overflow with a CVSS score of 8.8 that could allow remote code execution.
• CVE-2026-62914 – Spoofing. An Important cross-site scripting vulnerability with a CVSS score of 7.3.
• CVE-2026-62915 – Security Feature Bypass. An Important authorization flaw with a CVSS score of 6.5 that could allow an attacker to bypass certain access controls.

What Organizations Should Do

Exchange administrators should prioritize these updates, particularly for internet-facing servers.

After applying the patches, teams should verify that updates were successfully installed across all Exchange roles and continue monitoring for unusual authentication, administrative activity, and unexpected server behavior.

Keeping Exchange Server fully patched is especially important because it sits at the center of many organizations’ email and communication infrastructure.

The post Critical Microsoft Exchange Vulnerabilities Discovered appeared first on First Hackers News.

The update was released on August 11, 2026, and security teams have another important reason to move quickly: three of the vulnerabilities were already publicly known or are being actively exploited, according to Microsoft’s advisory information.

For organizations with large Microsoft environments, this is a release that should be reviewed early rather than left for the normal monthly patching cycle.

Three Vulnerabilities Need Immediate Attention

The most important issues this month involve Windows components.

CVE-2026-72971 affects the Windows Container Isolation File System Filter Driver (unionfs.sys). Microsoft rates it as Important and says the vulnerability was publicly disclosed before the security update was released. The issue could allow an attacker to tamper with protected system or container-related data.

Another publicly disclosed issue, CVE-2026-62832, affects the Windows User Profile Service. It is an elevation-of-privilege vulnerability, meaning an attacker with an existing foothold could potentially use it to obtain additional permissions on a vulnerable machine.

The biggest concern is CVE-2026-68820. Microsoft lists this Windows WinSock-related vulnerability as actively exploited in the wild. Because attackers are already using the flaw, organizations should give this update priority and investigate potentially affected endpoints.

Where the 394 Vulnerabilities Fall

The vulnerabilities fixed this month cover several major security categories:

The numbers show that privilege escalation and remote code execution continue to make up a significant portion of Microsoft’s monthly security workload.

For defenders, this means patching should not focus only on vulnerabilities carrying a Critical rating. An Important vulnerability can still become dangerous when it is combined with another weakness or used after an attacker gains initial access.

SharePoint Remains a Key Target

Several SharePoint Server vulnerabilities are included in the August release.

Among them are CVE-2026-70355, CVE-2026-70326, and CVE-2026-70324, which involve privilege escalation, as well as CVE-2026-70321, a remote code execution vulnerability.

SharePoint environments deserve special attention because they often sit close to valuable corporate information. A compromised server could potentially give attackers access to documents, accounts, internal applications, or other parts of an organization’s environment.

Companies running internet-accessible SharePoint servers should therefore make these systems a priority during their patching process.

Azure and Windows Infrastructure Also Affected

The update includes CVE-2026-71331, a Critical remote code execution vulnerability involving Microsoft Azure Attestation and Device Health Attestation services.

Issues affecting cloud and device-trust infrastructure can have broader implications because these services may be part of an organization’s authentication and security architecture.

Windows infrastructure is also covered by several fixes, including vulnerabilities affecting DNS, Windows Management Services, Windows Installer, and other system components.

Organizations should identify which of these services are actually deployed in their environments and prioritize systems that are externally accessible or support critical business operations.

Don’t Forget PowerShell and Developer Machines

Microsoft has also patched vulnerabilities in PowerShell Core and .NET.

One PowerShell issue, CVE-2026-70337, could lead to remote code execution, while CVE-2026-70338 involves a security feature bypass.

This is particularly relevant to security teams because PowerShell is both an essential administration tool and a common technique used during attacks. Keeping the platform patched should go hand in hand with monitoring suspicious PowerShell activity.

Developer environments should also be included in patching plans. Vulnerabilities affecting Visual Studio Code and GitHub Copilot could create additional risk when compromised developer machines have access to source repositories, cloud credentials, or CI/CD infrastructure.

A developer endpoint is not just another workstation. In many organizations, it can provide a pathway into systems that are critical to software development and production deployment.

Microsoft Office Is Part of the Release

Office applications receive their share of security fixes as well.

The August updates cover Outlook, Word, Excel, PowerPoint, and Microsoft Office, including remote code execution and information-disclosure vulnerabilities.

These issues deserve attention because attackers frequently use Office documents and email as an entry point for phishing and malware campaigns. A vulnerability that appears less urgent in isolation can become much more serious when combined with social engineering.

What Security Teams Should Do Now

The size of this month’s release can make patching 394 vulnerabilities seem overwhelming. The practical approach is to prioritize based on exposure and exploitability.

Start with the vulnerabilities that are actively exploited or publicly disclosed. Next, focus on Critical vulnerabilities and systems exposed to the internet, particularly SharePoint and important Azure or Windows infrastructure.

After that, review developer workstations, PowerShell installations, Office applications, and other Microsoft products used across the organization.

Teams should also use this update as an opportunity to check whether vulnerable systems are being properly identified through asset inventories and vulnerability-management tools.

The key takeaway from Microsoft’s August 2026 release is simple: don’t treat Patch Tuesday as just another routine update cycle. With 394 vulnerabilities addressed and an actively exploited Windows flaw among them, organizations should move quickly to identify their exposure and deploy the appropriate security fixes.

The post 394 Microsoft Flaws Patched in August Update appeared first on First Hackers News.

The vulnerability allows remote attackers to execute commands on vulnerable devices without requiring authentication. Since LoadMaster appliances are commonly deployed at the network edge to manage application traffic, a successful attack could provide threat actors with an entry point into an organization’s infrastructure.

What Is the Vulnerability?

CVE-2026-8037 is a command injection vulnerability affecting the API component of Progress LoadMaster and related Application Delivery Controller (ADC) products.

The flaw occurs because certain user-supplied input is not properly validated before being processed by the operating system. As a result, attackers can craft malicious requests that force the appliance to execute unauthorized system commands.

Most importantly, the attack does not require valid login credentials, making internet-facing devices particularly vulnerable.

Why the Risk Is So High

Security researchers have assigned the vulnerability a CVSS score of 9.6, reflecting its critical severity.

Because LoadMaster appliances often sit at the perimeter of enterprise networks, compromising one could allow attackers to:

• Execute remote commands.
• Gain an initial foothold inside the network.
• Steal credentials.
• Move laterally to other systems.
• Deploy additional malware or backdoors.
• Modify device configurations.

Public proof-of-concept (PoC) exploit code is also available, making it easier for attackers to scan for and target vulnerable systems.

Active Exploitation Confirmed

According to CISA, the vulnerability is no longer a theoretical threat.

Evidence of active exploitation prompted the agency to add CVE-2026-8037 to its KEV catalog and advise affected organizations to apply vendor updates immediately.

Although there are currently no reports linking the flaw to ransomware campaigns, attackers are actively attempting to exploit vulnerable devices exposed to the internet.

Recommended Security Measures

Organizations using Progress LoadMaster should act immediately by:

• Identifying all affected LoadMaster appliances.
• Applying the latest security updates provided by Progress.
• Restricting management and API access to trusted networks or VPNs.
• Reviewing logs for unusual API requests and command execution attempts.
• Investigating unexpected configuration changes or unauthorized administrative activity.
• Conducting a full security assessment after patching to ensure attackers have not already established persistence.

The inclusion of CVE-2026-8037 in CISA’s Known Exploited Vulnerabilities catalog underscores the seriousness of this security issue. Since the vulnerability can be exploited without authentication and public exploit code is already available, organizations should prioritize patching affected LoadMaster systems and closely monitor their environments for signs of compromise.

Taking prompt action can significantly reduce the risk of attackers gaining access to critical network infrastructure.

The post CISA Warns of Active LoadMaster Attacks appeared first on First Hackers News.

According to security researchers at AISLE, the flaw could have allowed attackers to compromise a developer’s system simply by convincing them to click a malicious link embedded in a Git commit message.

The issue has now been fixed across all affected platforms, but it highlights the growing security risks facing modern AI-powered development tools.

How the Attack Worked

The vulnerability relied on a malicious link hidden inside a Git commit message.

If a developer clicked the link while viewing the commit inside one of the affected editors, arbitrary code could run automatically with the same permissions as the developer.

The attack required only a single click and did not display any warning, confirmation message, or security prompt, making the compromise difficult to notice.

What Attackers Could Do

Successful exploitation could have given attackers extensive control over a developer’s machine.

Potential impacts included:

• Stealing API keys and other sensitive credentials.
• Installing malware or keyloggers.
• Accessing, modifying, or deleting local files.
• Maintaining persistent access even after the editor was closed.

Because the malicious activity could remain hidden, developers might not realize their systems had been compromised.

Vulnerability Found Across Multiple Editors

AISLE first discovered the flaw in Microsoft VS Code during security testing in late 2025.

Since Cursor is built on the VS Code codebase, it inherited the same vulnerability. Later, researchers identified the identical issue in Google Antigravity, another AI-assisted coding environment based on the same architecture.

The discovery shows how a single vulnerability in a shared codebase can spread across multiple developer tools used by millions of people.

Vendors Released Security Fixes

After receiving responsible disclosure reports, all three vendors addressed the issue.

• Cursor released a security update shortly after notification.
• Google patched the vulnerability in Antigravity within days.
• Microsoft later released a fix for VS Code.

Current versions of all three editors are no longer affected.

Why This Matters

Many modern AI coding tools are developed using common open-source foundations such as VS Code. While this speeds up development and feature delivery, it also means a single security flaw can impact multiple products simultaneously.

This incident demonstrates the importance of continuous security testing and timely patch management, particularly for AI-powered development environments.

What Developers Should Do

Developers and organizations should take the following steps:

• Update VS Code, Cursor, or Google Antigravity to the latest version.
• Review recent Git activity for anything suspicious.
• Rotate API keys and credentials if older vulnerable versions were used.
• Monitor developer systems for unusual behavior or unauthorized access.

Keeping development tools fully updated and regularly reviewing credentials can help reduce the risk of future software supply chain attacks.

The post Critical Vulnerability Disclosed in VS Code, Cursor, and Google Antigravity appeared first on First Hackers News.

Under the new policy, API keys created on or after August 17, 2026, will have a maximum lifetime of 30 days. Developers will no longer be able to create API keys that remain valid for 365 days. In addition, all API keys generated before August 17, 2026, will automatically expire on November 1, 2026.

The move is part of Microsoft’s broader effort to strengthen package security and encourage developers to adopt more secure authentication methods.

Why Is Microsoft Reducing API Key Lifetimes?

NuGet API keys are used by developers to publish packages to NuGet.org. These keys often function like passwords and are commonly stored in CI/CD pipelines, build servers, repository secrets, deployment environments, and other automation platforms.

Although this makes automated package publishing easier, it also creates an attractive target for cybercriminals. If attackers gain access to a long-lived API key, they could publish malicious packages under the name of a trusted project without immediately being detected.

By limiting API keys to just 30 days, Microsoft aims to significantly reduce the period during which a stolen credential can be exploited.

The Growing Risk of Supply Chain Attacks

Software supply chain attacks continue to rise as attackers increasingly target trusted software repositories instead of individual users.

Rather than directly attacking organizations, threat actors compromise developer credentials or package publishing accounts to insert malicious code into legitimate software packages. Once published, these compromised packages may be downloaded by thousands of developers and organizations, allowing malware to spread rapidly across multiple environments.

Microsoft explained that reducing the lifespan of publishing credentials is an important step toward minimizing this risk.

Recent Incidents Highlight the Threat

Microsoft referenced recent software package compromise incidents that demonstrate the dangers of stolen publishing credentials.

One notable example involved the NX Console package in the npm ecosystem. Attackers reportedly obtained valid publishing credentials and used them to release a malicious version of the package.

The compromised package was activated approximately 6,000 times within just 36 minutes before it was removed. This incident showed how quickly attackers can exploit trusted software repositories when publishing credentials fall into the wrong hands.

Events like these continue to reinforce the need for stronger authentication and shorter-lived credentials across software ecosystems.

Shorter API Keys Improve Security—but Don’t Eliminate the Risk

While reducing API key validity lowers the window of opportunity for attackers, Microsoft emphasized that shorter expiration periods alone cannot completely prevent credential theft.

API keys can still be exposed through several common scenarios, including:

• Source code repositories
• CI/CD pipeline logs
• Insecure secret storage
• Build servers
• Compromised developer workstations
• Accidentally shared configuration files

If an attacker obtains an active API key, they may still be able to publish malicious packages before the credential expires.

For this reason, Microsoft is encouraging developers to move beyond traditional API keys altogether.

Microsoft Recommends NuGet Trusted Publishing

To provide a more secure publishing process, Microsoft recommends using NuGet Trusted Publishing, which became available in September 2025.

Trusted Publishing replaces long-lived API keys with OpenID Connect (OIDC) authentication, allowing CI/CD platforms to securely verify their identity without permanently storing publishing credentials.

Instead of relying on reusable secrets, supported CI/CD services generate a temporary identity token during the publishing workflow.

NuGet.org validates this token against security policies configured by the package owner before issuing a temporary publishing credential that is valid only for that specific publishing operation.

This approach greatly reduces the chances of stolen credentials being reused by attackers.

How Trusted Publishing Works

The Trusted Publishing workflow is designed to eliminate long-lived secrets from automated publishing environments.

The process works as follows:

1. A supported CI/CD platform generates a short-lived OIDC identity token.
2. NuGet.org verifies the identity of the workflow.
3. Repository, workflow, and optional environment details are validated against the package owner’s security policy.
4. NuGet.org issues a temporary API key for that publishing session.
5. Once the publishing job is complete, the temporary credential expires automatically.

Because no reusable API key is stored in repositories or CI/CD secrets, attackers have far fewer opportunities to steal publishing credentials.

Benefits of Trusted Publishing

Microsoft highlighted several advantages of adopting Trusted Publishing:

• Eliminates long-lived API keys.
• Reduces the risk of credential theft.
• Removes the need to store publishing secrets in repositories.
• Simplifies credential rotation.
• Improves software supply chain security.
• Limits the impact of compromised developer environments.
• Strengthens automated package publishing workflows.

GitHub Actions and GitLab users are encouraged to migrate to Trusted Publishing before the August 2026 deadline.

What Developers Should Do Before the Deadline

Organizations that continue using traditional NuGet API keys should begin preparing now.

Microsoft recommends the following actions:

• Review all NuGet publishing workflows.
• Identify API keys created before August 17, 2026.
• Update automation to support 30-day API key rotation.
• Restrict API keys to the minimum required package scope.
• Apply the least-privilege principle for publishing permissions.
• Avoid storing API keys in source code, configuration files, or logs.
• Immediately revoke any API key that may have been exposed.
• Begin migrating CI/CD pipelines to Trusted Publishing wherever possible.

Taking these steps can help reduce the risk of malicious package publishing while ensuring a smooth transition to the new policy.

Looking Ahead

Microsoft indicated that shortening API key lifetimes is only one phase of its long-term software supply chain security strategy. As support for Trusted Publishing expands across additional CI/CD platforms, the company may further reduce API key validity periods in the future.

Developers and organizations are encouraged to adopt modern authentication methods such as OpenID Connect to strengthen package security, reduce reliance on reusable secrets, and better protect the software supply chain against evolving cyber threats.

The post Microsoft Takes Action to Strengthen NuGet Supply Chain Security appeared first on First Hackers News.

The vulnerability was first identified in Mozilla Firefox, and because Tor Browser is built on Firefox, it inherited the same security flaw until patches were released. Researchers from Nebula Security successfully demonstrated the exploit, highlighting the importance of keeping Tor Browser up to date.

How the Attack Works

The vulnerability exists within Firefox’s SpiderMonkey JavaScript engine, specifically in its Just-In-Time (JIT) compiler. This component improves browser performance by converting JavaScript into machine code while webpages are being loaded.

Researchers discovered that under certain conditions, the JIT compiler incorrectly manages memory during JavaScript optimization. This creates a use-after-free (UAF) vulnerability, allowing attackers to manipulate memory and execute arbitrary code within the browser process.

Unlike many browser attacks that rely on downloading malicious files or tricking users into approving software installations, this attack requires only that a victim visits a malicious webpage. Once the page loads, the exploit can be triggered automatically on vulnerable versions.

Why Tor Browser Users Are at Risk

Tor Browser is designed to protect users’ privacy and anonymity by routing internet traffic through the Tor network. However, browser-level vulnerabilities remain a significant risk because they can compromise the browser before Tor’s privacy protections can fully safeguard the user’s activity.

If attackers successfully exploit the browser, they may be able to:

• Execute malicious code on the victim’s system.
• Steal sensitive browser data.
• Bypass browser security protections.
• Potentially weaken a user’s privacy and anonymity.

This demonstrates that even privacy-focused browsers depend heavily on the security of their underlying browser engine.

Researchers Confirm the Exploit

According to the research, the vulnerability affects the browser’s JavaScript optimization process, where incorrect memory handling creates an opportunity for attackers to reuse invalid memory references. This can provide the building blocks needed to gain greater control over the browser process.

The researchers responsibly disclosed the vulnerability to Mozilla, allowing security updates to be developed and released before detailed technical information became widely available.

Security Updates Are Available

Mozilla addressed the vulnerability in Firefox 151.0.3, while the Tor Project later incorporated the fix into Tor Browser 15.0.19.

Users running the latest Tor Browser release are protected against this specific vulnerability. Anyone using older versions should update immediately to reduce the risk of exploitation.

How to Stay Protected

The best defense against browser-based attacks is to keep software fully updated. Users should always download Tor Browser from the official Tor Project website and install new security updates as soon as they become available.

In addition, organizations and individuals should:

• Keep Tor Browser updated to the latest version.
• Apply Firefox security updates promptly.
• Avoid visiting suspicious or untrusted websites.
• Use endpoint security solutions that can detect suspicious browser activity.
• Monitor systems for unusual processes or unexpected browser behavior.

Conclusion

The discovery of CVE-2026-10702 serves as a reminder that browser vulnerabilities can pose serious risks, even for applications built around privacy and anonymity. While the Tor network provides strong protection against online tracking, it cannot compensate for vulnerabilities within the browser itself. Regular software updates, timely patch management, and safe browsing practices remain essential for protecting both security and privacy against evolving browser-based threats.

The post New Attack Puts Tor Browser Users at Risk appeared first on First Hackers News.

Many Kusto Query Language (KQL) detection rules search only for connections where RemoteIPType is set to “Public”. However, some internet-bound connections are recorded differently, which means they may not appear in search results or trigger alerts. This creates a blind spot that attackers could exploit to hide malicious outbound communications.

Why Does This Happen?

The DeviceNetworkEvents table is one of the most important telemetry sources in Microsoft Defender XDR. It provides detailed information about endpoint network activity, including:

• Processes initiating the connection
• Command-line arguments
• User accounts
• Remote IP addresses
• Ports
• URLs
• Protocol information

Security analysts frequently use this data to investigate suspicious HTTPS traffic, DNS requests, remote management tools, and potential command-and-control (C2) communications.

The issue occurs because of the RemoteIPType field. Modern Windows systems often use dual-stack networking, allowing applications to communicate using both IPv4 and IPv6.

When an IPv4 address is stored as an IPv4-mapped IPv6 address, Microsoft Defender XDR may classify it as FourToSixMapping instead of Public.

For example:

• IPv4 address: 8.8.8.8
• Recorded value: ::ffff:8.8.8.8
• RemoteIPType: FourToSixMapping

If a detection rule only searches for:

| where RemoteIPType == "Public"

the connection to 8.8.8.8 will not appear in the results because it has been classified as FourToSixMapping instead of Public.

This behavior was discovered during a purple-team exercise after a covert external C2 channel failed to trigger the expected alert. The investigation revealed that the detection rule unintentionally ignored IPv4-mapped IPv6 traffic because it only filtered for Public IP types.

Impact on Detection

This classification behavior can create a significant detection gap, particularly in organizations that use dual-stack networking.

Detection rules designed to monitor:

• Command-and-control (C2) traffic
• Suspicious outbound HTTPS connections
• Unusual DNS activity
• Remote access tools
• Proxy-bypass techniques

may fail to detect malicious activity if they rely only on RemoteIPType == “Public”.

Another important consideration is the ipv4_is_private() KQL function. Some analysts use this function to identify private IP addresses, but it does not always work correctly with IPv4-mapped IPv6 values.

For example, when the function receives an address such as:

::ffff:8.8.8.8

it may return null instead of true or false.

Since null is neither true nor false in KQL filtering logic, mapped IPv4 addresses can be silently excluded from search results if the IP address is not normalized first.

To avoid this issue, Microsoft recommends including both Public and FourToSixMapping values in detection queries and normalizing mapped IPv4 addresses before applying additional filters.

A recommended query is shown below:

| where RemoteIPType in ("Public", "FourToSixMapping")
| extend RemoteIP = iff(
    RemoteIPType == "FourToSixMapping",
    replace_string(RemoteIP, "::ffff:", ""),
    RemoteIP
)

After normalizing the IP address, analysts can consistently filter private RFC 1918 addresses, loopback addresses, and other non-internet destinations without accidentally excluding legitimate outbound traffic.

Security teams should review existing Microsoft Defender XDR and Microsoft Sentinel detection rules that rely on RemoteIPType == “Public”. Rules designed to detect C2 activity, suspicious outbound HTTPS traffic, unusual DNS requests, remote management tools, and proxy-bypass techniques should be updated to account for both Public and FourToSixMapping values.

By making these changes, organizations can improve detection coverage, reduce false negatives, and ensure that outbound communications are monitored more accurately across both IPv4 and IPv6 environments.

The post Microsoft Defender XDR C2 Detection Gap appeared first on First Hackers News.

The change applies to all Copilot users, including both free and paid subscribers. Since Microsoft does not provide an option to export or download these podcasts, all existing podcast content and shared links will be permanently removed after the feature is discontinued.

Microsoft Ends the Copilot Podcasts Feature

Copilot Podcasts allowed users to turn prompts and documents into AI-generated podcast-style audio. However, the podcasts were stored only inside the Copilot app and could not be downloaded or moved to another platform.

Microsoft confirmed that once the feature is retired, previously created podcasts and any shared links pointing to them will stop working. The company thanked users for their feedback but did not explain why the feature is being removed.

This retirement only affects the consumer Copilot app and does not impact Microsoft 365 subscriptions or other Copilot features included with eligible plans.

What Users and Organizations Should Do

Users and organizations that have shared Copilot podcast links in documents, training materials, websites, or internal communications should review them before August 18, 2026. After the retirement date, those links will no longer be accessible.

Although the original AI-generated audio cannot be exported, users may be able to recreate important podcasts if they still have the original prompts, documents, notes, or transcripts used to generate them.

This announcement also highlights an important lesson for organizations using AI services. Business-critical AI-generated content should not rely solely on cloud-hosted features that do not support data export. Keeping local copies or storing important AI-generated content in approved repositories can help avoid data loss if a service or feature is removed in the future.

Microsoft confirmed that this change only affects the Podcasts feature. Other Copilot capabilities and Microsoft 365 subscription benefits will continue to be available as usual. Users who need additional information can contact Microsoft Support through the official support channels.

The post Microsoft Ends Copilot Podcasts and Access appeared first on First Hackers News.

The vulnerabilities, identified as CVE-2026-15409 and CVE-2026-15410, were observed being exploited before public disclosure. Because of the active attacks, both flaws have been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog, emphasizing the need for immediate action.

Exploitation Chain

The first vulnerability allows an unauthenticated attacker to reach internal services that are normally protected from external access. This provides an entry point to the appliance and enables attackers to execute commands with limited privileges.

The second vulnerability can then be used to escalate those privileges to root by abusing the appliance’s update and rollback process. Once exploited, attackers can run malicious scripts with full administrative permissions, giving them complete control over the system. Researchers also noted that the appliance may reboot after exploitation, which can make incident investigation more difficult.

Affected products include SonicWall SMA 1000 Series devices running vulnerable releases in the 12.4.3 and 12.5.0 software branches. SonicWall has confirmed that the SMA 100 Series and SSL VPN functionality on SonicWall firewalls are not affected.

Security Recommendations

Organizations using affected SonicWall SMA 1000 appliances should install the latest security hotfixes released by SonicWall as soon as possible, as no alternative mitigation is currently available.

In addition to patching, security teams should inspect appliances for signs of compromise, re-image affected systems if necessary, rotate administrator and user credentials, reset multi-factor authentication tokens following a confirmed breach, and continue monitoring VPN infrastructure for suspicious activity.

Applying the latest updates and reviewing exposed appliances promptly will help reduce the risk of compromise from these actively exploited vulnerabilities.

The post Attackers Target SonicWall SMA1000 Zero-Days appeared first on First Hackers News.

The vulnerability is linked to insecure cloud permissions and a built-in command execution feature found in certain Shark vacuum firmware. At the time of disclosure, no official patch had been released.

How the Vulnerability Works

Researchers found that the issue affects internet-connected Shark robot vacuums that communicate through AWS IoT services. By exploiting weak cloud permissions, an attacker who gains access to one vulnerable device could potentially interact with other Shark vacuums connected to the same cloud environment.

The most serious concern is a command execution feature that allows specially crafted messages to run commands on the device. During testing, researchers successfully demonstrated that credentials taken from one Shark vacuum could be used to execute commands on another compatible device.

Some Shark models also include cameras and store household maps for navigation. Researchers warned that a successful attack could allow unauthorized access to:

• Live camera feeds on supported models
• Home mapping data
• Stored Wi-Fi credentials
• Remote control of the vacuum
• Device information and telemetry

The research also identified a large number of active Shark devices communicating with the affected cloud infrastructure, indicating that the potential impact could be significant.

Recommended Security Measures

Until an official fix is released, Shark robot vacuum owners should take steps to reduce their exposure.

Recommended actions include:

• Keep the vacuum firmware updated with the latest available version.
• Monitor SharkNinja for future security updates and advisories.
• Place smart home and IoT devices on a separate Wi-Fi network whenever possible.
• Regularly review your home network for unknown or suspicious devices.
• Remove unused smart devices from your network.
• Change your Wi-Fi password if you suspect unauthorized access.

This vulnerability highlights the growing importance of securing Internet of Things (IoT) devices. As more connected devices become part of everyday life, regular updates, network segmentation, and strong security practices remain essential for protecting home networks and personal data.

The post Critical Flaw Found in Shark Robot Vacuums appeared first on First Hackers News.