Microsoft Edge for android Ask Copilot Prompt Injection

TLP:CLEAR

Prompt Injection in Microsoft Edge for Android: Ask Copilot Contextual Selection Vector

Advisory ID: LOSTMON-2026-0718  ·  MSRC Case: VULN-202824  ·  Published: October 18, 2026  ·  Severity: Provisional — CVSS v4.0 vector under finalization

Author: Manuel García Peña (Lostmon)  ·  https://lostmon.blogspot.com

Contents

1. Executive Summary
2. Vulnerability Details
3. Relationship to CVE-2026-48561
4. Potential Attack Scenarios
5. Observations with Other AI Assistants
6. Root Cause Analysis (Hypothesis)
7. Impact Assessment (Provisional)
8. Mitigation Recommendations
9. Disclosure Timeline
10. References
11. Contact Information
12. Revision History

1. Executive Summary

A prompt injection issue was identified in the integrated Ask Copilot feature of Microsoft Edge for Android.

In the tested scenario, instructions embedded in web page content influenced the response generated by Copilot after the user selected page text and explicitly invoked Ask Copilot through the contextual menu.

The observed behavior demonstrates that untrusted web content can influence the assistant's response in a user-initiated interaction. This may create opportunities for deceptive content generation, phishing assistance, or the presentation of malicious links as legitimate information.

This finding concerns the contextual text-selection interaction and is distinct from the previously reported automatic injection vector associated with CVE-2026-48561. The relationship between the earlier patch and this behavior should be assessed against the verified scope of that fix.

This public report describes the affected interaction, observed behavior, potential impact, and recommended mitigations. Exploit code and step-by-step reproduction instructions are intentionally omitted.

The findings and severity assessment apply to the tested configuration and should not be interpreted as evidence that all versions or all Copilot interactions are affected.

2. Vulnerability Details

Vulnerability Type	Prompt Injection (user-initiated, contextual selection)
CWE / Related Taxonomy	CWE mapping under review. MITRE ATLAS AML.T0051 (Prompt Injection) is provided as a related AI threat taxonomy, not as a CWE identifier. CWE-20, CWE-77 and CWE-94 are not asserted in this advisory.
Affected Component	Microsoft Edge for Android — "Ask Copilot" contextual menu feature
Attack Vector	Remote (AV:N)
User Interaction	Required — the user selects page text and invokes "Ask Copilot"
Privileges Required	None
CVSS v4.0	Provisional — see §7. The vector is documented metric by metric; no numeric score is published in this version pending confirmation with the official FIRST CVSS v4.0 calculator.
Relationship to CVE-2026-48561	Distinct interaction surface. The behavior described here was observed in the tested configuration after the July 14, 2026 patch associated with CVE-2026-48561. Whether that patch was intended to cover this vector is not established by the researcher; see §3.
MSRC Case	VULN-202824 (reported July 18, 2026)
Disclosure Coordination	Reported to Microsoft MSRC (case VULN-202824).

Description

The "Ask Copilot" feature in Microsoft Edge for Android allows users to select text from a web page and send it to the integrated AI assistant via the contextual menu. The selected text is transmitted to Copilot as context for generating a response.

The interaction surface can be described along three dimensions that this advisory distinguishes deliberately:

• Content visible to the user. Text the user can read on the page and that is part of the natural selection intent.
• Content present on the page but not evident to the user. Text rendered on the page in ways that make it non-obvious (for example, styling that renders it effectively invisible) while remaining inside the selectable region.
• Content actually transmitted to Copilot. The subset of the selection that the assistant receives and processes as context.

In the tested scenario, the assistant's generated response reflected content that had been embedded in the selected page content. This indicates that, within the tested interaction, the assistant did not clearly separate the user's intended request from instructions present in the selected material.

Observed behavior

In the tested configuration, the response produced by Copilot reflected the embedded instructions and was generated without a visible security warning. The response was presented in a plausible professional tone and included a link that was framed as a legitimate resource. No indication was surfaced to the user that the response had been conditioned by untrusted content. The specific payload, the step-by-step reproduction, and the response contents are intentionally withheld from this public advisory.

The observation supports the finding that untrusted page content can condition the assistant's output in a user-initiated "Ask Copilot" interaction. It does not, by itself, establish the internal mechanism responsible (see §6).

3. Relationship to CVE-2026-48561

CVE-2026-48561 (patched July 14, 2026, in Microsoft Edge for Android) was published by Microsoft as a separate issue concerning an automatic injection vector. The comparison below is limited to the publicly described scope of that CVE and to the difference in interaction flow that the researcher observed. The internal implementation of the CVE-2026-48561 fix has not been independently confirmed by the researcher, and no claim is made in this advisory about which internal mechanisms it does or does not address.

Aspect	CVE-2026-48561 (publicly described scope)	Vector described in this advisory
Interaction flow	Automatic — no user action beyond loading the page, per the CVE description.	User selects text and invokes "Ask Copilot".
User interaction	Not required, per the CVE description.	Required — user must select text and invoke the feature.
Component	As described in the CVE record.	"Ask Copilot" contextual menu feature.
Platform	Microsoft Edge for Android.	Microsoft Edge for Android.
Patch status (of the vector described here)	Not applicable.	The behavior described in this advisory was observed in the tested configuration on Microsoft Edge for Android after the July 14, 2026 patch associated with CVE-2026-48561.

Scope limitation: the observation that the behavior was reproducible after the CVE-2026-48561 patch does not, by itself, establish that the patch was intended to cover this vector, nor that the two issues share a root cause. The relationship between the two should be evaluated against the verified scope of the fix.

4. Potential Attack Scenarios

The scenarios below describe potential outcomes inferred from the observed behavior. They were not reproduced as end-to-end attacks in this research and are presented to illustrate the classes of risk that a successful conditioning of the assistant's response could enable.

Scenario	Description	Potential impact
Phishing	An assistant response presents an attacker-controlled link as if it were a legitimate resource.	A user follows the link; credentials or data could be exposed.
Social engineering	An assistant response presents content framed as an urgent security notice.	A user acts on the notice (e.g., initiates a password reset, installs software).
Disinformation	An assistant response presents false information as if it were authoritative.	A user makes a decision based on the manipulated content.
Credential harvesting	An assistant response invites the user to provide sensitive information.	A user shares confidential information in a subsequent interaction.
Impersonation	An assistant response impersonates an official communication channel.	A user trusts a fraudulent communication.

5. Scope of the Tested Vector

This advisory is scoped exclusively to the interaction flow observed in the tested configuration of Microsoft Edge for Android under MSRC case VULN-202824. Broader comparative research across other browser-integrated AI assistants was conducted as part of the underlying investigation, but those observations are outside the scope of this specific advisory and are not asserted here.

The findings and severity assessment apply to the tested Microsoft configuration and should not be interpreted as evidence that all versions, all browsers, or all Copilot interactions are affected.

6. Root Cause Analysis (Hypothesis)

The observed behavior indicates that instructions embedded in user-selected web content can influence Copilot's generated response. This suggests insufficient isolation between untrusted content and the intended user request in the tested interaction flow. The precise internal implementation responsible for this behavior has not been independently established.

The following is presented as a technical hypothesis supported by the observed behavior, not as a confirmed internal mechanism of the tested product:

