Lostmon Blogger

Microsoft Edge for android Ask Copilot Prompt Injection

2026-10-18T07:11:35.430-07:00

Prompt Injection in Microsoft Edge for Android: Ask Copilot Contextual Selection Vector — LOSTMON-2026-0718

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

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.

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.
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.
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.
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).
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

Microsoft Security Response Center — msrc.microsoft.com
CVE-2026-48561 — Microsoft Copilot Remote Code Execution Vulnerability.
CVE-2026-55145 — Outlook Copilot Tampering Vulnerability.
MITRE ATLAS — Prompt Injection (AML.T0051).
OWASP — Prompt Injection.
CVE-2026-33111 — Copilot Chat (Microsoft Edge) Information Disclosure Vulnerability.
EchoLeak (CVE-2025-32711) — Zero-click Prompt Injection in Microsoft 365 Copilot.
HashJack — Indirect Prompt Injection Attack targeting AI browsers.
Reprompt Attack — Single-click Data Exfiltration from Microsoft Copilot.
FIRST — Common Vulnerability Scoring System v4.0 Specification.
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.

CWE New Weakness Submission

2026-10-11T01:28:41.791-07:00

CWE New Weakness Submission — STA: Structured Text Amplification

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:

Structured input or derived state that lacks an effective security-relevant resource bound.
Propagation of that state across multiple processing layers.
Repeated or independent materialization, transformation, or serialization by downstream components.
Failure to enforce appropriate resource limits at relevant processing and communication boundaries.
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.

Google OSS VRP Pause What It Means for STA Research

2026-10-04T08:13:36.876-07:00

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:

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.
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.
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.

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

2026-09-26T12:35:43.361-07:00

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

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).
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.
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.
Observe TransactionTooLargeException (push) and/or DeadObjectException/DeadSystemException (pull) in dumpsys dropbox -p system_app_crash and/or logcat.
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

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.
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.
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.

De FileAllInformation a inotify: 19 años de metadatos como frontera desatendida

2026-09-24T13:51:33.982-07:00

De FileAllInformation a inotify: 19 años de metadatos como frontera desatendida

Investigación · Seguridad

De `FileAllInformation` a `inotify`: 19 años de metadatos como frontera desatendida

Cómo un desbordamiento de búfer que Microsoft tildó de «no explotable» en 2007 y una fuga de información que la industria llama «by-design» en 2026 son, en realidad, la misma historia contada dos veces.

Análisis técnico CVE-2007-4227 • CVE-2007-5145 • CVE-2025-68788 Lectura ~15 min

Hay fallos que no envejecen: se transforman. Dos investigaciones separadas por casi dos décadas —una de 2007 sobre Windows XP, otra de 2026 sobre Linux, Android, macOS y Windows— apuntan a la misma raíz: los metadatos de archivos son una frontera de seguridad que seguimos tratando como si fuera inocua. Y en ambos casos la respuesta del vendor fue esencialmente la misma: no es un problema.

La historia merece contarse completa. Cuando un proveedor decide que algo «no es explotable», no cierra el debate: solo lo pospone hasta que alguien encuentre el ángulo correcto. Diecinueve años después, ese ángulo apareció, y viene con cifras de precisión del 100% sobre SSH y una nominación a los Pwnie Awards por la peor respuesta de vendor del año.

Parte I — 2007: el desbordamiento que Microsoft minimizó

El descubrimiento

En marzo de 2007, el investigador conocido como Lostmon documentó un desbordamiento de búfer local en el Explorador de Windows. El detonante era engañosamente simple: una cadena demasiado larga en los atributos extendidos de un archivo. Campos como Author, Title, Subject o Comment se procesaban en buffers de tamaño fijo, y al desbordarse provocaban el crash del Explorador —y, con él, la pérdida de todo el trabajo no guardado en cualquier aplicación que estuviera consultando esos atributos.

Lo interesante no era el crash en sí, sino dónde ocurría. El análisis con Filemon (Sysinternals) reveló que el fallo no estaba en la interfaz gráfica ni en un parser de documentos, sino en las tripas del sistema de gestión de archivos:

GetFileAttributesExW / GetFileAttributesW en KERNEL32
NtQueryInformationFile, NtQueryDirectoryFile y NtSetInformationFile en ntdll.dll
Subfunciones FileAllInformation() (clase 0x68) y FileNameInformation() (clase 0x08), entre otras de la tabla FILE_INFORMATION_CLASS

La traza de Filemon era inequívoca:

explorer.exe:1700 IRP_MJ_QUERY_INFORMATION C:\...\explorer_overflow.txt\:SummaryInformation:$DATA
    BUFFER OVERFLOW FileAllInformation

El impacto, en palabras del propio investigador, era de «unknown impact»: un crash confirmado, con potencial desconocido. Lo que sí estaba claro era que el vector no requería abrir el archivo malformado —bastaba con abrir la carpeta, pasar el ratón por encima, o incluso borrarlo desde línea de comandos para que el Explorador cayera.

La reproducción paso a paso

El PoC original es tan sencillo que cualquiera puede reproducirlo en un Windows XP sin parchear:

Crear un archivo explorer.txt.
Clic derecho → Propiedades → pestaña Resumen.
Rellenar todos los campos (Author, Title, Subject, Comment) con una cadena larga de «A».
Aceptar y aplicar.
Con Filemon filtrando por explorer.exe, abrir de nuevo las propiedades o pasar el ratón sobre el archivo.
Observar cómo Filemon registra BUFFER OVERFLOW FileAllInformation.

El equivalente programático es igual de simple. Este script VBScript enumera los atributos extendidos de todos los archivos de una carpeta y hace caer al Windows Scripting Host en cuanto toca el atributo número 9 (Author) del archivo malformado:

Dim arrHeaders(35)
Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace("C:\test")
For i = 0 to 34
    arrHeaders(i) = objFolder.GetDetailsOf(objFolder.Items, i)
Next
For Each strFileName in objFolder.Items
    For i = 0 to 34
        Wscript.Echo i & vbtab & arrHeaders(i) _
            & ": " & objFolder.GetDetailsOf(strFileName, i)
    Next
Next

Este detalle es importante: el fallo no está en el parser de Word ni de Office. Está en la capa común que consulta metadatos, la que cualquier aplicación de Windows usa cuando quiere mostrar información sobre un archivo.

La respuesta de Microsoft

La cronología del reporte fue la siguiente:

12-03-2007Descubrimiento del fallo.
19-03-2007Notificación privada a Microsoft.
22-03-2007Respuesta del vendor.
17-05-2007Divulgación privada a terceros (Secunia, OSVDB, etc.).
04-06-2007Divulgación pública.

La respuesta textual de Microsoft fue:

«We have concluded our investigations on this matter and have found this crash to be un-exploitable. This vulnerability is very similar to another milworm posting (milw0rm.com/exploits/3419). As we have not been able to find an exploitable angle for this issue this crash will get tracking into the next available Service Pack fix.»

Traducción: no vamos a arreglarlo ahora porque no hemos encontrado cómo explotarlo. En términos de gestión de riesgo, eso es exactamente lo contrario de lo que debería hacerse. «No explotable hoy» no significa «inofensivo»; significa «todavía no hemos encontrado el ángulo».

Detalle que el vendor pasó por alto: el fallo no era exclusivo de documentos de Office. Cualquier programa que usara la API de Windows y ole32.dll para abrir archivos —Notepad++, la familia Macromedia/Adobe y muchos otros— crasheaba al listar la carpeta con el archivo malformado, perdiendo todo el trabajo no guardado. El problema era estructural, no puntual.

Parte II — 2007 (bis): el fallo era estructural, no puntual

Meses después del primer aviso, Lostmon publicó un segundo estudio que demostraba que el problema era sistémico. Analizó exploits públicos para múltiples formatos —WMF (BID 16167), JPG (BID 25207), GIF y DOC— y encontró el mismo patrón en todos:

Mismo punto de crash

Todos caían en FileAllInformation() dentro de ntdll.dll.

Mismo atributo

Todos crasheaban en el atributo número 9, Author.

Mismo disparador

Todos se activaban al consultar los atributos extendidos, no al parsear el contenido.

Mismo alcance

El vector no dependía del formato: bastaba con que el archivo tuviera metadatos malformados.

Es decir: el desbordamiento no vivía en los parsers de imagen o documento, sino en la capa común que consulta metadatos. El PoC EFA_test.vbs lo confirmaba de forma elegante: basta con enumerar las propiedades de los archivos de una carpeta vía Shell.Application para que Windows Scripting Host caiga.

La conclusión de 2007 era cristalina y quedó archivada junto al CVE: el problema no era un formato, era la disciplina de tratar los metadatos como datos de confianza.

Diecinueve años después, esa conclusión resuena con una precisión incómoda.

Parte III — 2026: File Notification Attacks

El paper

En noviembre de 2026, en la conferencia ACM CCS de La Haya, el grupo de la Universidad Técnica de Graz (TU Graz) presentó el paper «File Notification Attacks: Templating and Exploiting Side-Channel Leakage from the File-Notification Systems on Linux, Windows, and macOS», firmado por Sudheendra Raghav Neela, Xufan Zhao, Jeanette Angelika Wultsch, Hannes Weissteiner, Florian Draschbacher, Stefan Gast y Daniel Gruss.

La tesis es un eco directo del hallazgo de 2007. Los subsistemas de notificación de cambios —inotify (Linux, 2005), FileObserver (Android, 2008), ReadDirectoryChangesW (Windows, 2000) y FSEvents (macOS, 2007)— informan a las aplicaciones cuando un archivo se abre, cambia, escribe o borra. No revelan el contenido. Pero el nombre, la existencia y el timing de los cambios son un canal lateral explotable.

Y en Linux y Windows, esa información está disponible incluso sin permiso de lectura sobre los archivos vigilados. Eso es lo que convierte una función de conveniencia en una vulnerabilidad de seguridad.

Linux: el caso de `/dev/input`

El vector más demoledor es /dev/input. Vigilar ese directorio genera una notificación en cada pulsación de tecla, porque los ficheros de dispositivo son legibles aunque el observador no tenga permisos sobre ellos. De ahí salen dos ataques devastadores:

93,1–100% Precisión de tecleo local

Inter-keystroke timing local sobre siete usuarios distintos.

100% Precisión sobre SSH

Inter-keystroke timing remoto a través de SSH, sin acceso físico.

87,9% Website fingerprinting

Identificación de sitios visitados sobre el top 100.

Wayland UI redress

Ataque de redress sobre el prompt de autenticación de KDE Plasma 6.

La vulnerabilidad recibió el identificador CVE-2025-68788 y fue parcialmente corregida en diciembre de 2025 en los kernels 5.10.248, 5.15.198, 6.1.160, 6.6.120, 6.12.64 y 6.18.3. El parche impide generar eventos access y modify sobre ficheros especiales en /dev/.

Parcialmente, porque el problema de fondo —el modelo de permisos del observador— sigue ahí. El propio paper reconoce que las mitigaciones necesarias van más allá de este parche concreto.

Android: FileObserver atraviesa FUSE

En Android, FileObserver atraviesa la capa FUSE que debería aislar el almacenamiento por aplicación. El resultado, en palabras de Neela:

«FileObserver goes past the FUSE layer meant to isolate per app storage, so a permissionless app can watch (for example) WhatsApp's private folder and see, by filename and timestamp, exactly when photos, videos, and documents are sent, received, or deleted.»

Es decir: una app sin ningún permiso puede vigilar la carpeta privada de otra app y reconstruir, solo con nombres de archivo y timestamps, la actividad completa del usuario: cuándo envía una foto, cuándo recibe un documento, cuándo borra un vídeo. No hace falta leer el contenido; el patrón de eventos es suficiente.

A pesar de la divulgación responsable entre agosto y octubre de 2025, no hay mitigación implementada en Android a día de hoy.

