Severity Daily

IT and AI security incidents, checked against the primary source

Tag: IoT

  • The Justice Department edited its China hacking announcement to say seven agencies were targets, not victims

    The Justice Department edited its China hacking announcement to say seven agencies were targets, not victims

    The August 26 release named NASA, the Federal Reserve, and the Senate as victims of QTFY. Two days later it said they were among the targets, and the original sentence is gone.

    The Justice Department announced on Wednesday, August 26, 2026, that it and the FBI had seized the domains behind two hacking platforms run by a China state-sponsored group it tracks as QTFY. The release named seven federal bodies, and as originally published it described them as victims. On Friday, August 28, 2026, the department rewrote that description. The seven are now “among the targets of QTFY.”

    The page carries an “Updated August 28, 2026” stamp and a one-line editor’s note: “Edits have been made to ensure this press release accurately reflects the government’s allegations in the affidavit in support of the domain seizures.” The note does not say which sentence changed, and the original wording is not preserved anywhere on justice.gov. What the release said on August 26 is known from contemporaneous reporting by the Associated Press, not from the department.

    What happened

    The seizure itself is not in dispute. According to the release, the department obtained court authorization in the Southern District of California to seize domains hard-coded into two tools: QScan, which “automatically scans and infects thousands of internet-of-things devices” worldwide, and QTRouter, an obfuscation network that let operators “conceal the PRC-origin of their computer intrusion activities because the malicious communications appear to originate from computers … that are outside of the PRC.” Because the seized domains were used by both tools for communication and authentication, the department says taking them rendered the platforms inoperable.

    QTFY is described as employed by Nanjing Xinjiuwei Network Technology Company, which the government alleges “offers computer hacking services to its paying customers, including the PRC’s Ministry of State Security and the People’s Liberation Army.” Attorney General Todd Blanche is quoted saying, “State-sponsored malicious hackers preying on America’s critical infrastructure will be stopped.” FBI Director Kash Patel is quoted saying the operation “seized adversary infrastructure and shut these platforms down.” The FBI’s San Diego Field Office and Cyber Division, the U.S. Attorney’s Office for the Southern District of California, and the National Security Cyber Section of the Justice Department’s National Security Division ran the case.

    The sentence that changed is the one that matters to anyone building a risk picture. The current text reads: “Among the targets of QTFY are the National Aeronautics and Space Administration, Federal Reserve, Department of Energy, Department of Justice, Department of Health and Human Services, National Institutes of Health, and the U.S. Senate.”

    The Associated Press, which first reported the change, wrote that the August 26 version described all seven as victims, and that the department said the affidavit made clear all were targeted while only some were compromised. Severity Daily could not verify the original sentence against a primary source: the department replaced it in place, and the affidavit supporting the seizures is not published alongside the release. AP also reported an affidavit footnote stating that the attempted breach of NASA was unsuccessful because the agency had patched the software being targeted. That footnote is the only specific outcome for any of the seven that has surfaced publicly, and it reached the public through a reporter reading a court filing rather than through the announcement.

    AP reported that the FBI and CISA did not immediately respond to requests for clarification on the day of the edit. As of this writing, the department has not published a separate correction notice, a statement naming which agencies were compromised, or a copy of the original text.

    Why it matters

    “Target” and “victim” are not synonyms with different registers. One describes an attempt and the other describes an outcome, and the gap between them is the entire question a defender asks about someone else’s incident: did it work? The August 26 release answered that question for NASA, the Federal Reserve, the Department of Energy, the Justice Department, Health and Human Services, the National Institutes of Health, and the Senate. The August 28 release declines to answer it for any of them.

    That is not a small retreat, and it leaves the public record emptier than it was before the correction. The first version overstated compromise; the second removes the claim entirely and puts nothing in its place. Nobody outside the government now knows, from the government, whether any of the seven named bodies was breached. The one data point that exists — NASA’s patching held — points the other way, and it is not in the release.

    The mechanics of the correction compound the problem. An edit made in place, annotated only with a note that edits were made, is invisible to anyone arriving after the fact. A reader who opens the release today sees a clean, internally consistent document with no indication that its central factual claim was different two days earlier. Anyone who quoted the original — in a threat brief, a board update, a congressional statement, a vendor blog post — is now holding a quotation that cannot be checked against the source it came from. The department did not hide the edit, but it did not preserve what it edited, which for practical purposes puts the burden of proof on whoever copied it first.

    Reach is asymmetric here in the way it always is. The original announcement was a Wednesday press release from the Justice Department about Chinese state hacking of the Federal Reserve and the Senate; it traveled. The Friday edit was a silent word change on the same URL. Wire copy, aggregator summaries, and internal briefings written between Wednesday and Friday carry the stronger claim, and most of them will never be revisited.

    This publication has spent the past week documenting the same failure across very different records: a Microsoft exploited-in-the-wild flag that was set and then retracted with no note of what it had said, a vulnerability report deleted along with its author, and a CISA assessment of the PaperCut zero-days that still reads “none” for exploitation a day after the vendor said customers were being attacked. The common feature is not carelessness. It is that the systems publishing these records — press offices, advisory databases, scoring pipelines — are built to state the current position and not to preserve the previous one. Corrections are treated as maintenance rather than as news, even when the thing being maintained is the answer to whether a federal agency was breached.

    Government attribution statements get a level of deference that vendor advisories do not. They are cited in policy debates, procurement decisions, and insurance underwriting. That deference is reasonable, and it is exactly why the first draft has to be right, or the correction has to be as loud as the original. Here it was neither.

    What to do

    If you cited the August 26 release in anything that is still circulating internally — a threat briefing, a risk register entry, a slide claiming federal agencies were breached by this group — go back and check the wording you carried forward against the current text. The department’s position today is that these seven were among the targets. It has not said which, if any, were compromised, and you should not infer it.

    Do not treat the list of seven as a list of confirmed intrusions in any model you feed to someone else. If a vendor product or feed you consume asserts that the Federal Reserve or the Senate was breached by QTFY, ask what it is sourced to, and check whether the source is the pre-edit release.

    Keep dated copies of government press releases you rely on. Justice.gov publishes no diff, no revision history, and no archived prior version, so the only defense against an in-place edit is your own capture with a timestamp. This costs nothing and it is the difference between citing a source and citing a memory of one.

    On the operational side, the release is still useful. QScan targets internet-of-things devices at scale and QTRouter relays traffic through compromised machines outside China to disguise its origin. If you run edge devices, cameras, or routers with internet-facing management, the seizure removes two platforms but not the exposure that made them work. The affidavit’s one confirmed outcome is that patching stopped the attempt against NASA.

    Sourcing note

    Checked: the Justice Department press release “Justice Department and FBI Seize Platforms Operated and Used by China State-Sponsored Hackers,” read directly at justice.gov, including its “Updated August 28, 2026” stamp, its editor’s note, and the quotations from Blanche and Patel reproduced above. Associated Press coverage of the edit, published August 28, 2026, is the source for the original wording, for the department’s explanation that the affidavit distinguished targeting from compromise, for the NASA footnote, and for the FBI’s and CISA’s non-response.

    Not reached: the affidavit supporting the seizures, which is not linked from the release; the pre-edit text of the release, which the department did not preserve; cisa.gov, which returns 403 to automated fetching, so no CISA advisory was checked directly for this story.

    Unresolved: which of the seven named bodies, if any, QTFY compromised. The department asserted it on August 26, withdrew the assertion on August 28, and has not replaced it. Also unresolved is whether the pre-edit wording exists in any government-published form.

  • Unitree G1 robots take root code execution from Bluetooth range, and no one has named a fixed firmware version

    Unitree G1 robots take root code execution from Bluetooth range, and no one has named a fixed firmware version

    Two CVE records published August 27 describe unauthenticated root code execution on the Unitree G1 EDU humanoid, one of them reachable from Bluetooth range with no pairing — and neither the CVE records, the assigning CNA, nor Unitree names a firmware version that fixes it.

    What happened

    On Thursday, August 27, 2026, security researcher Olivier Laflamme published a technical writeup of two remote code execution chains in the Unitree G1 EDU humanoid robot, along with a proof-of-concept toolkit on GitHub. NVD published both CVE records the same day at 8:18 p.m. UTC. VulnCheck is the assigning CNA for both.

    CVE-2026-76639 carries a CVSS 3.1 base score of 8.8 and a CVSS 4.0 base score of 8.7, both supplied by VulnCheck. NVD’s record describes “an unauthenticated remote code execution vulnerability that allows network-adjacent attackers to execute arbitrary commands as root by chaining three weaknesses: an unauthenticated WebRTC-to-DDS bridge on TCP port 9991, a static AES-128 key stored with world-readable permissions, and a path traversal flaw in the chat_go knowledge upload API.” The researcher adds the last step: files written through the knowledge-base upload are executed by a service whose command whitelist is evaluated only once, at import time.

    CVE-2026-76640 is scored 7.5 on CVSS 3.1 and 7.7 on CVSS 4.0. VulnCheck titles it “Unitree G1 EDU 1.5.2 BLE GATT RCE via WiFi Provisioning Stack” and describes chained flaws that “allow unauthenticated proximate attackers to achieve root code execution without pairing or credentials.” The chain runs five links deep: a Bluetooth Low Energy characteristic that accepts writes with no authentication requirement, retrieval of the device’s RSA-wrapped AES key, a cloud API that decrypted and returned that key without verifying the requester owned the robot, an unquoted heredoc variable in the WiFi provisioning path, and a buffer overflow in the SSID chunk accumulator that overruns a 500-byte buffer and corrupts a function pointer.

    Both VulnCheck advisories give affected versions as “G1 EDU <= 1.5.2.” Neither names a patched version. Both CVE records carry an NVD vulnStatus of Received, meaning NVD has not yet performed its own analysis and the CNA’s scores are the only ones that exist.

    This is single-researcher work on a single product line, covering four G1 EDU units running firmware 1.5.1.1 and 1.5.2. The robot lists at roughly $20,000 and sells primarily into universities, research groups, and industrial pilots. There is no public count of how many are deployed, and this page does not estimate one.

    Unitree’s role was not adversarial. The researcher’s timeline records the robot arriving on April 29, 2026, the first chain working by May 10 and verified by Unitree on May 14, the second completed June 25 and validated June 30, a $5,000 bounty paid August 6, and CVE requests filed August 18. He describes the vendor’s security team as “were awesome to work with” and notes that “Unitree was already aware of some of these issues internally.” Unitree implemented at least one fix in that window: “an account-to-robot cloud binding ownership check before returning the AES-128 key.”

    Why it matters

    The most useful thing here is not either chain individually. It is that the highest-leverage repair was made in a cloud backend, and the rest was not made anywhere an owner can see.

    Consider what the ownership check fixed. The BLE chain did not break because Bluetooth is insecure; the designers knew the transport was open and layered encryption on top of it. It broke because the key for that encryption could be obtained by asking a cloud API for it, and the API answered without checking whether the asker owned the robot. That is an authorization bug in a web service, and Unitree fixed it server-side. No owner had to do anything. No owner could have done anything. No owner can verify it was done, roll it back, or confirm which robots it covers. For a class of device where firmware updates are slow, physically inconvenient, and sometimes skipped entirely, the vendor’s ability to repair the important link centrally is a genuine advantage, and it should be counted as one.

    It is also why the silence on firmware is the operative finding. The unquoted heredoc variable, the SSID buffer overflow, the DDS bridge on port 9991, the path traversal in the upload API, and the whitelist evaluated only at import time are all defects in code running on the robot. Fixing the cloud ownership check removes one link from one of the two chains. It does not touch the others. An owner reading these records today learns that firmware through 1.5.2 is vulnerable, that a working toolkit is published, and that there is no version number above 1.5.2 named by anyone as the fix. There is nothing to write on a change ticket. Searching for a Unitree security advisory turns up coverage of the research and no vendor page. The Hacker News reports it asked Unitree to confirm fixed firmware versions and affected scope and had not received an answer.

    The provisioning path is the recurring lesson, and it is not specific to robots. Any device set up out of the box has to accept its first configuration over a channel that cannot be authenticated, because no credential exists yet. That bootstrapping path is unauthenticated by construction — the hardest surface in the product to get right and, judging by how often it fails, one of the least reviewed. A BLE characteristic accepting bare writes is not itself the bug; it is the design premise. The bug is what the code behind it does with what it receives, and here it accumulated attacker-controlled SSID chunks into a fixed buffer without bounding them.

    Then there is what root on this device reaches. A humanoid robot is a Linux computer with a real-time kernel, microphones, cameras, and limbs, standing in a room with people in it; the security and safety questions stop being separable. The researcher also found production third-party API credentials on the robot’s locomotion computer — keys for cloud speech synthesis, voice recognition, and music services from several providers — so root on one robot reaches the vendor’s paid accounts with third parties, a billing and abuse exposure that extends past both the owner and Unitree. An API signing secret was likewise hardcoded in the vendor’s Android app; the literal value is in the published writeup and is not reproduced here, because it offers a defender nothing.

    Finally, the researcher’s own framing deserves to be carried rather than dropped, because it is the honest one and because coverage tends to strip it. He states plainly that the work is “a point-in-time account of the platform as I found it during the research and disclosure period, not as a description of its current security posture.” Between June and now, Unitree may have shipped firmware that closes some or all of these paths. Nothing published says so. The gap between “may have been fixed” and “was fixed in version X” is the entire distance between a security program and hoping.

    What to do

    There is no fixed firmware version to give, because none has been published. If you operate G1 EDU units, ask Unitree directly for the release that remediates CVE-2026-76639 and CVE-2026-76640 and for the models and branches in scope. Until that answer exists, treat every unit as affected.

    Put the robots on an isolated segment with nothing else of value on it, and do not treat them as trusted hosts. The first chain reaches the device from an adjacent network position, and TCP port 9991 is the named entry point — it should not be reachable from any general-purpose user network. Both records score the attack vector as adjacent rather than network, so segmentation is a real control here, not a token one.

    Treat physical Bluetooth range as part of the perimeter. The second chain needs proximity and no credentials, so the control surface is who can get close to the robot and when it is powered on. Powering units down when not in use reduces exposure and costs nothing.

    Rotate any credential a robot has held or could have observed. If your units were provisioned before Unitree’s cloud ownership check went in, treat the AES key protecting the BLE setup channel as having been obtainable by anyone who asked.

    Sourcing note

    Checked: the NVD records for CVE-2026-76639 and CVE-2026-76640, which supplied the publication timestamps, the CNA identity, the description text, and every CVSS vector and score quoted here; VulnCheck’s advisories for both identifiers, which supplied the titles and the “G1 EDU <= 1.5.2” affected-version string and confirmed no patched version is named; the researcher’s writeup at boschko.ca, which supplied the disclosure timeline, tested firmware versions, bounty amount, and vendor-response quotations; and the public GitHub repository holding the proof-of-concept toolkit, which confirms the artifacts are inspectable.

    Single-source limitations, stated plainly: this is one researcher’s work on four robots of one model. The vulnerability details have been validated by the vendor per the researcher’s timeline and accepted by a CNA, but there is no independent reproduction and no second research team. The deployed population is unknown and is not estimated above.

    Could not reach: any Unitree security advisory. Searches surfaced no vendor bulletin, no firmware release note referencing either CVE, and no Unitree PSIRT page. That is an absence, not a claim that Unitree has said nothing privately to customers.

    Unresolved: which firmware release, if any, fixes the on-device defects, and whether the cloud-side ownership check applies to previously provisioned units or only to new bindings. Neither CVE appears in the KEV catalog as of publication, and no party has reported exploitation in the wild.