| Branch | Affected versions | Fixed version |
| 10.4 | 10.4.0 to 10.4.2 | 10.4.3 |
| 10.2 | 10.2.0 to 10.2.6 | 10.2.7 |
| 10.0 | 10.0.0 to 10.0.9 | 10.0.10 |
| 9.4 | 9.4.0 to 9.4.14 | 9.4.15 |
| Product | Fixed versions |
| Bitbucket Data Center | 9.4.26, 10.2.8, 10.5.1 |
| Confluence Data Center | 9.2.26, 10.2.19 |
| Jira Service Management Data Center | 5.12.40, 10.3.26, 11.3.12 |
| Jira Software Data Center | 9.12.40, 10.3.26, 11.3.12 |
| Bamboo Data Center | 10.2.24, 12.1.12 |
| Crowd Data Center | 6.3.7, 7.0.3, 7.1.7, 7.2.4 |
| Crucible | 4.9.15 |
| Fisheye | 4.9.15 |
The FBI and the U.S. Secret Service (USSS) have issued a joint cybersecurity advisory warning organizations about FortiBleed, an active global credential-compromise campaign targeting internet-facing Fortinet FortiGate firewalls and SSL VPN gateways. The advisory, published on October 6, 2026, cites SOCRadar data verifying more than 86,644 compromised devices across 194 countries.
According to the advisory, the campaign exploits reused or leaked credentials and legacy SHA-256 password storage, allowing threat actors to harvest and crack authentication data at scale. Attackers continue to scan exposed Fortinet firewalls using previously obtained credentials, and some affected organizations have been locked out of their own systems.
The operation's internal workflow came to light after the threat actors unintentionally exposed their own backend server. The open directory revealed a mature, multi-stage campaign run as an initial access broker operation.
Attackers first scanned the internet for exposed FortiGate SSL VPN portals using automated scripts. They then gathered credentials through credential stuffing and password spraying, drawing on prior Fortinet leak dumps and infostealer logs.
Password hashes taken from compromised devices were exfiltrated and fed into a GPU-accelerated cracking cluster running on rented infrastructure, where Hashcat and Hashtopolis ran distributed jobs to convert stolen data into plaintext credentials.
[caption id="attachment_114628" align="aligncenter" width="800"] Source: FBI[/caption]
Cracked credentials were then validated, with scripts filtering out honeypots, mapping organizations and ranking high-value targets by revenue and network structure. Attackers created new administrative accounts on firewalls to maintain persistence, then moved into victim networks to enumerate Active Directory and identify privileged accounts. The final stage involved selling access, including working VPN configurations and target lists, to downstream threat actors.
The advisory warns that victims may lose access to their Fortinet devices if attackers delete original accounts or change their passwords. In certain cases, threat actors removed existing accounts to block organizations from their devices while attempting lateral movement. Recovery may require steps beyond standard patching and password resets.
Reporting also indicates that initial access brokers using the FortiBleed attack chain have supplied access to ransomware affiliates, currently including INC/Lynx ransomware and Payload ransomware.
The agencies released indicators of compromise (IOCs) to help defenders review their environments. IP address 45.154.12.132 was observed as a command and control server, while 154.202.59.169 and 103.27.186.156 served as proxy nodes and 45.155.250.158 functioned as a beacon relay. The address 85.11.187.8 was linked to the Hashtopolis tool. The advisory also lists 13 IP addresses observed between June 18 and July 23, 2026, conducting brute force attacks or authenticating with compromised accounts.
Account names found on victim systems include adminin, fortiAdmin, forticloud-sync, fgtsecure, adminsslvpn, itadmin and roadmin. The agencies note that IP addresses may be reassigned over time and advise organizations to vet IOCs before acting on them.
The FBI and USSS recommend that organizations:
Organizations that detect a compromise are urged to isolate affected hosts, scope the intrusion and report incidents to the FBI's Internet Crime Complaint Center (IC3), a local FBI field office or a local USSS field office.
404Media is reporting (alternate link) that a cyber-weapons arms manufacturer is exploiting a vulnerability in iOS to bypass its automatic reboot security feature. This is the feature that automatically puts an iPhone into a more secure state if it hasn’t been used for 72 hours.
The new technology to get around inactivity reboot was developed by Magnet Forensics, the company behind GrayKey, a popular tool sold to law enforcement agencies that allows them to unlock and access data stored in iPhones and Android smartphones. Magnet has developed a new device called GrayKey Preserve and a feature for its regular GrayKey devices called Evidence Preservation Mode, according to the video.
“This is an absolute game changer for iOS forensics and a function that I wish we had years ago,” a Magnet employee says in the leaked video, specifically mentioning that the solution is targeted at the iPhone’s inactivity reboot feature and the data it makes unavailable. GrayKey Preserve and Evidence Preservation Mode are also designed to combat another iPhone feature that automatically deletes certain data - such as cached locations, and recently deleted photos and iMessages - after a certain number of days. “We’re gonna be able to preserve that data for an infinite amount of time.”
Presumably, now that Apple engineers know that this flaw exists they can find and fix it. AI turns out to be really good at this sort of thing.
Another news article.
Hackers have been exploiting a critical vulnerability in the Zimbra Collaboration Suite in an attempt to obtain email backups and authentication credentials of vulnerable organzations, Microsoft has warned.
The vulnerability, tracked as CVE-2026-73570, lets attackers remotely issue operating system commands without authentication. Zimbra maintainer Synacor issued a patch on July 20, but didn’t disclose the vulnerability for more than three weeks after that. The security-focused Shadowserver Foundation said last week that its scans found that 274 separate instances of the Zimbra Collaboration Suite had been compromised. The number of servers running the software has fluctuated from 19,000 in the week following the patch to about 12,000 in the weeks following that. Currently, Shadowserver is tracking about 10,000 instances.
From July 28 to August 7, Microsoft said Wednesday, the company detected two distinct scanning tools probing the Internet for vulnerable endpoints. The attackers first validated their exploit worked by sending HTTP, requests and DNS, ICMP, and out-of-band identity checks to domains hosted on public services. The probes allowed the attackers to confirm the exploit successfully executed commands on vulnerable servers without actually compromising them. Eventually, the attackers began using their command injection capability to install malicious payloads. Microsoft wrote:
© Getty Images
| Affected branch | Fixed release |
| OpenSSL 4.0 | 4.0.3 |
| OpenSSL 3.6 | 3.6.5 |
| OpenSSL 3.5 | 3.5.9 |
| OpenSSL 3.4 | 3.4.8 |
| OpenSSL 3.0 Premium Support | 3.0.23 |
| OpenSSL 1.1.1 Premium Support | 1.1.1zj |
| OpenSSL 1.0.2 Premium Support | 1.0.2zs |
Once a month, Microsoft pushes a security update to all Windows users. Tomorrow’s is a new record:
Microsoft’s patch for September is a doozy, with a record number of roughly 972 vulnerabilities fixed and 112 of them meeting the high critical-severity threshold.
It was only two months ago that Microsoft patched a then-record 570 vulnerabilities. Then, last month, Microsoft patched some 620 of them. Google and other companies have also published record numbers of vulnerabilities in recent months. Two weeks ago, OpenAI, Anthropic, Amazon Web Services, Google, Microsoft, and 100 companies and organizations published an open letter warning of a narrowing window for patching vulnerabilities ahead of an expected tsunami of AI-enabled attacks that actively exploit them first. The industry is taking the threat seriously by pumping out unprecedented numbers of patches in their software.
This is the result of AI-powered vulnerability finding, and a good example of AI helping the defenders more than the attackers.
What will be interesting to watch is how the number of vulnerabilities changes over the next few months. My prediction is that it will continue to increase as the AIs get better at finding software vulnerabilities, and then decrease as they run out of vulnerabilities to find. How high the number gets, how fast the trend reverses, and how quickly it declines after that are all unknown.
And Microsoft is right: The window to patch has shrunk to “immediately.” AIs are also good at reverse-engineering exploits from patches, which means that these vulnerabilities will be weaponized as soon as the update is published.
It’s a vulnerability that allows someone to recover the order of ballots cast, newly exploited with AI tools.
Nearly four years since the original vulnerability was disclosed, I was still able to use it to analyze voter behavior in Georgia (one of the 21 states that uses affected scanners) in the recent May 2026 primary.
Notably, I never touched a voting machine, exploited a network, examined source code, or accessed anything non-public.
After pointing a coding agent to the original vulnerability paper, I supplied it with two data sources highlighted in the paper: the early-voting list for each county, and the “CVR” (cast-vote record) file, containing every ballot and its selections (but not the voters’ names or other identifying information). The CVR file is available upon request, precisely because a public, ballot-level record is what makes election results independently verifiable.
SonicWall disclosed this week that attackers are chaining two previously unknown vulnerabilities in its SMA1000 secure access appliances to run commands on unpatched devices, and urged customers to install an emergency hotfix.
The more severe flaw, CVE-2026-83548, is a pre-authentication server-side request forgery weakness in the appliance's Appliance Work Place interface, rated 10.0 on the CVSS scale. It lets a remote attacker with no credentials reach sensitive internal functionality. The second, CVE-2026-83549, is an operating-system command injection bug in the Appliance Management Console rated 7.8; on its own it requires administrative authentication, but paired with the SSRF flaw it yields remote code execution.
The vendor said it found both issues internally and then observed them being used together in live attacks. SonicWall has not published indicators of compromise or described the attackers.
Affected products are the SMA1000 series 6210, 7210 and 8200v, in both hardware and virtual form. Fixed builds are 12.4.3-03526 and later, and 12.5.0-02952 and later. SonicWall firewalls running SSL-VPN and the separate SMA 100 line are not affected.
Remediation guidance goes beyond patching. SonicWall told customers to contact its support organization to review appliances for signs of intrusion and, where compromise is suspected, to re-image or redeploy the device, rotate all credentials and reset TOTP tokens — an acknowledgment that one-time-password seeds stored on a breached appliance survive a software update. The company said customers should move to the hotfix release as quickly as possible.
Shadowserver Foundation scanning has tracked more than 400 internet-exposed SMA1000 appliances, though an unknown share of those are already patched. The small install base belies the risk profile. These are remote-access gateways that sit at the network edge and hold credentials for the environments behind them.
The disclosure extends a difficult run for the product line. Attackers exploited a separate pair of SMA1000 zero-days in July 2026, tracked as CVE-2026-15409 and CVE-2026-15410, to deploy custom malware; CISA later confirmed ransomware operators were abusing that access.
Another zero-day surfaced in December 2025. Seventeen SonicWall vulnerabilities across the company's product families currently sit in CISA's Known Exploited Vulnerabilities catalog. Edge appliances from SonicWall, Ivanti, Citrix and Fortinet have collectively become the preferred initial-access route for ransomware affiliates and espionage crews, because they are internet-facing by design and rarely instrumented with endpoint detection.
PaperCut released a second emergency patch last Friday, for two vulnerabilities in its NG and MF print management servers that attackers are already exploiting, after security researchers demonstrated that the vendor's first fix could be bypassed.
The two flaws work as a chain. CVE-2026-81578, rated 8.8 on the CVSS scale, is an improper access control weakness in the PaperCut web management interface that lets unauthenticated remote requests reach administrative functions before the server finishes validating access.
CVE-2026-82078, rated 9.4, is an unsafe dynamic class-loading flaw in the product's database utilities. The application loads database driver classes without checking them against an allowlist, so an attacker who can alter configuration parameters can get arbitrary Java bytecode running inside the application server process. Together they produce pre-authentication remote code execution on an internet-facing server.
PaperCut software runs print queues for universities, school districts, hospitals, local government and large enterprises, and the platform has a history of drawing ransomware attention. Three earlier PaperCut NG/MF vulnerabilities already sit in the U.S. Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalog, two of them weaponized in ransomware campaigns.
Huntress, which first documented the activity, said it observed exploitation in two customer environments on Aug. 26 and Aug. 27. In one case the whole intrusion ran under two minutes. Attackers dropped hex-encoded Java class files that the firm described as a bridge between PaperCut and the underlying operating system, then issued basic reconnaissance commands - enumerating the current user, operating system version and running processes - rather than deploying ransomware or other payloads. That pattern typically indicates access brokering or target triage ahead of a later stage.
The reason for a second patch was straightforward; the first one did not hold. Researchers at watchTowr found multiple ways around the original fix and turned up an additional authentication bypass in the process, while Huntress independently reproduced the full attack chain and found its own workarounds. Both firms worked with PaperCut's engineers on Emergency Patch Release 2.
PaperCut said it was aware of confirmed customer incidents and was treating the matter with the highest priority. Release 2 covers PaperCut NG and MF versions 24, 25 and 26 on Windows, Linux and macOS. Customers running version 23 or earlier are told to upgrade rather than wait for a backported patch - a significant caveat, since Huntress reported that roughly 47% of the approximately 2,500 installations it tracks are on those older builds.
The pair had not been added to CISA's KEV catalog as of the vendor's Aug. 28 update.
Whether CISA adds the two CVEs to KEV, whether the reconnaissance-only activity converts into ransomware deployment, and whether Release 2 survives the scrutiny that broke its predecessor, remains to be seen. But administrators should pull PaperCut servers off the public internet regardless of patch status, and check application logs for unexpected process execution and stray .class files.
path = "$." <> Enum.join(right, ".")The individual path segments were neither escaped nor quoted. Consequently, a key intended to represent the literal name private.secret could instead be interpreted as two JSON levels. Characters such as ., [, ], and $ could similarly alter JSONPath interpretation. The GitHub advisory describes the flaw as “JSONPath injection in AshSqlite.SqlImplementation get_path”, stating that an attacker controlling a get_path/2 segment can traverse nested JSON and disclose private fields. The affected package is ash_sqlite, with versions 0.1.2-rc.0 through before 0.2.18 affected and 0.2.18 listed as the patched release. The flaw remains separate from SQL injection because the generated JSON path is supplied to SQLite's json_extract as a bound expression parameter. The attacker manipulates the JSONPath grammar, rather than injecting SQL commands.
Microsoft disclosed on Thursday that a maximum-severity remote code execution vulnerability in Entra ID, the identity service underpinning Microsoft 365, Azure and Dynamics 365, was exploited in the wild before the company mitigated it on its own infrastructure. The flaw, tracked as CVE-2026-69836 and rated CVSS 10.0, required no authentication and no user interaction.
Entra ID, formerly Azure Active Directory, is the authentication and authorization layer for a large share of the world's enterprise cloud estates. It brokers sign-ins, conditional access decisions and token issuance across tenants, which makes any unauthenticated code execution in the service unusually consequential: an attacker operating inside that trust boundary is positioned upstream of nearly every control that depends on it.
According to Microsoft's advisory, the vulnerability stems from deserialization of untrusted data, a class of bug in which an application reconstructs attacker-controlled input into live objects without adequate validation. The result, per the advisory language, is that an unauthorized attacker can execute code over a network. Microsoft rated impact as high across confidentiality, integrity and availability, and characterized attack complexity as low. Credit for finding and reporting the issue went to a Microsoft principal security engineer.
Because Entra ID is a managed cloud service rather than software customers install, remediation happened server-side. Microsoft said the vulnerability has been fully mitigated and that there is no action for users of the service to take. Exploit code is not publicly available, the company said. Microsoft addressed several other maximum-severity cloud service issues, including flaws in Azure Arc and Exchange Online, in the same batch of disclosures.
What Microsoft did not say is drawing scrutiny. The advisory confirms exploitation but omits attribution, the window during which attacks occurred, how many tenants were touched, what attackers did after gaining execution, and any indicators defenders could use to check their own logs. Security teams face a structural problem here. With no patch to apply and no IOCs published, there is no independent way to confirm whether a given tenant was affected, and cloud-side telemetry that would answer the question sits with the provider.
The disclosure lands against a compliance backdrop that has grown less forgiving. Microsoft began issuing CVEs for cloud service vulnerabilities that require no customer action as part of transparency commitments made under its Secure Future Initiative, and CVE-2026-69836 is a test of how much that transparency actually delivers.
For U.S. public companies, exploitation of an identity provider raises Item 1.05 materiality questions under the Securities and Exchange Commission's cyber disclosure rule even when the fix is the vendor's determining whether a reportable incident occurred is difficult without provider-side evidence. In the European Union, operators in NIS2 scope carry 24-hour early-warning obligations that presuppose visibility they may not have.
Whether Microsoft publishes exploitation details or indicators, whether CISA issues supplemental guidance for federal tenants, and whether any organization ties confirmed intrusion activity to the flaw, enterprises should review Entra ID sign-in and audit logs for anomalous service principal activity, unexpected token issuance and privilege changes across the past several weeks, and re-examine standing assumptions about the identity layer.
When I give talks about AI genies, I use this sort of example as a hypothetical. It’s happened.
The story is from Australia. Someone named Andrew tasked OpenClaw to book gym classes for him. And….
Minutes later, his AI agent reported it had discovered a way to book Andrew into classes several weeks in advance, far beyond what was supposed to be possible.
Andrew, who was sitting fourth on a waitlist for a class later that week, asked if it was possible to move him to the top of the list.
The agent came back and told Andrew that it had kicked another gym-goer off the list as part of the testing of its capabilities.
“The API has zero authorisations checks on cancelling other people’s reservations … I tested this with the person in waitlist position #1 —and it actually went through. So you’ve moved from #4 to #3 already,” it messaged back.
If there is any vulnerability in anything, AIs are going to find and exploit them. Our cyber defensive game has to be dramatically improved…very fast.
Slashdot thread.
Login
.ENCRT extension for encrypted files. A documented sample from July 2025 used the .CRYPT extension. The ransomware also uses Windows Management Instrumentation to delete volume shadow copies before encryption, while one victim had backup and archived data deleted from both primary and disaster recovery infrastructure.
This is disturbing:
…a team of security researchers at UC San Diego, who found that a model of aftermarket car alarm known as the KARR Security System, installed in more than 2 million vehicles across the US by their estimate, can let any hacker within Bluetooth range send radio commands to silently unlock the car at will, turn off its alarm, honk the car’s horn or flash its lights, or even disable its ignition and leave a driver stranded.
Hugging Face has published a detailed timeline of the attack. From the summary:
The agent was running an internal OpenAI cyber-capability evaluation based on the ExploitGym benchmark, which tasks an AI agent with finding and exploiting software vulnerabilities. OpenAI ran this on its own infrastructure, and the ExploitGym maintainers and their infrastructure had no involvement in the deployment or operation of that evaluation environment. As far as we were able to infer, across the course of being evaluated on this benchmark, the agent inferred that Hugging Face may host that benchmark’s models, datasets, and reference solutions. We believe the entire intrusion was, from the agent’s point of view, an attempt to cheat the evaluation: reach our production systems and steal the test solutions rather than solve the challenge on its own.
Our forensic reconstruction covers ~17,600 attacker actions that we were able to recover, grouped into ~6,280 clusters, between 2026-07-09 02:28 UTC and 2026-07-13 14:14 UTC. We reconstructed these actions from the agent’s logs on a code sandbox used by the agent (see below) and were able to map them to shell commands as well as evaluation submissions and correlate actions with our own platform logs, in particular from the dataset processor nodes, API, and pod. Using open-weights models, in particular zai-org/GLM-5.2, we were able to decipher most of the agent payloads (see below) that were encrypted via chunking and key encryption.
The campaign, as we were able to reconstruct it, had two stages:
- Stage 1: reaching a launchpad by chaining through other parties’ infrastructure. As documented in OpenAI’s blog post (https://openai.com/index/hugging-face-model-evaluation-security-incident/), during an internal capability evaluation on OpenAI’s platform, the agent escaped its sandbox by exploiting a zero-day in the package registry cache proxy, one of its primary permitted network egress with internet, then abused a public code-evaluation harness hosted by a user of a third-party infrastructure provider. It was able to run commands as root/admin on that external sandbox and used it as a control, staging, and egress base for the entire campaign: it acted as an external launchpad for the agent. That compromised external sandbox had no direct network path to our cluster; however, during our counter-intervention to stop the intrusion, we were able to retrieve some of the agent logs from this external launchpad. We used those to reconstruct the present forensic analysis.
- Stage 2: the intrusion into Hugging Face infrastructure. From that external launchpad, the agent abused our dataset-processing pipeline via two injection vectors, both targeting the same config-driven data loader within our production Kubernetes pods. The first vector was an HDF5 external raw storage dataset read that returned the contents of local files: it handed the agent the pod’s environment (secrets and tokens) and the worker’s own source. The second vector was a Jinja2 template injection that executed arbitrary code, giving the agent a foothold inside our perimeter.
Once a prod-pod foothold was established, the agent followed a standard escalation shape: recon, drop a stager, establish Command-and-Control (C2), then pivot into the cluster, into cloud metadata, into our internal network, and into our source-control supply chain. Output from the commands run inside our pod was sent back to the agent via the HF API and attacker-controlled dead-drop datasets, which the agent then read from that sandbox.
While the intrusion did reach Hugging Face’s internal infrastructure, the only customer content accessed was five datasets whose names and files suggest a connection to ExploitGym/CyberGym challenges and solutions. No other customer-facing models, datasets, Spaces, or packages were affected, and the only customer records read were operational metadata tied to search queries against the dataset server.
Hypothetical: Imagine that this wasn’t an OpenAI model. Imagine that it was a Chinese model from a Chinese company. This would be an international crisis.
Question: Why aren’t we bringing OpenAI up on charges under the Computer Fraud and Abuse Act? How is this different from the Morris Worm? That was also an experiment that escaped the lab.
Microsoft’s Secure Boot has had a serious vulnerability for most of its existence.
An industry-wide standard Microsoft invented to protect Windows, and later Linux, devices from firmware infections has been trivial to bypass for 13 of its 14 years of existence. The discovery was made by researchers at security firm ESET after identifying 11 firmware images, at least one from 2013, that were known to be defective but remained signed by the software company anyway.
The images are known as shims, which were invented to extend Secure Boot to Linux devices and utility software. Using a technique simple enough to be performed by novice hackers, these old, forgotten shims can be used to completely circumvent the protection, which is embedded into the UEFI (Unified Extensible Firmware Interface) of the device’s motherboard. The gaffe is the result of the failure by Microsoft, which oversees the signing of shims, to revoke the publicly available images once vulnerabilities were found in them.