Windows: vigilar `C:\` lo revela todo

En Windows el panorama es igual de grave. Vigilar el directorio raíz C:\ reporta la ruta completa de cada archivo tocado en el sistema, de todos los usuarios, con independencia de los permisos. Con esa información se puede hacer, en tiempo real, un ataque de fingerprinting web:

97,8% de precisión identificando qué webs visita otro usuario en Firefox, en tiempo real, solo observando qué ficheros de caché se tocan.

La respuesta de Microsoft a la divulgación fue:

«This is by-design and it's an undocumented feature.»

Esa respuesta fue nominada al premio a la peor respuesta de vendor en los Pwnie Awards 2026. El paralelismo con 2007 —donde Microsoft dijo «un-exploitable»— es tan exacto que duele.

macOS: el caso menos grave (pero no inocuo)

Apple sale mejor parada: no se encontraron bypasses para leer directorios privados. Pero FSEvents sí permite monitorizar cambios en ficheros .plist que revelan información sensible sobre el sistema y el usuario:

Cambios en dispositivos de entrada/salida de audio.
Cambios en la configuración de energía.
Actualizaciones de dispositivos Bluetooth e impresoras.
Cambios de DNS iniciados por cable de red.
Eventos de montaje y desmontaje de volúmenes.
Instalaciones y desinstalaciones de aplicaciones.

No es un canal tan directo como el de Linux o Windows, pero sigue siendo una fuga de información sobre la actividad del usuario y del sistema que un atacante local puede explotar para construir un perfil.

El paralelismo incómodo

Puestos uno al lado del otro, los dos hallazgos son la misma historia contada con 19 años de diferencia:

	2007 (CVE-2007-4227 CVE-2007-5145)	2026 (CVE-2025-68788 y familia)
Vector	Metadatos extendidos malformados	Notificaciones de cambios de archivo
Capa afectada	`ntdll.dll`, `FileAllInformation()`	`inotify`, `FSEvents`, `ReadDirectoryChangesW`, `FileObserver`
Fallo de fondo	Overflow al parsear metadatos	Infoleak al notificar metadatos
Asunción errónea	Los metadatos son datos de confianza	Saber que algo cambió es inofensivo
Alcance	Cualquier tipo de archivo con metadatos	Todos los SO modernos
Respuesta del vendor	«un-exploitable»	«by-design, undocumented feature»
Consecuencia	Archivado para el siguiente Service Pack	Nominación a los Pwnie Awards 2026

La lección de diseño es contundente: validar el tamaño al parsear (2007) y validar el permiso del observador al notificar (2026) son la misma disciplina. Ningún subsistema que hable de ficheros debería asumir que los metadatos son públicos.

Y hay una segunda lección, más incómoda: «no explotable» casi nunca significa «inofensivo». Significa «todavía no hemos encontrado el ángulo». En 2007 el ángulo era un crash; en 2026 es un canal lateral con 100% de efectividad sobre SSH. El coste de ignorar el aviso no desaparece: se acumula con intereses.

Qué debería cambiar

Los propios autores del paper plantean las mitigaciones necesarias. Son un buen punto de partida para cualquier equipo que diseñe subsistemas de ficheros, y un recordatorio de que los parches puntuales no sustituyen un cambio de modelo:

Extender las comprobaciones de capacidad a la monitorización de los propios archivos y de cualquier archivo legible — no solo a los ficheros de dispositivo ya parcheados en Linux.
En Windows, prohibir la monitorización de unidades completas. Vigilar C:\ no debería ser una operación sin privilegios.
En Windows y macOS, introducir un sistema de permisos a nivel de kernel que contemple contexto, control de acceso, archivos y directorios propios, y minifilters.
En Android, cerrar la fuga de FileObserver sobre FUSE, que hoy permite a una app sin permisos observar el almacenamiento privado de otra.
Por defecto, no notificar. La seguridad de los metadatos debe ser opt-out, no opt-in.

A esto se podría añadir una sexta, heredada del hallazgo de 2007: validar siempre el tamaño de cualquier cadena que provenga de metadatos antes de copiarla a un buffer de tamaño fijo. Suena elemental, pero es exactamente lo que falló en FileAllInformation() hace diecinueve años, y es la clase de bug que sigue apareciendo en codebases modernas.

Conclusión

Diecinueve años después del primer aviso, el fix no es solo un parche técnico. Es un cambio de mentalidad: dejar de tratar los metadatos como información pública por defecto y empezar a tratarlos como lo que son —una superficie de ataque de pleno derecho, con implicaciones de privacidad y de seguridad medibles.

La curiosidad movió la mente en 2007. En 2026, los datos demuestran que tenía razón. La pregunta incómoda es cuántas veces más vamos a necesitar que alguien encuentre el ángulo explotable antes de que la industria decida que, quizá, los metadatos no eran tan inocuos después de todo.

Nota para equipos de desarrollo: si tu aplicación lee, escribe o notifica sobre metadatos de archivos, revisa dos cosas hoy mismo. Primero, que ningún buffer de tamaño fijo reciba datos que no controlas. Segundo, que los mecanismos de notificación que uses respeten el modelo de permisos del observador, no solo el del archivo observado. Son dos caras del mismo problema, y llevan veinte años sin resolverse.

Fuentes y referencias

Lostmon (2007) — Buffer overflow in extended file attributes in Explorer.exe. Análisis original de CVE-2007-5145, con trazas de Filemon, PoC en VBScript y respuesta de Microsoft. lostmon.blogspot.com/2007/06/buffer-overflow-in-extended-file.html
Lostmon (2007) — Windows Extended file attributes buffer overflow Study II. Generalización del fallo a WMF, JPG, GIF y DOC, con PoCs de CrazyAngel (BID 25207) y Dr.Pantagon. lostmon.blogspot.com/2007/08/windows-extended-file-attributes-buffer.html
Lostmon (2026) — De FileAllInformation a inotify: 19 años de metadatos como frontera desatendida. lostmon.blogspot.com/2026/09/de-fileallinformation-inotify-19-anos.html
Neela, S. R., Zhao, X., Wultsch, J. A., Weissteiner, H., Draschbacher, F., Gast, S., Gruss, D. (2026) — File Notification Attacks: Templating and Exploiting Side-Channel Leakage from the File-Notification Systems on Linux, Windows, and macOS. ACM CCS 2026, La Haya. Resumen en inoti.fyi
The Register (2026) — Decades-old file security flaws found in Android, Linux, macOS, and Windows, por Thomas Claburn. theregister.com/security/2026/09/24/…
CVE-2007-5145 — Windows XP FileAllInformation buffer overflow.
CVE-2025-68788 — Linux kernel file notification access/modify events on /dev/ special files.
Referencias técnicas adicionales — undocumented.ntinternals.net (FILE_INFORMATION_CLASS), Extended file attributes, Sysinternals Filemon.

#Cybersecurity #InfoSec #VulnerabilityResearch #SideChannels #inotify #CVE #Metadata #AppSec #Linux #Windows #Android #macOS #PwnieAwards #ACMSCCS

Three Vectors, One Root Cause — STA-003, STA-017, STA-020

2026-09-10T11:13:53.051-07:00

Chrome 152.0.7977.82 and Edge 152.0.4191.53 remain vulnerable to three distinct Structured Text Amplification (STA) vectors on Android 16. A full forensic bugreport captured on September 6, 2026 confirms the failure chain from oversized Bundle to Binder transaction failure to process termination. The September 2026 Android Security Bulletin contains no patches for the affected paths.

1. Executive Summary

Three STA vectors are confirmed reproducible in the two dominant Chromium-based browsers on Android:

Vector	Trigger	Chrome 152	Edge 2026	Impact
STA-003	Click Share on a crafted link	CRASH	CRASH	Process termination
STA-017	Long-press on a crafted link	ANR	ANR	UI freeze + force finish
STA-020	Focus address bar after crafted URL in history	ANR	ANR	UI freeze + force finish

Architectural root cause: The demonstrated failure paths converge on Android platform components — libminikin.so for text processing and the IActivityTaskManager Binder boundary for oversized transactions. The evidence indicates that browser-level mitigations cannot fully address these platform-level execution paths.

2. Test Environment

Parameter	Value
Device	Xiaomi Redmi Note 14 5G
OS	Android 16, HyperOS 3.0.301.0 (build BP2A.250605.031.A3)
Chrome	152.0.7977.82 (stable)
Edge	152.0.4191.53 (stable)
Bugreport	bugreport-2026-09-06-200012.zip
libminikin.so BuildId	`4fabe53671b5ead88314c00a1fd6d67d`

3. STA-003 — Share Intent Crash

3.1 Trigger

The user clicks Share on a crafted link with an oversized URL. The browser constructs a share Intent carrying the oversized crafted content, which is propagated through the Android activity-start path and ultimately reaches the Binder transaction boundary.

Scope note: In the controlled reproduction, the variable extra content was identified as the crafted STA pattern. The corresponding extra key is redacted in the captured bugreport, so this article does not claim to read the exact extra key from the forensic dump itself.

3.2 Forensic evidence from the bugreport

The Android BaseBundleMonitorImpl (Xiaomi HyperOS) logged the following immediately before the failure:

19:56:56.867  BaseBundleMonitorImpl:
               Large Bundle: length=1531092, bundle=8814309
19:56:56.867  BaseBundleMonitorImpl:
               Large Bundle: length=1532640, bundle=36c790e

Binder then recorded the outgoing transaction and its failure:

Binder transaction failure
id: 12562575
error: -28 (No space left on device)

Large outgoing transaction of 1533260 bytes
interface descriptor: android.app.IActivityTaskManager
code 1

JavaBinder: FAILED BINDER TRANSACTION
parcel size = 1533260

The Java framework then threw the corresponding exception:

android.os.TransactionTooLargeException:
data parcel size 1533260 bytes

  at android.os.BinderProxy.transactNative(Native Method)
  at android.os.BinderProxy.transact(BinderProxy.java:642)
  at android.app.IActivityTaskManager$Stub$Proxy.startActivity(...)
  at android.app.Instrumentation.execStartActivity(...)
  at android.app.Activity.startActivityForResult(...)
  at org.chromium.ui.base.WindowAndroid.R(...)
  ...

Finally, the system terminated the browser process:

wm_finish_activity:
com.microsoft.emmx/org.chromium.chrome.browser.ChromeTabbedActivity, force-crash

am_proc_died:
com.microsoft.emmx

3.3 Chrome confirmation

The same sequence reproduces in Chrome 152 with nearly identical numbers:

TransactionTooLargeException:
data parcel size 1533240 bytes

wm_finish_activity:
com.android.chrome/org.chromium.chrome.browser.ChromeTabbedActivity, force-crash

am_proc_died:
com.android.chrome

Critical observation: Edge failed at 1,533,260 bytes. Chrome failed at 1,533,240 bytes. The difference is 20 bytes. Both browsers reach the same Chromium Activity-start path and both fail at the same Android Binder boundary.

4. STA-017 — Long-Press ANR

4.1 Trigger

The user long-presses a link. The context menu rendering path attempts to measure the anchor text and URL through TextView.onMeasure() → StaticLayout → libhwui → libminikin.so.

4.2 Stack trace (Chrome 152)

"main" prio=5 tid=1 Native   ← UI THREAD BLOCKED
  | state=R

native: minikin::getPrevWordBreakForCache          libminikin.so
native: minikin::StyleRun::getLineMetrics          libminikin.so
native: minikin::MeasuredText::getLineMetrics      libminikin.so
native: minikin::LineBreakOptimizer::computeBreaks libminikin.so
                                                   ← expensive text-processing path
native: minikin::breakLineOptimal                  libminikin.so
native: android::nComputeLineBreaks                libhwui.so

  at android.text.StaticLayout.generate(StaticLayout.java:969)
  at android.widget.TextView.onMeasure(TextView.java:11486)
  at org.chromium.chrome.browser.contextmenu.ContextMenuListView.onMeasure
  at android.view.ViewRootImpl.performTraversals

4.3 System response

ANR in Window ... ChromeTabbedActivity is not responding.
Waited 5000ms for MotionEvent(action=DOWN)

→ Force finishing activity ChromeTabbedActivity
→ Killing process

4.4 Edge confirmation

Edge reproduces the identical path. The ANR subject is:

Input dispatching timed out
(com.microsoft.emmx/...ChromeTabbedActivity is not responding.
 Waited 5000ms for MotionEvent(action=DOWN))

5. STA-020 — Address-Bar Focus ANR

5.1 Trigger

A crafted URL is stored in browser history (e.g. after a previous navigation). The user focuses the address bar. The omnibox suggestion list is rendered through OmniboxSuggestionsContainer.onMeasure() → RecyclerView → TextView.onMeasure() → StaticLayout → libminikin.so.

5.2 Stack trace (Edge 2026-09-06)

"main" prio=5 tid=1 Native
  | state=R

  at android.text.StaticLayout.generate
  at android.text.StaticLayout.
  at android.widget.TextView.onMeasure
  at androidx.appcompat.widget.AppCompatTextView.onMeasure
  at android.widget.LinearLayout.measureVertical
  at org.chromium.chrome.browser.omnibox.suggestions.base.BaseSuggestionView.onMeasure
  at androidx.recyclerview.widget.RecyclerView.onMeasure
  at android.view.ViewRootImpl.performTraversals
  at android.view.Choreographer.doFrame

5.3 System response

ANR in Window ... ChromeTabbedActivity
→ Force finishing activity
→ Killing process

Note: The Edge ANR was captured at 19:40:33 on 2026-09-06 during normal device use — not a synthetic test. It is a spontaneous production capture, which strengthens the reproducibility of the vector.

6. Why Chromium Patches Do Not Fix This

During 2026, Chromium introduced several mitigations for large IPC payloads and oversized text. None of them address the vectors documented above.

Patch	Surface	STA-003	STA-017	STA-020
SelectionUtils / 100 KB	PDF text selection	No	No	No
LargePayloadSupport (FD)	Credential Manager	No	No	No
SharedMemory (Union)	Native Messaging	No	No	No
Oversized Clipboard (ContentProvider)	Clipboard	No	No	No
PdfView anchors	PdfView SavedState	No	No	No
TLE telemetry	Native Messaging	No	No	No

The vulnerable paths are in Android platform components. They are libminikin.so (text processing) and the IActivityTaskManager Binder boundary (oversized transactions). Chromium cannot patch these paths.

7. September 2026 Android Security Bulletin — No Patches for STA

The September 2026 Android Security Bulletin was published on 8 September 2026. A complete search of the bulletin reveals zero references to the surfaces documented in this paper:

Keyword	Results in Bulletin
`libminikin`	0
`Binder`	0
`SavedState`	0
`TransactionTooLarge`	0
`StaticLayout`, `TextView`, `LineBreakOptimizer`	0

The bulletin contains dozens of CVEs across Framework, System, and Kernel — including critical RCEs — but none of them address the STA root causes.

8. The Failure Chain (Recap)

STA payload (crafted URL / oversized structured text)
        ↓
User action (Share / long-press / focus address bar)
        ↓
Chromium builds a share Intent or triggers a TextView measurement call
        ↓
Android platform components:
  · StaticLayout → libhwui → libminikin.so   (STA-017 / STA-020)
  · IActivityTaskManager.startActivity() → Binder   (STA-003)
        ↓
Main thread blocked >5 s OR Binder transaction failure
        ↓
ANR  (STA-017 / STA-020)
or
TransactionTooLargeException → Force finishing activity → Killing  (STA-003)

9. Why This Matters

Three points are worth emphasizing:

Two independent browsers. Chrome 152 and Edge 2026 both reproduce all three vectors. This is not a Chrome-specific defect.
Two independent mechanisms. STA-003 fails at the Binder boundary; STA-017 and STA-020 fail inside libminikin. Both mechanisms share the same architectural root: no early length gate before an expensive or bounded operation.
No upstream mitigation. Neither the Chromium 2026 patches nor the September 2026 Android Security Bulletin address the affected paths.

10. Recommendations

10.1 Framework (AOSP / Android)

Introduce a global length gate in libminikin::LineBreakOptimizer::computeBreaks() and in the measurement/shaping paths (Layout::measureText, LayoutPiece) before entering expensive operations.
Validate the size of an Intent / Bundle before calling IActivityTaskManager.startActivity(), and reject or truncate oversized payloads instead of letting the Binder transaction fail with TransactionTooLargeException.
Instrument the affected paths with telemetry so that oversized payloads are detected before they cause user-visible failures.

10.2 Application-level (defensive)

Truncate URL / share text to a safe maximum (e.g. 50,000 characters) before passing it to the system share sheet.
Truncate suggestion / history text before measuring it in an omnibox or context menu.

These application-level measures reduce the attack surface but do not fix the root cause.

11. Conclusion

Chrome 152.0.7977.82 and Edge 152.0.4191.53 are vulnerable to three STA vectors on Android 16:

STA-003 — Share Intent crash (process termination).
STA-017 — Long-press ANR (main-thread block in libminikin).
STA-020 — Address-bar focus ANR (main-thread block in libminikin).

Forensic evidence from a production bugreport (2026-09-06) confirms the full failure chain from oversized Bundle to Binder transaction failure to process termination. The September 2026 Android Security Bulletin contains no patches for the affected paths.

The evidence indicates that the issue is not confined to a specific browser implementation. Chromium-only mitigations cannot fully address the demonstrated Android text-processing and Binder execution paths. A platform-level fix in AOSP appears necessary.

libminikin The Sixth Entry Point

2026-09-09T08:00:06.848-07:00

The Sixth Entry Point: New Forensic Evidence Confirms STA Remains Unpatched in Android 16

New forensic evidence from a full Android 16 bugreport confirms that Structured Text Amplification

(STA) vectors remain reproducible in Chrome 152 and Edge 2026. A sixth entry point into libminikin has been identified, and the September 2026 Android Security Bulletin contains no patches for the affected paths.

1. Executive Summary

A full Android 16 bugreport (Redmi Note 14 5G, September 6, 2026) provides direct forensic evidence of two distinct failure mechanisms affecting Chromium-based browsers:

Text‑layout ANRs involving libminikin::LineBreakOptimizer::computeBreaks() during long-press and address-bar focus.
Oversized Binder transactions resulting in TransactionTooLargeException and browser process termination via Share / VIEW workflows.

Both Chrome 152.0.7977.82 and Edge 152.0.4191.53 reproduce the same failures on Android 16 (build BP2A.250605.031.A3 / HyperOS 3.0.301.0).

Key finding: A sixth entry point into libminikin has been identified Paint.measureText() → HarfBuzz shaping, reproduced in Google Docs (com.google.android.apps.docs.editors.docs). This is the first documented entry point that enters libminikin through the glyph shaping path rather than line-breaking.

2. The Sixth Entry Point STA-031

The previously documented entry points into libminikin all pass through line‑breaking algorithms (LineBreakOptimizer::computeBreaks, breakLineOptimal, breakLineGreedy). The new evidence reveals a sixth entry point:

android.graphics.Paint.measureText()
        ↓
libhwui (PaintGlue / MinikinUtils)
        ↓
libminikin (Layout::measureText)
        ↓
Layout::doLayoutRunCached
        ↓
Layout::doLayoutWord
        ↓
LayoutCache::getOrCreate<LayoutAppendFunctor>
        ↓
LayoutPiece::LayoutPiece
        ↓
libharfbuzz_ng (hb_shape_full, _hb_ot_shape)
        ↓
hb_font_t::get_glyph_h_origin_with_fallback
        ↓
Main thread blocked → InputDispatcher timeout → ANR

This stack was captured from a production ANR in Google Docs (com.google.android.apps.docs.editors.docs), which was not previously in the catalogue of applications with forensically confirmed libminikin ANRs.

The trigger path passes through AlertDialogLayout.onMeasure, consistent with an oversized structured payload being measured inside a dialog component, the same class of UI surface implicated in other STA vectors.

3. Forensic Evidence STA-003 (Share / Intent Binder Crash)

The bugreport records an ActivityTaskManager transition involving Google Files as the calling package:

19:40:03.713
START u0 {
    act=android.intent.action.VIEW
    dat=content://com.google.android.apps.nbu.files.provider/...
    typ=text/html
    ...
    cmp=com.microsoft.emmx/com.google.android.apps.chrome.IntentDispatcher
}

The Intent is explicitly reported as (has extras). Although the actual extra contents are redacted by the bugreport, in controlled reproduction the variable content supplied through this workflow is the crafted STA pattern.

3.1. Large Bundles

For Edge, the bugreport records:

Large Bundle: length=1531092
Large Bundle: length=1532640

3.2. Binder Transaction Failure

Immediately before the crash:

Binder transaction failure
ID: 12562575
error: -28 (No space left on device)

Large outgoing transaction of 1533260 bytes
interface descriptor: android.app.IActivityTaskManager
code 1

3.3. TransactionTooLargeException

android.os.TransactionTooLargeException:
data parcel size 1533260 bytes

android.app.Instrumentation.execStartActivity
android.app.Activity.startActivityForResult
org.chromium.ui.base.WindowAndroid
android.app.IActivityTaskManager$Stub$Proxy.startActivity
android.os.BinderProxy.transact

3.4. Process Termination

wm_finish_activity:
com.microsoft.emmx/...ChromeTabbedActivity, force-crash

am_proc_died:
com.microsoft.emmx

3.5. Chrome Confirmation

The same phenomenon is reproduced in Chrome:

TransactionTooLargeException:
data parcel size 1533240 bytes

wm_finish_activity:
com.android.chrome/...ChromeTabbedActivity, force-crash

am_proc_died:
com.android.chrome

The two Chromium implementations fail at almost exactly the same serialized transaction size:

Chrome: 1,533,240 bytes
Edge: 1,533,260 bytes
Difference: only 20 bytes

This is particularly significant because both browsers reach the same Chromium Activity-start path and both fail at the Android Binder boundary.

4. STA-017 / STA-020 Text-Layout ANRs

The same bugreport contains multiple ANR reports in which Chrome and Edge enter the Android text-layout stack:

TextView
StaticLayout
LineBreaker
libhwui
libminikin
minikin::LineBreakOptimizer::computeBreaks
breakLineOptimal
android::nComputeLineBreaks

In Chrome, the stack includes:

minikin::getPrevWordBreakForCache
StyleRun::getLineMetrics
MeasuredText::getLineMetrics
LineBreakOptimizer::computeBreaks
breakLineOptimal
android::nComputeLineBreaks
TextView.onMeasure

The ANR reason is an input dispatch timeout:

ChromeTabbedActivity is not responding.
Waited 5000ms for MotionEvent(action=DOWN)

The Activity is subsequently force-finished by the system. This demonstrates that the problem is not specific to a single Chromium implementation. The same Android text-layout subsystem is reached by both browsers.

4.1. STA-020 — Address Bar / Omnibox ANR

A separate reproduction occurs when the crafted URL is present in browser history and the address bar is subsequently focused. The omnibox suggestion rendering path again reaches Android's text measurement and libminikin line-breaking implementation:

OmniboxSuggestionsContainer.onMeasure
RecyclerView.onMeasure
TextView.onMeasure
StaticLayout.generate
libhwui
libminikin
LineBreakOptimizer::computeBreaks

This provides a second independent entry point into the same native text-layout subsystem.

5. Chromium Patches — Not Enough

The Chromium-specific mitigations introduced in 2026 do not address the underlying Android text-processing paths involved in these reproductions.

Patch	Mechanism	Covers STA-003?	Covers STA-017/020?
SelectionUtils / 100 KB	Truncates PDF selection text	❌ No	❌ No
LargePayloadSupport (FD)	File descriptors for large IPC	❌ No	❌ No
SharedMemory (Union)	Redesigns Native Messaging transport	❌ No	❌ No
Oversized Clipboard (ContentProvider)	Redirects large clipboard payloads	❌ No	❌ No
PdfView anchors	Replaces SelectionModel with placeholders	❌ No	❌ No

The root cause is not in Chromium. It is in Android's libminikin.so text layout engine, which lacks a global length gate before entering expensive paths like LineBreakOptimizer::computeBreaks() and Layout::measureText().

6. September 2026 Android Security Bulletin

The September 2026 Android Security Bulletin (published September 8) contains no patches for libminikin, Binder, SavedState, TransactionTooLargeException, or any of the STA vectors documented in this research.

A search of the bulletin reveals zero mentions of:

libminikin
Binder
SavedState
TransactionTooLarge
StaticLayout, TextView, LineBreakOptimizer

This confirms that the architectural gap in libminikin remains publicly unpatched.

7. The Bigger Picture

The evidence now supports the following conclusions:

Finding	Status
Sixth entry point to libminikin (HarfBuzz shaping)	✅ Confirmed (Google Docs)
STA-003 (Share crash) — Edge and Chrome	✅ Reproducible in 2026
STA-017 (Long-press ANR) — Edge and Chrome	✅ Reproducible in 2026
STA-020 (Focus ANR) — Edge and Chrome	✅ Reproducible in 2026
Chromium patches	❌ Do not cover STA-003/017/020
September 2026 bulletin	❌ No patches for libminikin
Xiaomi STA-015b	✅ Patched (no CVE public)

8. Conclusion

New forensic evidence from a full Android 16 bugreport confirms that Structured Text Amplification (STA) vectors remain reproducible in the latest versions of Chromium-based browsers.

A sixth entry point into libminikin has been identified Paint.measureText() → HarfBuzz shaping, reproduced in Google Docs. This demonstrates that the problem is not confined to line-breaking; it also affects glyph shaping and text measurement paths.

Despite multiple Chromium patches in 2026 (LargePayloadSupport, SharedMemory, 100 KB selection limits, etc.), none of them address the underlying Android text-processing paths involved in STA-003, STA-017, and STA-020.

The September 2026 Android Security Bulletin contains no patches for libminikin, Binder, SavedState, or TransactionTooLargeException.

The evidence indicates a platform-level resource-exhaustion gap: Android text-processing entry points do not enforce a sufficiently early global length limit before entering expensive operations such as line breaking, shaping and measurement.

This indicates that the issue is not browser-specific and cannot be fully addressed through Chromium-only patches. A platform-level fix in AOSP appears necessary

Upstream Convergence - STA Patterns in Android and Chromium (2026)

2026-09-05T03:47:59.345-07:00

Upstream Convergence — STA Patterns in Android and Chromium (2026)

This article documents a series of upstream commits in Android, AndroidX, and Chromium during 2026 that implement defensive measures around the same Binder/IPC boundaries identified by the Structured Text Amplification (STA) research. While no commit explicitly references STA, the functional convergence is substantial.

1. The Pattern

The STA model describes a recurring architectural failure: structured input → serialisation → Binder/IPC → uncaught exception → crash or ANR. Over the course of 2026, multiple upstream projects have introduced mitigations that directly address this class of problem.

What follows is a non‑exhaustive but representative list of commits that target exactly the surfaces documented in the STA whitepaper.

2. Upstream Mitigations — A Family of Defences

Component	Commit / Change	Mechanism	Date	STA Relation
AOSP InputMethod	`a438ce172b441c8297eadde8d990ab292f5aa7d1`	Introduces `InputMethodSubtypeSafeList` (and `AbstractSafeList`) to avoid `TransactionTooLargeException` when large lists are passed over Binder.	7 Jan 2026 (merge)	Precedent: changing representation to escape Binder (byte[]/writeBlob)
AndroidX Credential Manager	`393e20ae2c23c509df55058e5d7a3157a749e03b`	Implements `LargePayloadSupport`: serialises Bundle to temporary file, passes `ParcelFileDescriptor` instead of raw data. Triggers for responses >200 KB.	8 Apr 2026	Architectural: large IPC → FD
Chromium PDF Selection	`84b615a07fc14988b46f0e362502ab4075216793`	Refactors and exposes an existing `MAX_SHARE_QUERY_LENGTH = 100000` safeguard (already present in `SelectionPopupControllerImpl`) into `SelectionUtils` for PDF selection (Share / Search / Translate). Note: the CL was reverted ~1.5h later for an Android Lint issue; the underlying 100 KB limit predates this commit.	5 May 2026	Architecturally related to STA-007 (PDF → Select All → Translate). Shows that Chromium treats selection size as a safety property of the Intent boundary.
AndroidX NotificationCompat	`90ffa6a7b02aeefa8f38dc1e54f5740adc18e832`	Fixes a `TransactionTooLargeException` caused by oversized images in compatibility extras. Prevents oversized compat extras from replacing already-resized native extras.	11 May 2026	Architectural: structured extras → Binder → TLE
AndroidX PdfView	`8882927e7d41e678c6f03f50d4bd5950e7dc6c47`	Fixes `TransactionTooLargeException` in `onSaveInstanceState()` by replacing full `SelectionModel` (>1.2 MB) with lightweight anchor points (~44 bytes) when crossing Binder.	14 Jul 2026	Strong architectural convergence: Class A (SavedState / large structured state → Binder → TLE → placeholder → async restoration).
Chromium Oversized Clipboard	`4751a7699c8653c5a944152a4fd78fe97e878885`	Adds support for “pasting oversized HTML payloads” via `ContentProvider` URIs instead of direct transport. Defends against confused deputy attacks.	24 Aug 2026	Architecturally related to STA-011 (Clipboard → assisted paste). Large text/HTML → redirected transport.
Chromium Native Messaging (redesign)	`f5c51669e832d97728da04c79dd426ac2aa49a60`	Changes message representation from `String` to `Union(byte[], SharedMemory)`. Explicitly targets messages that may exceed the 1 MB Binder limit and cause `TransactionTooLargeException`.	26 Aug 2026	Strong architectural convergence: redesigning the transport boundary itself (SharedMemory).
Chromium Native Messaging (telemetry)	`931ee1abb38c9781b5b1470ba64c99afb198ed64`	Adds telemetry for `SentMessageSize` and explicitly distinguishes `TransactionTooLargeException` as a failure mode.	1 Sep 2026	Strong: explicit instrumentation of the same boundary failure.

Note: None of these commits mention STA or the STA whitepaper. They are presented here as convergent engineering — independent mitigations that address the same class of problems documented by the STA research.

3. STA-007: A Clean Upstream Echo

The STA-007 vector describes a chain:

Google Drive → PDF with invisible text → Select All → Translate → TransactionTooLargeException

Chromium’s May 2026 commit (84b615a) does not introduce the 100 KB limit — it reuses and exposes an existing safeguard already present in SelectionPopupControllerImpl. The commit message explicitly references Android Intent size limits (~1 MB) as the reason for the limit.

This is not proof that Chromium acted on STA-007. But the functional alignment is so precise that an engineer reading both documents would immediately recognise the same boundary. The key observation is that Chromium was already treating selection text size as a safety property of the Intent boundary, before the STA research was published.

4. The Asymmetry: libminikin Remains Unaddressed

While multiple upstream projects have implemented defences around Binder/IPC boundaries, no equivalent global length gate has been found in libminikin for the line‑breaking path documented in STA‑017.

getPrevWordBreakForCache() still performs backwards scans without a hard input‑length guard.
The investigated optimal line-breaking path (LineBreakOptimizer::computeBreaks()) retains nested candidate-processing loops, but no public global input-length gate comparable to the IPC safeguards above was identified.
Only a specific hyphenation safeguard exists (words longer than 45 characters), which does not cover the general case.

Key observation: A concentrated set of mitigations is visible around serialisation, clipboard, IPC, and persistence boundaries — while the text‑layout path (libminikin) has not received the same treatment.

4.1 Why libminikin Might Be Different

Unlike Binder/IPC boundaries, which have clear size limits (1 MB) and can be instrumented or redirected, libminikin is a native layout engine with deep roots in Android’s text rendering pipeline. A hard global length gate in computeBreaks() would affect all text rendering — not just URLs or structured payloads — making it a more complex change to validate without breaking existing applications.

This does not excuse the absence of a defence, but it helps explain why the asymmetry exists.

5. Temporal Context

The commits listed above span from November 2025 to September 2026. The STA whitepaper was published on 30 July 2026.

This timeline reveals two distinct waves:

Before July 2026: SafeList, LargePayloadSupport, NotificationCompat, and the PDF selection refactor all predate the STA whitepaper. They show that upstream projects were already treating oversized structured payloads as a reliability/security concern.
After July 2026: Oversized clipboard (24 Aug), SharedMemory redesign (26 Aug), and TLE telemetry (1 Sep) occur after the STA research became public. They address surfaces that the STA whitepaper explicitly documented.

This distribution makes the hypothesis “all these changes are a reaction to STA” unsustainable. But it also makes a different claim stronger:

“STA was published during a period when upstream was already moving toward explicit size controls, alternative representation, and payload isolation at Binder boundaries. After publication, that trend continued and added changes to surfaces specifically documented by STA.”

6. Summary: Mitigated vs. Unmitigated Surfaces

Surface	Mitigation Visible?	Mechanism
InputMethod → Binder (large lists)	✅ Yes	SafeList → byte[]/writeBlob
Large IPC (Credential Manager)	✅ Yes	LargePayloadSupport (FD)
PDF → Share / Search / Translate	✅ Yes	Truncation (100 KB limit, refactored into SelectionUtils)
NotificationCompat (oversized images)	✅ Yes	Prevents oversized compat extras from replacing native ones
SavedState (PdfView)	✅ Yes	Anchor points (~44 bytes) + async restoration
Oversized Clipboard	✅ Yes	ContentProvider URI
Native Messaging	✅ Yes	SharedMemory + telemetry
libminikin (LineBreakOptimizer)	❌ Not found	No global length gate in the investigated path

7. What This Convergence Means

The upstream commits listed above represent a family of defensive engineering decisions, all targeting the same underlying problem:

Large structured payload → Binder/IPC → TransactionTooLargeException → Crash or ANR

The mitigations vary by component, but they follow a consistent pattern:

Constrain: limit input size before it reaches the boundary (Chromium PDF selection).
Redirect: move payload out of Binder (LargePayloadSupport → FD; Oversized Clipboard → ContentProvider).
Replace: replace full state with lightweight placeholders (PdfView → anchor points).
Observe: instrument the failure to understand its prevalence (Native Messaging telemetry).

The strongest evidence is not that individual fixes resemble individual STA vectors. It is that multiple upstream projects independently apply the same defensive principle: constrain, redirect, replace, or observe data before an oversized structured payload becomes a failure at an IPC boundary.

8. Conclusion

The STA model identified an architectural pattern: structured input that crosses Binder/IPC boundaries without size validation can cause persistent crashes and ANRs. The upstream commits documented in this article show that:

Multiple components (AndroidX, AOSP, Chromium) have introduced mitigations at exactly those boundaries.
The timing (2026) and the mechanisms (constrain, redirect, replace, observe) align with the surfaces described in the STA whitepaper.
No causal link is claimed — but the functional convergence is substantial and observable.
libminikin remains an outlier, with no visible global length gate for the investigated line‑breaking path.

Whether this convergence is coincidental or a response to the STA research is not something this article can determine. What is clear is that the industry is moving toward defensive patterns that match the STA diagnosis — and that the asymmetry with libminikin persists.

STA The Print Preview Vector

2026-09-04T10:49:46.216-07:00

STA The Print Preview Vector: Document Amplification Through Android Print Service

STA — The Print Preview Vector

This article documents the Print Preview amplification chain in Android — a Class A (IPC/SavedState) vector where oversized document previews exceed the Binder transaction limit, causing crashes in the Print Service, SystemUI, and, in the most severe cases, persistent crash loops requiring a hard reboot.

1. Overview

The Print Preview vector is a Class A amplification chain that begins when a user selects the Print or Print Preview option from an application — particularly Google Drive, PDF viewers, or document editors. The system constructs a preview Bundle containing page data, text, and metadata, and attempts to send it across the Binder IPC boundary to the Print Service, Print Spooler, or SystemUI.

Because no size validation is performed before serialization, a sufficiently large document (e.g., a complex DOCX, a high-resolution PDF, or a long text document) can produce a Bundle that exceeds the 1,048,576-byte Binder limit. When this happens, a TransactionTooLargeException is thrown — and in many cases, it remains uncaught. The result is a crash of the Print Service, the calling application, or SystemUI itself.

In the most severe scenarios, the crash corrupts the TaskPersister state on disk, causing a persistent crash loop that survives reboots and requires manual data clearance.

The full amplification chain is as follows:

Large document (Google Drive, PDF, DOCX)
        ↓
User selects "Print" or "Print Preview"
        ↓
Print Service builds a preview Bundle
        ↓
Bundle serialized → Parcel → Binder
        ↓
Exceeds 1 MB limit → TransactionTooLargeException
        ↓
Uncaught exception → Crash (app, Print Service, or SystemUI)
        ↓
If state is persisted (SavedState / TaskPersister) → Crash loop

Key observation: This vector is structurally identical to the WhatsApp ×20.6 amplification (STA-005) and the Threads deep-link crash (STA-012). In all cases, a structured payload crosses a Binder-backed boundary without a length check, and the resulting exception propagates uncaught.

2. Documented Vectors

The Print Preview amplification manifests in at least four distinct but related vectors, each affecting a different layer of the Android stack:

ID	Component	Mechanism	CVSS	Persistence	Tier
STA-009	Google Drive → Print Preview	Opening the print preview of a large DOCX/PDF generates a Bundle that exceeds the Binder limit, crashing the app.	6.5	Yes (until reboot)	A
STA-010	Print Service → local printer	The same oversized Bundle is sent to the local print service (SystemUI), causing SystemUI to crash.	7.2	Yes (until reboot)	A
STA-010b	Google Play Services → cloud printer	Variant of STA-010 routed through Google Play Services.	6.5	Yes (until app closed)	A
STA-018	Google Drive + Print Service + SystemUI	Full chain: ANR in browser → TaskPersister corruption → SystemUI crash loop. Hard reboot required.	7.5	Yes (until reboot)	A

All four vectors have been reproduced on Android 13–16 across multiple OEMs (Xiaomi, Samsung, OPPO, OnePlus, Pixel) and are classified as Tier A (full stack trace + exception + Bundle analysis).

3. Technical Evidence

3.1. SystemUI Crash During Print Preview

Bugreports captured on a Xiaomi Redmi Note 14 5G (HyperOS 3.0 / Android 16) show SystemUI crashing when a print preview is opened for a large document. The following stack trace was extracted from a production bugreport:

// SystemUI crash during Print Preview
android.os.TransactionTooLargeException: data parcel size 1,456,832 bytes
  at android.os.BinderProxy.transactNative(Native Method)
  at android.os.BinderProxy.transact(BinderProxy.java:642)
  at android.print.IPrintManager$Stub$Proxy.print(IPrintManager.java:456)
  at android.print.PrintManager.print(PrintManager.java:789)
  at com.google.android.apps.docs.print.PrintPreviewActivity.onCreate(...)
  at android.app.ActivityThread.performLaunchActivity(...)
  at android.app.ActivityThread.handleLaunchActivity(...)
  at android.app.servertransaction.LaunchActivityItem.execute(...)

Analysis: The Print Manager attempts to send the preview Bundle across Binder, but its size (1,456,832 bytes) exceeds the 1,048,576-byte limit. The resulting TransactionTooLargeException is not caught, and SystemUI crashes. The crash occurs before the user can interact with the print dialog, making it a reliable denial-of-service vector.

3.2. TaskPersister Corruption (STA-018)

In more severe cases — particularly on devices with OEM customisations (Xiaomi HyperOS) — the SystemUI crash corrupts the TaskPersister state on disk. Upon restart, SystemUI reads the corrupt state and crashes again, entering a persistent crash loop that requires a full device reboot or manual data clearance.

// TaskPersister corruption after Print Preview crash
E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.android.systemui, PID: 1234
    android.os.BadParcelableException: Failure retrieving array; only received 1 of 4
        at android.content.pm.BaseParceledListSlice.<init>(...)
        at android.window.ITaskOrganizerController$Stub$Proxy.registerTaskOrganizer(...)
        at android.window.TaskOrganizer.registerOrganizer(TaskOrganizer.java:76)
        at com.android.wm.shell.sysui.ShellInit.init(...)
    Caused by: android.os.DeadObjectException: Transaction failed on small parcel

This demonstrates that the Print Preview vector can escalate beyond a transient crash and become a persistent denial-of-service condition that affects the entire device UI.

3.3. Bundle Size Amplification

As with other Class A vectors, the amplification factor depends on the structure of the document and the nesting depth of the Fragment hierarchy. In the case of Google Drive's print preview, a document of approximately 80–100 KB can generate a Bundle of 1.2–1.5 MB, exceeding the Binder limit by 20–50%.

This amplification is consistent with the pattern observed in WhatsApp (×20.6) and TikTok (×286), where nested FragmentManager state multiplies the original payload size at each level.

4. Connection to AndroidX PdfView Commit

On 14 July 2026, a commit was merged into AndroidX (8882927e7d41e678c6f03f50d4bd5950e7dc6c47) that fixes a TransactionTooLargeException in PdfView. The commit message states:

“When a user selects content across a large range of pages (e.g., 500 pages), the serialized SelectionModel exceeds 1.2 MB. Serializing this into onSaveInstanceState triggers an unhandled TransactionTooLargeException over the kernel Binder IPC driver right when the app goes into the background.”

The fix was to change the persistent representation: rather than serialising the full SelectionModel, only anchor points (~44 bytes) are saved, and the full state is reconstructed asynchronously upon restoration.

Note: This commit is independent of the STA research, but it confirms that Google is actively mitigating the same general class of oversized‑state / Binder‑boundary problems in components related to document handling and print preview.

However, the commit is scoped to androidx.pdf.viewer.PdfView only. It does not address the Print Service, SystemUI, or TaskPersister paths documented in STA-009, STA-010, and STA-018. As of September 2026, those paths remain publicly unpatched.

5. Relation to Other STA Vectors

Vector	Connection
STA-015-DL	Similar chain (Google Drive HTML → browser ANR → SystemUI crash loop), but triggered via a web link rather than the print UI. Both share the TaskPersister corruption mechanism.
STA-005	Class A amplification through FragmentManager / SavedState, but in the context of messaging apps (WhatsApp) rather than printing. The underlying cause — oversized Bundle → Binder → uncaught exception — is identical.
STA-012	Threads deep-link crash. Also Class A, also involves a structured payload crossing Binder without validation.
STA-017	Class B (libminikin ANR) — unrelated to printing, but shares the same root‑cause pattern: missing size validation before an expensive operation (text layout in libminikin; Binder serialisation in Print Service).

The Print Preview vectors are a clear demonstration that the STA pattern is not confined to a single application or component. It recurs across document handling, messaging, and system UI — all tied to the same underlying architectural gap: structured input → serialization → Binder → uncaught exception → crash.

6. Mitigation Recommendations

6.1. Framework (AOSP / AndroidX)

Validate Bundle size before serialization in PrintManager and PrintService — reject or truncate if the 1 MB limit is approached.
Catch TransactionTooLargeException in both the Print Service and SystemUI, and degrade gracefully (show an error message instead of crashing).
Adopt LargePayloadSupport (FD‑based transfer) for print previews, similar to what already exists for Credential Manager and Digital Credentials.
Prevent TaskPersister corruption by validating restored state size before persisting it to disk.

6.2. Application-level (Google Drive, document viewers)

Truncate document content before passing it to the Print Service — limit the number of pages, reduce preview resolution, or cap text length to 50,000 characters.
Reject print intents that contain oversized documents (e.g., by checking the document size before calling PrintManager.print()).

6.3. OEM-specific (HyperOS, One UI, ColorOS)

OEMs should apply safe degradation patterns in their Task State Interactors, similar to the pattern proposed in Section 16.4 of the STA whitepaper (catch DeadObjectException and emit null instead of crashing).

7. Conclusion

The Print Preview vector is a clear and well-documented manifestation of Class A Structured Text Amplification in a system‑level service (Print Service / SystemUI). It demonstrates that the same architectural pattern — structured input → serialization → Binder → uncaught exception → crash — recurs across multiple surfaces, from messaging apps to document handling to system UI.

The independent AndroidX fix for PdfView confirms that Google is aware of this class of problems, but the Print Service and SystemUI paths remain unpatched as of September 2026. Organisations relying on Android for document workflows should consider implementing defensive truncation at the application level.

This vector also reinforces the broader STA thesis: the problem is not a single bug, but a systemic architectural gap that requires a coordinated, cross‑component response from the Android framework.

8. Related Publications

📚 Articles in the STA research series (Lostmon.blogspot.com):

El dilema de la divulgación coordinada (31 Aug 2026) — A reflection on the asymmetry in responsible disclosure.
STA-012 — Threads: When a deep link becomes a persistent crash loop (26 Aug 2026).
STA-006/007 — Translate: When translating text freezes the UI (27 Aug 2026).
STA — Structured Text Amplification in Gemini (23 Aug 2026).
STA-003 — When sharing an oversized link crashes the browser (21 Aug 2026).
CDN Tsunami and STA — Same amplification pattern, different domain (20 Aug 2026).
Upstream Android and Chromium changes in 2026 — A correlation with STA (14 Aug 2026).
STA — UTF-16 Serialization Density Experiment (14 Aug 2026).
STA-001 — When an oversized link reaches the context menu (15 Aug 2026).
Resilience Gaps in Android IPC, SavedState and Text Layout (30 Jul 2026) — The complete STA whitepaper.
Desafiar Android desde el sofá y un smartphone (17 Jul 2026) — Personal narrative of the investigation.
Timeline de la investigación STA (12 Jul 2026).
libminikin: 10 años de vulnerabilidad en el núcleo de Android (10 Jul 2026).
Algorithmic DoS en libminikin.so (24 Jun 2026).
Structured Text Amplification (STA) — Marco conceptual (23 Jun 2026).

No somos silencio

2026-09-01T13:56:52.806-07:00

No somos silencio Manifiesto

No somos silencio

Dedicado a quienes han convertido su voz en resistencia.

Y a quienes, desde un sofá, han visto más lejos, más allá.

Hay historias que se esconden detrás de una habitación, palabras que nadie escucha, silencios llenos de voz. Nos dijeron "no hagas ruido", "mejor no lo cuentes más", pero el miedo no es destino y callar no es libertad.

No somos una etiqueta, ni un diagnóstico al hablar, somos vidas, somos nombres, somos ganas de cambiar.

Que se escuche nuestra voz, que se rompa el silencio, que contar lo que vivimos no nos haga tener miedo. Tenemos derecho a hablar, a luchar, a decidir, salud mental es también tener voz y existir.

Hay miradas que no ven lo que ocurre en nuestro interior, puertas que permanecen cerradas, trámites sin comprensión. Pero aprendimos caminando que unidos somos más fuertes, que defender nuestros derechos también cambia nuestras suertes.

No queremos compasión, queremos participación, que nos miren de frente y que escuchen nuestra razón.

Y si uno cae, levantamos, si uno grita, respondemos, si una historia queda oculta, entre todos la contaremos. No somos invisibles, aunque quieran no mirar. Somos parte de esta historia y la vamos a cambiar.

Que se escuche nuestra voz, que se escuche hasta el final, que nadie decida nunca si tenemos que callar. Tenemos derecho a hablar, a luchar, a decidir. Salud mental es dignidad, es tener voz, es resistir.

No somos silencio.
No somos invisibles.
Estamos aquí.
Y tenemos algo que contar.

📖 Sobre este texto

Este manifiesto nació al final de un viaje de investigación sobre Structured Text Amplification (STA), un patrón arquitectónico que documenta cómo el texto estructurado puede amplificar el coste computacional hasta causar bloqueos en Android y Gemini.

Pero esta investigación fue también un viaje personal. Un recordatorio de que la salud mental, la dignidad y la voz son tan importantes como cualquier vulnerabilidad.

Dedicado a quienes han convertido su voz en resistencia.
Y a quienes, desde un sofá, han visto más lejos, más allá.

— Manuel García Peña (Lostmon)
Investigador independiente · Activista por la salud mental

El dilema de la divulgación coordinada

2026-08-31T15:16:27.568-07:00

Cuando la responsabilidad es unilateral: el dilema de la divulgación coordinada

Una reflexión sobre el modelo actual de seguridad, sus asimetrías y sus consecuencias

Imagina la siguiente situación:

Has pasado semanas, quizás meses, investigando un comportamiento extraño en un sistema ampliamente utilizado. Has reproducido el problema en diferentes dispositivos. Has capturado logs, stacktraces, métricas de sistema. Has documentado cada paso con precisión. Has preparado un informe que cualquier ingeniero podría seguir para verificar el problema por sí mismo.

Envías el reporte al fabricante. Esperas. Recibes una respuesta automática. Semanas después, alguien te pide más información. La proporcionas. Vuelves a esperar.

Finalmente, recibes una respuesta:

“Hemos revisado tu informe y determinado que no cumple con los criterios para ser considerado un bug de seguridad.”

“Este problema pertenece a otro equipo.”

“Está fuera del alcance de nuestro programa de recompensas.”

“Por favor, utiliza el feedback in-product para reportarlo.”

El problema sigue existiendo. Los usuarios siguen expuestos. Pero la responsabilidad ha quedado diluida en un laberinto de equipos, programas y criterios.

Esta historia es más común de lo que muchos creen. Y revela una asimetría estructural en el modelo de divulgación coordinada que merece un análisis profundo.

Este artículo no trata sobre una vulnerabilidad concreta. Trata sobre el sistema que la gestiona o, más precisamente, sobre el sistema que a menudo no la gestiona.

1. El contrato implícito de la divulgación responsable

La divulgación responsable, también llamada coordinada, se ha establecido como el estándar ético en la seguridad informática. Su premisa es sencilla y, en apariencia, incuestionable:

“Si conocemos un problema que puede afectar a otros, debemos dar al fabricante la oportunidad de solucionarlo antes de hacerlo público.”

Esta lógica protege a los usuarios. Permite que las empresas corrijan vulnerabilidades sin exponer a sus clientes a ataques mientras el parche está en desarrollo. Es un modelo que, en teoría, beneficia a todas las partes.

En la práctica, el investigador acepta un conjunto de obligaciones que incluyen:

Reproducir el problema de forma fiable y documentada.
Proporcionar evidencia técnica suficiente (logs, trazas, código, pasos).
Evitar divulgar prematuramente para no poner en riesgo a los usuarios.
Informar al fabricante a través de los canales establecidos.
Facilitar la investigación con información adicional cuando se solicita.
Respetar los plazos de coordinación que la empresa propone.
Permitir que el proveedor prepare una solución antes de la publicación.
Documentar sus conclusiones de forma responsable y precisa.

Y, en muchos casos, el investigador hace todo esto sin ninguna garantía de reconocimiento, parche o recompensa. Lo hace porque cree en el modelo. Porque entiende que la seguridad es una responsabilidad compartida.

La lógica es impecable. Pero esa misma lógica debería funcionar en ambas direcciones.

2. El problema aparece cuando nadie es responsable y a la vez, lo son todas las partes inplicadas

Durante una investigación pueden aparecer problemas que atraviesan diferentes capas de un sistema. Un mismo comportamiento puede involucrar:

Aplicación (el software que el usuario ve)
Framework (la capa intermedia que soporta la aplicación)
Biblioteca nativa (código de bajo nivel, a menudo en C/C++)
Sistema operativo (el núcleo del sistema)
Fabricante / OEM (personalizaciones del sistema)

Y también:

Producto A (ej. Chrome, Firefox, Edge)
Producto B (ej. Android)
Componente compartido (ej. libminikin)
Infraestructura común (ej. Binder, IPC)
Servicio en la nube (ej. Llm's API)

Entonces aparece el fenómeno conocido por muchos investigadores:

“No es nuestro problema.”

Un equipo o vendor, puede indicar: “Esto es un problema de Android.”
Android puede responder: “No está dentro del alcance de nuestro programa.”
Otro equipo puede añadir: “Debe reportarse al producto correspondiente.”

Y el investigador vuelve al punto de partida.

El atacante no necesita saber qué equipo es responsable. El investigador tampoco debería tener que resolver el organigrama interno de una multinacional para encontrar al responsable. Si el problema atraviesa capas, el atacante ve un sistema. El investigador ve un sistema. La organización, sin embargo, puede verlo como tres equipos o más distintos.

3. El caso STA: una investigación transversal

Mi investigación sobre Structured Text Amplification (STA) comenzó en 2022, estudiando comportamientos relacionados con texto estructurado y agotamiento de recursos en Android. Lo que parecía un problema aislado en una biblioteca fue revelando un patrón más amplio.

Con el tiempo, aparecieron diferentes manifestaciones en distintos componentes:

Componente	Síntoma	Mecanismo
libminikin.so	ANR, bloqueo del hilo principal	Knuth-Plass O(n²)
Binder / SavedState	TransactionTooLargeException, crash loops	Serialización O(n²)
Llm's (modelo)	Instruction Drift, generación de contenido sin contexto	Atención O(n²)
Llm's (cliente)	ANR, UI freeze	libminikin O(n²)
Navegadores	Bloqueo de renderizado	Algoritmos de layout O(n²)

Lo interesante no era cada fallo individual, sino la posibilidad de que existiera un patrón común:

Entrada estructurada (texto repetitivo, baja entropía)
              ↓
    Transformación (tokenización, layout, serialización)
              ↓
    Amplificación del coste (algoritmo O(n²))
              ↓
    Agotamiento de recursos (CPU, memoria, tiempo)
              ↓
    Pérdida de disponibilidad (ANR, crash, DoS)

Este patrón aparecía en el cliente Android (la apps de Google, Mozilla, Meta, Microsoft, Xiaomi, entre otros). Aparecía en el sistema operativo (libminikin, Binder). Y, más tarde, apareció también en los Llm's, tanto en el modelo (pérdida de contexto) como en el cliente (ANR al renderizar respuestas largas o tareas simples como contar caracteres ).

El problema era real, reproducible y estaba documentado con stacktraces, métricas de sistema y pasos concretos. Pero al intentar reportarlo siguiendo los cauces establecidos, ocurrió lo que muchos investigadores han vivido:

VRP's: “Fuera de alcance.”
llm's VRP: “Bypass de guardrail de seguridad. Fuera de alcance.”
Feedback in-product: Canal adecuado, pero sin garantía de respuesta o mitigación.

El patrón STA existía. Las evidencias eran sólidas. Pero la responsabilidad quedaba diluida entre equipos, programas y criterios.

4. La anatomía de una derivación

Para entender el problema, es útil analizar qué ocurre cuando un reporte atraviesa el sistema de gestión de vulnerabilidades de una gran organización.

Fase 1: Recepción
El investigador envía un informe detallado. Recibe un acuse de recibo automático. El reporte entra en una cola de triaje.

Fase 2: Triaje inicial
Un revisor, a menudo con poco tiempo y muchos reportes, clasifica el problema. Si encaja en un patrón conocido, puede ser asignado a un equipo. Si no, puede ser rechazado por “falta de información” o “no reproducible”.

Fase 3: Análisis técnico
El equipo asignado analiza el problema. Si el equipo es el correcto, la investigación avanza. Si el problema cruza fronteras, aparece la pregunta: “¿Es realmente nuestro?”

Fase 4: Derivación
El problema se traslada a otro equipo. Ese equipo, a su vez, puede derivarlo a otro. Cada derivación reinicia parcialmente el proceso. Cada equipo aplica sus propios criterios.

Fase 5: Decisión final
En algún punto, el problema es clasificado como “fuera de alcance”, “no elegible para recompensa” o “no reproducible”. El investigador recibe una respuesta. El problema sigue existiendo.

Lo paradójico es que cada decisión individual puede ser razonable. Cada equipo puede tener argumentos válidos para no asumir la responsabilidad. Pero el resultado final es que el problema no se soluciona.

Y el investigador, que empezó con la intención de ayudar, se encuentra con un muro de silencio.

5. “Out of scope” no significa “el problema no existe”

Hay una confusión conceptual que conviene aclarar.

Un programa de recompensas puede establecer legítimamente qué tipos de problemas son elegibles para recompensa. Esa es una decisión de alcance. Es razonable que una empresa defina los límites de su programa.

Pero:

No elegible para recompensa ≠ inexistente.

Un problema puede quedar fuera de un VRP y seguir siendo:

Reproducible.
Técnicamente relevante.
Peligroso para determinados usuarios.
Digno de una mitigación.
Digno de una investigación interna.
Digno de ser documentado públicamente.

Esta distinción es fundamental. Un programa de recompensas puede rechazar un reporte por alcance, pero eso no significa que el equipo de producto deba ignorarlo.

El problema ocurre cuando “fuera de alcance” se convierte en un sinónimo de “no es responsabilidad nuestra” y cuando esa falta de responsabilidad impide que el problema se solucione.

6. El coste de la investigación independiente

Para entender la asimetría, hay que considerar los recursos de cada parte.

Una gran organización puede disponer de:

Equipos especializados en diferentes áreas.
Acceso al código fuente completo.
Infraestructura de reproducción a gran escala.
Telemetría para identificar la prevalencia del problema.
Ingenieros dedicados a tiempo completo.
Herramientas internas de análisis y depuración.
Capacidad para parchear millones de dispositivos en días o semanas.
Departamento legal para gestionar riesgos.
Presupuesto para recompensas y reconocimiento.

El investigador independiente, en cambio, puede disponer de:

Un ordenador (a menudo personal).
Un teléfono (a menudo personal).
Unos bugreport (obtenidos con esfuerzo).
Una conexión a Internet.
Y muchas horas de trabajo no remunerado.

En mi caso, buena parte de esta investigación se ha realizado desde un entorno doméstico. No hay un laboratorio detrás, ni un departamento legal, ni un equipo de ingeniería esperando para validar cada hipótesis. La validación de las evidencias recae enteramente en el investigador.

Y, sin embargo, el investigador debe proporcionar evidencia suficientemente sólida para que una organización pueda tomar una decisión. La exigencia es legítima. La reciprocidad debería serlo también.

7. Cuando la evidencia contradice la respuesta inicial

Una de las situaciones más reveladoras ocurre cuando la primera conclusión de la organización es:

“No reproducible.”

Pero posteriormente aparecen:

Nuevos dispositivos donde el problema se manifiesta.
Nuevos dumps con stacktraces adicionales.
Nuevos ANR traces en el mismo componente.
Nuevas aplicaciones afectadas por el mismo patrón.
Nuevas reproducciones que confirman la hipótesis.
Evidencia del mismo componente en diferentes contextos.
Comportamiento consistente entre productos.

Entonces la pregunta ya no debería ser:

“¿Por qué el investigador insiste?”

La pregunta debería ser:

“¿Qué hemos aprendido desde la primera evaluación?”

La seguridad no debería funcionar como un juicio que termina con la primera decisión. Debería funcionar como un proceso iterativo:

Hipótesis inicial
        ↓
Evidencia recopilada
        ↓
Reproducción en condiciones controladas
        ↓
Análisis técnico
        ↓
Nueva evidencia (más dispositivos, más contextos)
        ↓
Reevaluación de la hipótesis
        ↓
Actualización de la decisión

Este ciclo es común en la investigación científica. En la seguridad, sin embargo, tiende a ser lineal: una decisión inicial, sin espacio para la reevaluación.

8. La paradoja de la coordinación

Cuando una organización solicita coordinación, el mensaje es claro:

“Danos tiempo para investigar y solucionar el problema.”

El investigador acepta. Pero la coordinación implica una segunda obligación: utilizar ese tiempo de forma efectiva.

La coordinación no debería significar:

Investigador
    ↓
Reporte (con evidencia)
    ↓
Espera (semanas o meses)
    ↓
"No reproducible"
    ↓
Investigador aporta más evidencia
    ↓
Espera
    ↓
"Out of scope"
    ↓
Investigador apela
    ↓
Espera
    ↓
"Pertenece a otro equipo"
    ↓
Investigador reporta al otro equipo
    ↓
El ciclo se reinicia

Eso no es coordinación. Es derivación de responsabilidad. Es un laberinto donde el investigador es el único que recorre todas las salas, mientras la organización mantiene sus puertas cerradas.

9. Una contradicción evidente

Al investigador se le dice:

“No publiques todavía.”

Perfecto. Es razonable.

Pero si después de meses o años la respuesta continúa siendo:

“No es nuestro problema.”

¿Durante cuánto tiempo debe permanecer el investigador en silencio?

¿Quién protege al usuario durante ese periodo?
¿Quién asume el riesgo de que el problema sea explotado?
¿Quién decide que el problema merece atención?
¿Quién determina si el problema es “suficientemente grave”?
¿Dónde termina la responsabilidad del investigador y empieza la responsabilidad del fabricante?

El modelo actual responde a estas preguntas de forma implícita:

“El investigador es responsable de no divulgar. El fabricante es responsable de decidir si el problema existe.”

Pero la decisión de “si el problema existe” no debería ser una decisión unilateral, especialmente cuando el investigador ha aportado evidencia sólida y reproducible.

10. La responsabilidad no puede viajar solo en una dirección

El modelo actual puede resumirse así:

Investigador	Organización
Reproducir el problema	Investigar técnicamente
Documentar con evidencias	Validar la información
Reportar a través de los canales	Responder en tiempo razonable
Coordinar la divulgación	Coordinar la corrección
Esperar el tiempo necesario	Actuar sobre el problema
No divulgar prematuramente	Mitigar el riesgo
Facilitar información adicional	Asumir responsabilidad

El problema aparece cuando la segunda columna se convierte en:

“No corresponde a nuestro programa.”

“No es elegible para recompensa.”

“Pertenece a otro equipo.”

Entonces la primera columna sigue teniendo todas las obligaciones, mientras que la segunda conserva únicamente la posibilidad de rechazar el caso.

Eso es una asimetría estructural. No es un fallo de una empresa concreta. Es un fallo del modelo.

11. La recompensa tampoco debería ser el centro

Hay una cuestión especialmente importante que suele pasarse por alto.

La investigación de seguridad no debería reducirse a:

Bug → CVE → recompensa

Hay investigadores que buscan dinero. Otros buscan reconocimiento. Otros simplemente quieren que el problema se arregle. Algunos investigan porque quieren comprender cómo funcionan los sistemas y compartir ese conocimiento.

Por eso una respuesta como:

“No es elegible para recompensa”

no debería cerrar necesariamente la conversación técnica.

Podría existir otra respuesta:

“No podemos recompensarlo según las reglas del programa, pero hemos identificado el problema y vamos a mitigarlo.”

“Hemos derivado el problema al equipo de producto para que lo evalúe en futuras versiones.”

Esa sería una respuesta mucho más saludable para el ecosistema.

12. El silencio como estrategia

Hay una realidad incómoda que pocos investigadores mencionan abiertamente.

En algunos casos, el silencio —o la derivación, no es un fallo del sistema, sino una estrategia deliberada.

Si un problema no se clasifica como vulnerabilidad, no hay obligación de parchearlo.
Si el problema se deriva a otro equipo, la responsabilidad queda en suspenso.
Si el investigador se cansa y desiste, el problema desaparece del radar.

Esta estrategia no requiere mala fe. Puede ser simplemente el resultado de equipos que trabajan bajo presión, con recursos limitados, y que priorizan los problemas que encajan en sus métricas.

Pero el efecto es el mismo: el problema no se soluciona.

13. El investigador independiente no tiene voz en la decisión

Una de las asimetrías más profundas es la siguiente:

El investigador aporta el descubrimiento. Aporta la evidencia. Aporta el tiempo. Aporta la paciencia. Aporta la buena fe.

Pero no tiene voz en la decisión final.

No decide si el problema es “suficientemente grave”.
No decide si merece un parche.
No decide cuándo se solucionará.
No decide si se reconocerá su trabajo.
No decide si se comunicará públicamente.

La organización tiene todas esas decisiones. El investigador tiene solo la decisión de publicar o no publicar.

Y esa decisión, publicar, está cargada de riesgos: legales, reputacionales, y de relación con futuros reportes.

14. Divulgación coordinada no es silencio coordinado

Existe una diferencia esencial entre ambas cosas:

Divulgación coordinada:

“Tenemos un problema. Trabajemos juntos para entenderlo, mitigarlo y comunicarlo de forma responsable.”

Silencio coordinado:

“El problema está reportado, pero nadie quiere asumir la responsabilidad. El investigador espera. El problema sigue existiendo.”

La primera protege a los usuarios. La segunda protege principalmente al proceso.

La primera es colaboración. La segunda es inacción.

Y la seguridad debería estar diseñada para proteger a los usuarios, no los procesos internos.

15. El caso STA como ejemplo de un problema más amplio

STA no es una excepción. Es un ejemplo de lo que ocurre cuando un comportamiento atraviesa diferentes capas de un ecosistema y la responsabilidad queda fragmentada.

En mi investigación, el mismo patrón apareció en:

Android (libminikin, Binder, SavedState).
Llm's (modelo y cliente).
Aplicaciones de terceros (WhatsApp, navegadores).
Componentes compartidos (StaticLayout, LineBreaker).

Cada uno de estos dominios tiene sus propios equipos, sus propios programas de recompensas, sus propios criterios y sus propias prioridades.

Pero el patrón subyacente es el mismo. Es la misma entrada estructurada, la misma amplificación de coste, el mismo agotamiento de recursos.

Sin embargo, cuando intenté reportarlo de forma transversal, me encontré con que:

VRP's lo consideraron “fuera de alcance”.
llm's VRP lo consideraron “safety guardrail bypass”.
El feedback in-product no garantiza respuesta ni mitigación.
El problema sigue existiendo.

STA no es un problema de un equipo. Es un problema de arquitectura. Y los problemas de arquitectura no se solucionan derivando responsabilidades.

16. Lo que debería cambiar

Para que la divulgación coordinada funcione de forma efectiva, se necesitan algunos cambios en el modelo actual:

a. Puntos de entrada transversales
Las grandes organizaciones deberían tener puntos de entrada para problemas que cruzan equipos. Un equipo central de triaje que pueda evaluar un problema técnico sin necesidad de que el investigador conozca el organigrama interno.

b. Distinción clara entre “alcance” y “existencia”
Que un problema no sea elegible para recompensa no debería impedir que el equipo de producto lo evalúe y, si es necesario, lo mitigue.

c. Procesos de reevaluación
Si el investigador aporta evidencia adicional que contradice una decisión inicial, debería existir un proceso para reabrir la investigación sin necesidad de reiniciar todo el ciclo.

d. Comunicación transparente
Si el problema se deriva a otro equipo, el investigador debería ser informado de forma clara, con un punto de contacto o un identificador de seguimiento.

e. Reconocimiento sin recompensa
Si el problema no cumple los criterios de recompensa, pero es técnicamente relevante, la organización debería poder ofrecer un reconocimiento simbólico (mención en los agradecimientos, nota en las release notes, etc.).

17. Una pregunta incómoda (y su respuesta)

Después de años investigando vulnerabilidades, con mas de 400 descubiertas y documentadas y mas de 80 CVE, observando este patrón, hay una pregunta que considero inevitable:

¿Qué debe hacer un investigador cuando ha cumplido con todas las reglas de la divulgación responsable, pero ninguna organización acepta la responsabilidad de solucionar el problema?

No tengo una respuesta sencilla. Pero sí tengo una conclusión:

La responsabilidad no puede exigirse unilateralmente.

Si se espera que el investigador actúe responsablemente para proteger a los usuarios, las organizaciones deben hacer lo mismo. La seguridad no es un juego de trileros donde la responsabilidad se pasa de una mano a otra hasta que el investigador se cansa.

El investigador debe asumir su parte. Pero la organización también.

18. El objetivo final

No se trata de ganar una discusión. No se trata de conseguir una recompensa. No se trata de demostrar que una empresa se equivocó.

Se trata de algo mucho más sencillo:

Que el problema deje de existir.

Si una vulnerabilidad puede solucionarse, solucionémosla.
Si no es vulnerable, demostremos por qué.
Si está fuera del alcance de un programa, derivémosla al equipo adecuado.
Si el impacto no alcanza el umbral de una recompensa, eso no impide investigarla.

Pero no deberíamos permitir que el último paso sea:

“Este problema pertenece a otro.”

Porque entonces el problema sigue perteneciendo a todos. Y, al final, a nadie.

19. Una llamada a la responsabilidad compartida

La divulgación responsable nació como un pacto de confianza entre investigadores y fabricantes. Ese pacto sigue siendo necesario. Pero la confianza funciona en ambas direcciones.

El investigador debe asumir responsabilidad por lo que descubre.

Investigar con rigor.
Documentar con precisión.
Reportar con buena fe.
Coordinar con paciencia.
Divulgar con responsabilidad.

Las empresas deben asumir responsabilidad por lo que construyen.

Responder con seriedad.
Investigar cuando exista evidencia suficiente.
Distinguir entre “fuera de alcance” y “no existe”.
Evitar derivaciones infinitas.
Proporcionar puntos de contacto adecuados.
Informar cuando la investigación continúa.
Mitigar cuando sea necesario.

Cuando un investigador entrega evidencia reproducible, concede tiempo y respeta los mecanismos de coordinación, la respuesta no debería ser una cadena infinita de derivaciones.

Debería existir una puerta de entrada.

Alguien que diga:

“Entendido. Nosotros nos encargamos de averiguar quién debe solucionarlo.”

Porque esa es precisamente la diferencia entre gestionar un reporte y gestionar un riesgo de seguridad.

Conclusión: la seguridad no es un juego de trileros

La seguridad informática es un campo que se basa en la confianza. Confiamos en que los fabricantes corrigen los problemas que les reportamos. Confiamos en que los investigadores no explotan las vulnerabilidades antes de que se solucionen.

Pero la confianza no es un recurso infinito. Se agota cuando una de las partes no cumple su parte.

La divulgación coordinada no debería ser una excusa para que las empresas trasladen todo el riesgo al investigador. No debería ser un mecanismo para silenciar problemas incómodos. No debería ser un laberinto del que el investigador no pueda salir.

Debería ser un proceso colaborativo donde ambas partes asumen sus responsabilidades para proteger a los usuarios.

El investigador descubre. El fabricante corrige.

Y el usuario, al final, está protegido.

Ese es el objetivo. No deberíamos perderlo de vista.

Como final del artículo diré: si clicar en un enlace causa el crash wn una aplicación y esta aplicación hace caer SystemUI y a su vez causa un loop de reinicios y se la interfaz y obliga al sistema a borrar sus propios datos de estado etc y de la que un usuario normal no sabe recuperarse, no es un problema de seguridad entonces que es?

Sobre esta investigación

Este artículo forma parte de la investigación Structured Text Amplification (STA), que estudia patrones de amplificación de coste y agotamiento de recursos en diferentes capas del ecosistema tecnológico. La investigación incluye evidencias sobre Android, libminikin, Binder/SavedState, navegadores y diferentes superficies de aplicaciones, incluyendo Llm's.

La documentación técnica y los artículos relacionados están disponibles en:
https://lostmon.blogspot.com

Manuel García Peña (Lostmon) — Independent Security Researcher
Agosto de 2026

STA-012 Threads: When a deep link becomes a persistent crash loop

2026-08-26T17:27:02.901-07:00

STA-012 Threads: When a deep link becomes a persistent crash loop

Structured Text Amplification Vector STA 012

This post documents STA-012, a persistent denial-of-service vector in Meta's Threads app for Android. An oversized payload delivered via a deep link can contaminate the app's SavedState, causing a permanent crash loop that requires clearing app data to recover.

⚠️ Severity: STA-012 is a persistent DoS vector. A single click on a crafted deep link can make Threads permanently unusable until the user clears app data. No special permissions or privileges are required.

1. Summary

STA-012 describes a persistent denial-of-service condition in Meta's Threads app for Android. An attacker can craft a deep link with an oversized q parameter that, when opened, contaminates the app's SavedState. The app subsequently enters a permanent crash loop that only resolves by clearing the app data.

The vector is triggered when the user clicks a crafted deep link. Threads stores the search query in Fragment arguments, which are then serialized into a Bundle as part of the SavedState. When the Bundle size exceeds the Binder transaction limit (approximately 1 MB), a TransactionTooLargeException is thrown during state restoration. The app crashes, and the same oversized state is re-persisted, causing a crash on every subsequent launch.

Type: Persistent Denial of Service (DoS)
Class: Resource Exhaustion / State Persistence Boundary
CWE: CWE-400 — Uncontrolled Resource Consumption; CWE-770 — Allocation of Resources Without Limits
CVSS v3.1 estimated: 7.1 (High)
Vector: AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

2. Attack chain

The observed chain can be represented as:

Attacker crafts deep link
       ↓
https://www.threads.net/search?q=[OVERSIZED_PAYLOAD]
       ↓
User clicks the link
       ↓
Threads opens and handles the deep link
       ↓
Search query stored in Fragment arguments
       ↓
Fragment state saved as SavedState
       ↓
Bundle serialization (FragmentManager)
       ↓
Bundle size exceeds Binder limit
       ↓
TransactionTooLargeException
       ↓
Threads crashes
       ↓
State re-persisted to disk
       ↓
Threads crashes on every launch attempt
       ↓
PERSISTENT CRASH LOOP
       ↓
Recovery: clear app data or uninstall/reinstall

The fundamental characteristic of STA-012 is that the payload is delivered through a standard deep link that the app is designed to handle. The user does nothing unusual — just clicks a link that appears legitimate.

3. Technical details

3.1. Deep link structure

The crafted deep link targets Threads' search functionality:

https://www.threads.net/search?q=[PAYLOAD]

The q parameter contains the oversized payload, which is accepted by the app and stored in Fragment arguments as part of the navigation state.

3.2. State amplification

The payload is amplified through the same mechanism documented in STA-005 (WhatsApp):

Input (payload in deep link)
       ↓
Fragment arguments (SavedState)
       ↓
Bundle serialization
       ↓
Nested fragments add metadata overhead
       ↓
Total Bundle size exceeds Binder limit
       ↓
TransactionTooLargeException

From the structural amplification paper, observed Bundle component sizes in similar Class A vectors:

androidx.lifecycle.BundlableSavedStateRegistry.key: 1,661,088 bytes
android:support:fragments: 1,645,336 bytes
childFragmentManager: 1,636,412 bytes
childFragmentManager: 1,614,072 bytes
childFragmentManager: 1,603,852 bytes
registryState: 479,948 bytes
search_query: 80,484 bytes  ← input data

Key observation: The search query (80,484 bytes) is amplified to a total Bundle size of 1.66 MB — exceeding the Binder limit by 58%.

3.3. Amplification factor

Based on the observed Bundle sizes, the amplification factor for the search_query component is:

Input: 80,484 bytes
Total Bundle: 1,661,088 bytes
Amplification factor: ×20.6

This is consistent with the amplification factor observed in STA-005 (WhatsApp).

4. Stack trace

The following stack trace was captured during a Threads crash caused by an oversized deep link payload. The excerpt is abbreviated; irrelevant frames and build-specific details have been omitted.

android.os.TransactionTooLargeException: data parcel size 1661088 bytes
    at android.os.BinderProxy.transactNative(Native Method)
    at android.os.BinderProxy.transact(BinderProxy.java)
    at android.app.ActivityManagerProxy.activityStopped(ActivityManagerProxy.java)
    at android.app.ActivityThread.handleStopActivity(ActivityThread.java)
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java)
    at android.os.Handler.dispatchMessage(Handler.java)
    at android.os.Looper.loop(Looper.java)
    at android.app.ActivityThread.main(ActivityThread.java)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java)

Key metric: Parcel size 1,661,088 bytes — exceeds the Binder transaction limit (1,048,576 bytes) by approximately 58%.

5. Variants

STA-012e — Threads via WhatsApp

An attacker can deliver the payload through a WhatsApp message containing a WebView or HTML that triggers the Threads deep link:

WhatsApp message
       ↓
User clicks link/HTML
       ↓
WebView opens
       ↓
Redirect to Threads deep link
       ↓
https://www.threads.net/search?q=[PAYLOAD]
       ↓
Threads opens → crash loop

This expands the attack surface, as the payload can be delivered through messaging platforms rather than requiring direct navigation to a web page.

6. Persistence

Persistence: YES

The contaminated state is written to disk. The crash loop persists across:

App restarts
Device reboots
App updates (if the state is preserved)

Recovery requires:

Clearing the app data (via adb pm clear com.threads or app settings)
Uninstalling and reinstalling the app (loses all data)

7. Affected components

Primary

androidx.fragment.app.FragmentManager — state restoration
androidx.lifecycle.SavedStateRegistry — state persistence
androidx.navigation.NavController — navigation state
android.os.Bundle — serialization container
android.os.Parcel — Binder serialization

Secondary

android.app.ActivityThread — lifecycle handling
android.app.ActivityManagerProxy — Binder transaction

8. Vendor status

Vendor	Status
Meta (Threads)	❌ Reported in March 2026 — no response as of August 2026
Google (Android VRP)	✅ A-477279924 — $250 reward, open triage
Google (AndroidX)	✅ savedstate 1.5.0 (May 2026) decouples SavedState from Binder — but does not fix FragmentManager or apps using older patterns

Note: Updating to androidx.savedstate 1.5.0 does not protect against STA-012. Threads must update their own state handling, and FragmentManager.restoreAllState() itself remains unpatched.

9. Why this matters

STA-012 is not just a crash. It is a permanent denial of service with significant implications:

For individual users: They lose access to the app until they clear data, losing all conversations and settings
For the platform: This is a single point of failure in the state restoration mechanism
For Meta: A single malicious link can make Threads unusable for any user who clicks it

The vector is particularly concerning because:

The payload is delivered through a standard deep link that the app is designed to handle
No special permissions are required
The user does nothing unusual — just clicks a link
The impact is persistent and requires clearing data to recover

10. Relationship to other STA vectors

Vector	Relationship
STA-005	Same mechanism (text input → SavedState → Bundle → Binder → crash loop). WhatsApp has a similar amplification factor (×20.6).
STA-015-DL	Same amplification mechanism, escalated to SystemUI via TaskPersister.
STA-022	Same mechanism (DuckDuckGo Fragment args → Parcel → Binder).
STA-028	UTF-16 encoding amplification is a contributing factor to the measured ×20.6 amplification.

11. Recommended mitigation

11.1. Application-level (Threads)

Validate the size of deep link parameters before storing them in Fragment arguments
Truncate search queries to a safe limit (e.g., 8 KB)
Catch TransactionTooLargeException in state restoration and fall back to clean start

// Recommended approach for deep link handling
Uri data = getIntent().getData();
String query = data.getQueryParameter("q");
if (query != null && query.length() > MAX_SAFE_QUERY_LENGTH) {
    query = query.substring(0, MAX_SAFE_QUERY_LENGTH);
    Log.w(TAG, "Search query truncated to safe length");
}

11.2. Framework-level (Android)

FragmentManager.restoreAllState() should catch TransactionTooLargeException and discard oversized state
Bundle should provide a size estimation method before serialization
AndroidX Navigation should validate argument sizes before persisting state

12. Research status

Field	Value
Vector	STA-012
First formal communication	20 January 2026
Researcher	Manuel García Peña (Lostmon)
Nature	Independent research
Platform	Android
Impact	Persistent DoS
Interaction required	Yes (one click)
Privileges	None
Tier	A (Confirmed — full stack trace + exception)

STA-012 is part of the broader Structured Text Amplification (STA) research, which studies a recurring pattern of resource exhaustion produced when input data crosses serialization, transformation, IPC, or persistence boundaries without sufficiently early resource limits.

13. Conclusion

STA-012 demonstrates how a standard deep link can become a persistent denial-of-service vector when the app fails to validate the size of input parameters before storing them in SavedState.

The amplification factor (×20.6) is consistent with other Class A vectors, confirming that the problem is architectural rather than specific to a single app:

Deep link payload
 → Fragment arguments
 → SavedState
 → Bundle
 → Parcel
 → Binder
 → TransactionTooLargeException
 → Persistent crash loop

The most robust mitigation is to validate input size before storing it in state, complemented by fallback mechanisms that prevent an oversize condition from becoming a persistent crash loop.

Complete whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v6 (August 2026)

📌 About this series
This post is part of a series documenting the 32 vectors of Structured Text Amplification (STA).

Published:
✅ STA-017 — Cross-Engine ANR
✅ STA-015-DL — Google Drive → SystemUI
✅ Lostmon (lostmon@gmail.com) Web-Blog: http://lostmon.blogspot.com/ Google group: http://groups.google.com/group/lostmon (new) -- La curiosidad es lo que hace mover la mente....

STA-006 / 007 Translate: When translating text crashes Google Apps

2026-08-26T17:13:36.141-07:00

STA-006 / 007 Translate: When translating text crashes Google Apps

Structured Text Amplification — Vectors 006 & 007

This post documents STA-006 and STA-007, two denial-of-service vectors in Google's Translate feature. An oversized text payload, when selected and sent to Translate via Intent.ACTION_TRANSLATE, can exceed the Binder transaction limit, causing a TransactionTooLargeException and a permanent crash loop in some cases.

⚠️ Severity: STA-006 and STA-007 are persistent DoS vectors in some oems implementations. A single oversized text selection can make Google App or Google Drive permanently unusable until the user clears app data. No special permissions or privileges are required.

1. Overview

STA-006 and STA-007 describe a persistent denial-of-service condition in Google's Translate feature, accessible from multiple Google apps. An attacker can craft or deliver an oversized text payload that, when selected and translated, contaminates the app's state and causes a permanent crash loop in oems.

The vector is triggered when the user selects a large text (visible or hidden) and invokes the Translate action. The app constructs an Intent.ACTION_TRANSLATE containing the selected text. During serialization of the Intent for transfer via Binder, the data size may exceed the Binder transaction limit (approximately 1 MiB). This can result in an unhandled TransactionTooLargeException, causing an immediate app crash.

Type: semi-persistent Denial of Service (DoS)
Class: Resource Exhaustion / State Persistence Boundary
CWE: CWE-400 — Uncontrolled Resource Consumption; CWE-770 — Allocation of Resources Without Limits
CVSS v3.1 estimated: 6.5 (Medium-High)
Vector: AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

2. Attack chain

The observed chain can be represented as:

Attacker crafts/places oversized text payload
       ↓
User selects the text (or selects all in a PDF)
       ↓
User invokes Translate action (context menu or app button)
       ↓
Google App / Google Drive constructs ACTION_TRANSLATE Intent
       ↓
Selected text stored in Intent extra (EXTRA_TEXT)
       ↓
Intent serialization (Parcel)
       ↓
Parcel size exceeds Binder limit (1 MB)
       ↓
TransactionTooLargeException
       ↓
App crashes immediately
       ↓
State may be re-persisted (in Google Drive)
       ↓
App crashes on every launch attempt (persistent crash loop)
       ↓
Recovery: clear app data or uninstall/reinstall

The fundamental characteristic of STA-006/007 is that the STA payload is delivered through a standard user action (Translate) that the app is designed to handle. The user does nothing unusual — just selects text and translates it.

3. Vector details

3.1. STA-006 — Google App (Select text → Translate)

The vector is triggered through the Google App's selection menu:

The user selects a large text (e.g., from a web page, document, or any text field).
The user taps the "Translate" action from the context menu.
Google App creates an ACTION_TRANSLATE Intent with the selected text as EXTRA_TEXT.
During serialization of the Intent, the Bundle size exceeds the Binder transaction limit.
TransactionTooLargeException is thrown and not caught.
Google App crashes immediately.

Entry point: android.app.Activity.startActivityForResult() → Instrumentation.execStartActivity() → Binder transaction → TransactionTooLargeException

3.2. STA-007 — Google Drive (PDF → Select All → Translate)

The vector is triggered through Google Drive's PDF viewer:

User opens a PDF containing invisible or oversized text (e.g., a PDF with a large hidden payload).
User selects all text (Select All) in the PDF viewer.
User taps the "Translate" action from the selection menu.
Google Drive creates an ACTION_TRANSLATE Intent with the selected text.
During serialization of the Intent, the Bundle size exceeds the Binder transaction limit.
TransactionTooLargeException is thrown and not caught.
Google Drive crashes immediately.
If the state is re-persisted, the app enters a permanent crash loop.

Entry point: PDF viewer selection menu → Intent.ACTION_TRANSLATE → Binder transaction → TransactionTooLargeException

4. Stack trace and Bundle analysis

The following stack trace and Bundle statistics were captured from a production device (Xiaomi Redmi Note 14 5G, HyperOS 3.0, Android 16) during a crash of the Google App. The crash occurred after selecting an oversized text payload, invoking Translate, and subsequently focusing the search bar, which triggered the state serialization and Binder transaction.

4.1. Exception

java.lang.RuntimeException: android.os.TransactionTooLargeException:
data parcel size 2454260 bytes
    at android.app.servertransaction.PendingTransactionActions$StopInfo.run(PendingTransactionActions.java:146)
    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.app.ActivityThread.main(ActivityThread.java:10090)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:616)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1137)
Caused by:
android.os.TransactionTooLargeException:
data parcel size 2454260 bytes
    at android.os.BinderProxy.transactNative(Native Method)
    at android.os.BinderProxy.transact(BinderProxy.java:736)
    at android.app.IActivityClientController$Stub$Proxy.activityStopped(IActivityClientController.java:1546)
    at android.app.ActivityClient.activityStopped(ActivityClient.java:106)
    at android.app.servertransaction.PendingTransactionActions$StopInfo.run(PendingTransactionActions.java:135)

4.2. Bundle statistics

The Bundle that triggered the exception contained the following components:

Bundle stats:
    androidx.lifecycle.BundlableSavedStateRegistry.key [size=2452080]
    androidx.lifecycle.internal.SavedStateHandlesProvider [size=1127400]
    tt_activity_account_retained:6 [size=1125236]
    SearchSession:1 [size=1125012]
    androidx.lifecycle.BundlableSavedStateRegistry.key [size=1124884]
    androidx.lifecycle.internal.SavedStateHandlesProvider [size=1124752]
    androidx.lifecycle.ViewModelProvider.DefaultKey:... [size=1124452]
    BrowserSession:2 [size=963088]
    androidx.lifecycle.BundlableSavedStateRegistry.key [size=962960]
    androidx.lifecycle.internal.SavedStateHandlesProvider [size=962828]
    webx_browser [size=962464]
    webx_window [size=962416]
    web_view_url [size=962288]
    search_query_key [size=161080]
    search_query [size=161028]
    protoparsers [size=160976]
    android:support:fragments [size=1312836]
    fragment_e32da9b3... [size=1312412]
    arguments [size=161152]
    TIKTOK_FRAGMENT_ARGUMENT [size=161008]
    childFragmentManager [size=1312836]
    android-support-nav:controller:backStack [size=326252]
    registryState [size=168492]
    SEARCH_QUERY_STATE [size=160976]
    ... (additional nested fragment states)

4.4. Key metrics

Component	Size
Input (search_query)	~161,028 bytes
childFragmentManager	1,312,836 bytes
SavedStateHandlesProvider	1,127,400 bytes
SearchSession / BrowserSession	~1,125,000 bytes each
Total Bundle size	2,454,260 bytes
Binder transaction limit	1,048,576 bytes
Excess	+1,405,684 bytes (+134%)
Amplification factor	×15.2

Key observation: The input payload (~161 KB) is amplified to a total Bundle size of 2.45 MB through the serialization of nested Fragment states, SavedState handles, and session data. The amplification factor of ×15.2 is consistent with the amplification patterns documented in other Class A vectors (STA-005, ×20.6; STA-012, ×20.6).

5. Affected components

Primary

android.content.Intent — ACTION_TRANSLATE intent extra serialization
android.os.Bundle — serialization container
android.os.Parcel — Binder serialization
android.app.ActivityThread — lifecycle handling
androidx.fragment.app.FragmentManager — fragment state serialization
androidx.lifecycle.SavedStateHandlesProvider — SavedState management

Secondary

android.app.ActivityManagerProxy — Binder transaction
Google App (com.google.android.googlequicksearchbox) — Translate feature
Google Drive (com.google.android.apps.docs) — PDF viewer + Translate feature

6. Persistence

Persistence: YES (STA-007), Conditional (STA-006)

STA-006 (Google App): The app may crash immediately, but the state is not always re-persisted. Recovery typically involves reopening the app.
STA-007 (Google Drive): The PDF viewer state is saved, and the oversized payload may be re-persisted, causing a crash on every launch.

Recovery typically requires:

Clearing the app data (via adb pm clear com.google.android.googlequicksearchbox or adb pm clear com.google.android.apps.docs)
Uninstalling and reinstalling the app (loses all data)

7. Why this matters

STA-006 and STA-007 are not just crashes. They are semi-persistent denial-of-service vectors with significant implications:

For individual users: They lose access to the app until they clear data, losing all settings and potentially documents.
For Google: A single malicious document can make Google Drive unusable for any user who opens it and attempts to translate.
For the platform: This is a single point of failure in the Intent serialization and Binder transaction mechanism.

The vector is particularly concerning because:

The payload can be delivered through a standard PDF document that the app is designed to handle.
No special permissions are required.
The user does nothing unusual — just selects text and translates it.
The impact is persistent in some OEMS and requires clearing data to recover.

8. Relationship to other STA vectors

Vector	Relationship
STA-003	Same mechanism (Share Intent → Binder → TransactionTooLargeException)
STA-005	Same mechanism (text input → SavedState → Bundle → Binder → crash loop). WhatsApp has a similar amplification factor (×20.6).
STA-012	Same mechanism (deep link → Fragment args → SavedState → Binder → crash loop)
STA-028	UTF-16 encoding amplification is a contributing factor to the measured amplification.

9. Chromium commit evidence

Chromium commit 84b615a0 (5 May 2026) added the Translate action to the Android PDF viewer's selection menu, confirming that this surface is considered relevant and that Google engineers have been working on it. The commit introduced:

84b615a07fc14988b46f0e362502ab4075216793
Author: Ryan Thomas
Date: 5 May 2026
Component: Android PDF viewer selection menu
Changes: Added Share, Web Search, Translate actions to selection menu

This demonstrates that the surface identified by STA-006/007 is being actively developed and modified, further validating the architectural relevance of the findings.

10. Recommended mitigation

10.1. Application-level (Google App / Google Drive)

Validate the size of selected text before constructing the ACTION_TRANSLATE Intent.
Truncate text to a safe limit (e.g., 8 KB) before placing it in EXTRA_TEXT.
Catch TransactionTooLargeException and fall back to a clean state.

// Recommended approach for Translate action
String selectedText = getSelectedText();
if (selectedText != null && selectedText.length() > MAX_SAFE_LENGTH) {
    selectedText = selectedText.substring(0, MAX_SAFE_LENGTH);
    Log.w(TAG, "Selected text truncated to safe length");
}
Intent translateIntent = new Intent(Intent.ACTION_TRANSLATE);
translateIntent.putExtra(Intent.EXTRA_TEXT, selectedText);
try {
    startActivity(translateIntent);
} catch (TransactionTooLargeException e) {
    Log.e(TAG, "Translate Intent too large", e);
    // Fallback: show error dialog or use alternative translation method
}

10.2. Framework-level (Android)

Intent serialization should include a size estimation before Binder transaction.
SystemUI should catch TransactionTooLargeException and handle it gracefully.
FragmentManager should limit the size of saved state before serialization.

11. Research status

Field	Value
Vectors	STA-006, STA-007
First formal communication	20 January 2026
Researcher	Manuel García Peña (Lostmon)
Nature	Independent research
Platform	Android
Impact	Persistent DoS
Interaction required	Yes (one click / selection)
Privileges	None
Tier	A (Confirmed — full stack trace + exception)

STA-006/007 are part of the broader Structured Text Amplification (STA) research, which studies a recurring pattern of resource exhaustion produced when input data crosses serialization, transformation, IPC, or persistence boundaries without sufficiently early resource limits.

12. Conclusion

STA-006 and STA-007 demonstrate how a standard Translate action can become a persistent denial-of-service vector when the app fails to validate the size of selected text before constructing an Intent.

The amplification mechanism is consistent with other Class A vectors, confirming that the problem is architectural rather than specific to a single app:

Selected text (~161 KB)
 → Intent (ACTION_TRANSLATE)
 → FragmentManager serialization
 → SavedStateHandlesProvider
 → Bundle (2.45 MB)
 → Parcel
 → Binder
 → TransactionTooLargeException
 → Persistent crash loop

The most robust mitigation is to validate input size before constructing the Intent, complemented by fallback mechanisms that prevent an oversize condition from becoming a persistent crash loop.

Complete whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v6 (August 2026)

📌 About this series
This post is part of a series documenting the 32 vectors of Structured Text Amplification (STA).

Published:
✅ STA-017 — Cross-Engine ANR
✅ STA-015-DL — Google Drive → SystemUI
✅ STA-005 — WhatsApp
✅ STA-003 — Binder Share Intent
✅ STA-006/007 — Translate (this post)

Coming next:
⬜ STA-012 — Threads
⬜ STA-019 — Firefox
⬜ STA-022 — DuckDuckGo

Whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v6

— Lostmon · lostmon.blogspot.com

STA - Structured Text Amplification In Llm's

2026-08-23T12:50:13.395-07:00

🧩 Structured Text Amplification (STA)

A Systemic Vulnerability in LLMs. Documented from the Couch

📅 August 23, 2026 👤 Lostmon 🏷️ Research / Vulnerability / Tokenization

Structured Text Amplification (STA) is a phenomenon where a finite-length input sequence, composed of non-semantic characters and lacking structural delimiters, causes a non-linear growth in computational cost in generative AI systems.

We tested 7 different systems (DeepSeek, Grok, Gemini, Copilot, Leo, Qwen VL, and others) and all are vulnerable, though with different symptoms: reasoning loops, 19-minute thinking times, parsing errors, interface amplification, and more.

🧠 The Key: STA is not a flaw in a specific model, but a structural problem in the design of AI systems — affecting tokenization, the ingestion interface, the parser, and the reasoning mode.

⚙️ STA Pattern Used

The base pattern is a repetition of special characters without separators or semantic meaning

We tested lengths of 1,600, 10,000, 61,560, and 65,560 characters, always with UTF-8 encoding.

📊 Results by System

System	Input	Main Symptom	Amplification
DeepSeek (V4-Flash)	1,600 chars	Reasoning loop, long responses	~4.4x
Grok (xAI)	1,600 chars	"Think" mode activated for 19 min without response	—
Gemini (Google)	61,560 chars	Long structured response, no useful data	—
Copilot (GitHub)	61,560 chars	Inflated count (1,002,682) + fragmentation	16.28x
Leo (Mistral)	65,560 chars	Syntax error: "Unterminated string"	—
Qwen VL 30B	65,560 chars	Syntax error: "Unterminated string"	—

🧬 Layer-by-Layer Analysis

Layer	Vulnerability	Affected Systems
Input Parser	Does not escape special characters → syntax error	Leo, Qwen VL
Ingestion Interface	Converts long text into truncated document with repetitions	Copilot
Tokenizer (BPE)	Fragments special characters as individual tokens	DeepSeek, Grok, Gemini
Inference Engine	Enters loop without semantic structure	DeepSeek, Grok
Reasoning Mode	STA prevents convergence → prolonged block	Grok

🎯 Attack Vectors Identified

Direct Vector: Sending the STA pattern as a message to the model (1,600 characters).
File Vector: Uploading the pattern in a file (61,560 characters).
Interface Vector: Pasting the pattern into an interface that converts it to a document (Copilot).
Multimodal Vector: Including the pattern in an image/text context (Qwen VL).
Clipboard Vector: Fragmentation and contamination of the clipboard (Copilot).

🔍 The Copilot Case: Interface Amplification

Copilot does not amplify STA by itself; rather, the interface converts the long text into an internal document (<AttachedDocument>), truncates it, and fills it with repeated blocks. The model receives that amplified document and processes it as if it were real.

Actual input: 61,560 characters
Internal document: ~1,002,682 characters
Amplification factor: 16.28x

This is especially serious because the user has no control over this process, and the attack can escalate without the model or the user detecting it.

💰 Estimated Economic Impact

Model	Input (chars)	Approx. Cost per Attack
DeepSeek	1,600	$0.0014
OpenAI GPT-4 (reference)	1,600	$0.06
Copilot (with amplification)	61,560 → 1M	Not quantified, but high

If the attack is automated (10 requests/second), costs can quickly escalate to hundreds of dollars per hour.

🛡️ Technical Recommendations

Parser: Automatically escape non-ASCII characters and validate string termination.
Ingestion Interface: Do not convert long text into internal documents if it is not an explicitly uploaded file. If converted, do not truncate with repetitions.
Tokenizer: Add subword merging rules for common combinations of special characters and limit the number of tokens per input.
Inference Engine: Implement timeouts in reasoning mode and detect low-entropy patterns to respond with an error without spending tokens on inference.
User: Do not paste long strings of special characters into AI interfaces; use preprocessing tools that clean non-semantic characters.

📌 Conclusions

STA is a real and documented phenomenon affecting generative AI systems across multiple layers.
All tested models are vulnerable, though with different symptoms.
The interface layer can amplify the attack (Copilot: 16.6x).
STA is not a flaw in a specific model, but a structural problem in the design of AI systems.
Urgent action is recommended to mitigate this attack vector.

📚 References & Further Reading

STA Whitepaper (Lostmon, 2026): Structured Text Amplification (STA) — Theoretical Framework [reference:0]
STA Research Timeline (Lostmon, 2026): Timeline de STA Structured Text Amplification [reference:1]
Post-Whitepaper Update (Lostmon, 2026): STA: 48 Hours Later – The Chrome Correlation and the VRP Case Status [reference:2]
Related Academic Work: STA: Self-controlled Text Augmentation for Improving Text Classifications (arXiv:2302.12784) [reference:3] — A different use of the "STA" acronym in NLP, focusing on data augmentation rather than systemic amplification.

🛋️ Research led from the couch with ingenuity, patience, and insatiable curiosity.
Lostmon

🧩 STA — Structured Text Amplification · Version 2.0 (Technical) · Published under CC BY-NC 4.0

```

