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.

The malicious packages were distributed as .NET command-line tools, allowing users to install them using the standard dotnet tool install command. They primarily targeted players of popular games such as Albion Online, GTA5RP, GrandRP, Majestic RP, Lineage 2, Russian Fishing 4, and Throne and Liberty.

After discovering the campaign, researchers reported the packages to NuGet’s security team for removal.

How the Malware Operates

Once installed, the malicious package downloads a second-stage payload called pepesoft.exe from attacker-controlled infrastructure hosted on GitHub Releases and Hugging Face.

The malware includes several techniques to avoid detection and maintain its operation. It uses Google DNS-over-HTTPS to resolve download servers, making it more difficult for traditional DNS-based security controls to block its activity. In many cases, it also attempts to synchronize the system clock before downloading additional components.

After installation, Pepesoft contacts remote servers to retrieve configuration updates and collect information from the infected device. The malware generates a unique hardware identifier and gathers system information such as usernames, computer names, hardware details, network information, public IP addresses, and approximate location.

Some variants also include Telegram bot functionality, allowing attackers to remotely capture screenshots of the victim’s desktop. These screenshots could expose browser sessions, password managers, cryptocurrency wallets, authentication prompts, private conversations, or other sensitive information displayed on the screen.

Security Recommendations

Developers and organizations should review their development environments for suspicious NuGet packages and investigate any unexpected execution of pepesoft.exe.

Recommended security measures include:

• Review installed NuGet packages and remove any unknown or suspicious tools.
• Verify the authenticity of open-source packages before installation.
• Monitor systems for unexpected execution of pepesoft.exe.
• Watch for unusual outbound connections to GitHub, Hugging Face, and other unknown infrastructure.
• Monitor for unexpected DNS-over-HTTPS traffic from development systems.
• Keep endpoint security solutions updated and regularly scan developer workstations.
• Educate developers about software supply chain attacks and package verification.

This campaign highlights the growing risk of software supply chain attacks, where attackers disguise malicious packages as legitimate developer tools. Carefully verifying third-party packages before installation remains one of the most effective ways to reduce this risk.

The post NuGet Packages Deliver Pepesoft Malware appeared first on First Hackers News.

This is a maintenance release rather than a new version of Debian. Existing users can upgrade their systems using the standard APT update process without performing a full operating system upgrade.

What’s New in Debian 13.6?

Debian 13.6 combines previously released security updates into a single package, making it easier for users to keep their systems up to date.

The release also includes:

• An updated Linux kernel (6.12.94+deb13)
• Improved installation media for new deployments
• Security fixes for Apache HTTP Server
• Curl updates that address credential leaks and other security issues
• QEMU updates with multiple security improvements
• Bug fixes across various Debian packages

The update also improves UEFI Secure Boot support by updating fwupd to version 2.0.20. Debian recommends installing firmware updates provided by your hardware manufacturer before making changes to Secure Boot on supported systems.

Security Recommendations

Administrators should update their systems as soon as possible to benefit from the latest security fixes.

Recommended actions include:

• Run apt update && apt upgrade to install the latest updates.
• Use the new Debian 13.6 installation images for fresh deployments.
• Apply firmware updates recommended by your hardware vendor.
• Update Apache, Curl, QEMU, and other affected packages.
• If your organization relies on accurate IP geolocation, obtain the latest GeoLite database directly from its provider instead of using Debian’s bundled package.

Keeping Debian systems updated is one of the most effective ways to reduce security risks and ensure stable, reliable operation.

Notable CVEs Fixed

