MediaTek’s September bulletin says its severity ratings come from CVSS v3.1. Three of the five flaws it labels High carry MediaTek’s own CVSS v3.1 scores of 5.5, 5.3 and 5.3 — Medium — and rank below four it labels Medium.
What happened
MediaTek published its September 2026 Product Security Bulletin on Monday, September 7, 2026, covering 18 CVEs across its chipset portfolio. NVD carried the matching records the same day, timestamped 2:17 a.m. UTC, all from [email protected] — MediaTek is its own CNA, so the bulletin and the CVE records are two publications by the same organization on the same day about the same bugs.
The bulletin states how it grades: “The severity of the identified vulnerabilities was conducted based on the Common Vulnerability Scoring System version 3.1 (CVSS v3.1).” It also says that “Device OEMs have been notified of all the issues and the corresponding security patches for at least two months before publication,” and that “At this time, we are not aware of any active exploitation of these vulnerabilities in the wild.”
Five entries carry the word High in the bulletin’s severity column: CVE-2026-20500, CVE-2026-20501, CVE-2026-20502, CVE-2026-20503 and CVE-2026-20504. The other thirteen are labeled Medium.
Now the scores MediaTek assigned to those same CVEs as CNA, read from the NVD records:
- CVE-2026-20500 — bulletin: High. CVSS v3.1 base score 5.5, MEDIUM, vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. “In Modem, there is a possible system crash due to improper input validation. This could lead to local denial of service with User execution privileges needed.” - CVE-2026-20503 — bulletin: High. CVSS v3.1 base score 5.3, MEDIUM, vector
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H. “In Modem, there is a possible system crash due to a missing bounds check. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed.” - CVE-2026-20504 — bulletin: High. CVSS v3.1 base score 5.3, MEDIUM, same vector, same description.
Against four the bulletin calls Medium:
- CVE-2026-20506 and CVE-2026-20507 — Audio HAL use-after-free, CVSS v3.1 6.7,
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, CWE-416. - CVE-2026-20508 — Power HAL type confusion, 6.7, same vector.
- CVE-2026-20517 — geniezone use-after-free, 6.7, same vector, CWE-416.
Under the CVSS v3.1 qualitative scale, 4.0 through 6.9 is Medium and 7.0 through 8.9 is High. So three of the five items MediaTek calls High are Medium by the very standard the bulletin names, and every one of them scores below four items MediaTek calls Medium. Only CVE-2026-20501 and CVE-2026-20502, the two vdec heap and out-of-bounds write bugs, cross 7.0; both scored 8.4 in the batch retrieval used here.
One more defect in the same batch. CVE-2026-20500 is classified CWE-295, Improper Certificate Validation. Its description is a modem crash from improper input validation with no certificate, no TLS and no trust decision anywhere in it. CWE-20 or CWE-1284 is the obvious fit. The other records in the batch are classified sensibly — CWE-617 for the reachable assertions, CWE-416 for the use-after-frees — which makes this one look like a single slip rather than a systematic problem.
None of the 18 records carries CPE data. All were in Received status at the time of reading, which means no NVD analysis, no configuration block, and nothing for a version-matching scanner to bind to.
Why it matters
A vendor advisory that carries two severity systems is common. Google’s Android Security Bulletin has long rated a remote denial of service on the modem above a local privilege escalation, on the reasonable view that something an attacker reaches over the air matters more than something requiring code already running as System. On that rubric, MediaTek’s word ordering is defensible and arguably better calibrated than the arithmetic: CVE-2026-20503 needs only that a handset attach to a rogue base station, while CVE-2026-20517 needs the attacker to hold System privilege first. CVSS v3.1 punishes AV:A combined with AC:H severely and rewards C:H/I:H/A:H generously even behind PR:H, and that is how a bug requiring existing System access outscores one requiring only radio proximity.
That reconciliation is available to a reader who knows the Android rubric exists. It is not available from this document, because this document says the severity ratings were “conducted based on” CVSS v3.1. If the bulletin said it graded on operational risk, or on Android’s severity classifications, the word and the number would be two measurements and a reader could hold both. Saying the word is the number, and then publishing a number that contradicts it, leaves no way to reconcile them from the primary source. That is what makes this a record problem rather than a methodology disagreement.
The practical consequence is that triage splits by tooling. A person reading the bulletin escalates the three modem flaws and defers the HAL bugs. A pipeline ingesting the CVE feed and sorting on CVSS does the exact opposite, because 6.7 sorts above 5.3. Both are following MediaTek. Neither can tell from MediaTek’s own material that the other exists, and in an organization running both, the same 18 CVEs produce two different priority orders from one vendor’s publications.
Then there is the part that makes the argument mostly theoretical. With no CPE on any record, none of these will match a device inventory automatically. There is no fixed firmware version in the bulletin to check against — there cannot be, because MediaTek does not ship firmware to handsets. The patches went to OEMs “at least two months before publication,” and whether they reached a given device depends on that OEM’s release schedule and on how long the model has been in support. For a fleet manager, the actionable artifact is not the CVE at all. It is the Android security patch level on the handset, and the bulletin does not say which patch level carries these fixes.
This is the recurring shape of silicon-vendor advisories, and it is worth naming plainly: the entity that knows the bug has no relationship with the device owner, the entity with that relationship did not find the bug, and the record that is supposed to connect them carries no version data. The severity disagreement is a symptom. Even resolved perfectly, it would not tell anyone which phones on their network are still exposed.
What to do
Triage on the vector, not the word or the score. For this batch the split is clean. CVE-2026-20500, CVE-2026-20503 and CVE-2026-20504 are availability-only modem crashes: no confidentiality or integrity impact, and the two remote ones require the device to attach to an attacker-controlled base station. CVE-2026-20506, CVE-2026-20507, CVE-2026-20508 and CVE-2026-20517 are full-impact local escalations that require System privilege as a precondition — serious as the second stage of a chain, useless as a first stage. Neither group is remote pre-authentication code execution. Nothing here warrants an emergency.
Track the patch level, not the CVE. Set and enforce a minimum Android security patch level through your MDM and measure your fleet against it. That is the only control that reaches these bugs. Devices past their OEM support window will not receive these fixes at all, and no scanner will tell you so.
If you filter CVE feeds by CWE, do not trust CWE-295 on CVE-2026-20500. A rule that routes certificate-validation weaknesses to your PKI or transport owners will misfile a modem input-validation crash.
If you build products on these chipsets, the chipset lists matter more than the severities. CVE-2026-20501 and CVE-2026-20502 name roughly 50 part numbers each and CVE-2026-20503 names more than 55, spanning phones, tablets and smart-display silicon. CVE-2026-20516, the MiracastService privilege escalation, is scoped entirely to MT5xxx and MT9xxx television parts — a reminder that a MediaTek bulletin is not only a handset document.
Sourcing note
Checked: MediaTek’s September 2026 Product Security Bulletin, read directly, twice, with the second read directed specifically at the severity column to confirm the printed words for CVE-2026-20500, 20503, 20504, 20506, 20507, 20508 and 20517. The quoted sentences on severity methodology, OEM notification and exploitation are from that bulletin. The CVSS scores, vectors, CWE classifications and Received status for CVE-2026-20500, 20503, 20504, 20506 and 20517 were each read from the NVD API record for that CVE individually, and the absence of CPE data was confirmed by a query that asked for it explicitly rather than by a general summary.
Could not reach: The individual NVD records for CVE-2026-20501 and CVE-2026-20502 could not be re-read — the API began returning HTTP 429 partway through this run. Their base scores of 8.4 come from a single bulk NVD query covering the day’s publications and have not been independently re-confirmed. Nothing in this story’s central finding depends on them; they are the two entries where the bulletin’s word and the score agree.
Unresolved: MediaTek has not been asked why the bulletin’s severity words diverge from its own CVSS scores, and the bulletin offers no second rubric that would explain it. The Android Security Bulletin rubric is offered here as the most plausible explanation, not as MediaTek’s stated reason. Which Android security patch level carries these fixes is not stated in the bulletin and could not be determined. Whether NVD will later add CPE data, or whether CISA’s ADP channel will add its own scores as it has on other unscored records, is unknown at the time of writing.