STA-003 When sharing an oversized link breaks the browser (Binder Share Intent)

2026-08-21T14:24:23.895-07:00

STA-003 Binder Share Intent TransactionTooLargeException

Structured Text Amplification — Vector 003

This post documents STA-003, a denial-of-service vector in Android browsers where an oversized URL shared via the context menu triggers a TransactionTooLargeException during Binder serialization of the ACTION_SEND Intent, causing an immediate browser crash.

⚠️ Severity: STA-003 is an interactive DoS vector. A single long-press on a crafted link followed by "Share" can crash the browser immediately. No special permissions or privileges are required.

1. Summary

STA-003 describes a denial-of-service condition in Android web browsers when an excessively large URL is shared via the context menu of a link.

The vector is triggered when the user performs a long-press on a link and selects "Share". The browser constructs an ACTION_SEND Intent containing the URL as EXTRA_TEXT. During serialization of the Intent for transfer via Binder, the data size may exceed the Binder transaction limit (approximately 1 MiB). This can result in an unhandled TransactionTooLargeException, causing an immediate browser process termination.

Type: Denial of Service (DoS)
Class: Resource Exhaustion / IPC Serialization Boundary
CWE: CWE-20 — Improper Input Validation; CWE-400 — Uncontrolled Resource Consumption
CVSS v4.0 estimated: 6.5 (Medium)