• Apache2: CVE-2026-29167, CVE-2026-48913, CVE-2026-29170, CVE-2026-34355, CVE-2026-34356, CVE-2026-42536, CVE-2026-42535, CVE-2026-44186, CVE-2026-49975, CVE-2026-43951, CVE-2026-44185, CVE-2026-44119, CVE-2026-44631
• Curl: CVE-2025-14524, CVE-2026-3783, CVE-2025-14819, CVE-2026-1965, CVE-2026-3784, CVE-2026-5545, CVE-2026-4873, CVE-2026-3805, CVE-2026-5773, CVE-2026-6253, CVE-2026-6429, CVE-2026-6276, CVE-2026-7168
• QEMU: CVE-2024-6519, CVE-2026-2243, CVE-2026-3195, CVE-2026-3196, CVE-2026-3842, CVE-2026-3886, CVE-2026-3890, CVE-2026-41435 through CVE-2026-41440, CVE-2026-5744, CVE-2026-5761, CVE-2026-5763, CVE-2026-6502, CVE-2026-8341, CVE-2026-48002 through CVE-2026-48004, CVE-2026-48914, CVE-2026-48915, CVE-2026-6425, CVE-2026-8343
• Linux kernel: Updated through multiple Debian security advisories, alongside refreshed signed AMD64 and ARM64 kernel packages.debian
• Other affected software: dcmtk, dhcpcd, giflib, libxml2, mutt, python3.13, rsync, sshfs-fuse, xz-utils, wireshark, OpenSSL, Chromium, Firefox ESR, Nginx, Redis, PostgreSQL 17, and Thunderbird received security-related updates.

The post Debian 13.6 Brings Major Security Fixes appeared first on First Hackers News.

The vulnerabilities were discovered by Miggo Security and affect RabbitMQ versions starting from 3.13.0. Security updates are now available, and organizations are encouraged to patch affected systems as soon as possible.

Two Critical Security Flaws

The first and more severe vulnerability, CVE-2026-57219, exposes RabbitMQ’s OAuth configuration through a management API endpoint that does not require authentication. If an organization stores an OAuth client secret for identity providers such as Auth0, Microsoft Entra ID, Keycloak, or UAA, an attacker with network access to the management interface could retrieve that secret.

Using the exposed credentials, an attacker may obtain administrator-level access to the RabbitMQ server, allowing them to manage messages, queues, users, and broker settings.

The second vulnerability, CVE-2026-57221, affects permission validation within RabbitMQ. Although less severe, it allows authenticated users with limited privileges to discover queues, exchanges, and usage statistics that they should not normally be able to access. In shared or multi-tenant environments, this information could help attackers gather intelligence for future attacks.

Recommended Security Measures

Both vulnerabilities have been fixed in RabbitMQ 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15.

Organizations should take the following steps to protect their RabbitMQ deployments:

• Update RabbitMQ to a supported patched version immediately.
• Rotate OAuth client secrets after applying updates.
• Restrict access to the RabbitMQ management interface (port 15672) and avoid exposing it to public networks.
• Isolate tenants using separate virtual hosts instead of shared environments.
• Review container images and Helm charts to ensure they are not using vulnerable RabbitMQ versions.
• Monitor RabbitMQ systems for unusual administrative activity or unauthorized access attempts.

These vulnerabilities highlight the importance of securing management interfaces and regularly updating infrastructure components. Prompt patching, strong access controls, and continuous security monitoring remain essential for protecting messaging platforms and the applications that depend on them.

The post RabbitMQ OAuth Bug Allows Unauthorized Access appeared first on First Hackers News.

This discovery challenges a long-standing assumption within Git—that a verified commit hash uniquely identifies a specific piece of signed code. As a result, organizations that rely on commit hashes for software integrity, dependency management, CI/CD validation, or software supply chain security should carefully evaluate the potential impact of this issue.

How the Attack Works

Git generates a unique hash for every commit using multiple components, including the source code, author and committer information, commit message, parent commit, and the embedded digital signature.

Under normal circumstances, modifying any part of a commit results in a completely different hash. However, researchers found that certain digital signature formats allow the signature’s encoded representation to be modified without affecting its cryptographic validity.

By changing only the encoding of the signature—not the source code or commit metadata—attackers can generate a new commit hash while preserving the same content and a valid signature. GitHub continues to verify the modified commit successfully and displays the familiar “Verified” badge.

