How to Check a Flutter TLS Security Update Before You Ship
Use the advisory, target platform and rebuilt artifact to verify that a Flutter TLS security update actually reached your app.
Published / Methodology
Start with the advisory, not the release headline
A release headline can tell you that an update is urgent, but it does not tell you which binaries are exposed. Start with the Dart SDK security advisory and record the advisory ID, affected SDK ranges, fixed versions, affected platforms and the remediation action. The October 23, 2026 advisory identifies GHSA-frr6-h895-5pxp, marks Dart versions before 3.13.7 and Flutter versions before 3.47.8 as affected, and asks maintainers to upgrade, rebuild and redeploy.
Keep three statements separate: the advisory describes the vulnerability and fix; a developer article may explain the issue for its audience; your build logs show which SDK produced your artifact. A Chinese developer post on Juejin, published October 26, summarizes the same emergency Flutter 3.47.8 release. It is useful context, while the GitHub advisory is the source for the version and platform scope.
| Question | Evidence to save | Why it matters |
|---|---|---|
| What is affected? | Advisory ID, vulnerable ranges and platform list | A version number alone does not define exposure |
| What is fixed? | Patched Flutter and Dart versions plus the documented change | The app must be rebuilt with the patched SDK |
| What did we ship? | SDK version, lockfile and artifact digest from CI | A local SDK upgrade does not change an existing binary |
Map the advisory to the app platforms
The advisory covers Dart applications making outbound TLS or HTTPS connections through dart:io on Android, Windows and Linux. Android and Windows use the compiled-in BoringSSL path described by the advisory. Linux exposure depends on the system ca-certificates bundle; static containers and hosts that have not received the relevant trust-store update need particular attention.
The same advisory says Web, iOS and macOS use browser or Apple Security.framework certificate verification and are not affected by this specific issue. Do not turn that statement into a general claim that every transport bug is platform-specific. Map the finding to the code path your release actually uses, including plugins that open sockets outside your obvious API calls.
Upgrade the SDK and prove the binary changed
Upgrade to the fixed stable Flutter SDK, or to a fixed beta only when your release policy permits it. Record the output of flutter --version and dart --version in the build log. Re-run dependency resolution and the platform build; do not assume that changing a version manager pointer updates an already exported APK, Windows executable or Linux bundle.
For each artifact, save a digest and the build metadata that ties it to the fixed SDK. A useful release record includes the Flutter channel and revision, Dart version, target platform, commit, dependency lockfile digest, artifact digest and build time. If your CI cache can reuse engine or intermediate files, make the cache key include the SDK revision and invalidate it deliberately for this release.
| Target | Build check | Release check |
|---|---|---|
| Android | Fixed Flutter/Dart version and a rebuilt APK or AAB | Install the new artifact and record its digest |
| Windows | Fixed SDK in the Windows build job | Replace the distributed executable, not only the source checkout |
| Linux | Fixed SDK plus current system certificate bundle | Rebuild static/container images and inspect the base image update |
| Web, iOS or macOS | Confirm the advisory scope and your actual transport path | Keep the scope note with the release record |
Check certificate validation assumptions
The fixed SDK updates BoringSSL to distrust the compromised eMudhra intermediate certificates during TLS chain verification. On Android 14 and later, the advisory also describes loading system root certificates from the updatable Conscrypt APEX module. Those changes improve the default path; they do not repair an application that disables certificate verification or pins an obsolete certificate incorrectly.
Search the app and its dependencies for custom HttpClient badCertificateCallback handlers, permissive certificate callbacks, test-only trust managers or native networking code. Exercise a normal HTTPS request in a staging environment and confirm that certificate errors are surfaced rather than silently accepted. This is a behavior check, not a claim that a staging test reproduces the compromised chain.
Publish a bounded remediation note
Tell users which app versions contain the rebuilt artifact, which platforms were in scope and whether an older binary remains exposed. Include the advisory link and the release date. Avoid saying that every Flutter app is compromised, that the update proves a successful attack, or that a hot-list ranking measures adoption.
Keep the original publication date and the ThreadEast observation date separate. ThreadEast first observed the Juejin listing on October 26 and captured the selected observation at 01:35 China Standard Time on October 28; those are collection timestamps. The official GitHub advisory was published October 23. This guide was checked on October 28, 2026 and does not reproduce the exploit, audit network traffic or certify a particular app release.
Scope and further reading
This workflow is for checking a documented Flutter/Dart TLS remediation before shipping. It does not replace a code review, dependency audit, penetration test or platform security response. Use the official advisory for the current affected ranges and update this record if the advisory changes.
Sources & further reading
- Dart SDK security advisory GHSA-frr6-h895-5pxp
- Flutter release notes
- Flutter 3.47.8 source report on Juejin
- Google: compromised eMudhra intermediate CA certificates
- Dart BoringSSL trust change
- Dart Conscrypt APEX trust-store change
- October 28 source-reviewed Flutter briefing
Found an error? Request a correction.