Yandex Restores Access to 96% of Yandex Disk Data After Data Center Attacks
Yandex has restored access to 96% of data on Yandex Disk after attacks on its data centers damaged company infrastructure. Documents, photographs, video files, and other content can once again be opened, downloaded, and shared with others.
Recovery efforts are still underway for a portion of users. Some accounts now have full access while others show lower percentages because Yandex Disk capacity continues to be migrated between sites. The company states that the volume of accessible files will increase in the coming days.
Core functions including upload, download, and synchronization are operational. However, the browser version remains limited: users cannot download an entire folder, album, or multiple files in a single action. Yandex recommends using the desktop client or API for these operations.
The incident began when attacks on data centers disrupted infrastructure integrity. Yandex is now distributing resources across independent external platforms to strengthen service resilience. Work on the remaining files and features continues, although no precise timeline for complete recovery has been announced.
Related articles
New Container, Old Code: Web Shell Persists Three Months in 1C-Bitrix Environment
Two 1C-Bitrix sites shared a web shell named WebShellOrb after an attacker exploited multiple vulnerabilities in a custom appeal application. The initial compromise went undetected because Nginx logs were retained for only one month, leading responders to conclude that no scanning activity remained visible. After agents showed no malicious code, administrators restarted the container without addressing the underlying issues in the shared filesystem and source code. The attacker regained access weeks later by reusing JWT tokens generated with a hardcoded secret and by exploiting SQL injection flaws that allowed password hash extraction. Shared system user accounts and a common filesystem volume enabled the shell to propagate between sites and survive container recreation. The incident highlighted that redeploying containers and rotating passwords failed to eliminate persistence rooted in unpatched code and misconfigured authentication logic.
How to Check If Your Passwords Have Leaked Online Using Have I Been Pwned
The article explains the common ways passwords end up exposed through site breaches, password reuse, or device infostealers. It details how to use the Have I Been Pwned service to check email addresses against known data leaks and the separate Pwned Passwords tool to verify if a password itself has appeared in dumps. Readers learn that absence from the database does not guarantee safety and that results must be interpreted by examining exactly which data fields were exposed. Practical steps include replacing reused passwords starting with email and financial accounts, enabling MFA or passkeys, terminating old sessions, and scanning devices for malware. The guide also recommends adopting a password manager and staying alert to login notifications. Overall it stresses that regular checks combined with unique credentials and multi-factor authentication form the most effective defense against credential stuffing and account takeovers.
k0t Operators Breach Corporate Firewalls and VPNs Exposing Over 70,000 Credentials
Group-IB and NyxLab detailed a campaign by the operator k0t targeting exposed firewalls and VPN portals. The operation collected more than 70,000 credentials from network devices and LDAP directory extractions across 84 compromised appliances. Initial access relied on CVE-2025-64446 directory traversal in FortiWeb, CVE-2026-0257 authentication bypass in Palo Alto GlobalProtect, and password brute-forcing against FortiGate devices. Attackers then leveraged CVE-2019-6693 to decrypt FortiOS configuration secrets and chained the noPac technique to reach domain administrator privileges. Persistence was achieved through MeshCentral, AdaptixC2, Atera, AnyDesk, and ngrok, while Rclone handled data exfiltration to cloud storage. Victims appeared on the Qilin and The Gentlemen leak sites, suggesting the operators likely act as initial-access brokers rather than direct ransomware affiliates.
OpenCode Reports Possible Exposure of Third-Party API Keys After Legacy System Breach
OpenCode disclosed that an attacker accessed a legacy system on October 16, potentially exposing API keys from external providers that users had stored in the Console. The incident affected only 1.4 percent of Console users, and the targeted system was already undergoing decommissioning. The company described the exposure as possible rather than confirmed and provided no details on the attack vector, duration, or number of keys involved. Some affected users reported unauthorized charges on their provider accounts. OpenCode stated that the incident was limited to keys stored in the Console and did not impact keys saved locally in its command-line or desktop applications. The firm notified impacted users by email on October 17 and is working with Anthropic, OpenAI, and Google. It recommended revoking and rotating exposed keys directly with each provider.