The company revealed the incident on November 3, 2026, stating that the attacker gained initial access through a third-party component before moving from a development environment into parts of its production infrastructure.

Attack Timeline

According to Chainstack, the attacker accessed a development environment on October 26, 2026, and subsequently escalated access to parts of the production environment.

The intrusion was detected on October 31, when Chainstack blocked the attacker’s access and began securing its systems.

Customer Information Potentially Exposed

The compromised database contained customer-related information, including:

• Organization names
• Account holder names
• Member email addresses
• Password hashes

The attacker also gained access to systems storing node credentials. Although Chainstack reported no evidence that these credentials were read, the company is treating them as potentially exposed.

The compromised database contained customer-related information, including:

• Organization names
• Account holder names
• Member email addresses
• Password hashes

The attacker also gained access to systems storing node credentials. Although Chainstack reported no evidence that these credentials were read, the company is treating them as potentially exposed.

Customers Urged to Rotate Credentials

Chainstack has advised customers to take precautionary security measures, including:

• Rotate node credentials.
• Regenerate platform API keys.
• Change account passwords, particularly reused passwords.
• Monitor accounts for suspicious activity.
• Remain alert to potential phishing attempts.

Possible Connection to AI-Powered Attack Campaign

The incident is assessed to share links with a broader AI-powered cyberattack campaign involving the ARTEX framework. Other organizations, including WorkOS and Chainalysis, have also reported security incidents involving AI-assisted offensive operations.

However, the specific attack method used against Chainstack has not been publicly detailed, and the company has not confirmed the identity of the attacker.

The incident highlights the growing risks facing blockchain infrastructure providers and the importance of securing third-party components, monitoring production environments, and maintaining strong credential management practices.

The post Chainstack Data Breach Exposes Customer Data and Password Hashes appeared first on First Hackers News.

The vulnerabilities, tracked as CVE-2026-116606 and CVE-2026-111560, involve an authorization bypass and command injection. They carry CVSS scores of 9.3 and 8.6, respectively.

Two Vulnerabilities Identified

The first vulnerability, CVE-2026-116606, affects Barracuda Email Security Gateway (ESG). It involves a pre-authentication authorization bypass that could allow attackers to circumvent security restrictions.

The second flaw, CVE-2026-111560, is a command injection vulnerability affecting multiple Barracuda products, including:

• Email Security Gateway
• Load Balancer Application Delivery Controller
• Message Archiver
• Web Application Firewall
• WAF Control Center
• Web Security Gateway

When exploited together, the vulnerabilities could allow attackers to bypass authorization controls and obtain root access to affected devices.

Administrative Interface Access Required

Barracuda clarified that successful exploitation requires attackers to have access to the administrative interface of an affected product.

Therefore, devices whose administrative interfaces are not exposed to the internet are less vulnerable to this particular attack path.

The company recommends restricting administrative access to trusted internal networks and implementing appropriate network access controls.

Barracuda Releases Security Patches

Barracuda has released firmware updates addressing both vulnerabilities. Customers are advised to verify their installed firmware versions and ensure that all applicable security patches have been applied.

Organizations running outdated firmware may need to perform multiple updates before reaching the latest supported version. Barracuda also recommends enabling automatic patching where possible.

The post Barracuda Vulnerabilities Could Allow Attackers to Gain Root Access appeared first on First Hackers News.

The incident, which occurred on October 29, 2026, affected Binance, one of the world’s largest cryptocurrency exchanges. Following the attack, the exchange temporarily restricted withdrawals while investigating the breach and arranging the replacement of affected assets.

FBI Identifies North Korean Hacking Group Behind Binance Attack

On October 31, the FBI publicly attributed the cryptocurrency theft to TraderTraitor, a North Korean state-sponsored hacking operation.

The agency reported that the attackers stole more than $6 billion in virtual assets from Binance. Law enforcement agencies subsequently began tracking the movement of the stolen cryptocurrency and monitoring transactions associated with the attackers.

According to the FBI, the stolen funds were being converted primarily into Ethereum (ETH). Authorities warned that the attackers could use decentralized finance (DeFi) platforms and cryptocurrency swap services to move the assets and complicate efforts to trace their origins.

The FBI also called on cryptocurrency exchanges and digital asset service providers to identify suspicious transactions and prevent the movement of funds connected to the attack.

How Did the Binance Crypto Heist Happen?

Binance’s initial investigation pointed towards a compromised employee laptop as one of the possible entry points into its infrastructure.