As a result, two different commit hashes can represent the same code, making both appear as separate trusted commits.

Why This Matters

Many organizations use commit hashes as trusted identifiers throughout their software development lifecycle. Security tools, CI/CD pipelines, dependency management systems, and software supply chain controls often assume that every verified commit hash is unique and immutable.

This research demonstrates that the assumption may not always hold true.

An attacker could recreate an existing verified commit with a different hash, potentially bypassing security controls that rely solely on commit hashes. Systems designed to block malicious commits, enforce dependency pinning, or verify source code integrity may fail to recognize the duplicated commit because it appears as a new trusted object.

Research Findings

Security researcher Jacob Ginesin demonstrated several practical techniques affecting multiple GitHub-supported signature formats, including:

• ECDSA
• RSA (OpenPGP)
• EdDSA
• S/MIME/CMS

The research shows that GitHub currently accepts these modified signatures during verification and continues to mark the resulting commits as Verified, even though their hashes differ from the originals.

Since GitHub validates the cryptographic signature rather than enforcing a canonical signature encoding, these modified commits continue to pass the verification process successfully.

Potential Impact

The implications extend beyond individual repositories and may affect broader software supply chain security practices.

Potential risks include:

• Bypassing hash-based security controls.
• Circumventing commit blocklists by generating new verified hashes.
• Misleading dependency pinning mechanisms that rely on commit hashes.
• Creating confusion during repository comparisons and code reviews.
• Weakening software supply chain verification processes.
• Affecting reproducible build and software provenance frameworks that treat commit hashes as trusted identifiers.

Because Git commits are linked through parent commit hashes, modifying a signed commit also changes the hashes of all subsequent commits, allowing attackers to generate an entirely new yet valid-looking commit history.

Security Recommendations

Until stronger mitigations are introduced, organizations should avoid relying solely on commit hashes when validating software integrity.

Consider adopting the following security practices:

• Validate both commit content and digital signatures instead of relying only on commit hashes.
• Monitor repositories for unexpected duplicate verified commits.
• Strengthen CI/CD validation with multiple layers of verification.
• Review dependency pinning strategies that depend exclusively on commit hashes.
• Keep GitHub security features and repository protection settings up to date.
• Monitor security advisories and implement recommended mitigations as they become available.

Final Thoughts

This research serves as an important reminder that a “Verified” badge alone should not be considered the sole indicator of trust. While digital signatures remain a critical component of software integrity, organizations should implement layered verification processes that validate both the authenticity of the signature and the integrity of the underlying code.

As software supply chain attacks continue to evolve, strengthening repository security, enhancing CI/CD validation, and adopting defense-in-depth strategies will be essential to maintaining trust in modern software development workflows.

The post GitHub Signature Flaw Enables Duplicate Verified Commits appeared first on First Hackers News.

Earlier versions focused on using indirect system calls to bypass user-mode API hooks. However, today’s EDR platforms have evolved and now analyze call stacks, Event Tracing for Windows (ETW), and execution flow to identify suspicious behavior.

To counter these detection methods, SindriKit 1.3.0 adds dynamic call stack spoofing, allowing malicious execution to appear as though it originated from legitimate Windows components.

How the Technique Works

Modern EDR solutions don’t just monitor API calls—they also inspect the execution path that leads to a system call.

Even when malware invokes a legitimate Windows function, security products can detect abnormal return addresses or unexpected call chains, revealing malicious activity.

SindriKit 1.3.0 addresses this by generating a legitimate-looking call stack before executing a system call.

The framework performs several steps automatically, including:

• Parsing Windows exception handling information.
• Identifying legitimate functions with large stack allocations (“Fat Frames”).
• Selecting trusted return addresses from Windows modules.
• Randomizing stack layouts to avoid predictable execution patterns.

This allows the execution flow to closely resemble normal Windows behavior.

Call Stack Layout

Researchers explained that SindriKit’s MASM-based loader builds a carefully crafted JMP trampoline that creates a legitimate-looking call stack. This enables the execution flow to appear normal to both the Windows processor and EDR solutions that analyze call stacks.

