A Flutter app can look native, ship fast, and still carry vulnerable packages inside pubspec.lock. The risk is not only your Dart code. It is every package pulled from pub.dev, every transitive dependency, and every native Android or iOS wrapper running under the surface.

Flutter dependency security means knowing what your app actually runs, checking those exact versions for known CVEs, and monitoring future disclosures after release. A clean build today does not guarantee a safe dependency tree next month. Mobile apps stay installed for months, so dependency risk can remain active long after deployment.

The Flutter Security Landscape

Flutter has become a popular choice for mobile teams because one codebase can target Android, iOS, web, desktop, and embedded use cases. That productivity also changes the security model. A Flutter app is not only Dart widgets and business logic. It often includes authentication packages, HTTP clients, local storage libraries, camera access, file pickers, Firebase plugins, analytics SDKs, and platform-specific native code.

Pub is the package manager for Dart, and pub.dev is the official repository for Dart and Flutter packages. Teams add packages to pubspec.yaml, then Dart resolves exact versions into pubspec.lock. That lockfile becomes the best source of truth for security scanning because it shows the versions your app actually installs.

The Flutter ecosystem is smaller than npm or PyPI, but smaller does not mean risk-free. Some security issues appear directly in Pub packages. Others appear in native Android/iOS code wrapped by Flutter plugins. A package such as image_picker, file_picker, firebase_auth, flutter_secure_storage, dio, or http may introduce security-sensitive behavior even when it does not have a public CVE at the time you install it.

Your Flutter dependency tree is part of your mobile attack surface, especially when packages handle authentication, files, network traffic, tokens, or local storage.

pubspec.yaml vs pubspec.lock — Which to Scan and Why

pubspec.yaml describes what your project requests. It usually contains version constraints such as ^1.2.0, which means Dart can resolve a compatible version within a range. That file is useful for understanding intent, but it does not always show the exact version installed in production.

pubspec.lock records the resolved dependency graph. It includes direct and transitive packages, exact versions, package sources, and content hashes. For applications, this file should be treated as a production security artifact because it answers the most important question: “Which package versions are we really running?”

For pubspec.lock security, scan the lockfile first. If pubspec.yaml says your app accepts dio: ^4.0.0, the lockfile tells you whether your app resolved dio 4.0.0, 4.0.6, 5.0.0, or a newer version. That difference matters because a vulnerability may affect one range but not another.

• Direct dependency: A package you explicitly list in pubspec.yaml, such as dio or firebase_auth.
• Transitive dependency: A package pulled in by another package, even if you never added it manually.
• Lockfile: A file that records exact package versions and helps reproduce the same dependency set across developers and CI/CD.

Tip: For Flutter apps, commit pubspec.lock and scan it in CI/CD so production builds use known, reviewed dependency versions.

How to Scan Your Flutter Dependencies

The first step in Flutter dependency security is visibility. Before you can fix vulnerable packages, you need to know every package in the resolved dependency tree. Dart gives you built-in commands for dependency inspection, and external scanners can check those packages against vulnerability databases.

Start with the dependency tree. This helps you see which packages are direct dependencies and which packages are pulled in indirectly. Then check outdated packages. Outdated does not always mean vulnerable, but old packages are more likely to miss security fixes, compatibility updates, and safe defaults.

dart pub deps
dart pub outdated
flutter pub deps
flutter pub outdated

The output from these commands helps you identify risky areas before you run a vulnerability scanner. For example, an app that uses old versions of HTTP clients, storage plugins, or file-handling plugins deserves deeper review because those packages touch sensitive data and platform APIs.

Using OSV-Scanner for Dart/Flutter

OSV-Scanner is a free vulnerability scanner maintained by Google. It uses the OSV database and supports the Pub ecosystem, including pubspec.lock. This makes it a practical starting point for Dart Pub security checks in local development or CI/CD.

osv-scanner --lockfile=pubspec.lock

You can also scan a full project directory. This is useful when you want OSV-Scanner to find supported lockfiles automatically.

osv-scanner -r .

If OSV-Scanner finds a vulnerable package, check the affected version range, fixed version, severity, and references. Then update the package and rerun your tests. Do not blindly upgrade every dependency at once in a production mobile app. Upgrade the vulnerable package first, test authentication, storage, permissions, and platform-specific flows, then release safely.

Uploading pubspec.lock to Vulert

Vulert supports pubspec.lock scanning for Dart and Flutter projects. You can upload the lockfile to Vulert’s free ABOM scanner and get an instant vulnerability report in about 60 seconds. This is useful when you want a simple web-based scan without connecting your repository or installing anything locally.

1. Find the lockfile: Open your Flutter project root and locate pubspec.lock.
2. Upload it: Go to vulert.com/abom and upload the file.
3. Review vulnerable packages: Check CVE details, affected versions, CVSS score, fix guidance, and recommended upgrade commands.
4. Monitor continuously: Use Vulert to receive alerts when new CVEs are disclosed for packages already used in your app.

Vulert analyzes manifest files and SBOMs against 458,000+ known CVEs. It supports Dart along with PHP, JavaScript, Java, Python, Go, Ruby, Rust, Elixir, Erlang, C++, and C#/.NET. For Flutter teams, the main workflow is simple: upload pubspec.lock, review the dependency risk, fix vulnerable packages, and keep monitoring after release.