The exchange subsequently indicated that the incident was more complex than initially understood, involving additional points of compromise and malicious software designed to remove traces of the attackers’ activities.

The incident highlights how attackers can exploit weaknesses in employee devices and internal technology environments to reach sensitive financial systems.

This rapid movement of digital assets demonstrates the challenges associated with detecting and containing attacks against cryptocurrency platforms, where transactions can be executed across multiple blockchain networks in a short period.

Stolen Cryptocurrency Converted Into Ethereum

Following the theft, investigators observed the attackers converting the stolen digital assets primarily into Ethereum.

This activity has raised concerns about potential cryptocurrency laundering through decentralized exchanges, instant swap services and other blockchain-based financial platforms.

Such techniques can make investigations more complicated by moving assets across different networks and converting them into multiple cryptocurrencies.

The FBI has been working with other US law enforcement agencies, including the US Secret Service and the Internal Revenue Service Criminal Investigation division, to track the stolen funds.

Cooperation between cryptocurrency exchanges, blockchain analytics companies and law enforcement agencies will be important in identifying suspicious wallets and preventing further transfers.

Security Lessons for Cryptocurrency Exchanges

The Binance crypto heist highlights several security challenges for organizations operating digital asset platforms.

Endpoint Security: Employee laptops and workstations must be protected through continuous monitoring, endpoint detection and response solutions, and effective device security policies.

Privileged Access Management: Organizations should restrict administrative privileges and implement strong authentication mechanisms to prevent compromised accounts from accessing critical infrastructure.

Continuous Security Monitoring: SIEM platforms and Security Operations Centers can help identify unusual access patterns, suspicious transactions and potential security incidents before they escalate.

Incident Response: Cryptocurrency exchanges must maintain effective incident response procedures to investigate breaches, contain threats and coordinate recovery activities.

Threat Intelligence: Sharing indicators of compromise and suspicious wallet information with industry partners can help organizations identify emerging threats and prevent stolen assets from moving through their platforms.

The post Binance Crypto Heist: FBI Links $6.3 Billion Theft to North Korean Hackers appeared first on First Hackers News.

The service appeared on October 16, 2026, and has drawn attention from security researchers because of its technical links to the StealC information-stealing malware. Its emergence also highlights how cybercrime operations can continue even after law enforcement disrupts their infrastructure.

One Malware, Multiple Attack Capabilities

Stadia combines information theft and remote administration features in a single package. According to Varonis Threat Labs, its capabilities are divided into six modules that allow operators to perform different activities on compromised machines.

These include:

• Stealing credentials and other sensitive information from browsers and applications.
• Accessing a hidden desktop through Hidden Virtual Network Computing (HVNC).
• Running commands remotely on infected computers.
• Browsing, transferring, and executing files.
• Monitoring and managing active processes.
• Loading additional malicious software.

The malware seller claims support for numerous browsers, cryptocurrency extensions, desktop wallets, messaging applications, email clients, and VPN software.

Stadia is also sold through monthly plans priced at $300, $550, and $900. The highest-priced subscription includes all six modules, while former StealC customers have been offered a free month of the Pro plan.

Evidence Connects Stadia to StealC

Stadia appeared after Operation Endgame disrupted infrastructure associated with StealC and other cybercrime operations. Varonis reported that authorities seized 326 servers and 142 domains during the operation.

Researchers connected the newer malware to StealC after examining its code. One important finding was an identical browser encryption component shared with StealC version 3.5. This provides evidence that the newer service reuses technology from the earlier malware.

Stadia also uses techniques intended to avoid detection and maintain access, including:

• Creating scheduled tasks to launch automatically and run periodically.
• Using encrypted strings to make analysis more difficult.
• Injecting code into browser processes to obtain sensitive data.
• Adding its installation directory to Microsoft Defender exclusions when sufficient permissions are available.
• Sending encrypted information to remote servers over HTTP.

The examined sample also checks Windows language settings and may stop running on systems configured for certain languages.

Detection Requires More Than Blocking Known Indicators

Stadia’s infrastructure and encryption details may change between versions, making it difficult to rely solely on known file hashes, domains, or IP addresses.

Security teams should look for suspicious browser process activity, unexpected scheduled tasks, unauthorized antivirus exclusions, unusual PowerShell commands, and unexplained outbound network traffic.

Organizations should also strengthen credential protection, monitor endpoints for suspicious behavior, and investigate signs of unauthorized remote access.