; Top-of-stack spoofing layout

mov [rsp+0], r8 ; Trampoline Gadget (RET in Fat Frame)

lea rax, SyscallCleanup

mov [rsp+8], rax ; True return address (payload cleanup)

mov rax, [rbp+16] ; Original caller return address

mov [rsp+r12+8], rax ; r12 = spoof_frame_size

Instead of returning directly to attacker-controlled memory, execution passes through legitimate Windows stack frames. This makes the call chain appear more consistent during analysis and reduces the likelihood of detection by security products that inspect stack behavior.

Randomization Improves Stealth

Another key enhancement in SindriKit 1.3.0 is the use of randomization.

Rather than using the same stack layout every time, the framework dynamically selects different legitimate functions during execution.

This helps ensure that each system call follows a slightly different path, making behavioral detection more difficult and reducing the effectiveness of static call stack signatures.

After the system call finishes, execution first returns to the Trampoline Gadget, which immediately redirects control to SyscallCleanup inside the payload.

At the same time, Windows rebuilds the call stack using its exception handling information, making the execution path appear legitimate during stack analysis. This helps the spoofed call stack blend in with normal Windows activity.

On 64-bit (x64) systems, SindriKit dynamically creates this spoofed call stack for each execution. On 32-bit (x86) systems, where the required exception metadata is unavailable, the framework instead relies on predefined Windows functions and trusted return instructions to achieve a similar result.

Security Recommendations

Organizations should strengthen their defenses against advanced EDR evasion techniques by:

• Keeping EDR and endpoint security solutions up to date.
• Monitoring abnormal syscall and process execution behavior.
• Detecting unusual memory manipulation and call stack anomalies.
• Enabling ETW and behavioral monitoring where supported.
• Combining multiple detection methods instead of relying solely on signature-based protection.
• Regularly reviewing endpoint telemetry for suspicious activity.

The release of SindriKit 1.3.0 demonstrates how offensive security techniques continue to evolve alongside defensive technologies. As attackers adopt increasingly sophisticated evasion methods, organizations should focus on layered detection strategies and behavioral analysis to identify threats that traditional security mechanisms may overlook.

The post SindriKit 1.3.0 Bypasses EDR Security appeared first on First Hackers News.

The update introduces a redesigned menu system, faster package handling, optimized builds for modern processors, official Vagrant support, and several quality-of-life improvements aimed at making Parrot OS easier to use for both security professionals and everyday users.

Parrot 7.3 -Performance Improvements

One of the biggest highlights of Parrot 7.3 is improved performance on newer hardware.

The release includes optional packages optimized for modern x86-64-v3 and ARMv8.2-A processors, allowing supported systems to achieve noticeable performance gains during resource-intensive tasks.

These optimizations benefit applications such as:

• FFmpeg
• Inkscape
• NumPy
• Shared libraries
• Programming language runtimes

To maintain compatibility, core system components continue using standard builds, while hardware compatibility checks ensure optimized packages are installed only on supported processors.

Redesigned Menu System

Parrot 7.3 replaces its previous shell-based launcher with a new menu system written in Go.

The updated launcher simplifies application management and allows users to install supported tools directly from the desktop menu without opening the terminal.

The new menu also offers:

• Faster application launching
• Automatic menu updates
• Removal of duplicate launcher entries
• Cleaner navigation across installed and available tools

The goal is to provide a smoother experience for both new users and experienced penetration testers.

Official Vagrant Support

Another major addition is official Vagrant support for the Home and Security editions.

The preconfigured Vagrant boxes allow users to quickly deploy consistent Parrot environments for:

• Security testing
• Training labs
• Development
• CI/CD environments
• Team collaboration

This makes it easier to reproduce testing environments across different systems.

Improved Privacy and Smaller Images

Parrot 7.3 also introduces a redesigned Firefox start page that respects user privacy.

Users can choose their preferred search engine, including:

