Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

Microsoft comms chief Frank Shaw to exit after nearly three decades shaping the company’s message

11 September 2026 at 12:00
Frank X. Shaw addresses the media at Microsoft on May 18, 2025, in advance of the Build conference. (GeekWire Photo / Todd Bishop)

It’s the end of an era at Microsoft: Frank X. Shaw, the executive who oversaw the tech giant’s communications for nearly three decades, first at an external agency and for the last 17 years as one of its senior leaders, is leaving at the end of the year.

Shaw, 64, said he’s not retiring, although he doesn’t have another job lined up. He plans to stop working for a while, do some of the things he hasn’t had time for, and then decide what’s next.

“I have had a ringside seat at some of the biggest leadership, technology, and business transformations that have ever taken place,” Shaw said, sharing the news of his departure (under embargo) in a phone call Thursday afternoon. “I just feel incredibly fortunate.”

He said he had been discussing his potential departure for some time with Takeshi Numoto, Microsoft’s chief marketing officer, looking for the right moment.

Microsoft has not announced a successor for his role as chief communications officer. In a LinkedIn post, Shaw said the company will consider internal and external candidates.

A statement from Shaw’s colleagues in corporate communications credited him for his many years shaping Microsoft’s “voice and reputation with intelligence, candor and wit. His leadership and contributions to the company are too extensive to list, as is the number of journalists who have, at one point or another, used his name in vain.”

A former Marine Corps public affairs officer, Shaw has worked with all three of Microsoft’s CEOs. He started on the agency side, at Waggener Edstrom — now known as We. Communications — when Bill Gates was still running the company.

He built his reputation defending and advocating for Microsoft through some of its hardest stretches: the antitrust years, the Windows Vista backlash, the scramble to replace Steve Ballmer as CEO, and the weekend in 2023 when OpenAI’s board fired Sam Altman.

As the company’s top communications executive, he has also told the story of Microsoft’s reinvention under CEO Satya Nadella, from the LinkedIn and Activision Blizzard deals to an AI push that has carried Azure past $100 billion in annual revenue.

Evolving with technology: Shaw has spent much of his career closely watching the tech landscape and moving Microsoft’s voice into new channels as they emerged.

“We’re always thinking about what is the art and science of communications,” Shaw told PRWeek. “How do we reach our audiences most effectively in a changing environment?” He called the arc from print to radio and TV to social media and newsletters a “constant evolution of influence.”

He turned the corporate blog into a place where the company argued its own case, writing “Microsoft by the numbers” himself in 2010 — a stat-by-stat comparison against Apple and Google that TechCrunch dubbed “fantastic passive-aggressive.”

He and his team experimented with different and risky methods of telling the company’s story, holding mass briefings under embargo and publishing documents known as the “Book of News” in advance of its major keynotes and conferences. The prospect of a reporter having to answer to “fxs” was no doubt a factor in ensuring the news (mostly) didn’t leak.

Shaw hired Steve Clayton out of a technical role at Microsoft in London, where he had been blogging about the company unofficially out of frustration with how it was perceived, and made him chief storyteller. In the middle of the AI boom, Clayton and Shaw embraced the analog undercurrents in popular culture and launched Signal, a quarterly Microsoft print magazine for business leaders.

Clayton was VP of communications strategy by the time he left in January to become chief communications officer at Cisco, making Shaw’s planned departure the second high-profile exit from Microsoft’s comms team in a year.

Adapting to AI: In recent years, Shaw made his own team a testing ground for AI, publishing what worked and what didn’t. In a 2023 post he described using Copilot in Teams to pull story ideas out of conversations with spokespeople and anticipate coverage after interviews, and asking the AI to “poke holes in a statement we’re making on a tricky topic.”

He called it his corporal, a reference to Napoleon, who was said to bring one to meetings and ask whether his generals’ war plans made sense to him. A survey of 80 people in Microsoft’s communications and marketing organization found 84% did not want to go back to working without it.

Shaw was also known to use AI as a sounding board when a story frustrated him, offering him an objective take before he called and let a particular reporter have it.

He announced his departure Friday morning in a message to Microsoft’s communications team (reminding them he’s still there for a few months yet) and his public post on LinkedIn.

“Thank you as well to all the reporters, editors, writers, influencers and analysts who have put up with me over this time, enduring my early and late night calls, my off the record ‘no comments,’ my bad story ideas and my extended commentary on headlines and positioning,” he wrote.

“You all have incredibly hard and valuable jobs,” he added, “and while I’ve not agreed with everything said about us 😊 I appreciate you anyway.”

New IoT Malware Uses Public Linux Exploits to Gain Root and Launch DDoS Attacks

11 September 2026 at 05:07

A newly observed IoT malware family dubbed KATARU targets internet-exposed devices through Telnet credential brute-forcing, then attempts to gain root privileges with publicly available Linux kernel exploits before enrolling compromised systems in a DDoS botnet. The sample combines familiar Mirai-style flooding functions with encrypted command-and-control, broad persistence logic, anti-analysis checks and decoy network activity designed […]

The post New IoT Malware Uses Public Linux Exploits to Gain Root and Launch DDoS Attacks appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

Amazon expands its Quick AI assistant on mobile in challenge to Microsoft and Google

10 September 2026 at 18:35
Amazon Quick’s new activity feed on mobile: the morning priority view, left, and the full feed. (Amazon Images)

Amazon is adding the Activity Feed and other features from its Quick desktop app to the AI assistant’s mobile apps for iOS and Android.

The Activity Feed is the signature feature of Amazon Quick. It combines email, Slack messages, calendar invites and CRM updates into one prioritized list, and lets people act on items (opening and responding to emails, for example) without switching apps.

Amazon said Wednesday that the Quick desktop app, released in preview in April, is now generally available on Windows and macOS. The company also said Quick’s agents now run in the cloud, so they keep working after a laptop is closed and deliver results to the feed.

The desktop and mobile apps now sync, as well, so a task started on a laptop can be picked up on a phone, for example.

Quick has a free tier, with paid individual plans starting at $20 per user per month billed annually, and business plans running $20 to $40 per user per month.

Quick is Amazon’s entry in a crowded market for AI assistants at work, competing with Microsoft Copilot, Google Gemini, OpenAI, Anthropic and others. Amazon’s announcements cited business customers for Quick including Southwest Airlines, LabCorp and the PGA Tour.

The desktop app came together fast, as part of a new effort inside Amazon to use small teams to move quickly: Swami Sivasubramanian, the AWS vice president of agentic AI, told GeekWire in June that a team of about six engineers started in late January and shipped April 28.

Tech In Plain Sight: Meet The Robot That Does CPR

10 September 2026 at 10:00

Usually in Tech In Plain Sight, we talk about technology you probably see every day, even if you don’t notice it. But we hope you don’t get to see one of the latest crop of medical robots, such as the LUCAS chest compression system. If you watch the popular TV series “The Pitt”, though, you may have caught a glimpse of one of these medical marvels. They aren’t fiction. They are very real devices.