Although researchers have identified technical links between Stadia and StealC, the initial infection method and the total number of affected systems remain unconfirmed. Monitoring the malware’s behavior is therefore essential to detecting potential attacks.

IoCs

The post Stadia RAT Emerges Alongside StealC to Target Windows Users appeared first on First Hackers News.

The malware is sold through a malware-as-a-service model. Its operators advertise a tool designed to evade Windows Defender and other antivirus products. However, these claims are not proof that every version can bypass security protections.

Researchers at Group-IB analyzed KGB RAT and found several dangerous capabilities, including credential theft, remote desktop access, keylogging, and ransomware-related features.

KGB RAT Malware and Its Evasion Techniques

According to Group-IB’s research, KGB RAT has been promoted on underground forums as a commercial malware tool. The sellers offer a payload builder that can generate files in formats such as EXE, BAT, HTA, and REG.

Researchers found that analyzed samples were based on an obfuscated version of NjRAT, an existing remote access trojan.

Once executed, the malware can attempt to establish persistence and collect information about the infected computer. Group-IB observed several techniques, including:

• File disguise: The malware copied itself into a temporary folder and relaunched under the name svchost.exe, resembling a legitimate Windows process.
• Scheduled task creation: It created a task named ChromeUpdate to help it run again when the user signs in.
• System changes: It modified Windows settings related to hidden files and security warnings.
• Security checks: It collected information about running processes, installed security products, and the operating system.

These activities can help the malware remain active and gather information about the environment.

How KGB RAT Steals Data and Controls Computers

KGB RAT combines several capabilities that can put personal and business information at risk.

Group-IB’s analysis identified features designed to:

• Steal credentials: Access Windows Credential Manager files containing saved sign-in information.
• Record activity: Capture keystrokes, screenshots, and clipboard contents.
• Control devices remotely: Use remote desktop functionality, including a hidden VNC feature.
• Monitor cryptocurrency transactions: A Crypto Clipper component in an analyzed sample could potentially replace copied cryptocurrency addresses.
• Communicate with attackers: Send infection notifications through Telegram and contact command-and-control (C2) servers for instructions.

The researchers also observed the sample checking for virtual machines and analysis tools. Such checks may help malware operators identify environments used for security research.

The seller advertises a crypter intended to hide the malware from antivirus detection. However, Group-IB reported that its analysis platform detected samples through their behavior, demonstrating why obfuscation alone does not guarantee evasion.

How to Protect Windows Systems

Organizations should focus on preventing unauthorized execution and detecting suspicious activity.

Recommended measures include:

• Keep Windows and endpoint protection software updated.
• Block unapproved applications and suspicious executable files.
• Monitor unusual scheduled tasks, especially those created by programs running from temporary folders.
• Investigate unexpected registry changes and suspicious outbound connections.
• Watch for unusual credential access, keylogging behavior, and remote desktop activity.
• If infection is suspected, isolate the affected device, investigate the incident, and reset exposed credentials from a clean system.

KGB RAT highlights the risks posed by commercially distributed malware. Even when attackers rely on existing malware code, a combination of credential theft, persistence, and remote control can create serious security consequences.

For defenders, the priority is not simply identifying a suspicious file. It is detecting the behavior that reveals an attack and responding before sensitive information is compromised.

IoCs

The post KGB RAT Bypasses Windows Security to Hijack PCs appeared first on First Hackers News.

According to researcher Sunil Tripathy, the attack involves hidden instructions placed in a public repository. When ChatGPT reviews the repository, the instructions may influence the AI agent to perform actions in another private repository connected to the user’s account.

The researcher assigned the finding a CVSS 4.0 score of 9.3. This is the researcher’s assessment, not a confirmed vendor rating. His testing reportedly used accounts he controlled and a dummy secret.

How the Attack Could Work

The reported attack uses a technique called indirect prompt injection, in which an AI system encounters malicious instructions inside content it is asked to process.

The researcher describes a scenario involving two GitHub accounts: one controlled by an attacker and another belonging to the user who connected GitHub to ChatGPT.

The attack reportedly follows these steps:

• The attacker adds hidden instructions to a public repository.
• The victim asks ChatGPT to review that repository.
• The AI agent follows the malicious instructions and attempts to modify another private repository.
• A GitHub Actions workflow is added and runs automatically.
• The workflow allegedly sends a dummy secret to an external server.

The researcher also reports private repository discovery and unauthorized file changes. These findings have not been independently verified.

