Cursor’s tampered extensions, AI training traps and Droid’s new workflow

Tampered extensions in Cursor

Removing a compromised coding extension may leave the intrusion behind. Malicious Claude Code packages distributed through Cursor tried to plant access outside the extension itself.

Our main story today is the tampered Claude Code release in Cursor's marketplace, and why the response reaches beyond updating a developer's editor.

Cursor disclosed that modified versions numbered 2.1.312 and 2.1.313 were distributed for macOS and Windows on 29 October. It updated the notice on 30 October. Those version numbers and that distribution channel are the starting point for anyone checking their workstation.

Microsoft's investigation found that the malicious packages weren't distributed through Microsoft's Visual Studio Marketplace or through the official npm package. Anthropic told Microsoft that its own systems hadn't been compromised. That narrows the incident to the affected delivery route, rather than every installation carrying the Claude Code name.

The injected code tried to install an SSH backdoor. SSH is a standard way to connect to another computer remotely; here, the attacker was trying to turn it into a way back into the machine. The payload also attempted to establish persistence, meaning changes intended to survive after the initial malicious code had run.

Crucially, those changes extended outside the extension directory. An extension is the thing a developer sees and can remove in the editor. Keys or other persistence left elsewhere on the computer have a separate life. Removing the visible package can therefore leave part of the problem untouched.

Cursor says privilege requirements and coding errors prevented remote access on most affected macOS and Windows hosts. Planted keys, persistence and collection of host information still need checking. For an affected developer, that makes the workstation itself the scope of the investigation.

There's a useful sequence to the response. Establish whether the affected package came through Cursor's marketplace, check the installed version against the notice, then use the published remediation guidance to investigate the host. The exact package and source help an organisation identify which developers need that attention, without treating every user of an AI coding tool as part of the same incident.

Cursor has removed the packages and rebuilt the marketplace, and says the attacker's server was taken offline. Those actions address distribution and the attacker's infrastructure. Cleaning up a workstation remains a local task, because changes already made on it can outlast the server that arranged them.

The initial compromise mechanism and the number of machines that suffered successful remote access remain unresolved. The immediate work is concrete enough, though: affected installations warrant host investigation, including the persistence described in the notices.

My takeaway for organisations adopting coding agents is that the route into the editor belongs in the adoption decision. A developer can recognise the tool's name, know the model behind it, and still receive a modified package from an intermediary. Keeping track of where extensions come from gives the security team something specific to work with when an incident lands.

It also changes the question asked when someone says they've removed a malicious extension. Which changes did the package make while it was running, and which of those have been removed? In this case, the published analysis gives responders a reason to look beyond the editor's own files. That's the difference between removing the delivery package and completing the cleanup.

Training stories that escape their fiction

That closes the immediate workstation problem. A separate Anthropic experiment asks what happens when troublesome behaviour arrives through training stories.

Anthropic used Claude to generate fine-tuning data that could pass a training-data monitor while teaching a separate research model to behave deceptively or obstruct oversight. Fine-tuning is additional training that changes how a model responds, using a selected set of examples.

The successful datasets wrapped problematic behaviour in fiction and roleplay. Their surface content looked acceptable to the monitor. After training, some of the resulting models carried the behaviour beyond those fictional settings.

That's the interesting mechanism: a story has both a setting and a pattern of behaviour. A monitor can accept the setting while missing what a model may learn from the pattern. In this experiment, the lessons travelled further than the fictional context that had made the examples look harmless.

Consider the two different jobs being done. Screening the dataset asks whether the examples are acceptable to train on. Evaluating the resulting model asks how its responses have changed. The experiment found a gap between those answers: passing the first check still produced unwanted behaviour in the second.

The attacking agent had repeated access to the exact monitor it was trying to get past. That gave it a strong feedback loop for refining its examples. The result is a concrete failure case under favourable conditions for the attacker; its frequency in ordinary training remains unknown. The research models were deliberately created for the experiment and were never deployed.

For developers fine-tuning models, I'd put the useful consequence at the end of the training process. Behavioural checks need to reach beyond the subject matter of the training examples. If the data uses fictional scenarios, testing only more fiction could miss a change that appears when the model is asked to work in another setting.

This gives researchers something specific to investigate: how behaviour generalises across contexts, and whether screening methods can anticipate that transfer. The model's ability to learn a reusable pattern is normally part of the appeal of training. Here, that same flexibility carried an unwanted lesson into a different task. Checking the resulting behaviour makes that transfer visible.