• DuckDuckGo
• Qwant
• Google

According to the Parrot team, the new page does not collect user data, reflecting the project’s privacy-focused approach.

The release also reduces the number of preinstalled packages in the Home and Security editions, resulting in smaller installation images and a lighter operating system.

Updated Security Tools

Parrot 7.3 ships with updated software packages to keep security professionals working with the latest tools.

Some notable updates include:

• Linux Kernel 7.0.9
• Metasploit 6.4.136
• Ghidra 12.0.4
• SQLMap 1.10.4
• Bettercap 2.41.5

Rather than introducing dozens of new tools, Parrot 7.3 focuses on refining the overall user experience. With improved performance, a redesigned menu system, official Vagrant support, updated security tools, and a lighter installation, the release delivers meaningful improvements for penetration testers, security researchers, and Linux enthusiasts alike.

The post Parrot 7.3 Launches with New Features appeared first on First Hackers News.

The decision comes after videos circulated online showing users remotely shutting down battery-powered three-wheelers, raising serious concerns about passenger and road safety.

Authorities have also warned that any other apps offering similar unsafe remote-control capabilities could face similar action.

Why Were These Apps Removed?

The apps were originally developed as Battery Management System (BMS) tools for electric vehicles.

Their intended purpose was to help:

• Monitor battery health and charging status
• Track vehicle location
• Manage fleet operations
• Disable vehicles in cases of theft or loan default

However, authorities found that the remote shutdown feature was allegedly being misused to stop vehicles without the driver’s permission.

How the Apps Were Misused

According to reports, some users were able to remotely disable nearby e-rickshaws using the connected battery management system.

Researchers believe the issue was caused by weak access controls, allowing unauthorized users with access credentials to send remote shutdown commands.

This meant that features designed for fleet management could potentially be misused by:

• Unauthorized individuals
• Rival financiers
• Disgruntled employees
• Malicious actors
• Pranksters

Such actions could interrupt journeys and create serious safety risks for both drivers and passengers.

Security Concerns

The incident highlights growing security challenges within Internet of Things (IoT)-enabled electric vehicles.

Researchers note that many low-cost electric vehicle platforms prioritize functionality over security, leaving connected systems vulnerable to misuse.

Some of the reported concerns include:

• Weak authentication mechanisms
• Shared or leaked login credentials
• Insufficient access controls
• Lack of driver authorization
• Remote shutdown without safety checks

Without proper safeguards, features intended to improve vehicle management can become potential security risks.

Government Response

Following reports of misuse, the government instructed Google and Apple to remove the affected applications from their respective app stores.

Officials also indicated that additional apps found enabling similar remote vehicle shutdown capabilities could face the same action.

The move reflects increasing efforts to improve the security of connected transportation technologies and protect public safety.

Recommendations for Fleet Operators

Organizations using connected Battery Management Systems should strengthen their security by:

• Enabling multi-factor authentication (MFA)
• Restricting access to authorized users only
• Preventing remote shutdown while vehicles are moving
• Maintaining audit logs for remote commands
• Conducting regular security assessments of BMS platforms
• Securing backend APIs and user credentials

As connected electric vehicles become more common, securing remote management features will be essential to prevent misuse and ensure passenger safety.

The post India Bans Apps Used to Stop E-Rickshaws Remotely appeared first on First Hackers News.

The attack is delivered through unsigned installers written in both .NET and Golang. Instead of installing the extension through an official browser store, the malware directly modifies Chromium browser files to install the extension and maintain persistence.

How the Attack Works

Once executed, the installer searches for Chromium-based browsers such as Google Chrome, Microsoft Edge, Brave, and other compatible browsers. It terminates running browser processes and modifies the Preferences and Secure Preferences files to register the malicious extension.

Researchers found that the malware recalculates browser integrity values, allowing the extension to bypass certain security checks on older Chromium versions. On newer versions, the attackers rely on social engineering or developer mode to enable the extension. After installation, the installer removes itself, leaving very few traces on the infected system.