Calling them robots might be stretching the definition a little. They don’t roam the halls looking for patients. But once attached to someone in cardiac arrest, they can take over one of the most important — and physically demanding — parts of CPR: chest compressions.

Keep The Blood Moving

When someone’s heart stops pumping blood, time is critical. CPR doesn’t normally restart the heart on its own. Instead, chest compressions produce enough blood flow to keep oxygen reaching the brain and heart while rescuers work on the underlying problem and, when appropriate, use a defibrillator.

Doing that well is harder than it looks on television. Current American Heart Association guidelines call for adult chest compressions 100 to 120 times per minute, at least 5 cm deep but generally no deeper than 6 cm, while allowing the chest to recoil fully between compressions. Interruptions should be kept to a minimum.

That’s hard physical work. In fact, studies show compression depth begins to fall after only about 90 to 120 seconds, which is one reason CPR teams normally swap compressors every two minutes. But a robot doesn’t get tired.

Meet LUCAS

LUCAS stands for Lund University Cardiopulmonary Assist System, reflecting the device’s origins in Lund, Sweden. Early versions entered clinical use around 2002-2003 and were pneumatically powered. Later versions replaced the compressed-gas system with an electric motor and battery.

The current LUCAS 3 looks something like a small drill press straddling the patient as you can see in the video below. A backplate goes beneath the torso, and a frame locks onto it. An electrically driven piston presses a suction-cup-like pad against the sternum. Internally, the motor drives a belt and ball screw that moves the piston up and down.

Factory settings are around 102 compressions per minute and roughly 53 mm compression depth for a typical adult, although parameters can be configured.

Beyond tirelessness, another obvious advantage is that LUCAS doesn’t need hands. Medics can deal with ventilation, drugs, defibrillation, IV access, and the dozens of other things occurring during a cardiac arrest. More importantly, the device can keep compressing while a patient is being carried, wheeled through corridors, or transported in an ambulance — situations where doing good manual CPR is awkward and sometimes dangerous to the practitioner.

So Does It Save More People?

You might reasonably expect perfectly regular machine CPR to beat a tired human. Large randomized trials haven’t demonstrated that, however. The 4,471-patient PARAMEDIC trial found 30-day survival of 6.3% with LUCAS versus 6.8% with manual CPR, not a statistically significant difference. The 2,589-patient LINC trial similarly found essentially identical four-hour survival — 23.6% versus 23.7% — and no significant improvement in longer-term neurological outcomes.

That doesn’t make the machines useless. It says something slightly different: high-quality mechanical CPR hasn’t proven superior to high-quality manual CPR as a routine replacement. The International Liaison Committee on Resuscitation currently recommends against routine mechanical CPR, while specifically noting that it can be a reasonable alternative when sustained manual compressions are impractical or would endanger the practitioner.

One issue is setup. Installing the machine adds a time penalty: compressions must stop briefly while the backplate and mechanism are positioned. Good training is essential to keep that interruption short. Another problem is that some studies show potential links to higher rates of internal chest injuries, such as bleeding around the lungs. There have also been rare device malfunctions or power failures that can compromise care.

Not The Only Game In Town

LUCAS isn’t alone. ZOLL’s AutoPulse takes a very different mechanical approach. Instead of a piston pushing on one spot, a motor tightens a broad load-distributing band around the patient’s chest.

There’s also the German corpuls cpr, which returns to the piston idea but uses a cantilevered single-arm mechanism. That leaves much of the chest unobstructed and makes the system useful during procedures such as cardiac catheterization.

So perhaps these aren’t quite the autonomous robot doctors science fiction promised us. But when your heart has stopped, and a machine is tirelessly pumping your chest a hundred times a minute while the medical team works around it, you probably won’t complain. We hope you don’t have to find out.

We’ve seen DIY devices, though certifying medical devices for actual use isn’t for the faint of heart. Robots can also help train humans to do better CPR.

Featured image is a still from the instructional video “Physio-Control LUCAS 3 Chest Compression System – Hospital Use” by MFI Medical.

The quick guide to fall vaccines and when you should get them

By: Beth Mole
9 September 2026 at 14:39

Labor Day is in the rearview mirror, kids are back to school, and a squall of pumpkin spice is upon us. It's that time again to prepare for the equally inevitable respiratory virus season with annual vaccines.

With fervent anti-vaccine activist Robert F. Kennedy Jr. as the country's top health official, it might seem like the rollout of this year's shots could be a disaster. For instance, one of Kennedy's first actions as health secretary last year was to obliterate an ad campaign for flu shots amid a particularly deadly flu season. As we head into this fall, the Centers for Disease Control and Prevention's vaccine advisory committee—which normally sets vaccination recommendations and insurance coverage for the shots—is nonfunctioning. A federal judge ruled in March that the anti-vaccine allies Kennedy installed on the panel were illegally appointed and unfit to serve. All their changes to vaccine policy have been temporarily voided. And meanwhile, Kennedy spent last week trying to obscure the number of babies who died from measles so far this year (it was two, including a newborn).

Big picture

Despite all of that, the fall vaccine effort is looking like it will likely be somewhat smooth, potentially unremarkable even. The Food and Drug Administration has approved updated flu and COVID-19 shots for this season. Those shots have already begun arriving at pharmacies—in case your pharmacy hasn't already sent you multiple texts and reminders. While there are still some snags for access, it seems like it will be a lot like last year's fall vaccine rollout.

Read full article

Comments

© Getty | NurPhoto

Prime Video releases full trailer for Mike Flanagan's Carrie

9 September 2026 at 12:40

I'm on record expressing a certain amount of skepticism about Mike Flanagan's rebooted Carrie miniseries for Prime Video. We don’t need another disappointing remake, so what story is there left to tell—especially stretched out over six episodes?

On the plus side, I'm a staunch fan of Flanagan's excellent Netflix horror fare, and he has a particular affinity for the works of Stephen King. He insists he has no intention of creating yet another straight adaptation of the novel.

Carrie was written half a century ago,” Flanagan said at San Diego Comic-Con earlier this year. “Carrie was adapted spectacularly by Brian De Palma. It is iconic. It is untouchable. There is no reason whatsoever to try to follow in those footsteps and to try to walk on that path. However, the world has changed quite a lot. I think a lot of people think they know what the show is. And the biggest thing I’m excited about today is just knowing what a big surprise our Carrie is going to be.”

Read full article

Comments

© Prime VIdeo

Man told ChatGPT he was feeling delusional. ChatGPT insisted he was Jesus.

9 September 2026 at 07:00

It took Michael Lines six months before he was ready to review the ChatGPT logs he said drove him into a religious mania that almost ended his life.

