Mobile Banking Security Weekly #4

Android December 2025 Security Bulletin · CRITICAL Actively exploited vulnerabilities patched (critical remote DoS in Framework) – update devices to 2025-12-05 or later Released: Dec 4, 2025

iOS 26.2 Security Update · CRITICAL Apple patches 20+ vulnerabilities (2 WebKit zero-days under active exploit) – update iPhones/iPads Released: Dec 12, 2025

Google Play US Policy Changes · HIGH Alternative billing and external links now allowed for U.S. users (Epic injunction) – compliance deadline Jan 28, 2026

CRITICAL Released: December 4, 2025

Monthly patch fixes a critical Framework flaw (remote denial-of-service) and dozens of high-severity vulnerabilities across System, Kernel, and vendor components. Google notes two of the patched bugs are under limited targeted exploitation, underscoring the need for immediate updates.

Why Critical:

• Active exploits: Vulnerabilities (CVE-2025-48633, CVE-2025-48572) are known to be exploited in the wild, potentially enabling privilege escalation or device instability
• Banking risk: Unpatched devices could be susceptible to remote app crashes or compromise, affecting transaction and OTP flows
• Fragmentation: Users on older Android versions might not receive timely OEM patches, increasing fraud risk

Impact Surfaces: Login sessions (potential DoS mid-transaction), WebView content rendering (malicious web content could crash app), biometric authenticator stability

Actions:

• Update all test devices to December 2025 SPL (security patch level) and require customers to update
• Re-run critical user flows (login, OTP, payments) on patched vs. unpatched devices to observe any difference or crashes
• Monitor crash logs and security alerts on devices pre-2025-12-05 patch for signs of the exploited CVEs
• If any in-house device management: enforce minimum patch level checks during app startup to warn users on older patches

Test Matrix:

• OS: Android 10, 12, 14, 15 (to cover devices that may or may not get patches)
• Patch Levels: 2025-11-05 vs 2025-12-05 on identical devices
• WebView: Test with WebView 143 (latest)
• Flows: Login, Balance check, Funds transfer (ensure no unexpected crashes)
• Locales: vi-VN primary (verify error messaging)

HIGH Updated: December 9, 2025 · Compliance Deadline: January 28, 2026

Google Play is implementing U.S.-only policy changes per a court injunction. Apps may now link to external app downloads and offer payment methods besides Google Play Billing for U.S. users. Google launched an External Content Links program and expanded Alternative Billing programs for U.S. developers.

Why it matters:

• Payment flexibility: Banks or fintech apps distributing in the U.S. can now direct users to web sign-up or external payment systems without fear of Play Store removal
• Compliance overhead: To use these freedoms, apps must follow new program requirements (disclosure dialogs, user protections). Non-compliance by Jan 28 will force removal of such links
• Competitive dynamics: Rival apps might offer fee-saving payment methods in the U.S., impacting user expectations

Impact Surfaces: In-app upgrade flows, subscription purchase screens, any “Add money” or “Premium account” feature for U.S. region users

Actions:

• Evaluate if our app would benefit from external link or alternative billing in the U.S. (most banking apps have no IAPs, so likely not applicable)
• If applicable, enroll in Google’s external links or alt billing program ASAP and implement required user prompts
• Update App Store listing and in-app wording for U.S. region to clarify any external purchase flows
• Ensure compliance by Jan 28, 2026 if participating

Test Matrix:

• Device/Region: U.S. Play Store account vs non-U.S. (feature flag differences)
• Flows: (If using alt billing) attempt a purchase in-app – verify proper warning dialog and smooth handoff
• Compliance: Check that the latest app bundle targets the correct Play policy version

MEDIUM Enforcement Begins: March 1, 2026

Google is raising the bar on battery performance. A new core vitals metric tracks apps holding partial wake locks >2 hours in 24h. Starting March 1, 2026, any app exceeding the bad threshold (5% of user sessions) will face Play Store penalties: reduced visibility and a warning label about battery drain.

Why Critical:

• Background services: Banking apps often run background jobs. If misconfigured to keep the CPU awake, the app could exceed the threshold, leading to public “battery hog” warnings
• Store discoverability: Being demoted in Play discovery means fewer organic installs
• User trust: A battery warning on our app’s listing could undermine user confidence

Impact Surfaces: Long-running background processes (balance refresh, biometric listeners, location-based offers), third-party SDKs with misuse of WakeLock

Actions:

• Audit the app for any explicit WakeLock usage or implicit wake locks. Ensure they release properly
• Use Play Console Android Vitals to check current Excessive Wake Locks metrics
• Optimize or remove long wake locks. Use JobScheduler with flexible execution windows instead of indefinite wake locks
• Prepare communication in case a battery warning appears

Test Matrix:

• Devices: One low-end device and one high-end
• OS: Android 13, 14, 15
• Scenarios: Simulate edge cases (e.g., user leaves app in background during OTP flow)
• Monitoring: Use Android Studio Profiler or adb shell dumpsys batterystats to capture wake lock usage