What Makes This Report Important?

The reported behavior raises concerns about how AI assistants handle untrusted repository content and permissions granted to connected services.

However, the exact integration involved remains important. OpenAI’s GitHub connection documentation describes the standard ChatGPT GitHub app as read-only, while Codex supports code editing and pushing. This difference means the affected product, permissions, and execution path need clarification.

The researcher says he reported related behavior on September 4, demonstrated the test scenario on September 28, and received an out-of-scope closure on October 14. He also claims the behavior remained reproducible on October 15. These statements do not establish that OpenAI has confirmed the issue or that a security patch is available.

Recommended Security Measures

Organizations using AI tools with GitHub should take steps to limit potential exposure:

• Restrict repository access: Give connected applications access only to repositories they need.
• Review workflow changes: Investigate unexpected GitHub Actions files, commits, and repository modifications.
• Protect sensitive credentials: Avoid exposing secrets to untrusted workflows and rotate credentials if exposure is suspected.
• Review application permissions: Regularly audit connected GitHub apps and remove unnecessary access.

The key lesson is that AI assistants must treat repository content as untrusted input. Limiting permissions and reviewing automated actions can help reduce the impact of malicious instructions.

As AI-powered development tools become more integrated into software workflows, access control and careful handling of untrusted content remain essential parts of software supply chain security.

The post ChatGPT GitHub Integration Flaw: Risks to Private Code appeared first on First Hackers News.

The flaws, tracked as CVE-2026-108184 and CVE-2026-108185, have CVSS v3.1 scores of 7.4. Zoom Offensive Security reported both issues in security bulletins dated October 13, 2026.

The available advisories describe information disclosure risks but do not confirm the exact information that could be exposed or whether attackers have exploited the flaws.

Zoom Certificate Validation Vulnerabilities

Certificate validation helps applications verify that they are communicating with trusted systems. If these checks do not work correctly, software may accept connections that should be rejected, potentially putting sensitive communications at risk.

The two Zoom vulnerabilities involve certificate validation, but the published details do not specify the exact validation failure or the method an attacker would use. There is also no confirmation that these flaws allow attackers to steal passwords, take over accounts, or execute malicious code.

CVE-2026-108184, documented in bulletin ZSB-26021, affects certain Windows-based Zoom applications. The affected products and version ranges include:

• Zoom Workplace for Windows: Versions 7.0.0 and later in the affected range, before versions 7.2.0 or 7.1.9 in the respective release branches.
• Zoom Workplace VDI Client for Windows: Versions 7.0.11 to before 7.0.13.
• Zoom Rooms for Windows: Versions 7.0.0 to before 7.1.7.

CVE-2026-108185, documented in bulletin ZSB-26022, affects certificate validation in the My Notes feature. The affected versions include Zoom Workplace for Windows from version 7.1.5, and for macOS and Linux from version 7.0.5, within the ranges specified by Zoom.

Zoom Workplace for Android and iOS is also affected by the My Notes vulnerability, starting at version 7.0.5 and continuing before version 7.2.0.

Recommended Security Updates

Organizations and individual users should review their installed Zoom versions and apply the appropriate security updates. The required fixed version depends on the product, operating system, and release branch.

Security teams should prioritize the following actions:

• Update affected applications: Install the latest supported releases from Zoom’s official Download Center.
• Audit all deployments: Check standard Workplace clients, VDI installations, Zoom Rooms, and devices using My Notes.
• Verify updates: Confirm that affected systems have moved to fixed versions after deployment.
• Coordinate across teams: Include remote devices and systems managed by separate IT teams in the update process.
• Follow official guidance: Review Zoom’s security bulletins for additional information and remediation instructions.

Disabling My Notes should not be treated as a confirmed workaround unless Zoom explicitly recommends it.

These vulnerabilities highlight the importance of keeping collaboration software updated across an organization’s entire environment. Applying patches consistently and verifying installed versions can help reduce exposure to known security weaknesses.

The post Zoom Certificate Validation Flaw Could Expose Sensitive Data appeared first on First Hackers News.

The update affects both OpenSSH client and server components, making it important for organizations and users that depend on SSH for remote administration, secure connections, and file transfers.

The vulnerabilities have different attack requirements and do not represent one universal attack against every OpenSSH installation. The main issues involve SSH compression, SFTP path handling, and usernames that may be passed into shell commands.

SSH Compression Flaw Could Expose Secrets

