Weights & Biases Attack Surface

Security analysis of Weights & Biases (W&B/wandb): API key exposure, experiment data leakage, team boundary violations, artifact poisoning, and attack techniques specific to the W&B platform.

Weights & Biases Attack Surface

Weights & Biases (W&B) is one of the most widely adopted experiment tracking platforms in ML, used by research labs and production teams alike. Its extensive integration surface -- spanning training frameworks, cloud providers, and CI/CD systems -- creates a correspondingly broad attack surface. W&B's design philosophy of "log everything" maximizes reproducibility but also maximizes the amount of sensitive data that flows through and is stored by the platform.

API Key Exposure

W&B API keys are the primary authentication mechanism and the most common entry point for attackers. A single API key grants access to the user's entire entity (personal or organizational), including all projects, runs, artifacts, and reports.

Where API Keys Leak

Exploitation

Once an API key is obtained, an attacker can use the W&B Python SDK or REST API to:

1. 1

   Enumerate accessible projects and runs

   Use wandb.Api() to list all projects, runs, and their metadata. This reveals the organization's complete experiment history.

   Enumerating W&B projects with a compromised API keypythonShow code

   import wandb
    
   # Authenticate with the compromised key
   api = wandb.Api(api_key="compromised_key_here")
    
   # List all accessible projects
   for project in api.projects():
       print(f"Project: {project.name}")
       for run in api.runs(f"{project.entity}/{project.name}"):
           print(f"  Run: {run.name} | State: {run.state}")
           print(f"  Config: {dict(run.config)}")
           print(f"  Summary: {dict(run.summary)}")

2. 2

   Extract artifacts and model checkpoints

   Download all artifacts including model weights, datasets, and configuration files stored in W&B Artifacts.

3. 3

   Harvest credentials from run configs

   Search across all runs for configuration keys that look like credentials: paths containing "key", "secret", "token", "password", or "credential".

4. 4

   Modify artifacts for poisoning

   If the key has write access, upload modified model checkpoints or datasets as new artifact versions. Downstream pipelines that pull "latest" will consume the poisoned artifacts.

Experiment Data Leakage

Public Projects

W&B allows projects to be set to "public" visibility, making all runs, configs, and artifacts accessible to anyone. Organizations sometimes set projects to public for collaboration without realizing the security implications.

What leaks from public projects:

• Complete hyperparameter configurations for every run
• Training loss curves and evaluation metrics
• Model architecture details encoded in config
• Dataset paths revealing internal infrastructure
• Artifact files including model checkpoints

Report Sharing

W&B Reports can be shared via URL. Reports may embed sensitive data including:

• Interactive plots of training metrics
• Code snippets from logged source
• Artifact references that may be downloadable
• Run tables with full configuration details

Even "view-only" report links can leak significant information because the underlying run data is accessible through the report's data bindings.

Sweep Configurations

Sweeps are particularly revealing because they expose the complete hyperparameter search space. A sweep configuration shows not just what values were tried, but the ranges the team considers reasonable -- information that dramatically accelerates competitive replication.

Team Boundary Violations

Multi-Team Organizations

W&B organizations can contain multiple teams. The security boundary between teams depends on configuration, and the defaults are often more permissive than expected.

Common boundary violations:

• Team members can see other teams' project names even without access to run data
• Organization admins have implicit access to all teams' data
• Service accounts created for CI/CD may have cross-team access
• Artifact references can cross team boundaries when runs reference artifacts from other teams

Entity Confusion

W&B uses "entities" (usernames or team names) in API paths: wandb.init(entity="team-name", project="project-name"). If a training script uses a hardcoded entity and the corresponding API key has access to multiple entities, runs may be logged to unintended projects. An attacker who controls a similarly named entity could intercept experiment data.

Artifact Poisoning

W&B Artifacts provide versioned, lineage-tracked storage for datasets, models, and other files. The artifact system's trust model creates opportunities for poisoning attacks.

Version Manipulation

Artifacts use aliases like "latest", "best", and "production" to reference specific versions. An attacker with write access can:

1. Upload a new version of a model artifact with a backdoor
2. Move the "latest" or "production" alias to point to the poisoned version
3. Downstream pipelines that reference artifact:latest will pull the poisoned version
4. The original artifact versions remain intact, making the attack reversible and deniable

Lineage Exploitation

W&B tracks artifact lineage -- which runs produced and consumed which artifacts. An attacker can create a run that claims to be a legitimate training job, produces a poisoned artifact, and links it to the genuine training lineage. The poisoned artifact appears in the lineage graph as a legitimate output.

Cross-Project Artifact References

Artifacts can be referenced across projects within the same entity. A compromised project can upload artifacts that are consumed by pipelines in other projects, enabling lateral movement through the artifact dependency graph.

import wandb
 
api = wandb.Api()
 
# Get the production model artifact
artifact = api.artifact("team/project/model:production")
print(f"Current production version: {artifact.version}")
 
# Create a poisoned version
run = wandb.init(project="project", entity="team")
poisoned_artifact = wandb.Artifact("model", type="model")
poisoned_artifact.add_file("poisoned_model.pt")
run.log_artifact(poisoned_artifact, aliases=["production", "latest"])
run.finish()
# The "production" alias now points to the poisoned version

Self-Hosted W&B Security

Organizations running self-hosted W&B (W&B Server) face additional attack surfaces beyond the managed cloud offering.

Infrastructure Concerns

Authentication Bypass

Self-hosted W&B instances sometimes use permissive authentication configurations:

• Local accounts with default or weak passwords
• SAML/OIDC misconfigurations allowing unauthorized access
• API endpoints that do not enforce authentication for certain operations
• Admin console accessible without additional authentication

Detection and Monitoring

Indicators of Compromise

Logging and Alerting

W&B provides audit logs in enterprise tiers. Key events to monitor:

• API key creation and usage
• Artifact version creation and alias changes
• Project visibility changes (private to public)
• Team membership modifications
• Bulk data export operations

References

• W&B Security Documentation -- Official security guidance
• W&B Server Deployment -- Self-hosted deployment documentation
• W&B Audit Logs -- Enterprise audit logging