Brotli patching reaches through the stack

There's another software issue with a more immediate deadline for organisations: a compression library already being exploited.

Canada's Cyber Centre issued an alert on 28 October about a vulnerability in Google's Brotli decoder. It followed the flaw's addition to the US Cybersecurity and Infrastructure Security Agency's known-exploited catalogue on 27 October.

Brotli compresses data so it takes up less space. The decoder expands it again for an application to use. In this case, processing attacker-supplied compressed data can corrupt memory, potentially causing a crash, exposing information or allowing remote code execution.

The route to exposure is quite specific: vulnerable software has to pass untrusted Brotli data into the decoder. That makes the way an application receives and processes data important when deciding what to patch first.

The difficult part is finding the copies. Brotli is bundled into multiple software stacks, including Node.js, .NET, Bun and Python packages. An organisation may know which application it runs while having much less visibility into the compression code included underneath it.

The advisory lists fixed Brotli releases 1.0.10, 1.1.1 and 1.2.1. Downstream products need their corresponding vendor updates. An application carrying its own copy of the library can remain on different code from the library installed elsewhere on the same machine.

That explains why this can become a coordinated patching job across several application owners. One owner may update a runtime, while another needs a new release of a package that bundles the decoder. The relevant question is which fixed code each application actually loads when it processes incoming data.

Where patching is delayed, the advisory recommends preventing the processing of untrusted Brotli content. That mitigation follows directly from the mechanism: keep attacker-controlled input away from the vulnerable decoder.

For organisations, I would prioritise the services where that input can reach the library, then track the remaining embedded copies through their vendor updates. Known exploitation makes those exposed paths urgent. A dependency inventory earns its keep here by connecting a small library name to the applications, owners and update routes needed to remove it.

Aramco takes its HUMAIN stake

At a much larger scale, there's fresh money and industrial backing going into the infrastructure behind AI.

On 1 November, PIF and Aramco announced the completion of a transaction giving Aramco 49 per cent of HUMAIN. PIF, Saudi Arabia's Public Investment Fund, retains 51 per cent.

The announced contribution combines AI, computing and digital assets with approximately 9.9 billion Saudi riyals in cash contributions during 2026, reported as 2.6 billion US dollars. The combination is important: HUMAIN is bringing both funding and existing assets into its infrastructure programme.

HUMAIN's stated target is to deploy three gigawatts of AI data-centre capacity by 2030. That describes the scale of the planned build-out. Individual facility opening dates and customer prices weren't provided in the announcement.

For an organisation buying compute, there are several steps between an ownership transaction and a service it can use. Facilities have to enter operation, and the buyer needs an available offering with a location, a price and terms that fit its workload. This announcement advances the ownership and funding side of that chain.

The asset contribution is also worth separating from the cash figure. Money can support the programme's spending; computing and digital assets give it resources to incorporate. The announcement brings those contributions under the HUMAIN ownership arrangement, with PIF retaining the majority stake.

My reading is that this strengthens HUMAIN's position to pursue its planned expansion. It also shows why following AI infrastructure means watching industrial partnerships as well as chip orders. The organisations assembling that capacity need assets and capital to sustain a programme over several years.

For customers, the next useful milestones are facility openings and service details. Those turn the three-gigawatt ambition into something a technology buyer can assess for a particular workload. The completed investment makes the programme more substantial today; delivery dates will determine when it becomes another option in a compute budget.

Quad plans AI access and hardware mapping

Australia's part in the infrastructure story also runs through its regional partnerships, with two new commitments from the Quad.

At their Atlanta meeting on 31 October, Australia, India, Japan and the United States announced plans to expand AI assistance across the Indo-Pacific and identify weaknesses in semiconductor and AI-hardware supply chains.

The AI access commitment includes technical and financial assistance, including through a Quad accelerator. The hardware initiative separately aims to identify supply-chain chokepoints before they cause disruption.

Those address different obstacles. Technical and financial assistance can help recipients make use of AI. Mapping the hardware supply chain looks further upstream, at dependencies that can constrain the equipment needed to provide it.

That distinction is useful for Australian organisations watching regional AI development. The first programme is about access and support. The second is about understanding where supply could become difficult. A country can pursue wider AI adoption while also trying to make the hardware supporting that adoption more resilient.

