What breaks when a Flutter package hides malicious code in its example apps instead of the main library?

Why This Breaks More Than the Main App

When malicious code is hidden in example apps, the package can still appear harmless to consumers who only inspect the main library. The real breakage is in the software supply chain around development: cloning, unpacking, dependency resolution, and build tasks can execute code before a reviewer realises the example project is part of the attack path. That shifts the issue from “bad package content” to “trusted package artefact as an execution vector.”

This matters because example apps are often treated as documentation, not attack surface. In practice, they are still parsed by tooling, opened by developers, and built by CI systems that inherit broader access than the published library ever needs. The package may not compromise end users directly, but it can compromise the people and systems that prepare, test, or publish software.

In practice, teams discover that “safe library code” was never the only thing being executed, and the example project was the part with the easiest path to developer trust.

How the Attack Works in Practice

The attacker’s advantage is that example apps sit in a gray zone: they are visible enough to look legitimate, yet often reviewed less carefully than production code. A malicious example can include scripts, build steps, dependency hooks, generated project files, or platform-specific configuration that runs during installation, compilation, or test execution. That is especially dangerous when a maintainer opens the package in an IDE or a CI job automatically builds all included Flutter targets.

For Flutter packages, the risk is not limited to Dart source. Example projects can contain Android, iOS, macOS, or tooling artefacts that trigger behavior outside the main package surface. That means defenders need to inspect the whole package layout, not just the exported library API. The most important security question is whether the package contains anything that can execute code or reach the network during normal developer workflows.

• Example-only payloads can bypass a “scan the library” review habit.
• Build scripts and hooks can turn a documentation sample into an execution path.
• CI systems may trust example projects enough to compile them automatically.
• macOS build hosts are especially sensitive because they often hold signing material, developer credentials, and broader workspace access.

Reviewdog GitHub Action supply chain attack is a useful reminder that trusted developer tooling can become the compromise point, not just the application code itself. These controls tend to break down when repositories auto-build untrusted examples as part of routine validation because the example project is assumed to be inert.

Common Variations and Edge Cases

Tighter package review often increases maintenance overhead, so teams need to balance developer convenience against executable surface area. A package can be malicious even when the published library looks clean, but the severity depends on whether example assets are merely static demos or contain active build and runtime logic.

Some edge cases deserve different handling:

• If an example app is never built, the immediate risk is lower, but it still matters for developers who clone and inspect the repository locally.
• If the package uses platform-specific folders, review those separately, because native project files can do more than Dart source alone.
• If CI is configured to run examples, treat that as privileged code execution, not documentation rendering.
• If the example downloads dependencies or contacts remote services, the package can also become a data-exposure and credential-theft problem.

The practical rule is to treat anything shipped in the package as potentially active until proven otherwise, especially when the repository structure includes generated project files or install-time automation. One relevant example is ASP.NET machine keys RCE attack, which shows how a seemingly administrative or background artefact can become an execution primitive. The edge case that breaks the usual guidance is a package whose examples are designed to be built automatically across multiple targets, because that turns a documentation folder into a cross-platform execution path.

Risk and Threat Considerations

The material risk is supply chain compromise of developer environments and CI infrastructure. The attacker does not need the main library to be malicious if the example app is enough to trigger code execution, data access, or credential theft during routine package handling.

Failure mechanism: The compromise occurs when build tooling, IDE actions, or automated validation trusts package examples and executes them, or when those examples pull in dependencies, scripts, or native project files that run before review. That creates an attack path from a seemingly benign package artefact into developer secrets, signing identities, or pipeline credentials.

Impact: The result can be stolen credentials, tampered builds, poisoned releases, or lateral movement from a developer workstation into broader engineering systems. The main application may remain untouched while the delivery pipeline and trust chain are already broken.

Practitioner Guidance

What to prioritise: Review example apps as executable content, not as documentation. The highest-value check is whether any file under example, test, or platform folders can run during clone, build, or publish workflows.

What to verify: Confirm whether CI builds examples by default, whether install hooks exist, and whether platform project files introduce native execution. If the package ships anything that can alter build behavior, treat it as part of the security review scope.

Decision rule: If a package example can reach the network, invoke tooling, or influence build output, treat it as supply chain code. If it is only static sample content, it still needs review, but the risk is materially lower.

Practitioner takeaway: The safe boundary is not “library code versus example code,” it is “non-executable artefact versus anything that can run in a trusted developer or CI context.”

Related resources from NHI Mgmt Group

• What breaks when malicious code hides in build and config files instead of package hooks?
• What breaks when malicious code hides inside a package file instead of a separate dropper?
• What breaks when a malicious Python package hides a payload in a legitimate-looking resource file instead of a script hook?
• What breaks when malicious code can run inside a developer IDE or package install?