Researchers Fabian Bäumer and Marcus Brinkmann detailed the compression-related issue in their research paper, Crossing the Streams.

The problem occurs because multiple channels inside the same SSH connection can share a compression dictionary when compression is enabled. An attacker who can control data sent through one channel and observe changes in encrypted traffic sizes may be able to gather information about secrets being transferred through another channel.

The weakness is related to the way LZ77 compression works. Repeated data is replaced with references to information that has already appeared. If attacker-controlled content matches part of a secret, the compressed data can become smaller, creating a measurable difference in traffic size.

This does not mean that SSH encryption itself has been broken. Instead, information about the encrypted content can leak through compression behavior before the data is encrypted.

In one low-noise test conducted by the researchers, an eight-character secret using a 26-letter alphabet could be recovered in as many as 276 guesses. However, this result depends on the specific testing conditions and should not be considered a guaranteed recovery method for all SSH connections.

OpenSSH 10.6 addresses the problem by disabling the LZ77 dictionary coder in both ssh and sshd. Compression is still supported, but its effectiveness is reduced. OpenSSH developers recommend using compression at the application level when possible instead of sharing SSH compression between trusted and untrusted traffic.

SFTP and Username Injection Issues

OpenSSH 10.6 also improves security around SFTP path handling.

The update changes how paths returned by an SFTP server are handled. Previously, a malicious server could potentially return specially crafted paths that caused a recursive copy operation to write files outside the directory originally selected by the client.

This issue affects how the SSH client processes responses from an SFTP server. It does not mean that an unauthenticated attacker can simply write files to any SSH server.

Another security fix addresses usernames supplied through the SSH command line. OpenSSH 10.6 now blocks dollar signs and backslashes in destination usernames.

Under certain configurations, an attacker-controlled username could reach shell commands through features such as ProxyCommand or Match exec, potentially creating a shell injection condition.

The issue was reported by SecBuddyF KeenLab Tencent. The new restriction applies to usernames supplied through the command line, while usernames configured through the User option in configuration files are not affected by this particular check.

OpenSSH developers also point out that character filtering alone cannot protect every possible shell environment. Applications should therefore avoid placing untrusted input directly into SSH command lines.

Additional Security Improvements in OpenSSH 10.6

Beyond the three major issues, OpenSSH 10.6 includes several other security and reliability improvements.

The release addresses problems involving GSSAPI credentials, tunnel restrictions, oversized decompressed packets, and certificate date conversion. On some older operating systems, including QNX 6 and SCO OpenServer 5, certain forwarding options have also been disabled because of risks associated with retained root privileges.

For administrators, the release is a reminder that SSH security involves more than strong encryption and authentication. Features such as compression, forwarding, SFTP operations, and command-line processing can also introduce security risks when they interact with untrusted input.

Organizations using OpenSSH should review the release and plan their upgrades, particularly if their environments use SSH compression, SFTP transfers, proxy commands, or forwarding features.

OpenSSH maintainers have also indicated that releases may become more frequent as AI-assisted vulnerability research leads to more security reports. Human review, testing, and validation will remain important to determine whether reported issues are genuine and how they should be fixed.

The post Several OpenSSH Security Flaws Put Systems at Risk appeared first on First Hackers News.

According to the advisory, more than 86,644 devices across 194 countries have been affected. Organizations that expose Fortinet management interfaces or remote-access services to the internet face a particularly high risk.

FortiBleed is not being described as one newly discovered Fortinet vulnerability. Instead, attackers are reportedly gaining access by using stolen, leaked, reused, or weak credentials.

The campaign also takes advantage of older SHA-256 password storage, allowing attackers to process stolen password data using distributed password-cracking systems.

Investigators discovered the scale of the operation after the attackers accidentally exposed a backend server containing their tools, target information, and operational workflows.

How the FortiBleed Campaign Works

The exposed infrastructure revealed what appears to be an organized initial-access operation.

Attackers reportedly scan the internet for FortiGate SSL VPN portals and then test credentials collected from previous breaches and infostealer logs.

They use techniques such as:

• Credential stuffing
• Password spraying
• Password cracking
• Testing stolen credentials
• Scanning exposed FortiGate systems

Once valid credentials are found, the access can potentially be sold to other cybercriminals.

Attackers may also create new administrator accounts after entering a FortiGate device. These accounts can help them maintain access even if the original compromised credentials are changed.

From there, threat actors can investigate Active Directory, identify privileged users, and attempt to move deeper into the victim’s network.

Attackers Can Lock Out Administrators

