CVE-2026-47682 is an arbitrary file write vulnerability in CVAT's cloud storage integration — specifically, the mechanism that synchronizes datasets from S3, Google Cloud Storage, or Azure Blob into the annotation server's filesystem. The bug is a classic path traversal flaw: when CVAT writes files retrieved from configured cloud storage, it fails to validate that the destination path stays within intended boundaries, allowing an attacker who can control or influence cloud storage contents to write files to arbitrary locations on the CVAT host.
The CVSS 7.1 rating is technically accurate but scope-blind. The EPSS of 0.003 reflects current exploitability given the prerequisite — but that prerequisite deserves scrutiny. The vulnerability requires "authenticated access to cloud storage configuration," which sounds restrictive until you recognise what CVAT actually does: its entire purpose is ingesting external datasets and making them pipeline-ready. An attacker uploading a malicious dataset through CVAT's normal workflow IS the authenticated actor. The prerequisite isn't a meaningful gate — it's the intended usage pattern.
The more important question is where arbitrary file write detonates. CVAT occupies a chokepoint in ML infrastructure — it sits adjacent to training data, model artifacts, and dataset management. Successful exploitation doesn't just land arbitrary files; it lands them in a system that downstream pipelines trust. Training data poisoning becomes viable, model corruption becomes viable, and the arbitrary file write translates directly into supply chain risk.
This vulnerability existed undetected from roughly version 1.6.0 through 2.64.0 — years of exposure in production ML annotation pipelines. The persistence isn't accidental; it's structural. Cloud storage connectors are "utility code" — they're added, they work functionally, and they never get retroactively classified as security-critical until someone demonstrates arbitrary file write. The S3 connector wasn't in CVAT's threat model because nobody puts "trusted cloud backend writes arbitrary files" in the blast cone. It's utility code. It's the forgotten layer.
For defenders: prioritize patching to 2.65.0 immediately if you're on any recent version. Beyond the immediate fix, audit all cloud storage integrations in your ML pipeline tools — annotation platforms, experiment trackers, data processing frameworks. The pattern "trusted storage backend becomes filesystem proxy" has reproduced across annotation tools, JupyterHub deployments, MLflow, and other computer vision pipelines. The fix in 2.65.0 will tell you whether this is a surgical path validation (input sanitization at one choke point) or a broader architectural change treating external storage as fundamentally untrusted. If it's surgical, expect follow-on CVEs — traversal variants get rediscovered, dotdot sequences get re-encoded, and the mutation expresses again within 18-24 months.
The deployment scenarios that should trigger immediate urgency: shared research environments where multiple users upload datasets, multi-tenant annotation platforms, and self-hosted instances with any untrusted user population. Even single-organisation deployments aren't immune if an attacker can compromise a legitimate user's cloud storage credentials or intercept dataset uploads. The EPSS may be low today, but it measures aggregate threat actor behaviour — a bug bounty researcher with cloud storage access faces entirely different exploitation costs than the population-level statistics suggest.