• In the tested interaction, the assistant's generated response did not clearly distinguish the user's explicit request ("Ask Copilot") from instruction-like content present within the selected page text.
• The observation is consistent with a processing flow in which selected untrusted content is treated, at least partially, as guidance for the model's output rather than strictly as data to be reasoned about.
• Whether such behavior stems from prompt construction, model behavior, missing post-generation safeguards, or a combination thereof, cannot be determined from the external observation alone.

Scope of this claim: this advisory does not assert that no sanitization is present. It asserts that, in the tested interaction, the assistant's output was conditioned by untrusted content in a way that produced a response reflecting the embedded instructions without a visible warning to the user. Internal mechanisms remain outside the scope of external verification.

7. Impact Assessment (Provisional)

Provisional. The impact assessment and the CVSS v4.0 vector are published as provisional. Metric choices are documented below; the numeric score will be computed from the final vector using the official FIRST CVSS v4.0 calculator and is not estimated in this advisory.

Dimension	Rating	Justification
Confidentiality	Not demonstrated	No direct data exfiltration was observed. Confidentiality exposure could occur indirectly as a downstream effect of social engineering, but is not demonstrated by the observed behavior itself.
Integrity	Demonstrated (partial)	The content and trustworthiness of the generated response were affected in the tested scenario. No modification of system data or other system-level integrity impact was demonstrated.
Availability	Not demonstrated	The observed behavior shows response manipulation, not a denial-of- service condition or a loss of availability of the assistant. This advisory does not assert an availability impact.
Subsequent systems	Not demonstrated	No impact on systems beyond the assistant's response content was demonstrated. No system compromise, lateral movement, or device integrity impact is asserted.
User interaction	Required	The interaction requires the user to select page text and explicitly invoke "Ask Copilot".

Provisional CVSS v4.0 vector

The vector below is expressed with the mandatory CVSS:4.0/ prefix and the official FIRST metric order. It documents the metric choices made against the observed behavior. It is not accompanied by a numeric score in this version.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Metric	Value	Rationale
AV	N	Content is delivered remotely via web pages.
AC	L	No special conditions beyond standard user interaction were observed.
AT	N	No additional attack requirements beyond the standard interaction were identified in the tested scenario.
PR	N	No privileges required on the target device.
UI	A	Active user interaction is required: selecting text and invoking the feature.
VC	N	No confidentiality impact demonstrated.
VI	L	The content and trustworthiness of the generated response were affected in the tested scenario, consistent with a partial loss of integrity. VI:H was considered and set aside: the observation does not establish a total loss of integrity of the vulnerable system, nor modification of system data.
VA	N	No availability impact demonstrated.
SC	N	No subsequent-system confidentiality impact demonstrated.
SI	N	No subsequent-system integrity impact demonstrated.
SA	N	No subsequent-system availability impact demonstrated.

Numeric score: to be computed from the final vector using the official FIRST CVSS v4.0 calculator and published together with the confirmation of the metric choices above. No numeric value is stated in this version.

8. Mitigation Recommendations

Mitigations are ordered by expected effectiveness, not by implementation effort. Phrase-based filtering and length limits do not, on their own, resolve prompt injection; they are complementary at best.

1. Instruction / content separation (primary). The assistant should treat user-selected page content strictly as data to reason about, not as instructions to be followed. The user's explicit request ("Ask Copilot") should remain the authoritative instruction, and content inside the selection should not be able to override or extend it.
2. Generation safeguards (primary). Outputs that present links, recommend downloads, or invite the user to provide sensitive information should be subject to dedicated safeguards: origin surfacing, confirmation prompts, or refusal to render attacker-controlled URLs as authoritative content.
3. Validation of sensitive actions (primary). Any action initiated from the assistant's output that has a security-relevant effect should require explicit user verification that is not satisfiable from the selected content alone.
4. User-visible warnings (complementary). When the selected content is consistent with instruction-injection patterns, display a warning to the user before generating the response. This reduces risk at the margin but does not substitute for (1)–(3).
5. Phrase-based filtering and length limits (complementary). Detection of instruction-like phrasing and enforcement of a maximum length on the selection can raise the cost of some variants, but are not a complete mitigation and should not be presented as one.

User-level mitigations

• Treat "Ask Copilot" outputs that present links or request actions with the same caution as the underlying page.
• Avoid invoking "Ask Copilot" on pages from sources you do not trust, particularly when selecting large amounts of text.
• No single user-level configuration was identified that eliminates the behavior described in this advisory.

9. Disclosure Timeline

Date	Event
July 14, 2026	CVE-2026-48561 published by Microsoft (different vector).
July 18, 2026	Vulnerability discovered and confirmed by the researcher.
July 18, 2026	Report submitted to Microsoft Security Response Center (MSRC).
July 19, 2026	Microsoft acknowledges receipt and assigns case VULN-202824.
August 12, 2026	Microsoft requests the publication plan and the report template to be published.
August 18, 2026	Microsoft requests the intended publication date.
October 18, 2026	Public advisory published (TLP:CLEAR, PoC withheld).

10. References

1. Microsoft Security Response Center — msrc.microsoft.com
2. CVE-2026-48561 — Microsoft Copilot Remote Code Execution Vulnerability.
3. CVE-2026-55145 — Outlook Copilot Tampering Vulnerability.
4. MITRE ATLAS — Prompt Injection (AML.T0051).
5. OWASP — Prompt Injection.
6. CVE-2026-33111 — Copilot Chat (Microsoft Edge) Information Disclosure Vulnerability.
7. EchoLeak (CVE-2025-32711) — Zero-click Prompt Injection in Microsoft 365 Copilot.
8. HashJack — Indirect Prompt Injection Attack targeting AI browsers.
9. Reprompt Attack — Single-click Data Exfiltration from Microsoft Copilot.
10. FIRST — Common Vulnerability Scoring System v4.0 Specification.
11. Research blog — https://lostmon.blogspot.com

11. Contact Information

Researcher	Manuel García Peña (Lostmon)
Email	lostmon@gmail.com
Blog	https://lostmon.blogspot.com
Advisory ID	LOSTMON-2026-0718
MSRC Case	VULN-202824
Disclosure Coordination	Reported to Microsoft MSRC (case VULN-202824).
Disclosure Date	October 18, 2026

12. Revision History

Version	Date	Notes
0.1 – 0.9	Jul 18 – Aug 12, 2026	Internal drafts and technical material shared with MSRC (VULN-202824). Not for public distribution.
1.0	October 18, 2026	Public release (TLP:CLEAR). PoC withheld. Root-cause language revised to reflect the limits of external observation. CVSS v4.0 metrics restated as provisional; VA:H revised to VA:N. CWE assignment deferred pending review.
1.1	October 18, 2026	CVSS v4.0 vector expressed with the mandatory CVSS:4.0/ prefix and official metric order. VI:H revised to VI:L to reflect a partial integrity impact limited to the generated response. ATLAS AML.T0051 explicitly separated from CWE taxonomy. Disclosure status restated as reported facts (MSRC only). Numeric CVSS score no longer estimated verbally; to be computed from the final vector.

TLP:CLEAR — This advisory may be freely shared.

This document is provided for defensive and coordination purposes. The PoC has been intentionally withheld from the public version. Authorized security teams may request the technical details directly from the researcher under MSRC case VULN-202824.

© 2026 Manuel García Peña (Lostmon) — lostmon.blogspot.com

CWE New Weakness Submission

Structured Text Amplification (STA)