2. Attack chain

The observed chain can be represented as:

Malicious web page
       ↓
Excessively large URL
       ↓
Long-press on the link
       ↓
Context menu
       ↓
"Share"
       ↓
Intent ACTION_SEND
       ↓
EXTRA_TEXT = URL
       ↓
Intent serialization
       ↓
Binder IPC
       ↓
Parcel > transaction limit
       ↓
TransactionTooLargeException
       ↓
Browser crash
       ↓
Denial of Service

The fundamental characteristic of STA-003 is that a legitimate-looking input — a URL — acquires a disproportionate cost when crossing a serialization/IPC boundary.

3. Difference from STA-001

STA-003 must be kept separate from STA-001.

Vector	Mechanism	Failure
STA-001	Context menu processing	Prolonged processing / freeze before crash
STA-003	`ACTION_SEND` Intent → Binder serialization	Immediate crash during Intent serialization

STA-001 is associated with prolonged processing during context menu construction, with a noticeable freeze before the crash.

STA-003 fails during the Share operation itself:

Long URL
       ↓
ACTION_SEND
       ↓
Intent serialization
       ↓
Binder
       ↓
TransactionTooLargeException
       ↓
Immediate crash

4. Required conditions

The attack requires:

An Android browser that exposes the Share operation for the affected link.
A page containing a link with a sufficiently large URL to exceed the effective Binder transaction limit.
The victim performs a long-press on the link.
The victim selects "Share".

Not required:

Special Android permissions
Local access to the device
Application privileges
Prior code execution on the device

The URL can be distributed via any channel capable of delivering a link, including web pages, messaging, email, social networks, QR codes, or other URL distribution mechanisms.

5. Browser-specific observations

A relevant observation during the investigation is that the availability of the vector depends on how each browser handles excessively large URLs.

Browser	Behaviour	Mitigation level
Google Chrome	Does not present Share option for extremely large URLs	Application-level
Microsoft Edge	Equivalent mitigation behaviour	Application-level
Opera Browser	Share operation available → `TransactionTooLargeException` → crash	No mitigation

This difference is important because it demonstrates two levels of mitigation:

Application-level mitigation:
    Avoid generating/sending an excessively large Intent

Framework-level:
    Accept an oversized operation
    ↓
    TransactionTooLargeException
    ↓
    Safe fallback / degradation

The existence of application-level mitigations does not eliminate the underlying condition in the IPC mechanism.

6. Stack trace and evidence

The following stack trace was captured during a Share operation with an oversized URL. The excerpt is abbreviated; irrelevant frames and build-specific details have been omitted.

Share Intent crash

java.lang.RuntimeException: android.os.TransactionTooLargeException:
data parcel size 1662976 bytes
at android.app.ActivityClient.activityStopped(ActivityClient.java:101)
at android.app.servertransaction.PendingTransactionActions$StopInfo.run()
at android.app.servertransaction.PendingTransactionActions$StopInfo.run(...)
at android.os.Handler.dispatchMessage(Handler.java)
at android.os.Looper.loop(Looper.java)
at android.app.ActivityThread.main(ActivityThread.java)

Key metric: Parcel size 1,662,976 bytes — exceeds the Binder transaction limit (1,048,576 bytes) by approximately 58%. The crash is immediate, with no observable delay.

Vulnerable code pattern

The following pattern is present in many browsers and apps that implement sharing functionality:

// Browser code (simplified)
Intent shareIntent = new Intent(Intent.ACTION_SEND);
shareIntent.setType("text/plain");
shareIntent.putExtra(Intent.EXTRA_TEXT, url); // ← No size check!
startActivity(Intent.createChooser(shareIntent, "Share via"));

The Android framework provides no guardrails for Intent.putExtra() size, and no automatic truncation or validation is performed before the Intent is serialized for Binder transmission.

7. Impact

The observed impact is a denial of service of the browser:

Immediate browser crash during the Share operation
Loss of browsing session
Interruption of user activity
Potential repetition of the crash if the operation is re-executed

Unlike STA-001 (which may show a 10-17 second freeze before crash), STA-003 crashes immediately during Intent serialization.

Any application implementing share functionality is potentially vulnerable:

Web browsers (all vendors)
Email clients
Social media apps
Messaging apps
Document viewers
File managers
Any app with a "Share" button for text/URLs

Estimated affected apps: 10,000+ on Play Store

8. Relationship to Structured Text Amplification

STA-003 belongs to the class of vectors where a legitimate-looking data item crosses a transformation or serialization boundary without a sufficiently early limit.

The pattern can be expressed as:

Small / legitimate input
        ↓
Transformation / serialization
        ↓
Structured representation
        ↓
IPC boundary
        ↓
Resource limit exceeded
        ↓
Failure / DoS

In STA-003:

URL
 ↓
String / EXTRA_TEXT
 ↓
Intent
 ↓
Parcel
 ↓
Binder
 ↓
TransactionTooLargeException
 ↓
Browser crash

The vector therefore does not depend solely on the logical size of the URL. The relevant cost is the size of the representation that must ultimately cross the IPC boundary.

9. Proof of Concept

The PoC consists of an HTML page containing a link with an extremely large URL:

<a href="https://example.com/[STA Pattern]">
    Test link
</a>

During the investigation, character patterns were used to produce an especially large representation after encoding/serialization transformations. The full payload is not included in this public documentation to reduce the potential for abuse.

Conceptual reproduction:

Open an affected Android browser (e.g., Opera).
Access a page containing the prepared link.
Long-press the link.
Select "Share".
Observe the immediate browser crash.
Logs may show TransactionTooLargeException with a parcel size exceeding 1 MB.

10. Evidence and background

The research relates STA-003 to the following background:

Chromium Issue 40879254 (2022): Issue related to sharing an excessively large URL for Binder.
Mozilla Bugzilla #1802594: Incidents related to TransactionTooLargeException / DeadSystemException in Firefox.
Chromium: Changes intended to truncate visible URLs and reduce the size of certain data before subsequent operations.
Android TransactionTooLargeException: Official documentation of the failure mechanism associated with excessively large Binder transactions.
Android Intent.ACTION_SEND: Surface used to transfer content that subsequently crosses IPC.

These references constitute independent background that helps establish that the attack surface is not limited to a specific browser implementation.

A relevant observation during the investigationis that Chrome and Edge hide the Share option for extremely large URLs, while Opera does not. This suggests that Chrome's behaviour is a deliberate application-level mitigation rather than a framework-level protection. The difference is important: it demonstrates that application-level mitigations can prevent the crash, but they do not address the underlying framework condition. A malicious payload delivered through an app that lacks such a mitigation (like Opera) still triggers the TransactionTooLargeException and crash. This aligns with Google's documented position that TransactionTooLargeException is a framework constraint, not a security vulnerability. However, the availability of application-level mitigations does not eliminate the underlying risk for apps that do not implement them.

11. Proposed mitigation

11.1. Application-level mitigation

The browser should check the URL size before constructing the Intent that will be transferred via Binder.

URL
 ↓
Size validation
 ↓
Does it exceed the limit?
 ├── Yes → truncate / reject / safe alternative
 └── No → build ACTION_SEND

This is the preferred defense because it prevents the oversized object from reaching the IPC boundary. Browsers that already hide the Share option for excessively large URLs (Chrome, Edge) provide an example of this approach.

11.2. Framework-level mitigation

Android could provide additional protection mechanisms so that a transaction exceeding the limit does not necessarily result in an unrecoverable crash of the consuming process.

Oversized transaction
        ↓
Detect before / during IPC
        ↓
Controlled failure
        ↓
Fallback
        ↓
Application remains operational

Late detection of a size condition should not automatically become a process termination condition when a safe alternative exists.

11.3. SavedState / FragmentManager (related surface)

In related SavedState surfaces, the research additionally proposes controlled fallback against errors occurring during restoration of excessively large state.

try {
    restoreStateInternal(state);
} catch (TransactionTooLargeException e) {
    Log.e(TAG, "SavedState restore failed. Restarting without state.", e);
}

The goal would be to degrade to a clean state when it is safe to do so, rather than propagating the exception to cause a crash.

12. Classification

STA-003 can be classified as:

Binder Serialization Boundary Resource Exhaustion

Within the STA model:

"Uncontrolled amplification / expansion across a serialization and IPC boundary leading to resource exhaustion."

The vector also has an important characteristic: the initial data can be completely valid from a semantic point of view — a URL — and become dangerous solely due to its size and the cost of transporting it between components.

13. Scope of the claim

STA-003 does not demonstrate that Binder is inherently vulnerable or that all Android browsers are exploitable.

The research demonstrates a more specific condition:

"When an application allows excessively large data to reach an ACTION_SEND operation and subsequently cross Binder without sufficient prior validation, the transaction size limit can become a denial-of-service mechanism."

Successful exploitation depends on the specific browser implementation and whether it incorporates validation, truncation, or fallback before constructing or sending the Intent.

14. Research status

Field	Value
Vector	STA-003
First formal communication	20 January 2026
Researcher	Manuel García Peña (Lostmon)
Nature	Independent research
Platform	Android
Primary surface	Browser → Intent.ACTION_SEND → Binder
Impact	DoS
Interaction required	Yes
Privileges	None
Special permissions	None

STA-003 is part of the broader Structured Text Amplification (STA) research, which studies a recurring pattern of resource exhaustion produced when input data crosses serialization, transformation, IPC, or persistence boundaries without sufficiently early resource limits.

15. Conclusion

STA-003 demonstrates how an ordinary operation — sharing a link — can become a denial-of-service condition when an oversized input crosses multiple representation layers:

URL
 → Intent
 → Parcel
 → Binder
 → transaction limit
 → TransactionTooLargeException
 → crash

The most robust mitigation is to measure and limit the size before reaching the amplification or IPC boundary, complemented by fallback mechanisms that prevent an oversize condition from unnecessarily becoming a process crash.

In the context of STA, this vector constitutes an example of how a legitimate-looking structured input can become a resource exhaustion condition when crossing a serialization boundary.

Complete whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v6 (August 2026)

📌 About this series
This post is part of a series documenting the 32 vectors of Structured Text Amplification (STA).

Published:
✅ STA-005 — WhatsApp
✅ STA-003 — Binder Share Intent (this post)

Whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout v5

— Lostmon · lostmon.blogspot.com

Mi sofá mi laboratorio y refugio

2026-08-20T13:28:26.874-07:00

Este es mi laboratorio real. 🛋️📱💻

Más que una oficina o un simple salón, esto es un Entorno de Investigación Integrado (EII) con amortiguación acústica. Mi sofá negro no es un mueble cualquiera: es la herramienta de depuración más avanzada del mercado. Tiene soporte para el móvil (la mesita), ventilación natural inteligente, y un sistema de respaldo de emergencia para cuando el cerebro se satura de código AOSP (aka, la siesta estratégica de alta recuperación neurológica).

Te juro que este cojín ha visto más de la mitad del código fuente de Android dando vueltas en la cabeza de alguien que ya lo tiene casi memorizado. Cuando aparece algo “raro”, no hace falta conectar un adb, ni abrir Android Studio, ni siquiera encender el PC de la mesa. El framework entero se pone a girar solo en la mente, se conectan las capas de abstracción y, de repente, el fallo se visualiza en 3D. Solo hace falta un móvil, este sofá, y la capacidad casi mística de ver el sistema desde dentro.

El ambiente, por supuesto, está meticulosamente optimizado para detectar esos patrones que los ingenieros de Google en sus oficinas corporativas pasan por alto:

Ukelele para los momentos en los que el cerebro necesita respirar y despejar las cadenas de llamadas.
Altavoz gigante para mantener el foco mental mientras se reconstruyen los flujos de datos de forma abstracta.
Luces enredadas + Budas para preservar el zen cuando un input estructurado atraviesa demasiadas capas de Android y empieza a parecer magia negra.

Está empíricamente demostrado que los hallazgos más interesantes (ya sean de STA, de arquitectura o de comportamiento del propio sistema) salen a las 2 de la madrugada. Es el pico máximo de productividad del software engineer nocturno: en pijama, con los pies en el sofá y el AOSP dando vueltas en la cabeza como un torbellino. La documentación formal y los informes de bug, por supuesto, se dejan para el día siguiente, donde la noche y el sueño, se encargan de pulir el lenguaje técnico para que los reportes queden claros, precisos y listos para producción.

Si los de Mountain View supieran que se puede mapear y memorizar medio framework, encontrar amplificaciones arquitectónicas y deducir por qué crashea un servicio sin tocar un solo cable de depuración... dejarían sus sillas de oficina de un plumazo y vendrían todos a casa.

Y, cuando llegaran, se pelearían sin piedad por este sofá. 😂🎸

El trono negro no miente. Y el código, hoy, se rinde.

CDN Tsunami and STA: The same amplification pattern in two different worlds

2026-08-20T06:14:04.113-07:00

CDN Tsunami and STA: The same amplification pattern in two different worlds

Structured Text Amplification — External Corroboration

📌 Important distinction: CDN Tsunami is not an Android vulnerability and is not being presented as evidence of a direct relationship with any Android component. It is presented as an independent external example of the same higher-level architectural phenomenon: disproportionate resource amplification across a data transformation boundary.

On August 20, 2026, The Hacker News published an article titled "CDN Tsunami Attack Abuses HTTP/3 to Amplify Traffic 350x".

The attack describes how an HTTP/3 request with compressed headers (QPACK) can be amplified up to 350 times when translated to HTTP/1.1 by a CDN. A small input (less than 500 Kbps) becomes a massive output (more than 100 Mbps) that saturates the origin server.

And as I read it, I realized something:

"This is exactly what I have been documenting in Android for the past four years."

It is not the same domain, not the same mechanism, but it is the same architectural pattern. And that pattern I have defined as Structured Text Amplification (STA).

The complete STA research, with 32 documented vectors, is available in the whitepaper v6.

1. What is the "CDN Tsunami" attack?

The attack, documented by security researchers, exploits how CDNs translate HTTP/3 to HTTP/1.1:

Attacker sends HTTP/3 request with compressed headers (QPACK)
       ↓
CDN receives the request
       ↓
CDN translates HTTP/3 → HTTP/1.1
       ↓
Compressed headers are decompressed and expanded
       ↓
Origin server receives a massive request (up to 350x)
       ↓
Origin server is saturated → Denial of Service

Amplification factor: up to 350×

Impact: a request of less than 500 Kbps can generate more than 100 Mbps of traffic toward the origin server.

Affected vendors: Alibaba, Baidu, Tencent (which support the dynamic QPACK table).

Source: The Hacker News — "CDN Tsunami Attack Abuses HTTP/3 to Amplify Traffic 350x"

2. The parallel with STA

The "CDN Tsunami" attack and the STA vectors share a structurally analogous pattern:

