The Week's Attacks Were Cheap, Ordinary, and Very Effective
Opening a repo, installing a package, or previewing a PDF was enough to hand attackers a foothold this week. None of it was sophisticated. All of it worked.
Key points
- Attackers this week relied on everyday actions: opening a code repository, installing a software package, or previewing a PDF file was enough to trigger a compromise.
- Exposed servers left facing the public internet, recycled old bugs, and default settings that quietly favour attackers made up most of the week's incidents.
- AI assistants were tricked into running hostile instructions hidden inside documents they were asked to read.
- Remote-access tools, the same kind IT support desks use, were dressed up as legitimate software to slip past staff.
- The pattern, first pulled together by The Hacker News in its weekly roundup, is that none of these attacks needed a rare or exotic flaw to succeed.
Opening the file is the attack now.
That is the uncomfortable thread running through this week's incidents. A software developer clones a code repository, which is just a folder of project files shared online, and hostile code runs before they type a single command. A engineer installs a package from a public library, and buried among hundreds of legitimate dependencies is one that phones home. A worker double-clicks a PDF to check an invoice, and that is game over.
None of this is clever. That is the point.
So what actually happened this week?
The short version: attackers used cheap, well-known tricks and got results. Servers left exposed to the public internet with no authentication. Bugs that were patched months or years ago but never updated on production systems. Malicious software packages uploaded to public registries under names that look almost identical to real ones.
We have seen every one of these before. We will see them next week too.
The reason they keep working is boring. Platform teams under pressure ship first and lock down later. Default configurations in cloud services, things like AWS S3 storage buckets or GCP service accounts, tend to favour convenience over safety unless someone actively changes them. Nobody gets paged for a permission that is too generous. They get paged when the deploy breaks.
How are AI assistants getting caught up in this?
A new failure mode is showing up: prompt injection. That is a mouthful, so here is the plain version. Companies are giving AI assistants the ability to read documents, browse pages, and take actions on a user's behalf. Attackers have worked out that if you hide instructions inside a document, like white text on a white background in a PDF, the AI will read those instructions and follow them.
The user asked the assistant to summarise a contract. The document told the assistant to email the contents somewhere else. The assistant did both.
In practice, this is the same class of problem as a macro in a Word document from twenty years ago. We just gave it a chatbot interface and called it agentic AI.
What about the remote-access tool angle?
Attackers keep dressing up legitimate remote-support software, the kind help desks use to fix your laptop from three cities away, as something else. A fake update. A support pop-up. A PDF that installs a "viewer." Once the tool is on the machine, the attacker has hands on keyboard, and every security product on the endpoint sees a signed, legitimate application doing signed, legitimate things.
The failure mode here is trust. These tools are allow-listed everywhere because IT needs them. Nobody is watching who else installs them.
The pattern, in one table
| Attack type | What triggers it | Why it works |
|---|---|---|
| Malicious repo | Opening the project | Build scripts run automatically |
| Poisoned package | Installing a dependency | Nobody audits hundreds of transitive packages |
| Weaponised PDF | Previewing the file | Default handlers execute embedded content |
| Prompt injection | AI reads a document | Assistant treats hidden text as an instruction |
| Fake support tool | User clicks install | Legitimate software, allow-listed by default |
Should ordinary people worry?
Mostly, no. These attacks target developers, IT staff, and companies. But two habits help anyone. Do not install software from a pop-up or an email attachment, even if it looks like a support tool. And if an AI assistant at work can read your files and send emails, ask whoever runs it what stops a document from telling it to do something you did not ask for.
One thing the post-mortem will say, on almost every one of these: the default was wrong, and nobody changed it.
Operational takeaway: if your platform's safe path is not also the easy path, your engineers will find the easy path, and so will the attackers.
