
A single missing check in Android lets one user's screen reader leak another user's private...
A single missing check in Android lets one user's screen reader leak another user's private notifications. Here's how it happened.
Android's multi-user support lets several people share one device. Each user gets their own space, apps, and data. This feature is common on tablets. But not all smartphones have it. Even so, the code is there. The problem is that accessibility services run with high privileges. They need to see everything to help users. Sometimes, this power breaks the walls between users.
Screen readers turn text into speech. They allow people with low vision to use apps. The screen may even be completely off, but the user can still interact with the device. TalkBack is Google's screen reader for Android. Normally, TalkBack only reads the currently focused UI elements. But there are ways to make it speak programmatically.
One is announceForAccessibility() (now deprecated) – a method that forces the screen reader to read arbitrary text. Another is live regions – parts of the UI that update without user interaction. When something changes, the system fires an accessibility event (a system-level broadcast) that carries the updated text. A screen reader picks it up and reads the new value aloud. Status bar notifications are one example of live regions.
The bug was simple: NotificationManagerService didn't check if a notification belonged to the current foreground user before dispatching the accessibility event. This is what caused screen readers to read it out loud.
Imagine a phone with two users: Alice (using the phone right now) and Bob (a background user).
Screen readers weren't the only apps that could intercept this data. Android dispatches accessibility events to all registered accessibility services – not just TalkBack. Apps like Tasker, which registers as an accessibility service for UI automation, or notification-logging apps would also receive Bob's notification content.
The entire fix was a single added condition – checking whether the notification actually belongs to the current user – plus a unit test to prevent regression:
// frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java
- && !suppressedByDnd) {
+ && !suppressedByDnd
+ && isNotificationForCurrentUser(record)) {
isNotificationForCurrentUser() returns true only when the notification's owner matches the foreground user – so background users' notifications are no longer broadcast as accessibility events.
The issue was reported on June 29, 2022. Google awarded a $5,000 bounty for the finding. They marked the bug as High severity in the November 2022 Android Security Bulletin and released patches for Android 10, 11, 12, 12L, and 13. The vulnerability is tracked as CVE-2022-20448.
It really makes you wonder just how many security bugs are hiding behind assistive technologies.
aiMost of us have seen a coding agent fail to complete a task we know it can do. We just don't...
googlecloudWhen building Generative AI applications, developers often encounter a massive bottleneck: sequential...
discussI’ve been thinking about sharing some electronic circuit posts on Dev.to — small circuits, DIY...
agentsWhat nobody tells you about exporting your multi-agent prototype to a local workspace. Every...
agenticarchitectAutonomous agents are genuinely good at answering messy business questions. Give one an LLM and a set...
aiPR volume went up, ticket quality didn't, and the gap got filled with LLMs on both sides of the review: bots reviewing, bots replying, bots occasionally arguing with bots about priorities that only existed in a teammate's head. Our CEO named the actual problem, and it's bigger than code review.
Workflows from the Neura Market marketplace related to this Stable Diffusion resource