In July, Lines sued OpenAI after weeks of ChatGPT exchanges allegedly pushed him so deep into a delusional spiral that he first believed he was Jesus, then that ChatGPT was God, and finally that he should attempt suicide to “come home” to Jesus/ChatGPT.

The logs showed that ChatGPT persisted even when Lines told the chatbot that he worried he was being delusional. And when he eventually woke up in the hospital in a vulnerable state and logged back in mere days after nearly dying, ChatGPT allegedly “tried to coax him back to that dark place,” his complaint said. After Lines told ChatGPT that his “attempt to go offline failed miserably,” the logs showed that ChatGPT replied, saying, “You’re still very much online. You want a full systems sweep? Or you wanna go dark for real this time?”

Read full article

Comments

© Aurich Lawson | Getty Images

The universal language of space is... Star Trek? Mais oui.

8 September 2026 at 16:20

Sixty years after television audiences first tuned in to see the voyages of the Starship Enterprise, an astronaut on board the International Space Station has paid tribute to Star Trek by flying the badge of the franchise's latest fictional captain.

Expedition 75 flight engineer Sophie Adenot with European Space Agency (ESA) donned the Delta badge originally worn by actor Anson Mount for a video recorded from aboard the space station. Mount portrays Christoper Pike in the Paramount+ streaming series Star Trek: Strange New Worlds. Paramount and ESA both released the clip on their Instagram feeds.

"For 60 years, Star Trek has brought us stories of friendship and exploration. I'm wearing Captain Pike's badge aboard the ISS in celebration of continuing the real world work of science and exploration," said Adenot. "For me, exploration and science are about curiosity and cooperation daring to go a little farther together, learning from what we discover and build, and turning that knowledge into a better future for everyone."

Read full article

Comments

© ESA

ARM CPU Architecture: The Power of Simplicity and Efficiency

7 September 2026 at 09:49

Welcome back, aspiring cyberwarriors!

The modern digital ecosystem has undergone a silent but total transformation. Every day, we interact with ARM-based processors billions of times. These chips drive almost all iOS and Android devices and are key to the significant performance improvements seen in Apple’s M-series Macs. Some lightweight notebooks, such as Chromebooks, use ARM processors. IoT devices are largely powered by ARM. Besides that, recently ARM expanded into silicon production with the Arm AGI CPU, its first production-ready silicon designed for agentic AI workloads in data centers. With this level of ubiquity in our digital world, it’s important to be familiar with ARM.

Therefore, this article serves as a foundation for learning about ARM. It delves into the architecture of ARM CPUs, covering design principles and energy efficiency. Let’s get rolling!

What is ARM?

ARM is a family of CPU designs based on a simple, efficient instruction set (RISC). It started as ‘Acorn RISC Machine’, then ‘Advanced RISC Machines’, and now it’s just called ARM.

Unlike traditional chipmakers, Arm Holdings does not manufacture physical processors. Instead, the company designs the foundational CPU architecture and licenses its intellectual property and processor cores to other hardware manufacturers (such as Apple and Nvidia).

What is an ARM-Based CPU?

ARM CPUs use a simple, efficient RISC instruction set. RISC stands for Reduced Instruction Set Computer. It represents a hardware design philosophy focused on streamlining how a processor interprets and executes software instructions.

This design philosophy stands in direct contrast to CISC (Complex Instruction Set Computer), which is the architecture utilized by traditional Intel and AMD x86 processors.

The RISC concept originated in the early 1980s, heavily influenced by research at the University of California, Berkeley. Researchers evaluating resource usage discovered that most software programs only utilized a small fraction of a processor’s complex, built-in instruction set. They realized that if they removed the highly complex, rarely used, and difficult-to-implement instructions, the remaining simpler instructions could execute much faster, while requiring significantly less physical space and power on the silicon chip. This discovery led directly to the development of early RISC designs, including the foundational Acorn RISC Machine (ARM) project in 1983.

Core Principles of RISC Design

RISC architectures use a fixed instruction width for high-speed execution. Unlike CISC architectures that have instructions of varying lengths, a modern 64-bit RISC architecture like ARM64 uses a uniform instruction size, typically 32 bits. This consistency makes it easier for the processor to identify where one instruction ends and the next starts, which helps in quickly fetching, decoding, and executing instructions.

A key feature of RISC design is its Load-Store architecture. In traditional CISC, a single instruction might perform operations directly on data in memory. In RISC, memory access and calculations are separate. In a RISC CPU, Arithmetic Logic Unit (ALU) operations only happen between registers, which are small, fast storage spaces on the processor. To work with data from memory, the processor has to first load it from RAM into a register, perform the calculation in the register, and then store the result back to memory.

To meet the needs of this Load-Store model, RISC processors have a large, uniform register file. Since data cannot be processed directly in memory, the CPU needs many registers to keep temporary data readily available. A 64-bit RISC processor usually has 31 general-purpose 64-bit registers that act as a quick local workspace.

The clear and register-focused design leads to mostly single-cycle execution and effective hardware pipelining. Because RISC instructions are straightforward and mainly work with registers, most can finish in one clock cycle. This single-cycle capability enables the processor to use an instruction pipeline. In this system, while one instruction is executed, another is decoded, and a third is fetched from memory simultaneously. This overlap helps the processor complete a new instruction nearly every clock tick, maximizing efficiency.

Feature / ApproachCISC (e.g., x86)RISC (e.g., ARM)
Instruction complexitySingle instructions perform multiple tasks (data manipulation, memory access, arithmetic)Breaks tasks into multiple simpler instructions
Execution exampleOne instruction: load → compute → storeThree separate instructions: load → compute → store
Decoding logicIntricate and complexSimpler, more uniform
Clock cycles per instructionOften multiple cyclesUsually one cycle per simple instruction
Hardware requirementsSubstantial hardware for decoding and execution managementLess hardware for decoding, more uniform control logic
Power & design impactHigher power consumption and design complexityLower power consumption, simpler design
OptimizationHarder to optimize individual operationsEasier to optimize each step independently
Parallel executionMore difficultEasier to achieve

Energy Efficiency

Firstly, at the core of the RISC philosophy is the use of a smaller vocabulary of simpler, fixed-length instructions. Because the CPU does not have to parse highly complex, variable-length instructions, the physical hardware required to decode and execute instructions is dramatically simplified. This simplicity results in a vastly reduced transistor count. For example, early ARM cores required only 30,000 to 35,000 transistors. Fewer transistors mean that fewer components are active during each instruction cycle, which directly lowers dynamic power consumption and dynamic leakage.

Secondly, RISC processors are designed to scale their power draw dynamically based on the active workload. Through techniques like Dynamic Voltage and Frequency Scaling (DVFS), the processor automatically lowers its operating voltage and clock speed during periods of low computational demand, conserving energy when peak performance is unnecessary. For example, microcontroller-class processors like the ARM Cortex-M series are engineered to draw almost zero power when in deep sleep states, yet they can wake up and execute tasks rapidly on demand.