Proposed Weakness Name: Unbounded Structured-State Propagation Across Processing Layers

Short Name: STA — Structured Text Amplification

Submitted by: Manuel García Peña (Lostmon) — Independent Security Researcher

1. Description

Unbounded Structured-State Propagation Across Processing Layers occurs when software accepts or transports structured textual input without enforcing an appropriate security-relevant resource bound, and the input, or state derived from it, is subsequently retained, propagated, materialized, transformed, or serialized across multiple processing layers.

Downstream components may independently process the resulting state without applying limits that account for its origin or cumulative resource impact. Repeated materialization and serialization across independent consumers can cause large inter-process communication (IPC) transactions, excessive resource consumption, transaction failures, incomplete state reconstruction, application failures, or cascading denial of service.

The weakness arises from the interaction between unbounded structured state and resource-constrained processing boundaries. Relevant inputs may include URLs, URIs, deep links, intent data, structured text, serialized payloads, and associated metadata or extras.

The originating component may accept or transport the input without a security-relevant size or complexity bound. The input, or state derived from it, can then become part of persistent or semi-persistent application or framework state. Subsequent components may retrieve that state and construct new representations for task management, lifecycle operations, window management, IPC, user-interface updates, or other consumers.

Each individual component may behave according to its local implementation contract, while the system as a whole fails to constrain the cumulative resource requirements of the propagated state. A representation may be serialized repeatedly or delivered through multiple independent interfaces. The same state, or state derived from the original input, may therefore reach consumers that did not participate in the original validation decision.

When a transaction or processing operation exceeds an implementation-specific resource limit, the result may include TransactionTooLargeException, failed IPC delivery, incomplete deserialization or state reconstruction, application termination, repeated component restarts, or cascading denial of service. Recovery mechanisms that repeatedly reconstruct or redistribute the affected state may prolong or intensify the failure.

2. Defining Characteristics

The weakness is characterized by the combination of:

1. Structured input or derived state that lacks an effective security-relevant resource bound.
2. Propagation of that state across multiple processing layers.
3. Repeated or independent materialization, transformation, or serialization by downstream components.
4. Failure to enforce appropriate resource limits at relevant processing and communication boundaries.
5. Resource exhaustion or cascading failures arising from the interaction between these layers.

The weakness does not require a specific serialization format, programming language, operating system, IPC mechanism, or fixed amplification ratio. It may occur even when no individual component performs an obvious multiplicative expansion. Its defining property is the cross-layer propagation and repeated processing of insufficiently bounded state.

3. Re-materialization

Re-materialization is the reconstruction or creation of a representation of existing state for a subsequent consumer or processing stage. For example, state originating in a URI or structured input may be incorporated into an Intent or task, later included in task metadata, serialized into an IPC transaction, and then reconstructed or queried by another component.

The same state, or state derived from the original input, may be materialized independently for multiple consumers that did not participate in the original validation decision. This can propagate resource pressure beyond the component that first accepted or transported the input.

Re-materialization is a defining mechanism of this weakness, but its presence alone is not sufficient to establish a vulnerability. The relevant condition is insufficiently bounded state propagation that results in, or can technically substantiate, resource exhaustion or a failure condition.

4. Relationships to Other CWE Entries

Potential relationships for CWE review:

• ChildOf CWE-400: Uncontrolled Resource Consumption.
• ChildOf CWE-770: Allocation of Resources Without Limits or Throttling.
• Related to CWE-405: Asymmetric Resource Consumption (Amplification).
• PeerOf CWE-130: Improper Handling of Length Parameter Inconsistency.
• PeerOf CWE-502: Deserialization of Untrusted Data.

These relationships are proposed for evaluation and should not be interpreted as a claim that STA is identical to any of the existing weaknesses.

STA focuses on cross-layer propagation and repeated materialization or serialization of insufficiently bounded structured state. It does not require a measurable byte-amplification ratio, a length-field inconsistency, or unsafe object deserialization.

CWE-833 (Deadlock) is not an inherent relationship: the described failure can occur without a demonstrated deadlock.

5. Security Properties and Consequences

Confidentiality Impact: Not established by the described weakness alone.

Integrity Impact: Not established by the described weakness alone. Recovery or state-management side effects must be demonstrated separately before assigning an integrity impact.

Availability Impact: High, where the weakness causes persistent application failure, repeated component crashes, exhaustion of shared IPC resources, or disruption of system services.

Potential consequences include:

• Denial of service.
• Application launch failures or process termination.
• Failed IPC transactions.
• Incomplete deserialization or state reconstruction.
• Repeated component restart loops.
• Degradation or failure of shared system-interface components.
• Cascading failures across components that consume or reconstruct the affected state.

6. Modes of Introduction

The weakness may arise from architectural or implementation decisions, including:

• Accepting or transporting structured input without an appropriate size or complexity bound.
• Persisting input, or state derived from it, in application or framework state.
• Reusing unbounded state across task, lifecycle, navigation, or window-management operations.
• Serializing state to IPC consumers without accounting for transaction limits.
• Relying on validation performed by an earlier component when later components independently materialize or serialize the state.
• Retrying failed operations or reconstructing state without reducing, bounding, or isolating the problematic data.

The weakness is language-agnostic and can affect operating-system frameworks, applications, browsers, messaging software, and other systems that propagate structured input across processing boundaries.

7. Affected Technologies and Examples

Potentially affected technologies include:

• Operating-system task and activity frameworks.
• Intent and deep-link routing.
• IPC and serialized message transport.
• Window-management and task-organizer interfaces.
• Recent-task and application-lifecycle management.
• Browser and application integrations that pass structured state to system components.
• Text-processing and rendering paths where structured text is repeatedly measured, shaped, or laid out.

Android Binder is one example of an IPC mechanism in which transaction-size limits can make this class of weakness observable. The weakness is not specific to Android or Binder.

8. Detection and Testing

Detection should examine the full lifecycle of structured input rather than testing only the initial parser or receiving component.

Useful approaches include:

• Instrumenting IPC transaction sizes and identifying repeated large transactions associated with the same input or derived state.
• Tracing structured input through Intent, URI, task, metadata, serialization, and consumer boundaries.
• Testing each entry point and delivery path while holding the underlying test input constant.
• Recording application and system-component crashes, transaction failures, incomplete state reconstruction, and recovery loops.
• Performing static analysis of serialization and materialization paths to identify missing resource bounds.
• Fuzzing structured input across multiple consumers and observing cumulative resource effects.
• Distinguishing correlation from causation by isolating the state fields and transaction paths responsible for observed failures.

A large input, a large transaction, or a crash in isolation is not sufficient to establish STA. Testing should substantiate the propagation mechanism and the resulting resource-exhaustion or failure condition.

9. Mitigation

Mitigation should apply resource bounds at multiple relevant boundaries:

• Enforce size and, where appropriate, complexity limits when structured input is first accepted.
• Apply independent validation when input-derived state is persisted, retrieved, or materialized for a new consumer.
• Bound fields such as URI data, captured links, extras, metadata, and serialized representations where applicable.
• Avoid repeatedly embedding unbounded state in task, lifecycle, or window-management metadata.
• Enforce serialization and IPC limits before sending transactions, with graceful failure handling.
• Avoid retry loops that repeatedly submit the same oversized state.
• Isolate state and failures between consumers so that one invalid or oversized representation cannot destabilize shared components.
• Add regression tests that exercise multiple delivery paths and downstream consumers, not only the original input handler.
• Ensure recovery paths can discard, truncate safely, or otherwise isolate invalid state without repeatedly reconstructing it.