CRITICAL Released: December 12, 2025

Apple released iOS 26.2 and iPadOS 26.2, addressing over 20 security vulnerabilities, including two WebKit bugs actively exploited in targeted attacks. The exploited flaws allow malicious web content to execute arbitrary code or cause memory corruption. Other fixes cover App Store payment token exposure, image processing memory corruption, and a Hidden Photos album bypass.

Why Critical:

• Zero-day exploits: At least two WebKit vulnerabilities were used in sophisticated attacks. A compromised WebView inside our app (e.g., during OAuth or 3DS) could be an entry point if the device isn’t updated
• App security & privacy: One patched bug allowed viewing Hidden album photos without auth – signals potential privacy weaknesses that could indirectly expose sensitive images used in KYC or mobile check deposit flows
• Platform stability: iOS 26.2 is now the latest stable; Apple typically requires apps to be built with the latest SDK by next year

Impact Surfaces: In-app web content (WKWebView) such as 3D Secure or OAuth login flows. Face ID/Touch ID and Keychain appear unaffected.

Actions:

• Upgrade test devices to iOS 26.2 (and iPadOS 26.2). Verify our app functions normally, especially web-based flows
• Re-run biometric login, OTP flows, and secure document upload on 26.2
• For users on older iOS (like 18.7.3), consider an in-app message encouraging updating
• Ensure the app is built with at least Xcode corresponding to iOS 26 SDK

Test Matrix:

• Devices: iPhone 15 (iOS 26.2), iPhone 12 (iOS 18.7.3 legacy), iPad mini 7 (iPadOS 26.2)
• Focus Tests: WKWebView flows (3DS), login with Face ID/Touch ID, share sheet
• Network: Use a proxy to observe if any new ATS or certificate pinning behaviors

HIGH Released: December 2, 2025 (Chrome 143.0.7499.40)

Google promoted Chrome 143 to stable on all platforms, which includes 13 security fixes. Among the patched issues is a high-severity V8 JavaScript engine type confusion (CVE-2025-13630) that could potentially lead to arbitrary code execution. No known active exploits yet, but a prior emergency patch fixed a zero-day, indicating attackers are targeting Chromium components.

Why it matters:

• Embedded WebView: Our Android app relies on Android System WebView. Chrome 143’s fixes apply to WebView 143, significantly reducing risk of malware-injected web content exploiting the WebView
• 3DS/OAuth flows: High-severity browser exploits could be triggered during redirections – patching ensures a rogue ACS or login page cannot compromise the app sandbox
• New features: Chrome 143 doesn’t introduce breaking web platform changes for OAuth/3DS (e.g., Read Aloud API, minor CSS enhancements mostly benign)

Impact Surfaces: In-app web content (SameSite cookies, CSP). OAuth login persistence should behave unchanged.

Actions:

• Ensure WebView 143 is installed on test devices and run full 3DS challenge flows and OAuth login flows
• Pay attention to any console logs or deprecation warnings in WebView during testing
• Force-update WebView/Chrome on QA devices and encourage end-users to keep Chrome up to date
• If anomalies appear, gather console logs and compare with Chrome 142 behavior

Test Matrix:

• Android Devices: Pixel 7 (Android 14) with WebView 143, Samsung S22 (Android 13) with WebView 143, one device with WebView 142 for comparison
• Flows: Login via Google SSO, Payment with 3D Secure challenge, Open bank T&C PDF in WebView
• Web Content: Test deep links and App Links to ensure Chrome’s update didn’t affect intents

MEDIUM Published: December 4, 2025 (WebKitGTK 2.50.3)

The WebKitGTK and WPE WebKit engines received an advisory addressing multiple vulnerabilities. Notably, one flaw could allow a malicious website to exfiltrate sensitive system information, and several others could lead to unexpected process crashes.

Why it matters:

• Cross-platform users: Some customers might access our web internet banking or 3DS flows on Linux desktop browsers that use WebKitGTK
• Consistency: Tracking WebKit advisories ensures our web-based components maintain secure parity with mobile
• No immediate mobile impact: iOS uses Apple’s WebKit (patched separately) and Android uses Chromium WebView

Impact Surfaces: 3DS web pages or OAuth on Linux devices. Internal admin tools using WebKitGTK browser.

Actions:

• If any team maintains web banking features, ensure WebKitGTK >= 2.50.3 is used on any Linux kiosks
• Update any Linux-based automated scanners or headless browsers
• Keep an eye on similar issues in Apple’s WebKit

Test Matrix: Use a Linux VM with WebKitGTK 2.50.3 and run our bank’s public website, login page, and a sample 3DS flow

MEDIUM Released: December 2, 2025

The popular Android rooting tool Magisk has reached version 30.6, marking a major update with a significant portion of its codebase rewritten in Rust. This update aims for better stability and security for the root tool itself, but still provides robust hiding features (Magisk Hide) that allow rooted devices to evade detection.

Why it matters (Attacker POV):