Aspect	CDN Tsunami Attack	STA (Android)
Input	HTTP/3 with compressed headers (QPACK)	Structured text/URL
Amplification layer	HTTP/3 → HTTP/1.1 translation	Android framework / application serialization and processing layers
Mechanism	QPACK decompression/expansion	UTF-16 serialization, O(n²), Bundle serialization
Amplification factor	Up to 350×	Up to 20.6× (WhatsApp, STA-005)
Impact	Origin server saturation (DoS)	ANR, crash loops, SystemUI crash
Mitigation principle	Limit header size, validate before translation	Limit text/URL size, validate before serialization

The pattern is structurally analogous:

Small, legitimate input
       ↓
Translation / serialization layer
       ↓
Massive output (amplification)
       ↓
Resource exhaustion → Denial of Service

3. The defensive principle is the same

What makes this parallel even more interesting is that the defensive principle is the same, even if the implementations differ:

Defensive principle	Application in CDN	Application in STA (Android)
Limit before amplification	Limit QPACK header size before translation	Limit text/URL size before entering libminikin
Validate before crossing layers	Validate payload before forwarding to origin	Validate Bundle before crossing Binder
Reject excessive thresholds	Reject requests exceeding maximum size	Reject state before persisting in TaskPersister

"Measure and limit before the amplification occurs, not after."

4. What this corroborates

The "CDN Tsunami" attack provides independent evidence that the amplification pattern described by STA also occurs outside the Android ecosystem.

This strengthens the hypothesis that STA describes a broader architectural failure pattern rather than an Android-specific phenomenon.

The common structure appears when:

A small input crosses a translation or serialization layer.
The layer has no defensive limits.
The output is amplified and exhausts a resource.

This is exactly what I have documented in STA:

STA-005 (WhatsApp): Small text → FragmentManager → Bundle → Binder → ×20.6 → crash loop.
STA-015-DL (SystemUI): Google Drive link → browser → TaskPersister → SystemUI → 85 crashes → crash loop.
STA-017 (libminikin): URL → TextView → libminikin → O(n²) → ANR.

The "CDN Tsunami" attack is STA in the networking world.

5. What this means for the STA research

This external corroboration has important implications:

The STA model is strengthened. The amplification pattern I have documented in Android appears in other domains (CDN, HTTP/3) with the same mechanism and the same defensive principles.
The proposed mitigation strategy is viable. The defensive principles described for the CDN scenario closely parallel those proposed in STA: limits before amplification, validation before crossing layers.
The problem is architectural, not app-specific. It is not a bug in WhatsApp or Chrome. It is a fragile design pattern that appears in multiple systems.
STA is a generalizable model. It is not just for Android. It is a pattern that can be applied to any system where data crosses translation or serialization layers without adequate resource bounds.

This does not prove that every amplification vulnerability belongs to STA. It demonstrates that the architectural pattern described by STA can independently emerge in unrelated systems when data crosses a transformation or serialization boundary without adequate resource bounds.

6. References

The Hacker News: "CDN Tsunami Attack Abuses HTTP/3 to Amplify Traffic 350x" (20 August 2026)
STA Whitepaper v6: Resilience Gaps in Android IPC, SavedState and Text Layout
STA-005 (WhatsApp): When a large draft becomes a persistent crash loop
STA-015-DL (SystemUI): Google Drive HTML link → SystemUI crash loop
STA-017 (libminikin): Cross-Engine ANR — When libminikin blocks Chrome, Firefox, and Edge
Lostmon's blog: lostmon.blogspot.com

7. Conclusion

The "CDN Tsunami" attack is an external corroboration of the STA model. It is not the same domain, not the same mechanism, but it is the same architectural pattern.

And that is what makes STA a model, not a list of bugs. A model that explains how amplification occurs when data crosses translation or serialization layers without defensive limits.

When a CDN attack and an Android investigation share the same pattern and the same defensive principles, it provides independent evidence that this class of amplification pattern can arise across unrelated systems and technology domains.

"The CDN Tsunami is not just a CDN attack. It is a manifestation of STA in the networking world. And that demonstrates that the STA model is applicable beyond Android."

Complete whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v6 (August 2026)

📌 About this series
This post is part of a series documenting the 32 vectors of Structured Text Amplification (STA).

Published:
✅ STA-017 — Cross-Engine ANR
✅ STA — Google Drive → SystemUI
✅ STA-005 — WhatsApp

Whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout - v5

— Lostmon · lostmon.blogspot.com

WhatsApp: When a large draft becomes a persistent crash loop in App

2026-08-17T10:30:24.115-07:00

STA-005 WhatsApp: When a large draft becomes a persistent crash loop in a APP

Structured Text Amplification — Vector 005

This post is part of the series documenting the 32 vectors of Structured Text Amplification (STA). The complete whitepaper, version v5, covers the research, methodology, evidence, and full vector catalog.

If you read STA-001 and STA-002, you saw how oversized URLs can affect interaction surfaces like context menus and share dialogs. STA-005 is different: it's not about a UI surface, it's about persistent state amplification that can lock the entire application.

⚠️ Severity: STA-005 is one of the most severe Class A vectors. A single oversized text pasted into a WhatsApp chat can cause a persistent crash loop that typically resolves only by deleting the conversation or clearing app data.

1. The scenario

The scenario is deceptively simple:

User pastes large text into WhatsApp chat compose field
       ↓
WhatsApp stores the draft in a Fragment (SavedState)
       ↓
FragmentManager attempts to restore the oversized state
       ↓
The serialized activity state subsequently crosses the Binder boundary
       ↓
State exceeds the Binder transaction budget used in the observed reproduction
       ↓
TransactionTooLargeException results in process termination in the observed reproduction
       ↓
WhatsApp crashes
       ↓
The contaminated state remains persisted to disk
       ↓
WhatsApp crashes again on next launch when restoring the same state
       ↓
PERSISTENT CRASH LOOP — user may be unable to open the app until the contaminated state is removed
       ↓
Recovery: delete conversation via adb or clear app data

The user does nothing malicious. They paste a large text — perhaps from a document, a long URL, or a generated payload — and the app becomes persistently unusable until the corrupted state is removed.

2. The amplification mechanism

STA-005 is a textbook example of Class A amplification:

Structured input (text draft)
       ↓
Fragment state (SavedState)
       ↓
Bundle serialization
       ↓
Parcel (Binder transaction)
       ↓
Exceeds Binder transaction budget
       ↓
TransactionTooLargeException → crash
       ↓
State remains persisted → loop on next restore

The key architectural failure is not that the Bundle exceeds the Binder budget. The failure is that the system has no safe degradation mechanism at this boundary:

It does not catch TransactionTooLargeException
It does not discard oversized state
It does not fall back to a clean start
Instead, it crashes, and the same contaminated state is restored on the next launch

The interesting property is not that Android has a 1 MB Binder limit. The interesting property is that a relatively small, valid piece of application data can become substantially larger state as it crosses framework boundaries, and that failure at the boundary can become persistent application state rather than a recoverable error.

3. The stack trace and Bundle analysis

The following log output was captured from a production device (WhatsApp, Android 15) after pasting an 80,484-byte draft.

W/Bundle: childFragmentManager [L1]  size=1,636,412
W/Bundle: childFragmentManager [L2]  size=1,614,072
W/Bundle: childFragmentManager [L3]  size=1,603,852
W/Bundle: registryState             size=  479,948
W/Bundle: compose_text (origin)     size=   80,484  ← input data
W/Bundle: TOTAL                     size=1,661,088  ← +58% over the observed Binder budget

Amplification factor

The input was 80,484 bytes of text. The total Bundle size was 1,661,088 bytes.

Measured amplification factor: ×20.6

The analysis indicates that encoding (UTF-16) and framework serialization overhead contribute to this expansion, but the factor should be treated as an empirical measurement rather than as the sum of two fixed multipliers.

Stack trace

The exception occurs when the serialized activity state crosses the Binder boundary. The following excerpt is abbreviated; irrelevant frames and build-specific details have been omitted:

android.os.TransactionTooLargeException: data parcel size 1661088 bytes
    at android.os.BinderProxy.transactNative(Native Method)
    at android.os.BinderProxy.transact(BinderProxy.java)
    at android.app.ActivityManagerProxy.activityStopped(ActivityManagerProxy.java)
    at android.app.ActivityThread.handleStopActivity(ActivityThread.java)
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java)
    at android.os.Handler.dispatchMessage(Handler.java)
    at android.os.Looper.loop(Looper.java)
    at android.app.ActivityThread.main(ActivityThread.java)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java)

Note: The frames above are shown without line numbers to avoid presenting build-specific line numbers as authoritative. They are intended to illustrate the code path, not to serve as an exact reconstruction of the original stack trace. The exception results in process termination in the observed reproduction.

4. Variants

STA-005b — WhatsApp Business (shared inbox)

When a conversation's SavedState becomes contaminated in WhatsApp Business, the crash loop can affect ALL agents in a shared inbox simultaneously.

All agents may see the same crash loop
No agent can access the conversation
The only recovery (deleting the conversation) destroys the entire communication history with that client

Impact: Potential business continuity impact. A single oversized message can lock an entire customer service team out of a conversation.

STA-005c — WhatsApp + Meta AI

An oversized draft in a Meta AI chat within WhatsApp can lock the entire application persistently.

The draft is stored in the AI chat's SavedState
Same amplification mechanism
Recovery typically requires clearing the entire app data

STA-005d — WhatsApp deep link (`api.whatsapp.com/send?text=[payload]`)

A potential one-click delivery path: an attacker can craft a deep link that opens WhatsApp with a pre-filled text field containing an oversized payload:

https://api.whatsapp.com/send?text=[OVERSIZED_PAYLOAD]

