In the vulnerabilities directory there is one json file for each vulnerability. There is one called template.json which is a good starting point for new files and the rest are named according to the name of the vulnerability (with spaces replaced with underscores). All facts need citations, where none is currently available then a [citation-needed] will be printed in the html. As many citations will be reused for multiple facts citations are specified by a reference string and there is a references object with all the details for each reference.
The references object is stored under the key 'references' in the json file. It has a series of key -> object pairs where the key is the reference id and the object is a reference object. The reference object contains key -> string or key -> list string pairs. It contains a url key which lists the url for the reference and may also contain:
"commit":"79b579c92afc08ab12c0a5788d61f2dd2934836f", "component":"platform/system/netd/".In the vulnerability json object dates are either lists of 1 or 2 elements (first being the ISO format date YYYY-MM-DD and second the reference) or they are a date object with a date key pointing to the ISO date string and optionally a bound and a ref key.
Other elements are specified either as a string/list of strings (for authoritative facts like name and submission details) or as 1/2 element lists of value and reference id.
Keys are as follows:
These are obtained from various sources, and give details of the type of vulnerability:
local - this vulnerability can be exploited by a user with physical access to the deviceremote - this vulnerability does not need physical access to the deviceapp - this vulnerability can be exploited by a malicious applicationwebview - this vulnerability can be exploited by malicious code on a webpageusb-debug - this vulnerability requires use of USB debugging to exploitfilesystem - this vulnerability can be exploited by placing crafted files into a specific place in the filesystemsystem-call - this vulnerability can be exploited through system callssms - this vulnerability can be exploited by sending the victim a malicious SMS messagemms - this vulnerability can be exploited by sending the victim a malicious multimedia messageinsufficient-standards-verification - a system component does not properly check standards, which allows a non-compliant app or feature to exploit the vulnerabilityimproper-verification - apps or data are not properly verified, allowing malicious apps or data to be used on the systemmemory-corruption - attacks via buffer overflows and similar methodsdaemon-abusing - exploiting a vulnerability in a daemon to gain privileged access to the systemshared-memory - use of shared memory exploits to escape the sandboxed environmentbad-access-control - improperly set file permissions or other resource access permisionsconcurrency-problem - race conditions and similar issuessymbolic-link - crafted symbolic links can override filesystem protectionother - miscellaneous or not knownapps - a local applicationbrowser - the Android web browsersystem-component - a component of the core OSkernel - the Linux kerneldriver - a device drivertee - Trusted Execution Environmentapp-execution - running an application which exploits the vulnerabilityremote - attacked over a network by a remote userphysical-access - requires physical access to the deviceshell - can be exploited via the ADB shellfile-placement - placement of a crafted file onto the filesystem (either in a particular location or simply in a place where the user will attempt to open it)bluetooth - attack via a Bluetooth connectionaffected-app-installed - an app which can exploit the vulnerability has been installed onto the deviceunknown-source-install-allowed - the option to install apps from non-Google Play sources has been enabledattacker-on-same-network - the attacker has a device connected to the same local network as the victimusb-debug - USB debugging is enabled on the devicefile-placed-onto-device - a crafted file has been placed onto the device's filesystemapp-uses-vulnerable-api-functions - an app in use makes calls to vulnerable API functionsuser-visits-webpage - the user visits a malicious webpagemalicious-file-viewed - the user views a malicious file (which could be delivered in many different ways)attacker-in-close-proximity - the attacker must be located physically close to the device (as with Bluetooth-based attacks)user-has-remote-access - a malicious user already has remote access, and can use this vulnerability to elevate permissionshardware-used-for-attack - the attacker can connect a piece of hardware to the device (usually via the USB port)root - the exploit must already have root accessnone - attack can be performed with no other access to the device, or use of vulnerable appsroot - gain root privilegeskernel - gain full kernel-level privileges (unconstrained by SELinux)user - get access to user-modemodify-apps - allows other apps on the device to be modifiedaccess-to-data - allows an attacker access to a user's personal datasystem - gain access as the system userunlock-bootloader - allows the device's bootloader to be unlockedcontrol-hardware - take control of hardware devicesdenial-of-service - execute a DoS attacktee - execute within the Trusted Execution Environment