• Improved stealth: A more stable Magisk means attackers have an easier time maintaining root without detection. The Rust rewrite eliminates many memory bugs
• MagiskHide revival: Forks and modules reintroduce hide functionality. Magisk v30.6 integrates hiding mechanisms effectively
• Attestation bypass: Combined with modules, Magisk v30 can help a device pass Play Integrity’s STRONG verdict even while rooted

Why it matters (Defender POV):

• RASP & integrity: Our app’s root detection must be updated to account for Magisk 30’s changes
• Debugging challenges: The new Rust-based Magisk might alter how root hiding interacts with debuggers
• KernelSU synergy: Users are increasingly using KernelSU alongside Magisk, leaving system partition untouched

Attacker/User Capabilities Observed:

• Rooted users running Magisk 30.6 (or KernelSU) have reported success running many banking apps by hiding root
• Community has created Magisk modules to patch specific bank apps’ detection (e.g., “patch prctl”)
• With Magisk’s stability improvements, more average users might attempt rooting

Defensive Actions:

• Update root detection: Look for signs of both Magisk and KernelSU (check /dev/kernelsu device)
• Play Integrity API: Place greater reliance on Google’s Play Integrity evaluationType
• Dynamic analysis: Install Magisk 30.6 on test devices and verify if our app detects it
• Continuous monitoring: Monitor forums (XDA, Telegram, VOZ) for Magisk modules targeting our app

Test Matrix:

• Devices: Pixel 6 (rooted with Magisk 30.6), Xiaomi device (rooted with KernelSU + Magisk), non-rooted control
• OS: Android 13 and 14 for Magisk, Android 15 for KernelSU
• Flows: Full login -> balance -> transfer on rooted device with root hidden
• Telemetry: Enable verbose logging in test build to capture root check triggers

MEDIUM Released: November 4-5, 2025 (Frida 17.5.0 & 17.5.1)

The Frida dynamic instrumentation toolkit saw a “feature-packed” 17.5.0 release. Major highlights include a smarter Frida compiler, more robust iOS (Darwin) injection internals, and a complete overhaul of the Swift bindings to use modern concurrency.

Why it matters:

• Resilience against detection: As Frida becomes more stable, our anti-instrumentation measures might fail. Frida 17.5’s improved Darwin injection might avoid telltale patterns we previously checked
• Swift bindings: Frida’s new Swift API is more “Swift-native,” making hooks more seamless and harder to spot. Attackers can now write Frida scripts in Swift
• Cross-platform ease: Frida’s enhancements are “platform-agnostic” and “delegate-free”, implying fewer complications for attackers

Attacker Capabilities:

• A Frida user can inject scripts more efficiently (less crash-prone) on iOS 17+/18
• The “smarter compiler” optimizes payloads, meaning a smaller footprint in memory. This could evade simplistic “scan memory for known Frida strings” defenses

Defensive Actions:

• Update Frida detection rules: Test against Frida 17.5 – signatures might have changed
• Runtime obfuscation: Continue efforts to obfuscate critical code (OTP generation, PIN validation)
• Monitor for Frida presence: Use multiple signals (listening port AND default named unix socket /tmp/frida-*)
• Penetration testing: Engage internal red team or external pentest to use Frida 17.5 against our app
• Server-side checks: Re-emphasize server-side anomaly detection for suspicious app behavior

Test Matrix:

• Android: Pixel 5 (Android 12) with Frida 17.5.1 server running; attempt to hook critical methods
• iOS: Jailbroken iPhone 13 (iOS 18.0) with Frida 17.5.0 gadgets injected
• Observation: Track performance impact – defensive checks shouldn’t degrade app performance

Thread: “Thao luan ve root bang Magisk, module, giai phap an root (24+)” – VOZ Forums Crawl Date: Dec 13, 2025 – capturing 10 most recent posts (#6461–#6470)

Pulse Summary (Vietnam Developer Community)

• VPBank app – Mixed results under root: One user reports bypass success (passes Strong Integrity, app working), but another still gets rooted device warning at login. (Root environment: KernelSU Next + Magisk hide)
• MoMo e-wallet – Crash at biometric stage: After hiding root and clearing data, MoMo consistently crashes during face verification (eKYC selfie step) on rooted devices
• MB Bank – New update heightened detection: Latest MB Bank app version detects root where previous version did not. Community suggests using newest KernelSU or applying “patch prctl” tweak (unverified)
• Techcombank app – No current bypass: App fails to fully log in on rooted devices. Blocking the root-check domain removed the in-app warning page, but login still doesn’t complete (stuck at OTP)
• General – Legacy root-hiding methods (e.g., BShield module) are reported ineffective on modern banking apps

Recent Reports Table

(Above posts are user-generated content from a developer forum, unverified by official sources. Interpret with caution – trust level low.)

Source: VOZ Root Discussion Thread

Mobile Banking Security Weekly #4 · December 13, 2025
Critical security patches require immediate action · Plan your January compliance
Questions? Contact phamdinhkhoivan@gmail.com