WARNING: A New Android Zero-Day Vulnerability Is Under Active Attack

2021-03-23T05:33:00

Description

[![](https://thehackernews.com/images/-fZV9AOkLFZw/YFl4ojMBVdI/AAAAAAAACFY/lDGhJ2azIxIuCePPX34BZU4H_0mtmSfrgCLcBGAsYHQ/s0/android-adb-hack.png)](<https://thehackernews.com/images/-fZV9AOkLFZw/YFl4ojMBVdI/AAAAAAAACFY/lDGhJ2azIxIuCePPX34BZU4H_0mtmSfrgCLcBGAsYHQ/s0/android-adb-hack.png>) Google has disclosed that a now-patched vulnerability affecting Android devices that use Qualcomm chipsets is being weaponized by adversaries to launch targeted attacks. Tracked as **CVE-2020-11261** (CVSS score 8.4), the flaw [concerns](<https://www.qualcomm.com/company/product-security/bulletins/january-2021-bulletin>) an "improper input validation" issue in Qualcomm's Graphics component that could be exploited to trigger memory corruption when an attacker-engineered app requests access to a huge chunk of the device's memory. "There are indications that CVE-2020-11261 may be under limited, targeted exploitation," the search giant [said](<https://source.android.com/security/bulletin/2021-01-01>) in an updated January security bulletin on March 18. CVE-2020-11261 was discovered and reported to Qualcomm by Google's Android Security team on July 20, 2020, after which it was fixed in January 2021. [![](https://thehackernews.com/images/-hngRw5Tf0vA/YFl3-qMvHtI/AAAAAAAACFQ/DZiVZPyGy7gyqDc233jO0YbxnggQbhdrwCLcBGAsYHQ/s0/android.jpg)](<https://thehackernews.com/images/-hngRw5Tf0vA/YFl3-qMvHtI/AAAAAAAACFQ/DZiVZPyGy7gyqDc233jO0YbxnggQbhdrwCLcBGAsYHQ/s0/android.jpg>) It's worth noting that the access vector for the vulnerability is "local," meaning that exploitation requires local access to the device. In other words, to launch a successful attack, the bad actor must either have physical access to the vulnerable smartphone or use other means - e.g., a [watering hole](<https://en.wikipedia.org/wiki/Watering_hole_attack>) \- to deliver malicious code and set off the attack chain. While specifics about the attacks, the identity of the attacker, and the targeted victims have not been released, it is not unusual for Google to withhold sharing such information to prevent other threat actors from taking advantage of the vulnerability. If anything, the development once again underscores the need to promptly install monthly security updates as soon as they are available to prevent Android devices from being exploited. We've reached out to Google for comment and will update this article if we hear back. Found this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter __](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.

{"id": "THN:EF60CC49D6364DA3E070A9958D3CCDB7", "vendorId": null, "type": "thn", "bulletinFamily": "info", "title": "WARNING: A New Android Zero-Day Vulnerability Is Under Active Attack", "description": "[![](https://thehackernews.com/images/-fZV9AOkLFZw/YFl4ojMBVdI/AAAAAAAACFY/lDGhJ2azIxIuCePPX34BZU4H_0mtmSfrgCLcBGAsYHQ/s0/android-adb-hack.png)](<https://thehackernews.com/images/-fZV9AOkLFZw/YFl4ojMBVdI/AAAAAAAACFY/lDGhJ2azIxIuCePPX34BZU4H_0mtmSfrgCLcBGAsYHQ/s0/android-adb-hack.png>)\n\nGoogle has disclosed that a now-patched vulnerability affecting Android devices that use Qualcomm chipsets is being weaponized by adversaries to launch targeted attacks.\n\nTracked as **CVE-2020-11261** (CVSS score 8.4), the flaw [concerns](<https://www.qualcomm.com/company/product-security/bulletins/january-2021-bulletin>) an \"improper input validation\" issue in Qualcomm's Graphics component that could be exploited to trigger memory corruption when an attacker-engineered app requests access to a huge chunk of the device's memory.\n\n\"There are indications that CVE-2020-11261 may be under limited, targeted exploitation,\" the search giant [said](<https://source.android.com/security/bulletin/2021-01-01>) in an updated January security bulletin on March 18.\n\nCVE-2020-11261 was discovered and reported to Qualcomm by Google's Android Security team on July 20, 2020, after which it was fixed in January 2021.\n\n[![](https://thehackernews.com/images/-hngRw5Tf0vA/YFl3-qMvHtI/AAAAAAAACFQ/DZiVZPyGy7gyqDc233jO0YbxnggQbhdrwCLcBGAsYHQ/s0/android.jpg)](<https://thehackernews.com/images/-hngRw5Tf0vA/YFl3-qMvHtI/AAAAAAAACFQ/DZiVZPyGy7gyqDc233jO0YbxnggQbhdrwCLcBGAsYHQ/s0/android.jpg>)\n\nIt's worth noting that the access vector for the vulnerability is \"local,\" meaning that exploitation requires local access to the device. In other words, to launch a successful attack, the bad actor must either have physical access to the vulnerable smartphone or use other means - e.g., a [watering hole](<https://en.wikipedia.org/wiki/Watering_hole_attack>) \\- to deliver malicious code and set off the attack chain.\n\nWhile specifics about the attacks, the identity of the attacker, and the targeted victims have not been released, it is not unusual for Google to withhold sharing such information to prevent other threat actors from taking advantage of the vulnerability.\n\nIf anything, the development once again underscores the need to promptly install monthly security updates as soon as they are available to prevent Android devices from being exploited. We've reached out to Google for comment and will update this article if we hear back.\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "published": "2021-03-23T05:33:00", "modified": "2021-03-23T10:57:24", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}, "cvss2": {"cvssV2": {"version": "2.0", "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "accessVector": "LOCAL", "accessComplexity": "LOW", "authentication": "NONE", "confidentialityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "baseScore": 7.2}, "severity": "HIGH", "exploitabilityScore": 3.9, "impactScore": 10.0, "acInsufInfo": false, "obtainAllPrivilege": false, "obtainUserPrivilege": false, "obtainOtherPrivilege": false, "userInteractionRequired": false}, "cvss3": {"cvssV3": {"version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "attackVector": "LOCAL", "attackComplexity": "LOW", "privilegesRequired": "LOW", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "availabilityImpact": "HIGH", "baseScore": 7.8, "baseSeverity": "HIGH"}, "exploitabilityScore": 1.8, "impactScore": 5.9}, "href": "https://thehackernews.com/2021/03/warning-new-android-zero-day.html", "reporter": "The Hacker News", "references": [], "cvelist": ["CVE-2020-11261"], "immutableFields": [], "lastseen": "2022-05-09T12:38:25", "viewCount": 92, "enchantments": {"dependencies": {"references": [{"type": "androidsecurity", "idList": ["ANDROID:2021-01-01"]}, {"type": "attackerkb", "idList": ["AKB:AAE507C1-8527-4F4A-9456-38A03B4A132E"]}, {"type": "cisa", "idList": ["CISA:72D01121CAFBC56638BC974ABA539CF8"]}, {"type": "cve", "idList": ["CVE-2020-11261"]}, {"type": "googleprojectzero", "idList": ["GOOGLEPROJECTZERO:CA925EE6A931620550EF819815B14156"]}, {"type": "thn", "idList": ["THN:37E4ECDE5CC5E074EC9FD4DF79D85121", "THN:9CE461E69A8B499207911497E3A349FD"]}, {"type": "threatpost", "idList": ["THREATPOST:17E00AD621A0ECD9F90FE97E083BF4AC", "THREATPOST:38BE049C6C451ED1B9E3037B2EA65D9A"]}]}, "score": {"value": -0.2, "vector": "NONE"}, "backreferences": {"references": [{"type": "androidsecurity", "idList": ["ANDROID:2021-01-01"]}, {"type": "attackerkb", "idList": ["AKB:AAE507C1-8527-4F4A-9456-38A03B4A132E"]}, {"type": "cisa", "idList": ["CISA:72D01121CAFBC56638BC974ABA539CF8"]}, {"type": "cve", "idList": ["CVE-2020-11261"]}, {"type": "thn", "idList": ["THN:9CE461E69A8B499207911497E3A349FD"]}, {"type": "threatpost", "idList": ["THREATPOST:17E00AD621A0ECD9F90FE97E083BF4AC", "THREATPOST:38BE049C6C451ED1B9E3037B2EA65D9A"]}]}, "exploitation": null, "vulnersScore": -0.2}, "_state": {"dependencies": 1659994789, "score": 1659896800}, "_internal": {"score_hash": "845b4c3707743483425c08c2ce228fa4"}}