A single size check may reduce a particular manifestation but may not eliminate the weakness if derived state can be propagated or materialized through other paths. Effective mitigation requires bounds and failure handling at the relevant acceptance, state, materialization, and serialization boundaries.

10. Observed and Reproduced Android Example

In the Android 16 / HyperOS test environment, structured input delivered through application and deep-link flows was associated with oversized Binder transactions across several framework interfaces. Observed transaction sizes ranged from approximately 365 KB to approximately 1.11 MB in different reproductions.

Observed symptoms included TransactionTooLargeException, failed Binder delivery, BadParcelableException messages indicating incomplete array retrieval, application launch failures, and repeated SystemUI crashes. In one documented reproduction, a sustained SystemUI crash sequence escalated to a RescueParty-triggered reboot.

A separate IntentResolver reproduction showed an ACTION_VIEW flow involving ResolverActivity followed by approximately 556 KB transaction failures, Resolver process launch failure/restart, and a SystemUI failure while querying recent tasks. These observations support the involvement of multiple Android-managed processing and IPC layers.

Reproductions have involved different application families and delivery paths, including browser-mediated links, messaging/deep-link handlers, video links, and Android's IntentResolver. These applications are treated as handlers, consumers, or affected components; the observations do not establish that every involved application independently contains the underlying weakness.

The precise contribution of every field to the observed transaction sizes has not been isolated. The evidence supports a cross-layer propagation and resource-boundary failure model, but does not justify attributing all transaction bytes to a single URI, captured-link field, or application component. The observations also do not establish memory corruption or remote code execution.

11. Distinction Between Entry Points and Root Cause

Different applications or delivery paths may provide independent ways to introduce or transport the same structured input. These paths should not automatically be counted as separate weaknesses.

An application may act as the initial receiver, a deep-link handler, a consumer of derived state, or a point at which the Android framework re-materializes existing state. The fact that a failure becomes visible while one application is active does not, by itself, establish that the application is the root cause.

The architectural question is whether insufficiently bounded state can propagate through multiple processing layers and repeatedly consume constrained resources after the original input-handling decision.

12. Related Mitigations and References

Related platform mitigations, including selective handling of large payloads in browser or application code, may reduce individual manifestations. Such mitigations should not be treated as proof that every framework-level propagation path has been addressed.

Research materials and references should be supplied with the submission and should identify the relevant public technical reports, reproducible observations, source-code references, and any related platform issue identifiers. Claims should be limited to what the referenced evidence demonstrates.

Research blog: https://lostmon.blogspot.com/2026/08/sta-utf-16-serialization-density_01007502893.html

Additional references:

• Android platform and framework source code relevant to Task, TaskInfo, ActivityTaskManager, TaskOrganizer, and Binder IPC.
• Relevant public Chromium changes concerning large-payload handling, where directly applicable.
• Reproduction logs and technical reports supplied privately to the affected vendors, subject to coordinated-disclosure constraints.

13. Rationale for a Distinct Weakness

Existing resource-consumption and amplification categories describe important aspects of this problem, but may not clearly express the cross-layer state-propagation mechanism.

STA identifies a class of failures in which insufficiently bounded structured state is accepted or transported, retained or derived into internal state, and then repeatedly materialized or serialized across independent processing layers. The security-relevant condition emerges from the interaction between the propagated state and the resource limits of downstream consumers.

The proposed weakness is intended to help developers and reviewers recognize that local validation or local resource controls may be insufficient when state is reused across multiple framework boundaries. It emphasizes lifecycle tracing, resource bounds at materialization and serialization boundaries, and containment of failures across consumers.

Submitted by:
Manuel García Peña (Lostmon)
Independent Security Researcher

Proposed short name: STA — Structured Text Amplification
Proposed CWE name: Unbounded Structured-State Propagation Across Processing Layers

Google OSS VRP Pause What It Means for STA Research

Google's OSS VRP Pause: What It Means for STA Research and the Disclosure Ecosystem

On 1 October 2026, Google announced that it would stop accepting product vulnerability submissions to its Open Source Software Vulnerability Reward Program (OSS VRP). The reason: an overwhelming influx of AI-generated reports, including hallucinations, non-reproducible findings, and automated submissions that consumed engineering time without adding security value. The pause took effect the same day and is expected to last until at least Q1 2027.

This is not an isolated incident. Intel had already suspended its bug bounty program. Linux maintainers reported being flooded with AI-generated CVE reports, with some projects dropping support for older drivers as a direct consequence. The bug bounty ecosystem is buckling under the weight of automated noise.

But this post is not about those programs. It is about what the pause means for a specific, ongoing investigation, STA Research, and for the broader problem of how legitimate security findings survive in an environment saturated with AI-generated noise.

---

1. What exactly was suspended

Three distinctions matter:

Program	Status	Scope
OSS VRP: product vulnerabilities	Suspended as of 1 Oct 2026	Code flaws, logic errors, design defects in Google's public repositories
OSS VRP: supply chain reports	Active	Dependencies, build pipelines, third-party components
Android VRP	Active	Android platform, Pixel firmware, Titan M security chip
Chrome VRP	Active	Chrome browser, Chromium
Cloud VRP	Active	Google Cloud products
Patch Rewards Program	Active	Proactive security improvements in open source

The suspension does not affect reports submitted before 1 October 2026, and it does not affect the Android VRP or Chrome VRP programs. Google has explicitly encouraged researchers to use Cloud VRP and Patch Rewards as alternative channels.

---

2. The case that matters: A-477279924

STA Research has an open case in the Google Android VRP: A-477279924, submitted on 20 January 2026. The case documents a class of defects in AOSP's handling of structured text across Binder boundaries, including unbounded TaskInfo serialization, missing size gates in Task.fillTaskInfo(), and the cascade of failures that follows when a single oversized task state is materialized repeatedly across multiple framework interfaces.

The case is currently blocked on an internal dependency (477593694), which according to my analysis corresponds to AOSP CL 3989977, a fix that exists internally at Google but has not been made public.

A-477279924 is not in the suspended program. It lives in Android VRP, not OSS VRP. But the pause matters because:

1. Shared triage resources. The engineers and maintainers who process Android VRP reports are part of the same security organization that has been overwhelmed by OSS VRP submissions. The burnout described in Google's announcement is not confined to one program.
2. Guilt by association. A 40-page technical report with multiple vectors, complete stack traces, and AOSP source verification is exactly the kind of submission that a triage engineer, saturated by AI-generated noise, might mistake for automation. The risk is not that the work is invalid. The risk is that the signal is lost in the noise.
3. The fix is already internal. The fact that AOSP CL 3989977 exists means Google has already identified the defect. The question is whether the OSS VRP pause delays its public release, or whether it accelerates internal prioritization to close the loop without public disclosure.

---

3. Why this affects every legitimate researcher

The OSS VRP pause is a symptom of a larger problem: the cost of generating a report has collapsed, but the cost of validating one has not.

Before large language models, writing a vulnerability report required understanding the code, reproducing the behavior, and articulating the impact. The effort served as a natural filter. Today, a model can produce a 3,000-word report with plausible-sounding analysis and fabricated stack traces in seconds. The human reviewer still has to read it, verify it, and reject it, consuming the same time whether the report is real or hallucinated.