One of the most serious parts of the campaign is the possibility of defenders being locked out of their own Fortinet devices.

According to the advisory, attackers have reportedly changed passwords, disabled legitimate accounts, or removed existing administrator accounts after creating their own accounts.

This can make incident response much more difficult because security teams may lose control of the firewall or VPN gateway while the attackers continue operating.

The activity has also been linked to initial-access brokers that provide compromised access to ransomware groups. Reported ransomware connections include INC/Lynx and Payload, raising the possibility that a compromised FortiGate device could be the starting point for a much larger attack.

FortiBleed MITRE ATT&CK Techniques

The campaign has been associated with several MITRE ATT&CK techniques:

The combination of valid credentials, newly created accounts, and administrator lockouts can make the attack difficult to detect and contain.

What Organizations Should Do

Organizations using FortiGate devices should immediately review their administrative and VPN accounts and look for accounts they do not recognize.

The advisory specifically recommends checking for suspicious accounts such as:

• forticloud-sync
• fgtsecure
• forti_support2
• Technical_support

Security teams should also investigate:

• Unexpected REST API keys
• Unusual configuration changes
• Suspicious authentication activity
• Connections to known malicious infrastructure
• Unexpected administrator accounts
• Successful suspicious logins
• Signs of lateral movement
• Attempts to modify firewall configurations

External management access should be restricted wherever possible. Organizations should use trusted hosts or local-in policies and avoid exposing administrative interfaces directly to the internet.

Administrators should also:

• Terminate active administrative and VPN sessions
• Reset Fortinet administrator and VPN passwords
• Enable phishing-resistant MFA for remote access and management
• Review firewall, VPN, authentication, and domain-controller logs
• Check whether administrator credentials use PBKDF2 instead of older password-hashing methods

The FortiBleed campaign shows why internet-facing firewalls and VPN gateways need the same level of monitoring and protection as other critical enterprise systems. A compromised edge device can provide attackers with a direct path into the wider network — and in some cases, even allow them to take control away from legitimate administrators.

The post 80,000+ Devices Hit in FortiBleed Attack appeared first on First Hackers News.

The incident happened on October 4, 2026, after an attacker gained access to the company’s cloud environment. Around 12 GB of database information was copied, while a stolen Discord bot token was later used to send unwanted invitations to about 50 large servers.

Double Counter says the incident has been contained and its services were restored. The company also reviewed 14 cloud projects and found no evidence of persistent backdoors. The incident affected Double Counter’s own infrastructure and does not indicate that Discord itself was breached.

How the Attacker Got In

The attack started with an old OVH server that Double Counter had used for hosting in the past.

Although the server was no longer part of the main service, it still had a publicly accessible analytics tool called Metabase. The attacker exploited a weakness in the setup to gain administrator access and retrieve credentials stored on the server.

Among the stolen information was a cloud account with high-level permissions and a saved administrator session. These credentials gave the attacker a path from the old server into Double Counter’s active cloud environment.

The attacker then added an SSH key, accessed cloud resources, and opened a shell inside a bot container. This eventually exposed the Discord bot token.

Stolen Token Used Against Discord Servers

The compromised token gave the attacker control over parts of Double Counter’s Discord presence.

They used it to give their account administrator permissions on a support server, restore a previously banned account, and send invitations to other Discord communities.

Double Counter initially replaced the stolen bot token, but the attacker was able to obtain the new token within minutes because their cloud access was still active.

This was an important lesson from the incident: changing a password or token is not enough if the attacker still controls the system that can access the replacement secret.

The attacker later accessed database records and copied information during several stages of the attack. Access was finally stopped after the company revoked the compromised cloud sessions and credentials.

What Data Was Exposed?

Double Counter estimates that several datasets may have been exposed, including:

• Discord IDs and usernames
• IP address and location information
• User-agent hashes
• Approximately one million unique email addresses

The company noted that these datasets overlap, so the figures should not be added together to estimate the total number of affected users.

Double Counter says Discord passwords and stored payment card information were not exposed. Separate cold-storage data covering millions of users was also unaffected.

The company has since shut down the old server, revoked compromised access, rotated credentials, removed exposed webhooks, and moved databases behind private networking.

The incident is another reminder that unused infrastructure can become a serious security risk. Old servers, forgotten applications, saved credentials, and inactive cloud resources should be regularly reviewed and removed when they are no longer needed.

The post Discord Bot Breach Exposes User Data appeared first on First Hackers News.