{"cisa_kev": [{"lastseen": "2022-08-10T17:26:47", "description": "Memory corruption due to improper check to return error when user application requests memory allocation of a huge size in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables", "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 7.8, "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-12-01T00:00:00", "type": "cisa_kev", "title": "Qualcomm Multiple Chipsets Improper Input Validation Vulnerability", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 3.9, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 7.2, "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "LOCAL", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-11261"], "modified": "2021-12-01T00:00:00", "id": "CISA-KEV-CVE-2020-11261", "href": "", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}], "attackerkb": [{"lastseen": "2022-10-06T05:06:37", "description": "Memory corruption due to improper check to return error when user application requests memory allocation of a huge size in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables\n\n \n**Recent assessments:** \n \nAssessed Attacker Value: 0 \nAssessed Attacker Value: 0Assessed Attacker Value: 0\n", "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 7.8, "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-06-09T00:00:00", "type": "attackerkb", "title": "CVE-2020-11261", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 3.9, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 7.2, "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "LOCAL", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-11261"], "modified": "2021-06-17T00:00:00", "id": "AKB:AAE507C1-8527-4F4A-9456-38A03B4A132E", "href": "https://attackerkb.com/topics/MYehmFmVBc/cve-2020-11261", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}], "cve": [{"lastseen": "2022-03-23T12:12:42", "description": "Memory corruption due to improper check to return error when user application requests memory allocation of a huge size in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables", "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 7.8, "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-06-09T05:15:00", "type": "cve", "title": "CVE-2020-11261", "cwe": ["CWE-20"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 3.9, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 7.2, "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "LOCAL", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-11261"], "modified": "2021-06-16T18:28:00", "cpe": ["cpe:/o:qualcomm:qpm8895_firmware:-", "cpe:/o:qualcomm:qpa8821_firmware:-", "cpe:/o:qualcomm:wcd9326_firmware:-", "cpe:/o:qualcomm:qet4101_firmware:-", "cpe:/o:qualcomm:rsw8577_firmware:-", "cpe:/o:qualcomm:qcs405_firmware:-", "cpe:/o:qualcomm:qpa4360_firmware:-", "cpe:/o:qualcomm:sdx20m_firmware:-", "cpe:/o:qualcomm:qca6320_firmware:-", "cpe:/o:qualcomm:smb231_firmware:-", "cpe:/o:qualcomm:sd_455_firmware:-", "cpe:/o:qualcomm:qbt1000_firmware:-", "cpe:/o:qualcomm:wcn3660_firmware:-", "cpe:/o:qualcomm:pm3003a_firmware:-", "cpe:/o:qualcomm:qca6391_firmware:-", "cpe:/o:qualcomm:sd632_firmware:-", "cpe:/o:qualcomm:smb1351_firmware:-", "cpe:/o:qualcomm:qca6430_firmware:-", "cpe:/o:qualcomm:msm8920_firmware:-", "cpe:/o:qualcomm:qca4020_firmware:-", "cpe:/o:qualcomm:sd675_firmware:-", "cpe:/o:qualcomm:pm7150a_firmware:-", "cpe:/o:qualcomm:csra6620_firmware:-", "cpe:/o:qualcomm:wsa8810_firmware:-", "cpe:/o:qualcomm:sa515m_firmware:-", "cpe:/o:qualcomm:qsm7250_firmware:-", "cpe:/o:qualcomm:qsm8250_firmware:-", "cpe:/o:qualcomm:pmi8996_firmware:-", "cpe:/o:qualcomm:qca6335_firmware:-", "cpe:/o:qualcomm:qfe4301_firmware:-", "cpe:/o:qualcomm:wsa8835_firmware:-", "cpe:/o:qualcomm:fsm10056_firmware:-", "cpe:/o:qualcomm:pmi8937_firmware:-", "cpe:/o:qualcomm:sd_675_firmware:-", "cpe:/o:qualcomm:ar8151_firmware:-", "cpe:/o:qualcomm:qat5515_firmware:-", "cpe:/o:qualcomm:wcn3680b_firmware:-", "cpe:/o:qualcomm:sd730_firmware:-", "cpe:/o:qualcomm:pm215_firmware:-", "cpe:/o:qualcomm:pm439_firmware:-", "cpe:/o:qualcomm:wcn3615_firmware:-", "cpe:/o:qualcomm:sd835_firmware:-", "cpe:/o:qualcomm:pm8350bh_firmware:-", "cpe:/o:qualcomm:qtm527_firmware:-", "cpe:/o:qualcomm:qsw8574_firmware:-", "cpe:/o:qualcomm:msm8909w_firmware:-", "cpe:/o:qualcomm:apq8017_firmware:-", "cpe:/o:qualcomm:qca6574au_firmware:-", "cpe:/o:qualcomm:qpm8830_firmware:-", "cpe:/o:qualcomm:qfe4305_firmware:-", "cpe:/o:qualcomm:qfe2520_firmware:-", "cpe:/o:qualcomm:sd820_firmware:-", "cpe:/o:qualcomm:qdm2310_firmware:-", "cpe:/o:qualcomm:sd768g_firmware:-", "cpe:/o:qualcomm:csra6640_firmware:-", "cpe:/o:qualcomm:qln4642_firmware:-", "cpe:/o:qualcomm:qca6584au_firmware:-", "cpe:/o:qualcomm:qln4650_firmware:-", "cpe:/o:qualcomm:pm670_firmware:-", "cpe:/o:qualcomm:qpa5580_firmware:-", "cpe:/o:qualcomm:sd460_firmware:-", "cpe:/o:qualcomm:sm4125_firmware:-", "cpe:/o:qualcomm:pm7250_firmware:-", "cpe:/o:qualcomm:smb1358_firmware:-", "cpe:/o:qualcomm:qfs2608_firmware:-", "cpe:/o:qualcomm:sdx55_firmware:-", "cpe:/o:qualcomm:qpa5461_firmware:-", "cpe:/o:qualcomm:sdw3100_firmware:-", "cpe:/o:qualcomm:sm4350_firmware:-", "cpe:/o:qualcomm:wcd9375_firmware:-", "cpe:/o:qualcomm:qfe2550_firmware:-", "cpe:/o:qualcomm:wtr2955_firmware:-", "cpe:/o:qualcomm:qca6421_firmware:-", "cpe:/o:qualcomm:qcc1110_firmware:-", "cpe:/o:qualcomm:sdr660g_firmware:-", "cpe:/o:qualcomm:wcd9341_firmware:-", "cpe:/o:qualcomm:qpm6582_firmware:-", "cpe:/o:qualcomm:qualcomm215_firmware:-", "cpe:/o:qualcomm:sd855_firmware:-", "cpe:/o:qualcomm:qca9377_firmware:-", "cpe:/o:qualcomm:smb1396_firmware:-", "cpe:/o:qualcomm:qpm5658_firmware:-", "cpe:/o:qualcomm:qat3519_firmware:-", "cpe:/o:qualcomm:pm6350_firmware:-", "cpe:/o:qualcomm:pm8150c_firmware:-", "cpe:/o:qualcomm:pmk7350_firmware:-", "cpe:/o:qualcomm:qpm5677_firmware:-", "cpe:/o:qualcomm:qcs410_firmware:-", "cpe:/o:qualcomm:pm660l_firmware:-", "cpe:/o:qualcomm:sdr425_firmware:-", "cpe:/o:qualcomm:wtr5975_firmware:-", "cpe:/o:qualcomm:qcm6125_firmware:-", "cpe:/o:qualcomm:qat3518_firmware:-", "cpe:/o:qualcomm:qln5020_firmware:-", "cpe:/o:qualcomm:csrb31024_firmware:-", "cpe:/o:qualcomm:qln1021aq_firmware:-", "cpe:/o:qualcomm:sd865_5g_firmware:-", "cpe:/o:qualcomm:qdm3302_firmware:-", "cpe:/o:qualcomm:qpm4630_firmware:-", "cpe:/o:qualcomm:qpm6621_firmware:-", "cpe:/o:qualcomm:qet5100_firmware:-", "cpe:/o:qualcomm:sd821_firmware:-", "cpe:/o:qualcomm:pmk8350_firmware:-", "cpe:/o:qualcomm:qtc800h_firmware:-", "cpe:/o:qualcomm:qat3522_firmware:-", "cpe:/o:qualcomm:qdm5579_firmware:-", "cpe:/o:qualcomm:wcn3610_firmware:-", "cpe:/o:qualcomm:qfe4308_firmware:-", "cpe:/o:qualcomm:msm8940_firmware:-", "cpe:/o:qualcomm:sd450_firmware:-", "cpe:/o:qualcomm:wcd9340_firmware:-", "cpe:/o:qualcomm:qln5030_firmware:-", "cpe:/o:qualcomm:sd710_firmware:-", "cpe:/o:qualcomm:wtr3925_firmware:-", "cpe:/o:qualcomm:sdm830_firmware:-", "cpe:/o:qualcomm:qpa5460_firmware:-", "cpe:/o:qualcomm:sd_8c_firmware:-", "cpe:/o:qualcomm:pmr525_firmware:-", "cpe:/o:qualcomm:sdm429w_firmware:-", "cpe:/o:qualcomm:pm8004_firmware:-", "cpe:/o:qualcomm:sd765g_firmware:-", "cpe:/o:qualcomm:wcn3950_firmware:-", "cpe:/o:qualcomm:smr525_firmware:-", "cpe:/o:qualcomm:wcd9385_firmware:-", "cpe:/o:qualcomm:smb1390_firmware:-", "cpe:/o:qualcomm:qet6110_firmware:-", "cpe:/o:qualcomm:qat3555_firmware:-", "cpe:/o:qualcomm:sd429_firmware:-", "cpe:/o:qualcomm:pmk8002_firmware:-", "cpe:/o:qualcomm:sdx20_firmware:-", "cpe:/o:qualcomm:sa415m_firmware:-", "cpe:/o:qualcomm:pm8150b_firmware:-", "cpe:/o:qualcomm:qca6420_firmware:-", "cpe:/o:qualcomm:fsm10055_firmware:-", "cpe:/o:qualcomm:apq8096au_firmware:-", "cpe:/o:qualcomm:qca6436_firmware:-", "cpe:/o:qualcomm:sa6145p_firmware:-", "cpe:/o:qualcomm:wcn3999_firmware:-", "cpe:/o:qualcomm:qdm2307_firmware:-", "cpe:/o:qualcomm:sdxr2_5g_firmware:-", "cpe:/o:qualcomm:pm8150a_firmware:-", "cpe:/o:qualcomm:qpm2630_firmware:-", "cpe:/o:qualcomm:pm6150l_firmware:-", "cpe:/o:qualcomm:sm6250p_firmware:-", "cpe:/o:qualcomm:qcs6125_firmware:-", "cpe:/o:qualcomm:apq8009_firmware:-", "cpe:/o:qualcomm:sd670_firmware:-", "cpe:/o:qualcomm:pm8250_firmware:-", "cpe:/o:qualcomm:sdx24_firmware:-", "cpe:/o:qualcomm:qat3514_firmware:-", "cpe:/o:qualcomm:pmi8998_firmware:-", "cpe:/o:qualcomm:qpm8870_firmware:-", "cpe:/o:qualcomm:qpa4361_firmware:-", "cpe:/o:qualcomm:qpa8802_firmware:-", "cpe:/o:qualcomm:qpm6670_firmware:-", "cpe:/o:qualcomm:msm8937_firmware:-", "cpe:/o:qualcomm:wsa8815_firmware:-", "cpe:/o:qualcomm:qfe2101_firmware:-", "cpe:/o:qualcomm:smb1398_firmware:-", "cpe:/o:qualcomm:qca6574_firmware:-", "cpe:/o:qualcomm:qpm5621_firmware:-", "cpe:/o:qualcomm:sd205_firmware:-", "cpe:/o:qualcomm:sd665_firmware:-", "cpe:/o:qualcomm:qca6564au_firmware:-", "cpe:/o:qualcomm:sm7350_firmware:-", "cpe:/o:qualcomm:sdw2500_firmware:-", "cpe:/o:qualcomm:qcs610_firmware:-", "cpe:/o:qualcomm:pm7150l_firmware:-", "cpe:/o:qualcomm:qpa6560_firmware:-", "cpe:/o:qualcomm:wtr6955_firmware:-", "cpe:/o:qualcomm:pmw3100_firmware:-", "cpe:/o:qualcomm:wcn3990_firmware:-", "cpe:/o:qualcomm:qpa2625_firmware:-", "cpe:/o:qualcomm:qpm5679_firmware:-", "cpe:/o:qualcomm:sda429w_firmware:-", "cpe:/o:qualcomm:qfs2630_firmware:-", "cpe:/o:qualcomm:qat3516_firmware:-", "cpe:/o:qualcomm:pmx50_firmware:-", "cpe:/o:qualcomm:qdm5671_firmware:-", "cpe:/o:qualcomm:qdm3301_firmware:-", "cpe:/o:qualcomm:wcn6750_firmware:-", "cpe:/o:qualcomm:qdm5620_firmware:-", "cpe:/o:qualcomm:qpm5579_firmware:-", "cpe:/o:qualcomm:qfe4320_firmware:-", "cpe:/o:qualcomm:sdr675_firmware:-", "cpe:/o:qualcomm:smb1360_firmware:-", "cpe:/o:qualcomm:wgr7640_firmware:-", "cpe:/o:qualcomm:qat5533_firmware:-", "cpe:/o:qualcomm:wcn6856_firmware:-", "cpe:/o:qualcomm:qfe4309_firmware:-", "cpe:/o:qualcomm:qtc801s_firmware:-", "cpe:/o:qualcomm:sa6155_firmware:-", "cpe:/o:qualcomm:smb1395_firmware:-", "cpe:/o:qualcomm:pm640p_firmware:-", "cpe:/o:qualcomm:qcs2290_firmware:-", "cpe:/o:qualcomm:qca6174a_firmware:-", "cpe:/o:qualcomm:sdr8250_firmware:-", "cpe:/o:qualcomm:wcn3660b_firmware:-", "cpe:/o:qualcomm:qfe4303_firmware:-", "cpe:/o:qualcomm:qpm5875_firmware:-", "cpe:/o:qualcomm:wcd9371_firmware:-", "cpe:/o:qualcomm:pm8150l_firmware:-", "cpe:/o:qualcomm:qpm4621_firmware:-", "cpe:/o:qualcomm:pm670a_firmware:-", "cpe:/o:qualcomm:pm8998_firmware:-", "cpe:/o:qualcomm:sm7250p_firmware:-", "cpe:/o:qualcomm:aqt1000_firmware:-", "cpe:/o:qualcomm:wsa8830_firmware:-", "cpe:/o:qualcomm:msm8996au_firmware:-", "cpe:/o:qualcomm:pm8940_firmware:-", "cpe:/o:qualcomm:sdxr1_firmware:-", "cpe:/o:qualcomm:sd660_firmware:-", "cpe:/o:qualcomm:qpm5620_firmware:-", "cpe:/o:qualcomm:qdm5650_firmware:-", "cpe:/o:qualcomm:pm8150_firmware:-", "cpe:/o:qualcomm:pmk8003_firmware:-", "cpe:/o:qualcomm:pmk8001_firmware:-", "cpe:/o:qualcomm:qca6390_firmware:-", "cpe:/o:qualcomm:pmd9655_firmware:-", "cpe:/o:qualcomm:qpm8820_firmware:-", "cpe:/o:qualcomm:rgr7640au_firmware:-", "cpe:/o:qualcomm:qdm5679_firmware:-", "cpe:/o:qualcomm:qpa8673_firmware:-", "cpe:/o:qualcomm:pmm8996au_firmware:-", "cpe:/o:qualcomm:pm4125_firmware:-", "cpe:/o:qualcomm:qca6564_firmware:-", "cpe:/o:qualcomm:qln1030_firmware:-", "cpe:/o:qualcomm:qca6426_firmware:-", "cpe:/o:qualcomm:smb1355_firmware:-", "cpe:/o:qualcomm:sd439_firmware:-", "cpe:/o:qualcomm:qdm5677_firmware:-", "cpe:/o:qualcomm:sd750g_firmware:-", "cpe:/o:qualcomm:qpm5657_firmware:-", "cpe:/o:qualcomm:pm6150_firmware:-", "cpe:/o:qualcomm:sd765_firmware:-", "cpe:/o:qualcomm:wcn3980_firmware:-", "cpe:/o:qualcomm:pm8953_firmware:-", "cpe:/o:qualcomm:pmm6155au_firmware:-", "cpe:/o:qualcomm:qpm6325_firmware:-", "cpe:/o:qualcomm:qln1036aq_firmware:-", "cpe:/o:qualcomm:smb1354_firmware:-", "cpe:/o:qualcomm:qpm4641_firmware:-", "cpe:/o:qualcomm:qpm5870_firmware:-", "cpe:/o:qualcomm:ar8031_firmware:-", "cpe:/o:qualcomm:wcn3991_firmware:-", "cpe:/o:qualcomm:sd720g_firmware:-", "cpe:/o:qualcomm:pm640a_firmware:-", "cpe:/o:qualcomm:pmc1000h_firmware:-", "cpe:/o:qualcomm:qat5568_firmware:-", "cpe:/o:qualcomm:sa6155p_firmware:-", "cpe:/o:qualcomm:sdr845_firmware:-", "cpe:/o:qualcomm:mdm9650_firmware:-", "cpe:/o:qualcomm:wcd9370_firmware:-", "cpe:/o:qualcomm:sdr051_firmware:-", "cpe:/o:qualcomm:pm660_firmware:-", "cpe:/o:qualcomm:qdm2308_firmware:-", "cpe:/o:qualcomm:sm6250_firmware:-", "cpe:/o:qualcomm:pm6125_firmware:-", "cpe:/o:qualcomm:sdr8150_firmware:-", "cpe:/o:qualcomm:qca6431_firmware:-", "cpe:/o:qualcomm:qcs605_firmware:-", "cpe:/o:qualcomm:wcd9380_firmware:-", "cpe:/o:qualcomm:qln5040_firmware:-", "cpe:/o:qualcomm:qsw8573_firmware:-", "cpe:/o:qualcomm:pm8916_firmware:-", "cpe:/o:qualcomm:qpa8675_firmware:-", "cpe:/o:qualcomm:qpm4640_firmware:-", "cpe:/o:qualcomm:wtr3905_firmware:-", "cpe:/o:qualcomm:qpm6375_firmware:-", "cpe:/o:qualcomm:qat5516_firmware:-", "cpe:/o:qualcomm:pm640l_firmware:-", "cpe:/o:qualcomm:sd845_firmware:-", "cpe:/o:qualcomm:qpa5581_firmware:-", "cpe:/o:qualcomm:qpa8801_firmware:-", "cpe:/o:qualcomm:apq8009w_firmware:-", "cpe:/o:qualcomm:qcm4290_firmware:-", "cpe:/o:qualcomm:qfe3340_firmware:-", "cpe:/o:qualcomm:pm8005_firmware:-", "cpe:/o:qualcomm:pm855p_firmware:-", "cpe:/o:qualcomm:pm8350c_firmware:-", "cpe:/o:qualcomm:sd888_5g_firmware:-", "cpe:/o:qualcomm:wcn3910_firmware:-", "cpe:/o:qualcomm:qpa8842_firmware:-", "cpe:/o:qualcomm:pm8350bhs_firmware:-", "cpe:/o:qualcomm:qdm4650_firmware:-", "cpe:/o:qualcomm:wcn3680_firmware:-", "cpe:/o:qualcomm:pm670l_firmware:-", "cpe:/o:qualcomm:apq8053_firmware:-", "cpe:/o:qualcomm:sdr052_firmware:-", "cpe:/o:qualcomm:apq8064au_firmware:-", "cpe:/o:qualcomm:qca8337_firmware:-", "cpe:/o:qualcomm:qet5100m_firmware:-", "cpe:/o:qualcomm:sdr735g_firmware:-", "cpe:/o:qualcomm:wtr3950_firmware:-", "cpe:/o:qualcomm:msm8953_firmware:-", "cpe:/o:qualcomm:pm456_firmware:-", "cpe:/o:qualcomm:qpm5670_firmware:-", "cpe:/o:qualcomm:ar8035_firmware:-", "cpe:/o:qualcomm:pmx20_firmware:-", "cpe:/o:qualcomm:wcn6850_firmware:-", "cpe:/o:qualcomm:qdm4643_firmware:-", "cpe:/o:qualcomm:pmm855au_firmware:-", "cpe:/o:qualcomm:pm8008_firmware:-", "cpe:/o:qualcomm:qfs2530_firmware:-", "cpe:/o:qualcomm:pm8009_firmware:-", "cpe:/o:qualcomm:wtr4905_firmware:-", "cpe:/o:qualcomm:smb1350_firmware:-", "cpe:/o:qualcomm:pmx24_firmware:-", "cpe:/o:qualcomm:qca6595au_firmware:-", "cpe:/o:qualcomm:qca6574a_firmware:-", "cpe:/o:qualcomm:qdm5652_firmware:-", "cpe:/o:qualcomm:wcn6851_firmware:-", "cpe:/o:qualcomm:qpm5641_firmware:-", "cpe:/o:qualcomm:qtc800t_firmware:-", "cpe:/o:qualcomm:sdr865_firmware:-", "cpe:/o:qualcomm:qbt2000_firmware:-", "cpe:/o:qualcomm:pm7350c_firmware:-", "cpe:/o:qualcomm:pm8350b_firmware:-", "cpe:/o:qualcomm:pmx55_firmware:-", "cpe:/o:qualcomm:wcd9335_firmware:-", "cpe:/o:qualcomm:pm8909_firmware:-", "cpe:/o:qualcomm:qpa8686_firmware:-", "cpe:/o:qualcomm:qsw6310_firmware:-", "cpe:/o:qualcomm:pm855b_firmware:-", "cpe:/o:qualcomm:sd_8cx_firmware:-", "cpe:/o:qualcomm:wtr2965_firmware:-", "cpe:/o:qualcomm:qca6564a_firmware:-", "cpe:/o:qualcomm:qpa8803_firmware:-", "cpe:/o:qualcomm:sd210_firmware:-", "cpe:/o:qualcomm:smb1380_firmware:-", "cpe:/o:qualcomm:qat3550_firmware:-", "cpe:/o:qualcomm:pmm8155au_firmware:-", "cpe:/o:qualcomm:smb2351_firmware:-", "cpe:/o:qualcomm:smr526_firmware:-", "cpe:/o:qualcomm:qdm2301_firmware:-", "cpe:/o:qualcomm:qfs2580_firmware:-", "cpe:/o:qualcomm:wcn6740_firmware:-", "cpe:/o:qualcomm:qfe4302_firmware:-", "cpe:/o:qualcomm:qet4100_firmware:-", "cpe:/o:qualcomm:wcn3988_firmware:-", "cpe:/o:qualcomm:sdr660_firmware:-", "cpe:/o:qualcomm:qat5522_firmware:-", "cpe:/o:qualcomm:pm6250_firmware:-", "cpe:/o:qualcomm:qfe4373fc_firmware:-", "cpe:/o:qualcomm:sdr735_firmware:-", "cpe:/o:qualcomm:sd_636_firmware:-", "cpe:/o:qualcomm:qpm5577_firmware:-", "cpe:/o:qualcomm:pm855a_firmware:-", "cpe:/o:qualcomm:pmi8952_firmware:-", "cpe:/o:qualcomm:pm8937_firmware:-", "cpe:/o:qualcomm:pmi632_firmware:-", "cpe:/o:qualcomm:qpm4650_firmware:-", "cpe:/o:qualcomm:sa8155p_firmware:-", "cpe:/o:qualcomm:pm855_firmware:-", "cpe:/o:qualcomm:pme605_firmware:-", "cpe:/o:qualcomm:sa8155_firmware:-", "cpe:/o:qualcomm:qln4640_firmware:-", "cpe:/o:qualcomm:wcn3620_firmware:-", "cpe:/o:qualcomm:qca9379_firmware:-", "cpe:/o:qualcomm:pmr735a_firmware:-", "cpe:/o:qualcomm:qpm6585_firmware:-", "cpe:/o:qualcomm:wcn3998_firmware:-", "cpe:/o:qualcomm:qln1031_firmware:-", "cpe:/o:qualcomm:qca6310_firmware:-", "cpe:/o:qualcomm:smb1394_firmware:-", "cpe:/o:qualcomm:apq8037_firmware:-", "cpe:/o:qualcomm:qtc410s_firmware:-", "cpe:/o:qualcomm:qdm5621_firmware:-", "cpe:/o:qualcomm:pm8996_firmware:-", "cpe:/o:qualcomm:smb1357_firmware:-", "cpe:/o:qualcomm:pm8350_firmware:-", "cpe:/o:qualcomm:pmi8994_firmware:-", "cpe:/o:qualcomm:sdx55m_firmware:-", "cpe:/o:qualcomm:qcm2290_firmware:-", "cpe:/o:qualcomm:pm7250b_firmware:-", "cpe:/o:qualcomm:sd662_firmware:-", "cpe:/o:qualcomm:qdm2302_firmware:-", "cpe:/o:qualcomm:smb1381_firmware:-", "cpe:/o:qualcomm:pm660a_firmware:-", "cpe:/o:qualcomm:pm855l_firmware:-", "cpe:/o:qualcomm:qpm5541_firmware:-", "cpe:/o:qualcomm:qtm525_firmware:-", "cpe:/o:qualcomm:sd690_5g_firmware:-", "cpe:/o:qualcomm:qtc800s_firmware:-", "cpe:/o:qualcomm:qdm2305_firmware:-", "cpe:/o:qualcomm:qcs4290_firmware:-", "cpe:/o:qualcomm:sdm630_firmware:-", "cpe:/o:qualcomm:qbt1500_firmware:-", "cpe:/o:qualcomm:msm8917_firmware:-", "cpe:/o:qualcomm:sdx50m_firmware:-", "cpe:/o:qualcomm:qcs603_firmware:-", "cpe:/o:qualcomm:qca6696_firmware:-", "cpe:/o:qualcomm:pm6150a_firmware:-", "cpe:/o:qualcomm:qet6100_firmware:-", "cpe:/o:qualcomm:qpa5373_firmware:-", "cpe:/o:qualcomm:qln1020_firmware:-", "cpe:/o:qualcomm:pmr735b_firmware:-", "cpe:/o:qualcomm:qpa4340_firmware:-", "cpe:/o:qualcomm:qdm5670_firmware:-"], "id": "CVE-2020-11261", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11261", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}, "cpe23": ["cpe:2.3:o:qualcomm:pmx55_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sa6155_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sa6155p_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfe4320_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd765g_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa8842_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qcs410_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn3988_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm2301_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8004_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd_636_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdm630_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm8895_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdr675_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wtr3925_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdr8150_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6426_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qsw6310_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sm7250p_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa8675_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcd9371_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn3660b_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wtr5975_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd450_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm5579_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcd9380_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm456_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfe4302_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm670_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn3998_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmm6155au_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:msm8917_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm4650_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa4361_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd429_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8940_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd730_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qbt1500_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb1354_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8953_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmx20_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdx20_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcd9335_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm6375_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm8870_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfe2550_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdxr1_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6421_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:apq8009w_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm7150a_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qln4642_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa6560_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdr735_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn3680_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8150l_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sda429w_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmr735a_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm3003a_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8350bhs_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcd9340_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdxr2_5g_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm5620_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdw3100_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qat5522_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfe3340_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:apq8017_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb1360_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qcm4290_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:fsm10055_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wtr2965_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qln5020_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdr660_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmr525_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qsm8250_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdr8250_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm5577_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:rsw8577_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd720g_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdr845_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfe4308_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca9379_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfe2101_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm640l_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfe4305_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa2625_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm4125_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6431_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa8801_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm5579_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6436_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sa8155p_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qtc800t_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn6851_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa8686_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sm4125_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8996_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qcm2290_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8350c_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm670l_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qln4640_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qat5568_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn3991_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca4020_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdx55m_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn3610_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wsa8810_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qcc1110_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd662_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qcs405_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca8337_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm5620_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qtc410s_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmm855au_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn3910_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smr525_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8009_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm2310_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd888_5g_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd660_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:msm8920_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd845_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qcs603_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qat5516_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmr735b_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfe4373fc_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:msm8996au_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm660_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb1381_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcd9341_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qcs4290_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qat3550_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcd9375_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa8802_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb231_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:ar8031_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcd9370_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcd9385_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdr865_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm6150l_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdx55_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdr735g_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm5658_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm5679_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm2305_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm6585_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm855b_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qln1031_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm2630_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd210_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm640p_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd665_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8008_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qat5533_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wsa8815_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm855_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm4643_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8909_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmk8003_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa5460_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm7250b_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa4340_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfs2608_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:msm8940_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm7250_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:aqt1000_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdx50m_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6574_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm855a_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6391_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6320_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm439_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb1355_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb1396_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8150b_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm4621_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qualcomm215_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qtm527_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmi632_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6595au_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qet5100_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wsa8830_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn6856_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm8820_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd710_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd765_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:msm8909w_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdm830_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm6125_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfs2630_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qat3522_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd690_5g_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmk7350_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmk8001_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm6150a_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm6670_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn3950_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8005_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb1357_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qln4650_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm4640_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdr052_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm5670_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm660a_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa4360_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:ar8151_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmm8155au_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb1350_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm5679_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd821_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm855l_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qet4101_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm5657_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qcm6125_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8150a_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qat5515_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qln1021aq_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm4641_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfe4303_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd_675_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm5641_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn3660_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:csra6640_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmk8002_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd439_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb1351_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qcs6125_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8937_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb1394_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn6750_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qat3555_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qcs2290_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm855p_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfe2520_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd768g_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmi8996_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm670a_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa8821_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn3980_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm4630_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wtr3950_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qcs610_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca9377_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6696_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qsw8573_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm5650_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb1398_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8350bh_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6335_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd820_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm8830_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pme605_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qbt1000_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm215_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd855_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:apq8053_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm7350c_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sa515m_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:fsm10056_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmi8998_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm3302_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm5652_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd632_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qln1020_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6574au_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:apq8064au_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:msm8937_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wtr3905_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm5677_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmw3100_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6584au_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmx50_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd_8c_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qtc800s_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdw2500_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:ar8035_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:csra6620_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm3301_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qat3519_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8998_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sm6250_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd835_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm6621_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wtr6955_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm6350_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qcs605_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm5671_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm640a_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd205_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6174a_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdm429w_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8350_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm5677_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8916_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6564au_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfe4309_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qet4100_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qtm525_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm5621_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6430_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn6850_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sm4350_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa5373_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smr526_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmc1000h_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm6250_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qtc801s_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdr425_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6564_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb2351_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qet6100_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn3990_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmm8996au_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn3615_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wtr4905_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm5541_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qln5030_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd865_5g_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdx24_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qln1030_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa8673_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6420_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6574a_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:apq8037_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcd9326_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmx24_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm6582_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm6325_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm5870_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8150c_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd675_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6564a_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm2307_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qtc800h_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wtr2955_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8350b_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qln5040_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn6740_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm5670_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qet6110_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm5621_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd670_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmd9655_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm6150_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qat3516_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:msm8953_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm7150l_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd_455_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6390_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm2302_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd750g_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfs2530_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa5580_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:apq8096au_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfe4301_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmi8937_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wsa8835_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn3680b_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wgr7640_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8150_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:apq8009_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm8250_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sa415m_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmi8952_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd460_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qat3518_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb1358_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpm5875_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qln1036aq_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb1380_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm4650_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa8803_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb1395_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qca6310_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdx20m_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qdm2308_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sm6250p_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmk8350_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qfs2580_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sm7350_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdr660g_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pmi8994_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qsm7250_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn3620_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:mdm9650_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qat3514_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:csrb31024_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sa6145p_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:rgr7640au_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qbt2000_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:smb1390_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:pm660l_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qsw8574_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:wcn3999_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sdr051_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qet5100m_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa5581_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sa8155_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:sd_8cx_firmware:-:*:*:*:*:*:*:*", "cpe:2.3:o:qualcomm:qpa5461_firmware:-:*:*:*:*:*:*:*"]}], "cisa": [{"lastseen": "2022-01-26T11:34:49", "description": "CISA has added five new vulnerabilities to its [Known Exploited Vulnerabilities Catalog](<https://www.cisa.gov/known-exploited-vulnerabilities-catalog>), based on evidence that threat actors are actively exploiting the vulnerabilities listed in the table below. These types of vulnerabilities are a frequent attack vector for malicious cyber actors of all types and pose significant risk to the federal enterprise.\n\nCVE Number | **CVE Title** | Remediation Due Date \n---|---|--- \n[CVE-2020-11261](<https://nvd.nist.gov/vuln/detail/CVE-2020-11261>) | Qualcomm Multiple Chipsets Improper Input Validation Vulnerability | 06/01/2022 \n[CVE-2018-14847](<https://nvd.nist.gov/vuln/detail/CVE-2018-14847>) | MikroTik Router OS Directory Traversal Vulnerability | 06/01/2022 \n[CVE-2021-37415](<https://nvd.nist.gov/vuln/detail/CVE-2021-37415>) | Zoho ManageEngine ServiceDesk Authentication Bypass Vulnerability | 12/15/2021 \n[CVE-2021-40438](<https://nvd.nist.gov/vuln/detail/CVE-2021-40438>) | Apache HTTP Server-Side Request Forgery (SSRF) | 12/15/2021 \n[CVE-2021-44077](<https://nvd.nist.gov/vuln/detail/CVE-2021-44077>) | Zoho ManageEngine ServiceDesk Plus Remote Code Execution | 12/15/2021 \n \n[Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities](<https://www.cisa.gov/binding-operational-directive-22-01>) established the Known Exploited Vulnerabilities Catalog as a living list of known CVEs that carry significant risk to the federal enterprise. BOD 22-01 requires FCEB agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See the [BOD 22-01 Fact Sheet](<https://www.cisa.gov/known-exploited-vulnerabilities>) for more information.\n\nAlthough BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing timely remediation of [Catalog vulnerabilities](<https://www.cisa.gov/known-exploited-vulnerabilities-catalog>) as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the Catalog that meet the meet the [specified criteria](<https://www.cisa.gov/known-exploited-vulnerabilities>). \n\nThis product is provided subject to this Notification and this [Privacy & Use](<https://www.dhs.gov/privacy-policy>) policy.\n\n**Please share your thoughts.**\n\nWe recently updated our anonymous [product survey](<https://www.surveymonkey.com/r/CISA-cyber-survey?product=https://us-cert.cisa.gov/ncas/current-activity/2021/12/01/cisa-adds-five-known-exploited-vulnerabilities-catalog>); we'd welcome your feedback.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-12-01T00:00:00", "type": "cisa", "title": "CISA Adds Five Known Exploited Vulnerabilities to Catalog", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 6.4, "obtainUserPrivilege": false}, "cvelist": ["CVE-2018-14847", "CVE-2020-11261", "CVE-2021-37415", "CVE-2021-40438", "CVE-2021-44077"], "modified": "2022-01-25T00:00:00", "id": "CISA:72D01121CAFBC56638BC974ABA539CF8", "href": "https://us-cert.cisa.gov/ncas/current-activity/2021/12/01/cisa-adds-five-known-exploited-vulnerabilities-catalog", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}], "threatpost": [{"lastseen": "2021-05-21T14:02:25", "description": "Google updated its May 3 Android security [bulletin](<https://source.android.com/security/bulletin/2021-05-01#mitigations>) on Wednesday to say that there are \u201cindications\u201d that four of the 50 vulnerabilities \u201cmay be under limited, targeted exploitation.\u201d That was mostly confirmed by Maddie Stone, a member of Google\u2019s Project Zero exploit research group, who clarified on Twitter that the \u201c4 vulns were exploited in-the-wild\u201d as zero-days.\n\n> Android has updated the May security with notes that 4 vulns were exploited in-the-wild. \n> \n> Qualcomm GPU: CVE-2021-1905, CVE-2021-1906 \nARM Mali GPU: CVE-2021-28663, CVE-2021-28664<https://t.co/mT8vE2Us74>\n> \n> \u2014 Maddie Stone (@maddiestone) [May 19, 2021](<https://twitter.com/maddiestone/status/1395004346996248586?ref_src=twsrc%5Etfw>)\n\nGoogle Android exploits are a rarity. These four bugs make up a full two-thirds of the six total bugs to be exploited in the wild since 2014, according to Google\u2019s tracking [spreadsheet](<https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1123292625>). Project Zero\u2019s Stone went on to celebrate that fact, pointing out that \u201cFor 2021, we\u2019ve surpassed the number of 0-days detected in-the-wild in all of 2020. That\u2019s great!\u201d\n\nAccording to security firm Zimperium, Google disclosed only one zero-day vulnerability in Android in 2020.\n\n## Could Give Attackers \u2018Complete Control\u2019 of Androids\n\nIs finding four zero-days really all that great? These four bugs could give attackers complete control of Android devices. All four affect GPU firmware code. Two of the bugs impact the ARM Mali GPU driver, while the other two are found in the Qualcomm Snapdragon CPU graphics component.\n\nCVE | Description \n---|--- \n[CVE-2021-1905](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-1905>) | Possible use after free due to improper handling of memory mapping of multiple processes simultaneously. in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables. \n[CVE-2021-1906](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-1906>) | Improper handling of address deregistration on failure can lead to new GPU address allocation failure. in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables. \n[CVE-2021-28663](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28663>) | The Arm Mali GPU kernel driver allows privilege escalation or information disclosure because GPU memory operations are mishandled, leading to a use-after-free. This affects Bifrost r0p0 through r28p0 before r29p0, Valhall r19p0 through r28p0 before r29p0, and Midgard r4p0 through r30p0. \n[CVE-2021-28664](<http://CVE-2021-28664>) | The Arm Mali GPU kernel driver allows privilege escalation or a denial of service (memory corruption) because an unprivileged user can achieve read/write access to read-only pages. This affects Bifrost r0p0 through r28p0 before r29p0, Valhall r19p0 through r28p0 before r29p0, and Midgard r8p0 through r30p0. \n \nAsaf Peleg, vice president of strategic projects for Zimperium, told [Ars Technica](<https://arstechnica.com/gadgets/2021/05/hackers-have-been-exploiting-4-critical-android-vulnerabilities/>) that successful exploits of the vulnerabilities \u201cwould give complete control of the victim\u2019s mobile endpoint. From elevating privileges beyond what is available by default to executing code outside of the current process\u2019s existing sandbox, the device would be fully compromised, and no data would be safe.\u201d\n\nThis is the second time this month that Qualcomm has suffered chip woes. As Check Point Research reported in early May, a vulnerability in a 5G modem data service could allow a malicious app to exploit the issue, opening up Android phones to [attackers being able to eavesdrop](<https://threatpost.com/qualcomm-chip-bug-android-eavesdropping/165934/>), inject, malicious code into a phone\u2019s modem, access call histories and text messages: a problem that could affect up to 30 percent of Android phones.\n\n## One Exploit May Be Tied to Spyware Maker NSO Group\n\nAs [The Record](<https://therecord.media/arm-and-qualcomm-zero-days-quietly-patched-in-this-months-android-security-updates/>) reported, two of the zero-days have previously been exploited in the wild: [CVE-2020-11261](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11261>), a bug in the Qualcomm graphics component that was patched in the [January 2021 Android security bulletin](<https://source.android.com/security/bulletin/2021-01-01>), and [CVE-2019-2215](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2215>), an Android exploit that Project Zero believes was [developed by exploit broker NSO Group](<https://bugs.chromium.org/p/project-zero/issues/detail?id=1942>) and was allegedly being used, abused and sold to its customers throughout 2019.\n\nNSO Group, an Israeli maker of the Pegasus mobile spyware tool, [has long insisted](<https://threatpost.com/nso-group-president-defends-controversial-tactics/150694/>) that its products are meant to be used to fight crime and terror. Whatever governments do with it, NSO Group isn\u2019t in on it, the company has said. That contention was dissected in court in July 2020, during Facebook\u2019s lawsuit over [alleged spying on WhatsApp users.](<https://threatpost.com/facebooks-nso-group-lawsuit-whatsapp-spying/157571/>)\n\n![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)\n\nAt the time, Judge Phyllis Hamilton said that it appears that NSO Group \u201cretained some role\u201d in how its wares are used. She also pointed to a statement to the court from CEO Shalev Hulio, which says that NSO Group carries out its activities \u201centirely at the direction of their government customers,\u201d and that it provides \u201cadvice and technical support\u201d for its notorious Pegasus, which is a remote access trojan (RAT). The tool enables governments to send a personalized text message with an infected link to a blank page. Click on it, whether it be on an iOS or Android phone, and the software gains full control over the targeted device, monitoring all messaging, contacts and calendars, and possibly even turning on microphones and cameras for surveillance purposes.\n\nAs far as whether NSO Group is behind these Android zero-day exploits, the sophistication required to exploit these vulnerabilities would be in line with its history. \u201cThe complexity of this mobile attack vector is not unheard of but is outside the capabilities of an attacker with rudimentary or even intermediate knowledge of mobile endpoint hacking,\u201d Peleg said. \u201cAny attacker using this vulnerability is most likely doing so as part of a larger campaign against an individual, enterprise, or government with the goal of stealing critical and private information.\u201d\n\n## How Should Android Fans Protect Themselves?\n\nOnly Android phones that use Arm or Qualcomm GPUs are affected by these bugs. According to recent [Arm](<https://developer.arm.com/support/arm-security-updates/mali-gpu-kernel-driver>) and [Qualcomm](<https://www.qualcomm.com/company/product-security/bulletins/may-2021-bulletin>) security bulletins each of their respected chipsets are impacted. Sources told The Record that this month\u2019s security updates may have been delayed by some smartphone vendors to make sure they shipped the Arm and Qualcomm fixes released on Wednesday.\n\nCheck Point Security Technologies\u2019 Head of Cyber Research, Yaniv Balmas, said via email that \u201cQualcomm, as one of the world\u2019s biggest chip manufacturers, also needs to deal with many security issues found on their products (both internally and externally). This not different than any other vendor of that size. Obviously, bugs found in Qualcomm mobile chips can cause security issues in their hosting devices and operating systems, which is mainly Android.\u201d\n\nThese security issues were found on Qualcomm\u2019s GPU chips, which provide \u201ca very large attack surface,\u201d Balmas told Threatpost. adding that \u201cSuccessful exploitation may lead to a complete phone compromise.\u201d\n\nThreatpost has reached out to Google, NVIDIA ARM and Qualcomm for input on how Android users should proceed.\n\n052121 09:58 UPDATE: Added input from Yaniv Balmas.\n\n**Download our exclusive FREE Threatpost Insider eBook, ****_\u201c_**[**_2021: The Evolution of Ransomware_**](<https://threatpost.com/ebooks/2021-the-evolution-of-ransomware/?utm_source=April_eBook&utm_medium=ART&utm_campaign=ART>)**_,\u201d_**** to help hone your cyber-defense strategies against this growing scourge. We go beyond the status quo to uncover what\u2019s next for ransomware and the related emerging risks. Get the whole story and **[**DOWNLOAD**](<https://threatpost.com/ebooks/2021-the-evolution-of-ransomware/?utm_source=April_eBook&utm_medium=ART&utm_campaign=ART>)** the eBook now \u2013 on us!**\n", "cvss3": {}, "published": "2021-05-20T16:50:16", "type": "threatpost", "title": "4 Android Bugs Being Exploited in the Wild", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-2215", "CVE-2020-11261", "CVE-2021-1905", "CVE-2021-1906", "CVE-2021-28663", "CVE-2021-28664"], "modified": "2021-05-20T16:50:16", "id": "THREATPOST:38BE049C6C451ED1B9E3037B2EA65D9A", "href": "https://threatpost.com/android-bugs-exploited-wild/166347/", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-01-06T21:52:10", "description": "Google has fixed two critical bugs affecting its Android handsets. The more serious flaws exists in the Android System component and allow remote attackers to execute arbitrary code.\n\nThe two critical vulnerabilities are part of Google\u2019s [January Android security bulletin](<https://source.android.com/security/bulletin/2021-01-01>), released Monday. The security update addressed 43 bugs overall for the Android operating systems. As part of this, Qualcomm, whose chips are used in Android devices, patched a mix of high- and critical-severity vulnerabilities tied to 15 bugs.\n\nThe critical-severity flaws include a remote-code-execution flaw in Google\u2019s Android System component (CVE-2021-0316), the core of the Android operating system.\n\n[![2020 Reader Survey: Share Your Feedback to Help Us Improve](https://media.threatpost.com/wp-content/uploads/sites/103/2020/12/18164737/Reader-Survey-Update.jpg)](<https://threatpost.com/2020-reader-survey/161168/>)\n\nAnother flaw, rated serious, is a denial-of-service issue (CVE-2021-0313) in the Android Framework component, which is a set of APIs (consisting of system tools and user interface design tools) that allow developers to quickly and easily write apps for Android phones.\n\n\u201cThe most severe of these issues is a critical security vulnerability in the System component that could enable a remote attacker using a specially crafted transmission to execute arbitrary code within the context of a privileged process,\u201d according to Google. Both critical flaws are fixed in Android versions 8.0, 8.1, 9, 10 and 11.\n\nBeyond these critical-severity issues, Google fixed a tangle of 13 high-severity flaws in its Framework. This included eight elevation-of-privilege issues (CVE-2021-0303, CVE-2021-0306, CVE-2021-0307, CVE-2021-0310, CVE-2021-0315, CVE-2021-0317, CVE-2021-0318, CVE-2021-0319); four information disclosure glitches (CVE-2021-0304, CVE-2021-0309, CVE-2021-0321, CVE-2021-0322) and one DoS flaw (CVE-2019-9376).\n\nThree high-severity bugs were found in Media Framework (which offers support for playing a variety of common media types, so users can easily utilize audio, video and images). These include a RCE flaw tied to CVE-2016-6328, and two information disclosure flaws tied to CVE-2021-0311 and CVE-2021-0312.\n\nGoogle also rolled out patches for flaws in various third-party components in its Android ecosystem. This included three high-severity flaws in the kernel (CVE-2020-10732, CVE-2020-10766, CVE-2021-0323), which could enable a local malicious application to bypass operating system protections that isolate application data from other applications. A high-severity vulnerability (CVE-2021-0301) was also fixed in the MediaTek component.\n\nFinally, 15 critical and high-severity flaws were addressed in Qualcomm components, including ones affecting the kernel (CVE-2020-11233), display (CVE-2020-11239, CVE-2020-11261, CVE-2020-11262), camera (CVE-2020-11240) and audio components (CVE-2020-11250).\n\nThe fixes come after [a hefty December Android security update](<https://threatpost.com/google-patches-critical-wi-fi-and-audio-bugs-in-android-handsets/162060/>), where Google patched ten critical bugs, including one tied to the Android media framework component that could give attacker remote control of vulnerable handsets.\n\n**Supply-Chain Security: A 10-Point Audit Webinar:** Is your company\u2019s software supply-chains prepared for an attack? On Wed., Jan. 20 at 2p.m. ET, start identifying weaknesses in your supply-chain with actionable advice from experts \u2013 part of a [limited-engagement and LIVE Threatpost webinar](<https://threatpost.com/webinars/supply-chain-security-a-10-point-audit/?utm_source=ART&utm_medium=ART&utm_campaign=Jan_webinar>). CISOs, AppDev and SysAdmin are invited to ask a panel of A-list cybersecurity experts how they can avoid being caught exposed in a post-SolarWinds-hack world. Attendance is limited: **[Register Now](<https://threatpost.com/webinars/supply-chain-security-a-10-point-audit/?utm_source=ART&utm_medium=ART&utm_campaign=Jan_webinar>)** and reserve a spot for this exclusive Threatpost [Supply-Chain Security webinar](<https://threatpost.com/webinars/supply-chain-security-a-10-point-audit/?utm_source=ART&utm_medium=ART&utm_campaign=Jan_webinar>) \u2013 Jan. 20, 2 p.m. ET.\n", "cvss3": {}, "published": "2021-01-05T20:21:40", "type": "threatpost", "title": "Google Warns of Critical Android Remote Code Execution Bug", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2016-6328", "CVE-2019-9376", "CVE-2020-10732", "CVE-2020-10766", "CVE-2020-11233", "CVE-2020-11239", "CVE-2020-11240", "CVE-2020-11250", "CVE-2020-11261", "CVE-2020-11262", "CVE-2021-0301", "CVE-2021-0303", "CVE-2021-0304", "CVE-2021-0306", "CVE-2021-0307", "CVE-2021-0309", "CVE-2021-0310", "CVE-2021-0311", "CVE-2021-0312", "CVE-2021-0313", "CVE-2021-0315", "CVE-2021-0316", "CVE-2021-0317", "CVE-2021-0318", "CVE-2021-0319", "CVE-2021-0321", "CVE-2021-0322", "CVE-2021-0323"], "modified": "2021-01-05T20:21:40", "id": "THREATPOST:17E00AD621A0ECD9F90FE97E083BF4AC", "href": "https://threatpost.com/google-warns-of-critical-android-remote-code-execution-bug/162756/", "cvss": {"score": 5.8, "vector": "AV:N/AC:M/Au:N/C:P/I:N/A:P"}}], "thn": [{"lastseen": "2022-05-09T12:38:02", "description": "[![](https://thehackernews.com/images/--bQd_wXz_co/YKXvNNPXGpI/AAAAAAAAClU/c5Se7viT_Ewh2TJZaiUOQmpA_FBdof58QCLcBGAsYHQ/s0/ANDROID.jpg)](<https://thehackernews.com/images/--bQd_wXz_co/YKXvNNPXGpI/AAAAAAAAClU/c5Se7viT_Ewh2TJZaiUOQmpA_FBdof58QCLcBGAsYHQ/s0/ANDROID.jpg>)\n\nGoogle on Wednesday updated its May 2021 Android Security Bulletin to disclose that four of the security vulnerabilities that were patched earlier this month by Arm and Qualcomm may have been exploited in the wild as zero-days.\n\n\"There are indications that CVE-2021-1905, CVE-2021-1906, CVE-2021-28663 and CVE-2021-28664 may be under limited, targeted exploitation,\" the search giant [said](<https://source.android.com/security/bulletin/2021-05-01>) in an updated alert.\n\nThe four flaws impact [Qualcomm Graphics](<https://www.qualcomm.com/company/product-security/bulletins/may-2021-bulletin>) and [Arm Mali GPU Driver](<https://developer.arm.com/support/arm-security-updates/mali-gpu-kernel-driver>) modules \u2014\n\n * **CVE-2021-1905** (CVSS score: 8.4) - A use-after-free flaw in Qualcomm's graphics component due to improper handling of memory mapping of multiple processes simultaneously.\n * **CVE-2021-1906** (CVSS score: 6.2) - A flaw concerning inadequate handling of address deregistration that could lead to new GPU address allocation failure.\n * **CVE-2021-28663** (CVSS score: NA) - A vulnerability in Arm Mali GPU kernel that could permit a non-privileged user to make improper operations on GPU memory, leading to a use-after-free scenario that could be exploited to gain root privilege or disclose information. \n * **CVE-2021-28664** (CVSS score: NA) - An unprivileged user can achieve read/write access to read-only memory, enabling privilege escalation or a denial-of-service (DoS) condition due to memory corruption.\n\nSuccessful exploitation of the weaknesses could grant an adversary carte blanche access to the targeted device and take over control. It's, however, not clear how the attacks themselves were carried out, the victims that may have been targeted, or the threat actors that may be abusing them.\n\nThe development marks one of the rare instances where zero-day bugs in Android have been spotted in real-world cyber offensives.\n\nEarlier this March, Google revealed that a vulnerability affecting Android devices that use Qualcomm chipsets ([CVE-2020-11261](<https://thehackernews.com/2021/03/warning-new-android-zero-day.html>)) was being weaponized by adversaries to launch targeted attacks. The other flaw is [CVE-2019-2215](<https://nvd.nist.gov/vuln/detail/CVE-2019-2215>), a vulnerability in [Binder](<https://developer.android.com/reference/android/os/Binder>) \u2014 Android's inter-process communication mechanism \u2014 that's said to have been allegedly exploited by the NSO Group as well as [SideWinder threat actor](<https://www.trendmicro.com/en_us/research/20/a/first-active-attack-exploiting-cve-2019-2215-found-on-google-play-linked-to-sidewinder-apt-group.html>) to compromise a victim's device and collect user information.\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-05-20T05:13:00", "type": "thn", "title": "Android Issues Patches for 4 New Zero-Day Bugs Exploited in the Wild", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-2215", "CVE-2020-11261", "CVE-2021-1905", "CVE-2021-1906", "CVE-2021-28663", "CVE-2021-28664"], "modified": "2021-05-20T05:35:42", "id": "THN:9CE461E69A8B499207911497E3A349FD", "href": "https://thehackernews.com/2021/05/android-issues-patches-for-4-new-zero.html", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2022-05-09T12:38:08", "description": "[![](https://thehackernews.com/new-images/img/a/AVvXsEiH_ku-QrzXLuWobEQwNeCU-1szXQE_YfU7-27jchcPvQch2oAG-unVPYTeIA9mD8dCRQKYOdycKdKQejYSAQDLOBNrC8o_iHMZtXakx0WEiJMrBaV54fvlywQNqzISF_c_16nYrItctTkviCxzwdXakAUJttFAEPo3UwwTfqKrp6jng_lB8VtW0jt9)](<https://thehackernews.com/new-images/img/a/AVvXsEiH_ku-QrzXLuWobEQwNeCU-1szXQE_YfU7-27jchcPvQch2oAG-unVPYTeIA9mD8dCRQKYOdycKdKQejYSAQDLOBNrC8o_iHMZtXakx0WEiJMrBaV54fvlywQNqzISF_c_16nYrItctTkviCxzwdXakAUJttFAEPo3UwwTfqKrp6jng_lB8VtW0jt9>)\n\nGoogle has rolled out its monthly security patches for Android with fixes for 39 flaws, including a zero-day vulnerability that it said is being actively exploited in the wild in limited, targeted attacks.\n\nTracked as **CVE-2021-1048**, the zero-day bug is described as a [use-after-free vulnerability](<https://cwe.mitre.org/data/definitions/416.html>) in the kernel that can be exploited for local privilege escalation. Use-after-free issues are dangerous as it could enable a threat actor to access or referencing memory after it has been freed, leading to a \"[write-what-where](<https://cwe.mitre.org/data/definitions/123.html>)\" condition that results in the execution of arbitrary code to gain control over a victim's system.\n\n\"There are indications that CVE-2021-1048 may be under limited, targeted exploitation,\" the company [noted](<https://source.android.com/security/bulletin/2021-11-01>) in its November advisory without revealing technical details of the vulnerability, the nature of the intrusions, and the identities of the attackers that may have abused the flaw.\n\nAlso remediated in the security patch are two critical remote code execution (RCE) vulnerabilities \u2014 CVE-2021-0918 and CVE-2021-0930 \u2014 in the System component that could allow remote adversaries to execute malicious code within the context of a privileged process by sending a specially-crafted transmission to targeted devices.\n\nTwo more critical flaws, CVE-2021-1924 and CVE-2021-1975, affect Qualcomm closed-source components, while a fifth critical vulnerability in Android TV (CVE-2021-0889) could permit an attacker in close proximity to silently pair with a TV and execute arbitrary code with no privileges or user interaction required.\n\nWith the latest round of updates, Google has addressed a [total](<https://thehackernews.com/2021/03/warning-new-android-zero-day.html>) of [six zero-days](<https://thehackernews.com/2021/05/android-issues-patches-for-4-new-zero.html>) in Android since the start of the year \u2014\n\n * [**CVE-2020-11261**](<https://nvd.nist.gov/vuln/detail/CVE-2020-11261>) (CVSS score: 8.4) - Improper input validation in Qualcomm Graphics component\n * [**CVE-2021-1905**](<https://nvd.nist.gov/vuln/detail/CVE-2021-1905>) (CVSS score: 8.4) - Use-after-free in Qualcomm Graphics component\n * [**CVE-2021-1906**](<https://nvd.nist.gov/vuln/detail/CVE-2021-1906>) (CVSS score: 6.2) - Detection of error condition without action in Qualcomm Graphics component\n * [**CVE-2021-28663**](<https://nvd.nist.gov/vuln/detail/CVE-2021-28663>) (CVSS score: 8.8) - Mali GPU Kernel Driver allows improper operations on GPU memory\n * [**CVE-2021-28664**](<https://nvd.nist.gov/vuln/detail/CVE-2021-28664>) (CVSS score: 8.8) - Mali GPU Kernel Driver elevates CPU RO pages to writable\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-11-03T05:20:00", "type": "thn", "title": "Google Warns of New Android 0-Day Vulnerability Under Active Targeted Attacks", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-11261", "CVE-2021-0889", "CVE-2021-0918", "CVE-2021-0930", "CVE-2021-1048", "CVE-2021-1905", "CVE-2021-1906", "CVE-2021-1924", "CVE-2021-1975", "CVE-2021-28663", "CVE-2021-28664"], "modified": "2021-11-03T05:20:12", "id": "THN:37E4ECDE5CC5E074EC9FD4DF79D85121", "href": "https://thehackernews.com/2021/11/google-warns-of-new-android-0-day.html", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "androidsecurity": [{"lastseen": "2022-09-08T00:19:45", "description": "The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2021-01-05 or later address all of these issues. To learn how to check a device's security patch level, see [Check and update your Android version](<https://support.google.com/pixelphone/answer/4457705>).\n\nAndroid partners are notified of all issues at least a month before publication. Source code patches for these issues have been released to the Android Open Source Project (AOSP) repository and linked from this bulletin. This bulletin also includes links to patches outside of AOSP. \n\nThe most severe of these issues is a critical security vulnerability in the System component that could enable a remote attacker using a specially crafted transmission to execute arbitrary code within the context of a privileged process. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed. \n\nRefer to the Android and Google Play Protect mitigations section for details on the Android security platform protections and Google Play Protect, which improve the security of the Android platform. \n\n**Note**: Information on the latest over-the-air update (OTA) and firmware images for Google devices is available in the January 2021 Pixel Update Bulletin. \n\n## Android and Google service mitigations\n\nThis is a summary of the mitigations provided by the Android security platform and service protections such as [Google Play Protect](<https://developers.google.com/android/play-protect>). These capabilities reduce the likelihood that security vulnerabilities could be successfully exploited on Android. \n\n * Exploitation for many issues on Android is made more difficult by enhancements in newer versions of the Android platform. We encourage all users to update to the latest version of Android where possible. \n * The Android security team actively monitors for abuse through [Google Play Protect](<https://developers.google.com/android/play-protect>) and warns users about [Potentially Harmful Applications](<https://developers.google.com/android/play-protect/potentially-harmful-applications>). Google Play Protect is enabled by default on devices with [Google Mobile Services](<http://www.android.com/gms>), and is especially important for users who install apps from outside of Google Play. \n**Note**: There are indications that CVE-2020-11261 may be under limited, targeted exploitation. \n\n## 2021-01-01 security patch level vulnerability details\n\nIn the sections below, we provide details for each of the security vulnerabilities that apply to the 2021-01-01 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. Devices with Android 10 and later may receive security updates as well as [Google Play system updates](<https://support.google.com/android/answer/7680439>). \n\n### Framework\n\nThe most severe vulnerability in this section could enable a remote attacker using a specially crafted string to cause a permanent denial of service. \n\nCVE | References | Type | Severity | Updated AOSP versions \n---|---|---|---|--- \nCVE-2021-0313 | [A-170968514](<https://android.googlesource.com/platform/frameworks/minikin/+/ffb33bcf2520208166cb29f47c60add9c0e37349>) | DoS | Critical | 8.0, 8.1, 9, 10, 11 \nCVE-2021-0303 | [A-170407229](<https://android.googlesource.com/platform/packages/services/Car/+/768c8bfbe91db71e11eae2c57fb678ff2a5bf15e>) | EoP | High | 11 \nCVE-2021-0306 | [A-154505240](<https://android.googlesource.com/platform/frameworks/base/+/03da463b2a94c36e3b46f0a110ec43710b82d404>) [[2](<https://android.googlesource.com/platform/frameworks/base/+/c4ce178c261e6a2dc1aa4c1e1d570f0efd980e47>)] | EoP | High | 8.0, 8.1, 9, 10, 11 \nCVE-2021-0307 | [A-155648771](<https://android.googlesource.com/platform/cts/+/a8a90255d43845e307b6d133c710b802dbece622>) [[2](<https://android.googlesource.com/platform/frameworks/base/+/a9f825922e1870575aeab11a2035903c217233c9>)] | EoP | High | 10, 11 \nCVE-2021-0310 | [A-170212632](<https://android.googlesource.com/platform/frameworks/native/+/dc6cb05ebe2cefdce215d797a8e418ba26c8c86c>) | EoP | High | 11 \nCVE-2021-0315 | [A-169763814](<https://android.googlesource.com/platform/frameworks/base/+/828fe0b915f30e22fec03dc1ed2e66220ceebd3e>) | EoP | High | 8.0, 8.1, 9, 10, 11 \nCVE-2021-0317 | [A-168319670](<https://android.googlesource.com/platform/frameworks/base/+/c4ce178c261e6a2dc1aa4c1e1d570f0efd980e47>) | EoP | High | 8.0, 8.1, 9, 10, 11 \nCVE-2021-0318 | [A-168211968](<https://android.googlesource.com/platform/frameworks/native/+/adb416ac460cb28ca03e7898bdd154b1d0f8c16b>) | EoP | High | 8.1, 9, 10, 11 \nCVE-2021-0319 | [A-167244818](<https://android.googlesource.com/platform/frameworks/base/+/0c17049d39b5a8867f030f6f36433564140e124a>) | EoP | High | 8.0, 8.1, 9, 10, 11 \nCVE-2021-0304 | [A-162738636](<https://android.googlesource.com/platform/frameworks/base/+/9f42cf00e94afc61eee1edbf5ecde11f6c38e37f>) | ID | High | 8.0, 8.1, 9, 10 \nCVE-2021-0309 | [A-158480899](<https://android.googlesource.com/platform/frameworks/base/+/0b610a27ba60047842b9416dd0537c68f0dd22b2>) | ID | High | 8.0, 8.1, 9, 10, 11 \nCVE-2021-0321 | [A-166667403](<https://android.googlesource.com/platform/frameworks/base/+/b57d1409c52478d37f006145949be8b4591b9898>) | ID | High | 11 \nCVE-2021-0322 | [A-159145361](<https://android.googlesource.com/platform/frameworks/base/+/a185996c829a159bb27446697329b01464ab3c03>) [[2](<https://android.googlesource.com/platform/frameworks/base/+/e237a83f95767f669b83508bb1f594091cbd6bac>)] | ID | High | 9, 10, 11 \nCVE-2019-9376 | [A-129287265](<https://android.googlesource.com/platform/frameworks/base/+/32e85796389f57e2539c28f9e670277ab610459a>) | DoS | High | 8.0, 8.1, 9 \nCVE-2020-15999 | [A-171232105](<https://android.googlesource.com/platform/external/freetype/+/358c238408a1fdc357d9afef6811369a7701e004>) | RCE | Moderate | 8.0, 8.1, 9, 10, 11 \n \n### Media Framework\n\nThe most severe vulnerability in this section could enable a remote attacker using a specially crafted file to execute arbitrary code within the context of a privileged process. \n\nCVE | References | Type | Severity | Updated AOSP versions \n---|---|---|---|--- \nCVE-2016-6328 | [A-162602132](<https://android.googlesource.com/platform/external/libexif/+/8b37da24f362ac660917ae5415e1e4063724093c>) | RCE | High | 8.0, 8.1, 9, 10, 11 \nCVE-2021-0311 | [A-170240631](<https://android.googlesource.com/platform/frameworks/av/+/8ea3bdb5ef11dad8e11a2c2cad34e91ad11657d0>) | ID | High | 8.0, 8.1, 9, 10, 11 \nCVE-2021-0312 | [A-170583712](<https://android.googlesource.com/platform/frameworks/av/+/bb460899b97f260e7ed556b578318b1133335e1c>) | ID | High | 8.0, 8.1, 9, 10, 11 \n \n### System\n\nThe most severe vulnerability in this section could enable a remote attacker using a specially crafted transmission to execute arbitrary code within the context of a privileged process. \n\nCVE | References | Type | Severity | Updated AOSP versions \n---|---|---|---|--- \nCVE-2021-0316 | [A-168802990](<https://android.googlesource.com/platform/system/bt/+/f328ab46d5419632aec221f95b186ec71077176e>) | RCE | Critical | 8.0, 8.1, 9, 10, 11 \nCVE-2020-0471 | [A-169327567](<https://android.googlesource.com/platform/system/bt/+/ca6b0a211eb39ba85eed60ea740c85d1122fc6bc>) | EoP | High | 8.0, 8.1, 9, 10, 11 \nCVE-2021-0308 | [A-158063095](<https://android.googlesource.com/platform/external/gptfdisk/+/6d369451868ce71618144c4f4bd645ae48f0d1c5>) | EoP | High | 8.0, 8.1, 9, 10, 11 \nCVE-2021-0320 | [A-169933423](<https://android.googlesource.com/platform/system/security/+/33b83f6f3211358568894f48e2aa03c8851e11b7>) | ID | High | 10, 11 \n \n### Google Play system updates\n\nThe following issues are included in Project Mainline components.\n\nComponent | CVE \n---|--- \nMedia Framework components | CVE-2021-0311, CVE-2021-0312 \n \n## 2021-01-05 security patch level vulnerability details\n\nIn the sections below, we provide details for each of the security vulnerabilities that apply to the 2021-01-05 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. \n\n### Kernel components\n\nThe most severe vulnerability in this section could enable a local malicious application to bypass operating system protections that isolate application data from other applications. \n\nCVE | References | Type | Severity | Component \n---|---|---|---|--- \nCVE-2020-10732 | A-170658976 [Upstream kernel](<http://android.googlesource.com/kernel/common/+/1d605416fb7175e1adf094251466caa52093b413>) | ID | High | ELF core dumps \nCVE-2020-10766 | A-169505740 [Upstream kernel](<https://android.googlesource.com/kernel/common/+/dbbe2ad02e9df26e372f38cc3e70dab9222c832e>) | ID | High | Speculative execution \nCVE-2020-10767 | A-156766097 [Upstream kernel](<https://android.googlesource.com/kernel/common/+/21998a351512eba4ed5969006f0c55882d995ada>) | ID | High | Linux kernel \n \n### MediaTek components\n\nThis vulnerability affects MediaTek components and further details are available directly from MediaTek. The severity assessment of this issue is provided directly by MediaTek. \n\nCVE | References | | Severity | Component \n---|---|---|---|--- \nCVE-2021-0301 | A-172514667 M-ALPS05342361* | | High | ged \n \n### Qualcomm components\n\nThese vulnerabilities affect Qualcomm components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm. \n\nCVE | References | | Severity | Component \n---|---|---|---|--- \nCVE-2020-11233 | A-170138863 [QC-CR#2257789](<https://source.codeaurora.org/quic/le/kernel/lk/commit/?id=d87aa073d641fd955330754008563549146235db>) | | High | Kernel \nCVE-2020-11239 | A-168722551 [QC-CR#2744826](<https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?id=20e2434473b259b40b590099da9fbce02a37cc8a>) | | High | Display \nCVE-2020-11240 | A-170138526 [QC-CR#2702760](<https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/?id=2e138f8bc21ac08898547d2320e11c073073216d>) [[2](<https://source.codeaurora.org/quic/la/kernel/msm-4.14/commit/?id=bbabced5e1467c10293c8f419c5fcee2a5a63235>)] [[3](<https://source.codeaurora.org/quic/la/kernel/msm-4.14/commit/?id=1afe9f760cd54ebba2fd7f>)] | | High | Camera \nCVE-2020-11250 | A-170139097 [QC-CR#2734543](<https://source.codeaurora.org/quic/la/kernel/msm-4.14/commit/?id=827c2fcadb0569bd94bdff386483fb404145687b>) | | High | Audio \nCVE-2020-11261 | A-161373974 [QC-CR#2742124](<https://source.codeaurora.org/quic/la/kernel/msm-4.19/commit/?id=b8d6a6665e15224b6913c48ac6641d6a9f42db61>) | | High | Display \nCVE-2020-11262 | A-170138789 [QC-CR#2742711](<https://source.codeaurora.org/quic/la/kernel/msm-4.14/commit/?id=10527de01e5fb34139487a3bc4e4dbbfa97eae0e>) | | High | Display \n \n### Qualcomm closed-source components\n\nThese vulnerabilities affect Qualcomm closed-source components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm. \n\nCVE | References | | Severity | Component \n---|---|---|---|--- \nCVE-2020-11134 | A-170138862* | | Critical | Closed-source component \nCVE-2020-11182 | A-168722721* | | Critical | Closed-source component \nCVE-2020-11126 | A-170139227* | | High | Closed-source component \nCVE-2020-11159 | A-170138666* | | High | Closed-source component \nCVE-2020-11181 | A-168051034* | | High | Closed-source component \nCVE-2020-11235 | A-170138866* | | High | Closed-source component \nCVE-2020-11238 | A-170139099* | | High | Closed-source component \nCVE-2020-11241 | A-170139229* | | High | Closed-source component \nCVE-2020-11260 | A-168918332* | | High | Closed-source component \n \n## Common questions and answers\n\nThis section answers common questions that may occur after reading this bulletin.\n\n**1\\. How do I determine if my device is updated to address these issues?**\n\nTo learn how to check a device's security patch level, see [Check and update your Android version](<https://support.google.com/pixelphone/answer/4457705#pixel_phones&nexus_devices>).\n\n * Security patch levels of 2021-01-01 or later address all issues associated with the 2021-01-01 security patch level.\n * Security patch levels of 2021-01-05 or later address all issues associated with the 2021-01-05 security patch level and all previous patch levels.\n\nDevice manufacturers that include these updates should set the patch string level to:\n\n * [ro.build.version.security_patch]:[2021-01-01]\n * [ro.build.version.security_patch]:[2021-01-05]\n\nFor some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2021-01-01 security patch level. Please see [this article](<https://support.google.com/android/answer/7680439?hl=en>) for more details on how to install security updates.\n\n**2\\. Why does this bulletin have two security patch levels?**\n\nThis bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. Android partners are encouraged to fix all issues in this bulletin and use the latest security patch level.\n\n * Devices that use the 2021-01-01 security patch level must include all issues associated with that security patch level, as well as fixes for all issues reported in previous security bulletins.\n * Devices that use the security patch level of 2021-01-05 or newer must include all applicable patches in this (and previous) security bulletins.\n\nPartners are encouraged to bundle the fixes for all issues they are addressing in a single update.\n\n**3\\. What do the entries in the _Type_ column mean?**\n\nEntries in the _Type_ column of the vulnerability details table reference the classification of the security vulnerability.\n\nAbbreviation | Definition \n---|--- \nRCE | Remote code execution \nEoP | Elevation of privilege \nID | Information disclosure \nDoS | Denial of service \nN/A | Classification not available \n \n**4\\. What do the entries in the _References_ column mean?**\n\nEntries under the _References_ column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs.\n\nPrefix | Reference \n---|--- \nA- | Android bug ID \nQC- | Qualcomm reference number \nM- | MediaTek reference number \nN- | NVIDIA reference number \nB- | Broadcom reference number \n \n**5\\. What does an * next to the Android bug ID in the _References_ column mean?**\n\nIssues that are not publicly available have an * next to the corresponding reference ID. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the [Google Developer site](<https://developers.google.com/android/drivers>). \n\n**6\\. Why are security vulnerabilities split between this bulletin and device / partner security bulletins, such as the Pixel bulletin?**\n\nSecurity vulnerabilities that are documented in this security bulletin are required to declare the latest security patch level on Android devices. Additional security vulnerabilities that are documented in the device / partner security bulletins are not required for declaring a security patch level. Android device and chipset manufacturers may also publish security vulnerability details specific to their products, such as Google, [Huawei](<https://consumer.huawei.com/en/support/bulletin/>), [LGE](<https://lgsecurity.lge.com/security_updates_mobile.html>), [Motorola](<https://motorola-global-portal.custhelp.com/app/software-security-page/g_id/6806>), [Nokia](<https://www.nokia.com/phones/en_int/security-updates>), or [Samsung](<https://security.samsungmobile.com/securityUpdate.smsb>).\n\n## Versions\n\nVersion | Date | Notes \n---|---|--- \n1.0 | January 4, 2021 | Bulletin released \n1.1 | January 7, 2021 | Bulletin revised to include AOSP links and revised CVE table\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-01-04T00:00:00", "type": "androidsecurity", "title": "Android Security Bulletin\u2014January 2021", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2016-6328", "CVE-2019-9376", "CVE-2020-0471", "CVE-2020-10732", "CVE-2020-10766", "CVE-2020-10767", "CVE-2020-11126", "CVE-2020-11134", "CVE-2020-11159", "CVE-2020-11181", "CVE-2020-11182", "CVE-2020-11233", "CVE-2020-11235", "CVE-2020-11238", "CVE-2020-11239", "CVE-2020-11240", "CVE-2020-11241", "CVE-2020-11250", "CVE-2020-11260", "CVE-2020-11261", "CVE-2020-11262", "CVE-2020-15999", "CVE-2021-0301", "CVE-2021-0303", "CVE-2021-0304", "CVE-2021-0306", "CVE-2021-0307", "CVE-2021-0308", "CVE-2021-0309", "CVE-2021-0310", "CVE-2021-0311", "CVE-2021-0312", "CVE-2021-0313", "CVE-2021-0315", "CVE-2021-0316", "CVE-2021-0317", "CVE-2021-0318", "CVE-2021-0319", "CVE-2021-0320", "CVE-2021-0321", "CVE-2021-0322"], "modified": "2021-01-07T00:00:00", "id": "ANDROID:2021-01-01", "href": "https://source.android.com/docs/security/bulletin/2021-01-01", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "googleprojectzero": [{"lastseen": "2022-08-25T01:57:30", "description": "A Year in Review of 0-days Used In-the-Wild in 2021\n\nPosted by Maddie Stone, Google Project Zero\n\nThis is our third annual year in review of 0-days exploited in-the-wild [[2020](<https://googleprojectzero.blogspot.com/2021/02/deja-vu-lnerability.html>), [2019](<https://googleprojectzero.blogspot.com/2020/07/detection-deficit-year-in-review-of-0.html>)]. Each year we\u2019ve looked back at all of the detected and disclosed in-the-wild 0-days as a group and synthesized what we think the trends and takeaways are. The goal of this report is not to detail each individual exploit, but instead to analyze the exploits from the year as a group, looking for trends, gaps, lessons learned, successes, etc. If you\u2019re interested in the analysis of individual exploits, please check out our [root cause analysis repository](<https://googleprojectzero.blogspot.com/p/rca.html>).\n\nWe perform and share this analysis in order to make 0-day hard. We want it to be more costly, more resource intensive, and overall more difficult for attackers to use 0-day capabilities. 2021 highlighted just how important it is to stay relentless in our pursuit to make it harder for attackers to exploit users with 0-days. We heard [over](<https://forbiddenstories.org/about-the-pegasus-project/>) and [over](<https://citizenlab.ca/2021/07/hooking-candiru-another-mercenary-spyware-vendor-comes-into-focus/>) and [over](<https://www.amnesty.org/en/latest/research/2021/11/devices-of-palestinian-human-rights-defenders-hacked-with-nso-groups-pegasus-spyware-2/>) about how governments were targeting journalists, minoritized populations, politicians, human rights defenders, and even security researchers around the world. The decisions we make in the security and tech communities can have real impacts on society and our fellow humans\u2019 lives.\n\nWe\u2019ll provide our evidence and process for our conclusions in the body of this post, and then wrap it all up with our thoughts on next steps and hopes for 2022 in the conclusion. If digging into the bits and bytes is not your thing, then feel free to just check-out the Executive Summary and Conclusion.\n\n# Executive Summary\n\n2021 included the detection and disclosure of 58 in-the-wild 0-days, the most ever recorded since Project Zero began tracking in mid-2014. That\u2019s more than double the previous maximum of 28 detected in 2015 and especially stark when you consider that there were only 25 detected in 2020. We\u2019ve tracked publicly known in-the-wild 0-day exploits in [this spreadsheet](<https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=0>) since mid-2014.\n\nWhile we often talk about the number of 0-day exploits used in-the-wild, what we\u2019re actually discussing is the number of 0-day exploits detected and disclosed as in-the-wild. And that leads into our first conclusion: we believe the large uptick in in-the-wild 0-days in 2021 is due to increased detection and disclosure of these 0-days, rather than simply increased usage of 0-day exploits.\n\nWith this record number of in-the-wild 0-days to analyze we saw that attacker methodology hasn\u2019t actually had to change much from previous years. Attackers are having success using the same bug patterns and exploitation techniques and going after the same attack surfaces. Project Zero\u2019s mission is \u201cmake 0day hard\u201d. 0-day will be harder when, overall, attackers are not able to use public methods and techniques for developing their 0-day exploits. When we look over these 58 0-days used in 2021, what we see instead are 0-days that are similar to previous & publicly known vulnerabilities. Only two 0-days stood out as novel: one for the technical sophistication of its exploit and the other for its use of logic bugs to escape the sandbox.\n\nSo while we recognize the industry\u2019s improvement in the detection and disclosure of in-the-wild 0-days, we also acknowledge that there\u2019s a lot more improving to be done. Having access to more \u201cground truth\u201d of how attackers are actually using 0-days shows us that they are able to have success by using previously known techniques and methods rather than having to invest in developing novel techniques. This is a clear area of opportunity for the tech industry.\n\nWe had so many more data points in 2021 to learn about attacker behavior than we\u2019ve had in the past. Having all this data, though, has left us with even more questions than we had before. Unfortunately, attackers who actively use 0-day exploits do not share the 0-days they\u2019re using or what percentage of 0-days we\u2019re missing in our tracking, so we\u2019ll never know exactly what proportion of 0-days are currently being found and disclosed publicly. \n\nBased on our analysis of the 2021 0-days we hope to see the following progress in 2022 in order to continue taking steps towards making 0-day hard:\n\n 1. All vendors agree to disclose the in-the-wild exploitation status of vulnerabilities in their security bulletins.\n 2. Exploit samples or detailed technical descriptions of the exploits are shared more widely.\n 3. Continued concerted efforts on reducing memory corruption vulnerabilities or rendering them unexploitable.Launch mitigations that will significantly impact the exploitability of memory corruption vulnerabilities.\n\n# A Record Year for In-the-Wild 0-days\n\n2021 was a record year for in-the-wild 0-days. So what happened?\n\n[![bar graph showing the number of in-the-wild 0-day detected per year from 2015-2021. The totals are taken from this tracking spreadsheet: https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=2129022708](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjC72HVhQEdwHNIzMiyb18bUFr6hPCWJiKL2Mm43-tW11qc0ucOPI8A9oChEXQe0-QNOBF83SIcfyjcyvPveuWvgipbiBzHWqZTx2-LilJFYIbx6uQeno9f481HJQ0CgylQkh8Ks7AbGC6tjhYDNBcI7jh6ihhzJATA0r_P4bQUBm-1lmHp2DPvWM6I/s1200/image1%287%29.png)](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjC72HVhQEdwHNIzMiyb18bUFr6hPCWJiKL2Mm43-tW11qc0ucOPI8A9oChEXQe0-QNOBF83SIcfyjcyvPveuWvgipbiBzHWqZTx2-LilJFYIbx6uQeno9f481HJQ0CgylQkh8Ks7AbGC6tjhYDNBcI7jh6ihhzJATA0r_P4bQUBm-1lmHp2DPvWM6I/s1200/image1%287%29.png>)\n\nIs it that software security is getting worse? Or is it that attackers are using 0-day exploits more? Or has our ability to detect and disclose 0-days increased? When looking at the significant uptick from 2020 to 2021, we think it's mostly explained by the latter. While we believe there has been a steady growth in interest and investment in 0-day exploits by attackers in the past several years, and that security still needs to urgently improve, it appears that the security industry's ability to detect and disclose in-the-wild 0-day exploits is the primary explanation for the increase in observed 0-day exploits in 2021.\n\nWhile we often talk about \u201c0-day exploits used in-the-wild\u201d, what we\u2019re actually tracking are \u201c0-day exploits detected and disclosed as used in-the-wild\u201d. There are more factors than just the use that contribute to an increase in that number, most notably: detection and disclosure. Better detection of 0-day exploits and more transparently disclosed exploited 0-day vulnerabilities is a positive indicator for security and progress in the industry. \n\nOverall, we can break down the uptick in the number of in-the-wild 0-days into:\n\n * More detection of in-the-wild 0-day exploits\n * More public disclosure of in-the-wild 0-day exploitation\n\n## More detection\n\nIn the [2019 Year in Review](<https://googleprojectzero.blogspot.com/2020/07/detection-deficit-year-in-review-of-0.html>), we wrote about the \u201cDetection Deficit\u201d. We stated \u201cAs a community, our ability to detect 0-days being used in the wild is severely lacking to the point that we can\u2019t draw significant conclusions due to the lack of (and biases in) the data we have collected.\u201d In the last two years, we believe that there\u2019s been progress on this gap. \n\nAnecdotally, we hear from more people that they\u2019ve begun working more on detection of 0-day exploits. Quantitatively, while a very rough measure, we\u2019re also seeing the number of entities credited with reporting in-the-wild 0-days increasing. It stands to reason that if the number of people working on trying to find 0-day exploits increases, then the number of in-the-wild 0-day exploits detected may increase.\n\n[![A bar graph showing the number of distinct reporters of 0-day in-the-wild vulnerabilities per year for 2019-2021. 2019: 9, 2020: 10, 2021: 20. The data is taken from: https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=2129022708](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiMbFpoEKSSn5AbAzsovaZ0yN6_OFXo9u4hpDCXJBpro8LRUWJlVQ9CSqtzT2V9ohrhOvP3_RnrYsOzFGPK0FZGJmW2713g2vVW82ReJVXpjAZc57BCxtHg8i-6AdR_ThDZB6UKvzAKekbmAkuUBliMyDyWSBW87z4ZZQJC3KX-_ptZIHveotLGoJ9I/s1200/image5%284%29.png)](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiMbFpoEKSSn5AbAzsovaZ0yN6_OFXo9u4hpDCXJBpro8LRUWJlVQ9CSqtzT2V9ohrhOvP3_RnrYsOzFGPK0FZGJmW2713g2vVW82ReJVXpjAZc57BCxtHg8i-6AdR_ThDZB6UKvzAKekbmAkuUBliMyDyWSBW87z4ZZQJC3KX-_ptZIHveotLGoJ9I/s1200/image5%284%29.png>)\n\n[![a line graph showing how many in-the-wild 0-days were found by their own vendor per year from 2015 to 2021. 2015: 0, 2016: 0, 2017: 2, 2018: 0, 2019: 4, 2020: 5, 2021: 17. Data comes from: https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=2129022708](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRS0t_2Bwvc3U_EIr5h7NcWpQyjzHCPb4OMiDpzPxPs587otAEj8bzwch8UMFlgKchwdSq4L_PXRn1O6KGLHUl4X9voLBdZJNQsgQyJcMCVB4Y8-aRHaXRpOYZw7KVtyNYwdWpwX8ILUV1fyG2kDsXVWORsSPUBGVTON90gWf9POhhxA4edxNe1eoV/s1200/image2%285%29.png)](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRS0t_2Bwvc3U_EIr5h7NcWpQyjzHCPb4OMiDpzPxPs587otAEj8bzwch8UMFlgKchwdSq4L_PXRn1O6KGLHUl4X9voLBdZJNQsgQyJcMCVB4Y8-aRHaXRpOYZw7KVtyNYwdWpwX8ILUV1fyG2kDsXVWORsSPUBGVTON90gWf9POhhxA4edxNe1eoV/s1200/image2%285%29.png>)\n\nWe\u2019ve also seen the number of vendors detecting in-the-wild 0-days in their own products increasing. Whether or not these vendors were previously working on detection, vendors seem to have found ways to be more successful in 2021. Vendors likely have the most telemetry and overall knowledge and visibility into their products so it\u2019s important that they are investing in (and hopefully having success in) detecting 0-days targeting their own products. As shown in the chart above, there was a significant increase in the number of in-the-wild 0-days discovered by vendors in their own products. Google discovered 7 of the in-the-wild 0-days in their own products and Microsoft discovered 10 in their products!\n\n## More disclosure\n\nThe second reason why the number of detected in-the-wild 0-days has increased is due to more disclosure of these vulnerabilities. Apple and Google Android (we differentiate \u201cGoogle Android\u201d rather than just \u201cGoogle\u201d because Google Chrome has been annotating their security bulletins for the last few years) first began labeling vulnerabilities in their security advisories with the information about potential in-the-wild exploitation in November 2020 and January 2021 respectively. When vendors don\u2019t annotate their release notes, the only way we know that a 0-day was exploited in-the-wild is if the researcher who discovered the exploitation comes forward. If Apple and Google Android had not begun annotating their release notes, the public would likely not know about at least 7 of the Apple in-the-wild 0-days and 5 of the Android in-the-wild 0-days. Why? Because these vulnerabilities were reported by \u201cAnonymous\u201d reporters. If the reporters didn\u2019t want credit for the vulnerability, it\u2019s unlikely that they would have gone public to say that there were indications of exploitation. That is 12 0-days that wouldn\u2019t have been included in this year\u2019s list if Apple and Google Android had not begun transparently annotating their security advisories. \n\n[![bar graph that shows the number of Android and Apple \\(WebKit + iOS + macOS\\) in-the-wild 0-days per year. The bar graph is split into two color: yellow for Anonymously reported 0-days and green for non-anonymous reported 0-days. 2021 is the only year with any anonymously reported 0-days. 2015: 0, 2016: 3, 2018: 2, 2019: 1, 2020: 3, 2021: Non-Anonymous: 8, Anonymous- 12. Data from: https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=2129022708](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPe_J-0Wu9Ap-0n3Yj5BoXiWTnjViyyGasIChhb3juADZosK9nTbyiaWtzuRyjwG3frQNjLsvRMRoQHrFfo1iKa3GjmcuLHqat40GcoechQ16XbhpVGwF7m_TJ0Oucvy3wvm8x0aXbVnJfhkG2FNkxI4cJf5ONBqEYnPxQDUmZChvByLHE8OzSU20N/s1200/image3%287%29.png)](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPe_J-0Wu9Ap-0n3Yj5BoXiWTnjViyyGasIChhb3juADZosK9nTbyiaWtzuRyjwG3frQNjLsvRMRoQHrFfo1iKa3GjmcuLHqat40GcoechQ16XbhpVGwF7m_TJ0Oucvy3wvm8x0aXbVnJfhkG2FNkxI4cJf5ONBqEYnPxQDUmZChvByLHE8OzSU20N/s1200/image3%287%29.png>)\n\nKudos and thank you to Microsoft, Google Chrome, and Adobe who have been annotating their security bulletins for transparency for multiple years now! And thanks to Apache who also annotated their release notes for [CVE-2021-41773](<https://httpd.apache.org/security/vulnerabilities_24.html>) this past year. \n\nIn-the-wild 0-days in Qualcomm and ARM products were annotated as in-the-wild in Android security bulletins, but not in the vendor\u2019s own security advisories.\n\nIt's highly likely that in 2021, there were other 0-days that were exploited in the wild and detected, but vendors did not mention this in their release notes. In 2022, we hope that more vendors start noting when they patch vulnerabilities that have been exploited in-the-wild. Until we\u2019re confident that all vendors are transparently disclosing in-the-wild status, there\u2019s a big question of how many in-the-wild 0-days are discovered, but not labeled publicly by vendors.\n\n# New Year, Old Techniques\n\nWe had a record number of \u201cdata points\u201d in 2021 to understand how attackers are actually using 0-day exploits. A bit surprising to us though, out of all those data points, there was nothing new amongst all this data. 0-day exploits are considered one of the most advanced attack methods an actor can use, so it would be easy to conclude that attackers must be using special tricks and attack surfaces. But instead, the 0-days we saw in 2021 generally followed the same bug patterns, attack surfaces, and exploit \u201cshapes\u201d previously seen in public research. Once \u201c0-day is hard\u201d, we\u2019d expect that to be successful, attackers would have to find new bug classes of vulnerabilities in new attack surfaces using never before seen exploitation methods. In general, that wasn't what the data showed us this year. With two exceptions (described below in the iOS section) out of the 58, everything we saw was pretty \u201c[meh](<https://www.dictionary.com/browse/meh#:~:text=unimpressive%3B%20boring%3A>)\u201d or standard.\n\nOut of the 58 in-the-wild 0-days for the year, 39, or 67% were memory corruption vulnerabilities. Memory corruption vulnerabilities have been the standard for attacking software for the last few decades and it\u2019s still how attackers are having success. Out of these memory corruption vulnerabilities, the majority also stuck with very popular and well-known bug classes:\n\n * 17 use-after-free\n * 6 out-of-bounds read & write\n * 4 buffer overflow\n * 4 integer overflow\n\nIn the next sections we\u2019ll dive into each major platform that we saw in-the-wild 0-days for this year. We\u2019ll share the trends and explain why what we saw was pretty unexceptional.\n\n## Chromium (Chrome)\n\nChromium had a record high number of 0-days detected and disclosed in 2021 with 14. Out of these 14, 10 were renderer remote code execution bugs, 2 were sandbox escapes, 1 was an infoleak, and 1 was used to open a webpage in Android apps other than Google Chrome.\n\nThe 14 0-day vulnerabilities were in the following components:\n\n * 6 JavaScript Engine - v8 ([CVE-2021-21148](<https://chromereleases.googleblog.com/2021/02/stable-channel-update-for-desktop_4.html>), [CVE-2021-30551](<https://chromereleases.googleblog.com/2021/02/stable-channel-update-for-desktop_4.html>), [CVE-2021-30563](<https://chromereleases.googleblog.com/2021/07/stable-channel-update-for-desktop.html>), [CVE-2021-30632](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30632.html>), [CVE-2021-37975](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-37975.html>), [CVE-2021-38003](<https://chromereleases.googleblog.com/2021/10/stable-channel-update-for-desktop_28.html>))\n * 2 DOM Engine - Blink ([CVE-2021-21193](<https://chromereleases.googleblog.com/2021/03/stable-channel-update-for-desktop_12.html>) & [CVE-2021-21206](<https://chromereleases.googleblog.com/2021/04/stable-channel-update-for-desktop.html>))\n * 1 WebGL ([CVE-2021-30554](<https://chromereleases.googleblog.com/2021/06/stable-channel-update-for-desktop_17.html>))\n * 1 IndexedDB ([CVE-2021-30633](<https://chromereleases.googleblog.com/2021/09/stable-channel-update-for-desktop.html>))\n * 1 webaudio ([CVE-2021-21166](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-21166.html>))\n * 1 Portals ([CVE-2021-37973](<https://chromereleases.googleblog.com/2021/09/stable-channel-update-for-desktop_24.html>))\n * 1 Android Intents ([CVE-2021-38000](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-38000.html>))\n * 1 Core ([CVE-2021-37976](<https://chromereleases.googleblog.com/2021/09/stable-channel-update-for-desktop_30.html>))\n\nWhen we look at the components targeted by these bugs, they\u2019re all attack surfaces seen before in public security research and previous exploits. If anything, there are a few less DOM bugs and more targeting these other components of browsers like IndexedDB and WebGL than previously. 13 out of the 14 Chromium 0-days were memory corruption bugs. Similar to last year, most of those memory corruption bugs are use-after-free vulnerabilities.\n\nA couple of the Chromium bugs were even similar to previous in-the-wild 0-days. [CVE-2021-21166](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-21166.html>) is an issue in ScriptProcessorNode::Process() in webaudio where there\u2019s insufficient locks such that buffers are accessible in both the main thread and the audio rendering thread at the same time. [CVE-2019-13720](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2019/CVE-2019-13720.html>) is an in-the-wild 0-day from 2019. It was a vulnerability in ConvolverHandler::Process() in webaudio where there were also insufficient locks such that a buffer was accessible in both the main thread and the audio rendering thread at the same time.\n\n[CVE-2021-30632](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30632.html>) is another Chromium in-the-wild 0-day from 2021. It\u2019s a type confusion in the TurboFan JIT in Chromium\u2019s JavaScript Engine, v8, where Turbofan fails to deoptimize code after a property map is changed. [CVE-2021-30632](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30632.html>) in particular deals with code that stores global properties. [CVE-2020-16009](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2020/CVE-2020-16009.html>) was also an in-the-wild 0-day that was due to Turbofan failing to deoptimize code after map deprecation.\n\n## WebKit (Safari)\n\nPrior to 2021, Apple had only acknowledged 1 publicly known in-the-wild 0-day targeting WebKit/Safari, and that was due the sharing by an external researcher. In 2021 there were 7. This makes it hard for us to assess trends or changes since we don\u2019t have historical samples to go off of. Instead, we\u2019ll look at 2021\u2019s WebKit bugs in the context of other Safari bugs not known to be in-the-wild and other browser in-the-wild 0-days. \n\nThe 7 in-the-wild 0-days targeted the following components:\n\n * 4 Javascript Engine - JavaScript Core ([CVE-2021-1870](<https://support.apple.com/en-us/HT212146>), [CVE-2021-1871](<https://support.apple.com/en-us/HT212146>), [CVE-2021-30663](<https://support.apple.com/en-us/HT212336>), [CVE-2021-30665](<https://support.apple.com/en-us/HT212336>))\n * 1 IndexedDB ([CVE-2021-30858](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30858.html>))\n * 1 Storage ([CVE-2021-30661](<https://support.apple.com/en-us/HT212317>))\n * 1 Plugins ([CVE-2021-1879](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1879.html>))\n\nThe one semi-surprise is that no DOM bugs were detected and disclosed. In previous years, vulnerabilities in the DOM engine have generally made up 15-20% of the in-the-wild browser 0-days, but none were detected and disclosed for WebKit in 2021. \n\nIt would not be surprising if attackers are beginning to shift to other modules, like third party libraries or things like IndexedDB. The modules may be more promising to attackers going forward because there\u2019s a better chance that the vulnerability may exist in multiple browsers or platforms. For example, the webaudio bug in Chromium, [CVE-2021-21166](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-21166.html>), also existed in WebKit and was fixed as [CVE-2021-1844](<https://support.apple.com/en-us/HT212223>), though there was no evidence it was exploited in-the-wild in WebKit. The IndexedDB in-the-wild 0-day that was used against Safari in 2021, [CVE-2021-30858](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30858.html>), was very, very similar to a [bug fixed in Chromium in January 2020](<https://bugs.chromium.org/p/chromium/issues/detail?id=1032890>).\n\n## Internet Explorer\n\nSince we began tracking in-the-wild 0-days, Internet Explorer has had a pretty consistent number of 0-days each year. 2021 actually tied 2016 for the most in-the-wild Internet Explorer 0-days we\u2019ve ever tracked even though Internet Explorer\u2019s market share of web browser users continues to decrease.\n\n[![Bar graph showing the number of Internet Explorer itw 0-days discovered per year from 2015-2021. 2015: 3, 2016: 4, 2017: 3, 2018: 1, 2019: 3, 2020: 2, 2021: 4. Data from: https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=2129022708](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbMTlnGhVLcVL8K20S3s6hSrpyB6kZAA9CWvWNpn1isbEbLFv0c2rs_dPvM0ALT45NtTvyhp8rGehGDRIAEJ6OZYSkk5mezOEoPJOquVXXyHeqrVOvRGEiQHv_J7Je8Itjc5qhwXMCR-E4y79abuxiddCYoeF2VrVakY-L1q82NeMEPjTA0fFC-t8h/s1200/image4%286%29.png)](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbMTlnGhVLcVL8K20S3s6hSrpyB6kZAA9CWvWNpn1isbEbLFv0c2rs_dPvM0ALT45NtTvyhp8rGehGDRIAEJ6OZYSkk5mezOEoPJOquVXXyHeqrVOvRGEiQHv_J7Je8Itjc5qhwXMCR-E4y79abuxiddCYoeF2VrVakY-L1q82NeMEPjTA0fFC-t8h/s1200/image4%286%29.png>)\n\nSo why are we seeing so little change in the number of in-the-wild 0-days despite the change in market share? Internet Explorer is still a ripe attack surface for initial entry into Windows machines, even if the user doesn\u2019t use Internet Explorer as their Internet browser. While the number of 0-days stayed pretty consistent to what we\u2019ve seen in previous years, the components targeted and the delivery methods of the exploits changed. 3 of the 4 0-days seen in 2021 targeted the MSHTML browser engine and were delivered via methods other than the web. Instead they were delivered to targets via Office documents or other file formats. \n\nThe four 0-days targeted the following components:\n\n * MSHTML browser engine ([CVE-2021-26411](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26411.html>), [CVE-2021-33742](<https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2021/CVE-2021-33742.html>), [CVE-2021-40444](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444>))\n * Javascript Engine - JScript9 ([CVE-2021-34448](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34448>))\n\nFor [CVE-2021-26411](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26411.html>) targets of the campaign initially received a .mht file, which prompted the user to open in Internet Explorer. Once it was opened in Internet Explorer, the exploit was downloaded and run. [CVE-2021-33742](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-33742.html>) and [CVE-2021-40444](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444>) were delivered to targets via malicious Office documents.\n\n[CVE-2021-26411](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26411.html>) and [CVE-2021-33742](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-33742.html>) were two common memory corruption bug patterns: a use-after-free due to a user controlled callback in between two actions using an object and the user frees the object during that callback and a buffer overflow.\n\nThere were a few different vulnerabilities used in the exploit chain that used [CVE-2021-40444](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444>), but the one within MSHTML was that as soon as the Office document was opened the payload would run: a CAB file was downloaded, decompressed, and then a function from within a DLL in that CAB was executed. Unlike the previous two MSHTML bugs, this was a logic error in URL parsing rather than a memory corruption bug.\n\n## Windows\n\nWindows is the platform where we\u2019ve seen the most change in components targeted compared with previous years. However, this shift has generally been in progress for a few years and predicted with the end-of-life of Windows 7 in 2020 and thus why it\u2019s still not especially novel.\n\nIn 2021 there were 10 Windows in-the-wild 0-days targeting 7 different components:\n\n * 2 Enhanced crypto provider ([CVE-2021-31199](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31199>), [CVE-2021-31201](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31201>))\n * 2 NTOS kernel ([CVE-2021-33771](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-33771>), [CVE-2021-31979](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31979>))\n * 2 Win32k ([CVE-2021-1732](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1732.html>), [CVE-2021-40449](<https://securelist.com/mysterysnail-attacks-with-windows-zero-day/104509/>))\n * 1 Windows update medic ([CVE-2021-36948](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36948>)) \n * 1 SuperFetch ([CVE-2021-31955](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31955>))\n * 1 dwmcore.dll ([CVE-2021-28310](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-28310>))\n * 1 ntfs.sys ([CVE-2021-31956](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31956>))\n\nThe number of different components targeted is the shift from past years. For example, in 2019 75% of Windows 0-days targeted Win32k while in 2021 Win32k only made up 20% of the Windows 0-days. The reason that this was expected and predicted was that 6 out of 8 of those 0-days that targeted Win32k in 2019 did not target the latest release of Windows 10 at that time; they were targeting older versions. With Windows 10 Microsoft began dedicating more and more resources to locking down the attack surface of Win32k so as those older versions have hit end-of-life, Win32k is a less and less attractive attack surface.\n\nSimilar to the many Win32k vulnerabilities seen over the years, the two 2021 Win32k in-the-wild 0-days are due to custom user callbacks. The user calls functions that change the state of an object during the callback and Win32k does not correctly handle those changes. [CVE-2021-1732](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1732.html>) is a type confusion vulnerability due to a user callback in xxxClientAllocWindowClassExtraBytes which leads to out-of-bounds read and write. If NtUserConsoleControl is called during the callback a flag is set in the window structure to signal that a field is an offset into the kernel heap. xxxClientAllocWindowClassExtraBytes doesn\u2019t check this and writes that field as a user-mode pointer without clearing the flag. The first in-the-wild 0-day detected and disclosed in 2022, [CVE-2022-21882](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2022/CVE-2022-21882.html>), is due to [CVE-2021-1732](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1732.html>) actually not being fixed completely. The attackers found a way to bypass the original patch and still trigger the vulnerability. [CVE-2021-40449](<https://securelist.com/mysterysnail-attacks-with-windows-zero-day/104509/>) is a use-after-free in NtGdiResetDC due to the object being freed during the user callback. \n\n## iOS/macOS\n\nAs discussed in the \u201cMore disclosure\u201d section above, 2021 was the first full year that Apple annotated their release notes with in-the-wild status of vulnerabilities. 5 iOS in-the-wild 0-days were detected and disclosed this year. The first publicly known macOS in-the-wild 0-day ([CVE-2021-30869](<https://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/>)) was also found. In this section we\u2019re going to discuss iOS and macOS together because: 1) the two operating systems include similar components and 2) the sample size for macOS is very small (just this one vulnerability).\n\n[![Bar graph showing the number of macOS and iOS itw 0-days discovered per year. macOs is 0 for every year except 2021 when 1 was discovered. iOS - 2015: 0, 2016: 2, 2017: 0, 2018: 2, 2019: 0, 2020: 3, 2021: 5. Data from: https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=2129022708](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPGaOlQUGIYyvpDY_M0rGh3JekH4mwXHfN459HYcklg74v4Mfp8j6fgh2SM09mjhA4svdgN_TdSN3R5Bb-DJTHnlo63qnRTsvLs1EZgAE3fBpRtsZhxKhyBNTb_khdS6mNT3EtSHnS_R-TshtHx-gSWnEPpHjmSqO_9Y7JxupGcDKZ0-xwsxgbX6zR/s1200/image6%284%29.png)](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPGaOlQUGIYyvpDY_M0rGh3JekH4mwXHfN459HYcklg74v4Mfp8j6fgh2SM09mjhA4svdgN_TdSN3R5Bb-DJTHnlo63qnRTsvLs1EZgAE3fBpRtsZhxKhyBNTb_khdS6mNT3EtSHnS_R-TshtHx-gSWnEPpHjmSqO_9Y7JxupGcDKZ0-xwsxgbX6zR/s1200/image6%284%29.png>)\n\nFor the 5 total iOS and macOS in-the-wild 0-days, they targeted 3 different attack surfaces:\n\n * IOMobileFrameBuffer ([CVE-2021-30807](<https://support.apple.com/en-us/HT212623>), [CVE-2021-30883](<https://support.apple.com/en-us/HT212846>))\n * XNU Kernel ([CVE-2021-1782](<https://support.apple.com/en-us/HT212146>) & [CVE-2021-30869](<https://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/>))\n * CoreGraphics ([CVE-2021-30860](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>))\n * CommCenter ([FORCEDENTRY sandbox escape](<https://googleprojectzero.blogspot.com/2022/03/forcedentry-sandbox-escape.html>) \\- CVE requested, not yet assigned)\n\nThese 4 attack surfaces are not novel. IOMobileFrameBuffer has been a target of public security research for many years. For example, the Pangu Jailbreak from 2016 used [CVE-2016-4654](<https://www.blackhat.com/docs/us-16/materials/us-16-Wang-Pangu-9-Internals.pdf>), a heap buffer overflow in IOMobileFrameBuffer. IOMobileFrameBuffer manages the screen\u2019s frame buffer. For iPhone 11 (A13) and below, IOMobileFrameBuffer was a kernel driver. Beginning with A14, it runs on a coprocessor, the DCP. It\u2019s a popular attack surface because historically it\u2019s been accessible from sandboxed apps. In 2021 there were two in-the-wild 0-days in IOMobileFrameBuffer. [CVE-2021-30807](<https://support.apple.com/en-us/HT212623>) is an out-of-bounds read and [CVE-2021-30883](<https://support.apple.com/en-us/HT212846>) is an integer overflow, both common memory corruption vulnerabilities. In 2022, we already have another in-the-wild 0-day in IOMobileFrameBuffer, [CVE-2022-22587](<https://support.apple.com/en-us/HT213053>).\n\nOne iOS 0-day and the macOS 0-day both exploited vulnerabilities in the XNU kernel and both vulnerabilities were in code related to XNU\u2019s inter-process communication (IPC) functionality. [CVE-2021-1782](<https://support.apple.com/en-us/HT212146>) exploited a vulnerability in mach vouchers while [CVE-2021-30869](<https://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/>) exploited a vulnerability in mach messages. This is not the first time we\u2019ve seen iOS in-the-wild 0-days, much less public security research, targeting mach vouchers and mach messages. [CVE-2019-6625](<https://support.apple.com/en-us/HT209443>) was exploited as a part of [an exploit chain targeting iOS 11.4.1-12.1.2](<https://googleprojectzero.blogspot.com/2019/08/in-wild-ios-exploit-chain-5.html>) and was also a [vulnerability in mach vouchers](<https://googleprojectzero.blogspot.com/2019/01/voucherswap-exploiting-mig-reference.html>). \n\nMach messages have also been a popular target for public security research. In 2020 there were two in-the-wild 0-days also in mach messages: [CVE-2020-27932](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2020/CVE-2020-27932.html>) & [CVE-2020-27950](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2020/CVE-2020-27950.html>). This year\u2019s [CVE-2021-30869](<https://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/>) is a pretty close variant to 2020\u2019s [CVE-2020-27932](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2020/CVE-2020-27932.html>). Tielei Wang and Xinru Chi actually [presented on this vulnerability at zer0con 2021](<https://github.com/wangtielei/Slides/blob/main/zer0con21.pdf>) in April 2021. In their presentation, they explained that they found it while doing variant analysis on [CVE-2020-27932](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2020/CVE-2020-27932.html>). [TieLei Wang explained via Twitter](<https://twitter.com/WangTielei/status/1486266258152726530>) that they had found the vulnerability in December 2020 and had noticed it was fixed in beta versions of iOS 14.4 and macOS 11.2 which is why they presented it at Zer0Con. The in-the-wild exploit only targeted macOS 10, but used the same exploitation technique as the one presented.\n\nThe two FORCEDENTRY exploits ([CVE-2021-30860](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>) and the [sandbox escape](<https://googleprojectzero.blogspot.com/2022/03/forcedentry-sandbox-escape.html>)) were the only times that made us all go \u201cwow!\u201d this year. For [CVE-2021-30860](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>), the integer overflow in CoreGraphics, it was because: \n\n 1. For years we\u2019ve all heard about how attackers are using 0-click iMessage bugs and finally we have a public example, and\n 2. The exploit was an impressive work of art. \n\nThe sandbox escape (CVE requested, not yet assigned) was impressive because it\u2019s one of the few times we\u2019ve seen a sandbox escape in-the-wild that uses only logic bugs, rather than the standard memory corruption bugs. \n\nFor [CVE-2021-30860](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>), the vulnerability itself wasn\u2019t especially notable: a classic integer overflow within the JBIG2 parser of the CoreGraphics PDF decoder. The exploit, though, was described by Samuel Gro\u00df & Ian Beer as \u201cone of the most technically sophisticated exploits [they]\u2019ve ever seen\u201d. [Their blogpost shares all the details](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>), but the highlight is that the exploit uses the logical operators available in JBIG2 to build NAND gates which are used to build its own computer architecture. The exploit then writes the rest of its exploit using that new custom architecture. From their blogpost:\n\nUsing over 70,000 segment commands defining logical bit operations, they define a small computer architecture with features such as registers and a full 64-bit adder and comparator which they use to search memory and perform arithmetic operations. It's not as fast as Javascript, but it's fundamentally computationally equivalent.\n\nThe bootstrapping operations for the sandbox escape exploit are written to run on this logic circuit and the whole thing runs in this weird, emulated environment created out of a single decompression pass through a JBIG2 stream. It's pretty incredible, and at the same time, pretty terrifying.\n\nThis is an example of what making 0-day exploitation hard could look like: attackers having to develop a new and novel way to exploit a bug and that method requires lots of expertise and/or time to develop. This year, the two FORCEDENTRY exploits were the only 0-days out of the 58 that really impressed us. Hopefully in the future, the bar has been raised such that this will be required for any successful exploitation.\n\n## Android\n\nThere were 7 Android in-the-wild 0-days detected and disclosed this year. Prior to 2021 there had only been 1 and it was in 2019: [CVE-2019-2215](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2019/CVE-2019-2215.html>). Like WebKit, this lack of data makes it hard for us to assess trends and changes. Instead, we\u2019ll compare it to public security research.\n\nFor the 7 Android 0-days they targeted the following components:\n\n * Qualcomm Adreno GPU driver ([CVE-2020-11261](<https://source.android.com/security/bulletin/2021-01-01>), [CVE-2021-1905](<https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2021/CVE-2021-1905.html>), [CVE-2021-1906](<https://source.android.com/security/bulletin/2021-05-01>))\n * ARM Mali GPU driver ([CVE-2021-28663](<https://source.android.com/security/bulletin/2021-05-01>), [CVE-2021-28664](<https://source.android.com/security/bulletin/2021-05-01>))\n * Upstream Linux kernel ([CVE-2021-1048](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1048.html>), [CVE-2021-0920](<https://source.android.com/security/bulletin/2021-11-01#kernel-components>))\n\n5 of the 7 0-days from 2021 targeted GPU drivers. This is actually not that surprising when we consider the evolution of the Android ecosystem as well as recent public security research into Android. The Android ecosystem is quite fragmented: many different kernel versions, different manufacturer customizations, etc. If an attacker wants a capability against \u201cAndroid devices\u201d, they generally need to maintain many different exploits to have a decent percentage of the Android ecosystem covered. However, if the attacker chooses to target the GPU kernel driver instead of another component, they will only need to have two exploits since most Android devices use 1 of 2 GPUs: either the Qualcomm Adreno GPU or the ARM Mali GPU. \n\nPublic security research mirrored this choice in the last couple of years as well. When developing full exploit chains (for defensive purposes) to target Android devices, [Guang Gong](<https://github.com/secmob/TiYunZong-An-Exploit-Chain-to-Remotely-Root-Modern-Android-Devices/blob/master/us-20-Gong-TiYunZong-An-Exploit-Chain-to-Remotely-Root-Modern-Android-Devices-wp.pdf>), [Man Yue Mo](<https://securitylab.github.com/research/one_day_short_of_a_fullchain_android/>), and [Ben Hawkes](<https://googleprojectzero.blogspot.com/2020/09/attacking-qualcomm-adreno-gpu.html>) all chose to attack the GPU kernel driver for local privilege escalation. Seeing the in-the-wild 0-days also target the GPU was more of a confirmation rather than a revelation. Of the 5 0-days targeting GPU drivers, 3 were in the Qualcomm Adreno driver and 2 in the ARM Mali driver. \n\nThe two non-GPU driver 0-days ([CVE-2021-0920](<https://source.android.com/security/bulletin/2021-11-01#kernel-components>) and [CVE-2021-1048](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1048.html>)) targeted the upstream Linux kernel. Unfortunately, these 2 bugs shared a singular characteristic with the Android in-the-wild 0-day seen in 2019: all 3 were previously known upstream before their exploitation in Android. While the sample size is small, it\u2019s still quite striking to see that 100% of the known in-the-wild Android 0-days that target the kernel are bugs that actually were known about before their exploitation.\n\nThe vulnerability now referred to as [CVE-2021-0920](<https://source.android.com/security/bulletin/2021-11-01#kernel-components>) was actually found in September 2016 and [discussed on the Linux kernel mailing lists](<https://lore.kernel.org/lkml/CAOssrKcfncAYsQWkfLGFgoOxAQJVT2hYVWdBA6Cw7hhO8RJ_wQ@mail.gmail.com/>). A [patch was even developed back in 2016](<https://lore.kernel.org/lkml/1475150954-10152-1-git-send-email-mszeredi@redhat.com/>), but it didn\u2019t end up being submitted. The bug was finally [fixed in the Linux kernel in July 2021](<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cbcf01128d0a92e131bd09f1688fe032480b65ca>) after the detection of the in-the-wild exploit targeting Android. The patch then made it into the [Android security bulletin in November 2021](<https://source.android.com/security/bulletin/2021-11-01#kernel-components>).\n\n[CVE-2021-1048](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1048.html>) remained unpatched in Android for 14 months after it was patched in the Linux kernel. The Linux kernel was actually only vulnerable to the issue for a few weeks, but due to Android patching practices, that few weeks became almost a year for some Android devices. If an Android OEM synced to the upstream kernel, then they likely were patched against the vulnerability at some point. But many devices, such as recent Samsung devices, had not and thus were left vulnerable.\n\n## Microsoft Exchange Server\n\nIn 2021, there were 5 in-the-wild 0-days targeting Microsoft Exchange Server. This is the first time any Exchange Server in-the-wild 0-days have been detected and disclosed since we began tracking in-the-wild 0-days. The first four ([CVE-2021-26855](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26855.html>), [CVE-2021-26857](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26857>), [CVE-2021-26858](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26858>), and [CVE-2021-27065](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-27065>)) were all disclosed and patched at the same time and used together in a [single operation](<https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/>). The fifth ([CVE-2021-42321](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321>)) was patched on its own in November 2021. [CVE-2021-42321](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321>) was demonstrated at Tianfu Cup and then discovered in-the-wild by Microsoft. While no other in-the-wild 0-days were disclosed as part of the chain with [CVE-2021-42321](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321>), the attackers would have required at least another 0-day for successful exploitation since [CVE-2021-42321](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321>) is a post-authentication bug.\n\nOf the four Exchange in-the-wild 0-days used in the first campaign, [CVE-2021-26855](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26855.html>), which is also known as \u201cProxyLogon\u201d, is the only one that\u2019s pre-auth. [CVE-2021-26855](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26855.html>) is a server side request forgery (SSRF) vulnerability that allows unauthenticated attackers to send arbitrary HTTP requests as the Exchange server. The other three vulnerabilities were post-authentication. For example, [CVE-2021-26858](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26858>) and [CVE-2021-27065](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-27065>) allowed attackers to write arbitrary files to the system. [CVE-2021-26857](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26857>) is a remote code execution vulnerability due to a deserialization bug in the Unified Messaging service. This allowed attackers to run code as the privileged SYSTEM user.\n\nFor the second campaign, [CVE-2021-42321](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321>), like [CVE-2021-26858](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26858>), is a post-authentication RCE vulnerability due to insecure deserialization. It seems that while attempting to harden Exchange, Microsoft inadvertently introduced another deserialization vulnerability.\n\nWhile there were a significant amount of 0-days in Exchange detected and disclosed in 2021, it\u2019s important to remember that they were all used as 0-day in only two different campaigns. This is an example of why we don\u2019t suggest using the number of 0-days in a product as a metric to assess the security of a product. Requiring the use of four 0-days for attackers to have success is preferable to an attacker only needing one 0-day to successfully gain access.\n\nWhile this is the first time Exchange in-the-wild 0-days have been detected and disclosed since Project Zero began our tracking, this is not unexpected. In 2020 there was [n-day exploitation of Exchange Servers](<https://www.cisa.gov/uscert/ncas/current-activity/2020/03/10/unpatched-microsoft-exchange-servers-vulnerable-cve-2020-0688>). Whether this was the first year that attackers began the 0-day exploitation or if this was the first year that defenders began detecting the 0-day exploitation, this is not an unexpected evolution and we\u2019ll likely see it continue into 2022.\n\n# Outstanding Questions\n\nWhile there has been progress on detection and disclosure, that progress has shown just how much work there still is to do. The more data we gained, the more questions that arose about biases in detection, what we\u2019re missing and why, and the need for more transparency from both vendors and researchers.\n\nUntil the day that attackers decide to happily share all their exploits with us, we can\u2019t fully know what percentage of 0-days are publicly known about. However when we pull together our expertise as security researchers and anecdotes from others in the industry, it paints a picture of some of the data we\u2019re very likely missing. From that, these are some of the key questions we\u2019re asking ourselves as we move into 2022:\n\n## Where are the [x] 0-days?\n\nDespite the number of 0-days found in 2021, there are key targets missing from the 0-days discovered. For example, we know that messaging applications like WhatsApp, Signal, Telegram, etc. are targets of interest to attackers and yet there\u2019s only 1 messaging app, in this case iMessage, 0-day found this past year. Since we began tracking in mid-2014 the total is two: a WhatsApp 0-day in 2019 and this iMessage 0-day found in 2021.\n\nAlong with messaging apps, there are other platforms/targets we\u2019d expect to see 0-days targeting, yet there are no or very few public examples. For example, since mid-2014 there\u2019s only one in-the-wild 0-day each for macOS and Linux. There are no known in-the-wild 0-days targeting cloud, CPU vulnerabilities, or other phone components such as the WiFi chip or the baseband.\n\nThis leads to the question of whether these 0-days are absent due to lack of detection, lack of disclosure, or both?\n\n## Do some vendors have no known in-the-wild 0-days because they\u2019ve never been found or because they don\u2019t publicly disclose?\n\nUnless a vendor has told us that they will publicly disclose exploitation status for all vulnerabilities in their platforms, we, the public, don\u2019t know if the absence of an annotation means that there is no known exploitation of a vulnerability or if there is, but the vendor is just not sharing that information publicly. Thankfully this question is something that has a pretty clear solution: all device and software vendors agreeing to publicly disclose when there is evidence to suggest that a vulnerability in their product is being exploited in-the-wild.\n\n## Are we seeing the same bug patterns because that\u2019s what we know how to detect?\n\nAs we described earlier in this report, all the 0-days we saw in 2021 had similarities to previously seen vulnerabilities. This leads us to wonder whether or not that\u2019s actually representative of what attackers are using. Are attackers actually having success exclusively using vulnerabilities in bug classes and components that are previously public? Or are we detecting all these 0-days with known bug patterns because that\u2019s what we know how to detect? Public security research would suggest that yes, attackers are still able to have success with using vulnerabilities in known components and bug classes the majority of the time. But we\u2019d still expect to see a few novel and unexpected vulnerabilities in the grouping. We posed this question back in the 2019 year-in-review and it still lingers. \n\n## Where are the spl0itz?\n\nTo successfully exploit a vulnerability there are two key pieces that make up that exploit: the vulnerability being exploited, and the exploitation method (how that vulnerability is turned into something useful). \n\nUnfortunately, this report could only really analyze one of these components: the vulnerability. Out of the 58 0-days, only 5 have an exploit sample publicly available. Discovered in-the-wild 0-days are the failure case for attackers and a key opportunity for defenders to learn what attackers are doing and make it harder, more time-intensive, more costly, to do it again. Yet without the exploit sample or a detailed technical write-up based upon the sample, we can only focus on fixing the vulnerability rather than also mitigating the exploitation method. This means that attackers are able to continue to use their existing exploit methods rather than having to go back to the design and development phase to build a new exploitation method. While acknowledging that sharing exploit samples can be challenging (we have that challenge too!), we hope in 2022 there will be more sharing of exploit samples or detailed technical write-ups so that we can come together to use every possible piece of information to make it harder for the attackers to exploit more users.\n\nAs an aside, if you have an exploit sample that you\u2019re willing to share with us, please reach out. Whether it\u2019s sharing with us and having us write a detailed technical description and analysis or having us share it publicly, we\u2019d be happy to work with you.\n\n# Conclusion\n\nLooking back on 2021, what comes to mind is \u201cbaby steps\u201d. We can see clear industry improvement in the detection and disclosure of 0-day exploits. But the better detection and disclosure has highlighted other opportunities for progress. As an industry we\u2019re not making 0-day hard. Attackers are having success using vulnerabilities similar to what we\u2019ve seen previously and in components that have previously been discussed as attack surfaces.The goal is to force attackers to start from scratch each time we detect one of their exploits: they\u2019re forced to discover a whole new vulnerability, they have to invest the time in learning and analyzing a new attack surface, they must develop a brand new exploitation method. And while we made distinct progress in detection and disclosure it has shown us areas where that can continue to improve.\n\nWhile this all may seem daunting, the promising part is that we\u2019ve done it before: we have made clear progress on previously daunting goals. In 2019, we discussed the large detection deficit for 0-day exploits and 2 years later more than double were detected and disclosed. So while there is still plenty more work to do, it\u2019s a tractable problem. There are concrete steps that the tech and security industries can take to make it even more progress: \n\n\n 1. Make it an industry standard behavior for all vendors to publicly disclose when there is evidence to suggest that a vulnerability in their product is being exploited,\n 2. Vendors and security researchers sharing exploit samples or detailed descriptions of the exploit techniques.\n 3. Continued concerted efforts on reducing memory corruption vulnerabilities or rendering them unexploitable.\n\nThrough 2021 we continually saw the real world impacts of the use of 0-day exploits against users and entities. Amnesty International, the Citizen Lab, and others highlighted [over](<https://citizenlab.ca/2021/10/breaking-news-new-york-times-journalist-ben-hubbard-pegasus/>) and [over](<https://www.amnesty.org/en/documents/doc10/4491/2021/en/>) how governments were using commercial surveillance products against [journalists](<https://forbiddenstories.org/pegasus-the-new-global-weapon-for-silencing-journalists/>), [human rights defenders](<https://www.amnesty.org/en/latest/research/2021/11/devices-of-palestinian-human-rights-defenders-hacked-with-nso-groups-pegasus-spyware-2/>), and [government officials](<https://www.reuters.com/technology/exclusive-us-state-department-phones-hacked-with-israeli-company-spyware-sources-2021-12-03/>). We saw many enterprises scrambling to remediate and protect themselves from the [Exchange Server 0-days](<https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/>). And we even learned of peer [security researchers being targeted by ](<https://blog.google/threat-analysis-group/update-campaign-targeting-security-researchers/>)[North Korean government hackers](<https://blog.google/threat-analysis-group/update-campaign-targeting-security-researchers/>). While the majority of people on the planet do not need to worry about their own personal risk of being targeted with 0-days, 0-day exploitation still affects us all. These 0-days tend to have an outsized impact on society so we need to continue doing whatever we can to make it harder for attackers to be successful in these attacks.\n\n2021 showed us we\u2019re on the right track and making progress, but there\u2019s plenty more to be done to make 0-day hard.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2022-04-19T00:00:00", "type": "googleprojectzero", "title": "\nThe More You Know, The More You Know You Don\u2019t Know\n", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2016-4654", "CVE-2019-13720", "CVE-2019-2215", "CVE-2019-6625", "CVE-2020-0688", "CVE-2020-11261", "CVE-2020-16009", "CVE-2020-27932", "CVE-2020-27950", "CVE-2021-0920", "CVE-2021-1048", "CVE-2021-1732", "CVE-2021-1782", "CVE-2021-1844", "CVE-2021-1870", "CVE-2021-1871", "CVE-2021-1879", "CVE-2021-1905", "CVE-2021-1906", "CVE-2021-21148", "CVE-2021-21166", "CVE-2021-21193", "CVE-2021-21206", "CVE-2021-26411", "CVE-2021-26855", "CVE-2021-26857", "CVE-2021-26858", "CVE-2021-27065", "CVE-2021-28310", "CVE-2021-28663", "CVE-2021-28664", "CVE-2021-30551", "CVE-2021-30554", "CVE-2021-30563", "CVE-2021-30632", "CVE-2021-30633", "CVE-2021-30661", "CVE-2021-30663", "CVE-2021-30665", "CVE-2021-30737", "CVE-2021-30807", "CVE-2021-30858", "CVE-2021-30860", "CVE-2021-30869", "CVE-2021-30883", "CVE-2021-31199", "CVE-2021-31201", "CVE-2021-31955", "CVE-2021-31956", "CVE-2021-31979", "CVE-2021-33742", "CVE-2021-33771", "CVE-2021-34448", "CVE-2021-36948", "CVE-2021-37973", "CVE-2021-37975", "CVE-2021-37976", "CVE-2021-38000", "CVE-2021-38003", "CVE-2021-40444", "CVE-2021-40449", "CVE-2021-41773", "CVE-2021-42321", "CVE-2022-21882", "CVE-2022-22587"], "modified": "2022-04-19T00:00:00", "id": "GOOGLEPROJECTZERO:CA925EE6A931620550EF819815B14156", "href": "https://googleprojectzero.blogspot.com/2022/04/the-more-you-know-more-you-know-you.html", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}]}

WARNING: A New Android Zero-Day Vulnerability Is Under Active Attack

Description

Related