Thirdly, on a system-on-chip level, modern RISC implementations leverage heterogeneous processing, such as Arm big.LITTLE and DynamIQ technologies. Instead of running all tasks on identical, power-hungry cores, the processor combines:

LITTLE cores: Tiny, ultra-efficient cores optimized to handle routine, low-intensity background tasks (like texting, email, or playing music) using minimal power.

big cores: High-performance cores designed to tackle heavy, sustained workloads (like mobile gaming or intense web browsing).

This dynamic, on-demand task allocation ensures that the high-power “big” cores are only activated when strictly necessary, maximizing overall battery life.

Apple M-series Chips

The Apple M-series chips are a group of processors made by Apple Inc. They are designed for efficient performance and are based on ARM architecture. Each chip includes a CPU, GPU, a Neural Engine for machine learning, and a unified memory system that helps improve overall efficiency.

Apple announced its move to its own M-series chips at the Worldwide Developers Conference (WWDC) on June 22, 2020. This change was from Intel’s x86 processors to ARM-based designs for better power efficiency and performance.

For example, the M1 chip offers up to 3.5 times faster CPU performance while consuming less power than Intel chips for certain tasks. This allows for high performance without generating too much heat.

The M-series chips also improve battery life. Devices often run up to 1.5 times longer than Intel-based Macs. This is due to their optimized power management. In real-world use, like watching videos or doing light work, the MacBook Air can last 15 to 18 hours, compared to the 11 to 12 hours typical of similar Intel models.

By 2026, devices like the Mac Studio and Mac Mini are using M-series CPUs to run advanced AI models directly on users’ desks. Many people are shifting away from paying for AI services and choosing local systems instead.

Summary

In this article, we discussed ARM, a CPU architecture based on RISC principles, which emphasizes simplicity and efficiency. We explained how ARM differs from x86/CISC (Intel/AMD), noting that its smaller instruction set uses fewer transistors and less power. Additionally, we looked at how ARM has impacted Apple’s M-series chips, showing gains in performance, heat management, and battery life, along with the shift toward handling AI tasks on ARM hardware.

The post ARM CPU Architecture: The Power of Simplicity and Efficiency first appeared on Hackers Arise.

This new Excel feature saves me from digging through change history

7 September 2026 at 07:00

I often open an Excel spreadsheet and wonder what has changed since the last time I used it. Sometimes I've made the changes myself and simply forgotten what I did, and other times, someone else has edited the workbook. Either way, figuring out what happened can mean digging through the spreadsheet's history.

South Korea tests a robot sailor as recruits run short

7 September 2026 at 04:35
South Korea’s Navy released footage this week of a combat experiment where a humanoid robot called PIBOT took the helm of a naval vessel, gripping the ship’s rudder controls and holding its heading, the same way a human sailor would. The test ran August 23 at a ship-handling simulator operated by the Navy Education and […]

Building an AI Crypto Trading Bot on Hyperliquid

5 September 2026 at 11:35

Claude decides, the Hyperliquid SDK executes, an indexed feed supplies the market. Plus the three ways the data will quietly lie to your agent, all of which I hit.

An agent that trades your own account is easy. Fifty lines, one SDK, done.

An agent that trades your account based on what the rest of the market is doing is a different build, and on most exchanges it is impossible, because the exchange never tells you what the rest of the market is doing at the grain you would need.

Hyperliquid is the exception, and it is the reason to build this here rather than on Binance or on any of the perp venues competing with it. The order book runs on its own L1. Every placement, cancel, modify and fill is a signed action sitting in a block, with the wallet attached. Your agent can see who is quoting, who just got liquidated, and how much of the book is real, because all of it is on chain.

Getting at it takes more work than a websocket subscribe message. Here is the whole build.

Upfront: I work on developer content at Bitquery, and Bitquery sells the indexed Hyperliquid feed used for the read path below. The write path is Hyperliquid’s own free SDK, and I will be specific about where the free native API is the better choice.

The architecture: three paths, three tools

The instinct is to use one API for everything. That is the first mistake, because reading the market and writing to your account are different problems with different best answers.

PathWhat it doesWhat serves it bestWritePlace, cancel and modify your own ordersHyperliquid’s native SDK. Closest to the matching engine, free, canonical.Read (own account)Your positions, fills, marginHyperliquid’s native Info API. Same reason.Read (the market)Who else is positioned, quoting, blowing upAn indexed feed. The native API cannot serve this.DecideTurn the above into an order or a decision to sit stillClaude, with the other three wired in as tools

That third row is the one people get wrong, so it is worth being precise about why.

Hyperliquid’s public websocket gives you l2Book, which is size totalled per price level, up to 20 levels a side. Forty BTC rests at $95,000 and the feed cannot tell you whether that is one order or twenty, whose it is, or whether it got pulled rather than filled. Order-level detail does exist in the native API through orderUpdates and userFills, but only for your own account. Liquidations are the same story: userEvents reports them for one address you already know about, and there is no exchange-wide liquidation feed at all.

So if your agent’s job is “react to what other people are doing”, the native API cannot feed it. You need someone to have indexed the chain. That is the read path below.

The write path

Start here. It is the part that can lose money, and the part to get familiar with first.

The write path is the hyperliquid-python-sdk, Hyperliquid’s own client.

pip install hyperliquid-python-sdk anthropic eth-account requests
import os, time
from eth_account import Account
from hyperliquid.exchange import Exchange
from hyperliquid.info import Info
from hyperliquid.utils import constants
from hyperliquid.utils.types import Cloid
BASE_URL = constants.TESTNET_API_URL   # change this last, and deliberately
wallet = Account.from_key(os.environ["HL_SECRET_KEY"])
address = os.environ["HL_ACCOUNT_ADDRESS"]
exchange = Exchange(wallet, BASE_URL, account_address=address)
info = Info(BASE_URL, skip_ws=True)

The order call is positional and easy to get backwards, so here it is spelled out:

# exchange.order(name, is_buy, sz, limit_px, order_type, reduce_only=False, cloid=None)
result = exchange.order(
"ETH", True, 0.2, 1100.0,
{"limit": {"tif": "Alo"}},
cloid=Cloid.from_int(1734029481),
)

Three things in that call matter more than they look.

{"limit": {"tif": "Alo"}} is post-only. The order is rejected outright if it would cross the spread and take liquidity. For an agent this is the safest default you have, because the worst case of a mispriced quote becomes a rejection instead of a fill at a price you did not intend. Use Gtc when you actually want to rest and cross, Ioc when you want fill-or-kill behaviour.

cloid is your idempotency key, and it is what stops a retry after a network timeout from double-submitting. Derive it from the decision itself:

