FortiBleed Data Leak Exposes 73K Fortinet VPN
The "FortiBleed" data leak exposed 73,932 Fortinet and FortiGate VPN credentials, affecting firewall URLs across organizations globally. This exposure, found by security researchers, details usernames, email addresses, and plaintext passwords that reportedly provide direct access to Fortinet VPN devices. The dataset includes information from organizations such as Chevron, Samsung, Foxconn, Comcast, AT&T, Mercedes-Benz, and Toyota, impacting entities in 194 countries.
Investigation into the exposed server indicates a Russian-speaking threat group conducted a large-scale credential collection campaign. This campaign involved approximately 1.16 billion login attempts against 320,777 FortiGate devices and an additional 2.1 billion attempts targeting 163,650 Microsoft SQL Server systems. The threat group reportedly used intercepted SSL VPN authentication hashes, cracked them with GPU-powered infrastructure, and then used these recovered credentials to access victim networks.
This credential exposure is a large collection of compromised Fortinet-related credentials. While Fortinet states its internal investigation found no evidence of a new vulnerability or breach, attributing the dataset to prior incidents and successful brute-force attacks, independent validation confirms the authenticity of parts of the leaked credentials. Many of the affected devices remain online, running relatively recent FortiOS versions, demonstrating an immediate risk of unauthorized access.
How Did the FortiBleed Credential Exposure Occur?
The FortiBleed data leak originated from an exposed server containing compromised Fortinet and FortiGate VPN credentials. This collection included usernames, email addresses, and plaintext passwords, potentially granting direct access to sensitive VPN infrastructure. The dataset also contained additional metadata, such as company revenue, industry classification, and employee counts, suggesting the information may have been used to prioritize targets for cyberattacks.
Analysis of the exposed server revealed evidence implicating a Russian-speaking threat group. This group reportedly conducted a large-scale campaign to collect these credentials, executing billions of login attempts against FortiGate devices and Microsoft SQL Server systems. The method involved intercepting SSL VPN authentication hashes, which were then processed and cracked using a dedicated GPU-powered infrastructure. This process allowed attackers to convert hashed credentials into plaintext, enabling their use for deeper network infiltration.
Cybersecurity researchers who independently validated the data found portions of the credentials authentic and functional. Their analysis suggested the data likely came from a combination of exported Fortinet configuration files and successful brute-force attacks, rather than a single, recent breach. Despite the extensive exposure, Fortinet has stated that its investigations have not identified a new vulnerability or a recent breach within its own systems, concluding the data is a compilation of credentials from various previous incidents.
Organizations affected by FortiBleed must take immediate steps to reduce the risk of unauthorized access. This includes resetting all FortiGate VPN and administrator passwords to invalidate any exposed credentials, enforcing Multi-Factor Authentication (MFA) on all VPN and administrative accounts, reviewing logs for suspicious login attempts or unauthorized activity, and promptly addressing any anomalies. Additionally, disabling or removing unused accounts, rotating service and privileged account credentials, and restricting management interface access to trusted networks are critical steps to improve security.
Is the Oracle PeopleSoft 0-Day Being Actively Exploited?
Yes, the Oracle PeopleSoft 0-day vulnerability, tracked as CVE-2026-35273, is being actively exploited, particularly within ransomware campaigns. The Cybersecurity and Infrastructure Security Agency (CISA) has added this critical flaw to its Known Exploited Vulnerabilities (KEV) catalog, showing the urgency for immediate remediation. This vulnerability affects Oracle PeopleSoft Enterprise PeopleTools and is classified as CWE-306 (Missing Authentication for Critical Function), allowing unauthenticated remote attackers to access and execute sensitive functions without valid credentials.
Successful exploitation of CVE-2026-35273 can give threat actors complete control over vulnerable PeopleSoft environments. As Oracle PeopleSoft is a widely deployed Enterprise Resource Planning (ERP) solution managing business functions such as finance, human resources, and payroll, a compromise can lead to access to highly sensitive corporate data, unauthorized administrative actions, privilege escalation, and persistent access. The unauthenticated, remote exploitability makes internet-facing PeopleSoft instances particularly susceptible to attack.
Threat actors, especially those financially motivated, use this zero-day to deploy ransomware payloads, exfiltrate confidential information, move laterally within networks, and establish long-term persistence. While specific technical details of the exploitation process remain limited, the authentication bypass nature of the flaw simplifies the attack chain, allowing direct abuse of exposed administrative functionality. The confirmed use in ransomware attacks further raises the severity of this vulnerability, making immediate patching a critical defense measure.
Organizations using Oracle PeopleSoft should consult CISA's Binding Operational Directive (BOD) 26-04 for mandated remediation guidance. This involves applying all Oracle-provided security patches and updates addressing CVE-2026-35273 immediately. Identifying and securing all vulnerable Oracle PeopleSoft Enterprise PeopleTools instances, especially those accessible from the internet, is paramount. Further information on this critical vulnerability, its exploitation, and mitigation strategies is available in dedicated analyses of the Oracle PeopleSoft CVE-2026-35273 exploit and reports detailing Oracle PeopleSoft CVE-2026-35273 RCE.
What Was Compromised in the ShapedPlugin WordPress Supply Chain Attack?
Multiple ShapedPlugin WordPress Pro plugins were compromised in a supply chain attack by unknown threat actors who injected backdoor code into release channels. This incident affected builds distributed through the vendor's Easy Digital Downloads (EDD) infrastructure via account.shapedplugin[.]com, specifically impacting licensed Pro versions. The free versions of these plugins available on WordPress.org were not affected.
The primary plugins identified in this supply chain attack include:
- Product Slider Pro for WooCommerce (versions before 3.5.4)
- Real Testimonials Pro (version 3.2.5)
- Smart Post Show Pro (versions before 4.0.2)
- Logo Carousel Pro (versions before 2.2.0, added for list variation)
The compromise for Product Slider Pro for WooCommerce has been assigned CVE-2026-49777, carrying a CVSS score of 10.0. The overall incident has been tracked under CVE-2026-10735, with a CVSS score of 9.8. This indicates a critical vulnerability allowing for remote code execution and significant data exfiltration.
The attackers' method involved injecting a loader into the compromised plugin versions. This loader activated on every admin page, fetching a malicious payload from a remote server (194.76.217[.]28:2871). Upon retrieval, the payload would install and activate itself as a fake plugin. Once active, the malware reported the victim domain to its command and control server and then erased itself to make detection and incident response harder.
The counterfeit plugin established multiple persistence mechanisms and had several malicious capabilities, including:
- Credential Capture: Able to capture plaintext credentials and two-factor authentication (2FA) codes.
- Arbitrary File Writes: Achieved via a custom REST endpoint when provided a specific authentication token.
- Web Shell Deployment: Dropped a web shell with command execution features.
- Data Exfiltration: Used a bundled PHP file (
install-persistent.php) to extract sensitive information: - Full contents of
wp-config.php, including database credentials, authentication keys, and debug settings. - All administrator accounts with registration dates.
- Mail plugin credentials from WP Mail SMTP, Post SMTP, and Easy WP SMTP.
- WooCommerce order data from the last three months, including payment method breakdowns.
The exfiltrated data was displayed, and then the install-persistent.php file was deleted quickly to hide its activity. This attack shows the dangers of supply chain compromises, where legitimate update channels distribute malware to unsuspecting users. ShapedPlugin has confirmed the incident and is reviewing its distribution processes to ensure future product integrity, with new, secure versions expected soon.
Can Cloud Storage Buckets Be Hijacked for Data Exfiltration?
Yes, a "bucket hijacking" technique has been identified that affects multiple services across major cloud service providers (CSPs), including Google Cloud, Amazon Web Services (AWS), and Microsoft Azure. This technique exploits a fundamental architectural element-the global uniqueness of storage bucket names. While no real-world threat actors have yet been observed using this specific attack, research shows it is possible for silent, long-term data exfiltration.
The attack methodology depends on an attacker's ability to compromise a cloud environment, gain permissions to delete a target storage bucket, and then immediately recreate a new bucket with the exact same name under their own control. Because bucket names are globally unique across a given cloud provider, data streams configured to write to the original bucket will subsequently reroute critical logs and sensitive data directly to the attacker's newly created bucket. This creates a "global namespace risk" where the destination's identity is tied to its name rather than an immutable account owner.
Simulations demonstrated this technique across various cloud services:
- Google Cloud Logging: Logs configured to route to a Google Cloud Storage (GCS) bucket were redirected after the original bucket was deleted and a new one with the same name was created in an attacker's project.
- Google Cloud Pub/Sub: Messages published to a topic with a subscription linked to a GCS bucket were exfiltrated to an attacker-controlled bucket after the original was hijacked.
- Google Cloud Storage Transfer Service: Data transfer jobs between GCS buckets were rerouted to an attacker's bucket after the destination was recreated.
- AWS S3 Replication: Objects replicated from a source S3 bucket appeared in an attacker's S3 bucket after the destination was hijacked.
- Amazon Data Firehose: Data streamed to an S3 bucket via Amazon Data Firehose was similarly redirected.
- Microsoft Azure Monitor: Diagnostic settings exporting resource logs to an Azure storage account could be rerouted cross-subscription by deleting and recreating the storage account with the same globally unique name, exploiting how the internal pipeline resolves the storage account at runtime.
The required permissions for this attack, such as storage.buckets.delete in Google Cloud or s3:DeleteBucket in AWS, are often included in broad storage administration roles, increasing the practical risk. Detecting these attacks is challenging because the data stream appears to function normally from the victim's perspective, with the sink configuration remaining intact even as data flows to the attacker. Mitigations include enforcing data perimeter controls, such as AWS data perimeter policies or Google Cloud VPC Service Controls, to prevent data from leaving trusted organizational boundaries, and implementing strong monitoring for storage bucket deletion API calls, especially on high-value assets.
Technical Takeaways
- The FortiBleed leak exposed 73,932 Fortinet and FortiGate VPN credentials, including plaintext passwords, used by a Russian-speaking threat group following billions of login attempts.
- CVE-2026-35273, a critical 0-day in Oracle PeopleSoft Enterprise PeopleTools, is actively exploited in ransomware campaigns for unauthenticated remote access.
- A supply chain attack compromised ShapedPlugin WordPress Pro plugins (CVE-2026-49777, CVE-2026-10735), deploying malware that captures credentials and installs web shells.
- A "bucket hijacking" technique exploits the global uniqueness of storage bucket names in Google Cloud, AWS, and Microsoft Azure, allowing attackers to reroute data streams if they can delete and recreate a bucket with the same name, though no active exploitation has been observed.
- Over-privileged administrative roles that include bucket deletion permissions significantly increase the risk for cloud data exfiltration via bucket hijacking.
How the FortiBleed Credentials Were Exploited
The exposed FortiBleed credentials were not simply harvested — they were actively weaponized. The Russian-speaking threat group used GPU-accelerated infrastructure to crack intercepted SSL VPN authentication hashes at scale, enabling rapid network intrusion across victim organizations.
- Cracked credentials provided direct VPN access without triggering standard alerts
- Threat actors leveraged valid accounts to move laterally within corporate networks
- Compromised sessions bypassed multi-factor authentication where it was absent
- Organizations in critical infrastructure sectors faced the highest exposure risk
See also: VPN credential stuffing attack techniques and brute-force attack prevention strategies.
Affected Organizations and Global Impact
The FortiBleed dataset spans 194 countries, making this one of the broadest VPN credential exposures on record. High-profile organizations across energy, technology, automotive, and telecommunications sectors appear in the leaked data.
- Energy: Chevron and affiliated subsidiaries
- Technology: Samsung, Foxconn
- Automotive: Toyota, Mercedes-Benz
- Telecom: Comcast, AT&T
Many affected devices were confirmed to still be online at the time of disclosure, running relatively recent FortiOS versions. This suggests credentials remained valid long after initial compromise. Related reading: FortiGate firewall misconfiguration risks.
Steps to Mitigate FortiBleed Credential Exposure
Organizations using Fortinet VPN products should act immediately regardless of whether their credentials appear in the leaked dataset.
- Reset all VPN credentials and force reauthentication across all active sessions
- Enable multi-factor authentication on all FortiGate and SSL VPN interfaces
- Audit VPN access logs for anomalous login patterns or unusual geolocations
- Update FortiOS to the latest patched version and review Fortinet security advisories
- Monitor for lateral movement indicators on internal network segments
Proactive credential hygiene and zero-trust access policies remain the strongest defenses against large-scale credential harvesting campaigns like FortiBleed.