Flutter-Specific Security Considerations

Flutter packages can do more than add Dart code. Many plugins act as bridges to Android and iOS APIs. That creates a security model where a package may include Dart code, Kotlin, Java, Swift, Objective-C, Gradle configuration, CocoaPods dependencies, or native SDK behavior. A vulnerability may exist in the native layer even when the Dart package itself has no Pub advisory.

Platform Plugin Vulnerabilities

Platform plugins connect Flutter to native capabilities such as camera access, file selection, secure storage, notifications, biometrics, location, and in-app purchases. Packages like image_picker, file_picker, shared_preferences_android, and Firebase plugins deserve extra attention because they interact with platform permissions and user data.

A real example is shared_preferences_android, which had advisory GHSA-3hpf-ff72-j67p related to unsafe deserialization behavior and was patched in version 2.3.4. Even though this was not a typical remote web vulnerability, it shows why Flutter teams should not ignore platform-specific package advisories.

Warning: A Flutter plugin can be “safe” at the Dart API level but still expose risk through Android, iOS, or bundled native SDK behavior.

Sensitive Data Handling Packages

Sensitive data handling needs special care in Flutter apps. Packages such as flutter_secure_storage, firebase_auth, and local database libraries often handle tokens, session data, refresh credentials, user identifiers, or cached profile information. A vulnerability scanner can tell you whether a package version has a known CVE, but it cannot prove that your implementation is safe.

For example, using secure storage incorrectly can still expose data through logs, backups, screenshots, debug builds, or weak server-side session controls. Treat package scanning as one layer. Also review how you store tokens, how long sessions last, how refresh tokens rotate, and whether debug logs ever include credentials.

Notable Flutter Package Vulnerabilities to Know About

Real vulnerabilities in the Dart and Flutter ecosystem show why scanning matters. CVE-2026-27704 affected Dart SDK versions before 3.11.0 and Flutter SDK versions before 3.41.0. The issue involved Zip Slip behavior during Pub package extraction, where a malicious package archive could write files outside the intended destination in the Pub cache. The fix landed in Dart 3.11.0 and Flutter 3.41.0.

Another example is CVE-2021-31402 in the dio package. The advisory describes CRLF injection in dio 4.0.0 when an attacker controls the HTTP method string. The issue was fixed in dio 5.0.0. This matters because dio is a common HTTP client in Flutter apps, and HTTP clients sit directly on the boundary between mobile apps and backend APIs.

For Flutter vulnerability scanning, do not wait until a package becomes famous for a CVE. Scan the lockfile regularly, review advisories for packages that touch sensitive capabilities, and update the Flutter SDK itself when security fixes land.

Adding Security Scanning to Flutter CI/CD

The best Flutter dependency security workflow runs automatically. Manual scans are useful before releases, but CI/CD scanning catches risky dependency changes earlier. A GitHub Actions workflow can install Flutter, install OSV-Scanner, fetch dependencies, scan pubspec.lock, and fail the build when known vulnerabilities appear.

name: Flutter Dependency Security

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  dependency-scan:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Flutter
        uses: subosito/flutter-action@v2
        with:
          flutter-version: '3.41.0'

      - name: Install dependencies
        run: flutter pub get

      - name: Install OSV-Scanner
        run: |
          curl -sSfL https://raw.githubusercontent.com/google/osv-scanner/main/install.sh | sh -s -- -b /usr/local/bin

      - name: Scan pubspec.lock
        run: osv-scanner --lockfile=pubspec.lock

For stricter production builds, add lockfile enforcement so CI fails when dependencies cannot be resolved from the exact locked versions and hashes.

dart pub get --enforce-lockfile

You can combine this with Vulert for ongoing monitoring after release. CI catches known issues during development. Vulert helps alert you later when a new CVE affects a package version already used by your mobile app.

Key Takeaways

• Scan pubspec.lock, not only pubspec.yaml, because the lockfile shows the exact package versions your Flutter app runs.
• Use dart pub deps and dart pub outdated to understand your dependency tree before making upgrades.
• OSV-Scanner supports the Pub ecosystem and can scan pubspec.lock locally or in CI/CD.
• Flutter plugins may include native Android or iOS code, so check both Dart advisories and native SDK risks.
• Real issues such as CVE-2026-27704 and CVE-2021-31402 show that Dart and Flutter dependency risk is not theoretical.
• Vulert supports pubspec.lock scanning and continuous alerts for Flutter dependency security.

Frequently Asked Questions

1. Are Flutter apps more vulnerable than native apps?

No, Flutter apps are not automatically more vulnerable than native apps. The risk depends on package choices, native plugins, authentication design, storage decisions, API security, and update discipline. Flutter apps can be secure when teams scan dependencies and review sensitive platform integrations.

2. How do I check my Flutter dependencies for CVEs?

Run dart pub deps or flutter pub deps to inspect the dependency tree, then scan pubspec.lock with OSV-Scanner or Vulert. The lockfile is the best scan target because it records exact versions. You should also run scans in CI/CD before release.

3. Does Vulert support Flutter and Dart?

Yes. Vulert supports Dart and Flutter dependency scanning through pubspec.lock. You can upload the file to vulert.com/abom and get a vulnerability report with fix guidance in about 60 seconds.