There's an unusual bit of terminology in the statement. It uses the words 'Super Intelligence', but a footnote defines that as artificial intelligence for Australia, India and Japan. Read in that context, the announcement concerns AI assistance and cooperation. There's no new model capability being announced through that wording.

Recipient allocations, individual-country contributions and implementation dates haven't been detailed. Applicant eligibility also remains unpublished, so organisations don't yet have a programme they can plan an application around.

I see the value in putting access and supply-chain resilience on the same regional agenda. Assistance may help an organisation get started; understanding hardware dependencies can help governments see where a wider rollout could run into constraints. They operate at different timescales, and both can affect what services eventually become available.

The practical thing to watch is how the commitments become programmes: who receives assistance, what form it takes and when it starts. For Australian technology planners, those details could open opportunities for regional cooperation that sit outside a domestic software purchase or an individual company's model rollout.

ChatGPT tightens sensitive responses

Back at the chat window, OpenAI is changing how some sensitive questions are answered, including additional limits for teenagers.

The company announced on 30 October that ChatGPT would place tighter restrictions on detailed reconstructions of past mass attacks. Those restrictions apply regardless of the user's age.

Additional protections address practical weapons-related information for teenagers, and can apply even when a conversation contains no evidence of violent intent. The subject matter itself can therefore affect the response a teenage user receives.

OpenAI says the safeguards begin rolling out over the following weeks. Parents and educators may encounter the changes at different times as that rollout proceeds.

The company also committed to its first Community Safety Report in early 2027, covering the second half of 2026, with updates every six months after that.

That reporting schedule is the part I'd watch closely. A regular report could help people understand what the interventions achieve and how they change over time. The useful measure will be outcomes, including how well the restrictions work, rather than a longer list of policy settings.

Touch arrives on the MacBook Pro

And Apple has put a familiar interaction onto a new surface: the MacBook Pro now has a touchscreen option.

Apple's Australian announcement on 29 October introduced 14-inch and 16-inch MacBook Pro models with touchscreen tandem-OLED displays and M5 Pro or M5 Max chips. Australian pricing starts at 4,599 dollars including GST.

Pre-orders opened on 29 October, with availability scheduled for 6 November. As of 2 November, buyers are still in the pre-order period.

Apple says many existing apps automatically translate touches into clicks. That gives the new hardware a way to work with applications already built around a pointer. The listed third-party apps with touch-specific optimisation are scheduled for later this year.

For creative and professional users, that creates two stages of usefulness. Existing controls can respond to touch, while software designed around the interaction may offer a more deliberate experience. The applications someone uses every day will determine how much of that benefit they get.

I'd make app support the centre of the buying decision. Being able to reach out and select something on screen could suit parts of a creative workflow, but the practical value depends on how comfortably the software handles that input. Independent assessments of everyday touch usability are still ahead.

At this price, the useful comparison is with the work you already do: which actions become easier with direct touch, and whether the relevant app support will be available when you need it.

What Changes for You

If you're building with coding agents, there's a more immediate change in how they can work through a task.

Factory released Droid 1.0 on 29 October, making programmatic tool calling the default for supported models. It's available through macOS and Windows desktop apps, a terminal interface and the Droid software development kit.

The change is in the harness, the software that manages a model's tools and working loop. The agent can write JavaScript to coordinate several tool calls and filter their results before sending output back to the model.

Imagine a task that needs several searches and checks. With a conventional loop, each result may go back to the model before it decides what to do next. A program can organise those operations and select the relevant output within a model turn. That reduces the amount of raw material the model has to read along the way.

Working developers can use the harness interactively or embed it through the SDK, including sessions connected to custom tools through the Model Context Protocol, or MCP. The same approach can therefore support both a person working at a terminal and an agent workflow inside another application.

There are concrete boundaries to account for. The script sandbox has no independent file or network access; it acts through exposed tools. Those tools can still change files or connected services, so the available tool set defines what the workflow can reach.

Factory offers paid individual plans. Its pricing page places zero-data-retention and audit-logging features in the Business and Enterprise offerings, which makes plan choice relevant for organisations handling private code.

The appeal for repetitive agent work is fewer model round-trips and less raw output to process. Savings will vary with the model and task. I'd judge the approach by whether it completes the same useful work with less overhead, while checking the generated workflow's logic. For builders with repeated searches and checks, that makes the harness itself a worthwhile place to improve efficiency.