What to look out for today
Heightened risk of malicious or tampered open-source packages entering websites, apps, integrations and internal tools via normal developer workflows (Composer/Packagist and JavaScript tooling). If you rely on a web agency, outsourced developers, or an MSP that builds/maintains software for you, this is relevant even if you don’t “write code” in-house.
Why this matters to smaller businesses
- SMEs often depend on third-party websites, plugins, and integrations that are updated frequently.
- A single compromised dependency can lead to website compromise, data theft, credential capture, or server infection, which then creates downtime and incident cost.
- Even charities and schools can be affected if their suppliers pull in compromised packages during routine maintenance.
Warning signs
- Unexpected website or application behaviour shortly after an update or “minor maintenance”.
- New or unfamiliar background processes on Linux servers, or unexplained spikes in CPU/network usage.
- Build/deployment pipelines behaving oddly (new steps, unusual downloads during builds, or new outbound connections).
- Suppliers reporting they need to “urgently roll back” a release without a clear explanation.
How attackers may exploit the situation
- Compromise or publish malicious packages that get pulled into builds automatically by developers, agencies, or CI/CD systems.
- Hide malicious changes in less-scrutinised places so the dependency appears normal at first glance.
- Abuse the trust chain: once inside a build, malware can end up on production servers or inside deployed web apps.
What to do today
- Ask your website/app supplier (or internal dev lead) if they use Packagist/Composer and JavaScript build tooling, and what checks they have for dependency tampering.
- Pause “non-essential” releases if you can’t validate dependencies today, especially for public-facing web apps.
- Ensure you have a known-good rollback (backups + deployment artefacts) for your website and key services.
- If you outsource development: request written confirmation that any impacted dependencies have been checked and that builds are not pulling unexpected binaries or downloads.
Ask your IT provider
- Do we have an inventory of our critical applications and who maintains them (internal vs agency vs MSP)?
- What controls do we use to prevent compromised dependencies entering production (e.g. approvals, locking/allowlisting, scanning, or controlled registries)?
- Can we quickly identify what changed in the last release (dependencies, build steps, deployment artefacts)?
- If we suspect a supply-chain issue, what is our containment plan (freeze deployments, rotate secrets, rebuild from clean sources, monitor servers)?
Patch watch - only one short paragraph, and only if relevant
One positive change: npm has introduced stronger publishing and install controls that require a human maintainer to pass a two-factor authentication challenge to approve releases (staged publishing). If you develop software or maintain web applications, it’s worth checking whether your teams and suppliers are adopting these safer publishing/approval workflows.
One action today
Contact whoever maintains your website/app today and ask them to confirm they have checked for compromised third-party dependencies in recent builds (especially Packagist/Composer and JavaScript tooling) and that they can roll back quickly if needed.
Related Actions On Cyber resource
Actions On Cyber: Supplier Security Checklist (questions to ask your MSP/web agency about updates, access, and incident response)
Sources
- Packagist Supply Chain Attack Infects 8 Packages Using GitHub-Hosted Linux Malware (The Hacker News)
- npm Adds 2FA-Gated Publishing and Package Install Controls Against Supply Chain Attacks (The Hacker News)
This brief is for general awareness and does not replace advice from your IT provider, legal adviser, insurer or incident response specialist.