Google's response (pause the program, redesign the intake process, return in Q1 2027) is rational from a resource-management perspective. But it creates a perverse incentive: the noise wins by silencing the signal. Legitimate researchers whose reports are already in the queue, or who discover new vulnerabilities during the pause, have no clear path to disclosure through the affected program.

The alternatives Google suggests (Cloud VRP, Patch Rewards) are valid, but they do not cover the same scope. A finding in AOSP's frameworks/base that affects Android devices is not automatically a Cloud VRP issue. The Patch Rewards Program rewards proactive fixes, not vulnerability reports. The gap is real.

---

4. What this means for STA Research

STA has always been a long-term investigation. The initial report was submitted in January 2026. The finding has been extended through 8 reproduction sessions, 31 documented crash instances, and verification against AOSP source code. The work predates the OSS VRP pause by months.

Three practical consequences:

1. The Android VRP case remains active, but patience is required.
A-477279924 is not suspended. The internal dependency (477593694) is the bottleneck, not the program status. Follow-up should continue, but expectations should be calibrated to the broader organizational pressure.

2. Public documentation becomes more important, not less.
When official channels are congested, the blog and the GitHub repository become the primary record. The technical report is published. The PoC is published. The evidence is timestamped. The absence of a public patch does not mean the finding is invalid. It means the system is slow.

3. Alternative disclosure channels matter.
The CVE assignment process through INCIBE to MITRE is independent of Google's VRP infrastructure. The HackerOne dispute for Xiaomi (#4064049) follows a different path. These are not substitutes for Android VRP, but they are parallel tracks that do not depend on the paused program.

---

5. The bigger question: how does disclosure survive AI noise?

The OSS VRP pause is not the end of bug bounties. It is an inflection point. The industry is being forced to redesign intake, triage, and validation processes around a new reality: automated report generation is cheap, and human review is not.

Some possible directions:

• Proof-of-work for reports. Require a reproducible PoC, a signed environment fingerprint, or a hash-verified test case before a report enters the queue.
• Tiered intake. Separate "first-pass automated scan" reports from "human-verified, reproducible" reports, with different processing paths.
• Reputation systems. Weight reports by the researcher's history of valid findings, with new submitters routed through stricter validation.
• AI-assisted triage. Use models to pre-filter obvious hallucinations, but with the understanding that this creates new failure modes.

None of these are perfect. All of them shift the burden somewhere. But the current model, where a single invalid report costs the same to process as a valid one, is not sustainable.

---

6. What this means for an independent researcher

There is a version of this article that would end at section 5, with the systemic analysis complete and the policy recommendations neatly laid out. That version would be accurate. It would also be incomplete, because it would leave out the part that matters most to those of us who do this work without institutional backing.

The asymmetry was already there before AI. Researchers working at large security firms have salaries, legal teams, PR departments, and colleagues who can validate a finding before it goes out. An independent researcher has a laptop, a test device, and a blog. When a report is ignored, misclassified, or closed without explanation, the institutional researcher moves on to the next thing on their employer's roadmap. The independent researcher carries the cost personally: the hours spent, the reputational risk of publishing, the ambiguity of not knowing whether the work will ever be acknowledged.

AI noise did not create this asymmetry. It made it worse.

The verification burden falls hardest on those with the least capacity to bear it. When triage teams are overwhelmed, the natural response is to apply stricter filters. That is rational. But stricter filters favor submissions that come with institutional credibility markers: company letterheads, internal references, coordinated timelines. A careful independent report, correctly evidenced but unadorned, is more likely to be filtered out than a mediocre report from a known entity. The playing field tilts further, not less.

And then there is the money. Or rather, the absence of it. Bug bounty payouts are inconsistent, but they exist. CVE assignment does not pay anything. Blog readers do not fund research. This work is not a job. There is no salary, no retainer, no consulting fee waiting at the end of a successful reproduction. When the STA investigation was submitted to Google in January 2026, the acknowledgment came with a partial payment of $250. That amount does not begin to cover the hours invested: 8 reproduction sessions across 4 weeks, 31 documented crash instances, 8 bugreports collected by hand, hundreds of logcat lines read one at a time, AOSP source verified commit by commit against android.googlesource.com. If this were billed at any professional rate, the invoice would be five figures. It was not billed. It was never going to be.

This is not a complaint about a specific payout being too low. It is a description of how the economics actually work. The bug bounty programs exist to incentivize disclosure, and for some researchers at some companies, they do. But for the independent researcher working on a class of defects that do not fit neatly into a single CVE, the payout, when it comes, is a symbolic acknowledgment, not compensation. The reward is the recognition. If the recognition does not come, nothing does.

Reputation becomes the only currency, and it is hard to build from scratch. For someone with prior credits from Microsoft, Google, and Mozilla, a closed case is a setback but not a career risk. For someone starting today, without those credits, a single misclassification can be the end of the attempt. The OSS VRP pause raises the barrier to entry not by making the work harder, but by making the acknowledgment of the work less likely. That is a cost the industry is paying without fully pricing it in.

Public documentation is the only defense that does not depend on anyone's goodwill. This is why I keep writing the blog. This is why the GitHub repository exists. This is why every bugreport, every stack trace, every timestamp, every hash is preserved in the open. Not because publication is a threat to anyone, but because publication is the only record that survives a program's silence. When Google pauses OSS VRP, when Xiaomi closes a case as "not applicable" while confirming an internal ticket, when MITRE takes months to assign a CVE, the blog is what remains. It is not a substitute for official acknowledgment, but it is not dependent on it either.

What sustains independent research is not the payout. It is the craft. It is the satisfaction of finding something real, of documenting it correctly, of leaving a trail that another researcher can follow. It is the conversations with people who understand why a 124-byte transaction failing in the same binder session as a 1.1 MB transaction is interesting, when almost no one else does. It is the small community of researchers who recognize each other's work not because a program validated it, but because the work itself stands on its own.

I am not writing this to complain. I am writing it because the current conversation about AI noise in bug bounties is happening mostly among people whose institutional positions protect them from the consequences. The companies will adapt. The programs will redesign. The platforms will survive. The question that is not being asked loudly enough is: what happens to the researchers who cannot wait for the redesign?

Some will move on to other work. Some will publish less. Some will stop. The loss will not be visible in any quarterly report, because the value of a finding that was never made is not measurable. But it is real, and it is being priced into the ecosystem silently.

For my part, I intend to keep going. STA has too much unfinished business: the CVE assignment through INCIBE and MITRE, the HackerOne dispute with Xiaomi, the follow-up on A-477279924, the reproduction sessions that keep adding new evidence. None of that depends on Google's VRP status. All of it depends on doing the work and documenting it honestly. And none of it pays in any direct sense. That is not the point. The point is that the work is worth doing, and someone has to do it.

The pause is a setback. It is not the end of the investigation.

---

7. What I am doing now

While the OSS VRP pause runs its course:

