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)
Berlin ‘s government faces a Rhysida ransomware attack weeks before elections, with officials refusing to pay despite a claimed 5.79 TB data theft. Berlin’s state government confirmed this week it’s dealing with an extortion attempt following an August cyberattack on the city-state’s administrative network, and officials have already refused the requested ransom. The ransomware group Rhysida claimed responsibility on its leak site August 28, posting an entry titled simply “Berlin, Germany” and claiming 5.79 terabytes of data across roughly 1.44 million files, with personal information on 12,076 individuals allegedly included. Rhysida claims it stole 5.79 TB of data, covering around 1.44 million files. The alleged dataset includes: Personal data: 12,076 individuals, 16,389 email addresses, 11,963 phone numbers and 148 IBANs. Sensitive records: more than 5,000 personnel files, more than 5,000 administrative-offence files, payroll data and leadership information. Credentials: plaintext passwords and credentials for systems including GebäudAtlas, the ePayment PAYONE database and Z_ADMIN accounts. Government and legal material: disciplinary proceedings, court cases, supervisory documents, NDA records and Bundesrat committee protocols. Classified information: data related to classified-material handling and documents allegedly containing state secrets. Critical infrastructure: vulnerability analyses concerning Berlin’s water supply. Identity documents: passports and ID cards from personnel records. Other material: contracts, financial documents, HR records, infrastructure files, health data, password stores and SQL/PST archives. The group also claims that the material could involve violations of GDPR, German classified-information rules, criminal law and KRITIS/BSIG requirements. These are Rhysida’s claims and have not been independently verified. The timing makes this attack especially sensitive. Berlin will elect its state parliament on September 20, less than a month after the breach, so an attack on government systems just before the vote was bound to raise questions. Interior Senator Iris Spranger said the election remains secure and that, so far, the attackers haven’t taken any election-related data. Security officials support that assessment. Broadcaster RBB first reported on Thursday that Berlin had received ransom demands. “The state of Berlin will not submit to extortion,” Berlin Mayor Kai Wegner and Berlin’s interior senator, Iris Spranger, said in a joint statement on Friday, before the ransomware group claimed the attack on their Tor data leak site. That position follows long-standing advice from US federal agencies, which warn that paying a ransom doesn’t guarantee data recovery and can encourage more attacks. Saying no to the ransom is one thing; dealing with the consequences if the attackers publish the stolen data is another. Berlin first disclosed the compromise on August 17, isolating the Senate Department for Mobility, Transport, Climate Protection and Environment along with a second department from the network. Forensic investigators later found the actual data exfiltration happened earlier than the public disclosure, sometime between August 7 and August 12, with the affected department having flagged an initial outflow internally on August 7, a full week before the network got cut off. That gap between first internal detection and actual network isolation is the kind of detail that tends to get scrutinized hardest once the immediate crisis passes. Rhysida isn’t a new name to anyone tracking ransomware against government targets. The group has claimed roughly 280 victims since emerging in 2023, according to tracking services cited by Reuters, including nine in Germany alone and headline targets like the British Library and Chile’s army. Roughly half its victims sit in the US, with the UK, Canada, and Italy rounding out the next tier, a spread that suggests Rhysida isn’t picking targets based on geography so much as opportunity. A joint advisory from CISA, the FBI, and the Multi-State Information Sharing and Analysis Center, first published in November 2023, lays out exactly how Rhysida typically gets in: compromised VPN credentials at organizations without multi-factor authentication, exploitation of the Zerologon vulnerability that Microsoft patched back in 2020, and old-fashioned phishing. None of those entry points are exotic or new, which is precisely the point; Rhysida doesn’t need novel techniques when so many organizations still haven’t closed gaps that have been publicly known for years. Berlin reconnected all Senate departments to the network on August 23, but forensic teams are still checking the systems. The state’s data protection commissioner and Germany’s federal cybersecurity agency, the BSI, are following the investigation. As of publication, neither Berlin’s data protection office nor the Senate Chancellery had given specific advice to the roughly 12,000 people whose data Rhysida claims to have stolen. If you’re among them and haven’t received any official message yet, don’t assume that means you’re safe. Investigators are still working to establish exactly what the attackers accessed and took. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Rhysida Ransomware)
Multiple critical security flaws have been disclosed in WordPress plugins and themes, including WPMU DEV Dashboard, Avada, TranslatePress, Pods, and GiveWP, that could lead to authentication bypass, account takeover, and arbitrary code execution. The vulnerabilities, according to Wordfence and Patchstack, are listed below - CVE-2026-76581 (CVSS score: 9.8) - An authentication bypass flaw in
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.
A 68-year-old has been sentenced in the U.K. to more than six years in prison for operating an illegal IPTV (Internet Protocol Television) service that generated £980,812 ($1.3 million) over three years. An investigation by the Police Intellectual Property Crime Unit (PIPCU) at the City of London Police found that Milan Ibrahim ran a "sophisticated operation" that provided illegal IPTV services to users in the UK and abroad. According to PIPCU, Ibrahim sold illegal broadcasts from major rights holders such as the BBC, ITV, Sky, the Premier League and the Motion Picture Association. The police seized and shut down all servers they found during the operation, disrupting the illegal streams that users of the IPTV service received. “The investigation revealed that the business operated on 80 servers from premises in Chorley and generated £980,812 over a three-year period,” announced the City of London Police.
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)
Confirm this action.
Leaving now will discard your changes.