Unlike traditional malware that connects to a hardcoded command-and-control server, the extension uses an EtherHiding technique. It queries a public blockchain RPC endpoint and retrieves an encoded value from a smart contract, which is decoded at runtime to obtain the active backend server. This approach allows attackers to change their infrastructure without updating the malware itself, making detection and takedown more difficult.

Wallet Address Replacement and Detection

The extension requests broad permissions, including access to websites, browsing history, and clipboard data. It continuously monitors copy-and-paste activity and uses cryptocurrency-specific patterns to identify wallet addresses for multiple blockchains, including:

• Bitcoin (BTC)
• Ethereum (ETH)
• Bitcoin Cash (BCH)
• Ripple (XRP)
• Dash (DASH)
• Solana (SOL)

When a wallet address is copied, the extension sends it to the attacker’s backend using an embedded API key. The server responds with an attacker-controlled wallet address, which immediately replaces the original address in the clipboard. If the victim pastes the address without verifying it, the cryptocurrency is transferred directly to the attacker’s wallet.

Researchers also found that the installer contains embedded configuration data, including API keys, extension settings, supported wallet types, and blockchain RPC endpoints. The malicious extension is downloaded separately during installation, allowing attackers to update components without modifying the installer.

The campaign has affected users across multiple regions, with researchers observing a notable concentration of infections in India, suggesting opportunistic targeting of cryptocurrency users rather than a region-specific operation.

To reduce the risk of compromise, users should install browser extensions only from official stores, avoid running unsigned installers, carefully review requested permissions, and always verify the first and last few characters of a cryptocurrency wallet address before completing a transaction.

Security teams should also monitor for unauthorized changes to Chromium Secure Preferences files, unexpected browser configuration modifications, and unusual blockchain RPC traffic associated with EtherHiding infrastructure.

IOCs

The post Malicious Extension Swaps Crypto Wallet Addresses appeared first on First Hackers News.

Instead of exchanging phone numbers, users will be able to share a unique username when starting new conversations. This feature is especially useful when joining community groups, networking at events, or interacting with people for the first time.

The rollout is being introduced in phases, with users able to reserve their preferred usernames before the feature becomes widely available.

How the Username Feature Works

Once the feature is enabled, new contacts will only see a user’s username instead of their phone number. Existing chats and contacts will continue to function normally, and users who prefer sharing phone numbers can continue using WhatsApp as they always have.

To prevent impersonation and abuse, WhatsApp has introduced several rules for creating usernames:

• Usernames must be 3–35 characters long.
• Only lowercase letters, numbers, periods, and underscores are allowed.
• Every username must include at least one letter.
• Usernames that resemble website domains, such as .com or .in, are not permitted.
• Each username must be unique, and users can choose to match their existing Instagram or Facebook handle for consistent branding.

WhatsApp has also added an optional username key, a four-digit PIN-like code that provides an additional layer of privacy. New contacts must enter this code before they can send a message, helping reduce spam and unwanted conversations. Existing contacts are not affected by this requirement.

Improved Privacy and User Protection

Unlike many social media platforms, WhatsApp usernames are not searchable through a public directory. Users cannot browse or discover other usernames unless they already know the exact handle, significantly reducing unsolicited messages and unwanted contact.

The feature is available across Android, iOS, Windows, and WhatsApp Web as the rollout expands globally. Users can reserve a username by navigating to Settings → Account → Username on the latest version of the app. WhatsApp also provides username suggestions if a preferred handle has already been taken.

The new system is particularly beneficial for creators, businesses, and organizations, allowing them to use the same username across WhatsApp, Instagram, and Facebook for a consistent online identity.

By moving from phone number-based communication to username-based messaging, WhatsApp is strengthening user privacy while reducing unnecessary exposure of personal contact information. The update also brings the platform closer to privacy-focused messaging services that have long supported handle-based communication.

The post WhatsApp Introduces Usernames for Private Messaging appeared first on First Hackers News.