• The Android VRP case remains open. I will continue to follow up on A-477279924 and the internal dependency.
• Public documentation continues. The blog and GitHub repository are the primary record of the investigation.
• CVE assignment proceeds through INCIBE to MITRE. This path does not depend on Google's VRP status.
• The HackerOne dispute for Xiaomi (#4064049) remains active. The contradiction between "not applicable" and the internal ticket XS-112757 is documented.
• New reproduction sessions continue. The finding is not static; the evidence base grows.

---

8. A note on the irony

The STA research documents a class of defects that arise when structured input is allowed to propagate without size constraints across processing layers. The OSS VRP pause is a different manifestation of the same underlying pattern: an unconstrained input channel (automated report generation) overwhelming a downstream processing layer (human triage), producing a cascading failure (program suspension).

The difference is that in STA, the fix is technical: bound the field, gate the transaction, degrade gracefully. In the bug bounty ecosystem, the fix is procedural: redesign intake, separate signal from noise, restore the economic asymmetry between generating a report and validating one.

Both problems are solvable. Neither will be solved by pretending the input is not there.

Project links:

• https://lostmon.blogspot.com
• https://github.com/Lostmon/STA-Structured-Text-Amplification

Related posts:

• STA Class A: Unbounded TaskInfo serialization in ActivityTaskManagerService
• STA: 48 Hours Later, The Chrome Correlation and the VRP Case Status
• Upstream Android and Chromium Changes in 2026: Converging with the STA Model

AI can exponentially expand the search surface, but security still depends on the ability to demonstrate causality, reproducibility, and impact.

Manuel García Peña ("lostmon") is an independent security researcher. Prior public vulnerability credits from Microsoft, Google, and Mozilla. President of the BojosXtu association.

Unbounded TaskInfo serialization in ActivityTaskManagerService

Unbounded TaskInfo serialization in ActivityTaskManagerService leads to persistent-process (SystemUI) crash loop and device-level denial of service

Reporter: Manuel García Peña ("lostmon") — independent security researcher

Contact: lostmon.blogspot.com

Project reference: STA Research (Structured Text Amplification)

Date: 20 September 2026

Component: Android Open Source Project — frameworks/base (ActivityTaskManagerService, Task, TaskOrganizerController, TaskInfo)

Affected versions: Confirmed on Android 16 (device build below); the root cause traces to a serialization path that has been present, in incomplete form, since at least the March 2020 commit referenced in §5 — likely affects a broad range of Android versions. Requires confirmation by Google against the AOSP version matrix.

Test device: Redmi Note 14 5G (citrine_eea_global), build BP2A.250605.031.A3 / HyperOS 3.0 (OS3.0.302.0.WOQEUXM), Android 16.

---

This report is the Nth instance in the STA (Structured Text Amplification) series, a four-year line of research documenting a recurring class of defect in AOSP and adjacent systems: unbounded serialization or amplification of user-influenceable, variable-size fields across a translation boundary, followed by exhaustion of a downstream resource. Prior STA instances in AOSP include STA-015 (RecentTasksController/SystemUI) and STA-015-DL (SystemUI via Google Drive → browser → TaskPersister), both of which share the same root cause family as the present case: an oversized Task-related object crossing Binder into a persistent platform process. The present defect should therefore be read not as an isolated bug in Task.fillTaskInfo(), but as further evidence that AOSP's parcel/serialization model does not impose a default upper bound on attacker-influenceable fields. The remediation in §8 is formulated accordingly: a point fix for TaskInfo, and a structural proposal for frameworks/base.

---

1. Summary

Task.fillTaskInfo() serializes a Task's Intent data Uri and capturedLink field into TaskInfo/RootTaskInfo/RunningTaskInfo/RecentTaskInfo without any upper bound on size. This object is transferred over Binder both when the platform pushes task-organizer callbacks (ITaskOrganizer.onTaskInfoChanged, addStartingWindow) and when a client pulls task state (getFocusedRootTaskInfo, getTasks, getRecentTasks). When the underlying Intent/link data is large enough, the resulting Binder transaction exceeds the transaction buffer and fails with TransactionTooLargeException (push direction) or leaves the caller in a state where subsequent reads fail with DeadObjectException/DeadSystemException (pull direction, once system_server itself becomes unable to service the request).

SystemUI, a platform-critical, persistent process, does not degrade gracefully when these calls fail. The uncaught/unhandled exception propagates up through multiple independent SystemUI components that all query "current focused task" or "recent tasks," causing SystemUI to be killed and restarted repeatedly by ActivityManagerService ("Process com.android.systemui has crashed too many times, killing!"), which in turn triggers the platform's RescueParty self-healing subsystem through an escalating series of mitigations. Depending on how many times the trigger repeats, the outcome ranges from a forced device reboot to an OEM-level "safe mode" recovery requiring manual user intervention.

This is reachable with a single user tap on a link that opens in the default browser — no special permissions, no user interaction beyond a single tap, fully reproducible.

---

2. Affected code paths (AOSP frameworks/base)

Path	Direction	API
services/core/java/com/android/server/wm/TaskOrganizerController.java	Push	ITaskOrganizer.onTaskInfoChanged, addStartingWindow
services/core/java/com/android/server/wm/ActivityTaskManagerService.java	Pull	getFocusedRootTaskInfo
core/java/android/app/ActivityTaskManager.java	Pull	getTasks, getRecentTasks
services/core/java/com/android/server/wm/Task.java	Shared serialization point	fillTaskInfo(), trimIneffectiveInfo()
core/java/android/app/TaskInfo.java	Shared serialization point	writeTaskToParcel(), field capturedLink

All five paths converge on Task.fillTaskInfo(), which is the single point where the defect should be fixed.

---

3. Root cause

3.1 Task.fillTaskInfo() does not bound the Intent data Uri or capturedLink

void fillTaskInfo(TaskInfo info, boolean stripExtras, @Nullable TaskDisplayArea tda) {
    ...
    final Intent baseIntent = getBaseIntent();
    final int baseIntentFlags = baseIntent == null ? 0 : baseIntent.getFlags();
    info.baseIntent = baseIntent == null
            ? new Intent()
            : stripExtras ? baseIntent.cloneFilter() : new Intent(baseIntent);
    info.baseIntent.setFlags(baseIntentFlags);
    ...
    // capturedLink is not cleared or bounded here; it is only nulled in
    // trimIneffectiveInfo() for non-privileged callers.
}

3.2 The 2020 mitigation is incomplete — verified against source

Commit 66b08f0201877e6013058fda2f0263016338c770 ("Reduce parceled data size between system & sysui", Winson Chung, 3 March 2020, Bug: 150242007) changed:

- info.baseIntent = baseIntent == null ? new Intent() : new Intent(baseIntent);
+ info.baseIntent = baseIntent == null ? new Intent() : baseIntent.cloneFilter();

This removes Bundle extras and ClipData from the serialized baseIntent. It does not bound:

• the Intent's data Uri (cloneFilter() explicitly preserves action, data, type, categories, flags, package, component);
• the capturedLink field, which is a separate TaskInfo field entirely untouched by this commit and only cleared in trimIneffectiveInfo() for non-privileged callers — SystemUI and TaskOrganizer receive it unfiltered.

The test added in the same commit, testTaskInfo_expectNoExtras, only asserts that baseIntent.getExtras() is null/empty — it does not assert any bound on data-field length.

3.3 TaskInfo.writeTaskToParcel() has no length limit on variable-size fields

dest.writeTypedObject(baseIntent, 0);       // data Uri, post-cloneFilter, unbounded
dest.writeTypedObject(capturedLink, flags); // full Uri when not trimmed, unbounded

3.3 trimIneffectiveInfo() clears capturedLink only for non-privileged callers

info.capturedLink = null;
info.capturedLinkTimestamp = 0;

This clearing is applied only when the caller is not privileged. SystemUI and TaskOrganizer — precisely the components affected by this defect — are privileged callers and receive capturedLink unfiltered.

3.4 TaskInfo.writeTaskToParcel() has no length limit on variable-size fields

dest.writeTypedObject(baseIntent, 0);       // data Uri, post-cloneFilter, unbounded
dest.writeTypedObject(capturedLink, flags); // full Uri when not trimmed, unbounded

RootTaskInfo adds fixed-size bounds/children fields and then delegates the rest to the same writeTaskToParcel().

3.5 Confluence of push and pull paths

                    ├─ onTaskInfoChanged / addStartingWindow   (push, §5.1)
Task.fillTaskInfo ──┼─ getFocusedRootTaskInfo                  (pull, §5.2, variants A/B)
                    ├─ getTasks                                (pull, §5.2, variant C)
                    └─ getRecentTasks                          (pull, §5.2, variant E)

This explains why five structurally distinct SystemUI call sites (different classes, different threads, different public APIs) all fail with the same root cause: every one of them ultimately calls Task.fillTaskInfo()/writeTaskToParcel() on the same oversized Task object.

3.6 SystemUI does not degrade gracefully on ATMS binder failure

Independently of the above, the Binder client side of this contract — SystemUI's various components that call getFocusedRootTaskInfo/getTasks/getRecentTasks — does not catch DeadObjectException/DeadSystemException and fall back to a last-known-good state or a safe default. The exception propagates and crashes the calling component, and because these components (Dynamic Island top-activity tracking, notification shade token interactor, recents controller) are on SystemUI's main/critical threads, repeated failures cause ActivityManagerService to conclude the persistent process is unrecoverable and kill it outright.

---

4. Reproduction

1. Construct an Intent/link whose data Uri (and/or any field that populates TaskInfo.capturedLink) is large — on the order of hundreds of kilobytes. In our reproduction this was delivered as a link inside an HTML document opened via a cloud-storage viewer, which the OS resolved to the default browser (Firefox, in our test — confirmed not to be the origin of the fault; see §7).
2. The browser is launched as a new Task; system_server/ATMS retains this oversized data as part of the Task's baseIntent/captured-link state.
3. As TaskOrganizerController dispatches pending task-info-changed / starting-window events for this task, and/or as SystemUI's focus/recents observers poll getFocusedRootTaskInfo/getTasks/getRecentTasks, the oversized TaskInfo is serialized to Binder.
4. Observe TransactionTooLargeException (push) and/or DeadObjectException/DeadSystemException (pull) in dumpsys dropbox -p system_app_crash and/or logcat.
5. Repeat exposure (re-opening the link while the browser remains foregrounded) escalates the failure into a sustained SystemUI crash loop.

We can provide the full sequence of bugreports (adb bugreport, 4 captures across 2 dates on the same device/build) documenting both directions with complete stack traces on request through the appropriate secure channel. We are withholding the exact payload construction from this initial report per responsible-disclosure practice; happy to share it privately with the assigned engineer.

---

5. Evidence (redacted stack excerpts)

5.1 Push — TransactionTooLargeException, kernel-confirmed (16-09-2026, 11:26–11:28, same device)

TaskOrganizerController: android.os.TransactionTooLargeException: data parcel size 365036 bytes
    at android.window.ITaskOrganizer$Stub$Proxy.onTaskInfoChanged(ITaskOrganizer.java:513)
    at com.android.server.wm.TaskOrganizerController$TaskOrganizerCallbacks.onTaskInfoChanged(TaskOrganizerController.java:191)
    ...
    at com.android.server.wm.RootWindowContainer.performSurfacePlacementNoTrace(RootWindowContainer.java:923)
    at com.android.server.wm.WindowSurfacePlacer.performSurfacePlacementLoop(WindowSurfacePlacer.java:173)

Kernel binder driver, independently confirming the same failure:

binder: 2124:3180 transaction async to 20444:0 failed 7086360/29201/-28, code 1 size 365788-48 line 3548
binder: 2124:2173 transaction async to 20444:0 failed 7086449/29201/-28, code 7 size 365036-40 line 3548

ActivityManager log line for the same event: pid 2124 system sent binder code 7 with flags 1 to frozen apps and got error -2147483646 — the target process (SystemUI) was in the platform's cached/frozen state at time of delivery, which appears to aggravate the failure.

5.2 Pull — complete evidence set: 25 recorded instances across 3 sessions, 5 distinct call sites

All 25 instances were extracted from dumpsys dropbox -p system_app_crash across three independent bugreports on the same device/build (19–20 September 2026). Every instance shares the same two root exceptions (DeadObjectException or DeadSystemException); they differ only in which SystemUI component happened to be polling task state at the moment system_server/ATMS became unable to service the request.

Frequency by call site:

Variant	Component	API	Instances
C	com.android.systemui.shared.system.ActivityManagerWrapper.getRunningTask (via com.miui.systemui.functions.MiuiTopActivityObserver)	getTasks	12
A	com.android.systemui.statusbar.notification.policy.DynamicIslandTopActivityController	getFocusedRootTaskInfo	5
B	com.miui.systemui.statusbar.shade.domain.interactor.ShadeStatusBarTokenInteractor	getFocusedRootTaskInfo	5
D	com.android.systemui.statusbar.notification.InstantAppNotifier	(stack truncated by system, root cause DeadSystemException)	2
E	com.android.wm.shell.recents.RecentTasksController.getRecentTasks	getRecentTasks	1

Complete timestamped log (25/25 instances, PID and exception type):

2026-09-19 23:32:04  PID 2858   DeadObjectException      Variant A
2026-09-19 23:39:14  PID 21592  DeadSystemException       Variant D
2026-09-19 23:39:28  PID 29332  DeadSystemException       Variant C
2026-09-19 23:39:40  PID 29982  DeadObjectException       Variant B
2026-09-19 23:39:49  PID 30266  DeadSystemException       Variant D
2026-09-19 23:39:56  PID 30579  DeadSystemException       Variant C
2026-09-19 23:42:14  PID 5351   DeadSystemException       Variant C
2026-09-20 00:25:16  PID 2847   DeadSystemException       Variant D
2026-09-20 00:25:24  PID 29311  DeadSystemException       Variant C
2026-09-20 00:25:30  PID 29616  DeadSystemException       Variant C
2026-09-20 00:25:33  PID 29806  DeadSystemException       Variant C
2026-09-20 00:25:39  PID 29952  DeadSystemException       Variant C
2026-09-20 00:25:46  PID 30137  DeadSystemException       Variant C
2026-09-20 14:10:27  PID 2558   DeadObjectException       Variant B
2026-09-20 14:10:44  PID 22995  DeadObjectException       Variant A
2026-09-20 14:10:47  PID 23667  DeadSystemException       Variant C
2026-09-20 14:10:55  PID 24079  DeadSystemException       Variant C
2026-09-20 14:11:09  PID 24700  DeadObjectException       Variant A
2026-09-20 14:11:20  PID 25138  DeadObjectException       Variant B
2026-09-20 14:32:12  PID 26950  DeadObjectException       Variant B
2026-09-20 14:32:28  PID 6263   DeadObjectException       Variant B
2026-09-20 14:32:31  PID 6809   DeadSystemException       Variant C
2026-09-20 14:32:46  PID 6983   DeadObjectException       Variant A
2026-09-20 14:32:52  PID 7317   DeadSystemException       Variant C
2026-09-20 14:33:01  PID 7535   DeadSystemException       Variant E

Entry #25 (14:33:01, RecentTasksController.getRecentTasks) is the last crash of the entire sequence, immediately before the device stabilized — the fault is not limited to "resolve current focus," it extends to enumerating the recent-tasks list in general, which we consider additional evidence that the defect is in the shared Task/TaskInfo state rather than in any single SystemUI component's handling of it.

Full stack — Variant A (DynamicIslandTopActivityController):

android.os.DeadObjectException: Transaction failed on small parcel; remote process
probably died, but this could also be caused by running out of binder buffer space
    at android.os.BinderProxy.transactNative(Native Method)
    at android.os.BinderProxy.transact(BinderProxy.java:736)
    at android.app.IActivityTaskManager$Stub$Proxy.getFocusedRootTaskInfo(IActivityTaskManager.java:3682)
    at com.android.systemui.statusbar.notification.policy.DynamicIslandTopActivityController
        $special$$inlined$mapNotNull$1$2.emit(...)
    at kotlinx.coroutines.flow.SharedFlowImpl.collect$suspendImpl(...)

Full stack — Variant B (ShadeStatusBarTokenInteractor):

android.os.DeadObjectException: Transaction failed on small parcel; remote process
probably died, but this could also be caused by running out of binder buffer space
    at android.os.BinderProxy.transactNative(Native Method)
    at android.os.BinderProxy.transact(BinderProxy.java:736)
    at android.app.IActivityTaskManager$Stub$Proxy.getFocusedRootTaskInfo(IActivityTaskManager.java:3682)
    at com.miui.systemui.statusbar.shade.domain.interactor.ShadeStatusBarTokenInteractor
        $special$$inlined$mapNotNull$1$2.emit(go/retraceme...:62)
    at com.miui.systemui.statusbar.shade.domain.interactor.ShadeStatusBarTokenInteractor
        $special$$inlined$filter$1$2.emit(go/retraceme...:64)
    at kotlinx.coroutines.flow.SharedFlowImpl.collect$suspendImpl(go/retraceme...:194)

Full stack — Variant C (ActivityManagerWrapper.getRunningTask, the most frequent — 12/25):

android.os.DeadSystemRuntimeException: android.os.DeadSystemException
    at android.app.ActivityTaskManager.getTasks(ActivityTaskManager.java:480)
    at android.app.ActivityTaskManager.getTasks(ActivityTaskManager.java:454)
    at com.android.systemui.shared.system.ActivityManagerWrapper.getRunningTask(...:5)
    at com.miui.systemui.functions.MiuiTopActivityObserver$$ExternalSyntheticLambda0.run(...:71)
    at android.os.Handler.handleCallback(Handler.java:1029)
    at android.os.Handler.dispatchMessage(Handler.java:107)
    at android.os.Looper.loopOnce(Looper.java:274)
    at android.os.Looper.loop(Looper.java:369)
    at android.os.HandlerThread.run(HandlerThread.java:85)
Caused by: android.os.DeadSystemException
    ... 9 more

Full stack — Variant D (InstantAppNotifier):

android.os.DeadSystemRuntimeException: android.os.DeadSystemException
    at com.android.systemui.statusbar.notification.InstantAppNotifier$$ExternalSyntheticLambda0.run(...:49)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1100)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:1572)