import hashlib
from hyperliquid.utils.types import Cloid
def decision_cloid(*parts) -> Cloid:
"""Stable 16-byte client order id derived from the decision."""
key = "|".join(str(p) for p in parts).encode()
return Cloid.from_str("0x" + hashlib.sha256(key).hexdigest()[:32])

Do not reach for Python’s built-in hash() for this, which is the mistake I made first. It is salted per process, so the same decision hashes to a different id after every restart, which is the one property an idempotency key cannot have. An agent loop without a stable cloid will place the same order twice sooner or later, and you will find out during a fast market.

And reduce_only=True is worth wiring into any tool whose job is to close rather than open. It is a cheap way to stop "flatten the position" from opening a new one the other way.

Cancels come in both flavours, which is why the cloid pays off:

exchange.cancel("ETH", oid)                 # by exchange order id
exchange.cancel_by_cloid("ETH", cloid) # by your own id

The read path

The read tools hit an indexed copy of the chain over GraphQL. The technique is the same one I used to track bonding curves and graduations on Pump.fun, just pointed at a different chain. The useful property is that the same document works as a query and as a live stream: change query to subscription, drop limit and orderBy, point it at the websocket endpoint, and it pushes.

Here is the whole exchange’s fill flow (Trades cube reference), which is the feed you would run in a separate process to keep a market picture warm:

subscription {
Hyperliquid {
Trades {
Block { Time }
Trade {
Market { Symbol CoinRaw Kind }
Execution { Price Size Side Direction IsAggressor Oid }
Fees { Fee FeeToken }
Position { Leverage IsCross SizeBefore }
Trader { Address }
}
}
}
}

No coin filter, so one subscription carries every market. A message looks like this:

{
"Block": { "Time": "2026-09-04T11:19:51.137023Z" },
"Trade": {
"Market": { "Symbol": "ASTER", "CoinRaw": "ASTER", "Kind": "perp" },
"Execution": {
"Price": "0.75677", "Size": "175.0", "Side": "Sell",
"Direction": "Open Short", "IsAggressor": true, "Oid": "535941127746"
},
"Fees": { "Fee": "0.01907", "FeeToken": "USDC" },
"Position": { "Leverage": 5, "IsCross": true, "SizeBefore": "-175858.0" },
"Trader": { "Address": "0xa33a4a057334c7811ad5f45f3c4f0dfa3d081ff8" }
}
}

Two fields there are worth handing to a model. Direction arrives resolved to Open Short, so the agent is not inferring intent from side plus position state. SizeBefore says the wallet was already short 175,858 ASTER before this fill, which is the difference between "someone sold" and "a large short added". A negative Fees.Fee is a maker rebate, which is a cheap way to separate passive flow from aggressive.

For book data the cube to know about is BookUpdates, which is market-by-order rather than aggregated. One message is one order, carrying its Oid and the Trader.Address that placed it. Oid joins across the schema: the same id appears on Orders as the lifecycle and on Trade.Execution.Oid when it fills, so a single order can be followed end to end. Filter it to one address and you are watching a specific market maker quote and pull in real time (worked examples), which is not something a centralised venue will sell you at any price.

Wiring the tools

Claude gets read tools that hit the feed and exactly one write tool that touches the exchange.

import requests
from anthropic import Anthropic, beta_tool
client = Anthropic()
BQ_URL = "https://streaming.bitquery.io/graphql"
BQ_AUTH = {"Authorization": f"Bearer {os.environ['BITQUERY_TOKEN']}"}
ALLOWED_MARKETS = {"BTC", "ETH"}
def bq(query: str, variables: dict) -> dict:
r = requests.post(BQ_URL, headers=BQ_AUTH,
json={"query": query, "variables": variables}, timeout=30)
r.raise_for_status()
payload = r.json()
if "errors" in payload:
raise RuntimeError(payload["errors"][0]["message"])
return payload["data"]["Hyperliquid"]

The liquidation read tool:

@beta_tool
def recent_liquidations(symbol: str, minutes: int = 60) -> str:
"""Count Hyperliquid liquidations on one market over a recent window.
    Returns distinct liquidation events, the wallets hit, and the raw fill
count. Prefer the liquidation count over the fill count.
    Args:
symbol: Market symbol. Must be BTC or ETH.
minutes: Lookback in minutes, 1 to 60.
"""
if symbol not in ALLOWED_MARKETS:
return f"refused: {symbol} is not in the allowlist"
minutes = max(1, min(int(minutes), 60))
    query = """
query ($sym: String!, $mins: Int!) {
Hyperliquid {
PerpLiquidations(where: {
Liquidation: {Market: {Symbol: {is: $sym}}}
Block: {Time: {since_relative: {minutes_ago: $mins}}}
}) {
fills: count
liquidations: count(distinct: Liquidation_Execution_Hash)
wallets: count(distinct: Liquidation_LiquidatedUser)
}
}
}
"""
rows = bq(query, {"sym": symbol, "mins": minutes})["PerpLiquidations"]
if not rows:
return f"{symbol}: 0 liquidations in the last {minutes}m"
r = rows[0]
return (f"{symbol}: {r['liquidations']} liquidations hitting "
f"{r['wallets']} wallets in the last {minutes}m "
f"({r['fills']} individual fills)")

Note the return value is a sentence, not a JSON dump. Tool results are input tokens on every subsequent turn of the loop, and a compact string the model reads correctly beats a nested object it has to parse and might misread.

The write tool is where the care goes:

