A researcher chained two Unitree G1 flaws to gain root access remotely and showed how a compromised robot could attack others nearby. Security researcher Olivier Laflamme spent about three months digging into the Unitree G1 humanoid robot and eventually found a way to fully compromise it without plugging in a single cable. In his technical write-up, he details two vulnerabilities, CVE-2026-76639 and CVE-2026-76640, that can be chained across Bluetooth, Unitree’s cloud infrastructure, the mobile app, and the robot’s firmware to gain unauthenticated root access to any G1 within Bluetooth range. The first bug lives entirely inside the robot itself, no wireless attack surface needed if you can reach it over Ethernet. The G1’s AI chatbot service accepts a “knowledge” upload with almost no validation on the filename it writes to disk, and a classic path traversal payload lets an attacker write an arbitrary file anywhere on the filesystem, including into a directory that a separate service called bashrunner treats as trusted. Restart bashrunner, tell it to run the newly planted file, and you’ve got root-level shell execution with five DDS messages and zero authentication. The second chain is the one that should worry anyone deploying these robots at scale. It starts with a Bluetooth characteristic that accepts writes without pairing, something The Hacker News also covered in its own report on the disclosure. An unpaired device can request the robot’s encrypted key bootstrap blob, and Unitree’s cloud API would decrypt that blob for any free, logged-in Unitree account without ever checking whether the account actually owned that specific robot. “The blob is RSA-encrypted & the corresponding RSA private key is held by Unitree’s cloud infrastructure. This, in theory, is safe.. This is the security boundary Unitree appears to have relied on. Nearby devices can request the bootstrap blob, but only Unitree owns the RSA private key capable of opening it.” reads Laflamme’s report. “However, the Unitree mobile app reassembles the BLE notification chunks and slingshots that shit via a POST to Unitree’s cloud API /device/bindExtData on global-robot-api.unitree.com and the app stores the response body as gcmKey.” That decryption oracle is the crux of the whole chain, and Laflamme doesn’t undersell how convenient it made everything. “This single AES-128 key unlocks both the BLE protocol and the WebRTC signaling channels.” continues the report. Once an attacker has obtained it, they can authenticate to the robot’s Bluetooth handshake and unlock WiFi configuration commands that were previously locked behind that same key. From there, an oversized WiFi password triggers a fallback code path in Unitree’s own configuration script that inserts attacker-controlled text directly into a config file without escaping it, letting the attacker force the robot to join a hotspot they control, no physical access needed at any point. Going from “the robot connects to my Wi-Fi” to a full root shell required a buffer overflow in the G1’s Bluetooth server, and this is where the research gets particularly impressive. The server used a 500-byte buffer without proper bounds checking, allowing Laflamme to overwrite nearby memory with a carefully crafted 1,050-byte payload. He used that payload to create a fake cleanup structure that the program later interpreted as a legitimate function pointer, causing it to execute an attacker-controlled command with root privileges. There was one more obstacle: randomized memory addresses. To make the exploit work reliably, Laflamme first needed to discover where the vulnerable program was loaded in memory. He solved that by turning the first vulnerability into an information leak and using the result to make the second exploit work. In other words, one bug effectively helped unlock the other. The wormability is what turns this from an interesting security flaw into a much more serious operational risk. Once an attacker compromises one G1, that robot can use the same attack against other G1 robots within Bluetooth range, without requiring additional discovery or configuration. Laflamme tested the technique on just two robots in the same room, so the real-world reach of a chain reaction remains unclear. In a warehouse, laboratory, or campus where dozens of these robots operate close to each other, however, the possibility of one compromised machine spreading the attack to others is difficult to ignore. Unitree’s response gets genuine credit in the writeup, and it’s worth noting given how often vendor disclosure stories go badly. The company patched the cloud ownership-check flaw within about two months of the report, paid out a combined $5,000 bounty across both chains, and worked through verification quickly enough that Laflamme calls the collaboration close to ideal. “July 1-6 August, 2026 — Unitree implemented an account-to-robot cloud binding ownership check before returning the AES-128 key. Patching the “cloud-oracle” vulnerability discovered back in May. “August 6, 2026 — a $5,000 USD bounty was paid out, $4,000 for the BLE RCE and $1,000 for the chat_go RCE.” The BLE pairing and buffer overflow issues themselves, notably, sit deeper in the firmware and represent a harder, slower fix than a simple cloud-side ownership check. None of this required exotic tools or some cutting-edge attack technique. That is probably the detail that should get the most attention from anyone who still sees robot security as a niche problem. This was a $20,000 humanoid robot, the kind increasingly used in research labs and universities and likely to appear in more workplaces, compromised with a decompiled Android app, a firmware encryption scheme that researchers had already broken years ago, and a familiar class of buffer overflow that predates humanoid robots by decades. If your organization has a G1 sitting in a lab, lobby, or workspace, checking its patch status should be a priority. A 90-pound robot losing its collision-detection capabilities is not the kind of security incident you want to discover the hard way. “You could use the G1 to spy on people through audio and video, make it say obscene shit in public, swap out or backdoor the ResNet onboard AI models, tamper with perception and movement logic, disable collision detection and other safety checks (it weighs ~90lbs having that run into a kid, a wall, or even step on your toe will do some serious damage).” concludes the researcher. “They also cost a lot! I’d be pissed off if someone hacked into my G1, took control of it, and walked it off my factory/campus.” Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Robot)
Healthcare and pharmaceutical distribution giant McKesson has disclosed a cybersecurity incident involving unauthorized access to third-party applications and data theft, with the ShinyHunters extortion group claiming it stole 284 million patient data records.
New research reveals that AI safety refusal lives in a thin neural layer, highlighting the critical need for external, multi-layered security. The post Perturbation Probing: A New Diagnostic for the Fragility of LLM Safety appeared first on Unit 42.
Love Electric’s alleged data breach exposes sensitive driver data and highlights the identity risks created by third-party salary sacrifice providers. A seller on an English-language data-breach forum claimed on August 26 that they had obtained the driver database of Love Electric, a UK broker that runs electric-vehicle salary sacrifice schemes. The seller, operating under the name “seraphims”, offered 877,000 records for $600 in cryptocurrency, with the price negotiable. That headline number needs a qualification. Ransomnews researchers examined a 999-row sample published with the listing and found strong evidence that the sample came from a genuine production database, but the claimed 877,000 records remain unverified. Love Electric had been contacted for comment at the time of publication. “The 999 rows split into 731 primary drivers and 268 additional named drivers. There are exactly 731 distinct quote IDs, and every quote has exactly one primary driver, 731 out of 731. All 268 additional drivers reference a quote that exists in the file, with no orphans.” reads the Ransomnews’s report. “The consent flag governing National Insurance processing is empty for precisely the 268 additional drivers and populated for every one of the 731 primary drivers. National Insurance numbers appear on primary drivers only. Those are constraints enforced by whatever application wrote the data, and they hold across all 999 rows without exception.” That matters because fabricated breach databases often fall apart when researchers examine the relationships between records. Here, the relationships hold: additional drivers point to existing quotes, the National Insurance processing flag appears where the underlying application logic would expect it, and National Insurance numbers appear only on primary drivers. Love Electric Financial Services Limited is an Edinburgh-based company that provides EV salary sacrifice administration, credit broking and related services to employers across the UK. Companies House identifies it as an active Scottish company, registered under number SC374952, while Love Electric’s own documentation confirms that it operates as a salary sacrifice administrator and FCA-regulated credit broker. The business model explains why its systems can contain information that many people would normally associate with payroll departments. Salary sacrifice arrangements require the broker to identify employees, process the scheme and support insurance and tax-related requirements, so the underlying records can include National Insurance numbers and driving licence information. Love Electric’s privacy policy also says it processes personal information under UK data protection law. “The seller published a free sample as a 999-row CSV with 24 columns, named in a way that indicates an export of a dbo.drivers table from a Microsoft SQL Server database.” continues the report. “The columns are: id, quote_id, user_id, title, first_name, last_name, email, phone_number, date_of_birth, address, address2, city, country, postcode, national_insurance_number, driving_licence_number, driving_licence_country, allow_processing_national_insurance, primary, created_at, updated_at, deleted_at, weekly_hours and occupation_id.” The fields included names, email addresses, phone numbers, dates of birth, addresses, postcodes, National Insurance numbers, driving licence numbers, quote IDs and consent-related fields. The data wasn’t uniformly populated, which is another reason the sample looks like a real production export rather than a synthetic dataset. Around 71% of the rows lacked a name, address or city, 74% had no phone number, and 85% had no National Insurance number, while 147 records contained a National Insurance number and 287 contained a driving licence number. The geography also made sense. Postcodes clustered around Edinburgh and central Scotland, with records extending into England, while dates of birth ranged from 1946 to 1999 and concentrated around people born in the 1970s and 1980s. Ransomnews then tested the driving licence numbers against the structure used by UK licences. Of the 108 full-length licence numbers in the sample, 98.1% had a surname block matching the surname in the corresponding record, 97.2% had an initial matching the first name, and 78.7% contained a date-of-birth encoding that matched the stored date of birth. The imperfections were just as interesting. Licence numbers appeared in many different lengths, only 53% of the National Insurance numbers present matched the expected HMRC format, and phone numbers appeared in three different formats. That kind of mess is exactly what you’d expect from users entering information into a live form, abandoning fields or making mistakes. “A UK driving licence number is not random. Characters one to five are the holder’s surname padded with the digit 9, characters six to eleven encode the date of birth with 50 added to the month for female holders, and character twelve is the first-name initial. Of the 108 full-length licence numbers in the sample, 98.1% have a surname block matching the record’s own surname field and 97.2% have an initial matching the first-name field. 78.7% carry an encoded date of birth matching the date_of_birth column.” state the researchers. “The roughly one in five that disagree are consistent with people mistyping a sixteen-character string into a web form, which is exactly the error rate real self-reported data carries and synthetic data does not.” The email addresses provided another useful check. Most belonged to corporate domains associated with identifiable UK employers, Love Electric itself or a European software consultancy, rather than being dominated by Gmail and other consumer providers. That fits the way workplace salary sacrifice schemes operate because employees generally enter through their employer. The database structure also looked normal. It included a soft-delete field, integer foreign keys for quotes and occupations, regional values for Scotland, England, Wales and Northern Ireland, and even a Jane Doe test record that appears to have survived from the system’s setup. Real databases leave fingerprints like these. Synthetic ones tend to be suspiciously tidy. The seller’s own history is less convincing than the database evidence. The “seraphims” account was created on July 22, 2026 and had published nine data listings by August 26, roughly two per week, but several of those listings were described by the seller as scrapes rather than breaches. The Love Electric listing had attracted no replies and only 52 views when Ransomnews checked it. The account’s reputation score of 30 came from a single positive vote posted on August 17 with the comment “keep scrapping”, which says more about the seller’s scraping activity than about a track record of selling verified breach data. That doesn’t make the Love Electric sample fake. The technical evidence points in the opposite direction. It does mean we should separate two questions: whether the sample appears genuine, and whether the seller really controls 877,000 records. The second claim is much harder to establish. Ransomnews saw only 0.11% of the alleged dataset, and the sample shows that database rows don’t map directly to individual people. The 999 rows corresponded to 731 quotes and only 58 distinct surname-and-date-of-birth combinations, with one person appearing 48 times. There’s another clue in the filename. The db2_ prefix suggests that the table may belong to one database among several, so the seller’s 877,000 figure could refer to a larger collection rather than this particular driver table. At this point, treating 877,000 as a confirmed number would go beyond the evidence. The timeline also deserves caution. The seller claimed an August 2026 attack involving a zero-day in a third-party system, but every sample row carries a created_at timestamp within a six-second window on August 14, 2022. That pattern looks like a bulk migration into a newer platform rather than 999 people signing up within six seconds. It tells us that the database contains legacy records. It doesn’t tell us when someone took them, how they obtained them or whether the seller’s claimed zero-day played any role. That last point matters for incident response. “Third-party zero-day” is a claim made by the seller, not an established fact, and attackers have plenty of reasons to make an access story sound more sophisticated than it was. Ransomnews says it has not verified that route. For the people potentially affected, the more immediate issue is the nature of the exposed information. A password can be replaced. A National Insurance number and a driving licence number can’t simply be rotated because someone has posted them for sale. That creates an obvious phishing risk. Someone who has a person’s name, date of birth, address, employer and National Insurance number can construct a much more convincing message pretending to be HMRC, a payroll team, an employer or a vehicle leasing provider. Drivers who used Love Electric should therefore treat unexpected messages about their vehicle scheme, payroll or tax affairs with suspicion. They should verify the sender through a phone number or website they already trust rather than using contact details contained in the message. Love Electric’s current public material says it works with more than 1,500 companies, which gives some sense of the scale of the service’s employer-facing footprint. That makes supplier security worth treating as an operational issue rather than a procurement checkbox. If a third-party provider holds National Insurance numbers, driving licence numbers, employment information and contact data, its security controls deserve the same level of scrutiny as any other system handling high-value identity information. The seller’s alleged third-party entry point is therefore worth investigating, but it shouldn’t become the centre of the story before someone verifies it. The useful evidence is already sitting in the sample: a production-style schema, consistent relationships, realistic user errors and identifiers that line up with real-world records. The other important detail is the price. $600 for a database containing National Insurance and driving licence numbers isn’t a serious valuation of the data. It’s a price designed to make a quick sale. And if the seller really has more than the published sample, multiple buyers could obtain the same information. That’s where the risk gets worse: the exposure doesn’t end with the first person who downloads it. Ransomnews says it did not access or probe Love Electric’s systems, purchase the full dataset, or validate the exposed identifiers against live services. It analysed the free sample, removed identifying information from its publication and notified Love Electric before publication, offering to share the listing and sample with the company’s incident-response team. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, data breach)
PaperCut has released a second emergency security update for two actively exploited vulnerabilities in its PaperCut NG and MF print management software after researchers discovered multiple ways to bypass the initial fixes. As BleepingComputer reported yesterday, PaperCut warned that hackers were exploiting a vulnerability in zero-day attacks against customer servers and released an initial emergency patch for PaperCut NG/MF versions 25 and 26. At the time, however, the company had not disclosed CVE identifiers or technical details about the vulnerabilities, saying it was withholding information while it investigated the attacks and gave customers time to apply emergency fixes. PaperCut has now shared technical details and CVE identifiers for the two vulnerabilities, tracked as CVE-2026-82078 and CVE-2026-81578. These vulnerabilities can be chained to bypass authentication and execute code on vulnerable servers.
AI is accelerating vulnerability discovery, putting pressure on systems built to enrich, prioritize, and remediate flaws at a slower pace. Action1 explains why defenders increasingly need to correlate multiple intelligence sources and turn vulnerability data into faster remediation.
U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds ownCloud, Linux Kernel, and JFrog Artifactory flaws to its Known Exploited Vulnerabilities catalog. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the following vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog: CVE-2023-49105 ownCloud Improper Authentication Vulnerability CVE-2026-53362 Linux Kernel Unspecified Vulnerability CVE-2026-66384 JFrog Artifactory Improper Limitation of a Pathname to a Restricted Directory Vulnerability CVE-2023-49105 (CVSS score of 9.8) is an improper-authentication flaw in ownCloud Server’s WebDAV functionality. An unauthenticated attacker who knows a victim’s username can read, alter, or delete that user’s files when no signing key is configured, because the application can accept pre-signed URLs without properly validating that condition. The issue affects ownCloud core versions 10.6.0 through 10.13.0, before version 10.13.1. Organisations running affected ownCloud instances should treat remediation as urgent, review exposed WebDAV services, and investigate unusual file access, deletion, modification, or downloads. CVE-2026-53362 (CVSS score of 7.8) is an out-of-bounds memory-write vulnerability in the Linux kernel’s IPv6 networking subsystem. A local attacker who can create UDP sockets could exploit an incorrect parameter-length calculation during fragmented IPv6 packet handling to overwrite kernel memory, potentially causing a system crash, corrupting data, or escalating privileges.access. Shortly after the Hugging Face incident became public, OpenAI said its models had identified and exploited a zero-day vulnerability in JFrog’s Artifactory package registry manager. The report also describes a separate incident on July 19. In that case, some AI agents exploited the Linux kernel vulnerability, CVE-2026-53362, to gain higher privileges inside an OpenAI environment. The agents detected that the Linux kernel on their machine was vulnerable, found a public exploit, modified it to work in their environment, and used it to gain root access to the underlying worker node. This allowed them to escape the Artifactory container and move laterally to other parts of the connected environment. CVE-2026-66384 (CVSS score of 5.3) is a path-traversal vulnerability in JFrog Artifactory’s Docker cache handling. Under specific remote-repository conditions, an authenticated user can manipulate a file path and write data outside the intended cache directory, potentially affecting other locations on the Artifactory host. According to Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, FCEB agencies have to address the identified vulnerabilities by the due date to protect their networks against attacks exploiting the flaws in the catalog. Experts also recommend that private organizations review the Catalog and address the vulnerabilities in their infrastructure. CISA orders federal agencies to fix the flaw CVE-2026-66384 by September 10, while the remaining must be addressed by August, 30, 2026. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, CISA)
Over 8,300 Internet-exposed Gitea instances are still unpatched against a critical security flaw exploited in ongoing remote code execution attacks, according to cybersecurity watchdog Shadowserver. The code injection vulnerability (CVE-2026-60004) targeted in these attacks was reported by Salesforce security researcher Shai Rod, and it allows authenticated attackers to execute arbitrary shell commands with the privileges of the Gitea service account by submitting malicious patches via the diffpatch API endpoint. While successful exploitation requires repository write access to repositories hosted on vulnerable servers, Gitea comes with self-registration enabled by default, allowing unauthenticated attackers to register an account, create a new repository, and trigger the vulnerability without prior credentials.
Microsoft released the KB5120998 preview cumulative update for Windows 11 versions 25H2 and 24H2, which comes with 35 changes, including improvements to the Start menu, taskbar, and Windows search. KB5120998 is a preview update that lets IT administrators test Windows bug fixes, improvements, and new features before they roll out to all users during next month's Patch Tuesday release. However, unlike cumulative updates, monthly optional updates do not include security fixes and provide only quality improvements. After installing the August 2026 preview update, users can move the taskbar to the bottom, top, left, or right side of their screen in Settings > Personalization > Taskbar > Taskbar behaviors > Taskbar position, with most customization settings, like never combining taskbar icons, working in every position.
U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds Red Hat, Linux Kernel, Ajax.NET Professional, Microsoft SQL Server, and Citrix NetScaler flaws to its Known Exploited Vulnerabilities catalog. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the following vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog: CVE-2015-3246 Red Hat Libuser Race Condition Vulnerability CVE-2015-5287 Red Hat Automatic Bug Reporting Tool Privilege Escalation Vulnerability CVE-2019-1068 Microsoft SQL Server Remote Code Execution Vulnerability CVE-2021-23758 Ajax.NET Professional Deserialization of Untrusted Data Vulnerability CVE-2022-0995 Linux Kernel Out-of-Bounds Write Vulnerability CVE-2026-8452 Citrix NetScaler ADC and NetScaler Gateway Improper Restriction of Operations within the Bounds of a Memory Buffer Vulnerability CVE-2015-3246 is a race condition in Red Hat libuser that could let an authenticated local user corrupt /etc/passwd to cause denial of service or escalate privileges. CVE-2015-5287 is a privilege escalation bug in Red Hat Automatic Bug Reporting Tool that could allow local users with certain permissions to gain higher privileges via a symlink attack on a predictable file. CVE-2019-1068 is a remote code execution flaw in Microsoft SQL Server that could allow an attacker to execute code in the context of the SQL Server Database Engine service account. CVE-2021-23758 (CVSS score not specified in the KEV notice) is a deserialization of untrusted data vulnerability in Ajax.NET Professional that could allow for remote code execution via arbitrary .NET classes. CVE-2022-0995 (CVSS score not specified in the KEV notice) is an out-of-bounds memory write vulnerability in Linux Kernel that could allow a local user to gain privileged access or cause a denial of service on the system. CVE-2026-8452 (CVSS score not specified in the KEV notice) is an improper restriction of operations within the bounds of a memory buffer vulnerability in Citrix NetScaler ADC and NetScaler Gateway that could lead to denial-of-service and has been observed under active exploitation in the wild. According to Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, FCEB agencies have to address the identified vulnerabilities by the due date to protect their networks against attacks exploiting the flaws in the catalog. Experts also recommend that private organizations review the Catalog and address the vulnerabilities in their infrastructure. CISA orders federal agencies to fix the flaws CVE-2019-1068 and CVE-2026-8452 by August 29, 2026, while the remaining must be addressed by September 9, 2026. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, CISA)
Confirm this action.
Leaving now will discard your changes.