Key details

  1. Aikido disclosed the `universal_file_viewer` compromise on September 8, 2026.
  2. The affected package is a legitimate Dart/Flutter package hosted on pub.dev.
  3. Aikido identifies XCSSET, a macOS worm, as the contaminating malware.
  4. The reported infection path begins on the maintainer's development machine rather than with a deliberately malicious package author.
  5. Pub.dev currently marks `universal_file_viewer` versions 0.1.5 and 0.1.6 as retracted.
  6. Version 0.1.7 is currently listed as the latest stable release.
  7. Ossprey reports a second affected Flutter package, `surveyjs_flutter`.
  8. The malicious content can propagate through Android Gradle, Xcode and Git project files.

What builders should take away

  1. Check Dart/Flutter lockfiles and build caches for retracted affected versions; registry retraction does not retroactively erase local artifacts.
  2. If a developer Mac is suspected of XCSSET infection, treat Git repositories and packages published from that machine as potentially contaminated until reviewed.
  3. Review changes to Gradle, Xcode project and repository hooks with the same suspicion as application source changes, especially when generated or rarely inspected.
  4. Use clean, reproducible publishing environments where practical so release artifacts are not built directly from a general-purpose developer workstation.
  5. Treat valid publisher identity as one trust signal, not proof that the package contents reflect the maintainer's intent.

What changed

Aikido Security reported on September 8 that version 0.1.5 of the legitimate Flutter package `universal_file_viewer` contained a variant of XCSSET, a macOS worm. Aikido says the maintainer's machine had been infected and malicious project/build files were then included when the package was published to pub.dev; it traced the package back to a compromised GitHub repository. Pub.dev now shows versions 0.1.5 and 0.1.6 as retracted, with 0.1.7 available as the current version. Follow-up research from Ossprey reported another legitimate Flutter package, `surveyjs_flutter`, affected through similar XCSSET contamination, broadening the event beyond one accidental package release.

Why it matters

Many software-supply-chain defenses focus on stolen publisher tokens or malicious maintainers. This incident demonstrates a different route: compromise the trusted developer's workstation, let malware modify repository/build files, and wait for the maintainer to publish normally. Registry authentication can be perfectly valid while the artifact is still malicious. For Flutter teams—especially developers building on macOS—the response therefore includes workstation and repository integrity, not only dependency pinning and publisher-account security.

The publisher appears to have been an unwitting carrier

Aikido says `universal_file_viewer` was not intentionally weaponized by its maintainer. XCSSET on the developer machine injected malicious build/project content, which then traveled into the GitHub repository and the pub.dev package when a new version was published.

XCSSET spreads through development projects

The malware targets developer environments and can insert malicious hooks into Android Gradle projects, Xcode projects and Git repositories. That makes a compromised developer machine unusually dangerous because each normal commit or package release can become another distribution path.

The malicious package versions are now retracted

Pub.dev's current version history marks `universal_file_viewer` 0.1.5 and 0.1.6 as retracted and lists a newer 0.1.7 release. Consumers should still inspect lockfiles and caches rather than assuming retraction automatically removes already downloaded artifacts.

Follow-up research suggests the pattern was not unique to one package

Ossprey says it identified `surveyjs_flutter` as another legitimate package affected by XCSSET contamination. That makes the event more instructive than a single low-download package and suggests teams should search projects and registries for the infection pattern rather than only one package name.

What to watch next

  • Whether pub.dev or the Dart/Flutter teams publish a formal incident report or new registry controls.
  • Additional packages traced to infected maintainer machines.
  • Indicators and remediation guidance from XCSSET researchers and endpoint-security vendors.
  • Whether package publishers adopt more isolated or reproducible release workflows after the incident.

Still unclear

  • Aikido and Ossprey provide the technical attribution; pub.dev's public version page confirms retraction but does not by itself explain why those versions were retracted.
  • The number of downstream installations and successfully infected developer machines is not established by package download counts.
  • The current evidence does not show a broad compromise of pub.dev itself; the reported path is compromised publisher environments.

Sources

Direct reading behind this dossier.

3 sources

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment