Vulnerability Properties
Definition
A vulnerability property is an implicit structural attribute of a flaw, independent of the code that expresses it: that it arises from a data flow, that it requires injection of attacker-controlled content, that it depends on multi-threaded behavior, that it turns on a check-then-use window. Every analysis targets a bounded set of properties and can only find flaws carrying them — explicitly in a static analyzer’s rule set, implicitly in a fuzzer’s mutation strategy or in an unstructured request to a language model.
Yan Shoshitaishvili’s Black Hat USA 2026 keynote proposes making the set explicit and treating it as the input to an agentic discovery pipeline: mine properties out of software that has been studied for years, then apply them to software that has not.1
The properties are the transferable asset, not the findings. A decade of Android security research yields a recipe book that a fresh operating system has never been checked against.
Distinction from adjacent primitives
A vulnerability property is not a vulnerability class such as CWE. A CWE names a defect pattern in a taxonomy built for reporting; a property names what an analysis must be able to reason about to reach that defect at all, and several unrelated CWEs can share one. It is also not a detection signature: the property survives when the code is rewritten in a different language, which a signature does not.
Within the wiki’s harness vocabulary, properties sit upstream of the false-positive controls that dominate the vendor pipelines. Adversarial Reflexion and the ensemble-and-prover designs decide whether a candidate is real. Properties decide which candidates the pipeline generates in the first place, which is a coverage question rather than a precision one.
Evidence
Three results from the same lab carry the claim, each testing a different implication.
Property transfer to unstudied software
Huawei’s OpenHarmony is a from-scratch reimplementation of an Android-inspired operating system, running on a billion devices. The keynote states that no major academic security study of it existed before the lab’s paper, which was due out the week after the talk and unpublished at the time. The pipeline mined a decade-plus of Android security research into a property recipe book, with the mining step agentically assisted, then used those properties to guide manual review of millions of lines of OpenHarmony source.
Roughly every property applied specifically produced a new zero-day. The reported yield is dozens of flaws spanning Bluetooth device takeover and location and privacy leaks. An agentic version of the pipeline is running, with results held for a later talk.1
Properties as a harness multiplier at fixed model capability
The lab ran a Linux-kernel discovery pipeline in three configurations while holding the model generation constant, against a benchmark of 479 kernel vulnerabilities attributed to Mythos in a June 2026 Washington Post report:
| Configuration | Triaged findings | Increment |
|---|---|---|
| Dozens of last-generation GPT instances, no workflow | ~300 | baseline |
| Workflow added (adversarial review, planning), narrowed to three instances | ~600 | ~2× from orchestration |
| Vulnerability properties added, formatted for the pipeline | over 1,000 | a further ~2× from properties |
Every count is a local privilege escalation triggerable by an unprivileged user, triaged as real. The keynote states the comparison against 479 is apples-to-oranges, since published counts typically include root-only bugs.1
Two features of the design carry the inference. The model generation is fixed across all three rows, so nothing in the delta is attributable to model capability. And the second row reduces parallelism from dozens of instances to three while doubling the yield, which separates orchestration quality from compute spend — a separation no vendor report on the frontier-AI axis makes. The counts are the lab’s own triage and the keynote reports no repeated runs, so the design bounds what the delta can be attributed to rather than establishing an effect size.
Properties survive a language rewrite
Agents reimplemented load-bearing C libraries — libssl, libpng, libxml among them — as millions of lines of Rust behind an assurance pipeline. Memory-corruption properties did not survive the language change, as intended. The others did. The crypto library reproduced the classic non-memory-safety cryptographic attacks the original was vulnerable to, including under explicit instruction naming those historical vulnerabilities and forbidding them.
The independent confirmation is not the speaker’s project: 79 CVEs dropped against a Rust reimplementation of coreutils after it shipped in the current Ubuntu release, carrying time-of-check/time-of-use flaws in critical utilities rather than memory corruption.1
Consequence for memory-safe rewrites
A memory-safe rewrite retires exactly the property set the language addresses and leaves every other property in place. Agent-assisted rewriting changes the economics of attempting one at the scale of millions of lines without changing that arithmetic, and the coreutils cohort shows the residue reaching production through a distribution release.
Two operational implications follow for anyone planning a rewrite as a security control:
- The threat model must be re-derived, not inherited. The pre-rewrite vulnerability history tells you which properties the original code was predisposed to. Those minus the memory-safety set are the ones the rewrite still carries.
- Instructing the model is not a control. The keynote’s strongest evidence here is negative: naming the specific historical vulnerabilities in the prompt and forbidding them did not prevent their reappearance. Whatever assurance the rewrite gets has to come from analysis of the output.
Agent-driven formal verification to eliminate the residual logic errors is named in the keynote as a research direction and explicitly not a present capability at scale.
Property extraction is undocumented as a method
The keynote reports the results of property extraction across three studies and does not specify how properties are represented, how the agentic mining step decides what counts as one, or what “the correct format to present them to our agentic pipeline” means in practice — which is the step the final ~2× is attributed to. The OpenHarmony paper was unpublished at talk time, so no reproducible description exists on the wiki.
Single-source concept
Every figure and the framing come from one keynote by one lab, with no external verification, no published corpus, and no peer-reviewed artifact available at time of ingest. The Linux-kernel counts are the lab’s own triage.
Footnotes
-
Yan Shoshitaishvili, Keynote: Vulnerability Research in the Agentic Age, Black Hat USA 2026 (2026-08-06). See the talk summary. ↩ ↩2 ↩3 ↩4