How 56 Old Vulnerabilities Became a Portable Audit
The OpenHarmony study makes a large claim from a finite body of evidence: historical Android design weaknesses can reappear in a separately implemented operating system. To judge that claim, it is not enough to repeat the headline number. The important work is the chain from selected publications to design-level vulnerabilities, from each vulnerability to an Android-independent audit question, and from that question to a release-specific test. Understanding that chain lets the reader interpret what the numbers establish—and what they leave open.
A literature corpus is not a vulnerability count
The researchers began with a broad search for security publications that mentioned Android in their title or abstract. They examined papers from IEEE S&P, USENIX Security, ACM CCS, and ISOC NDSS published between 2010 and 2024, producing 450 candidates. They also added technically substantial Android-security briefings from Black Hat USA, Europe, and Asia between 2015 and 2024. The candidate pool was then narrowed by hand.
The selection rules were designed to isolate design problems. The researchers retained work focused on Android's system design and excluded studies concerned only with application vulnerabilities, malware, or a defense that did not introduce an attack. They also excluded ordinary implementation defects such as memory corruption. After this review, the corpus contained 116 publications: 102 academic papers and 14 industry briefings. From those sources, the authors extracted 56 unique Design-Level Vulnerabilities, or DLVs.
That filter is not a judgment that app flaws, malware, or memory corruption are less serious. It is a way to hold the research question steady. A memory-safety error may recur in a rewrite if the same unsafe library or coding practice is reused, but it does not recur merely because two systems expose an Activity-like screen or a permission-like setting. The study wanted to test whether the system's intended relationships—between an app and a service, a caller and a receiver, or a user and a device capability—could carry the same weakness across a change of implementation. Mixing all vulnerability types would make that causal question harder to see.
The authors also analyzed the root cause and the mitigation for each selected case. This turns a publication's incident report into a design proposition. “A component leaked data” is an observation about an outcome. “A system-wide broadcast did not restrict its recipients” is a proposition about the rule that produced the outcome. The second form can be compared with another operating system. It tells an auditor what to look for even when the newer platform has different source files, APIs, and internal names. The mitigation is equally important because it records which part of the rule Android changed: the caller's permission, the receiver's identity, the amount of data exposed, the default behavior, or the lifetime of a resource.
The taxonomy then gives these propositions a common vocabulary. Common Weakness Enumeration categories do not replace the individual mechanisms, but they make recurring patterns visible. Improper access control can cover an exposed API, an unprotected component, or a file that bypasses the API layer; those mechanisms should not be collapsed into one exploit. Origin validation concerns whether a request or data item comes from an authorized source. Communication-channel categories concern whether a message can reach or be altered by an unintended endpoint. Grouping them helps the authors state principles across cases while retaining the evidence for each case.
That sequence matters. “450” describes the search space. “116” describes the sources selected for close analysis. “56” describes distinct design-level vulnerability classes extracted from those sources. None of the numbers means that Android has only 56 vulnerabilities, that 56 problems affect every Android device, or that the selected papers are a statistically representative sample of all security research. The corpus is deliberately shaped toward high-impact, technically detailed system-security work. Its value is depth and transferability, not prevalence measurement.
The researchers organized the 56 DLVs using the Common Weakness Enumeration taxonomy. The taxonomy has five root categories and 12 child categories, including improper access control, origin validation errors, unsafe communication channels, improper certificate validation, unrestricted hardware interfaces, exposed dangerous functions, UI misrepresentation, insecure automated optimizations, resource-lifetime failures, covert channels, and cleartext transmission. The distribution itself suggests where the selected literature found recurring design difficulty: 36 of the 56 DLVs fall under improper access control. Only three primarily violate availability, while most affect confidentiality or integrity.
That distribution should be read as a map of observed design concerns, not as a claim that access control is the only important security problem. A platform can leak data quietly for years without causing the visible disruption associated with a crash. The paper emphasizes that many of these failures are stealthy and persistent: an app may infer another app's activity, access a sensitive system state, or move data through a legitimate communication path without visibly breaking the device.
The corpus also records the parent system's response. The authors report that 52 of the 56 DLVs had been fixed in Android as of 2025, based on their review of Android documentation, Security Bulletins, fixing commits, and tests on an up-to-date Pixel 7a running Android 15. That result does not mean the design lesson disappears after a patch. It supplies a reference point: if Android has recognized and mitigated a weakness, a reimplementer needs a way to know that the old design should no longer be reproduced.
From historical attack to cross-system test
A paper describing a vulnerability usually contains more than an exploit outcome. It may explain the intended feature, the trust relationship that failed, the conditions required for abuse, and the mitigation that changed the design. The researchers extracted those elements and rewrote them as an Android-independent audit method. Instead of asking, “Does OpenHarmony contain Android's function?” the method asks, “Does OpenHarmony provide a comparable capability, make a comparable trust decision, and leave the same security-relevant behavior possible?”
The distinction between feature and behavior is crucial. A name can be translated while the semantics change, or two differently named components can make the same security decision. For each DLV, the authors first looked for the corresponding feature or component in OpenHarmony. If the feature was absent, they marked the DLV as not applicable. That is not a failed security test. It means the historical attack has no corresponding surface in that system, at least within the scope of the comparison.
If a comparable feature existed, the researchers performed reconnaissance. They consulted OpenHarmony documentation and located the relevant APIs, components, or system resources. This stage translates the security question into OpenHarmony's own vocabulary. Android's Intent becomes OpenHarmony's Want at the inter-component-communication level; Android's Content Provider becomes DataAbility for data sharing; Android's Broadcast Receiver has an analogous role in Common Events. The mapping makes the question portable without assuming that the implementations or all security semantics are identical.
The final stage was empirical. The authors created proof-of-concept applications that attempted to reproduce the design-level attack on stock OpenHarmony. A test might ask whether an untrusted app can observe a protected state, reach a sensitive operation through an alternate interface, manipulate a hardware relationship without consent, or send data through a channel that the permission model was supposed to exclude. The point of the PoC is not to provide a general attack tool. It is to determine whether the design assumption produces the security consequence in the newer system.
The study used three classifications when evaluating the tested behavior. “Not vulnerable” means the researchers could not reproduce the DLV under the tested conditions, whether because the relevant boundary was enforced or because the remaining surface was sufficiently restricted. “Fully vulnerable” means the tested design-level attack remained possible. “Partially vulnerable” means the attack surface remained, but existing mitigations blocked some scenarios or reduced the impact. Partial protection matters because a platform can be safer than the historical design while still exposing a residual path.
These labels describe the relationship between a design and a tested attack, not a moral ranking of the platform. Suppose an operating system removes one route to a sensitive state but leaves another route available. Calling the result “fixed” would hide the surviving design exposure; calling it “fully vulnerable” would hide the protection that now blocks some cases. The partial category preserves both facts. Likewise, “not vulnerable” is narrower than “secure”: the researchers may have found a sufficient mitigation, but the test still covers one mapped DLV, one set of conditions, and one release family.
The denominator also changes as the audit proceeds. The 56 DLVs are the historical set. The 46 applicable cases are the subset for which OpenHarmony had an analogous feature or functionality. The 24 vulnerable cases are the subset in which the authors reproduced a security-relevant outcome. A reader who jumps directly from 56 to 24 can miss the role of applicability; a reader who reports 24 without the 17-full and seven-partial split can miss the role of residual mitigation. The evidence is strongest when the claim carries its denominator and its conditions with it.
The same discipline applies to Android's mitigation status. The authors checked current Android behavior rather than assuming that an old paper described the present system. They examined documentation and security bulletins, looked for fixing commits, and tested an up-to-date Android 15 phone. That step matters because the comparison is about whether a historical lesson was incorporated into a parent system and whether a separate system shows the same lesson—not about replaying a decades-old snapshot against a modern product. It also means that “fixed in Android” is a time-bounded observation, not a guarantee that every downstream build or future design remains safe.
This funnel prevents several common errors in interpreting the result. A DLV that is not applicable should not be counted as a secure fix, because the comparison never reached a corresponding feature. A partially vulnerable result should not be reported as fully exploitable in every situation. A fully vulnerable result should not be treated as evidence that every component or release has the same flaw. Each label answers a narrower question about a mapped surface under tested conditions.
The model also separates Android's mitigation history from OpenHarmony's current behavior. The researchers reviewed how and when Android addressed each DLV, then tested whether the corresponding OpenHarmony design reflected that lesson. This is more informative than comparing two vulnerability totals without chronology. It can reveal a knowledge gap: Android may have changed a system rule after a problem was published, while an independently developed platform may never have received or incorporated that design correction.
The procedure required considerable manual judgment. The authors had to decide whether a feature was genuinely analogous, find its relevant entry points, understand the surrounding permission or lifecycle rules, and implement a test for the intended security property. The model is therefore reusable guidance, not an automatic scanner. It is also not a proof of absence. Failure to reproduce an attack can reflect a mitigation, an inaccessible test surface, a device-specific control, or a limitation in the mapping. Conversely, finding a vulnerable path in one release does not establish that later releases remain vulnerable.
That caution is especially important for OpenHarmony. The experiments used stock versions 4.1 and 5.1 on an OHarmPi phone, without modifying or recompiling the system. The study later checked the 24 OpenHarmony findings on a commercial HarmonyOS NEXT device and confirmed 20, while filesystem hardening or debugging restrictions prevented evaluation of four. Those results extend the case, but they do not turn related products into one test target or make the findings universal across versions.
The audit model's main contribution is therefore methodological. It preserves the causal content of historical research while removing an unnecessary dependence on Android's source code. It asks what a feature assumes about identity, authority, state, and failure; it then looks for the same assumptions in a different implementation. The next step is to combine this method with the code and component comparison: what does it mean for OpenHarmony to be independent in implementation yet similar enough in design for these tests to apply?