Metascan Confirms Limited Data Breach After Two-Minute Telegram Bot Compromise
Metascan, a company providing vulnerability scanning and information security services, has confirmed an internal data leak and released the findings of its investigation. According to the company, an attacker remained in a corporate Telegram chat for roughly two minutes and managed to export only a limited set of documents.
The incident occurred in the early hours of September 5. The attacker used a compromised administrative token belonging to a Telegram bot and added a fake account disguised as an HR employee. Export of the chat began at 02:02 and was interrupted at 02:04 when the account was removed. The bot itself had no access to client chats but held administrator rights in the internal corporate chat.
The company stated that the attacker obtained a small volume of data, including two pilot project reports dated July 2026. Earlier, the threat actors published internal documents and screenshots referencing Transneft, Selectel, Lenta, Sberbank, Rostelecom and other large organizations. They also alleged that Metascan had concealed client vulnerabilities to sell remediation services later. Metascan rejected these claims and linked the publication to a former employee now cooperating with a competitor.
The root cause was identified as an internal error: while primary tokens were revoked upon the employee’s departure, a token remained active on test virtual machines. Metascan has fully accepted responsibility, announced plans to strengthen technical controls, and stated its intention to pursue legal assessment of the actions involved. The company has also launched a vulnerability disclosure program, accepting reports at bb@metascan.ru prior to publication on specialized platforms.
Related articles
Unauthorized Access to Japan's Government Solution Service (GSS) Exposes 246,000 Personal Records via VPN Flaw
Japan's Digital Agency confirmed that its Government Solution Service (GSS) suffered unauthorized access after attackers exploited a vulnerability in VPN equipment used for external maintenance operations. The intrusion, believed to have begun in late May 2026, allowed threat actors to compromise maintenance accounts and access large volumes of files on internal servers. On June 25, 2026, security teams detected suspicious access to numerous files using a compromised account, prompting an investigation that concluded on July 9 with confirmation of the breach. Some files containing personal information may have been exfiltrated, affecting approximately 246,000 records of government officials, civil servants, contractors, and related individuals. The agency immediately disabled the affected accounts and severed external communications on July 9 but has not disclosed technical details of the exploited VPN vulnerability. The incident was reported by Security NEXT on September 11, 2026.
South Korean Medical Beauty Platform Gangnam Unni Suffers API Breach Exposing 220,000 Users' Sensitive Photos and Medical Records
Healing Paper, operator of South Korea's largest medical beauty information platform Gangnam Unni, confirmed a data breach affecting nearly 220,000 customers after an API endpoint used to query consultation records was abnormally accessed. The incident exposed highly sensitive personal information including names, contact details, medical consultation reasons, treatment progress, uploaded pre-procedure photos, appointment times, actual procedures performed, and payment information. Approximately 160,000 South Korean users and 60,000 overseas users were impacted, including 481 from mainland China, 4,218 from Taiwan, and others from Japan and Thailand. Attackers exploited weak authentication and rate limiting on the API, first detected on September 4, with a second attempt on a different path the following day. The breach raises risks of targeted phishing and extortion using victims' private medical images and records. Healing Paper has reported the incident to authorities, implemented enhanced authentication and monitoring, and allowed users to check their exposure status within 30 days.
Dropbox Accounts Compromised Through Lenovo ID Authentication Flaw
Several thousand Dropbox accounts were breached between August 4 and 21 due to an authorization flaw involving Lenovo ID. The root cause was an error on Lenovo's side that permitted registration of accounts using arbitrary email addresses, which could then be used to access matching Dropbox accounts. Dropbox responded by forcing logouts for all users who had relied on Lenovo ID and by requiring direct password entry for Dropbox credentials. Approximately 5,000 accounts were affected, though only about one-third saw stored files accessed by attackers. Accounts protected by two-factor authentication remained unaffected. Additional reports from the same period covered Kaspersky analysis of ValleyRAT spyware using DLL sideloading, a critical SQL injection vulnerability in the All-in-One WP Migration WordPress plugin, and a Google Chrome update addressing CVE-2026-85046 in the V8 engine.
Detecting and Removing Secrets from Git History with Betterleaks and git-filter-repo
Developers often accidentally commit sensitive data such as API keys, passwords, database dumps, or private uploads to Git repositories. Even after removal in a later commit, these secrets remain accessible in the commit history and can be recovered by anyone with repository access. The recommended approach begins with scanning the entire history using specialized tools to identify leaked credentials across all branches and past commits. Once identified, the secrets must first be rotated or revoked before any history rewriting occurs. Tools like Betterleaks provide detection with keyword filtering, entropy analysis, and Base64 decoding, while git-filter-repo enables precise removal of files and replacement of secret strings throughout the repository timeline. The process requires careful backups, coordination with teams, and force-pushing rewritten history, followed by fresh clones for all contributors and CI/CD systems. Even after cleanup, organizations must assume that old secrets may persist in forks, backups, or caches and therefore treat rotation as mandatory.