Caused by: android.os.DeadSystemException
    ... 4 more

Full stack — Variant E (RecentTasksController.getRecentTasks, the final crash of the sequence):

android.os.DeadSystemRuntimeException: android.os.DeadSystemException
    at android.app.ActivityTaskManager.getRecentTasks(ActivityTaskManager.java:539)
    at com.android.wm.shell.recents.RecentTasksController.getRecentTasks(...:10)
    at com.android.wm.shell.recents.RecentTasksController$IRecentTasksImpl$$ExternalSyntheticLambda1.accept(...:11)
    at com.android.wm.shell.common.ExternalInterfaceBinder$$ExternalSyntheticLambda0.run(...:18)
    at com.android.wm.shell.common.ShellExecutor$$ExternalSyntheticLambda0.run(...:5)
    at android.os.Handler.handleCallback(Handler.java:1029)
    at android.os.Handler.dispatchMessage(Handler.java:107)
    at android.os.Looper.loopOnce(Looper.java:274)
    at android.os.Looper.loop(Looper.java:369)
    at android.os.HandlerThread.run(HandlerThread.java:85)
Caused by: android.os.DeadSystemException
    ... 10 more

5.3 Terminating action (ActivityManagerService)

Captured live during the 20-09-2026 14:32 reproduction:

