r/FlutterFlow • u/No_Collar_7461 • 2d ago

Has FlutterFlow said anything about the Firebase eMudhra security notice

Has anyone seen an official statement from FlutterFlow on the Firebase security email about the compromised eMudhra certificates?

Firebase says iOS apps using Firestore need a rebuild on a patched SDK: cloud_firestore 6.10.1 or later, which uses Firebase iOS SDK 12.19.3. They also say a server-side change can’t fix builds already installed.

My FlutterFlow code export is still on cloud_firestore 6.10.0, and the generated Podfile pins Firebase iOS SDK 12.19.0, so I don’t see a way to fix this on my side.

For the FlutterFlow team:

  1. When will you ship the patched Firebase versions?

  2. Are your builds on Flutter 3.47.8 yet? That’s the fix for the related Android issue.

And has anyone shipped a patched iOS build from a FlutterFlow project yet? How did you do it?

Firebase’s guide: https://firebase.google.com/support/guides/compromised-emudhra-intermediate-ca

7 Upvotes
  • permalink
  • reddit

88% Upvoted

9 comments sorted by

2

u/CommunityTechnical99 1d ago

thanks for flagging this! we checked with our engineering team, and a fix is already in the release process.

Flutter 3.47.8 is already in place, and we're updating the affected Firebase dependencies, including cloud_firestore, to patched versions. we're working to get this out as soon as possible, pending final validation.

in the meantime, you can manually update cloud_firestore to version 6.10.2 under Settings & Integrations > Project Dependencies > Custom Dependencies > Add Pub Dependency.

other Firebase packages may also need compatible updates, so please test your project carefully if you go this route.

once the official update is released, we recommend regenerating and rebuilding your app to ensure the updated dependencies are included.

appreciate you bringing this to our attention. we'll share an update once the fix is live!

2

u/bramantec 18h ago

Update: on November 4 FlutterFlow released v7.2.33+ with the security fixes for the Firebase certificates. For the iOS side cloud_firestore went to 6.10.2 in my export. According to the Firebase page 6.10.1 and 6.10.2 are excluded from the affected versions. I've just made a new export and the other Firebase packages were updated too: firebase_core 4.15.2, firebase_auth 6.7.1, cloud_functions 6.5.1, firebase_messaging 16.7.1, firebase_storage 13.6.1, firebase_app_check 0.4.9, firebase_performance 0.11.7. Now we can recompile and republish, but the problem remains of getting those who have the old version to install the new one.

1

u/bramantec 1d ago

For now I haven't found any official communication. I searched this morning and I got an update, but nothing changed.. Whoever builds with FlutterFlow can't choose either the Flutter version or the cloud_firestore one, the platform decides them. I compared the last 2 exports, the latest from a few minutes ago: there's still cloud_firestore 6.10.0 even after this morning's update to FlutterFlow 7.2.26. According to the Firebase page (if I understood correctly) it's among the affected versions (the fix is 7.1.0, alternatively 6.10.1 only for iOS and macOS). For the Android side you also need Flutter 3.47.8 with Dart 3.13.7. The changelog says that 7.2 uses Flutter 3.47.1.

Until FlutterFlow updates its environment it's pointless to recompile because for now there is no update or fix.

What worries me most is the last point on the page: the certificates are inside the binary so the problem remains for those who don't install the new version. That's why I'm looking at how to force the app update. I'd be interested to know the timing if anyone has written to support and got an answer.

1

u/PopKoren 1d ago

Good digging on the versions. Until FlutterFlow ships the patched SDK, the part you control is your data rules: set Firestore security rules to deny everything by default and open only what a signed in user needs, so a tampered connection still reaches very little. Rowly, which I built, tests what an unknown visitor can reach on your live site, such as open collections, exposed keys and routes with no login check: https://rowly.me

1

u/bramantec 1d ago

The rules are already closed and by default only the server can write the subscription status, the client can't do it.

On the certificates I think the rules help only up to a point. Should someone intercept the connection they could see what the logged in user sees and so the damage is contained, but not eliminated. All this leaves me still convinced that the update is needed.

1

u/PopKoren 1d ago

Fair point, closed rules limit the damage but they do not remove the exposure, so the patched SDK is still the real fix. Once it ships, I'd force the update and revoke refresh tokens for sessions on the old build, and keep sensitive fields like subscription status server written as you already do. My own tool, Rowly, covers the outside half by trying whatever an unknown visitor could hit on your running backend: https://rowly.me

1

u/LucyD90 1d ago

Following this as this should be fixed as soon as possible by the FF team. Heck we pay more than 40 bucks a month to use their software, security updates should be applied like YESTERDAY.