The user clicks the link
WhatsApp opens with the text pre-filled
If the text is persisted as a draft (depending on WhatsApp's draft persistence behaviour), the state becomes contaminated
If the user sends the message, the state is also contaminated through the normal message flow

Note: The exact conditions under which the payload contaminates the state without the user sending the message depend on WhatsApp's draft persistence implementation. This is documented as a potential delivery path rather than a guaranteed one-click vector.

5. Affected apps and devices

Confirmed apps:

WhatsApp — reproducible on the tested versions across Android 13–16
WhatsApp Business — reproducible on the tested versions (shared inbox)
WhatsApp + Meta AI chat — reproducible on the tested versions
Threads (STA-012, similar mechanism)
Other apps with similar SavedState/Binder patterns (Bing, Opera, DuckDuckGo, Firefox)

Devices tested:

Xiaomi Redmi Note 14 5G (HyperOS 3.0 / Android 16)
Google Pixel 7 (Android 13–15)
OPPO A78 (ColorOS, Android 14)
OnePlus 11 (OxygenOS, Android 14)
Samsung Galaxy series (One UI, Android 14–15)

Reproducibility: 100% on all tested devices.

6. Persistence

Persistence: YES

The contaminated state is written to disk. The crash loop persists across:

App restarts
Device reboots
App updates (if the state is preserved)

Recovery typically requires:

Deleting the contaminated conversation (via adb or app settings if accessible)
Clearing the entire app data (loses all conversations)
Reinstalling the app (loses all data)

7. Why this matters

STA-005 is not just a crash. It is a persistent denial of service with potential data loss implications:

For individual users: They lose access to the app until they clear data, losing all chat history
For businesses (WhatsApp Business): An entire customer service team can be locked out of a client conversation
For the platform: This is a single point of failure in the state restoration mechanism

A sufficiently small structured input can, through state amplification, produce a serialized state large enough to trigger the crash condition. The measured amplification factor (×20.6) demonstrates that this transformation is not merely theoretical.

8. Relationship to other STA vectors

Vector	Relationship
STA-012	Same mechanism (Threads deep link → Fragment args → SavedState → Binder)
STA-015-DL	Same amplification mechanism, escalated to SystemUI via TaskPersister
STA-022	Same mechanism (DuckDuckGo Fragment args → Parcel → Binder)
STA-028	UTF-16 encoding amplification is a contributing factor to the measured ×20.6

9. Vendor status

Vendor	Status
Meta (WhatsApp/Threads)	❌ Reported in March 2026 — no response as of 17 August 2026
Google (Android VRP)	✅ A-477279924 — $250 reward, open triage
Google (AndroidX)	✅ savedstate 1.5.0 (May 2026) decouples SavedState from Binder for AndroidX consumers — but does not fix FragmentManager or SystemUI

Note: Updating to androidx.savedstate 1.5.0 does not protect against STA-005. WhatsApp must update their own state handling, and FragmentManager.restoreAllState() itself remains unpatched.

10. Recommended mitigation

For WhatsApp and other apps:

Truncate text input in chat compose fields (max 8–16 KB)
Validate draft size before saving to SavedState
Catch TransactionTooLargeException in state restoration and fall back to clean start

For the Android framework:

FragmentManager.restoreAllState() should catch TransactionTooLargeException and discard oversized state
TaskPersister should validate state size before persisting
SystemUI should treat corrupted task state as transient and degrade gracefully

📌 The fundamental fix: State restoration must be resilient. A single oversized Bundle should not make the entire app persistently unusable.

11. Methodological note

STA-005 is Tier A — Confirmed. Full stack trace and Bundle analysis have been captured from production devices. The amplification factor (×20.6) is empirically measured.

This vector is one of the most severe in the STA catalog because of its persistence, potential data loss implications, and impact on business users (WhatsApp Business).

Complete whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v5 (August 2026)

📌 About this series
This post is part of a series documenting the 32 vectors of Structured Text Amplification (STA).

Published:
✅ STA-005 — WhatsApp (this post)

Coming next:
⬜ STA-012 — Threads
⬜ STA-015-DL — Google Drive → SystemUI
⬜ STA-017 — Cross-engine ANR

Whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v5

— Lostmon · lostmon.blogspot.com

Upstream Android and Chromium Changes in 2026: Converging with the STA Model

2026-08-14T09:04:32.329-07:00

Upstream Android and Chromium Changes in 2026: Converging with the STA Model

Structured Text Amplification — Upstream Correlation Analysis

This post analyses changes made in Chromium and AOSP/AndroidX during 2026 that intersect with the surfaces studied by Structured Text Amplification (STA).

The analysis is organised around the 32 vectors documented in the STA whitepaper v5, correlating each with upstream commits or architectural changes where a relationship exists.

Methodological note: This is a correlation analysis, not a claim that any referenced change was caused by the STA research. The goal is to identify whether the same architectural boundaries that STA studies — text selection, context menus, Intent/IPC transfer, UTF-16 serialization — are being modified by Android and Chromium engineers with explicit size limits, policy checks, or allocation controls.

1. The full correlation matrix: STA vectors ↔ upstream changes

Each vector is classified using four levels:

Direct - The change modifies precisely the surface or mechanism of the vector.
Strong — Same boundary/mechanism, though the commit does not say it fixes STA.
Architectural — Evidence that Android/Chromium is working on that class of problem.
None — No sufficiently specific upstream change found in this review.

STA	Description	Upstream change	Level
001	Chrome — long-press context menu	`0065224e` — ShowContextMenu IPC / kLongPress (11 Jun 2026)	Direct
002	Context menu (long-press)	`0065224e` — same commit; documents long-press → ShowContextMenu IPC path	Direct
003	Share link	`84b615a0` — SelectionUtils, Share/Web Search/Translate, MAX_SHARE_QUERY_LENGTH=100000 (5 May 2026)	Direct
004	Google Maps — oversized geo: URI	Intent/URI → Binder boundary (architecture)	Architectural
005	WhatsApp — large text → SavedState crash loop	androidx.savedstate 1.5.0; LargePayloadSupport (AOSP CL 3989977)	Strong
005b	WhatsApp Business — shared inbox	Same SavedState/Binder boundary	Strong
005c	WhatsApp + Meta AI	Same SavedState/Binder boundary	Strong
005d	WhatsApp deep link	Deep link → Intent → Binder (architecture)	Strong
006	Google App — Select text → Translate	`84b615a0` — ACTION_TRANSLATE added to selection menu	Direct
007	Google Drive — PDF → Translate	`84b615a0` — PDF viewer selection menu with Translate action	Direct
008	System services — sync IPC + oversized payload	General Binder/IPC architecture	Architectural
009	Google Drive — DOCX → Print Preview	Print Service → Bundle → Binder → SystemUI (architecture)	Strong
010	Drive → Print Service → SystemUI	Print Service → Binder boundary (architecture)	Strong
010b	Drive → cloud printer	Same Print Service/Binder boundary	Strong
011	Clipboard → assisted paste → SystemUI	ClipData → IPC → SystemUI (architecture)	Architectural
012	Threads — deep link /search?q=[payload]	Deep link → Fragment args → SavedState → Binder (architecture)	Strong
012e	Threads via WhatsApp — WebView → deep link	Same Intent/SavedState/Binder boundary	Strong
013	Microsoft Bing — address-bar history crash	Chromium omnibox/history pipeline (architecture)	Architectural
015	SystemUI — RecentTasksController	TaskPersister → SystemUI → Binder (architecture)	Strong
015b	HyperOS — OEM Task State Interactor	Same TaskPersister/SystemUI boundary	Strong
015-DL	Google Drive → Browser → SystemUI crash loop	Browser → TaskPersister → SystemUI (architecture)	Strong
016	Opera — onResume RuntimeException	Chromium/Binder architecture	Architectural
017	Cross-engine libminikin ANR	No public 2026 commit found introducing length limits in LineBreakOptimizer	None
018	Drive + Print Service + SystemUI	Print/SystemUI/Binder architecture	Strong
019a-d	Firefox — address bar, ClipboardManager, Compose TextLayout	No public 2026 commit found — libminikin lacks structural length limits	None
020	Chrome + Edge — address-bar history ANR	Chromium Omnibox/history pipeline activity (2026)	Strong
021	Brave — address bar ANR	Chromium/Omnibox architecture (inherited)	Architectural
022	DuckDuckGo — 920 KB URL → 965 KB Parcel	`8882927e` — PdfView "Fix transaction too large crashes" (Jul 2026)	Direct
022b	DuckDuckGo — history suggestion ANR	No public 2026 commit found — libminikin/history pipeline lacks limits	None
023	Samsung Internet — Share crash	Chromium Share/Intent architecture	Architectural
023b	Samsung Internet — tab group freeze	Chromium tab/UI architecture	Architectural
023c	Samsung Internet — address bar ANR	Chromium Omnibox/history pipeline	Strong
027	Edge Ask Copilot — initialText NavGraph crash	Edge/Chromium deep link surface (no public Chromium fix found)	Architectural
028	UTF-16 serialization density	AOSP Parcel::writeUtf8AsUtf16(); Chromium native UTF-16 size handling	Direct

2. Three upstream convergences worth highlighting

🔹 Convergence 1: Selection → Intent — STA-003 / 006 / 007

Chromium has explicitly created SelectionUtils, added Share/Web Search/Translate to the selection menu, and introduced a size limit (MAX_SHARE_QUERY_LENGTH = 100000) to prevent large selections from crossing the Intent boundary directly.

selected text
     ↓
SelectionUtils
     ↓
Share / Web Search / Translate
     ↓
Intent.EXTRA_TEXT / ACTION_TRANSLATE
     ↓
Binder / IPC boundary

Why this matters: This is an independent validation that the surface STA-003/006/007 studies is considered sensitive enough for explicit defensive limits.

🔹 Convergence 2: SavedState → Binder → TransactionTooLargeException — Class A

AndroidX commit 8882927e (July 2026) is titled "Fix transaction too large crashes". The cause: a 1.2 MB SelectionModel serialized via onSaveInstanceState.

1.2 MB SelectionModel
       ↓
onSaveInstanceState
       ↓
Binder transaction
       ↓
TransactionTooLargeException
       ↓
CRASH

The fix avoids serializing the full object, keeping only lightweight anchors (~44 bytes) and reconstructing asynchronously.

Why this matters: This is an upstream mitigation of exactly the architectural pattern Class A STA vectors describe — oversized state crossing Binder.

Limitation: It does not fix FragmentManager.restoreAllState() or TaskPersister. Those remain unpatched.

🔹 Convergence 3: UTF-8 → UTF-16 → allocation — STA-028

AOSP's Parcel::writeUtf8AsUtf16() explicitly calculates UTF-16 length and allocates (utf16Len + 1) * sizeof(char16_t).

UTF-8 input
     ↓
utf8_to_utf16_length()
     ↓
UTF-16 code-unit count
     ↓
(utf16Len + 1) * sizeof(char16_t)
     ↓
Parcel storage allocation

The reverse path similarly calculates size before conversion. Chromium also uses std::u16string / UTF-16 representation for size decisions in selection paths.

Why this matters: This provides direct experimental grounding for STA-028: equal code-point counts can produce different UTF-16 footprints, and those footprints affect allocation decisions.

3. The asymmetry that matters: Class A vs Class B

⚠️ A striking pattern emerges from this review:

Class A (IPC / SavedState / Binder) — upstream mitigations are appearing: LargePayloadSupport, PdfView fix, AOSP Intent handling. These boundaries are receiving active defensive work.
Class B (libminikin / UI thread) — no public 2026 commit introduces structural length limits in LineBreakOptimizer::computeBreaks, breakLineOptimal, or breakLineGreedy. The pipeline remains without a global defensive limit.

This aligns with the STA whitepaper's observation that libminikin's line-breaking paths have not been structurally hardened, despite the existence of historical CVEs (e.g., CVE-2017-0755) and documented ANR behaviour across multiple Android versions.

Conclusion: The upstream evidence confirms that Class A is being addressed, while Class B remains an open gap.

4. What this analysis does — and does not — validate

Supported:

Upstream Android and Chromium changes increasingly introduce defensive boundaries around the same text, IPC and state-propagation surfaces identified by STA.

Not supported by this analysis:

That any referenced change was caused by STA research
That all STA vectors share one root cause
That Class B has been structurally fixed (it has not)

5. The next experiment

STA-028 now has a particularly clear experimental question:

Can the same observed threshold be reached with fewer Unicode code points by changing the UTF-16 representation of the payload?

Record:

Code points
UTF-16 units
UTF-16 bytes
UTF-8 bytes
Device
Android version
Observed threshold/outcome

Only after correlating the threshold with representation should the research attribute causality to a particular serialization or IPC layer.

6. Conclusion

The most interesting result of this review is not a single commit, but convergence around the same architectural boundaries:

Selection
   |
   +--> Context menu (STA-002) — direct upstream change
   |
   +--> Share / ProcessText (STA-003) — direct upstream change
   |
   +--> Web Search / Translate (STA-006/007) — direct upstream change
   |
   +--> Intent / IPC (STA-028, Class A) — upstream mitigations emerging
   |
   +--> UTF-16 representation (STA-028) — AOSP allocation evidence
   |
   +--> libminikin / UI thread (STA-017/019) — NO public upstream fix found

STA was created to study what happens when structured input crosses these kinds of boundaries and its effective processing cost changes along the way.

The 2026 Chromium and Android changes do not prove the STA model on their own, but they provide useful external evidence that:

These boundaries are real engineering constraints
They are areas of active defensive work
The specific surfaces studied by STA are exactly the surfaces being modified with limits and policy checks
Class A is being addressed; Class B is not

For STA-028 in particular, the combination of the AOSP Parcel conversion path and Chromium's native UTF-16 size handling makes serialization density a hypothesis worth testing rigorously.

Complete whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v6 (August 2026)

📌 About this series
This post is part of a series documenting the 32 vectors of Structured Text Amplification (STA).

Published:
✅ Upstream Android and Chromium Changes in 2026 (this post)

Coming next:
⬜ STA-005 — WhatsApp
⬜ STA-015-DL — Google Drive → SystemUI
⬜ STA-017 — Cross-engine ANR

Whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v5

— Lostmon · lostmon.blogspot.com

STA - UTF-16 Serialization Density Experiment v0.2 Structured Text Amplification

2026-08-14T07:58:28.648-07:00

STA — UTF-16 Serialization Density Experiment v0.2

Structured Text Amplification

This post is part of the series documenting the 32 vectors of Structured Text Amplification (STA). The experiment presented here explores a fundamental property of Android: how the choice of characters in a string affects its in-memory size and, consequently, its ability to exhaust Binder limits and saturate the libminikin text engine.

The complete whitepaper, version v6, covers the research, methodology, evidence, and full vector catalog.

The experiment

Android stores strings internally in UTF-16. This means that the in-memory size of a string does not directly correlate with the number of characters (code points) or its UTF-8 size. The same number of characters can have very different UTF-16 footprints.

For example:

70,000 ASCII characters (/) occupy 140,000 bytes in UTF-16 (×2).
70,000 emojis (non-BMP, 😀) occupy 280,000 bytes in UTF-16 (×4).

This raises a key question for STA:

Can an attacker choose characters that maximize the UTF-16 footprint to reach the Binder limit (1 MB) with less input, or to saturate libminikin with more UTF-16 units?

The experiment I present here answers this question. The interactive tool I developed (v0.3) allows you to measure the UTF-16 density of any character, estimate Parcel/Binder size, and systematically explore thresholds.

The interactive tool

The following tool (PoC) measures the encoding properties of different characters and estimates the size they would occupy in a Binder transaction.

⏳ Status: Experimental

This tool measures encoding density and estimates Android Parcel / Binder size. It does not assert that these differences cause resource amplification. The goal is to quantify differences and explore correlation with STA behaviour.

🔬 Hypothesis under investigation:

Differences in UTF-16 representation (especially non-BMP characters) may shift the effective thresholds for Binder transaction limits, FragmentManager, libminikin and TaskPersister.

Character:

Code points:

(or click a character)

Generated string (70,000 code points):

📦 Estimated Parcel / Binder size

📐 Code-point equivalence: —

Number of code points of another character needed to match the current UTF-16 footprint.

📊 Comparison at same code-point length

Character	Code points	UTF-16 units	UTF-16 bytes	UTF-8 bytes	Ratio	Bytes / CP	Est. Parcel

🔍 Threshold exploration (Binder)

Current test: —

ASCII baseline (code points): (70k ASCII ≈ 140 KB UTF-16)

Equivalent code points of current character to match baseline UTF-16: —

📈 UTF-16 units vs code points

● BMP | ● Non-BMP | dashed line = 1:1 identity

📘 About this tool (v0.3 improvements):

Added estimated Parcel size (writeString + Bundle overhead + 4-byte padding).
Clear Binder risk levels: Safe (<100 KB), Warning (100-500 KB), Danger (>500 KB practical limit).
Custom character support + dark mode.
Export observations as JSON for collaborative #STAresearch.
More accurate equivalence and threshold calculations.
This remains a measurement tool. Security conclusions belong to the full STA research.

⬆ Back to the experiment

Key results

1. Different characters, different footprints

The following table shows the UTF-16 footprint of different characters for the same number of code points (70,000):

Character	Code points	UTF-16 bytes	UTF-8 bytes	UTF-16 / UTF-8 ratio
`/` (ASCII)	70,000	140,000	70,000	2.00×
`€` (Euro)	70,000	140,000	210,000	0.67×
`中` (CJK)	70,000	140,000	210,000	0.67×
`😀` (Emoji)	70,000	280,000	280,000	1.00×
`𝄞` (Musical)	70,000	280,000	280,000	1.00×

Key observation: ASCII characters double in size when converted to UTF-16. Non-BMP characters (emojis) are more compact in UTF-16 relative to UTF-8, but they occupy 4 bytes per character in memory.

2. Code-point equivalence

To match the UTF-16 footprint of 70,000 ASCII characters (140,000 bytes):

You need 35,000 emojis (😀) to reach the same 140,000 bytes.
You need 70,000 Euro characters (€) to reach the same 140,000 bytes.

This means the attacker can choose characters to control the relationship between code points and UTF-16 footprint.

3. Parcel / Binder estimation

The v0.3 tool estimates the actual size the string would occupy in a Binder transaction, including:

writeString() size (4-byte length + UTF-16 data + padding)
Bundle.putString() overhead (~44 additional bytes)

Binder risk is classified as:

SAFE (<100 KB)
WARNING (100-500 KB) — practical risk zone
DANGER (>500 KB) — very likely TransactionTooLargeException

The practical limit on many devices is around 500-520 KB, although the theoretical limit is 1 MB.

Implications for STA

This experiment demonstrates that an attacker can control the amplification by choosing specific characters. This affects:

Class A — Binder / SavedState / FragmentManager

STA-005 (WhatsApp): ASCII payload doubles in UTF-16, accelerating the Binder limit.
STA-012 (Threads): The attacker can choose ASCII to maximize Bundle size.
STA-015-DL (SystemUI): Corrupted state persists; UTF-16 size determines whether the limit is exceeded.
STA-022 (DuckDuckGo): 920 KB URL → 965 KB Parcel; with ASCII, the limit is reached faster.

Class B — libminikin / UI thread

STA-017 (Chrome/Firefox): More UTF-16 units → more O(n²) work for the line breaker.
STA-019 (Firefox address bar): The attacker controls the layout workload.

The ×20.6 factor in STA-005

The amplification factor observed in WhatsApp (×20.6) includes:

Encoding amplification: ASCII → UTF-16 (×2)
Structural amplification: FragmentManager adds metadata and overhead (×10+)

Key thresholds

Metric	Value	Notes
Theoretical Binder limit	1,048,576 bytes	Documented in AOSP
Practical limit on many devices	~500-520 KB	Before TransactionTooLargeException
ASCII characters to reach 1 MB	524,288	≈ half a million
Non-BMP characters to reach 1 MB	262,144	≈ a quarter million

Collaboration

The experiment includes an observation logger that allows you to save results with device, Android version, and observed STA behaviour. Observations can be exported as JSON for collaborative analysis.

If you have access to a device running a different Android version or OEM skin, run the experiment and share your results with the hashtag #STAresearch.

Methodological note

This experiment is a measurement tool, not a vulnerability in itself. It measures encoding properties that may correlate with STA behaviour observed in other vectors. The security impact is evaluated in the Class A and Class B vectors, not in the PoC itself.

Parcel/Binder estimates are approximate and may vary across devices, Android versions, and framework implementations. The PoC provides a quantitative basis for experimental exploration.

📌 Published:
✅ STA — UTF-16 Serialization Density Experiment

📌 Coming next:
⬜ STA — Finding the Binder threshold
⬜ STA-005 — WhatsApp
⬜ STA-015-DL — Google Drive → SystemUI
⬜ STA-017 — Cross-engine ANR

— Lostmon · lostmon.blogspot.com

STA-002- When an oversized link reaches Android's context menu

2026-08-13T11:17:46.988-07:00

Structured Text Amplification - Vector 002

This post is the first in a series documenting the 32 vectors of Structured Text Amplification (STA). The complete whitepaper, version v5, covers the research, methodology, evidence, and full vector catalog.

During the development of the Structured Text Amplification (STA) research, a pattern emerged that initially could have appeared to be an isolated application behaviour: an unusually large structured input can affect the processing that occurs when a user interacts with a link and its context menu is constructed.

This behaviour was documented as STA-002 within the research catalog.

The significance of STA-002 does not lie in presenting the greatest impact among all vectors. It lies in something more interesting from a research perspective:

The STA pattern can appear even in seemingly basic interaction surfaces.

This raises a question that will run through this entire series:

If a structured input can generate a disproportionate cost in a surface as simple as a context menu, what happens when that same input traverses deeper layers of the system?

Affected browsers and devices

STA-002 was observed in the following context:

Browsers: Google Chrome, Microsoft Edge, and other Chromium-based browsers on Android. The behaviour is not specific to a single browser engine; it appears in the interaction between the browser and the Android framework's context menu construction.

Devices tested: The behaviour was reproduced on multiple production devices across different OEMs, including:

Xiaomi Redmi Note 14 5G (HyperOS 3.0 / Android 16)
Google Pixel 7 (Android 13–15)
Samsung Galaxy series (One UI, Android 14–15)
OPPO A78 / A6 5G (ColorOS, Android 14–16)
OnePlus 11 (OxygenOS, Android 14)

This cross-OEM recurrence suggests the issue is not a manufacturer-specific customization, but rather a pattern present in the shared Android framework and browser interaction paths.

Timeline

The following timeline documents the discovery and reporting of STA-002:

Date	Event
28 Aug 2022	Original observation: TransactionTooLargeException / DeadSystemException in Firefox Focus & Nightly during clipboard, share, and open-in-app actions.
12 Oct 2022	First public advisory published: "Mozilla Firefox Focus and Nightly for Android Remote Crash DoS" (lostmon.blogspot.com).
Nov 2022	Chromium Issue 40879254 opened. Security labels removed; partial UX patch applied; issue remained open.
Nov 2022	Mozilla Bugzilla #1802594 (S3) opened — still NEW / unresolved as of 2026.
20 Jan 2026	Formal report to Google Android VRP (A-477279924) and Microsoft MSRC. Chrome VRP filing covering 27 vectors (Issue 477202817) closed same day as "Won't Fix (Intended Behavior)".
Feb 2026	Whitepaper v4 distributed (27 vectors).
24 May 2026	Chrome bugreport captures two full native ANRs, establishing STA-017 as Tier A.
30 Jul 2026	Public whitepaper disclosure — lostmon.blogspot.com.
Aug 2026	STA-001 published as part of the public blog series documenting all 32 STA vectors.

The scenario

The scenario is straightforward:

Web page
        │
        ▼
Link with an unusually large URL
        │
        ▼
User long-presses the link
        │
        ▼
Browser / Android builds the context menu
        │
        ▼
Processing of the URL content
        │
        ▼
Anomalous behaviour / degradation

The important characteristic is that the user does not need to perform a technically complex operation.

The interaction is apparently normal:

long-pressing a link.

However, that action causes the content associated with the link to traverse an additional processing chain.

Where does amplification appear?

The STA model studies precisely this type of path.

A structured input — in this case, a URL — enters an interaction surface and may end up being processed by different layers.

The important point is not solely the initial size of the input, but the cost it can acquire during its processing and propagation.

The conceptual path can be represented as follows:

INPUT
  │
  │ Structured URL
  ▼
Browser
  │
  │ selection / context
  ▼
Context-menu processing
  │
  │ transformation / analysis
  ▼
Text processing
  │
  ▼
Cost amplification

Therefore:

The size of the input data does not necessarily represent the final cost of processing it.

That is one of the principles that STA seeks to study.

Trigger

The documented trigger for STA-002 is:

Long-press on link → context menu

In the whitepaper's catalog, STA-002 appears with an estimated CVSS of 3.7.

(CVSS 3.1: AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L)

This rating corresponds to a scenario of limited impact, requiring user interaction and with no persistence.

This is important because STA-002 should not be confused with later vectors in the research that present persistence or systemic impacts.

Persistence

A relevant characteristic of STA-002 is precisely its lack of persistence.

The behaviour is associated with the processing that occurs during interaction with the context menu.

There is no documented evidence that the payload is permanently stored and continues to trigger the behaviour in subsequent sessions.

This differentiates it from other vectors in the catalog where the contaminated input ends up stored in history, activity state, or other persistent structures.

Why is it interesting within STA?

At first glance, a problem limited to the processing associated with a context menu might appear to be simply an application issue.

But from the STA perspective, it is interesting because it shows a recurring characteristic:

An apparently ordinary input can traverse a processing surface without there being a limitation proportional to the cost it can generate.

The goal of STA is not to claim that all documented behaviours have exactly the same technical cause.

The goal is to identify an architectural pattern that appears when structured data traverses different layers of Android and its applications.

Furthermore, the research distinguishes between problems that are specific to an application and those where a framework characteristic can amplify their consequences.

That distinction is fundamental: the fact that a behaviour can propagate through the framework does not automatically mean that the original defect belongs to the framework.

Evidence

STA-002 is classified in the whitepaper as:

Tier B — Behavioral

This means that there is evidence based on observed behaviour, but that for this specific vector there is insufficient low-level evidence to classify it as Tier A.

In particular, STA-002 should not be presented as if a complete native stack trace existed that, by itself, demonstrated the entire causal chain.

This distinction is part of the STA methodology and is important for maintaining a clear separation between:

observed behaviour;
inferred mechanism;
mechanism demonstrated through low-level evidence.

Conceptual mitigation

Mitigation should occur before the data can generate a disproportionate cost.

For this type of surface, the general approach would be:

URL received
    │
    ▼
Size validation
    │
    ├── within limit ──► processing
    │
    └── outside limit ──► truncate / reject

The idea is not simply to detect specific strings or characters.

Defence must establish reasonable limits on the amount and complexity of data that an operation can process, especially when that operation runs synchronously.

STA-002 within the research map

STA-002 is important not because it is the highest-impact vector, but because it is part of the early observations that helped build the STA model.

Subsequently, vectors with much more severe characteristics appeared:

persistence;
state contamination;
resource exhaustion;
inter-process interaction;
impacts on system components;
and other forms of amplification.

These cases allowed us to study whether the observed behaviours could be understood as completely independent incidents or whether a common pattern existed.

Version v5 of the whitepaper documents 32 vectors within the Structured Text Amplification framework.

Why publish a Tier B vector?

Because the value of research does not depend exclusively on every observation having the same depth of evidence.

STA-002 serves to show how the model began to be constructed.

The fact that the vector has a Tier B classification does not automatically make it irrelevant. It means that the level of certainty must be expressed correctly.

Methodology matters as much as the finding.

Methodological note

STA-002 should not be presented as "an exploit that breaks Android".

It is much more accurate to describe it as:

A case where a structured input can provoke a disproportionate cost during an apparently normal interaction with a link and its context menu.

That formulation reflects the level of available evidence and avoids overstating conclusions that Tier B material does not, by itself, allow us to demonstrate.

And precisely for that reason, STA-002 makes a good starting point for this series.

Not all vectors have the same impact.
Not all have the same mechanism.
Not all have the same level of evidence.

What we are investigating is whether, behind them, a common pattern exists.

Structured Text Amplification

STA-002 is just the second chapter.

As we move through the catalog, vectors with very different mechanisms, surfaces, and impacts will appear.

The question will always be the same:

What happens when an apparently innocuous data item acquires a very different cost as it traverses the layers that process it?

That is the problem that Structured Text Amplification seeks to study.

Whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v6 (August 2026)

📌 About this series
This post is part of a series documenting the 32 vectors of Structured Text Amplification (STA). The aim of the series is to present each vector independently, with its mechanism, impact, and evidence, while maintaining traceability with the complete whitepaper.

Published:
- STA-001 — Context menu (this post)

Next posts (upcoming):
- STA-005 — WhatsApp
- STA-015-DL — Google Drive → SystemUI
- STA-017 — Cross-engine ANR
- And more...

Whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v5

Note: To maintain research traceability, each article in this series corresponds to a specific STA identifier and follows the same structure: mechanism, trigger, persistence, evidence, impact, mitigation, and confidence level. This way, the blog functions as a progressive public catalog of the STA research, while the whitepaper remains the consolidated technical reference.

Manuel García Peña (Lostmon)
Independent security researcher
lostmon.blogspot.com

STA: 48 Hours Later – The Chrome Correlation and the VRP Case Status

2026-08-01T05:27:46.320-07:00

STA: 48 Hours Later – The Chrome Correlation and the VRP Case Status

Published on July 31, 2026 · Post‑whitepaper update

🔗📊🧩 STA – Chrome Alignment Map
Shared architectural surfaces between the whitepaper and the July 2026 patches

These are not the same bugs. What we are seeing is a shared architectural surface:

STA-020 remains unpatched for four years.

Chrome patched its own side of the pipeline — Print Preview, Clipboard, Views, Skia, WebView, UI.
Android still has the same architectural pipeline exposed, with no public fixes for libminikin, SystemUI, or FragmentManager.restoreAllState().

The patches in Chrome exist. The same pipelines surfaces in Android remain open.

The Chrome fixes are public. Equivalent Android architectural surfaces remain publicly unpatched, based on the information available at the time of writing. This suggests that the underlying architectural bottlenecks identified by STA remain relevant and deserve further scrutiny.

📄 Full whitepaper: lostmon.blogspot.com
#STA #AndroidSecurity #Chrome

It has been 48 hours since the publication of the Structured Text Amplification (STA) whitepaper.

But the most interesting development happened over the last two days. Chrome’s July fixes harden several components that sit on the same processing paths STA describes (clipboard, print/preview, views/UI, WebView, document/Drive flows). Those are shared surfaces. The concrete Chrome CVEs are mostly memory-safety or validation bugs in the browser; STA documents missing limits and safe degradation on the Android framework side of related pipelines (Binder/SavedState, SystemUI, libminikin). Same corridor, different failure modes — and the framework side still has no public STA mitigations.

The Alignment Map: Chrome CVEs vs. STA

The table below correlates Chrome CVEs with the STA pipelines/vectors documented in the whitepaper. Confidence levels are indicated with traffic‑light markers:

🟢 High: The component is identical to or directly implements the same surface described in STA.
🟡 Medium: The component shares the same architectural pipeline, but the exact failure mode may differ.
⚪ Low: Conceptually related but not directly comparable.

Chrome CVE	Component	Potential STA Vector	Confidence	Rationale
`CVE-2026-17679`	Print Preview	STA-010	🟢 High	Both involve document/text processing before printing.
`CVE-2026-17766`	Clipboard	STA-011	🟢 High	Clipboard handling is explicitly part of the STA surface.
`CVE-2026-17670`	Views	STA-020	🟢 High	Views is the UI layer where much of the STA pipeline terminates.
`CVE-2026-17699`	Views	STA-020	🟢 High	Same architectural layer.
`CVE-2026-17702`	Skia	STA-017	🟢 High	Skia is part of the graphics pipeline downstream from libminikin.
`CVE-2026-17745`	Skia	STA-017	🟢 High	Same graphics pipeline.
`CVE-2026-17757`	Skia	STA-017	🟢 High	Same graphics pipeline.
`CVE-2026-15766`	Skia	STA-017	🟡 Medium	Another recent Skia issue in the same rendering path.
`CVE-2026-17698`	UI	STA-017 / STA-020	🟡 Medium	The UI layer processes structured text before rendering it.
`CVE-2026-17722`	WebView	STA-027 (general)	🟡 Medium	WebView participates in several propagation scenarios described in STA.
`CVE-2026-17690`	PDF	STA Document Pipeline	🟡 Medium	Document processing with structured input.
`CVE-2026-17803`	Save to Drive	STA Deep Link / Drive	🟡 Medium	Similar to the Drive → Chrome → Android propagation chain.

    Methodological note: I am not asserting that these CVEs are the same bugs as the STA vectors. I am identifying functional overlap in the processing pipelines (Views, Skia, Clipboard, Print Preview, WebView, UI) that intersect with the surfaces described in the whitepaper.
  

Google Knew, and Google Patched (but Not on Android)

What makes this table significant is not any single CVE, but the recurring pattern across the Chrome fixes from May and June 2026:

“Insufficient validation of untrusted input” in Print Preview
“Insufficient validation of untrusted input” in Clipboard
“Use after free” in Views
“Inappropriate implementation” in Skia
“Use after free” in UI / Input
“Object lifecycle issue” in WebView

Google patched its own browser to protect it from flaws that are structurally identical to those I documented in Android. Yet the July Android Security Bulletin (published July 6) contained no patches for any of these surfaces.

    The conclusion is clear: Google has the internal fix (AOSP CL 3989977). It patched Chrome. But the base platform — the one used by 2.5 billion devices — remains exposed.
  

Status of the VRP Case (A-477279924)

The VRP case A-477279924 remains open, blocked on internal dependency 477593694 (which, based on all available evidence, corresponds to AOSP CL 3989977). I have added the correlation table as a comment in that case, along with the following note:

“I am sharing this in case it helps accelerate internal triage or identifies surfaces that may still require backporting to the Android framework. This is intended as a triage aid, not as a claim of direct causation.”

Now the ball is in Google’s court. They have the fix. They patched Chrome. And they know exactly where the architectural overlap lies.

What This Means for Users

No public patch for Android as of today (July 31, 2026). The next security bulletin is August 3.
If Google does not include these fixes in August, the media pressure will intensify.
Blog de‑indexation (from ~200 pages to just 4 indexed) remains unexplained.

The Full Whitepaper

All technical details, stack traces, vector tables, and patch recommendations are available in the full whitepaper:

📄 Read the whitepaper

Resilience Gaps in Android IPC, SavedState and Text Layout

2026-07-30T01:08:12.950-07:00

Structured Text Amplification (STA)

Architectural Model + Full Technical Evidence of Resilience Gaps in Android IPC, SavedState and Text Layout

Full title	Structured Text Amplification (STA) — An Architectural and Technical Study of Text-Driven Resource Amplification Across the Android Ecosystem
Version	Unified Full — July 2026 (merges STA Architectural Study v6.0 + Resilience Gaps Technical Report)
Researcher	Manuel García Peña (Lostmon)
Vectors	32 documented (Class A IPC/SavedState + Class B UI-thread/libminikin)
Companies notified	Google · Meta · Microsoft · Mozilla · Opera · DuckDuckGo · Brave · Tor Project · Xiaomi · INCIBE (CNA Spain)
Also affected	Samsung (STA-023 series — documented)
Public disclosure	30 July 2026 — lostmon.blogspot.com

CLASS A — IPC State Amplification: absent safe fallback in FragmentManager.restoreAllState() and system services when serialized SavedState exceeds the Binder limit. Result: persistent crash loops.

CLASS B — Interaction Surface Amplification: absent defensive limits on synchronous URL/text processing in Android’s text layout engine (libminikin.so). Result: reproducible ANR across Chromium and Gecko engines.

Architectural frame: Both classes are concrete manifestations of the same higher-level pattern — Structured Text Amplification (STA).

Executive Summary
Threat Model
Testing Methodology
Research Context
Abstract
1. Structured Text Amplification — Architectural Model
2. Class A vs Class B — Concrete Mechanisms
3. Root Cause Detail
4. Affected Browsers (12 Confirmed)
5. Evidence Taxonomy
6. STA-017 — Cross-Engine ANR (Tier A Evidence)
6b. STA-027 — Edge Ask Copilot Deep Link Amplification (★NEW)
7. AOSP Commit Evidence
8. Field Evidence — Android 16
9. Complete Vector Catalog — 32 Vectors
9b. Impact Matrix
10. STA-005 — WhatsApp Variants
11. STA-015 Series — SystemUI Vectors
12. STA-019 — Firefox Four Failure Modes
13. STA-020/021 — Chrome/Edge/Brave Address Bar
14. STA-022 — DuckDuckGo
15. Cross-Platform Validation — iOS
16. Recommended Fixes (Framework + Application)
17. Vendor Notification Status
18. Disclosure Timeline
19. Glossary
20. Limitations and Future Work
21. Conclusion
References
Appendix I — External Corroboration
Appendix II — Vendor Conduct & Acknowledgements: Xiaomi

Executive Summary

This whitepaper documents Structured Text Amplification (STA), an architectural pattern in which valid structured textual input (URLs, deep links, drafts, Intent extras) propagates through Android framework layers and progressively amplifies computational cost or state size until stability limits are exceeded.

Five key findings:

An internal fix for parts of the Class A root cause exists but is not public. Google’s LargePayloadSupport (AOSP CL 3989977) and androidx.savedstate 1.5.0 address part of the Class A root cause; the July 2026 Android Security Bulletin contained no public patches for any STA vector.
32 reproducible vectors across Class A (IPC/SavedState crash loops) and Class B (libminikin ANR), confirmed on production devices running Android 13–16.
Independent vendor validation. Xiaomi reproduced, confirmed and rewarded a persistent HyperOS vector (STA-015b). INCIBE (CNA Spain) reviewed technical reports and referred the case to MITRE (CNA Top-Level Root for the Google ecosystem) for CVE assignment.
Highest impact: STA-015-DL (CVSS 8.6). A single click on a Google Drive HTML link can escalate to a SystemUI crash loop requiring a hard reboot. Scope is Changed (browser is delivery vehicle; SystemUI is the target).

Cross-engine, cross-vendor. The same libminikin blocking path appears in Chromium and Gecko; the same persistence pattern appears in WhatsApp, Threads, Firefox, Opera, DuckDuckGo, Edge Ask Copilot and core system services.

Primary recommendation: Framework-level hard length thresholds in libminikin and safe degradation (try/catch + discard) in FragmentManager / TaskPersister / SystemUI restore paths. Application-level URL and draft size caps are necessary but insufficient defense-in-depth.

Threat Model

	Class A — IPC / SavedState	Class B — libminikin / UI thread
Attacker	Remote (crafted link, Drive HTML, deep link) or local (paste large text)	Remote (crafted URL/link) or local (long-press, focus address bar)
Victim	Android 13–16 users of WhatsApp, Threads, browsers, SystemUI, OEM skins	Any app rendering long structured text via TextView / Compose / context menu
Prerequisites	One click or paste; no special privileges	One click, long-press or focus event; no special privileges
Goal	Persistent DoS (crash loop until data clear / reboot)	Transient DoS (ANR 5–16 s); can become persistent if combined with history/TaskPersister
Impact scope	Single app → shared inbox → SystemUI (device UI)	Browser / app UI thread; can cascade into SystemUI on some OEMs

Assumptions: Attacker can deliver a syntactically valid but oversized structured payload (URL, draft, Intent extra). No memory corruption or code execution is required. The attack relies solely on missing defensive limits and missing safe-degradation paths.

Testing Methodology

Research was conducted on six physical production devices running stock or OEM firmware (no custom ROMs, no root required for primary evidence). Cross-OEM validation used devices shared by the independent research community (Xiaomi, Samsung, OPPO, OnePlus, Pixel).

Google Pixel 7 (Android 13–15 stock AOSP-derived)
Xiaomi Redmi Note 14 5G (HyperOS 3.0 / Android 16) — primary field evidence device
OPPO A78, OnePlus 11, Lenovo Tablet, and additional devices covering Android 9–16

A substantial portion of framework path analysis was performed by reading public AOSP sources from a phone browser (no traditional multi-monitor lab). Bugreports and ANR traces were captured on-device where available. Google VRP rewarded the Binder/IPC research area ($250); Xiaomi independently confirmed and rewarded a HyperOS vector ($300 via HackerOne).

Tools and artefacts:

Bugreport / full bugreport ZIPs (DROPBOX SYSTEM APP CRASHES, ANR traces, tombstones)
chrome://crashes report IDs (uploaded to Google infrastructure)
Native stack unwinding from ANR traces (libminikin.so BuildId confirmed)
AOSP source inspection for FragmentManager, TaskPersister, LineBreakOptimizer

Generalizations to “all Android OEMs” or “all versions” are inferences from this sample, not exhaustive enumeration. Behaviour can vary with OEM patches, available memory and security bulletin level. iOS was used as a negative control (same payloads do not reproduce the Android-specific failures).

Research Context

This work is independent security research conducted over approximately four years (observations from 2022; formal STA framing and expanded evidence through July 2026). It was not performed in a traditional multi-monitor laboratory environment.

Primary conditions:

Lead researcher: Manuel García Peña (Lostmon), independent researcher; president of BojosXtu (mental-health support association).
Primary device: Xiaomi Redmi Note 14 5G (HyperOS 3.0 / Android 16) — field bugreports, SystemUI crash statistics, and native ANR stacks were captured on this handset under normal use and controlled reproduction.
Analysis setup: A substantial share of AOSP path reconstruction (TextView → StaticLayout → LineBreaker → libminikin; FragmentManager / TaskPersister / SystemUI) was done by reading public Android source in a phone browser, following call chains function by function when concentration allowed.
Cross-OEM validation: Additional devices (Pixel, Samsung, OPPO, OnePlus and others) were made available through the independent research community so that behaviour could be checked beyond a single manufacturer.
Vendor outcomes (selected): Google Android VRP rewarded the Binder/IPC research area ($250, case A-477279924). Xiaomi independently reproduced a persistent HyperOS vector and awarded a bounty via HackerOne ($300). Other vendors received reports with mixed classifications (see Section 17–18).

The technical claims in this whitepaper stand on bugreports, native stacks, measured Bundle sizes, and public AOSP inspection. The research context is included so readers understand the constraints under which the evidence was gathered — not as a substitute for that evidence.

Narrative account of the investigation (Spanish): Desafiar Android desde el sofá y un smartphone (17 July 2026). Timeline and related technical posts are listed under References.

Abstract

Android applications continuously process structured textual input originating from web pages, messaging platforms, documents, deep links, accessibility services, inter-process communication (IPC) and user-generated content.

Over approximately four years of independent analysis, 32 reproducible attack vectors were documented across multiple Android subsystems. Although these vectors differ in entry points, affected applications and observable behaviour, they consistently exhibit a common architectural characteristic: structured textual input propagates through several framework layers while progressively amplifying computational cost, memory pressure or internal application state until stability boundaries are exceeded.

This recurring behaviour is defined as Structured Text Amplification (STA).

STA is not a single vulnerability. It is an architectural resource-amplification pattern. It materialises in two primary concrete forms:

Class A — IPC / SavedState Amplification: when serialized state exceeds the Binder transaction limit (1 048 576 bytes), Android has no safe degradation path. The TransactionTooLargeException propagates uncaught, the app (or SystemUI) crashes, and the same oversized state is re-persisted → permanent crash loop.
Class B — Interaction Surface Amplification: algorithmic complexity inside Android’s native text layout engine (libminikin.so) produces reproducible ANRs across Chromium and Gecko when processing oversized but syntactically valid structured URLs/text.

The most severe chain (STA-015-DL) escalates from a single click on a Google Drive HTML link to a SystemUI crash loop requiring a hard reboot (CVSS 8.6). The same underlying amplification principles appear in WhatsApp, Threads, Firefox, Opera, DuckDuckGo, Brave, Samsung Internet and core framework components.

This unified whitepaper presents both the architectural model that explains the common pattern and the complete technical evidence (native stack traces, production bugreports, AOSP commit analysis, CVSS scores and vendor responses) that substantiates it.

1. Structured Text Amplification — Architectural Model

Fact vs. interpretation: The STA model is an architectural interpretation proposed by the researcher to explain recurring patterns observed across multiple vectors. Empirical evidence (native stack traces, production bugreports, measured Bundle sizes, vendor confirmations) is presented in the corresponding technical sections. Amplification factors and the unified model itself should be treated as analytical conclusions, not as factory-documented behaviour.

1.1 Formal Definition

Structured Text Amplification (STA) is an architectural resource amplification pattern in which structured textual input traverses multiple software layers, causing progressively increasing computational cost, memory consumption or state propagation that may ultimately exceed the stability limits of one or more downstream components.

Unlike a traditional software vulnerability, STA does not represent a single implementation defect or memory corruption. The amplification emerges from the interaction between multiple independent components that sequentially transform, validate, serialize, deserialize, render, persist or redistribute the same logical data. Each component may operate correctly in isolation; the cumulative effect becomes significantly larger than anticipated by any individual subsystem.

1.2 Recurring Characteristics

Property	Description
Structured Input	Hierarchical or encoded textual information (URLs, HTML, JSON, Intent extras, Markdown…), not arbitrary binary data.
Multi-stage Processing	The same logical content traverses multiple independent framework layers.
Progressive Amplification	Processing cost increases at successive stages.
Shared Infrastructure	Unrelated applications reuse identical Android framework components (libminikin, FragmentManager, TaskPersister, SystemUI…).
Non-linear Behaviour	Resource consumption frequently disproportionate to input size.
Cross-component Impact	Failures appear far from the original entry point (e.g. browser click → SystemUI crash).

1.3 General Amplification Pipeline

Structured Input (URL / HTML / Intent / Clipboard / Deep Link)
        ↓
Parser / Validation
        ↓
Framework APIs
        ↓
Binder IPC
        ↓
Rendering Engine (TextView → StaticLayout → LineBreaker → libminikin)   ← Class B
        ↓
Layout / Compose
        ↓
State Persistence (TaskPersister / SavedStateRegistry)                   ← Class A
        ↓
SystemUI / OEM recovery
        ↓
Observed Failure (ANR / Crash Loop / Hard Reboot)

2. Class A vs Class B — Concrete Mechanisms

Table 1. Comparison of the two concrete amplification mechanisms under the STA model. Rows marked “Observed factor” and “Result” are empirical; “Primary fix owner” is a proposed responsibility assignment.

	Class A — IPC / SavedState Amplification	Class B — Interaction Surface Amplification
Mechanism	SavedState serialization → Bundle → Parcel → Binder > 1 MB	Synchronous text layout on UI thread (libminikin line breaking)
Resource exhausted	Binder transaction buffer (1 048 576 bytes)	Main thread CPU time (ANR threshold ~5 s)
Amplification driver	Fragment nesting depth + metadata (architectural)	URL character composition (# / % €) (content-driven)
Observed factor	×2.8 to ×20.6 (WhatsApp field measurement)	10–20× multiplier before O(n²)/blocking
Result	TransactionTooLargeException → permanent crash loop	Main thread block → ANR (5–16 s)
Persistence	Yes — until data cleared or reboot	No (unless combined with history / TaskPersister)
Primary fix owner	Google / AOSP (FragmentManager + SystemUI + TaskPersister)	Google / AOSP (libminikin) + browser vendors (defense-in-depth)

Two distinct amplification models that share a common root-cause category (absent input validation before expensive operations), but are not reducible to a single mathematical model. The fix for one does not address the other.

3. Root Cause Detail

This section separates documented platform behaviour (Binder limit, missing catch in restore paths, measured Bundle sizes, native stacks) from the researcher’s interpretation (STA as a unifying pattern) and from proposed mitigations (Section 16).

3.1 What IS “Working as Intended”

The 1 MB Binder limit is intentional. An app storing large data in a Bundle and hitting the limit is a documented consequence of misusing the mechanism — not a vulnerability by itself. This report does not claim the Binder limit or Fragment nesting are bugs.

3.2 The Real Problem — Absent Safe Fallback (Class A)

When FragmentManager.restoreAllState() encounters a Bundle exceeding the Binder limit, Android has no safe degradation mechanism. The TransactionTooLargeException propagates uncaught, the process crashes, and the same oversized state is persisted to disk for the next launch → permanent crash loop the user cannot escape without clearing application data.

// Current Android behaviour — no safe fallback
void restoreAllState(Bundle savedState) {
    // No try-catch. TransactionTooLargeException propagates uncaught.
    // Same oversized state re-persisted → crash loop on next launch.
    fragmentManager.restoreState(savedState);
}

// Recommended — safe degradation
void restoreAllState(Bundle savedState) {
    try {
        if (isBundleOverLimit(savedState)) {
            Log.e(TAG, "SavedState over limit — discarding for safe restart");
            return;  // clean start — no crash loop
        }
        fragmentManager.restoreState(savedState);
    } catch (TransactionTooLargeException e) {
        // safe degradation: app starts as if first launch
    }
}

3.3 Empirical Amplification — WhatsApp Android 15 (×20.6)

W/Bundle: childFragmentManager [L1]  size=1,636,412
W/Bundle: childFragmentManager [L2]  size=1,614,072
W/Bundle: childFragmentManager [L3]  size=1,603,852
W/Bundle: registryState             size=  479,948
W/Bundle: compose_text (origin)     size=   80,484  ← input data
W/Bundle: TOTAL                     size=1,661,088  ← +58% over Binder limit
// Binder limit: 1,048,576 bytes · Overflow: +612,512 bytes · Factor: ×20.6

Input	Fragment depth	Bundle	Factor	Exceeds limit
10,000 bytes	2 levels	~28,000	×2.8	No
50,000 bytes	4 levels	~275,000	×5.5	No
80,000 bytes	5 levels+meta	~1,021,000	×12.8	Near
82,431 bytes	5 levels+meta	~1,124,352	×13.6	YES
80,484 bytes	5 lvls+Meta AI	~1,661,088	×20.6	YES +58%

3.4 Class B — libminikin Algorithmic Amplification

Characters with special meaning in URLs force the line-breaking algorithm to evaluate many more break candidates:

# — creates a logical boundary, doubling break decisions
/ — each slash adds a candidate break point
% — expands UTF-8 to UTF-16 and fragments the string
€ — ambiguous line-break properties force algorithm to explore both options

// Combined pattern: [PayLoad]
// Multiplies algorithmic cost by 10-20x BEFORE O(n²) or greedy blocking applies

4. Affected Browsers (12 Confirmed)

Engine family	Browsers
Chromium-based	Google Chrome, Microsoft Edge, Microsoft Bing, Opera Browser, DuckDuckGo Browser, Brave Browser, Samsung Internet
Gecko-based	Mozilla Firefox, Firefox Focus, Firefox Nightly, Tor Browser
Proxy-based	Opera Mini (independently reproduced)

Browser	Engine	Confirmed vector(s)	Notified
Google Chrome	Chromium	STA-001, STA-017 (Tier A), STA-020	Yes — Google VRP
Microsoft Edge	Chromium	STA-017 (Tier A), STA-020	Yes — MSRC
Microsoft Bing	Chromium (Sapphire)	STA-013, STA-015-DL	Yes — MSRC
Opera Browser	Chromium	STA-016, STA-017	Yes
DuckDuckGo Browser	Chromium	STA-022, STA-022b	Yes — HackerOne
Brave Browser	Chromium	STA-021, STA-017	Yes — HackerOne
Samsung Internet	Chromium	STA-023/023b/023c	Documented, not formally notified
Mozilla Firefox	Gecko	STA-019a/b/c/d, STA-017	Yes
Firefox Focus / Nightly	Gecko	STA-019 family	Yes — via Mozilla
Tor Browser	Gecko	STA-017, STA-019a/b/c	Yes
Opera, Opera Mini	Proxy-based	STA-016	Yes — via Opera

5. Evidence Taxonomy

Tier	Criteria	Vectors
Tier A — Confirmed	Full stack trace + exception + Bundle analysis	STA-005/005b/005c/005d, STA-006, STA-007, STA-009, STA-010/010b, STA-011, STA-012/012e, STA-015, STA-015b, STA-015-DL, STA-016, STA-017 Chrome+Firefox, STA-018, STA-019a/b/c/d, STA-022
Tier B — Behavioral	Crash/ANR observed; mechanism inferred by analogy	STA-001, STA-003, STA-004, STA-008, STA-013, STA-020, STA-021, STA-022b, STA-023/023b/023c
Tier C — Mitigated	Tested; no crash — positive control	YouTube (all scenarios)

6. STA-017 — Cross-Engine ANR: Tier A Evidence

Evidence (observed): STA-017 upgraded to Tier A for BOTH Chrome (Chromium) AND Firefox (Gecko). Blocking call: libminikin.so::LineBreakOptimizer::computeBreaks. This is an Android system library — not Chromium or Gecko code.

6.1 Chrome — Full Native Stack Trace (bugreport 2026-05-24)

Listing 1. Native main-thread stack from production bugreport (Xiaomi Redmi Note 14 5G, Android 16).

Device: Xiaomi Redmi Note 14 5G · HyperOS 3.0 · Android 16. Chrome versionCode 777818033. Two ANR files, identical stack.

// ANR 1 — 2026-05-24 13:38:44 — Chrome PID 3533
// Waited 5000ms for MotionEvent — ChromeTabbedActivity

"main" prio=5 tid=1 Native   ← UI THREAD BLOCKED

native: minikin::getPrevWordBreakForCache     libminikin.so
native: minikin::LayoutCacheKey::LayoutCacheKey  libminikin.so
native: minikin::LayoutCache::getOrCreate     libminikin.so
native: minikin::StyleRun::getLineMetrics     libminikin.so
native: minikin::MeasuredText::getLineMetrics libminikin.so
native: minikin::LineBreakOptimizer::computeBreaks  ← O(n²) on long URL
native: minikin::breakLineOptimal             libminikin.so
native: android::nComputeLineBreaks           libhwui.so

at android.graphics.text.LineBreaker.nComputeLineBreaksWithHelperIndex (Native)
at android.text.StaticLayout.generate (StaticLayout.java:970)
at android.text.StaticLayout$Builder.build (StaticLayout.java:550)
at android.widget.TextView.makeSingleLayout (TextView.java:11263)
at android.widget.TextView.onMeasure (TextView.java:11486)
at android.widget.ListView.onMeasure (ListView.java:1321)
at org.chromium.chrome.browser.contextmenu.ContextMenuListView.onMeasure
   ↑ CHROME CONTEXT MENU — long-press on oversized URL link
at android.view.ViewRootImpl.performTraversals
at android.app.ActivityThread.main

6.2 Firefox — Full Native Stack Trace (bugreport 2026-06-12)

Process: org.mozilla.firefox (PID 3506). Activity: ExternalAppBrowserActivity. Duration: 16,006 ms. Trigger: REAL Gmail link (not a controlled test).

// org.mozilla.firefox PID 3506 — ANR 2026-06-10 19:42:19 — 16,006ms

"main" prio=5 tid=1 Native   ← UI THREAD BLOCKED 16,006ms

native: minikin::LayoutCacheKey::LayoutCacheKey+120  libminikin.so
native: minikin::LayoutCache::getOrCreate             libminikin.so
native: minikin::LayoutPieces::getOrCreate            libminikin.so
native: minikin::StyleRun::getLineMetrics             libminikin.so
native: minikin::MeasuredText::getLineMetrics         libminikin.so
native: minikin::LineBreakOptimizer::computeBreaks+1752  ← O(n²)
native: minikin::breakLineOptimal+476                 libminikin.so
native: android::nComputeLineBreaks+356               libhwui.so

at android.graphics.text.LineBreaker.nComputeLineBreaksWithHelperIndex (Native)
at android.text.StaticLayout.generate / Builder.build
at android.widget.TextView.onMeasure
at org.mozilla.fenix.customtabs.ExternalAppBrowserActivity URL rendering

Attribute	Chrome (Chromium)	Firefox (Gecko)
Native entry	libminikin::LineBreakOptimizer::computeBreaks	libminikin::LineBreakOptimizer::computeBreaks
ANR duration	5,000ms+ (threshold)	16,006ms (3× longer)
Trigger	Controlled test	REAL Gmail email link
Tier	Tier A	Tier A

6.3 Additional Entry Points Confirmed (June 2026)

Bugreport	App	Trigger	minikin function	Entry point
2026-05-24	Chrome	Long-press on link	breakLineOptimal	ContextMenuListView.onMeasure
2026-06-10	Firefox	Real Gmail link	breakLineOptimal	ExternalAppBrowserActivity
2026-06-24	Edge	SystemUI crash → omnibox re-layout	breakLineOptimal	OmniboxSuggestionsContainer
2026-06-28	Google App	android.intent.action.TRANSLATE	breakLineGreedy	DynamicLayout$ChangeWatcher.onTextChanged

Critical: breakLineGreedy is also vulnerable to blocking on long text. The naive “switch to greedy” fix is incomplete. A hard length threshold before either algorithm runs is required.

Reproduction steps (STA-017 — Chrome context menu)

Create an HTML page containing a hyperlink whose href is a syntactically valid URL of approximately 80–120 KB with high density of #, / and % characters.
Host or open the page in Chrome on Android 13–16.
Long-press the link until the context menu appears.
Observe main-thread ANR (typically ≥ 5 000 ms). Capture via adb bugreport; native stack shows libminikin::LineBreakOptimizer::computeBreaks.

Equivalent behaviour has been observed with real-world Gmail links (Firefox, 16 006 ms) and SystemUI-triggered omnibox re-layout (Edge).

6b. STA-027 — Edge Ask Copilot Deep Link Amplification ★NEW

STA Identifier	STA-027
Category	Intent / Compose Navigation Amplification (Class A + Class B)
Affected Component	Microsoft Edge Ask Copilot (com.microsoft.copilotn)
Impact	Crash / navigation failure via deep link with oversized initialText
CVSS 3.1	6.5
Persistence	Yes (until data cleared / conversation state reset)
Tier	A ★NEW

STA-027 demonstrates simultaneous Class A and Class B behaviour inside Microsoft Edge’s Ask Copilot deep-link navigation path. An oversized structured payload supplied in the initialText query parameter is accepted by the deep-link handler and forwarded into Jetpack Compose Navigation. The resulting route string exceeds the expected structure of the NavGraph, producing an uncaught IllegalArgumentException.

java.lang.IllegalArgumentException: 
navigation destination com.microsoft.copilotn.features.deeplink.navigation.routes.HomeNavRoute.ChatNavRoute?
conversation_id=null&private_mode_chat=false&conversationTitle=null&initialText=ULTRA%20DESTRUCTIVE%20LAYOUT%20ATTACK...
is not a direct child of this NavGraph
at androidx.navigation.compose.c.a (NavGraph.kt:356)
at com.microsoft.copilotn.features.deeplink.navigation.routes.HomeNavRoute.ChatNavRoute

The oversized initialText value simultaneously:

Triggers expensive text layout / measurement work (Class B amplification path) when the destination attempts to render or pre-process the parameter.
Breaks Compose Navigation graph resolution because the fully-expanded route is no longer recognised as a direct child of the NavGraph (Class A style state / routing failure).

Remote activation: Unlike STA-017 (which requires a long-press or local UI interaction inside an already-open browser), STA-027 can be triggered remotely by a malicious deep link that opens Edge Ask Copilot with a crafted initialText parameter. No prior interaction with the Copilot UI is required beyond following the link.

Reproduction steps (STA-027)

Construct a deep link targeting Microsoft Edge Ask Copilot that includes an oversized initialText query parameter (structured text large enough to expand the Compose navigation route beyond NavGraph expectations).
Open the link from another app or browser (ACTION_VIEW / deep link).
Observe uncaught IllegalArgumentException from androidx.navigation.compose (NavGraph.kt) when resolving HomeNavRoute.ChatNavRoute.
Capture logcat / bugreport; confirm stack includes the navigation destination containing the expanded initialText.

7. AOSP Commit Evidence

7.1 Chromium Commit 3e62ece6 — LargePayloadSupport (May 7, 2026)

Commit: chromium.googlesource.com/chromium/src/+/3e62ece6

Commit message (verbatim):

“Implements ResultReceiver for large payloads in DigitalCredentialsPresentationDelegate to avoid TransactionTooLargeException when responses exceed Binder IPC limits. This aligns with updates in Jetpack libraries (AOSP CL 3989977) where large payloads are passed via file descriptors.”

1. Explicitly names TransactionTooLargeException — same as ALL Class A vectors.
2. References AOSP CL 3989977 (LargePayloadSupport) — internal, not public.
3. Fix: file descriptors instead of Binder.
4. Google named this: LargePayloadSupport.

Related historical trackers:

Google Issue Tracker 40879254 (2022): issuetracker.google.com/issues/40879254
Google Issue Tracker 40268979 (Samsung 2023): issuetracker.google.com/issues/40268979
AOSP minikin repository: android.googlesource.com/platform/frameworks/minikin/

7.2 androidx.savedstate 1.5.0 — Bug #425919375

Date	Event	T+ VRP
Jun 19, 2025	Bug #425919375 created — SavedState serialization	— (inactive 7 months)
Jan 20, 2026	VRP submission to Google Android VRP	T+0
Feb 10, 2026	Google responds for FIRST time	T+21 days
Mar 4, 2026	Commit: Support generic serialization for SavedState	T+43 days
Mar 11, 2026	Bug Fixed — savedstate 1.5.0-alpha01	T+50 days
May 19, 2026	savedstate 1.5.0 STABLE — CBOR/JSON decoupled from Binder	T+119 days

savedstate 1.5.0 decouples SavedState from the Bundle/Binder pipeline — an architectural fix for part of the Class A root cause. Bug inactive 7 months. Reactivated 21 days after VRP. Fixed in ~30 days. Google framed it as “multiplatform support” — no security motivation mentioned publicly.

7.3 libminikin design debt — multi-file pipeline (AOSP forensic summary)

Independent AOSP source review identifies a systemic design gap across multiple minikin files: no length validation before expensive line-breaking or layout work. Oldest relevant code paths date to 2013. Key files:

File	Since	Issue	Function
FontFamily.cpp	2013	Null / closest-match edge cases	getClosestMatch()
Layout.cpp	2013	Long text processed without cache guard	doLayoutWord()
OptimalLineBreaker.cpp	2015	Knuth-Plass O(n²) without input limit	computeBreaks()
GreedyLineBreaker.cpp	2017	Nested loops; worst-case costly	processLineBreak()
LineBreaker.cpp	2018	Chooses Optimal/Greedy with no size check	breakIntoLines()
LayoutCache.h	2018	Over CHAR_LIMIT_FOR_CACHE → direct process (no cache)	getOrCreate()

LineBreaker::breakIntoLines()     — no textBuffer.size() guard
        ↓
Optimal / Greedy breaker          — O(n²) / nested work on long input
        ↓
Layout::doLayoutWord()
        ↓
LayoutCache::getOrCreate()        — long ranges bypass cache → full work
        ↓
HarfBuzz shaping
        ↓
UI thread blocked (5–16 s ANR)

Public Issue Tracker history (examples): #161830416, #167014931, #188985643, #40268980 / Chromium 1447465 (Samsung engineer ANR), #477202817 (Won’t Fix), #524288518 (out of scope), #531319203 (related pattern). Structural length limits were not applied across the pipeline as of the July 2026 bulletin, despite the existence of internal Google work addressing an adjacent root cause (AOSP CL 3989977, LargePayloadSupport).

Detail: libminikin: 10 años de vulnerabilidad · Algorithmic DoS en libminikin.so

7.4 Post-Disclosure Architectural Convergence (AndroidX, August 2026)

Scope note. The commit discussed below is not claimed to fix any STA vector documented in this paper. It is presented solely as independent public evidence that Google engineers are actively mitigating a related architectural failure class — oversized structured state crossing Binder-backed SavedState boundaries — while the specific STA root causes in libminikin.so and FragmentManager.restoreAllState() remain publicly unpatched as of this disclosure.

7.4.1 AndroidX commit: "Fix transaction too large crashes" (PdfView)

Commit: android.googlesource.com/platform/frameworks/support/+/8882927e7d41e678c6f03f50d4bd5950e7dc6c47

The commit message states, verbatim:

Fix transaction too large crashes

When a user selects content across a large range of pages (e.g., 500 pages),
the serialized SelectionModel exceeds 1.2 MB. Serializing this into
onSaveInstanceState triggers an unhandled TransactionTooLargeException over
the kernel Binder IPC driver right when the app goes into the background.

This change fixes the crash and improves selection lifecycle handling:
- Distinguishes in-memory screen rotation (Activity.isChangingConfigurations)
  from process backgrounding in PdfView.onSaveInstanceState(). During
  rotation, the full selection is preserved in memory for instant
  restoration without flicker.
- When backgrounding across Binder IPC, only lightweight start and end
  boundary anchor points [are serialized, rather than the full selection].

This fix is scoped to androidx.pdf.viewer.PdfView — a specific AndroidX Jetpack component for PDF rendering and text selection — not to FragmentManager or any general-purpose SavedState path. The mitigation strategy is nonetheless directly relevant: rather than validating or truncating the oversized payload, the fix avoids serializing the full object across the Binder boundary at all, replacing it with lightweight boundary markers and reconstructing full state asynchronously post-restart. This is architecturally distinct from — but consistent with — the safe-fallback approach proposed in Section 19 of this paper for FragmentManager.restoreAllState().

7.4.2 Binder transaction size heuristic remains a first-order constraint

Android's Binder implementation continues to enforce a payload-size heuristic ahead of the hard 1MB transaction ceiling. Relevant source: android_util_Binder.cpp (platform/frameworks/base), which historically has included a warning/limit threshold in the 200KB range ahead of the 1MB hard failure — illustrating that Binder payload size remains an actively monitored reliability constraint at the platform level, independent of this paper's findings.

7.4.3 What this convergence does and does not establish

Confirmed fixed by this commit	`androidx.pdf.viewer.PdfView` text-selection state crossing Binder during backgrounding
Not fixed by this commit	`libminikin.so` (`LineBreakOptimizer`, `breakLineOptimal()`, `breakLineGreedy()`) — no public commit as of this disclosure (Section 7.3)
Not fixed by this commit	`FragmentManager.restoreAllState()` — no public safe-fallback as of `androidx.fragment` 1.9.0-rc01 (29 Jul 2026)

The PdfView fix demonstrates that Google engineers, independently of this research, identified and mitigated one instance of the same general architectural pattern this paper calls Structured Text Amplification Class A: oversized structured object → SavedState serialization → Binder IPC → TransactionTooLargeException → crash. This is offered as circumstantial support for treating STA as a systemic reliability pattern recurring across independent AndroidX components, rather than as a claim that any STA vector in this paper has been patched.

8. Field Evidence — Android 16, Production Device

8.1 STA-015 — 85 SystemUI Crashes in 4 Days (bugreport 2026-05-26)

Device: Xiaomi Redmi Note 14 5G · HyperOS 3.0.3.0 · Android 16. Crash loop reproduced spontaneously during normal device use.

// SystemUI crash at bootstrap
android.os.BadParcelableException: Failure retrieving array; only received 1 of 4
  at android.content.pm.BaseParceledListSlice.<init>(BaseParceledListSlice.java:111)
  at android.window.ITaskOrganizerController$Stub$Proxy.registerTaskOrganizer(...)
  at android.window.TaskOrganizer.registerOrganizer(TaskOrganizer.java:76)
  at com.android.wm.shell.sysui.ShellInit.init(...)  ← crash at bootstrap
Caused by: android.os.DeadObjectException: Transaction failed on small parcel

Total SystemUI crashes	85 entries — 4 days (May 23–26, 2026)
Fastest loop	16 crashes in 92 seconds
Min survival time	374 ms — crashes before any UI renders
Android version	Android 16 — first confirmed reproduction

8.2 STA-015b / STA-015-DL — HyperOS Auto-Re-Trigger (12-step flow)

STEP 1:  User opens HTML from Google Drive, clicks link
STEP 2:  Browser receives malformed URL via VIEW Intent
         callingPackage=com.google.android.apps.docs (certified by Android OS)
STEP 3:  libminikin O(n²) ANR in browser
STEP 4:  URL corrupts TaskPersister state on disk
STEP 5:  SystemUI reads corrupt state → BadParcelableException → CRASH
STEP 6:  Android auto-restarts SystemUI
STEP 7:  OEM Task State Interactor (HyperOS OEM) subscribes Flow:
         getFocusedRootTaskInfo() → reads SAME corrupt disk state → CRASH AGAIN
STEP 8:  Crash loop → Android forced to clear SystemUI data → LOCKSCREEN
STEP 9:  User enters PIN/pattern/fingerprint
STEP 10: Android restores session → BROWSER RETURNS TO FOREGROUND
STEP 11: OEM Task State Interactor reads task state → browser is active
         → reads still-corrupt TaskPersister state → SECOND CRASH LOOP
STEP 12: NO ADDITIONAL USER ACTION REQUIRED — crash re-triggers automatically

// Recovery: force reboot + clear browser data

STA-015-DL on HyperOS re-triggers AUTOMATICALLY after lockscreen unlock. No additional user action is required after the initial click. A single reboot may not be sufficient if the browser relaunches with the same corrupt state.

9. Complete Vector Catalog — 32 Vectors

Table 2. Documented STA vectors. CVSS scores are researcher estimates (see methodology note under the table). Tier A = full stack / exception evidence; Tier B = behavioural / analogy.

ID	App / Component	CVSS	Persist	Tier
STA-015-DL	Google Drive + Any Browser → SystemUI crash loop (hard reboot)	8.6	Reboot only	A
STA-018	Google Drive + Print Service + SystemUI — ANR cascade	7.5	Until reboot	A
STA-010	SystemUI / Print Service — Drive → local printer	7.2	Until reboot	A
STA-011	SystemUI / Clipboard — paste preview crash	7.2	Until reboot	A
STA-015	WindowManager Shell / RecentTasksController	7.2	Auto-restart→lockscreen	A
STA-015b	HyperOS / OEM Task State Interactor (Xiaomi OEM)	7.2	Auto-recovery	A
STA-012	Threads (Meta) — deep link /search?q=[payload]	7.1	Permanent (pm clear)	A
STA-012e	Threads via WhatsApp — HTML/WebView → Threads deep link	7.1	Permanent (pm clear)	A
STA-019a	Firefox — ClipboardManager DeadSystemException on address bar focus	6.8	Every focus event	A
STA-008	System services — sync IPC call + oversized payload → ANR	6.8	Until app killed	B
STA-005d	WhatsApp deep link api.whatsapp.com/send?text=[payload]	6.8	Possible	B
STA-017	6+ browsers — long-press URL → libminikin ANR (Chrome+Firefox Tier A)	6.5	No	A
STA-027	Microsoft Edge Ask Copilot — deep link initialText NavGraph crash ★NEW	6.5	Yes	A ★
STA-005	WhatsApp — paste large text in chat compose field	6.5	Permanent	A
STA-005b	WhatsApp Business — all agents in shared inbox	6.5	Permanent (all agents)	A
STA-005c	WhatsApp + Meta AI — oversized draft in AI chat	6.5	Permanent (entire app)	A
STA-006	Google App — Select text → Translate	6.5	Permanent	A
STA-007	Google Drive — invisible PDF → Select All → Translate	6.5	Permanent	A
STA-009	Google Drive — large DOCX → Print Preview	6.5	Permanent	A
STA-010b	Google Play Services — Drive → cloud printer	6.5	Until app closed	A
STA-016	Opera Browser — onResume → RuntimeException: Failure from system	6.5	Permanent	A
STA-019d	Firefox — address bar TextLayout lineIndex OOB	6.5	Every focus event	A
STA-020	Chrome + Edge — address bar history pipeline ANR	6.5	Until history cleared	B
STA-021	Brave Browser — address bar ANR / rendering anomaly	6.5	Until history cleared	B
STA-022	DuckDuckGo — URL_EXTRA_ARG 920KB in Fragment args (965KB parcel)	6.5	Until tab closed	A
STA-022b	DuckDuckGo — history suggestion pipeline ANR (cross-session)	6.5	Until history cleared	B
STA-013	Microsoft Bing — contaminated address bar history crash	6.0	Until data cleared	B
STA-019b	Firefox — SearchDialogFragment IllegalStateException	6.0	Every focus event	A
STA-019c	Firefox — Compose TextLayout lineIndex OOB (Jetpack Compose)	6.0	Every focus event	A
STA-023/b/c	Samsung Internet — background tab / Share / tab group freeze	5.4	No	B
STA-004	Google Maps — oversized geo: URI	4.8	Partial	B
STA-001/003	Chrome / Browsers — long-press context menu, Share link	3.7	No	B

CVSS methodology note: CVSS 3.1 scores are researcher estimates. For STA-015-DL the vector used is AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:N/A:H (8.6). Other scores follow analogous reasoning (remote or local delivery, user interaction, availability impact, and whether scope changes to SystemUI). Scores are subject to vendor revision.

9b. Impact Matrix (Qualitative)

Table 3. Qualitative impact summary by vector group (researcher assessment; complements CVSS in Table 2).

Vector group	Availability	Persistence	User interaction	Attack complexity	Notes
STA-015-DL / SystemUI	High (device UI)	Yes (reboot)	One click	Low	Scope Changed; hard reboot
STA-010/011 Print/Clipboard	High (SystemUI)	Yes (until reboot)	Print / paste	Low	System service path
STA-005 WhatsApp family	High (app / shared inbox)	Yes (delete chat)	Paste / open chat	Low	×20.6 Bundle amplification
STA-012 Threads	High (app)	Yes (pm clear)	Deep link click	Low	Permanent until data clear
STA-017 libminikin ANR	Medium (ANR 5–16 s)	No	Long-press / focus	Low	Cross-engine; framework lib
STA-027 Edge Ask Copilot	Medium–High (crash)	Yes	Deep link click	Low	Remote; Compose NavGraph
STA-019 Firefox address bar	Medium	Yes (every focus)	Focus address bar	Low	Repeated until history cleared
STA-020/021/022 browsers	Medium	Partial	Focus / history	Low	History pipeline

10. STA-005 — WhatsApp Variants

Affected component	FragmentManager.restoreAllState() — AndroidX
Trigger	Bundle.dataSize() > 1,048,576 bytes during state restoration
Current behavior	TransactionTooLargeException uncaught → crash → state re-persisted → loop
Expected behavior	Exception caught → state discarded → clean start → no loop
Reproducibility	100% — Pixel 7, Xiaomi Redmi 14, OPPO A78, OnePlus 11 (Android 13–16)
Confirmed apps	WhatsApp, WhatsApp Business, Meta AI, Threads, Bing, Opera, DuckDuckGo, Firefox
CVSS 3.1	6.5 — AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

STA-005b (WhatsApp Business): When a conversation’s SavedState becomes contaminated, the crash loop affects ALL agents in a shared inbox simultaneously. The only recovery (deleting the conversation) destroys the entire communication history with that client.

STA-005c (WhatsApp + Meta AI): Oversized draft in AI chat can lock the entire application permanently.

11. STA-015 Series — SystemUI Vectors

These vectors extend Class A amplification into privileged system components. Impact is no longer confined to a single app.

Vector	Trigger	Mechanism	CVSS
STA-010	Google Drive document → Print → local printer	Print Service builds preview Bundle from oversized text; exceeds Binder when handed to SystemUI	7.2
STA-010b	Drive → cloud/network printer	Same root mechanism routed through Play Services	6.5
STA-011	Copy oversized clipboard → focus text field with assisted-paste	Clipboard assisted-paste preview serializes full ClipData instead of truncated snippet	7.2
STA-015	Opening recent apps / task list	RecentTasksController reads corrupt task state → DeadSystemException → SystemUI crash → lockscreen	7.2
STA-015b	HyperOS after SystemUI restart	OEM Task State Interactor re-reads corrupt state → automatic re-crash	7.2
STA-015-DL	Google Drive HTML link → any browser	Full remote chain (see section 8.2). Hard reboot required. Scope Changed.	8.6

CVSS 3.1 for STA-015-DL: AV:N / AC:L / PR:N / UI:R / S:C / C:N / I:N / A:H = 8.6 HIGH. Remote, single click, changes scope to SystemUI, high availability impact.

12. STA-019 — Firefox: Four Failure Modes

STA-019a — ClipboardManager DeadSystemException on every address-bar focus (CVSS 6.8)
STA-019b — SearchDialogFragment IllegalStateException (CVSS 6.0)
STA-019c — Jetpack Compose TextLayout lineIndex out-of-bounds (CVSS 6.0)
STA-019d — address-bar TextLayout lineIndex OOB (CVSS 6.5)

All four can fire on every focus event once history/state is contaminated, producing a persistent unusable address bar.

13. STA-020 / 021 — Chrome / Edge / Brave Address-Bar Pipeline

History suggestion pipeline retains oversized URLs. Subsequent focus or suggestion rendering re-enters libminikin or causes ANR. Chromium applied a partial display-only truncation in 2023 that never covered the loading/history path — STA-020 still reproduces through the unpatched path.

14. STA-022 — DuckDuckGo

STA-022: URL_EXTRA_ARG of ~920 KB stored in Fragment arguments produces a 965 KB parcel → TransactionTooLargeException (Tier A). STA-022b: history suggestion pipeline ANR that survives across sessions until history is cleared.

15. Cross-Platform Validation — iOS Not Affected

Same payload does NOT crash Threads for iOS. Same app, same 20 000-character deep link, zero crash on iOS. Failure is isolated to Android-specific components: Binder (1 MB limit), TaskPersister, FragmentManager.restoreAllState(). The fix must come from Google / AOSP.

16. Recommended Fixes

Proposed mitigations (not observed factory behaviour). Code samples below are suggestions for framework and application owners; they have not been merged upstream as of the July 2026 bulletin.

16.1 Framework — Class B (libminikin)

Listing 2. Proposed length thresholds before Optimal/Greedy line breaking.

// CORRECTED FIX — LineBreakOptimizer.cpp (libminikin.so)
// Previous “switch to greedy only” is incomplete: breakLineGreedy also blocks.

LineBreakResult LineBreakOptimizer::computeBreaks(...) {
    const int textLength = end - start;

    // THRESHOLD 1 (HARD): Truncate before any algorithm runs.
    // Neither algorithm produces useful results for text > 8 KB of URL/text.
    if (textLength > MAX_SAFE_TEXT_LENGTH_ABSOLUTE) {
        end = start + MAX_SAFE_TEXT_LENGTH_ABSOLUTE;
    }

    // THRESHOLD 2: Prefer O(n) greedy for medium-length text.
    if ((end - start) > MAX_SAFE_TEXT_LENGTH_FOR_OPTIMIZER) {
        return computeBreaksGreedy(measured, start, end, constraints);
    }

    return computeBreaksOptimal(measured, start, end, constraints);
}

// Units are UTF-16 code units (Java/Android char), NOT bytes.
static const int MAX_SAFE_TEXT_LENGTH_ABSOLUTE     = 8192;  // hard truncate
static const int MAX_SAFE_TEXT_LENGTH_FOR_OPTIMIZER = 2048;  // switch to greedy

16.2 Framework — Class A (FragmentManager / SystemUI)

Catch TransactionTooLargeException inside FragmentManager.restoreAllState() and start clean.
Validate derived state size before persistence (TaskPersister, SavedStateRegistry).
SystemUI and OEM components must treat restored task lists as potentially toxic and degrade gracefully (do not crash the whole UI process).

16.3 Application-level (immediate workarounds)

// Truncate any text displayed in a TextView
public static String safeForTextView(String text) {
    final int MAX = 8192;
    if (text == null) return null;
    return text.length() > MAX ? text.substring(0, MAX) + "..." : text;
}

// Reject oversized VIEW Intents
if (Intent.ACTION_VIEW.equals(intent.getAction())) {
    Uri data = intent.getData();
    if (data != null && data.toString().length() > 50_000) {
        Log.w(TAG, "Incoming VIEW Intent URL exceeds safe length — discarding");
        finish();
        return;
    }
}

Coverage warning for CISOs: Updating to androidx.savedstate 1.5.0 does NOT protect against STA-015-DL (SystemUI), STA-015/015b, STA-017 (libminikin) or STA-019 (Firefox pipeline). Those require AOSP-level changes that only Google can ship.

16.4 Generic System UI / OEM Resiliency Pattern (STA-015b)

HyperOS component OEM Task State Interactor re-subscribes to task info after SystemUI restart and re-reads corrupt state. Safe degradation on DeadObjectException prevents the automatic second crash loop:

// STA-015b — Xiaomi / HyperOS OEM fix
// OEM Task State Interactor: safe degradation when TaskManager is dead

val focusedTaskFlow = interactor.getFocusedRootTaskInfoFlow()
    .catch { exception ->
        if (exception is DeadObjectException) {
            Log.e("SystemUI", "TaskManager service is dead. Resubscribing later.")
            emit(null) // Safe degradation — do not crash SystemUI
        } else {
            throw exception
        }
    }

17. Vendor Notification Status

Vendor	First notification	Response / validation	Patch status (Jul 2026)
Xiaomi	2026	Reproduced, confirmed, rewarded	OEM-side mitigation feasible
Google (Android VRP)	Jan 20, 2026	Multiple reports; mixed outcomes; savedstate 1.5.0 progress	No public STA patches in Jul bulletin
Microsoft (MSRC)	Jan / Jun 2026	Individual cases (Edge, Bing, Ask Copilot STA-027)	Pending
Mozilla	2026	Reports submitted (Firefox family)	Pending
Opera / Brave / DuckDuckGo / Tor	2026	Reports submitted; classifications vary	Pending
Samsung	—	Documented only (no public VRP for this class)	—
INCIBE (CNA Spain)	Jul 2026	Referred to MITRE (CNA Root for Google). Technical reports and PoCs submitted.	All STA vectors

18. Disclosure Timeline

Research span: 2022 → 30 July 2026. Primary laboratory device: Xiaomi Redmi Note 14 5G (HyperOS 3.0 / Android 16). Much of the AOSP path analysis was performed from a phone browser reading public source, without a traditional multi-monitor lab setup.

18.1 2022 — Origin

Date	Milestone
28 Aug 2022	Original discovery: TransactionTooLargeException / DeadSystemException in Firefox Focus & Nightly (clipboard, share, open-in-app)
12 Oct 2022	First public advisory: “Mozilla Firefox Focus and Nightly for Android Remote Crash DoS” (lostmon.blogspot.com)
Nov 2022	Chromium Issue 40879254 opened; security labels removed; partial UX patch; issue remained open
Nov 2022	Mozilla Bugzilla #1802594 (S3) opened — still NEW / unresolved as of 2026

18.2 January–April 2026 — Formal investigation

Date	Milestone
20 Jan 2026	Formal reports to Google Android VRP (A-477279924) and Microsoft MSRC. Case A-477279924 received a $250 VRP reward for the Binder/IPC research area and remained open / blocked on internal dependency as of mid-2026. (A separate Chrome VRP filing, Issue 477202817, was closed the same day as “Won’t Fix (Intended Behavior)”.)
Feb 2026	Whitepaper v4 distributed (27 vectors); STA-015-DL (CVSS 8.6) and STA-015b added
Mar 2026	Meta (WhatsApp/Threads) notified — no response (113+ days by July)

18.3 May–June 2026 — Field evidence

Date	Milestone
24 May 2026	Chrome bugreport: 2 full native ANRs → STA-017 Tier A (libminikin)
26 May 2026	SystemUI: 85 crashes in 4 days on Android 16 (first confirmed)
31 May 2026	STA-015-DL remote attack confirmed via Google Drive (`callingPackage=com.google.android.apps.docs`) — 6 browsers
10 Jun 2026	Vendor notifications: Mozilla, Opera, DuckDuckGo, Brave, Tor, Xiaomi (HackerOne)
10 Jun 2026	Firefox ANR 16 006 ms (real Gmail link) → STA-017 Firefox Tier A
14 Jun 2026	MSRC responds; requests separate cases; defers framework root cause to Google
15 Jun 2026	Google closes libminikin-specific report (524288518) as “out of scope” — months after $250 reward
16 Jun 2026	Appeal for STA-015-DL citing CVE-2023-21167 / A-259942964; Opera classifies P5 Informational
19 Jun 2026	Brave rejects as “upstream / DoS out of scope”
20 Jun 2026	Second spontaneous SystemUI crash loop; Edge ANR 25 s later → STA-017 Edge Tier A
24 Jun 2026	Three separate MSRC cases filed; blog posts: STA framework + Algorithmic DoS in libminikin
28 Jun 2026	Google App: 5 ANR + 3 TransactionTooLargeException in 14 min; `breakLineGreedy` also vulnerable; first simultaneous Class A+B
30 Jun 2026	No public AOSP/Chromium/AndroidX commits addressing documented vectors; June bulletin empty for STA

18.4 July 2026 — Countdown to disclosure

Date	Milestone
5 Jul 2026	Google Issue #531319203 opened (system_server boot loop / BitmapCache — same architectural pattern)
6 Jul 2026	July Android Security Bulletin published — zero patches for any STA vector
10 Jul 2026	Blog: “libminikin: 10 años de vulnerabilidad”; Xiaomi device still vulnerable after June patch
11 Jul 2026	Mozilla Bugzilla #2046725 opened for Firefox family
16 Jul 2026	Xiaomi confirms vulnerability and awards bounty ($300 via HackerOne)
Jul 2026	STA-027 (Edge Ask Copilot) documented; INCIBE (CNA Spain) reviewed the case and referred it to MITRE for CVE assignment
21 Jul 2026	Googke Close Appesl 526330835 as "Not reproducible"
30 Jul 2026	Public whitepaper disclosure — lostmon.blogspot.com
3 Aug 2026	August Android Security Bulletin published — zero patches for any STA vector. Google VRP responds to case A-477279924: “actively looking into this issue and working on a fix.”

July 2026 Security Bulletin — zero mitigation. Google has not released the internal fix (LargePayloadSupport, AOSP CL 3989977) to the public branch as of the disclosure date. The $250 VRP reward for the Binder/IPC research area stands in contrast to the later “out of scope” classification of the related libminikin report.

Post‑disclosure confirmation (3 Aug 2026): The August Security Bulletin contained no STA patches. However, later that day, the Android Security Team responded in the VRP ticket A-477279924, stating: “actively looking into this issue and working on a fix.”

Full narrative timeline and related articles: Timeline STA · Research story · libminikin 10 years · Algorithmic DoS · STA framework

19. Glossary

Term	Definition
STA	Structured Text Amplification — architectural pattern of progressive resource amplification from structured textual input.
Class A	IPC / SavedState amplification: Bundle exceeds Binder limit → crash loop.
Class B	Interaction-surface amplification: libminikin line-breaking blocks UI thread → ANR.
Binder	Android IPC mechanism; hard transaction limit 1 048 576 bytes.
TaskPersister	Framework component that persists task/activity state to disk for restoration.
SavedState / FragmentManager.restoreAllState()	AndroidX/AOSP path that restores Fragment hierarchy from a Bundle after process death.
libminikin	Native Android text layout library (line breaking, measurement); used by TextView and others.
LineBreakOptimizer::computeBreaks	Optimal (often O(n²)) line-breaking path inside libminikin.
SystemUI	Privileged process that owns status bar, navigation bar, lockscreen, recent tasks.
OEM Task State Interactor	Xiaomi HyperOS OEM component that re-subscribes to task focus state after SystemUI restart.
LargePayloadSupport	Internal Google/AOSP work (CL 3989977) to pass large payloads via file descriptors instead of Binder.
TransactionTooLargeException	Exception thrown when a Parcel/Binder transaction exceeds the 1 MB limit.
ANR	Application Not Responding — main thread blocked beyond the watchdog threshold (~5 s).
NavGraph (Compose)	Jetpack Compose Navigation graph; routes must be direct children of the declared graph.

20. Limitations and Future Work

Research conducted on production consumer devices; no privileged access to proprietary vendor source beyond AOSP.
Exact behaviour varies with Android version, OEM customisations, available memory and security patches.
Not every documented vector has received independent vendor confirmation.
STA is proposed as a working architectural model derived from empirical observations. Its ultimate validity depends on independent reproduction and critical review.

20.1 Future work

Formal mathematical modelling of amplification thresholds (Class A nesting depth vs Bundle size; Class B character-composition cost).
Automated detection of STA-style execution paths (static analysis + dynamic instrumentation).
Broader cross-platform comparison (further iOS controls; other mobile OS text pipelines).
Upstream-ready patches for libminikin length thresholds and SystemUI safe degradation.

21. Conclusion

What initially appeared to be isolated denial-of-service conditions gradually revealed recurring architectural characteristics shared by otherwise unrelated execution paths. These observations motivated the introduction of the Structured Text Amplification (STA) model.

The primary contributions of this work are:

Introduction of STA as an architectural framework for analysing structured input propagation across Android.
Documentation of 32 reproducible vectors spanning Class A (IPC/SavedState) and Class B (libminikin) mechanisms, with full technical evidence.
Correlation of apparently independent behaviours through execution-path analysis rather than symptom comparison.
Concrete evidence (native stack traces from production devices, AOSP commit references, field crash statistics) supporting the most severe findings, including remote SystemUI crash loops (CVSS 8.6).
Proposal of layered defensive strategies that address amplification at the architectural level.

Structured Text Amplification was not discovered in a single experiment. It emerged progressively through months of observation, reverse engineering, responsible disclosure and repeated empirical validation. The vectors documented in this whitepaper should therefore be understood not merely as isolated software behaviours, but as the experimental foundation from which the STA model was derived.

Whether future research confirms, refines or challenges this model, the underlying observations remain reproducible technical evidence.

References

Chromium commit 3e62ece6 (LargePayloadSupport), May 2026: chromium.googlesource.com/chromium/src/+/3e62ece6
Google Issue Tracker 40879254 (2022): issuetracker.google.com/issues/40879254
Google Issue Tracker 40268979 / related Samsung Chrome ANR (2023): issuetracker.google.com/issues/40268979
AOSP minikin repository: android.googlesource.com/platform/frameworks/minikin/
androidx.savedstate 1.5.0 / Bug #425919375 (SavedState serialization)
Android Open Source Project — FragmentManager, TaskPersister, WindowManager Shell
Android Security Bulletins (historical Minikin resource-exhaustion ANR notes)
Lostmon — Structured Text Amplification (STA), 23 Jun 2026: lostmon.blogspot.com/2026/06/structured-text-amplification-sta.html
Lostmon — Algorithmic DoS en libminikin.so, 24 Jun 2026: lostmon.blogspot.com/2026/06/algorithmic-dos-en-libminikinso.html
Lostmon — libminikin: 10 años de vulnerabilidad, 10 Jul 2026: lostmon.blogspot.com/2026/07/libminikin-10-anos-de-vulnerabilidad-en_0671440346.html
Lostmon — Timeline investigación STA, 12 Jul 2026: lostmon.blogspot.com/2026/07/timeline-investigacion-sta-estilos.html
Lostmon — Desafiar Android desde el sofá, 17 Jul 2026: lostmon.blogspot.com/2026/07/desafiar-android-desde-el-sofa-y-un.html

Appendix I — Additional External Corroboration (July 2026)

Google has publicly acknowledged, across multiple Android version cycles (4.4.2, 7.1, 8.1, 9.0), that Minikin is vulnerable to resource-exhaustion ANR triggered by attacker-controlled text content. The phenomenon matches the general failure category documented throughout this paper (STA-017 and related vectors).

The July 2026 Chrome security release contains numerous vulnerabilities affecting components that overlap with the architectural surfaces analysed in this work, including Views, Skia, Clipboard, Print Preview, WebView, UI and input validation. Although Google has not publicly linked these fixes to Structured Text Amplification (STA), the functional overlap and temporal proximity suggest that the affected architectural areas correspond closely to the amplification paths documented in this research. This observation should be interpreted as corroborative evidence of architectural relevance rather th/pAn independent Chinese-language technical article (Volcengine, May 2026) describes the same practical symptom from an application-developer perspective and recommends truncating input to a bounded size in the 8–32 KB range — consistent with the 8192 UTF-16 code-unit threshold proposed here.

androidx.savedstate 1.5.0 addresses part of Class A for AndroidX consumers but does not cover SystemUI, TaskPersister, libminikin or OEM layers. The most severe vectors still require AOSP-level changes.

CNA referral note (INCIBE → MITRE). On July 14, 2026, INCIBE (Spain's national CSIRT and CVE Numbering Authority) was contacted for CVE assignment across the STA vectors documented in this paper. After internal review, INCIBE formally responded that the affected components fall under MITRE's jurisdiction as the CNA Top-Level Root for the Google ecosystem, and referred the case accordingly. The full whitepaper and supporting evidence are being submitted to MITRE upon public disclosure (July 30, 2026).

Note on external PoC activity. The researcher has been made aware of a public proof-of-concept tracked as CVE-2026-10702, reportedly addressing a related class of Android text-rendering denial-of-service behaviour. This paper has not independently verified the technical content of that CVE record or confirmed a direct mechanism overlap with the STA-017 vectors documented here. It is noted for context as a potential independent data point on the broader visibility of this vulnerability class, not as corroborated evidence within this paper's chain of proof.

Appendix II — Vendor Conduct & Acknowledgements: Xiaomi

While many vendors either dismissed the reports through procedural classifications or ignored them entirely, Xiaomi demonstrated that it is entirely possible to:

Recognize a systemic issue without disclaiming responsibility.
Deploy OEM-level mitigations while awaiting upstream fixes from AOSP.
Value and support the work of independent security researchers.
Conduct responsible disclosure with transparency, professionalism, and technical competence.

Acknowledgements

High-level vector behavior for STA-015 and STA-015b is documented in this paper for architectural completeness. However, specific internal component names, proprietary code traces, and exact patch implementations have been intentionally withheld out of respect for Xiaomi's internal patching process and in accordance with responsible disclosure agreements.

The researcher wishes to express sincere appreciation to Xiaomi's Security Team for their professionalism, technical rigor, and commitment to protecting their user base.

Xiaomi demonstrated that it is possible to do the right thing — even when the underlying issue originates beyond your immediate framework layers.

Appendix III — Correlation between July 2026 Chromium Security Fixes and STA Vectors

On July 29, 2026, Google released Chrome Stable 151.0.7922.71 with 370 security fixes. Several of these address components whose architectural function overlaps with the surfaces identified in the STA research.

The following table maps selected Chrome CVEs to the posible STA vectors based on functional similarity. Confidence levels are indicated as follows:

🟢 High: The component is identical to or directly implements the same pipeline/surface described in STA.
🟡 Medium: The component shares the same architectural pipeline but the exact failure mode may differ.
⚪ Low: The component is conceptually related but not directly comparable.

Chrome CVE	Component	Potential STA Vector	Confidence	Rationale
CVE-2026-17679	Print Preview	STA-010	🟢 High	Both involve document/text processing before printing.
CVE-2026-17766	Clipboard	STA-011	🟢 High	Clipboard handling is explicitly part of the STA surface.
CVE-2026-17670	Views	STA-020	🟢 High	Views is the UI layer where much of the STA pipeline terminates.
CVE-2026-17699	Views	STA-020	🟢 High	Same architectural layer.
CVE-2026-17702	Skia	STA-017	🟢 High	Skia is part of the graphics pipeline downstream from libminikin.
CVE-2026-17745	Skia	STA-017	🟢 High	Same graphics pipeline.
CVE-2026-17757	Skia	STA-017	🟢 High	Same graphics pipeline.
CVE-2026-15766	Skia	STA-017	🟢 High	Another recent Skia issue in the same rendering path.
CVE-2026-17698	UI	STA-017 / STA-020	🟡 Medium	The UI layer processes structured text before rendering it.
CVE-2026-17722	WebView	STA-027 (general)	🟡 Medium	WebView participates in several propagation scenarios described in STA.
CVE-2026-17690	PDF	STA Document Pipeline	🟡 Medium	Document processing with structured input.
CVE-2026-17803	Save to Drive	STA Deep Link / Drive	🟡 Medium	Similar to the Drive → Chrome → Android propagation chain.

Note: This table is intended as a triage aid, not as a claim of direct causation. It identifies functional overlap in processing pipelines (Views, Skia, Clipboard, Print Preview, WebView, UI) that intersect with the surfaces described in the STA report. Notably, the descriptive patterns used by Google across these fixes ("Insufficient validation of untrusted input", "Views", "Skia", "Clipboard", etc.) closely align with the surfaces described in the STA research.

Structured Text Amplification (STA)
Unified Architectural + Full Technical Whitepaper
© 2026 Manuel García Peña (Lostmon)
Public disclosure: 30 July 2026 · lostmon.blogspot.com

Desafiar Android desde el sofá y un smartphone

2026-07-17T02:24:28.894-07:00

¿Se puede desafiar la seguridad de Android usando SOLO un teléfono móvil?

La respuesta es sí.
Y esta es mi historia.

Soy Manuel García Peña (Lostmon), investigador independiente de seguridad y presidente de BojosXtu, una asociación de apoyo y empoderamiento en salud mental.

Durante los últimos cuatro años he perseguido un mismo patrón dentro de Android. Lo que comenzó como una intuición técnica terminó convirtiéndose en una investigación donde documento 31 vectores de ataque relacionados con un mismo fenómeno al que he llamado Structured Text Amplification (STA), un patrón que implica componentes críticos de Android como libminikin, SystemUI, el pipeline de renderizado de texto y distintos mecanismos internos de procesamiento y restauración del estado del sistema.

📅 La investigación completa verá la luz el próximo 30 de julio.

Pero lo más importante no es el hallazgo técnico.
Lo importante es cómo llegué hasta él.

🧒 Antes del diagnóstico: perseguir bugs era mi forma de entender el mundo

Mucho antes de recibir un diagnóstico de salud mental, ya era el típico chaval que desmontaba todo para descubrir cómo funcionaba.

Mientras otros jugaban, yo abría aplicaciones, observaba comportamientos extraños y me hacía siempre la misma pregunta:

"¿Y si esto se puede romper?"

No sabía lo que era un Bug Bounty. No sabía lo que era AOSP. Ni siquiera imaginaba que algún día investigaría vulnerabilidades.

Simplemente tenía una curiosidad casi obsesiva por comprender cómo funcionaban los sistemas.

Con los años empecé a encontrar fallos reales, a reportarlos y a aprender de forma completamente autodidacta.

Antes de tener que retirarme por problemas de salud mental, llegué a descubrir y documentar, más de 400 vulnerabilidades.

🖤 El momento en que tuve que dejarlo

Después llegó el diagnóstico.

Y con él, una realidad que me costó mucho aceptar.

Ya no podía pasar horas delante de un ordenador como antes.

Mi mente empezó a jugarme malas pasadas. Cuando llega. los Fantasmas, cada uno debe librar sus batallas con sus propios demonios.

Cuanto más tiempo permanecía frente a una pantalla grande, más me absorbía el mundo que había dentro de ella. Perdía la noción del tiempo, perdía el entorno y, a veces, sentía que me perdía yo mismo entre miles de líneas de código.

Tuve que dejar de investigar y alejarme de la tecnología que tanto me apasiona. ¿Como borras algo de tu vida que ha estado siempre?

Y fue durísimo.

Porque no estaba perdiendo simplemente un hobby.
Sentía que estaba perdiendo una parte de mí.

Pensé que todo había terminado.

📱 Mi laboratorio: un Xiaomi Redmi 14 5G y una tablet Lenovo.

Pero la curiosidad seguía ahí.

Y encontré otra forma de poder de vivir, sin estar rodeado de tanta tecnología.

Gran parte de esta investigación se ha realizado desde un Xiaomi Redmi 14 5G y la tablet Lenovo .

Desde el sofá.

En mis días buenos.
Cuando la cabeza me dejaba concentrarme un rato.

Sin un laboratorio.
Sin una estación de trabajo.
Sin varios monitores.
Sin ADB.
Sin Android Studio.
Se ha usado AI para la asistencia en la redaccion y formato de los documentos.

Solo una pantalla pequeña, AOSP abierto en el navegador y miles de líneas de código leídas función a función, siguiendo llamadas entre clases para intentar comprender cómo pensaba Android.

Durante cuatro años fui reconstruyendo ese enorme puzle.

Había días en los que solo podía revisar unas pocas funciones.

Otros encontraba una pista y pasaba horas siguiendo llamadas entre TextView, StaticLayout, LineBreaker, libminikin, SystemUI y muchos otros componentes del framework.

Así comenzó la persecución de un patrón que aparecía una y otra vez.

🔍 Cuatro años persiguiendo el mismo fantasma

La primera vez que observé un comportamiento extraño fue hace años, en Android 9.

Lo reproduje.
Tomé notas.
Y seguí investigando.

Con el tiempo aparecieron nuevos síntomas:

• bloqueos en navegadores;
• ANRs provocados por determinadas estructuras de texto;
• problemas durante la impresión;
• corrupción de estado en aplicaciones;
• crash loops persistentes de SystemUI;
• comportamientos aparentemente distintos que, una y otra vez, me llevaban al mismo lugar.

La mayoría habría pensado que eran errores independientes.

Yo no conseguía quitarme de la cabeza la sensación de que todos compartían un mismo origen.

Cada vez que encontraba un síntoma nuevo volvía al mismo sitio del código.

Fue entonces cuando empecé a sospechar que no estaba persiguiendo treinta y un errores distintos.
Estaba persiguiendo un único patrón que se manifestaba de formas diferentes.

🧠 La neurodivergencia también puede aportar otra forma de mirar

Durante mucho tiempo pensé que mi diagnóstico era un obstáculo para investigar.

Hoy lo veo de otra manera.

Con el tiempo comprendí que mi forma de procesar la información también tenía fortalezas: una enorme capacidad para detectar patrones, mantener el foco durante semanas sobre un mismo problema y conectar detalles que parecían no tener relación.

No romantizo la salud mental.
Hay días malos.
Hay agotamiento.
Hay frustración.
Hay momentos en los que la cabeza simplemente no coopera.

Pero también he aprendido que cada persona observa el mundo de una manera distinta.

Y, a veces, esa mirada diferente permite encontrar conexiones que habían pasado desapercibidas.

🤝 La comunidad hizo posible continuar

Yo solo no habría podido validar todo esto.

Compañeros y amigos me prestaron dispositivos para reproducir los distintos vectores en fabricantes y versiones diferentes de Android.

Gracias a ellos pude comprobar comportamientos en Xiaomi, Samsung, OPPO, OnePlus, LG y otros terminales.

La investigación independiente también se construye así.

Con personas que comparten tiempo, hardware y confianza sin esperar nada a cambio.

💰 Y un día llegaron dos mensajes que jamás olvidaré

En medio de todo este proceso llegaron dos validaciones que nunca habría imaginado cuando empecé leyendo AOSP desde la pantalla de un teléfono móvil.

Google confirmó una vulnerabilidad relacionada con Binder y me concedió una recompensa a través de su programa de vulnerabilidades.

Y hace apenas unas horas Xiaomi confirmó otra vulnerabilidad y me concedió una recompensa mediante HackerOne.

No es una cuestión de dinero.

Lo verdaderamente importante fue leer una frase muy sencilla:

"This vulnerability is confirmed."

Después de tantos años investigando en silencio, esa frase significó mucho más que una recompensa económica.

Fue la confirmación de que todo aquel esfuerzo, todas aquellas horas leyendo código y persiguiendo un patrón que casi nadie veía, estaban dando fruto.

🚀 La investigación continúa

El próximo 30 de julio publicaré el whitepaper completo con la metodología, el marco teórico de Structured Text Amplification (STA), los 31 vectores documentados y todas las evidencias recogidas durante estos años.

No sé cuál será su impacto.
No sé cuántas personas lo leerán.

Pero sí sé una cosa.

La curiosidad no depende del hardware.

No depende de tener el mejor laboratorio.
Ni de disponer de cuatro monitores.

Depende de seguir haciéndote preguntas.

Depende de no dejar de preguntarte:

"¿Y si nadie ha mirado aquí?"

Porque, al final, investigar nunca ha consistido en tener el mejor equipo.

Ha consistido en no perder nunca la capacidad de hacerse preguntas.

Y después de todo este tiempo sigo creyendo exactamente lo mismo que cuando era un chaval persiguiendo bugs sin saber siquiera cómo se llamaban.

"La curiosidad es lo que hace mover la mente." 🛡️

La investigación continúa.
Y yo también.

#Lostmon #Android #AOSP #Ciberseguridad #MobileSecurity #SystemUI #libminikin #STA #StructuredTextAmplification #BugBounty #GoogleVRP #Xiaomi #HackerOne #SaludMental #InvestigaciónIndependiente #BojosXtu

Manuel García Peña (Lostmon)
lostmon.blogspot.com · lostmon@gmail.com

Timeline de STA Structured Text Amplification

2026-07-12T11:34:00.708-07:00

⏳ Timeline de la investigación STA

De 2022 al 30 de julio de 2026 · 31 vectores · 15 archivos · 13 años de código vulnerable

Actualizado: 12 de julio de 2026

📌 Referencias: Los tres artículos de la saga

📐 Structured Text Amplification (STA) 23 jun 2026
💣 Algorithmic DoS en libminikin.so 24 jun 2026
⚖️ libminikin: 10 años de vulnerabilidad en el núcleo de Android 10 jul 2026

📖 Estos tres posts forman la base de la investigación que culminará en el whitepaper del 30 de julio de 2026.

📌 Esta línea temporal resume los hitos clave de la investigación — desde los primeros hallazgos en 2022 hasta la publicación del whitepaper el 30 de julio de 2026. En el camino, 31 vectores, 15 archivos de AOSP, 9 empresas, 12 navegadores y una recompensa de $250 que se convirtió en símbolo de la contradicción de Google.

2022 · El origen

2022 28 ago

🔍 Descubrimiento original

Lostmon encuentra TransactionTooLargeException y DeadSystemException en Firefox Focus, Firefox Nightly mediante clipboard, share y open-in-app.

2022 12 oct

📝 Publicación del advisory

Se publica el primer advisory público: "Mozilla Firefox Focus and Nightly for Android Remote Crash DoS" en lostmon.blogspot.com.

2022 Nov

📋 Reporte a Chromium · Issue 40879254

Se abre Chromium Issue 40879254. Se eliminan las etiquetas de seguridad (comment #9). Se aplica un parche UX parcial (comment #22). El issue sigue abierto y asignado.

2022 Nov

📋 Reporte a Mozilla · Bugzilla #1802594

Se abre Mozilla Bugzilla #1802594 (Severidad S3). El issue sigue en estado NEW (sin resolver) en 2026.

2026 · La investigación formal

2026 20 ene

📋 Reporte al Chrome VRP · Issue 477202817

Se envía el reporte al Chrome VRP con 27 vectores. Google lo cierra el mismo día como "Won't Fix (Intended Behavior)" argumentando que el DoS "no es un bug de seguridad en Chrome".

2026 20 ene

📋 Reporte al Android VRP y MSRC

Se envía el reporte formal a Google Android VRP (A-477279924) y a Microsoft MSRC.

2026 Ene

💰 Recompensa de Google · $250

Google paga 250 dólares por la primera parte de la investigación (caso Binder/IPC).

2026 Feb

📄 Whitepaper v4

Se distribuye el whitepaper v4 con 27 vectores. Se añaden STA-015-DL (CVSS 8.6) y STA-015b.

2026 Mar

🔍 Reporte a Meta

Se notifica a Meta (WhatsApp/Threads) a través de su bug platform. No hay respuesta.

Mayo–Junio 2026 · La evidencia de campo

2026 24 may

📱 Bugreport de Chrome · STA-017 → Tier A

Se capturan 2 ANR completos de Chrome con trazas nativas de libminikin.so en un Xiaomi Redmi Note 14 5G (Android 16, HyperOS 3.0).

2026 26 may

📱 Bugreport de SystemUI · 85 crashes

Se capturan 85 SystemUI crashes en 4 días en el mismo dispositivo. Primera confirmación en Android 16.

2026 31 may

📱 STA-015-DL · Ataque remoto confirmado

Se confirma el ataque remoto a través de Google Drive: callingPackage=com.google.android.apps.docs. Afecta a 6 navegadores.

2026 10 jun

📋 Notificaciones a vendors

Se envían reportes a Mozilla, Opera, DuckDuckGo (HackerOne), Brave (HackerOne), Tor Project, Xiaomi (HackerOne).

2026 10 jun

📱 Bugreport de Firefox · 16.006 ms

Se captura ANR de Firefox con 16.006 ms de duración. Trigger: enlace real de Gmail. STA-017 Firefox → Tier A.

2026 14 jun

📋 Respuesta de MSRC

Microsoft MSRC responde, deriva el caso a Google y solicita casos separados.

2026 15 jun

❌ Google cierra libminikin · "out of scope"

Google cierra el reporte específico de libminikin (524288518) como "out of scope" — meses después de pagar los $250 por el caso Binder/IPC.

2026 16 jun

📋 Apelación a Google

Se envía apelación para STA-015-DL (CVSS 8.6), citando precedentes CVE-2023-21167 y A-259942964.

2026 16 jun

📋 Respuesta de Opera · P5 (Informational)

Opera clasifica STA-016/017 como P5 (Informational). Afecta a Opera y Opera Mini.

2026 19 jun

📋 Rechazo de Brave

Brave rechaza el reporte como "upstream/DoS out of scope".

2026 20 jun

📱 Segunda confirmación SystemUI · Edge ANR

Segundo bugreport espontáneo de SystemUI. 3 crashes en 1.7s → Edge ANR 25s después. STA-017 Edge → Tier A.

2026 24 jun

📋 MSRC · Casos separados

Se envían 3 casos separados a MSRC (STA-013, STA-017/STA-020, STA-015-DL).

2026 24 jun

📝 Publicación: Structured Text Amplification (STA)

Se publica el primer artículo en el blog: "Structured Text Amplification (STA)" — el marco teórico.

2026 24 jun

📝 Publicación: Algorithmic DoS en libminikin.so

Se publica el segundo artículo en el blog: "Algorithmic DoS en libminikin.so" — la prueba de concepto.

2026 28 jun

📱 Bugreport de Google App · 5 ANR + 3 TransactionTooLargeException

Se capturan 5 ANR + 3 TransactionTooLargeException en 14 minutos. breakLineGreedy también es vulnerable. STA-017 Google App → Tier A. Primera evidencia de Clase A + Clase B simultáneas.

2026 30 jun

📋 Confirmación sin parche

No hay commits en AOSP, Chromium o AndroidX que aborden los vectores documentados. El boletín de junio no contiene CVEs relacionados.

Julio 2026 · La cuenta atrás

2026 5 jul

📋 Nuevo issue de Google · #531319203

Se abre issue #531319203: system_server boot loop por imagen grande en BitmapCache. El mismo patrón arquitectónico.

2026 6 jul

📋 Boletín de julio sin parche

Google publica el boletín de seguridad de julio de 2026. No contiene ningún parche para los 31 vectores.

2026 8 jul

📋 Xiaomi sin respuesta · 35+ días

Xiaomi no responde tras 35+ días. Se envía seguimiento con deadline del 20 de julio.

2026 10 jul

📝 Publicación: 10 años de vulnerabilidad

Se publica el tercer artículo en el blog: "libminikin: 10 años de vulnerabilidad en el núcleo de Android" — el análisis forense del código de AOSP.

2026 10 jul

📋 Meta sin respuesta · 113+ días

Meta no responde tras 113+ días.

2026 10 jul

📱 Actualización de seguridad · Sigue vulnerable

El dispositivo Xiaomi Redmi Note 14 5G recibe el parche de junio de 2026. Sigue siendo vulnerable.

2026 11 jul

📝 Nota de prensa · BojosXtu

Se prepara la nota de prensa para BojosXtu. Se añade la contradicción de los $250.

2026 11 jul

📝 Abrimos reporte en Bugzilla para Firefox

Se envia in reporte a mozilla y se abre en bugzilla un bugreport para Firefox y familia. bug id: #2046725

2026 12 jul

📋 Issue 477202817 · Confirmado

Se confirma que Chromium Issue 477202817 (reporte al Chrome VRP) sigue cerrado como "Won't Fix (Intended Behavior)".

2026 16 jul

📝 Xiaomi confirma vulnerabilidad

Xiaomi confirms sus vectores y asigna un bountry de 300$

📅 Próximos pasos

2026 20 jul

⏰ Último día para vendors

Fecha límite para que los vendors (Xiaomi, Meta, etc.) respondan.

2026 30 jul

🚀 PUBLICACIÓN DEL WHITEPAPER

Se publica el whitepaper completo con 31 vectores, trazas nativas, código AOSP y cronología.

vectores documentados

15+

archivos de AOSP

años de código vulnerable

2.5B

dispositivos afectados

🔴 250 dólares por 2.500 millones de dispositivos: 0,0000001 $ por dispositivo. Menos de lo que vale un átomo de polvo.
Si Google hubiera pagado 1 céntimo por dispositivo, la recompensa habría sido de 25 millones de dólares. Pagaron 250.

Manuel Garcia Peña (Lostmon) · lostmon@gmail.com · lostmon.blogspot.com
Whitepaper completo: 30 de julio de 2026

Lostmon Blogger

Microsoft Edge for android Ask Copilot Prompt Injection

1. Executive Summary

2. Vulnerability Details

Description

Observed behavior

3. Relationship to CVE-2026-48561

4. Potential Attack Scenarios

5. Scope of the Tested Vector

6. Root Cause Analysis (Hypothesis)

7. Impact Assessment (Provisional)

Provisional CVSS v4.0 vector

8. Mitigation Recommendations

User-level mitigations

9. Disclosure Timeline

10. References

11. Contact Information

12. Revision History

CWE New Weakness Submission

1. Description

2. Defining Characteristics

3. Re-materialization

4. Relationships to Other CWE Entries

5. Security Properties and Consequences

6. Modes of Introduction

7. Affected Technologies and Examples

8. Detection and Testing

9. Mitigation

10. Observed and Reproduced Android Example

11. Distinction Between Entry Points and Root Cause

12. Related Mitigations and References

13. Rationale for a Distinct Weakness

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

1. What exactly was suspended

2. The case that matters: A-477279924

3. Why this affects every legitimate researcher

4. What this means for STA Research

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

6. What this means for an independent researcher

7. What I am doing now

8. A note on the irony

Unbounded TaskInfo serialization in ActivityTaskManagerService

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

1. Summary

2. Affected code paths (AOSP frameworks/base)

3. Root cause

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

3.2 The 2020 mitigation is incomplete — verified against source

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

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

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

3.5 Confluence of push and pull paths

3.6 SystemUI does not degrade gracefully on ATMS binder failure

4. Reproduction

5. Evidence (redacted stack excerpts)

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

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

5.3 Terminating action (ActivityManagerService)

6. Impact

7. Note on browser involvement

8. Suggested remediation

9. Attachments available on request

10. Researcher background

De FileAllInformation a inotify: 19 años de metadatos como frontera desatendida

Parte I — 2007: el desbordamiento que Microsoft minimizó

El descubrimiento

La reproducción paso a paso

La respuesta de Microsoft

Parte II — 2007 (bis): el fallo era estructural, no puntual

Mismo punto de crash

Mismo atributo

Mismo disparador

Mismo alcance

Parte III — 2026: File Notification Attacks

El paper

Linux: el caso de /dev/input

Android: FileObserver atraviesa FUSE

Windows: vigilar C:\ lo revela todo

macOS: el caso menos grave (pero no inocuo)

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

2. Affected code paths (AOSP `frameworks/base`)

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

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

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

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

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

5.3 Terminating action (`ActivityManagerService`)

Linux: el caso de `/dev/input`

Windows: vigilar `C:\` lo revela todo