Protecting Your Pipelines from the Axios Dependency Vulnerability

[#1]

Overview

On March 31, 2026, a critical supply-chain vulnerability was identified in versions 1.14.1 and 0.30.4 of the axios npm package. See CVE-2025-27152 for full details.

This is not a vulnerability in Bitbucket Pipelines itself. However, if your pipeline builds, installs or depends on a compromised version of axios (directly or transitively), your pipeline environment and the secrets accessible to it may have been exposed, just as your local environment could have been.

Below is a list of recommended steps for you to consider, to help assess your exposure and secure your environment.

1. Upgrade axios to the latest patched version

Check whether any of your pipeline builds resolved a vulnerable version of axios. You can review your package-lock.json, yarn.lock, or build logs for the affected version(s).

Action:

• Determine your exposure: identify and document all affected repositories.

• Upgrade axios to the latest patched version as recommended in the CVE-2025-27152 advisory. If axios is a transitive dependency, update the parent package or use dependency overrides/resolutions to force the safe version.

2. Expire Pipeline Caches

Compromised dependencies may have been persisted in your Bitbucket Pipelines caches, meaning future builds could continue using the vulnerable package even after you update your lockfile.

Action: Delete all pipeline caches associated with affected repositories. You can do this via:

• Repository Settings → Pipelines → Caches, or

• The Bitbucket REST API: DELETE /2.0/repositories/{workspace}/{repo_slug}/pipelines-config/caches/{cache_uuid}

3. Review resources accessed via OIDC Credentials

If your pipelines use OpenID Connect (OIDC) to authenticate with cloud providers (e.g., AWS, GCP, Azure), the identity tokens issued during compromised builds may have been exposed.

Action: Review actions taken in your OIDC providers. Consult your cloud provider's documentation to review any access or actions taken

4. Rotate Pipeline Variables

A compromised dependency running within your pipeline has access to all environment variables injected into that build step, not just the ones explicitly consumed by your scripts.

Action: Rotate all secured variables accessible to the affected pipelines, including:

• Repository variables

• Workspace variables

• Deployment environment variables

Do not limit rotation to only the variables you believe were used. Assume all were potentially exfiltrated.

5. Remove Artifacts from Compromised Builds

Build artifacts produced by a compromised pipeline should be considered untrusted. These may include published packages, container images, or deployment bundles.

Action:

• Delete any artifacts stored in Bitbucket from affected pipeline runs.

• If artifacts were published to external registries (npm, Docker Hub, etc.), remove or replace them with builds from a verified-clean pipeline.

• Audit any deployments that consumed these artifacts.

6. Review Self-Hosted Runners

If affected pipelines executed on self-hosted runners, the runner environment itself may have been compromised.

Action:

• Inspect runner hosts for unexpected processes, files, or network activity.

• Preferably, deprovision and recreate any runners that executed compromised builds.

• If using containerised runners, ensure the runner image and any cached layers are rebuilt from a trusted base.

7. Review Downstream Integrations

If your pipelines trigger deployments, update external services, or push to other repositories, any credentials or webhooks used in those integrations should also be reviewed.

Action: Audit and rotate tokens/keys for any third-party integrations invoked by affected pipelines (e.g., deployment targets, notification webhooks, API keys for SaaS services).

---

Note: The items listed here highlight key recommendations for Bitbucket Pipelines usage and configuration. They are not exhaustive and do not include every action that may be necessary in your particular infrastructure or deployment environment. Please review and adapt these recommendations according to your organisation’s security, compliance, and operational requirements.