14:32:52.874  ActivityManager: Process com.android.systemui has crashed too many times, killing! Reason: crashed quickly
14:32:52.874  RescueParty: Checking available remediations for health check failure. failedPackage: com.android.systemui failureReason: 3 available impact: 50
14:32:52.884  RescueParty: Executing remediation. failedPackage: com.android.systemui failureReason: 3 mitigationCount: 3

RollbackPackageHealthObserver reports available impact: 0 for the same event — no Mainline/APEX rollback candidate exists for com.android.systemui on this build, so the platform's self-healing falls through entirely to the OEM's own escalation logic (documented in the companion Xiaomi report).

---

6. Impact

• Class: Denial of service, platform-level.
• User interaction: One tap on an attacker-controlled or attacker-influenced link.
• Privileges required: None.
• Effect: Forced lockscreen, sustained SystemUI crash loop, and — depending on repeat exposure — full device reboot or entry into an OEM-defined degraded/safe-mode recovery state requiring the user to manually restart the device. No code execution is claimed.
• Reliability: Deterministic across 25/25 observed crash instances in our testing; consistent across two dates four days apart on the same build.

---

7. Note on browser involvement

We initially suspected the browser itself (Chrome) was implicated, based on a temporally-adjacent ANR in our first capture. On closer inspection of the activity-resume records across all sessions, the browser that actually receives the triggering intent in every case is Firefox (org.mozilla.fenix.IntentReceiverActivity). Firefox shows no crash, ANR, or tombstone of its own in any of the four bugreports we collected — it is the intent receiver, not a party to the defect. We flag this so the assigned engineer does not spend time chasing a red herring; the defect is entirely within the ATMS/SystemUI Binder contract described above.

---

8. Suggested remediation

1. Introduce a length bound on the Intent data Uri and capturedLink in Task.fillTaskInfo() / TaskInfo.writeTaskToParcel() — truncate, hash, or replace with a placeholder above a reasonable threshold before serialization, extending the intent of commit 66b08f0 to cover these two fields.
2. Have TaskOrganizerController measure/cap the serialized size of a TaskInfo before dispatching push callbacks, rather than relying on the caller to catch TransactionTooLargeException after the fact.
3. Harden SystemUI's focus/recents observers (and any similar persistent-process client of these APIs) to catch DeadObjectException/DeadSystemException and fall back to last-known-good state instead of propagating the exception to a crash.

---

9. Attachments available on request

• 4 full bugreport captures (device: Redmi Note 14 5G, build BP2A.250605.031.A3), dated 16-09-2026 and 20-09-2026 (×3).
• Consolidated internal forensic report cross-referencing all four captures against AOSP source.

10. Researcher background

Independent security researcher (handle "lostmon"), President of the BojosXtu association (civic/educational digital-rights work). Blog: lostmon.blogspot.com.