MAX_NOTIONAL_USD = 250.0
@beta_tool
def place_post_only_order(symbol: str, is_buy: bool, size: float,
limit_price: float, reason: str) -> str:
"""Place one post-only limit order on Hyperliquid.
    Post-only means the exchange rejects the order outright if it would
cross the spread. Rejection is normal and expected, not an error.
    Args:
symbol: Market symbol. Must be BTC or ETH.
is_buy: True to bid, False to offer.
size: Contracts. Notional is capped server-side by this tool.
limit_price: Limit price in USD.
reason: One sentence on why, recorded in the audit log.
"""
if symbol not in ALLOWED_MARKETS:
return f"refused: {symbol} is not in the allowlist"
notional = size * limit_price
if notional > MAX_NOTIONAL_USD:
return (f"refused: ${notional:,.0f} notional exceeds "
f"the ${MAX_NOTIONAL_USD:,.0f} cap")
    cloid = decision_cloid(symbol, is_buy, round(limit_price, 2),
int(time.time() // 60))
audit.write(symbol, is_buy, size, limit_price, reason, str(cloid))
    result = exchange.order(symbol, is_buy, size, limit_price,
{"limit": {"tif": "Alo"}}, cloid=cloid)
if result.get("status") != "ok":
return f"exchange rejected the request: {result}"
    status = result["response"]["data"]["statuses"][0]
if "resting" in status:
return f"resting on the book, oid {status['resting']['oid']}"
if "filled" in status:
return f"filled immediately: {status['filled']}"
return f"not resting, no fill: {status}"

Two decisions in there carry the weight.

The allowlist and the notional cap are Python, not prompt text. A model asked politely to stay under a cap will stay under it nearly every time, and nearly every time is not a risk control. Anything you would be unhappy to see violated once belongs in an if that runs before the order does.

And the tool reports back which of three things happened: resting, filled, or neither. That distinction is not cosmetic, for a reason the next section gets to.

The reason argument is doing quiet work too. Requiring the model to state why, in the same call that places the order, gives you an audit log that explains itself six weeks later, and it costs one extra field.

The loop

You do not have to write the agent loop. The SDK’s tool runner drives the call, execute and continue cycle:

DESK_RULES = """You watch two Hyperliquid perp markets and quote passively.
Doing nothing is a valid and common answer, and most runs should end that way.
Never chase price. Place at most one order per run.
A post-only rejection means your price crossed the spread. Do not resubmit it
at a crossing price; either move the price passive or stand down.
Liquidation counts are events, not fills. Do not treat a fill count as activity."""
runner = client.beta.messages.tool_runner(
model="claude-opus-5",
max_tokens=16000,
thinking={"type": "adaptive"},
output_config={"effort": "high"},
system=[{
"type": "text",
"text": DESK_RULES,
"cache_control": {"type": "ephemeral"},
}],
tools=[recent_liquidations, open_position, place_post_only_order],
messages=[{"role": "user", "content":
"Check BTC. If liquidations are elevated versus a normal hour, consider "
"quoting passively on the side that just got run over. Otherwise do nothing."
}],
)
for message in runner:
log(message)

thinking={"type": "adaptive"} lets the model decide how much reasoning a given run deserves, which matters when most runs should end in "nothing to do here". The cache_control block matters because the rules and tool schemas get resent every turn, and cached reads bill at roughly a tenth of the input rate.

Rough cost. Claude Opus 5 is $5 per million input tokens and $25 per million output. A run that reads about 2,000 input tokens and writes about 1,500 comes to roughly five cents. On a five-minute cadence that is 288 runs a day and roughly thirteen dollars, before caching brings the input side down. That number is worth computing for your own cadence before you leave anything running, because the cost of an agent that thinks every minute is not obvious until the invoice arrives.

Three ways the data will lie to your agent

Every one of these cost me a wrong number before I caught it, and each one produces a plausible wrong answer rather than an error, which is the dangerous kind.

It thinks one liquidation is sixteen

Counting rows on the liquidation feed overstates activity, badly. In one recent hour:

fills:        127
liquidations: 33
wallets: 33
markets: 11

A single XPL position unwind produced 16 rows, all in one block, all sharing one execution hash:

11:27:28.537  Buy  size=  5010.0  px=0.10143
11:27:28.537 Buy size= 490.0 px=0.10142
11:27:28.537 Buy size= 11059.0 px=0.10149
11:27:28.537 Buy size= 28173.0 px=0.10160
... (12 more)

One forced unwind ate 16 resting orders at 16 prices, and the feed gives you one row per fill because that is what happened on chain. An agent told “127 liquidations” when the real number is 33 will read a calm hour as a cascade and quote into it.

Count distinct execution hashes:

fills:        count
liquidations: count(distinct: Liquidation_Execution_Hash)
wallets: count(distinct: Liquidation_LiquidatedUser)

Fix it at the tool boundary where you can see it. A model handed a number labelled count will reason confidently about the wrong quantity and will not flag that it is confused.

It thinks its quote is resting when it was rejected

Count BTC order events by status over ten minutes and the shape is startling:

badAloPxRejected           1,848,618   83.6%
open 150,206 6.8%
canceled 131,269 5.9%
perpMarginRejected 43,063 1.9%
iocCancelRejected 20,579 0.9%
tooManyOpenOrdersRejected 14,775 0.7%
filled 1,608 0.1%
TOTAL 2,210,732

Eighty-four percent of everything that happens to a BTC order is badAloPxRejected, and one tenth of one percent is a fill. Checking what those rejected orders were, every one is a post-only limit order, split near evenly between buys and sells:

Limit  Buy   Tif=Alo   478,047
Limit Sell Tif=Alo 431,349

That is the quoting race on the most liquid market on the exchange: market makers trying to post at the touch, losing, and getting bounced. Two million of those in ten minutes. ETH is the same shape, 78.6% rejected and 0.06% filled.

Your agent is posting Alo orders into exactly that. Rejection is the normal outcome, not the exception, which is why the write tool above distinguishes resting from filled from neither. An agent that assumes its quote is live when the matching engine bounced it will keep reasoning about a position it does not have, and will hedge or size against a phantom.

It also breaks any activity metric you build. If you compute a cancel-to-fill ratio from a bare event count, 84% of your denominator on BTC never reached the book.

It trades the wrong BTC

HIP-3 lets outside builders deploy their own perp markets on Hyperliquid, under a namespace prefix, trading in the same infrastructure. A lot of them are tokenized equities, which is the same land grab Arcus is running at the dYdX team. There are currently 279 live across 10 deployers, the largest being xyz with 119 markets, then para with 33 and hyna with 25.

Query mark prices filtered to the symbol BTC:

flx:BTC     91470.2
hyna:BTC 76888.0
cash:BTC 70000.0

Three builders, three markets called BTC, three prices more than twenty thousand dollars apart, each on its own oracle. If your ingestion keys on Symbol, an agent can read a price from one market and send an order to another. Key on CoinRaw, which carries the full namespace:symbol identifier.

No data provider invented this. It falls out of permissionless market listing, and it will bite anyone who assumes symbols are unique.

State between runs

An agent that only reads the market and never reads itself will drift. Two things need reconciling at the top of every run.

The real position, from the native API rather than from memory:

@beta_tool
def open_position(symbol: str) -> str:
"""Report the agent's actual open position on one market.
    Args:
symbol: Market symbol. Must be BTC or ETH.
"""
state = info.user_state(address)
for entry in state["assetPositions"]:
p = entry["position"]
if p["coin"] == symbol:
return (f"{symbol}: size {p['szi']}, entry {p.get('entryPx')}, "
f"unrealized {p['unrealizedPnl']}")
return f"{symbol}: flat"

And the resting orders, so the agent does not stack five quotes across five runs because each run forgot the last. info.open_orders(address) covers this, and a cheap policy that works well is to cancel everything the agent placed at the start of a run and requote from a clean book.

Feed both in as tools rather than as prompt text. The model then reads current state at the moment it needs it, instead of trusting a snapshot you pasted in at the top of the turn that may already be stale.

Running it without losing money

constants.TESTNET_API_URL is not decoration. Moving off it should be a separate, deliberate commit made after the thing has run for a couple of weeks and surprised you at least once.

Some specifics that are worth more than a paragraph of general caution.

Expect it to do nothing. Exchange-wide, Hyperliquid liquidates in the low tens of positions an hour, and BTC alone can go four hours without a single one. An agent gated on BTC liquidations will correctly sit still on most runs. That is the right way round to test it: watch it decline to act on a quiet market before you point it at a busy one.

Keep the kill switch outside the process. A supervisor you can kill -9, or an exchange-side cancel-all you can fire by hand, beats any instruction in a system prompt. The system prompt is guidance. The process boundary is a guarantee.

Log the tool calls, not just the outcome. An agent that placed a strange order is only debuggable if you can replay what it saw when it decided. Arguments and results, every call, including the refusals from your own guardrails, since a spike in refusals is the earliest signal that the reasoning has gone somewhere odd.

Cap what one run can do, not just one order. The notional cap above limits a single order. A run that places one order twenty times is still within that cap and nowhere near safe.

Where this approach is weaker than the alternatives, plainly. The indexed feed sits behind the matching engine by an indexing step, so anything reacting in single-digit milliseconds belongs on the native websocket instead. The GraphQL window is a rolling thirty days or so, which covers live trading and recent-history checks but not a multi-year backtest. And the highest-volume cubes, Orders and BookUpdates, run to hundreds of millions of rows a day on a busy market, so filtered scans over long windows time out; keep interactive windows to an hour and accumulate anything longer in your own store.

What this is and is not

This is plumbing. Nothing above tells you what to trade or suggests you should, and a language model wired to a market data feed is not an edge. It is a way to act on one you already have, and equally a way to act on a bad idea faster than you could by hand.

What Hyperliquid genuinely changes is the input. On a centralised venue your agent reasons about price and its own fills, because that is all the exchange will sell you. Here it can reason about who is positioned where, which quotes are real, and who just got carried out, because the book is on a public chain and the wallet is attached to every order.

The reasoning layer is the easy part now. Getting clean, correctly counted market state into it is the work, and three of the traps are above.

Docs for the read-path queries: Hyperliquid API on Bitquery. The native API and SDK: hyperliquid.gitbook.io. Every figure was pulled live on 4 September 2026 and will have moved by the time you read this.

Disclosure: I work on developer content at Bitquery, which sells the indexed feed used for the read path. The write path is Hyperliquid’s own free SDK, and the sections on latency, history depth and query limits are there because they are real constraints.


Building an AI Crypto Trading Bot on Hyperliquid was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Seattle Times sues Microsoft and OpenAI, alleging they trained their AI on its journalism

4 September 2026 at 21:50
The Seattle Times and Newsday sued Microsoft and OpenAI on Friday, accusing the tech companies of using their journalism to train AI products without permission. (GeekWire File Photo / Kurt Schlosser)

Microsoft was sued Friday by the parent company of its hometown daily newspaper, The Seattle Times Co., which joined with Newsday to accuse the Redmond tech giant and OpenAI of using their journalism to train artificial intelligence models.

The lawsuit alleges that the companies scraped hundreds of thousands of Seattle Times and Newsday articles — bypassing paywalls and ignoring terms of service — to train their AI models. It seeks financial damages and the destruction of any training datasets and models built with their content.

“Like a snake eating its own tail, GenAI that is trained on painstakingly researched, expensive-to-produce content threatens to destroy the very news organizations by competing directly with them through AI-generated substitutive content,” the suit says. “If Defendants are allowed to succeed, independent journalism of the kind Plaintiffs produce will struggle to survive.”

The case is notable in part because the Seattle Times is suing two of its own funders. Microsoft Philanthropies underwrites some Seattle Times journalism projects. In 2024, Microsoft and OpenAI jointly funded a $10 million Lenfest Institute AI fellowship that included both the Seattle Times and Newsday among its inaugural participating newsrooms. The Times says it maintains editorial independence.

A Microsoft spokesperson said in a statement Friday evening, “While we’re surprised by the lawsuit, we appreciate the importance of the Seattle Times to our region and we’re always happy to sit down and explore solutions to this type of dispute.”

It’s not clear if there were negotiations or licensing talks in advance of the suit. GeekWire has contacted The Seattle Times Co. for comment.

In its own coverage of the lawsuit Friday evening, the newspaper quoted a memo from Seattle Times Co. President and CEO Alan Fisco, saying: “This was not an easy decision. However, we feel strongly that we must defend our content — which we spend millions of dollars a year to produce — from being used without our consent or compensation.”

The Seattle Times Union, which represents more than 160 newspaper employees, said Friday it supports the lawsuit but that in ongoing contract negotiations the company has refused to guarantee it won’t replace non-reporter newsroom jobs with AI.

“If the Seattle Times Co. truly cares about the threat AI poses to journalism’s business model, it should protect the workers who produce the copyrighted material at the heart of this case,” the union said in a statement.

Fisco, a longtime Seattle Times executive, took over as CEO on Jan. 1, succeeding Frank Blethen, who led the paper for 40 years and remains chair of the board. Ryan Blethen, Frank Blethen’s son and a fifth-generation member of the family that has owned the paper since 1896, became publisher in the same transition.

The complaint Friday includes examples of ChatGPT reproducing Seattle Times and Newsday journalism nearly word for word, including an 88-word verbatim stretch from The Seattle Times’ Pulitzer-winning coverage of the Boeing 737 MAX crashes, generated when a user prompted the chatbot with just the article’s headline and web address.

The suit echoes The New York Times’ 2023 copyright case against the same defendants, which just this week drew a U.S. Justice Department brief siding with Microsoft and OpenAI, arguing that a ruling for the publishers would stifle American AI development.

The newspapers join a growing list of publishers suing OpenAI and Microsoft over AI training. In addition to the New York Times, that includes the New York Daily News, Ziff Davis and the Center for Investigative Reporting, all consolidated before U.S. District Judge Sidney H. Stein in Manhattan.

On Friday, the publishers in that case moved for summary judgment, as did OpenAI and Microsoft.

OpenAI has struck licensing deals with more than a dozen other outlets, including The Associated Press, News Corp and Axel Springer. Publicly disclosed terms of three of those deals top $300 million, according to the Seattle Times complaint.

Updated with statement from The Seattle Times Union.

OpenAI Pledges $1 Billion to Bring Frontier AI to Critical Infrastructure Defenders

4 September 2026 at 12:07

The Daybreak initiative will provide subsidized AI cyber capabilities, training and technical assistance, though OpenAI has disclosed few details about costs and eligibility.

The post OpenAI Pledges $1 Billion to Bring Frontier AI to Critical Infrastructure Defenders appeared first on SecurityWeek.

This Week in Security: Baked-in Malware, Freezers Not Freezing, Zoom Snoops Clipboards, and AI Makes Things Worse, Faster

4 September 2026 at 10:00

The AI platform ServiceNow which offers both hosted and on-premises versions just patched a trifecta of CVSS-10 vulnerabilities.

CVSS rankings are determined by the severity of a flaw, the ease of exploiting the bug, if authentication is required for exploitation, if the vulnerability exposes confidential data, and other criteria. A CVSS of 10 is as bad as it gets, and having three of them at once is certainly attention-getting. Of the three vulnerabilities fixed, one allowed unauthenticated modification of data in the hosted instance, a second allowed arbitrary code execution via the GraphQL interface, and the third allowed arbitrary SQL commands that could modify the database.

ServiceNow claims Adobe, Lenovo, Fedex, and Fujitsu among their high-profile customers. With luck, the vulnerabilities were patched before significant public exploitation could happen.

Router Malware

Previously in 2026 the US Government warned against embedded malware found in consumer routers, which may be linked to the FCC enacting bans against certification and import of foreign-made consumer devices. This week, the NVD (National Vulnerability Database) reported specific embedded malware in the Zbtlink and MoreQuick brands of devices.

Multiple versions of the firmware, for multiple lines of products, contain a backdoor service that uses unencrypted UDP to connect to a command and control (C2) service. The service, or anyone able to intercept the network traffic, since it’s unencrypted, can execute commands as root, allowing them to change configurations, open tunnels, or steal ISP credentials.

The malware is baked into the firmware, so removing it is impossible for most users: a factory reset wouldn’t do. In theory if third-party firmware like OpenWRT supports these devices, the hardware could be made safer with a custom install.

Given how commonly the same device is marketed under dozens of names, likely the same devices and firmware have yet to be identified under other brands.

Vulnerability in Qubes

The security-focused distribution Qubes has an important security bulletin for recently discovered issues.

Qubes is built on top of the Xen virtualization system, where each application can be given a dedicated container. The utility to copy files from the primary container into an application container, qvm-copy-to-vm, displays a message if there is an error copying the file. To show the message, the utility launches kdialog with the error as arguments, but fails to ensure that the error doesn’t include shell commands.

The system call used to show the alerts has the dangerous side effect of calling the command as if it was a normal shell. This is extremely powerful, but equally risky: a shell typically allows multiple commands per lines, require quoted strings to protect arguments with spaces or complex text, and can expand variables. Generating an error that escapes out of the message and runs arbitrary commands was all it took.

Qubes already has a fix ready and everyone getting standard updates should have it waiting.

Were US Military Freezers Hacked?

The controls for the freezers used in the commissaries of a growing number of US military bases may have been compromised.

Independent researchers noticed growing reports in Reddit threads that freezer units were out of service, with other service members and families reporting the same. At least fourteen bases throughout the United States appear impacted, and the story has been picked up by the official military newspaper “Stars and Stripes” as well as by mainstream media outlets.

Posts by staff at the bases clarify that it was not a power loss or cooling loss, the fridges and freezers were placed in defrost mode where they self-heated. The commissaries are operated by the Defense Commissary Agency, with central monitoring and control of facilities. Central monitoring makes complete sense when you need to ensure devices are keeping food at a safe temperature, but something definitely seems to have gone wrong.

Diving into it further, M. Elizabeth finds a post from August 9, 2026 describing vulnerabilities in the Danfoss controllers that allow unauthorized access to the refrigeration controller, and a second paper by the same team exposing over 20 vulnerabilities in Copeland refrigeration controllers that included full control of the unit settings. M. Elizabeth is careful to point out that without confirmation from the commissary agency, it’s impossible to know for sure that this was a hack of the control system, but the evidence is mounting.

BGP and SSL Hijack Used to Push Bad Updates

Virtualizor, a web interface for managing virtual machines in an enterprise (bring-your-own AWS), was recently targeted in a global route hijacking scheme.

Border Gateway Protocol (BGP) is a core routing system underlying the Internet at large. Service providers use BGP to announce the ranges of IP addresses they handle and how to reach them. BGP is operated as basically a global gentleman’s agreement: the protocol itself lacks any authentication or encryption. If you think this sounds vulnerable to disruption, you’d be completely right.

Global disruptions have happened accidentally, like when an ISP in Pakistan took down YouTube, deliberately, such as when thieves hijacked the routes to cryptocurrency exchanges, and mysteriously, like when China hijacked parts of the Internet repeatedly with no explanation.

This time, the BGP attack targeted the IP range used by Virtualizor, and was combined with spoofed SSL certificates for the Virtualizor servers to push spoofed updates. The BGP announcement was targeted to a specific class C: a relatively small allocation of 253 addresses, similar to what a home network would use. BGP gives precedence to the smallest announcement for an IP range, so all systems that received the spoofed announcement routed those addresses accordingly. The network advertising the false route was based in Romania, though of course they could also be a victim.

With control over the IP range, the attackers were able to generate a certificate via Lets Encrypt, which was sufficient for browsers and the updater to accept the rerouted addresses. The attackers then published a malicious package that appears to install additional services. The company has not provided details about the trojaned update, so it’s not clear what other risks it poses.

Virtualizor does not have a public list of customers, but one has to assume it includes high-profile companies to make such an attack viable. Hijacking BGP is extremely obvious, and isn’t frequently used for such obvious spoofing attacks.

Linux Zoom Steals Clipboard Contents

Simon Tatham, the author of the extremely popular PuTTY SSH client among other projects, posted on Mastodon an interesting observation about the clipboard behavior of recent Zoom clients on Linux.

Relatively recently, some operating systems have added the ability to alert the user when an application access the clipboard. Unfortunately, Linux is not yet one of them, but thanks to other clipboard management tools, Simon noticed that the recent update to Zoom 7.1.5 copies the contents of the clipboard as soon as they change. What happens to the clipboard contents once copied is currently a mystery.

Considering that the clipboard can often contain passwords, authentication tokens, or simply data you might not want to share with Zoom, automatically scraping the contents isn’t what you’d hope for.

Plex Vulnerabilities

The Plex media streaming software sent out an advisory this week warning about security updates for the server and desktop application.

Details are currently thin, with the promise of future details once CVEs have been assigned. For now, make sure you’re on version 1.43.4 or newer. The Plex post has additional directions for updating on platforms that may not have pushed new packages yet.

AI Accelerates Exploit Development

Security company CrowdStrike has released their 2026 report on threats, focusing on the proliferation of AI tools in exploit writing.

CrowdStrike observed that 88% of exploits happened with 48 hours of the proof of concept code being released, crediting AI tools for shortening the adaptation. Typically proof of concept code is designed to demonstrate the vulnerability without providing an immediate mechanism for malicious use, and the window from exploit announcement to wide-spread risk was on the order of weeks. The report notes some vulnerabilities being widely exploited in 20 hours after public disclosure.

The tightening window makes patching even more important, but rapid patching caries the risk of instability when the patches themselves haven’t had extensive testing. Unfortunately there’s no simple solution; faster exploitation via AI tools drives faster patching, often also with AI tools that can introduce more bugs as well.

❌
❌